> 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 Quels codes de refus Stripe FlyCode traite comme des refus définitifs, ce qu’il en fait (relances plus rapides et ciblées, et débit de la carte de secours), mises à jour automatiques pour les cartes remplacées, et paiement 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.flycode.com/fr/ai-payment-recovery/hard-declines-and-backup-logic.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.