Les codes de refus Stripe expliqués : que faire pour chacun

Quand un renouvellement échoue sur Stripe, le paiement revient avec une courte chaîne comme insufficient_funds ou do_not_honor. Cette chaîne est l’information la plus utile que vous obtenez sur l’échec. Elle vous dit si une nouvelle tentative peut marcher, si le client doit faire quelque chose, et ce que vous avez le droit de lui dire.

Ce guide passe en revue les codes de refus qui comptent le plus pour les abonnements, regroupés selon ce qu’il faut en faire. Il s’en tient à ce que Stripe documente dans sa référence des codes de refus et son guide des refus de carte (tous deux consultés en novembre 2026), et le signale quand les pages de Stripe laissent place à l’interprétation.

Où se trouvent les codes

Un paiement par carte échoué sur Stripe peut porter plusieurs champs. Ils répondent à des questions différentes :

Champ	Ce qu’il vous dit	Où le trouver
decline_code	La raison normalisée par Stripe du refus de la banque émettrice, si elle en a donné une	Sur l’erreur, et sur last_payment_error du PaymentIntent
advice_code	Que faire ensuite : retenter, ne pas retenter, ou vérifier les données de carte	Sur l’erreur, à côté du code de refus
network_decline_code	Le code brut du réseau de cartes	Sur l’outcome du paiement
network_advice_code	Le conseil propre au réseau (pour Mastercard, ses Merchant Advice Codes)	Sur l’outcome du paiement

Stripe a ajouté les champs network advice et network decline code à l’API en décembre 2024. La doc de Stripe prévient que le sens d’un network_decline_code diffère selon les réseaux de cartes : lisez-le donc toujours avec la marque de la carte.

Pour les abonnements, vous les lirez généralement depuis le webhook invoice.payment_failed : récupérez le PaymentIntent de la facture et regardez last_payment_error.

Les advice codes d’abord

L’advice_code est le signal le plus simple, et le guide des refus de carte de Stripe documente trois valeurs :

• try_again_later : la banque émettrice a refusé, mais vous pouvez retenter. Si les tentatives répétées échouent, le client doit contacter sa banque.
• do_not_try_again : n’utilisez plus cette carte pour cette transaction. Regardez le code de refus pour la raison.
• confirm_card_data : la banque a refusé parce que certaines informations de carte étaient fausses. Le client doit vérifier ses informations.

Si un advice code est présent, il l’emporte sur toute règle générale. Un do_not_try_again sur ce qui ressemble à un refus temporaire veut dire stop.

Refus temporaires et refus définitifs

Stripe ne qualifie pas chaque code de temporaire ou de définitif, mais la distinction est utile et Stripe l’emploie dans sa documentation sur les nouvelles tentatives :

• Les refus temporaires (soft declines) sont passagers. La carte est valide ; la banque a dit non cette fois-ci. Retenter plus tard peut marcher.
• Les refus définitifs (hard declines) veulent dire que la carte ne peut pas être débitée en l’état. La page Smart Retries de Stripe liste les codes qu’elle ne retentera pas sans nouveau moyen de paiement : incorrect_number, lost_card, pickup_card, stolen_card, revocation_of_authorization, revocation_of_all_authorizations, authentication_required, highest_risk_level et transaction_not_allowed.

Pour ces codes de refus définitif, Stripe continue de programmer des tentatives sur la facture, mais un prélèvement n’a lieu qu’une fois un nouveau moyen de paiement ajouté. Si personne ne le demande au client, rien ne se passera. Nous détaillons le côté nouvelles tentatives dans comment fonctionnent les Smart Retries de Stripe.

Les codes courants, et que faire

Le tableau ci-dessous couvre les codes que vous verrez le plus sur les renouvellements d’abonnement. « Description et étape suivante selon Stripe » reformule la référence des codes de refus ; « Pour un abonnement » est notre lecture pratique.

