> 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/handling-failed-payments/when-and-how-payments-are-retried.md).

# When and How Payments Are Retried

How FlyCode decides when to retry a failed payment using per-merchant machine learning, what it does beyond retries (backup cards, anomaly detection, dunning orchestration, analytics), and how it opti

Retry timing is the single biggest lever in failed payment recovery. Retrying at the wrong moment burns one of the limited attempts the card networks allow and usually fails again; retrying at the right moment recovers the payment without the customer ever knowing. This page explains how FlyCode chooses that moment and what else it does when a retry is not the answer.

## How does FlyCode decide when to retry a payment?

FlyCode uses machine learning to find the best moment to retry each failed payment. A model trained on your own transaction history scores candidate retry windows for each failed invoice using the decline code, the issuing bank's historical behaviour, card type and brand, the customer's country and time zone, the amount, and the customer's past successful payment dates. An `insufficient_funds` decline is typically retried 2 to 5 days later around the customer's likely deposit cycle and in morning hours; a `do_not_honor` is retried at a different time of day 24 to 48 hours later; transient errors such as `issuer_not_available` are retried within hours. Every schedule stays within Visa and Mastercard limits on attempts per billing cycle.

The model is per merchant, so a B2B SaaS company billing corporate cards and a DTC brand billing consumer debit cards get different schedules, and it keeps learning from each outcome. Compared with fixed schedules this means fewer attempts per recovered invoice, faster recovery and a 16 to 25 percentage point higher recovery rate.

## Does FlyCode do more than simple retries?

Yes. Retries are the first step, not the whole product. When the primary card fails with a hard decline, FlyCode automatically charges an alternate card the customer already has on file. It sends coordinated communication (email and SMS) only when silent recovery has been exhausted. It detects revenue anomalies, such as subscriptions that still show as active while invoices go unpaid or are marked uncollectible. It orchestrates dunning flows so retries, messages and subscription status changes happen in the right order. And it surfaces granular analytics on decline codes, recovery by failure type, recovery speed and outreach performance that your finance and payments team can act on.

## How does FlyCode optimize billing workflows?

FlyCode tracks failures in real time as webhooks arrive from your processor, classifies each one, and adapts the recovery path to the specific issue: retry timing for soft declines, backup method or outreach for hard declines, immediate re-attempt for technical errors. Where more than one processor is available, it routes retries through the provider most likely to succeed for that card and country, then syncs the outcome back to your billing platform. Anomaly detection runs continuously, flagging invoices, proration events and refunds that would otherwise leak revenue. The dashboard gives instant visibility into what is working and what is not, so you can see recovery rate, revenue recovered against baseline and where failures are concentrated without exporting data.

## Related

* [How to Handle the Most Common Declines](https://help.flycode.com/decline-codes-explained/how-to-handle-the-most-common-declines)
* [Backup Payment Methods](https://help.flycode.com/backup-payment-methods)
* [Payment Orchestration Agent](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 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/handling-failed-payments/when-and-how-payments-are-retried.md?ask=<question>&goal=<user_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.