Comment fonctionne FlyCode : architecture du moteur de récupération
Comment FlyCode récupère les paiements d'abonnement échoués : les signaux qu'il lit, le modèle par marchand qui décide de chaque nouvelle tentative, les actions qu'il entreprend et les garde-fous.
Par l’équipe FlyCode. Dernière révision en septembre 2026.
Points clés à retenir
FlyCode remplace le moteur de nouvelles tentatives au lieu d’ajouter des essais par-dessus. Les nouvelles tentatives intégrées de votre processeur et les e-mails de relance sont désactivés afin qu’une seule couche coordonnée décide de chaque tentative sur une carte.
Les décisions sont prises par marchand, et non à partir d’une moyenne globale : le modèle est entraîné sur vos propres raisons de refus, les réponses des émetteurs, les schémas BIN, les types de cartes, la géographie et les signaux de cycle de solde, en utilisant plus de 100 points de données par transaction ainsi que les données du réseau Visa et Mastercard.
Le recouvrement silencieux passe en premier (nouvelles tentatives et moyens de paiement de secours). Les clients ne sont contactés que lorsque le réseau a réellement besoin qu’ils agissent, et chaque message est séquencé avec les nouvelles tentatives afin que personne ne reçoive d’e-mail à propos d’un débit sur le point de réussir.
La configuration prend quelques minutes, aucune intervention d’ingénierie n’est requise, et la tarification correspond à un pourcentage du revenu récupéré au-dessus de votre base de référence mesurée.
Les quatre couches
Chaque paiement échoué passe par les mêmes quatre couches. Les comprendre explique pourquoi les chiffres de recouvrement de FlyCode diffèrent d’un calendrier fixe de nouvelles tentatives.
1. Entrées
FlyCode reçoit la facture en échec, le code de refus du processeur, le code brut de réponse du réseau, l’émetteur, le BIN et le type de carte, le montant, la devise, l’historique client et le fuseau horaire.
Les webhooks de la plateforme de facturation et les lectures d’API (pour Stripe : les quatre appels listés dans le Guide d’intégration Stripe) ainsi que les données du réseau de cartes.
2. Prise de décision
Un modèle par marchand classe l’échec (réversible, irréversible, authentification, fraude), prédit quand et comment une nouvelle tentative a le plus de chances d’être approuvée, et évalue la facture selon sa valeur.
Votre propre historique de transactions, plus les apprentissages inter-marchands de FlyCode et les signaux du réseau Visa et Mastercard.
3. Actions
Nouvelle tentative adaptative au moment choisi, tentative via un moyen de paiement de secours, orchestration du paiement vers un autre processeur, puis e-mail ou SMS de recouvrement si le client doit intervenir.
Exécuté via la plateforme de facturation afin que la facture, l’abonnement et les reçus restent synchronisés.
4. Reporting
Le revenu récupéré est attribué par rapport à la base de référence d’avant FlyCode ; le tableau de bord affiche le taux de recouvrement, le recouvrement incrémental, les tentatives par recouvrement et l’entonnoir de contact.
Tableau de bord FlyCode et rapports périodiques.
Couche 1 : ce que lit FlyCode
Un paiement échoué contient plus d’informations que le code que vous voyez dans le tableau de bord de votre processeur. La banque émettrice renvoie un code de réponse brut, le réseau le standardise, et le processeur le traduit à nouveau (par exemple generic_decline dans Stripe peut masquer une douzaine de décisions bancaires). FlyCode capture toute la chaîne et ajoute un contexte que le processeur n’utilise pas : l’historique de comportement de l’émetteur envers votre compte marchand, la plage BIN et le type de produit de la carte (crédit, débit, prépayée), l’historique de paiement du client chez vous, le jour du mois par rapport aux cycles de paie habituels, et l’heure locale.
FlyCode ne traite jamais de numéros de carte bruts. Les débits sont exécutés par votre processeur sur les moyens de paiement déjà enregistrés chez lui.
Couche 2 : comment la décision est prise
Le cœur de FlyCode est un modèle d’apprentissage automatique par marchand. Un modèle global (du type de celui qu’exécute un processeur sur des millions d’entreprises) optimise pour le marchand moyen. Un modèle par marchand apprend, par exemple, que vos clients chez un émetteur donné approuvent à 9 h, heure locale, le deuxième jour après un échec, ou que do_not_honor à partir d’une plage BIN donnée se comporte comme un manque de fonds. Le modèle répond à trois questions pour chaque facture ouverte :
Cette facture peut-elle être récupérée par une nouvelle tentative ? Les refus souples (fonds insuffisants, émetteur indisponible, erreurs de traitement, la plupart des refus génériques) le sont généralement. Les refus définitifs (identifiants invalides ou remplacés, carte volée ou perdue, compte fermé) ne le sont pas, et les réessayer gaspille des tentatives réseau. La référence des codes de refus répertorie chaque code.
Quel est le meilleur moment pour la prochaine tentative ? Le moment est choisi par facture, et non selon un calendrier fixe à 3, 5, 7 jours, et toujours dans les limites de Visa et Mastercard (voir les règles de nouvelle tentative du réseau de cartes).
Quelle est la valeur de la facture à poursuivre ? L’évaluation de la valeur (ARR, valeur vie client, ancienneté, coût d’acquisition) décide de la durée du recouvrement et de savoir si la facture est transmise à un humain via Priority Recovery.
Couche 3 : les actions, dans l’ordre
Nouvelles tentatives adaptatives. La nouvelle tentative est programmée au meilleur moment prévu pour cette carte et cet émetteur. Le nombre de tentatives reste dans les limites du réseau et un seul calendrier coordonné remplace les nouvelles tentatives par défaut du processeur.
Moyens de paiement de secours adaptatifs. Lorsque la carte principale échoue et que le client a d’autres moyens de paiement valides enregistrés, FlyCode débite le meilleur suivant, sans action du client. Voir Moyens de paiement de secours sur Stripe.
Orchestration des paiements. Pour les marchands utilisant plus d’un processeur, l’agent d’orchestration sans code peut router un débit échoué vers un fournisseur ayant une probabilité d’approbation plus élevée.
Contact de recouvrement. Ce n’est que lorsque le refus nécessite une action du client (nouvelle carte requise, authentification requise) que FlyCode envoie un e-mail ou SMS de marque depuis votre domaine, à l’heure locale du client, avec un lien de mise à jour sans connexion. Les messages sont retenus pendant qu’une nouvelle tentative est en attente. Voir la collection de contact du Centre d’aide.
Règles du cycle de vie. Lorsque le recouvrement est épuisé, vos règles décident de ce qui se passe par produit et par segment : annuler, invalider ou laisser en retard de paiement. Les annulations pour non-paiement peuvent déclencher Réactivation.
Mesures de protection
Pas de double relance. Sur Recharge, Skio, Stay AI et Chargebee, des garde-fous orientent les paiements échoués vers FlyCode et synchronisent les débits récupérés en retour, afin que la relance native et FlyCode n’envoient jamais de message deux fois au même client. Détails pour Shopify dans Comment FlyCode gère les paiements d’abonnement Shopify échoués.
Conformité réseau. Les volumes de tentatives et les codes de non-réessai suivent les règles Visa et Mastercard, ce qui protège votre taux d’autorisation au premier essai.
La base de référence d’abord. Vos performances de recouvrement avant FlyCode sont mesurées afin que le gain incrémental, et les frais, soient calculés par rapport à un chiffre réel. Voir explication du modèle tarifaire.
Contrôles de mise en production. Les intégrations démarrent en mode surveillance ; le recouvrement est activé une fois que les paramètres côté plateforme (nouvelles tentatives natives, e-mails natifs) sont alignés.
À quoi ressemblent les résultats
Parmi les résultats publiés chez les clients, les équipes qui passent des nouvelles tentatives par défaut du processeur constatent une hausse de 16 à 25 points du taux de recouvrement et une augmentation de 5 à 9 % de l’ARR ; par rapport aux outils de relance hérités, la hausse est de 25 à 40 %. Exemples : Capsho 63 à 91 % de recouvrement, Gardencup 62 à 82 % avec une hausse de 20 % de LTV, BUBS Naturals 51 à 66 % en un mois, GitBook +8 % d’ARR. Voir Coût des paiements échoués et ROI du recouvrement pour le modèle derrière ces chiffres et les benchmarks par segment pour la liste complète.
FAQ
FlyCode remplace-t-il Stripe Smart Retries ou fonctionne-t-il à leurs côtés ?
FlyCode les remplace. Pendant la configuration, les nouvelles tentatives automatiques et les e-mails d’échec de paiement de Stripe sont désactivés afin qu’un seul moteur coordonné décide de chaque tentative. Des nouvelles tentatives superposées provenant de deux systèmes sont interprétées par les émetteurs comme une activité non coordonnée et peuvent faire baisser les taux d’autorisation.
FlyCode stocke-t-il les numéros de carte ?
Non. Les débits sont exécutés par votre processeur sur les moyens de paiement déjà stockés chez lui. FlyCode travaille avec des jetons, des objets facture et abonnement, ainsi que des données de refus.
Combien de temps faut-il pour que FlyCode soit en ligne ?
La plupart des marchands se connectent en quelques minutes (installation de l’application Stripe, application de marketplace Recharge ou marketplace Skio) et constatent une hausse mesurable en un à deux cycles de facturation.
FlyCode fonctionne-t-il aussi bien pour le B2B que pour le B2C ?
Oui. Comme le modèle s’adapte par marchand plutôt que par catégorie, il est utilisé par des marques d’abonnement SaaS, B2B, fintech et DTC. Hausses publiées par segment : 27 % B2C, 19 % B2B, 26 % DTC, 23 % entreprises IA (par rapport à l’outil précédent).
Connexe
Comment l’IA de FlyCode décide-t-elle quand réessayer ? dans le centre d’aide
Ce contenu vous a-t-il été utile ?