Code	Description et étape suivante selon Stripe	Retenter ?	Pour un abonnement
insufficient_funds	Fonds insuffisants ; le client doit utiliser un autre moyen de paiement	Oui, plus tard	Retenter à un meilleur moment (après un jour de paie probable) ; envoyer un email au client avec un lien de mise à jour
generic_decline	Refusé pour une raison inconnue, ou bloqué par Radar ; le client contacte sa banque	Quelques fois	Retenter ; envoyer un email ; suggérer au client d’appeler sa banque ou d’essayer une autre carte
do_not_honor	Refus générique de la banque sans raison précise	Quelques fois	Comme generic_decline
processing_error	Erreur lors du traitement de la carte ; réessayer, puis contacter la banque	Oui	Retenter vite ; n’envoyer un email que si l’échec persiste
card_velocity_exceeded	Le client a dépassé son solde, sa limite de crédit ou sa limite de transactions ; contacter la banque	Oui, plus tard	Retenter plus tard ; mentionner un plafond de dépenses dans l’email
expired_card	La carte a expiré ; utiliser une autre carte	Non	Vérifier d’abord s’il y a une mise à jour automatique de carte ; sinon demander une nouvelle carte
incorrect_cvc	Le CVC est incorrect ; réessayer avec le bon CVC	Non	Demander au client de ressaisir sa carte sur la page de mise à jour
incorrect_number	Le numéro de carte est incorrect	Non	Demander une nouvelle carte
lost_card, stolen_card	Carte déclarée perdue ou volée ; présenter comme un refus générique	Non	Demander une nouvelle carte, sans mentionner la raison
pickup_card	La carte ne peut pas être utilisée pour ce paiement (peut-être déclarée perdue ou volée) ; contacter la banque	Non	Demander une nouvelle carte
fraudulent	Stripe soupçonne une fraude ; afficher le même message qu’un refus générique	Non	Traiter avec prudence ; ne pas révéler la raison
authentication_required	La banque exige que le client s’authentifie	Pas sans le client	Envoyer un lien pour confirmer le paiement ; voir la SCA sur les renouvellements
revocation_of_authorization, stop_payment_order	Stripe les liste avec une raison inconnue ; le client contacte sa banque	Non	Demander un nouveau moyen de paiement ; vérifier si le client voulait arrêter de payer
transaction_not_allowed	Non autorisé sur cette carte	Non	Demander une autre carte ou un autre moyen de paiement

Deux points sont faciles à rater :

1. Certaines raisons ne doivent pas être montrées au client. Pour lost_card, stolen_card et fraudulent, la référence de Stripe dit de présenter le refus comme un refus générique. Votre email de relance doit dire « votre paiement a été refusé », jamais « votre carte a été déclarée volée ».
2. « Contactez votre banque » est une vraie consigne. Pour les refus génériques, un appel à la banque lève souvent le blocage. Vous pouvez le dire dans l’email, brièvement.

Les limites de tentatives sont bien réelles

Retenter n’est pas gratuit, même pour les refus temporaires. Les réseaux de cartes limitent la fréquence à laquelle un marchand peut retenter une carte refusée, et les banques émettrices peuvent traiter des tentatives excessives comme un signal de fraude.

D’après l’article du support Stripe sur les paiements bloqués pour tentatives excessives (consulté en novembre 2026), les règles de Visa interdisent globalement plus de 15 tentatives d’un même paiement sur 30 jours. Pour les transactions Visa en tarification intégrée, Stripe bloque les tentatives après la 15ᵉ quand il juge les chances de succès faibles. Les réglages par défaut de Stripe (8 tentatives pour Smart Retries) restent bien en dessous, mais une logique de nouvelles tentatives maison hors de Stripe peut dépasser la limite si vous n’y prenez pas garde.

L’équivalent chez Mastercard est le Merchant Advice Code, que Stripe expose en network_advice_code. La documentation des processeurs, comme la référence des merchant advice codes de Braintree, décrit des codes qui veulent dire « ne pas réessayer » et un code qui indique que le titulaire a annulé le paiement récurrent. Quand vous les voyez, arrêtez de retenter cette carte.

Règles pratiques :

• Comptez chaque tentative par facture, y compris celles que déclenche votre propre code.
• Arrêtez immédiatement sur un refus définitif ou un advice do_not_try_again.
• Ne retentez pas la même carte plusieurs fois dans la journée « au cas où ».
• Espacez les tentatives sur refus temporaire, et calez-les sur les moments où l’argent a des chances d’être disponible.

Quoi dire au client, par groupe

La plupart des équipes envoient le même email pour chaque échec. Quelques variantes par groupe de refus marchent mieux et ne demandent pas beaucoup de travail en plus.

