Guide des codes de refus de paiement d'abonnement pour Stripe
Référence des codes de refus d'abonnement Stripe, refus souples versus refus fermes, ce que signifie chaque code, et la stratégie de nouvelle tentative ou de dunning qui récupère chacun d'eux.
Par l’équipe FlyCode. Dernière révision en septembre 2026.
Points clés à retenir
Les refus souples représentent 60 à 70 % des échecs de paiement d’abonnement et peuvent généralement être récupérés par des nouvelles tentatives silencieuses, tandis que les refus fermes (30 à 40 %) nécessitent que le client mette à jour son moyen de paiement.
insufficient_funds(code réseau 51) est le refus le plus fréquent, représentant 50 à 70 % des échecs, et il est récupéré dans 70 à 85 % des cas lorsqu’on retente autour des jours de paie plutôt que le même jour.« Do Not Honor » (code 05) est un code fourre-tout qui représente 10 à 20 % des échecs et ne révèle presque rien à lui seul, donc l’élément qui le rend récupérable consiste à classer sa cause sous-jacente à partir des schémas de transaction.
Activez Card Account Updater et Network Tokens avant d’envoyer tout e-mail de relance pour une carte remplacée : CAU évite 60 à 80 % des échecs liés aux informations de paiement sans action du client.
Codes de refus de paiement d’abonnement : ce qu’ils signifient et comment récupérer chacun d’eux
Comment fonctionnent les codes de refus : l’anatomie d’un paiement échoué
Lorsqu’un paiement d’un client est tenté, la requête suit une chaîne : votre processeur de paiement (par ex., Stripe) → le réseau de cartes (Visa, Mastercard) → la banque émettrice. La banque émettrice prend la décision d’approbation ou de refus et renvoie un code de réponse qui remonte la chaîne.
Ce que vous voyez dans votre tableau de bord Stripe est l’interprétation par Stripe de la réponse de la banque, souvent plus descriptive que le code réseau brut, mais toujours imparfaite.
Le problème des codes à trois niveaux
Banque émettrice
Code de réponse brut (DE 39)
05
Vous ne voyez pas cela directement
Réseau de cartes
Code réseau standardisé
05 : Do Not Honor
Disponible via l’API Stripe
Processeur de paiement (Stripe)
Code de refus spécifique à Stripe
generic_decline
Ce qui apparaît dans votre tableau de bord
Cette superposition crée un problème de traduction. Le code brut de la banque est interprété par le réseau, puis réinterprété par Stripe. La nuance se perd à chaque étape. Un seul code Stripe comme generic_decline peut représenter une douzaine de décisions bancaires sous-jacentes différentes.
Refus souples vs refus fermes : la distinction critique
C’est le concept le plus important dans la récupération des paiements. Chaque refus entre dans l’une de deux catégories, et votre réponse à chacune doit être complètement différente.
Comparaison entre refus souples et refus fermes
Nature
Temporaire : peut se résoudre d’elle-même
Permanent : ne se résoudra pas sans action
% de tous les échecs d’abonnement
60–70 %
30–40 %
Peut être récupéré avec des nouvelles tentatives ?
Oui : souvent sans que le client s’en aperçoive
Non : nécessite que le client mette à jour le paiement
Exemples
Fonds insuffisants, erreur de traitement, émetteur indisponible
Identifiants de carte obsolètes, numéro invalide, carte volée, compte fermé
Réponse optimale
Nouvelle tentative silencieuse avec un timing optimisé
E-mail de relance avec lien de mise à jour de la carte
Potentiel de récupération
Élevé (70–90 % avec un bon timing)
Moyen (40–60 % avec une bonne relance)
Risque de retenter
Faible (dans les limites du réseau)
Gaspille des tentatives et risque des pénalités réseau
La règle d’or : épuisez les nouvelles tentatives intelligentes sur les refus souples avant de contacter le client. Envoyez immédiatement des communications de relance pour les refus fermes.
Référence complète des codes de refus : chaque code, chaque stratégie de récupération
Refus souples : fort potentiel de récupération (retenter d’abord)
51
insufficient_funds
Le client n’a pas assez d’argent
50–70 %
Retentez autour des jours de paie (1er, 15 du mois), le matin dans le fuseau horaire du client. Ne retentez pas le même jour.
70–85 % avec un timing optimisé
05
generic_decline / do_not_honor
Refus de la banque : aucune raison précise donnée
10–20 %
Nouvelles tentatives optimisées par ML à différents moments. Peut se résoudre d’elle-même. C’est le code « boîte noire ».
40–60 % selon la cause sous-jacente
91
issuer_not_available
Systèmes bancaires temporairement hors service
3–5 %
Retentez dans 4 à 24 heures. Réussit presque toujours à la tentative suivante.
90%+
06
processing_error
Échec de traitement générique
3–5 %
Retentez dans 24 à 48 heures avec une autre fenêtre horaire.
80–90 %
65
card_velocity_exceeded
Trop de transactions sur une courte période
1–3 %
Attendez 24 à 48 heures, puis retentez. La limite quotidienne de la carte a été atteinte.
70–80 %
61
withdrawal_amount_exceeds_limit
La transaction dépasse la limite de transaction de la carte
1–2 %
Retentez après 24 heures. Si cela se répète, envisagez de fractionner en montants plus petits.
60–75 %
N/D
try_again_later
Problème temporaire de l’émetteur
2–4 %
Retentez dans 4 à 12 heures.
85–95 %
Refus fermes : action du client requise (relance immédiate)
54
expired_card
La carte n’est plus valide ; l’émetteur l’a remplacée
10–15 %
Vérifiez d’abord si Card Account Updater / Network Tokens peut la remplacer automatiquement. Sinon, envoyez un e-mail de relance avec un lien de mise à jour de carte en un clic.
60–80 % (avec CAU), 40–55 % (e-mail uniquement)
14
invalid_number
Le numéro de carte n’existe pas ou est incorrect
2–3 %
E-mail de relance demandant au client de ressaisir les informations de carte.
35–50 %
43
stolen_card
Carte signalée comme volée
1–2 %
NE retentez PAS. Envoyez une notification douce demandant un autre moyen de paiement.
30–40 %
41
lost_card
Carte signalée comme perdue
1–2 %
Similaire à une carte volée : les Network Tokens peuvent se mettre à jour automatiquement. Sinon, e-mail de relance.
40–55 % (avec tokens), 30–40 % (sans)
04
pickup_card
La banque souhaite saisir la carte
<1%
Ne retentez pas. Contactez le client pour obtenir un nouveau moyen de paiement.
20–30 %
N/D
card_declined (avec do_not_try_again conseil)
Refus terminal : la banque dit d’arrêter
2–3 %
Ne retentez pas. Relance immédiate avec formulaire de mise à jour de carte.
30–45 %
Refus liés à l’authentification : nécessitent l’interaction du client
N/D
authentication_required
Challenge 3D Secure / SCA requis
5–10 %
Envoyez un e-mail avec un lien de paiement qui déclenche le flux d’authentification. Notification in-app pour les utilisateurs actifs.
50–65 %
N/D
3ds_required
Obligation SCA européenne
Dépend de la région
Redirigez le client pour terminer la vérification 3DS. Ne peut pas être résolu par de simples nouvelles tentatives silencieuses.
55–70 % avec une bonne UX
Refus liés à la fraude : à traiter avec précaution
N/D
fraudulent
Stripe Radar ou la banque a signalé une fraude
3–5 %
Si Stripe a bloqué : examinez dans le tableau de bord, ajoutez à la liste autorisée si c’est légitime. Si la banque a signalé : le client doit appeler sa banque.
25–40 %
59
suspected_fraud
La banque soupçonne une fraude
2–3 %
Ne retentez pas de manière agressive. L’heure et la géographie comptent : un débit à 3 h du matin depuis un lieu inhabituel est plus souvent signalé. Retentez pendant les heures ouvrables.
30–50 % avec optimisation du timing
Le problème « Do Not Honor » : résoudre la boîte noire
Code 05 / do_not_honor / generic_decline mérite une attention particulière car c’est à la fois le code de refus le plus courant et le moins informatif dans la facturation d’abonnement.
Pourquoi « Do Not Honor » est-il si courant
Lorsqu’une banque refuse une transaction mais ne veut pas en révéler la raison précise (confidentialité, raisons concurrentielles ou simplement classification paresseuse), elle renvoie le code 05. C’est un code fourre-tout qui peut en réalité signifier :
Fonds insuffisants (la banque ne le dit simplement pas)
Dépassement de la limite de vélocité
Blocage de sécurité temporaire
Dépassement du seuil de scoring de risque
Restrictions de carte (par ex., transactions internationales bloquées)
Compte en cours d’examen
Stratégies de récupération pour « Do Not Honor » selon le schéma
Premier échec, le client est actif
Blocage temporaire ou fonds insuffisants
Retentez dans 24 à 48 heures, à un autre moment de la journée
Échecs répétés le même jour chaque mois
Fonds insuffisants, lié au timing
Décalez la nouvelle tentative après la période de paie
L’échec se produit à une heure inhabituelle (3 h du matin, heure locale)
Scoring de risque de fraude
Retentez entre 9 h et 12 h, heure locale
Nouvelle carte ajoutée récemment
Restriction de l’émetteur sur les nouvelles cartes
Attendez 5 à 7 jours, puis retentez
Carte internationale, commerçant domestique
Blocage de risque transfrontalier
Si possible, routez via un acquéreur local
Échec après une période de prélèvements réussis
Blocage temporaire de la banque ou revue de sécurité
Retentez dans 48 à 72 heures
C’est ici que les modèles ML excellent. Un humain qui voit « Do Not Honor » voit une impasse. Un modèle qui a analysé des millions de ces refus selon les types de cartes, les émetteurs, les zones géographiques et les schémas temporels peut prédire la cause sous-jacente et appliquer la bonne stratégie de récupération.
Les classifieurs internes de FlyCode désagrègent les codes de refus génériques à l’aide de centaines de points de données par transaction, transformant une boîte noire en plan de récupération exploitable.
Card Account Updater et Network Tokens : les héros silencieux
Avant d’envoyer le moindre e-mail de relance pour une carte remplacée ou réémise, assurez-vous d’avoir activé les outils qui peuvent la corriger automatiquement.
Mécanismes automatiques de mise à jour de carte
Card Account Updater (CAU)
Remplace automatiquement les informations de carte obsolètes par de nouvelles provenant du réseau
Visa VAU, Mastercard ABU : disponible via Stripe
Prévient 60 à 80 % des échecs liés aux informations d’identification
Tokenisation réseau
Crée un jeton persistant qui se met à jour automatiquement lorsque la carte physique change
Visa, Mastercard : pris en charge par Stripe
Réduit les échecs des cartes enregistrées de 2 à 5 % dans tous les cas
Débit de la carte de secours
Débite automatiquement une autre carte enregistrée lorsque la principale échoue
Pas natif dans Stripe : disponible via FlyCode
Récupère 10 à 15 % des échecs qui nécessiteraient autrement une action du client
Vérification d’implémentation : Network Tokenization et Card Account Updater devraient être actifs par défaut sur la plupart des comptes Stripe. Vérifiez en regardant si vous voyez card_updated des événements dans vos journaux de webhook. Si vous ne les voyez pas, contactez l’assistance Stripe.
Optimisation du timing de récupération : quand retenter chaque code
Le timing ne consiste pas seulement à « attendre et réessayer ». Les différents types de refus ont des fenêtres de nouvelle tentative optimales différentes.
Timing optimal des nouvelles tentatives par type de refus
Fonds insuffisants
48 à 72 heures (attendre la paie)
5 à 7 jours (prochain cycle de paie)
Jour 14–15 (paie de milieu de mois)
E-mail de relance avec mise à jour de la carte
Erreur de traitement
4 à 12 heures
24 heures
48 heures
À investiguer : peut indiquer un problème d’intégration
Do Not Honor
24 à 48 heures, à un autre moment de la journée
4 à 5 jours, le matin
7 à 10 jours
Si l’échec persiste, il s’agit probablement d’un refus ferme : passez à la relance
Émetteur indisponible
4 à 6 heures
12 à 24 heures
48 heures
Il est rare d’avoir besoin de 3 nouvelles tentatives ; cela devrait réussir rapidement
Identifiants de carte obsolètes
Ne retentez pas : attendez la mise à jour CAU
Après 48 heures (CAU a peut-être été mis à jour)
5 jours
E-mail de relance avec lien de mise à jour de la carte
Authentification requise
Ne retentez pas : envoyez un lien d’authentification
3 jours (e-mail de rappel)
7 jours (e-mail d’urgence)
Paywall dans l’application ou restriction de fonctionnalité
Conclusion : cessez de traiter tous les refus de la même manière
La plus grosse erreur dans la récupération des paiements est d’appliquer le même calendrier de nouvelles tentatives et la même séquence de communication à chaque paiement échoué. Un refus pour fonds insuffisants et un refus sur une carte remplacée ou réémise nécessitent des réponses fondamentalement différentes.
Les entreprises qui récupèrent 70 à 90 % de leurs paiements échoués font trois choses différemment : elles classent chaque refus par type et ajustent leur stratégie en conséquence, elles épuisent les nouvelles tentatives silencieuses avant d’impliquer le client, et elles utilisent des modèles ML qui apprennent à partir de leurs propres schémas de transaction, et non de la moyenne globale.
Passez à l’action :
https://www.flycode.com/churn-audit-failed-payments : obtenez un audit de paiement gratuit, voyez la répartition de vos codes de refus et votre taux de récupération par type.
https://www.flycode.com/revenue-recovery-calculator : calculez votre ROI de récupération des revenus.
https://marketplace.stripe.com/apps/flycode-payments : installez FlyCode pour Stripe.
Lectures associées
https://www.flycode.com/blog/stripe-generic-decline-code-what-it-means-why-it-happens-and-how-flycode-recovers-the-revenue
https://www.flycode.com/blog/the-do-not-honor-decline-code-what-subscription-businesses-need-to-know
https://www.flycode.com/blog/what-are-issuer-declines-in-stripe-failed-payment-report
https://www.flycode.com/blog/subscription-ghosting-when-"insufficient-funds"-steals-your-mrr
https://www.flycode.com/blog/how-to-deal-with-failed-payments-if-you-re-using-stripe
Associés
Codes de refus expliqués dans le Centre d’aide
Référence des codes de refus Stripe (chaque code avec son code de réponse réseau)
Mis à jour
Ce contenu vous a-t-il été utile ?