> 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/read-more/failed-payment-recovery-glossary.md).

# Glossaire de la récupération des paiements échoués

Définitions courtes et autonomes des termes utilisés dans toute la documentation de FlyCode et, plus généralement, dans les paiements d'abonnement. Chaque entrée renvoie vers la page contenant plus de détails.

**Désabonnement involontaire.** La perte d'un abonné parce qu'un paiement récurrent a échoué et n'a pas été récupéré, plutôt que parce que le client a choisi d'annuler. Aussi appelé désabonnement passif, en impayé ou lié au paiement. Représente généralement 20 à 40 % du désabonnement total d'abonnement. Voir [Comprendre le churn involontaire](https://help.flycode.com/understanding-involuntary-churn).

**Désabonnement volontaire.** Un client qui annule activement un abonnement en raison du prix, de l'adéquation, de la concurrence ou d'un besoin. Nécessite des réponses sur le produit et la tarification plutôt qu'une optimisation des paiements.

**Paiement échoué / paiement refusé.** Une transaction récurrente que la banque émettrice a refusé d'autoriser. Le refus s'accompagne d'un code de refus.

**Code de refus.** La raison que donne la banque émettrice pour refuser un débit, standardisée par les réseaux de cartes sous la forme d'un code de réponse à deux caractères (par exemple 05 Do Not Honor, 51 Insufficient Funds) et traduite par les processeurs dans leur propre vocabulaire (Stripe: `do_not_honor`, `insufficient_funds`). Voir [Codes de refus expliqués](https://help.flycode.com/decline-codes-explained).

**Refus temporaire.** Un refus temporaire qui peut réussir lors d'une tentative ultérieure : fonds insuffisants, refus générique, ne pas honorer, réessayer plus tard, émetteur indisponible, erreur de traitement. Environ 60 à 70 % des échecs de paiement d'abonnement.

**Refus définitif.** Un refus permanent pour cette carte : perdue, volée, saisie, compte fermé ou invalide, et toute réponse avec consigne de ne pas réessayer. Nécessite un nouveau moyen de paiement ; ne doit pas être retenté.

**Dunning.** Le processus de récupération d'un paiement en retard, historiquement par l'envoi de messages de rappel. Le dunning moderne combine d'abord des relances silencieuses, puis une prise de contact coordonnée. Voir [Guide 2026 de gestion des relances](https://docs.flycode.com/docs/dunning-management-2026-guide).

**Nouvelle tentative (réessai).** Une nouvelle tentative d'autorisation sur un débit précédemment refusé. Les réseaux de cartes limitent le nombre et le calendrier des nouvelles tentatives. Voir [Règles de relance des réseaux de cartes](https://docs.flycode.com/docs/read-more/card-network-retry-rules-for-failed-payments-visa-and-mastercard).

**Relances intelligentes.** La fonctionnalité de réessai par apprentissage automatique intégrée à Stripe Billing, entraînée sur tous les marchands Stripe et plafonnée à 8 tentatives par facture. Voir [Guide complet de Stripe Smart Retries](https://docs.flycode.com/docs/stripe-smart-retries-complete-guide).

**Relances personnalisées.** L'alternative à intervalle fixe de Stripe aux relances intelligentes, avec des relances à des intervalles de jours définis.

**Taux de recouvrement.** Les paiements échoués récupérés divisés par le total des paiements échoués sur une période donnée. La référence du secteur est d'environ 40 à 55 % ; les meilleurs atteignent 70 à 90 %.

**Taux d'échec des paiements.** Les débits échoués divisés par les débits tentés. Généralement 8 à 15 % pour les entreprises par abonnement.

**Vitesse de recouvrement.** Nombre moyen de jours entre le premier échec et la récupération réussie. Un recouvrement plus rapide signifie moins de risque de désabonnement.

**Conversion du désabonnement passif en désabonnement actif.** Des clients qui annulent volontairement après avoir été informés d'un paiement échoué dont ils n'avaient pas connaissance, généralement parce qu'un e-mail de dunning est arrivé avant que les relances n'aient eu une chance d'aboutir. La principale raison de réessayer silencieusement d'abord.

**Période de grâce / en retard de paiement.** La durée pendant laquelle un abonnement reste actif ou en retard après un paiement échoué avant que le système de facturation ne l'annule. Des périodes de grâce plus longues laissent davantage de marge pour la récupération.

**Card Account Updater (CAU).** Services Visa (VAU) et Mastercard (ABU) qui transmettent de nouvelles informations de carte aux commerçants lorsqu'un émetteur remplace ou réémet une carte, afin que les cartes enregistrées continuent de fonctionner sans action du client.

**Jeton réseau.** Un jeton émis par le réseau qui remplace le numéro de carte dans le coffre du commerçant et se met à jour automatiquement lorsque la carte sous-jacente change, améliorant ainsi les taux d'autorisation.

**Méthode de paiement de secours.** Un moyen de paiement valide supplémentaire enregistré pour un client et qui peut être débité automatiquement lorsque le moyen principal échoue. Voir [Méthodes de paiement de secours](https://help.flycode.com/backup-payment-methods).

**Orchestration des paiements.** Acheminer les transactions via plus d'un processeur de paiement selon des règles ou des modèles. En recouvrement, réacheminer une nouvelle tentative refusée via un processeur alternatif plus susceptible de l'approuver. Voir [Agent d'orchestration des paiements](https://help.flycode.com/payment-orchestration-agent).

**Émetteur (banque émettrice).** La banque du titulaire de la carte, qui prend la décision d'approuver ou de refuser.

**Acquéreur.** La banque ou le processeur du commerçant qui soumet l'autorisation au réseau de cartes.

**Code de conseil du commerçant (MAC).** Un champ Mastercard renvoyé avec de nombreux refus qui indique au commerçant quoi faire ensuite, par exemple 01 mettre à jour les informations du compte, 02 réessayer plus tard, 03 ne pas réessayer, 21 paiement récurrent annulé.

**Transaction initiée par le commerçant (MIT).** Un débit initié par le commerçant à l'aide d'identifiants stockés, sans la présence du client, comme un renouvellement d'abonnement ou une relance. Doit être signalé correctement conformément aux règles de stockage des identifiants du réseau.

**3D Secure / SCA.** Étapes d'authentification du titulaire de la carte (authentification forte du client dans l'UE et au Royaume-Uni). Un refus de `authentication_required` ne peut pas être récupéré par une nouvelle tentative silencieuse ; le client doit terminer l'authentification.

**Tarification basée sur les résultats.** Un modèle de tarification dans lequel le fournisseur est payé sur une part des revenus récupérés au-dessus du niveau de référence antérieur du commerçant, et rien sur les revenus que le commerçant aurait de toute façon récupérés. Le modèle de FlyCode.

**Recouvrement de référence.** Le taux de recouvrement qu'un commerçant obtenait avant d'ajouter un outil de recouvrement, utilisé pour mesurer l'amélioration incrémentale.

**Revenu à risque.** Le MRR échoué multiplié par la durée de vie moyenne restante du client ; l'exposition financière réelle des paiements échoués. Voir [ROI de 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://docs.flycode.com/docs/fr/read-more/failed-payment-recovery-glossary.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.