Pourquoi les paiements d'abonnement échouent sur Stripe, et ce que demande chaque code de refus
Un renouvellement échoué veut rarement dire qu'un client veut partir. La plupart du temps, une carte a expiré, le solde était bas le mauvais jour, ou la banque a demandé une confirmation que personne n'a vue. Le code de refus enregistré par Stripe dit lequel de ces cas s'est produit, et chacun demande une réponse différente.
Ce qui se passe quand un renouvellement échoue
Quand un abonnement se renouvelle, Stripe crée une facture et tente de débiter le moyen de paiement par défaut du client. Si la banque refuse, la facture reste ouverte, l'abonnement passe en général en past_due, et Stripe enregistre la raison du refus : un code comme insufficient_funds ou expired_card, parfois accompagné d'un motif plus précis de la banque.
La suite dépend de tes réglages de facturation. Stripe peut retenter le paiement selon un calendrier, envoyer un email au client, puis, après la dernière tentative, annuler l'abonnement, le marquer impayé ou le laisser en retard. Aucune de ces étapes ne regarde pourquoi le paiement a échoué. Une carte expirée depuis trois mois reçoit le même traitement qu'un solde à qui il manquait quelques francs le 28 du mois.
Refus temporaires et refus définitifs
La distinction la plus utile sépare les refus qui peuvent réussir lors d'une tentative suivante de ceux qui ne réussiront pas tant que le client n'a rien fait. On parle souvent de refus temporaires (soft decline) et de refus définitifs (hard decline).
- Refus temporaires : fonds insuffisants, problème passager à la banque (
processing_error,try_again_later), plafond de dépenses ou de fréquence atteint (card_velocity_exceeded). Une tentative plus tard peut passer sans aucune action du client. - Refus définitifs : carte expirée, perdue ou volée, compte fermé, numéro erroné. Aucune nouvelle tentative ne réussira ; le client doit fournir un autre moyen de paiement.
- Authentification requise : une catégorie à part. La carte fonctionne, mais la banque veut que le titulaire confirme le paiement. Retenter ne sert à rien ; le client doit faire une démarche.
Retenter un refus définitif est inutile, et les réseaux de cartes surveillent les tentatives répétées sur une carte qui ne peut pas être débitée. Retenter un refus temporaire au bon moment, en revanche, fonctionne souvent sans que le client remarque qu'il y a eu un problème.
Les codes de refus les plus fréquents
| Code | Ce qu'il veut dire en général | Ce qui aide |
|---|---|---|
insufficient_funds | Solde ou crédit insuffisant à ce moment-là | Une nouvelle tentative quelques jours plus tard, un email court et neutre |
expired_card | La carte enregistrée a dépassé sa date d'expiration | Une nouvelle carte du client ; la mise à jour automatique des cartes règle parfois le cas avant |
generic_decline, do_not_honor | La banque a refusé sans donner de raison | Une nouvelle tentative, puis un email proposant une autre carte ou un appel à la banque |
authentication_required | La banque veut une confirmation 3-D Secure | Un lien où le client confirme le paiement |
incorrect_cvc, incorrect_number | Les données de la carte sont fausses | Demander au client de saisir à nouveau sa carte |
lost_card, stolen_card | La banque a bloqué la carte | Un nouveau moyen de paiement ; ne jamais citer la raison au client |
card_velocity_exceeded | Trop de tentatives ou plafond atteint | Attendre avant la tentative suivante |
La liste n'est pas exhaustive et les banques n'utilisent pas toujours les codes de la même façon. Prends le code comme un indice solide, pas comme une certitude, et regarde ce qui est réellement payé ensuite.
Carte expirée : l'échec le plus prévisible
Une date d'expiration est connue des années à l'avance, ce qui en fait l'échec le plus facile à éviter. Les réseaux de cartes proposent des services de mise à jour qui transmettent les nouvelles données de carte aux marchands, et Stripe applique ces mises à jour automatiquement quand la banque émettrice y participe. Sinon, le renouvellement échoue à la première échéance qui suit l'expiration.
Deux choses aident : un rappel envoyé avant l'expiration de la carte, avec un lien pour la mettre à jour, et une relance après l'échec qui demande clairement une nouvelle carte au lieu de dire vaguement qu'il y a eu un souci. On détaille les deux dans réduire les refus de carte avant qu'ils arrivent.
Fonds insuffisants : une question de moment
C'est en général l'échec le plus récupérable. Le client a une carte valide et compte souvent bien payer ; l'argent n'était simplement pas là ce jour-là. Beaucoup de gens sont payés une fois par mois : une tentative quelques jours après le début ou la fin du mois a plus de chances qu'une tentative à une heure quelconque.
L'email qui l'accompagne doit rester court et neutre. Personne n'aime s'entendre dire que son compte était vide. Une phrase comme « ta banque a refusé le paiement » suffit, suivie du montant et d'un seul lien pour payer ou changer de carte.
3-D Secure : quand la banque veut une confirmation
Avec les règles d'authentification forte en Europe, le premier paiement d'un abonnement est en général confirmé par le titulaire de la carte. Les renouvellements suivants sont le plus souvent traités comme des paiements initiés par le marchand et passent sans nouvelle confirmation, mais la banque peut quand même en demander une, par exemple après un changement de carte ou pour un montant élevé.
Dans ce cas, Stripe marque le paiement comme nécessitant une action et envoie l'événement invoice.payment_action_required. Les nouvelles tentatives seules n'y changent rien : le client doit ouvrir un lien, confirmer dans son application bancaire et revenir. Plus ce lien lui arrive vite, mieux c'est.
Refus génériques : les plus difficiles à lire
Des codes comme do_not_honor ou generic_decline signifient que la banque a dit non sans dire pourquoi. Ce peut être une règle antifraude, une carte bloquée pour les paiements en ligne, un plafond ou un incident passager. Une seule nouvelle tentative quelques jours plus tard réussit parfois. Sinon, le client doit essayer une autre carte ou contacter sa banque, et l'email doit dire exactement cela, sans accuser personne.
Transformer les codes de refus en méthode
- Enregistrer le code de refus de chaque facture échouée, pas seulement le fait qu'elle a échoué.
- Regrouper les codes en trois familles : à retenter, nouvelle carte nécessaire, authentification nécessaire.
- Pour chaque famille, décider du moment des nouvelles tentatives et du message reçu par le client.
- Mesurer ce qui est payé, et le comparer à ce qui l'aurait été de toute façon. Un groupe témoin est la seule façon honnête de le faire.
C'est la logique que suit Reclaiva. Il lit chaque facture échouée grâce à un accès en lecture seule à Stripe, envoie la relance adaptée au refus au nom de ton entreprise, et compare le résultat à un groupe de factures qui ne reçoivent aucune relance. Ce que tu vois, c'est le revenu récupéré en plus de ce que Stripe récupère seul.