Smart Retry Logic for Failed Payments: How to Time Your Dunning Retries to Maximize Recovery

Smart retry is a payment retry system that picks the best time to reattempt a failed subscription charge. It reads the decline code, the customer's billing history, and card network signals to set that timing.

That targeting recovers more revenue than a fixed-day schedule, because it stops retrying cards that won't succeed and saves attempts for the windows when they will.

The businesses we've helped that recover the most aren't running the most aggressive schedules. They classify why the card failed before timing the next attempt. Get that order right and you cut involuntary churn without tripping a card network fine.

Key takeaways

• Classify every decline code before you retry, because the code decides the path.
• Retry soft declines and never retry a hard decline like a stolen card.
• Time the first retry 48 to 72 hours out, after the next payday.
• Cap soft-decline retries at 4 to 5, the first attempt clears 35%.
• Recover 40 to 50% of soft declines within the first two attempts.
• Hand off to account updater, a card-update email, or a churn flag.

What is smart retry, and how does it differ from a fixed-day dunning schedule?

Smart retry sets each retry from the decline code, the billing cadence, and network signals, while a fixed-day schedule uses one offset for every failure.

Stripe brands its version Smart Retries (older docs may call it Adaptive Acceptance). Recurly calls its version Intelligent Retries.

The difference is one extra step. A fixed schedule retries on day 3, day 7, and day 14 for every charge. It treats an insufficient-funds blip the same as a stolen-card report. Smart retry runs each failure through a decision first, because the right move depends on why the card was declined.

So you retry a temporary decline, timed to the next likely payday, and you never retry a permanent one.

Getting that order right is what matters, and the rest of this guide covers it. Smart retry only beats a fixed schedule on soft declines, the temporary failures the network lets you reattempt.

On a hard decline, like a stolen card or a closed account, no schedule recovers the charge. The right move there is to stop and ask for a new card, which is the hard declines path.

Why your platform's smart retry defaults aren't enough

Platform smart retry tunes timing inside its own network, but it won't give you the controls your own failure mix needs. You can't pick which decline codes to stop on, treat a bank transfer differently from a card, or hand a charge to a human. Stripe's Smart Retries and Recurly's Intelligent Retries are no exception.

The platform tunes timing across all its merchants at once.

Stripe earns back $9 in recovered revenue for every $1 a business spends on Billing, and that model is strong on the aggregate. But it optimizes for Stripe's whole pool, where your subscribers and payment methods are only a sliver.

Picture a fictional company, Clearpath Analytics, a $79-a-month B2B project-management tool with 1,800 monthly subscribers on Stripe.

At about 0.8% involuntary churn rate, Clearpath sees roughly 14 to 15 failed payments a month. Stripe's docs put the default at 8 retries over 2 weeks, and its model times those eight attempts well.

But it won't tell Clearpath to stop after one attempt on a stolen-card code, or hold a failed bank transfer for three days. Those calls are yours.

There's a real exception, though. If you run one payment method, see fewer than about five failures a month, and do no B2B invoicing, the defaults are fine. Taking control pays off once you see enough failures to spot a pattern.

The Smart Retry Decision Framework

The Smart Retry Decision Framework routes every failed charge through four steps, Classify, Time, Sequence, and Hand Off, before a single retry runs. You can't reorder them, because each step decides one thing the next step needs:

1. Classify decides whether a retry is even allowed.
2. Time sets the delay window that gives the charge its best chance.
3. Sequence caps the total attempts and spaces them inside card network rules.
4. Hand Off routes the charge to the right recovery path once retries run out.

The four steps below walk through each one in order.

Step 1: classify the decline code

Every decline code lands in one of three buckets, retry now, retry after a delay, or stop and never retry. The bucket, not the calendar, decides what happens to the charge.

The split follows the card network's response code. Codes like 51 (insufficient funds) and 65 (soft decline, exceeds limit) are temporary, so they go in the delay-and-retry bucket.

The permanent stops are 04, 41, 43, and 57 — lost card, stolen card, pickup card, transaction not permitted.

Stripe won't even attempt the permanent ones. Its docs lists:

• incorrect number
• Lost card
• Stolen card
• Pickup card
• Revocation of authorization
• Transaction not allowed

Retrying one of these costs you real money. A single retry on a Visa never-approve code triggers a per-retry fee from the first attempt onward. The hard-decline breakdown covers how those fees work.

A few codes are ambiguous across networks. Code 05, "Do Not Honor," is soft on some issuers and hard on others. When your platform doesn't pass through a clear network signal, treat code 05 as delay-and-retry, cap it at three attempts, then reclassify it as a stop.

That way you don't abandon a recoverable charge or keep chasing a dead one.

Step 2: set timing windows by billing cadence and payment method

Retry timing should change with the billing cadence and the payment method. A monthly card failure, an annual card failure, and a bank-transfer failure each call for a different first-retry window.

The windows differ because each customer's money moves on a different clock. Monthly subscribers get paid around the 1st and the 15th. A retry timed 48 to 72 hours after the failure often lands after the next paycheck.

A rigid day-3 retry can land mid-cycle, when the account is still empty.

Annual subscribers fail once a year for a much larger charge, so a 72-hour wait gives the cardholder room to fix the problem first. Bank transfers like ACH and SEPA fail on the bank's slower clock.

They need a three-day minimum hold before a second attempt, because retrying them faster only gets the same rejection.

Clearpath's monthly subscribers show the pattern. Take a code-51 failure on a $79 monthly charge:

