Comment Lemon Squeezy gère les paiements d’abonnement échoués

Quand le renouvellement d’un abonnement échoue sur Lemon Squeezy, beaucoup de choses se passent sans que vous ayez à intervenir : le prélèvement est retenté, le client reçoit des emails, et l’abonnement passe par quelques statuts avant de prendre fin. Savoir exactement ce que fait Lemon Squeezy, et ce qu’il vous laisse, fait la différence entre un client qui disparaît en silence et un client qui met à jour sa carte.

Ce guide parcourt ce cycle étape par étape, puis donne des conseils pratiques à appliquer dans votre propre appli. Il s’en tient à la documentation de Lemon Squeezy : la page d’aide Recovery and Dunning, la référence de l’objet Subscription, les types d’événements webhook et la page d’aide Subscriptions (toutes consultées en novembre 2026). Quand la doc ne dit pas quelque chose, nous le précisons.

Le cycle d’un paiement échoué sur Lemon Squeezy

Lemon Squeezy est un marchand officiel (merchant of record) : il prélève le client, fait les nouvelles tentatives et envoie les emails de facturation. Votre rôle consiste surtout à réagir aux changements de statut dans votre appli.

Étape 1 : le renouvellement échoue et l’abonnement passe en past_due

D’après la référence de l’objet Subscription, quand un paiement de renouvellement échoue, le statut de l’abonnement devient past_due. L’abonnement passe ensuite par 4 nouvelles tentatives de paiement sur 2 semaines. Si l’une d’elles réussit, le statut redevient active.

La page Recovery and Dunning ajoute deux détails :

• Pendant les nouvelles tentatives, l’abonnement compte toujours comme actif du point de vue de l’accès : le client continue d’utiliser votre produit.
• Chaque tentative échouée déclenche un email qui demande au client de mettre à jour ses coordonnées de facturation.

Étape 2 : les tentatives sont épuisées et l’abonnement devient unpaid

Si toutes les tentatives échouent, le statut passe à unpaid. C’est là que commencent les relances de Lemon Squeezy. D’après la page Recovery and Dunning, les emails de relance sont envoyés sur une période définie, et chacun renvoie vers une page où le client peut mettre à jour ses coordonnées de paiement et réactiver son abonnement.

Étape 3 : les relances se terminent, ou l’abonnement reste unpaid

La suite dépend de vos réglages Recovery :

• Vous pouvez fixer un délai après lequel l’abonnement est automatiquement annulé. Une fois que c’est fait, le client ne peut plus le réactiver.
• Vous pouvez laisser l’abonnement en unpaid, ce qui permet au client de le réactiver à tout moment.
• Si vous désactivez les relances, le statut reste simplement unpaid, et c’est à vous de décider ce que cela implique pour l’accès.

Quand les relances sont terminées, Lemon Squeezy envoie subscription_expired, que sa page des types d’événements décrit comme se déclenchant « une fois les relances terminées pour les abonnements past_due ».

PayPal fonctionne différemment

La page Recovery indique que les abonnements PayPal suivent un rythme de tentatives différent, avec une tentative tous les 5 jours. Si une part importante de vos clients paie avec PayPal, ne supposez pas que le calendrier des cartes s’applique à eux.

Les statuts en un coup d’œil

Statut	Ce qu’il signifie	Le client doit-il avoir accès ?
active	Payé et en règle	Oui
past_due	Renouvellement échoué, tentatives en cours (4 sur environ 2 semaines)	Oui, selon Lemon Squeezy
unpaid	Tentatives épuisées, relances en cours ou désactivées	À vous de voir ; la doc du cycle de vie de Lemon Squeezy dit que l’accès ne doit prendre fin qu’à expired
cancelled	Annulé, en période de grâce jusqu’à ends_at	Oui, jusqu’à ends_at
expired	Terminé	Non

La page d’aide Subscriptions indique que les clients doivent garder l’accès dans tous les statuts sauf expired. Certaines équipes préfèrent restreindre des fonctionnalités en unpaid ; si c’est votre cas, dites-le clairement dans votre appli pour que le client sache pourquoi.

Les webhooks dont vous avez besoin

La page des types d’événements liste les événements d’abonnement. Pour les paiements échoués, ces cinq comptent :

Événement	Quand il se déclenche	Contenu
subscription_payment_failed	Un paiement de renouvellement échoue (pas le premier paiement)	Objet subscription invoice
subscription_payment_recovered	Un paiement réussit après un échec	Objet subscription invoice
subscription_payment_success	Tout paiement réussi ; toujours envoyé en même temps que subscription_payment_recovered	Objet subscription invoice
subscription_updated	Tout changement de l’abonnement, y compris les changements de statut	Objet subscription
subscription_expired	Après la fin d’un abonnement annulé, ou une fois les relances terminées	Objet subscription

