> 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/ai-payment-recovery/hard-declines-and-backup-logic.md).

# Refus définitifs et logique de secours

Toutes les tentatives de paiement échouées ne sont pas identiques. Un refus souple est un problème de timing ; un refus ferme signifie que la carte ne peut pas être débitée à nouveau. FlyCode applique une logique différente à chacun, et pour les refus fermes, il dispose de deux voies qui ne dépendent pas de la réponse du client à un e-mail : débiter une carte de secours et actualiser automatiquement les identifiants d’une carte remplacée.

## Quels codes de refus FlyCode traite-t-il comme des refus fermes ?

Les réponses de l’émetteur qui signifient que la carte ne doit pas être retentée. Dans le vocabulaire de Stripe, ce sont `incorrect_number`, `lost_card`, `pickup_card`, `stolen_card`, `revocation_of_authorization`, `revocation_of_all_authorizations`, `authentication_required` (le client doit terminer 3D Secure, donc une nouvelle tentative silencieuse ne peut pas réussir) et `highest_risk_level` (le blocage de Stripe Radar). Les codes tels que `invalid_account` et tout ce qui est renvoyé avec `la consigne do_not_try_again` sont traités de la même façon. Tout le reste, y compris `insufficient_funds`, `generic_decline`, `do_not_honor`, `try_again_later` et `processing_error`, est un refus souple et passe au modèle de relance. Voir [Codes de refus expliqués](https://help.flycode.com/decline-codes-explained) pour savoir ce que signifie chaque code.

## Que fait FlyCode avec les refus fermes ?

Pour un refus ferme, le client doit changer la carte enregistrée, donc FlyCode ne consomme pas de tentatives ni de jours de période de grâce à la retenter. D’abord, il vérifie s’il existe déjà un moyen de paiement de secours enregistré et le débite si c’est le cas. Sinon, il ajuste la cadence des messages pour qu’elle soit plus rapide que pour les refus souples, utilise des modèles dynamiques avec l’action précise requise (« mettez à jour votre carte », « terminez la vérification auprès de votre banque »), renvoie vers une page de mise à jour du paiement en un clic, et enchaîne les relances en fonction de l’engagement passé du client avec les e-mails. Une fois que le client met à jour la carte, FlyCode retente immédiatement et marque la facture comme recouvrée.

## FlyCode peut-il mettre à jour automatiquement les cartes remplacées ou réémises ?

Oui. FlyCode prend en charge à la fois Card Account Updater (CAU) et les jetons réseau. Lorsqu’une banque émettrice remplace ou réémet la carte d’un client, Visa et Mastercard transmettent les nouvelles données d’identification à la carte enregistrée, et FlyCode retente avec les informations actuelles. Aucune action n’est requise du client, et aucun e-mail de relance n’a besoin d’être envoyé au préalable. Une grande partie des refus fermes causés par des données de carte obsolètes sont ainsi résolus silencieusement, de sorte que les relances peuvent être réservées aux échecs qui nécessitent vraiment l’attention du client, comme les fonds insuffisants et les refus génériques qui ne se résolvent pas après des tentatives de nouvelle exécution optimisées.

## FlyCode prend-il en charge les moyens de paiement de secours ?

Oui. FlyCode peut retenter automatiquement un paiement échoué en utilisant une autre carte déjà enregistrée pour le client, sans aucun flux de travail manuel et sans interrompre le service du client. Cela s’active avec une simple bascule et ne nécessite aucun code supplémentaire ni parcours de collecte, car il utilise les moyens de paiement déjà stockés par votre plateforme de facturation. Si toutes les cartes enregistrées échouent, FlyCode revient à sa logique standard de nouvelle tentative et de communication. Les détails, les exigences légales et les rapports se trouvent dans [Moyens de paiement de secours](https://help.flycode.com/backup-payment-methods).

## Associé

* [Que faire lorsque vous voyez ces autres codes](https://help.flycode.com/decline-codes-explained/what-to-do-when-you-see-these-other-codes)
* [Stratégie de diffusion pour les relances de paiement échouées](https://help.flycode.com/failed-payment-outreach/delivery-strategy)


---

# 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/ai-payment-recovery/hard-declines-and-backup-logic.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.