> 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/what-is-flycode/what-makes-flycode-different.md). # What Makes FlyCode Different How FlyCode differs from legacy dunning tools and fixed retry schedules: AI-native per-merchant models, retries separated from emails, alternative payment routing, and network data from Visa, Masterca Most payment recovery tools were built around a fixed retry calendar and a sequence of reminder emails. FlyCode was built around a model that learns from every transaction and issuer response. This page explains what that changes in practice and why FlyCode's card network and processor partnerships matter. ## How is FlyCode different from traditional payment-recovery tools? FlyCode is AI-native from day one. Legacy dunning tools and processors' built-in recovery apply static, rule-based schedules (retry on day 3, 5 and 7, email after each attempt) that are the same for every merchant and every failure. FlyCode trains a model per merchant on that merchant's own transactions and issuer responses, and it keeps learning: retry timing, payment routing and messaging are refined continuously as new outcomes come in. The result is fewer attempts per recovered invoice, faster recovery, fewer customer emails and a recovery rate 16 to 25 percentage points above the native baseline. Three other design choices set it apart. Recovery is silent first: no customer contact while a retry still has a good chance. Recovery is multi-path: if the primary card fails hard, FlyCode charges a backup method on file or routes through another processor rather than stopping at an email. And pricing is outcome-based, so FlyCode is paid only on incremental recovered revenue. ## What makes FlyCode different from standard retry logic? Standard retry logic is a schedule. FlyCode is a decision made per invoice. Instead of a fixed cadence, it dynamically adjusts retry timing, routing and messaging based on the failure reason (the decline code), payment metadata (issuer, card type and brand, country, amount, billing history) and customer behaviour (past payment dates and time-of-day patterns). An `insufficient_funds` decline on a debit card is retried around the customer's likely deposit date; a `do_not_honor` at 3 a.m. local time is retried in business hours; a hard decline is not retried at all and goes straight to a backup method. FlyCode also separates retries from emails. Standard tooling emails the customer at every failed attempt, which tells otherwise unaware customers there is a problem and pushes some of them to cancel. FlyCode holds messaging until silent recovery has been exhausted, then sends a specific, well-timed message. Its recovery models are strengthened by a partnership with Visa, which gives the engine network-level insight into how issuers respond. ## Why do the Visa, Mastercard and Stripe partnerships matter? Because recovery quality depends on data the merchant cannot see alone. Direct partnerships with Visa and Mastercard give FlyCode network insights and payment metadata about how issuers behave, which decline patterns resolve on retry and within what limits, and how card credential updates propagate. That data trains the models and keeps every retry inside the networks' retry rules, so recovery improves without risking excessive-retry fees or issuer penalties. FlyCode is a Visa Everything Award winner and a Mastercard network partner. The Stripe partnership matters for a different reason: FlyCode is a Stripe design partner and its app is verified on the Stripe App Marketplace, which means the integration is reviewed by Stripe, installs with standard Stripe permissions, and executes every retry and update through Stripe's own API, keeping Stripe as the system of record. ## Related * [FlyCode & Stripe](https://help.flycode.com/flycode-and-stripe) * [FlyCode vs. ProfitWell (Paddle Retain)](https://help.flycode.com/flycode-vs.-profitwell-paddle-retain) * [How FlyCode Makes Decline Codes Work for You](https://help.flycode.com/decline-codes-explained/how-flycode-makes-decline-codes-work-for-you) --- # 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/what-is-flycode/what-makes-flycode-different.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.