Retry schedule

A retry schedule is the set of rules that governs when and how a subscription business reattempts a failed recurring payment. It defines how many times to retry a declined charge, how long to wait between attempts, and when to stop, so that recoverable failures are collected without excessive attempts.

Recurring payments fail for many reasons, and a large share of those failures are temporary: an account that lacks funds today, a card that was momentarily flagged, or an issuer that declined a first attempt it would approve later. A retry schedule exists to capture those recoverable payments by trying again at sensible intervals rather than treating the first decline as final. A subscription platform runs retries automatically against configured rules, and some platforms adapt the timing to the decline reason or to patterns in when payments succeed. Recurly does both, and offers several retry approaches that range from a machine learning engine to fixed, rule-based schedules.

Why a retry schedule matters for subscription businesses

Failed payments are a leading cause of involuntary churn, revenue lost not because a customer chose to leave but because a charge did not go through. A well-designed retry schedule recovers a meaningful portion of that revenue automatically, before dunning outreach or cancellation ever come into play. The difference between a naive schedule and a considered one shows up directly in retained revenue.

The design also has to balance recovery against cost and customer experience. Retrying too often or too aggressively can trigger fees, irritate customers with repeated notifications, and in some cases draw scrutiny from card networks. Retrying too little leaves recoverable revenue on the table. The goal is a schedule that captures the temporary failures without punishing the customer or the business.

How to use a retry schedule

Key decisions when setting up a retry schedule include:

• Number of attempts: how many retries before the invoice is treated as failed.

• Interval and spacing: how long to wait between attempts, often widening the gaps so later tries land when funds or issuer conditions may have changed.

• Timing by method: bank-based methods like ACH settle and return more slowly than cards, so their retries need longer gaps.

• Coordination with dunning: aligning retries with customer emails so people can update details between attempts.

• Terminal rule: what happens when retries are exhausted, such as suspension or cancellation.

Where a platform supports it, retry timing can be adapted to the specific decline reason, since a temporary insufficient-funds decline calls for a different pattern than a do-not-honor response — and Recurly does this via Intelligent Retries, its ML-powered engine that factors in the decline reason, payment type, card issuer, and historical success patterns to determine the optimal retry window per transaction. Static retries also vary cadence by gateway error type — for example, "Try Again" errors retry every 2 days, while communication errors follow an escalating schedule starting 4 hours apart.

Recurly offers several retry approaches:

• Intelligent Retries: a machine learning engine, available across products, that sets the optimal retry window for each failed charge from the decline reason, payment type, card issuer, and historical success patterns.

• Static Retries: uses gateway signals and decline or merchant advice codes to schedule retries on fixed cadences by error type, without machine learning. For example, "Try Again" errors retry every 2 days, while communication errors follow an escalating schedule that starts 4 hours apart.

• Custom Retries: merchant-configured fixed schedules, such as a standard 5 retries every 2 days, retry after failed billing, or retry before next billing.

• Direct Debit Retries, for ACH, SEPA, BACS, and BECS: regulation-compliant, with up to 2 retries at a fixed 24-hour interval after an insufficient-funds failure.

Benefits and examples

A considered retry schedule can:

• Recover revenue from temporary payment failures without any manual work.

• Reduce involuntary churn by resolving declines before they end a subscription.

• Limit fees and customer annoyance by spacing attempts rather than repeating them quickly.

• Work with dunning so customers who need to act get a clear prompt between attempts.

As an illustration, a business might retry a declined card three times over about two weeks, widening the gap between each attempt, while sending a payment-update email after the first failure. Many charges that fail once succeed on a later attempt once the issuer or the account balance changes. This example is illustrative and not tied to any specific recovery result.

Frequently asked questions

What is a retry schedule in subscription billing? It is the set of rules that decides when and how many times to reattempt a failed recurring payment, and when to stop. Its purpose is to recover payments that failed for temporary reasons.

How many times should a failed payment be retried? There is no single right number; it depends on the payment method, the decline reason, and the cost of each attempt. The aim is enough attempts, spaced sensibly, to catch temporary failures without incurring unnecessary fees or annoying the customer. In Recurly, Intelligent Retries caps attempts at 20 per 30-day period, Direct Debit methods are limited to 2 retries by regulation, and hard declines are generally not retried at all.

What is the difference between a retry schedule and dunning? A retry schedule is the automated reattempting of the charge. Dunning is the customer-facing communication, such as emails asking the customer to update their payment details. They work together: retries try to collect, dunning prompts the customer to act.

Should retry timing differ by payment method? Yes. Bank-based methods such as ACH and direct debit settle and return more slowly than cards, so retries for those methods generally need longer gaps between attempts to be effective.