> 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/coordinating-messaging-with-recovery.md). # Coordonner les messages avec la récupération La manière dont vous communiquez au sujet d’un paiement échoué détermine si un événement de désabonnement involontaire reste récupérable ou se transforme en une véritable résiliation. FlyCode considère les messages comme faisant partie du moteur de récupération plutôt que comme une simple série d’e-mails distincte. Cette page explique ce qui est fourni, en quoi cela diffère des paramètres par défaut de Stripe, et ce qu’il faut montrer au client. ## Proposez-vous des modèles d’e-mails pour les relances en cas d’échec de paiement ? Oui. FlyCode inclut des modèles transactionnels prêts à l’emploi pour les relances en cas d’échec de paiement, et ses modèles de communication déterminent quand chacun est envoyé afin que les e-mails soient coordonnés avec le calendrier des nouvelles tentatives plutôt que d’être envoyés après chaque tentative. Les modèles sont courts, transactionnels et spécifiques au type d’échec (une demande de nouvelle carte se présente différemment d’une note indiquant qu’une nouvelle tentative est programmée), et ils peuvent être personnalisés avec votre marque, votre ton et votre domaine d’envoi. Ils sont envoyés depuis une infrastructure d’envoi à forte réputation afin de maintenir une excellente délivrabilité, et les SMS sont disponibles en plus des e-mails. Voir [Relance des paiements échoués](https://help.flycode.com/failed-payment-outreach) pour les détails de personnalisation et de délivrabilité. ## Comment FlyCode gère-t-il les e-mails clients par rapport aux paramètres par défaut de Stripe ? La relance par défaut de Stripe peut envoyer un e-mail à chaque tentative échouée, jusqu’à huit e-mails sur un cycle de nouvelles tentatives, chacun alertant un client qui ignorait peut-être qu’un problème existait. C’est le mécanisme par lequel le désabonnement involontaire devient volontaire : le client voit des échecs de paiement répétés, estime que l’abonnement est une contrainte, et résilie. FlyCode coordonne les e-mails avec ses nouvelles tentatives. Aucun e-mail n’est envoyé après un refus temporaire tant que la récupération silencieuse a encore de bonnes chances de réussir. Lorsqu’une relance est nécessaire, elle est envoyée selon un rythme conçu pour le type d’échec, dans le fuseau horaire local du client, depuis votre propre domaine, avec une seule action claire. Au lancement, vous désactivez les e-mails par défaut de Stripe concernant les paiements échoués afin que les deux systèmes n’envoient pas tous deux des messages au client. Le [Guide d’intégration à Stripe](https://docs.flycode.com/docs/integrations/stripe-integration-guide-for-flycode) couvre les paramètres exacts. ## Dois-je montrer le code de refus brut aux clients ? C’est votre choix, et la recommandation habituelle est non. Des codes bruts comme `do_not_honor` ou `generic_decline` ne signifient rien pour la plupart des clients et peuvent paraître alarmants. Le produit d’e-mail de FlyCode vous permet d’afficher un message convivial et orienté vers l’action (« votre banque a refusé le renouvellement ; mettez à jour votre carte ou contactez votre banque ») tout en enregistrant en interne le code exact du refus pour les agents du support et pour la logique automatique de nouvelle tentative. L’exception est lorsque le code comporte une action claire pour le client, par exemple lorsqu’une banque exige une autorisation pour les prélèvements récurrents, auquel cas nommer la raison aide le client à la résoudre. ## Associé * [Stratégie de diffusion pour les relances de paiement échouées](https://help.flycode.com/failed-payment-outreach/delivery-strategy) * [Comportement des e-mails et délivrabilité](https://help.flycode.com/ai-payment-recovery/email-behavior-and-deliverability) * [Guide 2026 de gestion des relances de paiement](https://docs.flycode.com/docs/dunning-management-2026-guide) --- # 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/coordinating-messaging-with-recovery.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.