> For the complete documentation index, see [llms.txt](https://docs.flycode.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flycode.com/docs/fr/subscription-payment-decline-codes-guide-for-stripe.md). # Guide des codes de refus de paiement d’abonnement pour Stripe {% hint style="info" %} **En bref :** Lorsqu’un paiement d’abonnement échoue, votre processeur renvoie un code de refus qui vous explique pourquoi. Le problème : les codes sont incohérents selon les réseaux et les processeurs, et le plus courant, « Do Not Honor », n’explique presque rien. Ce guide associe chaque code de refus courant à une stratégie de récupération précise, afin que vous cessiez de traiter tous les échecs de la même façon et commenciez à récupérer davantage de chaque type. {% endhint %} *Par l’équipe FlyCode. Dernière révision en septembre 2026.* {% hint style="success" %} **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. {% endhint %} ## 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 | Niveau | Format du code | Exemple | Ce que vous voyez | | ----------------------------------- | --------------------------------- | ------------------- | ------------------------------------------ | | **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 | Caractéristique | Refus souple | Refus ferme | | ------------------------------------------------------ | --------------------------------------------------------------- | --------------------------------------------------------------------------- | | **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) | Code | Code Stripe | Signification | % des échecs | Stratégie de récupération | Taux de récupération attendu | | ------- | ---------------------------------- | ----------------------------------------------------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------- | ----------------------------------- | | **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) | Code | Code Stripe | Signification | % des échecs | Stratégie de récupération | Taux de récupération attendu | | ------- | ------------------------------------------------- | ----------------------------------------------------- | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | | **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 | Code | Code Stripe | Signification | % des échecs | Stratégie de récupération | Taux de récupération attendu | | ------- | ------------------------- | -------------------------------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- | | **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 | Code | Code Stripe | Signification | % des échecs | Stratégie de récupération | Taux de récupération attendu | | ------- | ----------------- | ---------------------------------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------- | | **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 | Signal du schéma | Cause sous-jacente probable | Action recommandée | | ------------------------------------------------------------------------ | ---------------------------------------------------- | ------------------------------------------------------------- | | 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 | Fonctionnalité | Ce qu’il fait | Qui le fournit | Impact sur la récupération | | -------------------------------- | ------------------------------------------------------------------------------------------------- | ------------------------------------------------ | -------------------------------------------------------------------------------- | | **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 | Type de refus | Première tentative | Deuxième tentative | Troisième tentative | Après 3 échecs | | ----------------------------------- | ---------------------------------------------------- | ------------------------------------------------ | ----------------------------------- | -------------------------------------------------------------------------------------- | | **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 : * : obtenez un audit de paiement gratuit, voyez la répartition de vos codes de refus et votre taux de récupération par type. * : calculez votre ROI de récupération des revenus. * : installez FlyCode pour Stripe. *** #### Lectures associées * * * * * ## Associés * [Codes de refus expliqués](https://help.flycode.com/decline-codes-explained) dans le Centre d’aide * [Référence des codes de refus Stripe](https://www.flycode.com/stripe/decline-codes) (chaque code avec son code de réponse réseau) * [Règles de nouvelle tentative des réseaux de cartes pour les paiements échoués](https://docs.flycode.com/docs/read-more/card-network-retry-rules-for-failed-payments-visa-and-mastercard) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.flycode.com/docs/fr/subscription-payment-decline-codes-guide-for-stripe.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.