Les 4 raisons principales d'échec de paiement Stripe (et comment les corriger)
Analyse des 4 causes les plus fréquentes d'échec de paiement sur Stripe pour un SaaS en France, avec les solutions concrètes pour chacune.
Quand un paiement Stripe échoue, l'API renvoie un code d'erreur très précis. Mais beaucoup de SaaS se contentent de traiter tous ces échecs de la même façon : un email générique, un retry à 24h, et basta. C'est une erreur. Chaque cause d'échec appelle une réponse différente — et c'est précisément ce distinguo qui fait passer un taux de récupération de 40% à 70%.
1. Carte expirée (expired_card) — 35% des échecs
C'est la cause numéro un. La carte bancaire du client a été remplacée par sa banque et l'ancienne a expiré. Typiquement, cela arrive entre 2 et 3 ans après l'inscription.
La mauvaise réponse : retenter le paiement. Cela ne marchera jamais — la carte est morte.
La bonne réponse : envoyer immédiatement un email clair ("votre carte a expiré") avec un lien unique vers une page de mise à jour (Stripe Customer Portal ou équivalent). Les taux de conversion sur ce type de campagne dépassent 65% dans les 10 jours.
2. Fonds insuffisants (insufficient_funds) — 20% des échecs
Le client a bien une carte valide, mais son compte est à découvert au moment du prélèvement. C'est typique en fin de mois, particulièrement en France où beaucoup de salariés sont payés le 25-27 du mois.
La bonne réponse : retenter 3 à 5 jours plus tard, idéalement en début de mois suivant. Les retries sur ce type d'échec convertissent à plus de 60% sans aucune action du client. Pas besoin d'email agressif — un simple message d'information suffit.
3. Authentification 3D Secure refusée (authentication_required) — 15% des échecs
Depuis la directive DSP2 (SCA) en Europe, de nombreux paiements récurrents nécessitent une authentification forte. Si le client n'a pas autorisé le paiement (souvent parce qu'il n'a pas vu la notification de sa banque), le prélèvement est refusé.
La bonne réponse : envoyer un email qui invite le client à effectuer manuellement le paiement (via un lien checkout Stripe avec SCA intégré). Cela force l'authentification et débloque non seulement le paiement actuel, mais aussi les prélèvements futurs.
4. Carte refusée par l'émetteur (card_declined) — 15% des échecs
C'est le cas fourre-tout : la banque refuse sans donner de raison précise. Cela peut être une détection de fraude, un plafond atteint, une carte bloquée, ou simplement une erreur temporaire du réseau bancaire.
La bonne réponse : retenter une fois à J+2, puis si l'échec persiste, contacter le client par email pour l'inviter à vérifier avec sa banque ou à utiliser une autre carte.
Les 15% restants
Le reste se répartit entre : carte perdue/volée (lost_card, stolen_card), erreurs de traitement (processing_error), codes postaux invalides, et quelques cas rares. Pour ces derniers, la stratégie est la même que pour card_declined : retry + email.
Le principe fondamental
Un bon système de dunning ne traite PAS tous les échecs de paiement de la même façon. Il utilise le code d'erreur Stripe pour router chaque cas vers la bonne séquence : retry pur, email "mettez à jour votre carte", ou email "authentifiez ce paiement". C'est ce niveau de personnalisation qui fait la différence entre un dunning médiocre et un dunning qui récupère 70% de votre churn involontaire.
RecoverFlow gère tout cela automatiquement
Notre moteur de règles inspecte automatiquement le decline_code renvoyé par Stripe et applique la bonne stratégie pour chaque cas. Vous n'avez rien à configurer : les meilleures pratiques sont déjà implémentées, et vous pouvez les personnaliser si besoin.