An annual Clearpath subscriber on the same code gets a different shape. The first retry comes at 72 hours, the second at day 7, and then you stop. Annual failures are rarer and the charge is larger, so a careless extra retry risks a fraud flag more than a repeated monthly charge does.

Tuning the timing earns its keep once you clear roughly 20 failures a month. Below that, the spread is too thin to read a pattern, and the platform default will do.

Step 3: cap and space the sequence

For soft declines, cap the total at 4 to 5 retries across a 15-day window. Past the fifth attempt, the next recovery is worth less than the processing fees and the cost of another failed-charge notice. The cap protects both your margin and your sender reputation.

The recovery curve is front-loaded. The first retry wins back the largest share of recoverable charges, and each later attempt returns less than the one before.

Spacing the attempts also keeps you under the card networks' reattempt limits. Visa caps reattempts at 15 over 30 days, and Mastercard sets its own thresholds. Stay well inside both, and the excessive-retry fees never start.

For Clearpath's code-51 monthly subscriber, the full sequence runs four attempts and then stops:

• Attempt 1 at 48 hours, the highest-recovery window
• Attempt 2 at 5 days
• Attempt 3 at 10 days
• Attempt 4 at 14 days

The recovery curve is front-loaded. Most soft-decline failures that will ever recover do so in the first two attempts, with each later attempt adding less than the one before. The cap is there because more attempts past that point cost more than they recover.

The benchmarks section below shows the attempt-by-attempt picture.

The 4-to-5 cap assumes card payments on monthly billing. For annual plans, cap at 2 to 3 attempts instead, because the larger charge carries more dispute risk every time it declines again.

Step 4: hand off when retries are exhausted

When the sequence ends without recovery, the charge routes to one of three hand-off paths. Which path depends on who has to act, the network or the customer:

• Account updater: refreshes a stored card on its own when it expires or is reissued.
• Manual card-update email: asks the customer to enter a new card themselves.
• Hard stop and churn flag: sends a fraud or closed-account decline straight to dunning.

Account updater is the first choice for expiry failures, and it should run before the retry sequence starts. A manual email covers the cases where only the customer can fix the card.

Clearpath's failures land at two ends of the spectrum.

An expired-card failure on a monthly subscriber goes to account updater first. If that resolves the card within 24 hours, no retry is needed. Otherwise the charge routes to a card-update email, then to a churn flag when the customer doesn't act within 7 days.

A stolen-card failure skips all of that. It's a hard stop on the first attempt, with no updater and no retry, straight to the dunning sequence on day one. (The specific network codes behind each failure type are homed in the card decline codes article.)

Account updater only works on card-on-file credentials. Bank transfers like ACH, SEPA, and BECS have no equivalent, so a manual outreach email is the only hand-off path open to them.

Recovery rate benchmarks: what to measure

Against a well-tuned sequence, your first two attempts should win back 40 to 50% of soft-decline failures, according to Churn.io's retry sequencer data. Well-run dunning recovers most at-risk subscribers overall.

Track the rate attempt by attempt, because the per-attempt numbers tell you whether your timing is right. The platform-level benchmarks for native vs. dedicated dunning software are homed in the dunning management software article.

Why measure it attempt by attempt rather than as one blended number?

Because the curve drops sharply after the first retry, and a single recovery percentage hides where you're losing money. The attempt-level view shows exactly which attempt starts losing recoverable charges, and a blended total never can.

For a sense of the wider picture, Recurly reported a 96% renewal invoice paid rate across its 2023 data. That's the share of renewal invoices that end up paid in their final state. The dunning playbook breaks the recovery rate down per attempt and overall.

These figures are for soft declines on card payments. Hard-decline recovery runs structurally lower, because the fix there is a new credential, and better retry timing can't change that.

What to do when retries run out

When the retry sequence is spent, the charge moves on to the dunning email sequence and then a win-back campaign. That revenue isn't lost yet, it just needs a different recovery path.

Retries only recover involuntary churn, the payments that fail without the customer choosing to leave, which is the voluntary vs involuntary churn line. The emails are the human layer that picks up where the automation stops.

This is one of four stages in involuntary churn recovery. The automated retries do what timing and classification can do. The dunning email sequence and win-back handle the recovery that needs a person to read a message and act.

The hand-off is a hard stop you must honor. Run automated retries past the point where the smart retry sequence ends, and that's exactly where excessive-retry fees pile up and dispute rates climb. Once you're out of attempts, the dunning emails take over.

Use the churn rate calculator to size the revenue at risk from failed payments before you tune your sequence.

FAQ

Does smart retry work differently for annual subscribers than monthly subscribers?

Yes, annual plans use a longer first-retry window and a lower cap, 2 to 3 retries against the 4 to 5 on monthly. The larger annual charge carries more dispute risk on each repeated decline, so you trade retry volume for caution.

Can I use smart retry on ACH and SEPA payments, or only card-on-file charges?

You can retry ACH and SEPA failures, but they follow bank-transfer timing and need a three-day minimum hold before retrying. They also have no account updater equivalent, so a card-on-file recovery path won't apply to them.

What happens to my dispute rate if I retry a hard decline?

Retrying a hard decline like a stolen-card or revoked-authorization code pushes your dispute rate up, because you're re-charging a card the cardholder already flagged. Each reattempt also risks a per-retry network fee on never-approve codes, so the cost lands twice.

How do I know if my billing platform's smart retry is actually working, or if I need a third-party tool?

Watch your attempt-level recovery rate, a well-tuned sequence recovers 40-50% within two attempts according to Churn.io's retry sequencer data. If you're below that, or you run several payment methods plus B2B invoicing, you're leaving money behind with the defaults.