> 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/understanding-involuntary-churn/causes-and-risks.md).

# Causes et risques

La plupart des paiements d’abonnement échoués ne sont pas de la faute du client et ne sont pas permanents. Comprendre les causes vous indique quels échecs peuvent être récupérés silencieusement et lesquels nécessitent l’intervention du client, et comprendre les risques montre pourquoi la facture impayée n’est que la plus petite partie du coût.

## Quelles sont les principales raisons pour lesquelles un paiement échoue ?

Les principales causes, par ordre approximatif de fréquence, sont l’insuffisance de fonds, les refus génériques de la banque ou de la carte, des informations de facturation incorrectes ou obsolètes, et les erreurs techniques de la passerelle ou du processeur.

**Fonds insuffisants** est la plus grande catégorie à elle seule, représentant 50 à 70 % des refus dans l’étude de FlyCode portant sur plus de 500 commerçants, due aux renouvellements qui tombent avant la paie, aux retenues en attente et aux limites de dépenses des cartes. **Refus génériques et de l’émetteur** (`do_not_honor`, `generic_decline`) sont les suivantes par importance : la banque refuse sans motif indiqué, généralement en raison de règles internes de risque, de limites de fréquence ou de restrictions sur les paiements récurrents ou transfrontaliers. **Coordonnées incorrectes ou obsolètes** couvrent les numéros erronés, les vérifications CVC ou du code postal échouées, ainsi que les cartes qui ont été remplacées, clôturées, perdues ou volées. **Erreurs techniques** (`processing_error`, `issuer_not_available`, `try_again_later`) sont des échecs temporaires de la banque, du réseau ou de la passerelle et réussissent presque toujours lors d’une nouvelle tentative rapide.

Les deux premières catégories et les erreurs techniques sont des refus temporaires et représentent environ 60 à 70 % de tous les échecs. Seule la catégorie des coordonnées obsolètes est définitive. Voir [Explication des codes de refus](https://help.flycode.com/decline-codes-explained) pour les détails au niveau des codes.

## Quels sont les codes de refus définitifs dans les paiements échoués ?

Un refus définitif est un refus permanent pour cette carte : l’émetteur a indiqué que la carte ne peut plus être débitée, donc réessayer ne fonctionnera pas. Les codes typiques sont `lost_card`, `stolen_card`, `pickup_card`, `invalid_account`, `invalid_number` et tout code renvoyé avec `do_not_try_again` indication. Lorsque l’émetteur renvoie un refus définitif, FlyCode ne retente pas automatiquement la même carte. Il passe plutôt à la prochaine voie de récupération : débiter un moyen de paiement de secours déjà enregistré, actualiser les identifiants de carte via Card Account Updater ou les Network Tokens lorsque l’émetteur a réémis la carte, et si aucune de ces options ne s’applique, contacter immédiatement le client avec une demande précise d’un nouveau moyen de paiement. Comme les refus définitifs sont identifiés dès leur réception, aucun essai de nouvelle tentative ni aucun jour de période de grâce n’est gaspillé dessus.

## Au-delà du chiffre d’affaires, qu’est-ce qui est aussi menacé ?

Trois choses. D’abord, l’expérience client : le désabonnement dû aux paiements échoués coupe l’accès à des clients par ailleurs satisfaits, et un e-mail de relance mal calibré ou générique peut transformer un client qui ignorait le problème en quelqu’un qui décide d’annuler, convertissant un désabonnement involontaire en désabonnement volontaire. Deuxièmement, la perception de la marque : un compte verrouillé ou une série de rappels de paiement donne l’impression d’un échec de l’entreprise, pas de la banque. Troisièmement, le coût d’acquisition : chaque abonné perdu à cause d’un paiement échoué doit être remplacé, à un coût d’acquisition client qui est généralement 5 à 10 fois supérieur au coût de récupération du paiement, et le remplaçant repart de zéro en valeur vie client.

Il existe aussi un aspect conformité : retenter trop agressivement des cartes refusées enfreint les règles de nouvelle tentative de Visa et Mastercard et peut déclencher des frais de tentatives excessives ou des pénalités de l’émetteur ; la récupération doit donc être à la fois intelligente et persistante.

## Articles associés

* [Comment gérer les refus les plus courants](https://help.flycode.com/decline-codes-explained/how-to-handle-the-most-common-declines)
* [Moyens de paiement de secours](https://help.flycode.com/backup-payment-methods)
* [Retour sur investissement de la récupération des coûts liés aux paiements échoués](https://docs.flycode.com/docs/failed-payment-cost-recovery-roi)


---

# 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/understanding-involuntary-churn/causes-and-risks.md?ask=<question>&goal=<endgoal>
```

`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.
