> 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/flycode-vs.-profitwell-paddle-retain/whats-different-behind-the-scenes.md). # What's Different Behind the Scenes Why FlyCode's per-merchant AI retry engine outperforms ProfitWell Retain's fixed-interval schedule, and how FlyCode coordinates customer emails with the retry cycle instead of emailing after every att Two design decisions explain most of the performance gap between FlyCode and ProfitWell Retain: how retries are scheduled and how emails are timed. ## Why does FlyCode's AI-driven retry engine matter? Because the right retry moment differs by customer, card and bank, and a fixed schedule cannot capture that. ProfitWell Retain relies on a fixed-interval retry schedule applied to every failed invoice in the same way. FlyCode trains a custom machine-learning model for each merchant on that merchant's own transactions and issuer responses, and the model keeps learning from every outcome. It weighs the decline code, issuer behaviour, card type and brand, country and time zone, amount and the customer's past payment dates to choose the retry window most likely to succeed, while staying inside Visa and Mastercard limits on attempts per cycle. The practical effects are fewer wasted attempts, faster recovery, less exposure to excessive-retry fees, and a materially higher recovery rate, especially on the `insufficient_funds` declines that make up the largest share of failures. ## How does FlyCode handle customer emails during the retry cycle? FlyCode coordinates emails with its retry plan instead of running an independent drip. No email is sent immediately after a soft decline, because silent retries usually recover it and an early email risks turning an unaware customer into a voluntary cancellation. Hard declines get their own distinct schedule with a specific request for a new payment method. Every message is sent at the customer's local time, from your own domain, using short transactional templates from high-deliverability sending infrastructure. This goes well beyond Stripe's one or two default messages and differs from dunning-first tools that email at each attempt. See [Coordinating Messaging with Recovery](https://help.flycode.com/handling-failed-payments/coordinating-messaging-with-recovery). ## Related * [When and How Payments Are Retried](https://help.flycode.com/handling-failed-payments/when-and-how-payments-are-retried) * [Failed Payment Outreach](https://help.flycode.com/failed-payment-outreach) --- # 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/flycode-vs.-profitwell-paddle-retain/whats-different-behind-the-scenes.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.