Groupe	Codes	Message de l’email
Fonds ou plafonds	insufficient_funds, card_velocity_exceeded	« Nous réessaierons le [date]. Si vous préférez utiliser une autre carte, mettez-la à jour ici. »
Flou	generic_decline, do_not_honor, processing_error	« Votre banque a refusé le paiement. C’est souvent un blocage temporaire ; un rapide appel à votre banque, ou une autre carte, règle généralement le problème. »
Carte inutilisable	expired_card, lost_card, stolen_card, pickup_card, incorrect_number	« Il nous faut une nouvelle carte pour garder votre abonnement actif. » Aucune raison donnée.
Authentification	authentication_required	« Votre banque vous demande de confirmer ce paiement. Cela prend une minute. »
Données de carte	incorrect_cvc, advice confirm_card_data	« Certaines informations de carte ne correspondaient pas. Merci de ressaisir votre carte. »

Des emails prêts à l’emploi pour chaque étape se trouvent dans nos modèles d’emails de relance.

Bien enregistrer les codes de refus

On ne peut pas améliorer ce qu’on ne mesure pas. Pour chaque renouvellement échoué, enregistrez :

• L’ID de facture, l’ID client, le montant et la devise.
• Le numéro de tentative et la date.
• decline_code, advice_code, network_decline_code, network_advice_code.
• La marque de carte, le type (crédit, débit, prépayée) et le pays.
• Le résultat : récupéré (et comment : nouvelle tentative, nouvelle carte, authentification), ou perdu.

Avec quelques mois de données, vous pouvez répondre aux questions qui comptent : quels codes se récupèrent par nouvelle tentative et lesquels seulement quand le client agit, si les cartes prépayées échouent plus souvent (voir cartes prépayées et virtuelles), et si ce sont vos emails ou vos nouvelles tentatives qui font l’essentiel du travail.

Regrouper pour les rapports

Les codes bruts sont trop détaillés pour un rapport mensuel. Regroupez-les :

Groupe de rapport	Codes
Temporaire : fonds	insufficient_funds, card_velocity_exceeded
Temporaire : flou	generic_decline, do_not_honor, processing_error, try_again_later
Définitif : carte	expired_card, lost_card, stolen_card, pickup_card, incorrect_number, incorrect_cvc
Définitif : autorisation	revocation_of_authorization, revocation_of_all_authorizations, stop_payment_order, transaction_not_allowed
Authentification	authentication_required
Risque	fraudulent, highest_risk_level

Gardez le code brut dans vos données pour pouvoir regrouper autrement plus tard. Stripe ajoute et déprécie des codes au fil du temps ; la référence de Stripe marque désormais certains anciens codes comme dépréciés au profit des advice codes.

Tester la gestion des refus

Stripe fournit des numéros de carte de test qui déclenchent des codes de refus précis. Avant de mettre en production toute logique de récupération, faites passer chaque groupe en mode test :

• Un refus temporaire programme une nouvelle tentative et envoie le premier email.
• Un refus définitif envoie un email « nouvelle carte nécessaire » et ne retente pas la même carte.
• authentication_required envoie un lien de confirmation.
• lost_card et stolen_card produisent un message générique.
• Un paiement réussi (invoice.paid) arrête tous les emails et toutes les tentatives.
• Chaque tentative est enregistrée avec ses codes.

Erreurs courantes

• Traiter tous les refus de la même façon. Retenter huit fois une carte volée ne récupère rien et peut jouer contre vous auprès du réseau.
• Donner au client la raison brute. « Do not honor » ne veut rien dire pour les clients, et certaines raisons ne doivent pas du tout être divulguées.
• Ignorer les advice codes. Ils existent justement pour vous dire s’il faut retenter.
• Ne lire que le premier échec. Le code peut changer d’une tentative à l’autre ; une carte peut passer de insufficient_funds à expired_card sur une longue fenêtre de tentatives.
• Aucune issue pour les refus définitifs. Si le seul chemin de récupération est une nouvelle tentative, les refus définitifs sont perdus d’avance.

Pour une vue complète de la récupération des paiements échoués, des nouvelles tentatives aux emails jusqu’à la mesure, voir comment récupérer les paiements échoués sur Stripe.

Comment NoChurn aide

NoChurn lit le code de refus de chaque renouvellement échoué et traite chaque groupe différemment. Les refus temporaires sont retentés à des moments choisis selon les jours de paie probables et l’heure locale du client (ou vous gardez les Smart Retries de Stripe). Les refus définitifs et les demandes d’authentification évitent les tentatives inutiles et passent directement à un email de récupération rédigé par l’IA, relu avant l’envoi, avec un lien vers une page hébergée de mise à jour de carte. Les raisons sensibles ne sont jamais montrées au client, et chaque décision est enregistrée avec son code.

Il se connecte à Stripe en un clic, et le prix ne dépend que du MRR, sans part du revenu récupéré. Voir paiements échoués et tarifs.