Smart retries

Smart retries is a dunning technique that reattempts a failed subscription payment at times and intervals chosen to give each attempt the best chance of succeeding, instead of retrying on a fixed, uniform schedule. Rather than charging again at the same hour every day, the system varies when it tries based on signals such as the reason the payment failed and past patterns of when similar payments recover.

When a recurring charge is declined, the card may be fine and the failure temporary, for example a momentary hold, an over-limit balance that clears at payday, or a network timeout. Smart retries aim to catch those recoverable failures by timing later attempts more intelligently. A subscription platform can run this retry logic automatically as part of its failed-payment recovery flow. In Recurly, the timing model, the number of attempts, and the recovery rates are driven by machine learning trained on billions of transactions across more than 2,000 merchants. Retries are timed dynamically for each individual failure rather than on a fixed schedule, capped at a maximum of 20 transaction attempts per invoice or 60 days from invoice creation, whichever comes first, and recover up to 70% of failed payments

Why smart retries matter for subscription businesses

Failed payments are one of the largest sources of involuntary churn, where a customer leaves not because they chose to but because a renewal charge did not go through. Every payment that recovers on retry is revenue kept and a subscriber retained without any new acquisition cost.

A fixed retry schedule treats every decline the same and often fires at times that are unlikely to work. Smart retries improve on that by:

• Timing attempts to when a card is more likely to have funds or clear a temporary hold.

• Adjusting the approach to the decline reason instead of blindly repeating the same charge.

• Spacing attempts to avoid triggering issuer flags from repeated identical tries.

The revenue this recovers depends on the business, the payment mix, and the customer base, and any recovery figure is an estimate that varies by merchant. Recurly's published benchmarks cite recovering up to 70% of failed payments through intelligent retries, and one documented analysis saw recovery rates improve from about 53% to about 71% on the same set of transactions.

How smart retries work

Smart retries sit inside the broader dunning process that manages a failed payment from first decline to either recovery or cancellation. A typical flow runs like this:

1. A recurring charge is declined and the subscription enters a past-due or dunning state.

2. The system reads the decline response to judge whether the failure looks recoverable.

3. Later attempts are scheduled at varied times rather than a fixed daily slot.

4. Each retry runs automatically, and a success clears the past-due state and keeps the subscription active.

5. Dunning notifications can prompt the customer to update a card if attempts keep failing.

6. If no attempt succeeds within the configured window, the subscription follows its end-of-dunning rule.

Recurly's retry logic uses a dynamic, non-fixed timing model to optimize recovery. Our ML engine determines the optimal retry window for each transaction based on decline codes, card types, payment history, and network data. This timing is not configurable and operates within your defined dunning window. We perform a maximum of 20 transaction attempts per invoice to push to the absolute limits permitted by card networks. For businesses that require deeper reach and have a higher tolerance for risk, we also offer an 'Aggressive' retry strategy upon request, which is intended for merchants who understand the potential for increased network penalties and issuer flagging.

Benefits and examples

Smart retries help a subscription business recover revenue that would otherwise be lost to involuntary churn, and they do it in the background without asking the customer to act. The main benefits are:

• More recovered payments than a fixed schedule, because attempts are timed to when they are likely to work.

• Less involuntary churn, since subscribers with a temporary payment issue are kept rather than cancelled.

• Fewer wasted retries and issuer flags, because attempts are spaced and reason-aware.

As an illustrative scenario, imagine a monthly subscriber whose renewal is declined because the card is briefly over its limit. A fixed schedule might retry at the same time each morning and fail again. A smart retry waits and attempts later, after the balance clears, and the charge goes through, keeping the subscription active with no action from the customer. This example is hypothetical and not a measured result.

Frequently asked questions

What is the difference between smart retries and a fixed retry schedule? A fixed schedule retries a failed payment at set intervals regardless of context. Smart retries vary the timing of each attempt using signals such as the decline reason and historical recovery patterns, which generally recovers more payments.

Do smart retries help with voluntary or involuntary churn? They target involuntary churn, which happens when a renewal payment fails rather than when a customer actively cancels. Recovering those failed payments keeps subscribers who never intended to leave.

How many times will a payment be retried? Recurly's standard retry model is built to push to the absolute limits permitted by card networks. This includes up to a maximum of 20 transaction attempts per invoice which ensures you maximize revenue recovery while maintaining account health. For businesses that require deeper reach and have a higher tolerance for risk, we also offer an 'Aggressive' retry strategy. This configuration is available for merchants who fully understand and accept the potential trade-offs regarding network penalties and issuer flagging.

Do customers know a smart retry is happening? Retries run in the background, and the customer usually only hears from you through dunning notifications that ask them to update payment details if attempts keep failing.