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
Last updated
Was this helpful?