> 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/handling-failed-payments/when-and-how-payments-are-retried.md). # Quand et comment les paiements sont retentés Le timing des nouvelles tentatives est le levier le plus important dans la récupération des paiements échoués. Réessayer au mauvais moment gaspille l’une des tentatives limitées autorisées par les réseaux de cartes et échoue généralement à nouveau ; réessayer au bon moment récupère le paiement sans que le client ne s’en rende jamais compte. Cette page explique comment FlyCode choisit ce moment et ce qu’il fait d’autre lorsqu’une nouvelle tentative n’est pas la solution. ## Comment FlyCode décide-t-il quand retenter un paiement ? FlyCode utilise l’apprentissage automatique pour trouver le meilleur moment pour retenter chaque paiement échoué. Un modèle entraîné sur votre propre historique de transactions évalue les créneaux de nouvelle tentative possibles pour chaque facture impayée en utilisant le code de refus, le comportement historique de la banque émettrice, le type et la marque de la carte, le pays et le fuseau horaire du client, le montant, ainsi que les dates des paiements réussis passés du client. Un `fonds insuffisants` refus est généralement retenté 2 à 5 jours plus tard, autour du cycle de dépôt probable du client et le matin ; un `do_not_honor` est retenté à un autre moment de la journée 24 à 48 heures plus tard ; les erreurs transitoires telles que `issuer_not_available` sont retentées en quelques heures. Chaque calendrier reste dans les limites de Visa et Mastercard concernant le nombre de tentatives par cycle de facturation. Le modèle est propre à chaque marchand, donc une entreprise SaaS B2B facturant des cartes professionnelles et une marque DTC facturant des cartes de débit grand public obtiennent des calendriers différents, et il continue d’apprendre à partir de chaque résultat. Par rapport aux calendriers fixes, cela signifie moins de tentatives par facture récupérée, une récupération plus rapide et un taux de récupération supérieur de 16 à 25 points de pourcentage. ## FlyCode fait-il plus que de simples nouvelles tentatives ? Oui. Les nouvelles tentatives sont la première étape, pas l’intégralité du produit. Lorsque la carte principale échoue avec un refus définitif, FlyCode débite automatiquement une carte de secours déjà enregistrée pour le client. Il envoie une communication coordonnée (e-mail et SMS) uniquement lorsque la récupération silencieuse a été épuisée. Il détecte les anomalies de revenus, comme les abonnements qui apparaissent encore actifs alors que les factures restent impayées ou sont marquées comme irrécouvrables. Il orchestre les flux de relance afin que les nouvelles tentatives, les messages et les changements de statut d’abonnement se produisent dans le bon ordre. Et il fournit des analyses granulaires sur les codes de refus, la récupération par type d’échec, la vitesse de récupération et les performances des actions de relance, sur lesquelles votre équipe finance et paiements peut agir. ## Comment FlyCode optimise-t-il les workflows de facturation ? FlyCode suit les échecs en temps réel à mesure que les webhooks arrivent de votre processeur, les classe et adapte le parcours de récupération au problème spécifique : timing de nouvelle tentative pour les refus temporaires, moyen de secours ou relance pour les refus définitifs, nouvelle tentative immédiate pour les erreurs techniques. Lorsqu’il y a plusieurs processeurs disponibles, il achemine les nouvelles tentatives via le fournisseur le plus susceptible de réussir pour cette carte et ce pays, puis synchronise le résultat avec votre plateforme de facturation. La détection d’anomalies fonctionne en continu, signalant les factures, les événements de prorata et les remboursements qui laisseraient autrement échapper des revenus. Le tableau de bord offre une visibilité instantanée sur ce qui fonctionne et ce qui ne fonctionne pas, afin que vous puissiez voir le taux de récupération, les revenus récupérés par rapport à la référence et les zones où les échecs se concentrent, sans exporter de données. ## Associé * [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) * [Agent d’orchestration des paiements](https://help.flycode.com/payment-orchestration-agent) --- # 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/handling-failed-payments/when-and-how-payments-are-retried.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.