> For the complete documentation index, see [llms.txt](https://help.flycode.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.flycode.com/fr/decline-codes-explained/what-decline-codes-tell-you.md). # Ce que les codes de refus vous indiquent Un code de refus est la raison donnée par la banque émettrice pour refuser un débit par carte. Stripe et d'autres processeurs l'affichent pour chaque paiement échoué, et c'est l'information la plus importante pour déterminer si un paiement d'abonnement échoué peut être récupéré automatiquement ou s'il nécessite l'aide du client. Cette page répond aux quatre questions que les commerçants posent le plus souvent sur la signification des codes de refus. ## Que sont les codes de refus dans le contexte des paiements échoués ? Les codes de refus sont de courtes chaînes renvoyées par la banque émettrice de la carte et affichées par Stripe et d'autres processeurs de paiement pour expliquer pourquoi une transaction a été refusée, par exemple `fonds insuffisants` ou `do_not_honor`. La banque prend la décision d'approbation ou de refus, envoie un code de réponse réseau à deux caractères (tel que `51` ou `05`) en retour via le réseau de cartes, et le processeur le traduit en son propre code lisible. Dans Stripe, la valeur apparaît comme `decline_code` dans la dernière erreur de paiement d'un PaymentIntent, Charge ou Invoice. Le code guide la prochaine action du commerçant : réessayer la même carte plus tard, demander une nouvelle carte ou indiquer au client de contacter sa banque. Sans lui, chaque paiement échoué se ressemble et reçoit le même traitement, c'est pourquoi la plupart des processus de relance hérités sont moins performants. ## Pourquoi les codes de refus sont-ils importants pour mon activité d'abonnement ? Parce qu'ils vous permettent d'automatiser la bonne prochaine étape pour chaque échec au lieu de deviner. Savoir si un refus est temporaire ou définitif vous indique s'il faut lancer des nouvelles tentatives optimisées (refus temporaires) ou inviter le client à fournir de nouvelles informations de paiement (refus définitifs). Bien faire cela préserve les revenus à double titre : les refus temporaires sont récupérés discrètement avant même que le client n'apprenne qu'il y a un problème, et les refus définitifs déclenchent immédiatement une demande précise au lieu de jours de tentatives infructueuses. Pour une activité d'abonnement, les paiements échoués représentent généralement 8 à 15 % des débits, et l'attrition involontaire due à ces échecs est souvent la principale source d'attrition. Les codes de refus sont le levier qui transforme cette perte en un chiffre récupérable et mesurable. Voir [Comprendre l'attrition involontaire](https://help.flycode.com/understanding-involuntary-churn) pour l'impact sur l'activité. ## Quelle est la différence entre un refus temporaire et un refus définitif ? Un refus temporaire est provisoire et peut réussir lors d'une tentative ultérieure ; un refus définitif est permanent pour cette carte et nécessite de nouvelles informations de paiement. | | Refus temporaire | Refus définitif | | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Nature | Condition temporaire chez l'émetteur ou sur le compte | La carte est invalide, clôturée, perdue ou volée | | Codes typiques | `fonds insuffisants`, `generic_decline`, `do_not_honor`, `try_again_later`, `issuer_not_available`, `processing_error` | `lost_card`, `stolen_card`, `pickup_card`, `invalid_account`, `invalid_number`, `invalid_cvc`, `la consigne do_not_try_again` | | Part des échecs d'abonnement | Environ 60 à 70 % | Environ 30 à 40 % | | Réponse appropriée | Réessayer au bon moment, sans contact client au début | Cesser les tentatives, demander un nouveau moyen de paiement ou se rabattre sur une carte de secours enregistrée | | Potentiel de récupération | Élevé avec un bon timing | Dépend de la relance et des moyens de secours | La règle qui découle de ce tableau : épuiser les nouvelles tentatives intelligentes sur les refus temporaires avant de contacter le client, et contacter le client immédiatement en cas de refus définitifs. ## Les schémas de codes de refus sont-ils utiles pour détecter la fraude ? Oui. Des groupes de refus définitifs tels que `stolen_card` ou `pickup_card` sur un seul compte ou dans une courte fenêtre sont un signal qu'il faut ajouter une vérification, et des répétitions rapides de refus temporaires sur de nombreux petits montants indiquent souvent des bots de test de cartes sondant des numéros volés. Des codes comme `fraudulent` et `security_violation` proviennent directement du score de risque de l'émetteur ou de Stripe Radar. FlyCode affiche ces anomalies dans son tableau de bord afin que les équipes des paiements et de la finance puissent distinguer un client qui manque temporairement de fonds d'un compte qui devrait être bloqué, et il ne retente jamais un débit que l'émetteur a signalé comme frauduleux. ## Associé * [Où trouver les codes de refus (et comment les utiliser)](https://help.flycode.com/decline-codes-explained/where-to-find-decline-codes-and-how-to-use-them) * [Comment gérer les refus les plus courants](https://help.flycode.com/decline-codes-explained/how-to-handle-the-most-common-declines) * [Référence des codes de refus Stripe sur flycode.com](https://www.flycode.com/stripe/decline-codes) --- # 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://help.flycode.com/fr/decline-codes-explained/what-decline-codes-tell-you.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.