Si vous utilisez Stripe pour encaisser vos abonnements, vous avez probablement déjà vu apparaître dans votre dashboard ces quelques lignes rouges : "Payment failed". La première fois, ça surprend. La dixième fois, ça inquiète. Et quand on commence à calculer ce que ça représente sur l'année, ça fait vraiment mal.
Les paiements échoués sur Stripe sont l'un des problèmes les plus sous-estimés dans la gestion d'un SaaS. On les considère souvent comme des incidents isolés, alors qu'ils représentent en réalité une fuite structurelle et prévisible de revenus. Dans cet article, nous allons disséquer toutes les causes possibles d'un échec de paiement Stripe, comprendre ce qui se passe réellement en coulisses, et voir comment y remédier de façon systématique.
Ce qui se passe quand un paiement échoue sur Stripe
Quand vous déclenchez un paiement sur Stripe — que ce soit via une subscription, une invoice ou un payment intent — Stripe envoie une demande d'autorisation à la banque émettrice de la carte de votre client. Cette demande transite par les réseaux de paiement (Visa, Mastercard, CB) avant d'atteindre la banque.
La banque analyse alors la demande en quelques millisecondes et retourne une réponse : approuvée ou refusée. Si elle est refusée, elle renvoie un code de refus que Stripe traduit en code d'erreur lisible dans votre dashboard.
C'est là que beaucoup d'entrepreneurs s'arrêtent : ils voient "payment failed" et passent à autre chose. Mais ce code d'erreur contient une information précieuse — il vous dit exactement pourquoi le paiement a échoué, et donc quelle est la meilleure façon de le récupérer.
Les causes principales des paiements Stripe échoués
1. Fonds insuffisants (insufficient_funds)
C'est de loin la cause la plus fréquente des paiements échoués, notamment pour les abonnements B2C. Le compte bancaire du client ne contient pas suffisamment de fonds pour couvrir le montant de la transaction au moment du prélèvement.
Ce n'est pas un refus définitif. Dans la grande majorité des cas, le client aura les fonds disponibles quelques jours plus tard — notamment après réception de son salaire en fin ou début de mois. C'est pourquoi réessayer le paiement au bon moment fait toute la différence.
Stratégie recommandée : ne pas réessayer immédiatement. Attendre la fin du mois (J+20 à J+28) maximise statistiquement les chances de succès. Envoyer un email de notification au client lui permet également de provisionner son compte en amont.
2. Carte expirée (expired_card)
Les cartes bancaires ont une date de validité de 2 à 3 ans en général. Vos clients changent de carte, reçoivent une nouvelle carte suite à un renouvellement, et oublient tout simplement de mettre à jour leurs informations de paiement dans votre SaaS.
Ce code d'erreur est particulièrement problématique car il est 100% prévisible. Vous savez des semaines à l'avance qu'une carte va expirer — si vous avez stocké la date d'expiration via Stripe, vous pouvez envoyer un email de rappel 30 jours avant l'expiration.
Stratégie recommandée : email immédiat avec lien vers le Customer Portal Stripe pour mise à jour de la carte. Mettre en place des rappels préventifs 30 et 7 jours avant l'expiration.
3. Refus générique de la carte (card_declined)
Ce code est le plus frustrant car il est peu informatif. La banque a refusé la transaction mais n'en précise pas la raison. Cela peut couvrir de nombreuses situations : limite de crédit atteinte, restriction sur les achats en ligne, carte temporairement bloquée suite à une activité suspecte détectée par la banque.
Dans ce cas, la bonne approche est de tenter un réessai après 24-48h, le temps que la situation se normalise. Un email demandant au client de contacter sa banque peut également débloquer la situation rapidement.
Stratégie recommandée : réessai J+1, puis J+3. Email de notification avec instruction de contacter la banque si le problème persiste.
4. Transaction bloquée pour fraude (fraudulent)
La banque ou le système anti-fraude de Stripe a détecté une activité suspecte et bloqué la transaction. C'est l'un des codes d'erreur les plus sérieux — réessayer un paiement marqué comme frauduleux peut aggraver la situation et potentiellement déclencher un chargeback.
Stratégie recommandée : ne jamais réessayer automatiquement. Contacter directement le client pour comprendre la situation et lui demander de contacter sa banque. Ce cas représente heureusement une infime minorité des paiements échoués.
5. Erreur de traitement (processing_error)
Une erreur technique s'est produite lors du traitement de la transaction. Cela peut venir de Stripe, du réseau de paiement ou de la banque. Ces erreurs sont typiquement temporaires — un incident technique qui se résout en quelques heures.
Stratégie recommandée : réessai dans les 2 à 6 heures. Pas d'email au client pour ce type d'erreur, sauf si le réessai échoue également.
6. Do not honor (do_not_honor)
C'est un code de refus générique envoyé par la banque sans explication détaillée. La banque refuse la transaction mais ne précise pas pourquoi. Cela peut être lié à des restrictions internes, des paramètres de sécurité ou des limites de transaction.
Stratégie recommandée : email de mise à jour avec lien Customer Portal, réessai J+3. Si le problème persiste, demander au client de contacter sa banque.
7. Carte perdue ou volée (lost_card, stolen_card)
La carte a été déclarée perdue ou volée auprès de la banque. Dans ce cas, le client a une nouvelle carte avec un nouveau numéro. Il faut impérativement qu'il mette à jour ses informations de paiement.
Stratégie recommandée : email immédiat avec lien de mise à jour. Ne jamais réessayer avec les mêmes informations de carte.
8. Limite de carte dépassée (card_velocity_exceeded)
Le client a effectué trop de transactions en peu de temps et a atteint la limite fixée par sa banque. Ce blocage est généralement temporaire — il se lève après quelques heures ou jours.
Stratégie recommandée : réessai J+2, email de notification sans alarmer le client.
Les erreurs liées à la configuration Stripe
Certains paiements échouent non pas à cause du client, mais à cause d'une mauvaise configuration côté Stripe ou côté développeur.
Devise incorrecte
Votre Stripe est configuré pour accepter des paiements en euros mais vous tentez une charge en dollars, ou vice versa. Ce type d'erreur est rare mais peut apparaître lors de migrations ou de changements de configuration.
Montant invalide
Stripe exige que les montants soient exprimés en centimes (100 = 1€). Une erreur dans votre code peut entraîner des tentatives de charge avec des montants incorrects.
Clé API incorrecte
Une confusion entre les clés de test et les clés de production peut entraîner des échecs systématiques. C'est une erreur classique lors du passage en production d'une nouvelle fonctionnalité.
Webhook mal configuré
Si votre webhook n'écoute pas les bons événements ou pointe vers la mauvaise URL, vous ne serez pas notifié des paiements échoués et ne pourrez pas déclencher vos processus de récupération.
Tableau récapitulatif des codes d'erreur Stripe
| Code d'erreur | Fréquence | Réessai ? | Action prioritaire |
|---|---|---|---|
| insufficient_funds | Très fréquent | Oui — fin de mois | Email de notification |
| expired_card | Fréquent | Non — nouvelle carte | Email mise à jour immédiat |
| card_declined | Fréquent | Oui — J+1, J+3 | Email + contact banque |
| fraudulent | Rare | Jamais | Contact direct client |
| processing_error | Occasionnel | Oui — dans les 6h | Réessai silencieux |
| do_not_honor | Fréquent | Oui — J+3 | Email mise à jour |
| lost_card / stolen_card | Rare | Jamais | Email mise à jour urgente |
| card_velocity_exceeded | Occasionnel | Oui — J+2 | Attendre et réessayer |
L'impact réel des paiements échoués sur votre MRR
Beaucoup de fondateurs SaaS regardent leurs paiements échoués comme des incidents isolés. La réalité est que c'est une fuite structurelle qui s'accumule mois après mois.
Prenons un exemple concret. Vous avez 150 clients à 79€/mois, soit un MRR de 11 850€. Si 8% de vos paiements échouent chaque mois sans système de récupération :
- 12 paiements échoués × 79€ = 948€ potentiellement perdus chaque mois
- Sur 12 mois : 11 376€ de revenus non récupérés
- Sans compter l'effet de churn involontaire : certains clients qui ne paient pas finissent par partir
Avec un système de dunning efficace qui récupère 75% de ces paiements :
- 711€ récupérés par mois
- 8 532€ récupérés sur l'année
- Pour un outil à 79€/mois, le ROI est évident dès le premier mois
Pourquoi le système natif de Stripe ne suffit pas
Stripe dispose d'un système de relance automatique appelé Smart Retries. Il tente de recharger la carte selon un calendrier prédéfini, généralement 3 à 4 fois sur 4 semaines. C'est mieux que rien, mais c'est insuffisant pour plusieurs raisons.
Les emails partent au nom de Stripe, pas de vous
Vos clients reçoivent un email de "Stripe" leur disant que leur paiement a échoué. Pour un client qui vous fait confiance depuis des mois, recevoir cet email d'un tiers peut être déstabilisant. Le taux d'ouverture de ces emails est beaucoup plus faible qu'un email envoyé depuis votre propre domaine.
Pas d'adaptation au type d'erreur
Stripe réessaie selon un calendrier fixe, sans tenir compte du code d'erreur. Un insufficient_funds le 3 du mois sera réessayé le 6, le 12 et le 18 — soit exactement les jours où la probabilité de succès est la plus basse. Un système intelligent attendrait la fin du mois.
Pas de visibilité sur le MRR récupéré
Stripe ne vous dit pas combien vous avez récupéré grâce aux relances. Il n'y a pas de dashboard dédié pour suivre votre taux de récupération, votre MRR en danger, ou l'efficacité de vos relances.
Aucune personnalisation possible
Vous ne pouvez pas modifier le contenu des emails de Stripe, ajouter votre logo, changer le ton, ni adapter le message selon le profil du client ou la raison de l'échec.
Comment mettre en place un système de dunning efficace
Un bon système de dunning (gestion des relances de paiement) repose sur trois piliers : le bon timing, le bon message, et la bonne action.
Le timing : adapter le retry au code d'erreur
Comme nous l'avons vu, chaque code d'erreur a son timing optimal. Un système de dunning efficace ne réessaie pas selon un calendrier fixe — il s'adapte à la cause de l'échec.
Pour les insufficient_funds, le meilleur moment de réessai est entre le 25 et le 28 du mois. Pour les processing_error, réessayer dans les 6 heures suffit. Pour les cartes expirées, ne jamais réessayer sans que le client ait mis à jour ses informations.
Le message : personnalisé, depuis votre domaine
Vos emails de relance doivent paraître venir de vous, pas de Stripe. Ils doivent être envoyés depuis votre adresse email professionnelle, avec votre logo, et dans le ton qui correspond à votre marque.
Le contenu doit être adapté à la situation : un email pour une carte expirée n'est pas le même qu'un email pour des fonds insuffisants. Le premier demande une mise à jour des informations, le second peut être plus empathique et simplement informer le client de la situation.
La séquence : 3 emails bien espacés
- J+0 (immédiat) — Notification bienveillante. "Il y a eu un problème avec votre paiement. Voici comment le résoudre." Lien direct vers le Customer Portal.
- J+3 — Rappel avec légère urgence. "Votre accès pourrait être suspendu si le problème n'est pas résolu." Même lien.
- J+7 — Dernier avis. "C'est notre dernière notification avant suspension." CTA fort.
L'action : le lien Customer Portal
Chaque email doit contenir un lien unique vers le Customer Portal Stripe de votre client. Ce lien lui permet de mettre à jour sa carte bancaire en 2 minutes, sans avoir à se connecter à votre application. C'est la façon la plus simple de convertir un paiement échoué en paiement réussi.
Les outils pour automatiser la récupération des paiements Stripe
Gérer tout cela manuellement est impossible dès que vous avez plus d'une vingtaine de clients. Voici les principales catégories d'outils :
Les solutions de dunning dédiées
Salvr est une plateforme française spécialisée dans la récupération des paiements Stripe échoués. Elle se connecte à votre compte Stripe en 2 minutes via OAuth, détecte automatiquement les paiements échoués, et déclenche les relances depuis votre propre domaine email. Le dashboard affiche en temps réel le MRR récupéré, les paiements en cours de relance et les statistiques de récupération. Salvr gère également le churn volontaire — quand un client annule son abonnement, une séquence email automatique est déclenchée pour tenter de le retenir.
Les solutions anglophones comme Churnkey ou Baremetrics Recover existent mais sont conçues pour le marché américain et ne proposent pas d'interface française.
Les outils de gestion d'abonnements
Des plateformes comme Chargebee ou Recurly incluent des fonctionnalités de dunning dans leur offre, mais elles sont généralement coûteuses et nécessitent de migrer toute votre facturation. Elles sont adaptées aux entreprises avec des besoins de facturation complexes, pas aux SaaS qui utilisent déjà Stripe nativement.
Le développement interne
Certaines équipes choisissent de développer leur propre système de dunning. C'est techniquement faisable — Stripe fournit tous les webhooks nécessaires — mais c'est chronophage à maintenir et à faire évoluer. Pour la plupart des SaaS, le ROI d'un outil dédié est bien meilleur que le coût de développement interne.
Les bonnes pratiques pour prévenir les échecs de paiement
La prévention vaut toujours mieux que la récupération. Voici les actions concrètes qui réduisent structurellement votre taux d'échecs :
Activer le Card Updater Visa/Mastercard
Visa et Mastercard proposent un service qui met automatiquement à jour les informations de carte dans votre Stripe quand un client reçoit une nouvelle carte. Ce service est disponible via Stripe et peut réduire significativement les échecs liés aux cartes expirées ou remplacées.
Envoyer des rappels préventifs d'expiration
30 jours avant l'expiration d'une carte, envoyez un email automatique à votre client pour l'inviter à mettre à jour ses informations. C'est simple à implémenter et évite une grande partie des expired_card.
Informer avant le prélèvement
Un email 3 à 5 jours avant la date de prélèvement réduit les mauvaises surprises. Vos clients peuvent ainsi vérifier que les fonds sont disponibles ou mettre à jour leurs informations en amont.
Optimiser la date de prélèvement
Si vos clients sont principalement des salariés, évitez les prélèvements en début de mois (1er-5). Leurs comptes sont souvent au plus bas à cette période. Préférez les prélèvements entre le 8 et le 15, ou en fin de mois après les virements de salaire.
Faciliter la mise à jour des informations de paiement
Plus votre interface permet facilement de mettre à jour une carte, moins vous aurez de paiements échoués récurrents. Le Customer Portal Stripe est la solution la plus simple — un lien unique, une mise à jour en 2 minutes.
Questions fréquentes
Un paiement échoué entraîne-t-il des frais Stripe ?
Non, Stripe ne facture pas les paiements échoués. Vous ne payez les frais Stripe que sur les transactions réussies. En revanche, les chargebacks (contestations de paiement) sont facturés — c'est pourquoi il vaut mieux ne jamais réessayer un paiement marqué comme fraudulent.
Combien de fois peut-on réessayer un paiement échoué ?
Il n'y a pas de limite technique fixée par Stripe, mais il y a des limites de bon sens. Réessayer trop souvent peut être perçu comme du harcèlement par votre client et potentiellement déclencher des signalements. Une séquence de 3 à 4 réessais sur 7 à 14 jours est généralement la bonne pratique.
Comment accéder aux codes d'erreur Stripe ?
Dans votre dashboard Stripe, allez dans Paiements → trouvez le paiement échoué → cliquez dessus. Vous verrez le code d'erreur dans les détails de la transaction. Via l'API, le code est disponible dans l'objet PaymentIntent sous last_payment_error.code.
Un paiement échoué affecte-t-il le score de crédit de mon client ?
Non. Un paiement échoué sur Stripe n'a aucun impact sur le score de crédit de votre client. Seuls les incidents déclarés auprès des organismes de crédit peuvent affecter un score, ce que Stripe ne fait pas.
Quelle est la différence entre un paiement échoué et un chargeback ?
Un paiement échoué se produit quand la banque refuse la transaction avant qu'elle ne soit complétée. Un chargeback se produit après qu'un paiement a été accepté — le client conteste la transaction auprès de sa banque. Les chargebacks sont beaucoup plus problématiques car ils entraînent des frais et peuvent affecter votre score Stripe.
Salvr fonctionne-t-il pour les paiements one-shot ou uniquement les abonnements ?
Salvr est principalement optimisé pour les abonnements récurrents Stripe, qui représentent la grande majorité des cas de paiements échoués pour les SaaS. Pour les paiements one-shot, le mécanisme de relance est moins pertinent car il n'y a pas d'historique de relation client à préserver.