RecoverRetry scheduling
Reflects the code as of 28 July 2026. If the product changes and this page does not, that is a bug worth emailing about.
The schedule depends on the decline reason. There is no single interval that suits a customer who is short until payday and a customer whose card processor glitched.
The schedule
| Decline reason | When we try again |
|---|---|
insufficient_funds | The next payday, meaning the 1st or 15th, at 10:00. Then the day after that payday, then the following payday. |
processing_error | Two hours later. This is a transient technical failure, not a decision about the customer. |
expired_card, incorrect_cvc | Never. These go to the card-update path instead. |
| Everything else retryable | Six hours, then two days, then five days. |
The six hour first step is deliberately not a round number of days: it lands the retry at a different time of day from the original failure, which is free to do and occasionally matters.
The caps
- Four attempts maximum per invoice.
- Fourteen days maximum from the first failure. An attempt that would land outside the window is not scheduled at all.
- One pending attempt at a time. A retry that fails re-triggers
invoice.payment_failed, so without this guard a case could stack duplicate attempts against itself.
The decline code from the most recent attempt decides whether there is a next one. A case that starts recoverable and becomes a hard decline stops there rather than running out its remaining attempts.
How these intervals were chosen
Reasoning, not measurement. Aiming insufficient_funds at the 1st and 15th is a bet that balances are most likely to have been topped up around then. Spreading attempts across different times of day is a bet that a bank declining at one hour may approve at another.
We have no recovery data of our own yet, and the published "best time to retry" figures are vendor sourced and not something we would print. So these are starting points that will be revisited when there is enough real outcome data to test them, and this page will say so when that happens.
Worth knowing: Stripe's own Smart Retries picks attempt timing with a model trained across the whole Stripe network, which is more data than RecoverFlow will have for a long time. If retry timing is the only thing you care about, Stripe's free version is a reasonable choice and the comparison page says so.
Common questions
How many times will RecoverFlow retry a failed payment?
Up to four attempts per invoice, and never more than fourteen days after the first failure. Attempts that would fall outside that window are not scheduled.
When does RecoverFlow retry an insufficient_funds decline?
On the next payday, meaning the 1st or 15th of the month, at 10:00, then the day after, then the following payday. The reasoning is that balances are most likely to have been topped up around those dates.
Are these retry timings based on measured results?
No, and we would rather say so. They are reasoned starting points. RecoverFlow has no recovery data of its own yet, and the published industry figures on retry timing are vendor sourced, so nothing here is tuned against a benchmark we would be willing to publish.
What if the decline reason changes between attempts?
The most recent decline code decides what happens next. A case that starts as insufficient_funds and later returns lost_card stops being retried at that point.