Deux points à noter. D’abord, subscription_payment_failed porte un objet subscription invoice, pas l’abonnement lui-même : vous récupérerez donc généralement l’abonnement pour lire son statut. Ensuite, Lemon Squeezy indique que subscription_updated se déclenche à chaque changement après le paiement initial : pour beaucoup d’applis, il suffit de l’écouter et de lire status.

Les docs que nous avons utilisées ne décrivent pas, sur ces événements, de champ de raison du refus comparable aux codes de refus des réseaux de cartes : ne construisez pas de logique qui en dépend sans vérifier vos propres payloads.

Le lien de mise à jour du paiement

Chaque objet subscription a un attribut urls avec un lien update_payment_method : une URL pré-signée où le client peut changer de carte. La référence de l’objet Subscription indique que ces URL signées sont valables 24 heures, et le guide de gestion des abonnements dit la même chose pour les liens de récupération : récupérez à nouveau l’abonnement pour en obtenir un frais plutôt que de le stocker.

Cela a une conséquence pratique. Si vous envoyez vos propres emails, ne collez pas un lien stocké dans un email qui risque d’être ouvert trois jours plus tard. Liez vers une page de votre appli qui récupère une URL fraîche et redirige.

Configurer les réglages Recovery

Les emails de relance de Lemon Squeezy se configurent sur la page des réglages Recovery de votre boutique. La page Recovery and Dunning indique que vous pouvez activer ou désactiver les relances et modifier les emails, les objets, le contenu et le calendrier d’envoi, avec des valeurs par défaut fournies.

Une configuration raisonnable :

1. Gardez les relances activées. Elles ne coûtent rien et atteignent les clients qui n’ouvrent jamais votre appli.
2. Réécrivez le texte par défaut avec votre ton. Dites quel est le produit, ce qui se passe si la carte n’est pas mise à jour, et gardez un seul bouton clair.
3. Décidez délibérément de l’annulation automatique. Laisser les abonnements en unpaid laisse la porte ouverte à une réactivation. L’annulation automatique vous donne une date de fin nette. Choisissez, et alignez les règles d’accès de votre appli sur ce choix.
4. Testez. Le mode test de Lemon Squeezy permet de simuler des événements webhook : vous pouvez vérifier la réaction de votre appli à past_due, unpaid et expired avant qu’un vrai client n’y soit confronté.

Des conseils pratiques à appliquer dès aujourd’hui

Le comportement intégré de Lemon Squeezy est une bonne base. Les manques sont surtout de votre côté de l’intégration.

1. Montrer le problème dans votre appli

Les emails de facturation se font filtrer. Quand un abonnement est en past_due ou unpaid, affichez une bannière dans votre appli avec un bouton vers votre page « mettre à jour la carte ». C’est souvent le moment où le client est le plus enclin à agir, puisqu’il est déjà en train d’utiliser le produit.

2. Traiter les statuts explicitement

Associez chaque statut à une règle d’accès, à un seul endroit de votre code. Un bug courant consiste à traiter tout ce qui n’est pas active comme « pas d’accès », ce qui bloque les clients en past_due et cancelled qui ont payé leur période en cours.

3. Vérifier et dédoublonner les webhooks

Lemon Squeezy signe chaque requête avec un HMAC dans l’en-tête X-Signature (signature des requêtes) et retente les réponses autres que 200 jusqu’à trois fois de plus, avec un délai exponentiel (requêtes webhook). Vérifiez la signature sur le corps brut et faites en sorte que votre handler puisse s’exécuter deux fois sans dégât.

4. Envoyer un message humain

Les emails automatiques couvrent la mécanique. Un message court et simple d’une vraie personne (« Votre carte n’est pas passée, voici le lien, répondez si quelque chose ne va pas ») est souvent reçu autrement. Envoyez-le une fois, vers le moment où l’abonnement devient unpaid, pas à chaque tentative échouée.

5. Suivre la récupération

Comptez chaque mois les événements subscription_payment_failed et subscription_payment_recovered. Le rapport entre les deux est votre propre taux de récupération, mesuré sur vos données. S’il bouge après un changement de texte, vous savez que le changement a compté.

Le faire avec NoChurn

Lemon Squeezy continue de gérer le paiement, les nouvelles tentatives et ses propres emails de relance ; NoChurn ne remplace pas cela. NoChurn lit vos webhooks Lemon Squeezy, met chaque paiement échoué dans une même chronologie, et peut ajouter des emails de récupération rédigés par l’IA, que vous relisez avant leur envoi. Il donne aussi à chaque client un churn score de 0 à 100, et les litiges, que Lemon Squeezy gère en tant que marchand officiel, apparaissent en lecture seule. NoChurn est gratuit sous 300 $ de MRR, avec toutes les fonctionnalités dans chaque offre (votre propre domaine d’email dès 9 $). Voir NoChurn + Lemon Squeezy.