Resources

Smart Retries: How Payment Retry Logic Wins Revenue

Smart retries are retries with a reason. When a subscription payment fails, a smart retry system reads why it failed, picks a moment when that reason is most likely to have cleared, tries again only if trying makes sense, and stops before extra attempts hurt the customer relationship or the card's standing with its bank. That is the whole idea behind payment retry logic — and it is the difference between recovering a payment and simply repeating it.

Most failed payments are not lost customers. They are good customers whose card hit a temporary problem at a bad moment. Smart retries treat each failure as information; dumb retries treat every failure the same. This guide explains how the logic works, what Stripe Smart Retries do and where they stop, and what a dedicated layer adds.

What smart retries are

A retry is a second attempt to collect the same payment on the same card. A smart retry is a retry that is conditional — conditional on the decline code, on timing, and on what has changed since the last attempt.

Three questions define whether a retry is smart. First, should this payment be retried at all? Some failures can never succeed on the same card, and retrying them wastes attempts and creates noise. Second, if it should be retried, when? A retry fired before anything has changed is likely to fail for the same reason. Third, when should the system stop? Every sequence needs a ceiling and a stopping rule decided in advance, not improvised after the fifth failure.

How smart retry logic works

Smart retry logic runs in a loop: read the failure, choose a branch, wait for a better moment, attempt, then decide again. Timing without a decline-code read is guesswork. Attempts without stop rules become harassment of a card that cannot pay.

1. The decline code reads the failure

Every failed payment returns a reason, expressed as a decline code. That code is the single most useful fact in recovery, because it separates failures into three practical groups.

The first group should never be retried on the same card: hard declines, where the card itself is the problem — expired, lost, stolen, or closed. Only a new card fixes those. Retrying a hard decline does not create a second chance; it creates a second failure.

The second group is worth retrying on a timed schedule: soft declines, where the failure is temporary. The most common example is insufficient funds, where the money was not in the account at the moment the charge arrived. Bank-side processing issues that may clear belong here too.

The third group needs the customer before another attempt: cases where the bank wants the cardholder to approve the charge, call the bank, or clear a block. Another blind retry does not solve that. A clear message does.

A system that ignores the code will always underperform one that branches on it. The code sets the branch, and everything else — timing, messaging, stopping — follows from that branch.

2. Timing picks the moment

For soft declines, when you retry matters at least as much as how often. The clearest case is insufficient funds. According to Churnkey's published analysis of Stripe data, across 5.4M failed payments, insufficient funds is the largest decline category at 40.6%. That failure is a statement about a moment, not about the customer: the money was not there when the charge arrived. It may well be there after the next deposit.

Good timing therefore thinks in terms of pay cycles, described honestly as tendencies rather than certainties. Attempts spaced to give a pay cycle a chance to turn over stand a better chance than attempts clustered in the first days, when nothing has had time to change. A schedule spread across genuinely different moments samples different conditions; one that only retries on the same weekday keeps sampling the same point in the customer's financial week.

The discipline can be stated simply: each retry should have a reason to succeed that the previous attempt did not have. Time has passed. A pay cycle has turned. The card has been updated. The customer has cleared a block with their bank. A retry with no new reason is just noise, and banks notice noise. For a deeper look at choosing that moment, see our guide to when to retry failed payments.

3. Attempt ceilings set the limit

Every smart retry sequence has a defined maximum number of attempts per failed payment. The ceiling is not one number for every failure. Soft declines justify a small set of spaced attempts inside a defined window. Hard declines justify none at all on the same card. Customer-action cases justify an attempt promptly after the customer acts — for example, right after a card update — because the thing that was broken has been fixed.

Ceilings protect the customer from a stream of unexpected charges, protect your standing with banks and networks that watch for repeated attempts on failing cards, and protect the economics: beyond a sensible ceiling, extra attempts add failures and complaints faster than recoveries.

4. Stop rules end the sequence

A ceiling is a number. A stop rule is a decision. Smart systems use both.

• Immediate stops. Some responses end the sequence on the spot regardless of attempts remaining — above all, any signal that the card is gone for good.
• Success stops. The moment an attempt succeeds, every remaining scheduled attempt and message for that failure cancels. Double-charging a saved customer because a queue was not cleared turns a recovery into a refund and a complaint.
• Customer-action stops. Where the branch requires a new card or a bank approval, the retry clock pauses until the customer acts. The next attempt follows the fix, not the calendar.
• A time boundary. Attempts and outreach share one recovery window with a real end date — the date the customer was told the subscription would pause or lapse if payment is not fixed.

The question to ask of any system is not just "how many retries?" It is "how many retries, for which codes, over what window, stopping when?" Our retry schedule matrix lays out that policy view — branch, timing, and stop rule side by side — so you can compare systems on logic rather than slogans.

Dumb retries vs smart retries

Most older retry setups are fixed schedules: every failed payment is retried on the same preset rhythm — a set number of attempts spaced a set number of days apart, regardless of why the payment failed. Fixed schedules are simple to build and easy to explain. Their defect is just as simple: they spend attempts where attempts cannot work and stop on a calendar whether or not the underlying problem has changed.

Decision	Dumb / fixed retries	Smart retries
Whether to retry	Retry everything the same way	Branch on the decline code; hard declines are never retried
When to retry	Same spacing for every failure	Spacing aligned to the failure type and to pay cycles
How many attempts	One cap applied blindly, or no clear cap	A ceiling set per branch, inside a defined window
When to stop	When the schedule runs out	On success, on a hard stop signal, or when the customer must act first
Role of outreach	Emails sent on a separate, uncoordinated track	Emails and SMS coordinated with attempts, so each supports the other

An adaptive schedule changes the plan based on what is known. An insufficient-funds decline earns patient, spaced-out attempts aligned to when money is likely to be in the account. A temporary decline might earn a sooner retry. An expired card earns no retries until it is updated — at which point a prompt attempt makes sense. More attempts are not smarter attempts: our piece on why aggressive retries backfire covers the cost of treating volume as a strategy.

Stripe Smart Retries, specifically

Stripe calls its broader system Revenue Recovery, and Smart Retries are the retry part of it: they use network and transaction signals to pick retry times. Revenue Recovery adds emails and a hosted payment-update page in the Stripe Dashboard. For a business billing only through Stripe, that is a real, included starting layer — free with Stripe and far better than retrying on hope.

The published numbers give that layer a fair benchmark. According to Churnkey's published analysis of Stripe data, Stripe Smart Retries alone recover about 51% of failed payments, and layered precision retries reach about 55%. The native engine does the heavy lifting; the layering — code-aware branching and coordinated outreach — is where the additional recovery comes from. The same source notes that each additional dunning email touch adds roughly 1–2 points of recovery, which is why messages are part of the logic, not decoration.

Our dedicated explainer on Stripe Smart Retries walks through the native feature in detail. The short version for this page is: know what Stripe already does for you before you judge what anything else adds.

Where Stripe Smart Retries stop

These are not criticisms of Stripe. They are the boundaries of a native, single-platform feature — where a cross-platform business feels the gap.

• Stripe-only scope. Smart Retries work inside Stripe Billing. If you also bill through another platform — or you migrated, or different product lines sit on different systems — the native view covers only the Stripe slice. There is no cross-platform picture of failed payments, attempts, and recoveries in one place.
• No decline-code playbook you control. You get Stripe's timing decisions, not a branch-by-branch policy you set and adjust per decline type. For a business whose failures cluster in one category, that is the limit.
• Email-centric outreach. Revenue Recovery's outreach is centred on email and a hosted update page. A sequence that also needs SMS in the same flow, branded dunning emails, and a branded card-update page asks for more than the native layer is designed to provide.
• Nothing for the off-Stripe backlog in the same system. Failed payments sitting in another system still need the same discipline — code-aware retries, timed attempts, and outreach — under one policy.

If you bill only through Stripe and email-only outreach fits your customers, the native layer may be enough. The test is not whether Smart Retries are good — by the published figures, they are — but whether their boundaries match your business.

What a dedicated layer adds

A dedicated layer widens that system in four ways.

First, one policy across platforms. The same branches, ceilings, and stop rules apply wherever the subscription lives, so you can measure recovery in one place instead of stitching together separate platform reports.

Second, outreach coordinated with attempts. Even well-timed retries have a ceiling, because a retry can only re-present the same card. For many failures, something has to change first — a new card, a bank block lifted, an approval given — and only the customer can change it. That is why retry logic has to be coordinated with outreach: branded dunning emails and SMS between attempts, each carrying one secure link to a branded card-update page. Coordination also means honesty: if the email says no further attempts will be made until the card is updated, the retry engine has to mean it.

Third, coordination with native retries. Two uncoordinated systems working the same payment can attempt on the same day and send conflicting messages. A layered system coordinates with native retries so the same payment is never double-retried. Verify it: run one test subscription to failure and list every attempt and message in order. If it surprises you, coordination is not finished.

Fourth, the backlog, not just the next failure. A system that only works tomorrow's failures leaves money already sitting in past failures untouched. Working the existing backlog on connect separates a retry feature from a recovery programme.

How to judge any smart retry system

Judge every option by the same five questions. Does it branch on decline codes? Can it explain its timing in plain sentences? Does it state its ceiling per branch and its window? Does it stop on a hard signal and cancel everything on success? And is outreach coordinated with attempts, or running on a separate track?

Our comparison of the best smart retry tools applies those questions across the field: this page is the logic, that page is the shopping list.

How Swipe Again applies this logic

Swipe Again is failed-payment recovery software built for subscription businesses. Its retries are decline-code-aware smart retries: up to 6 attempts over about 16 days, scheduled by why the payment failed, and hard declines are never retried — those go straight to a new-card request through its branded card-update pages. Branded dunning emails and SMS run in the same sequence, so attempts and outreach follow one policy instead of racing each other.

On connect, a 90-day backfill works your existing backlog of failed payments, not just the next ones. Cancel deflection with Discount, Pause, and Service offers is included in the same price. Swipe Again connects to Stripe, Recharge, Seal Subscriptions, Skio, Loop Subscriptions, Chargebee, Recurly, Braintree, and Paddle. It is priced at $179/mo flat ($1,799/yr), with no percentage of recovered revenue and no MRR tiers, and starts with a 14-day trial, card upfront, self-serve, with connect in about 2 minutes. The guarantee is: Recover $179 in 30 days, guaranteed — or Swipe Again is free the next 30 days.

The bottom line

Smart retries are not a secret algorithm. They are disciplined decisions, in the right order. Read the decline code before you touch the calendar. Never retry a card that cannot succeed. Space soft-decline attempts across moments that are actually different, aligned to pay cycles. Cap the attempts, stop when there is a reason to stop, and let outreach handle cases only a customer can fix. Stripe Smart Retries give Stripe-only businesses a strong included start — about 51% recovery on the published analysis — and a dedicated layer adds cross-platform policy, coordinated email and SMS, and backlog work. That is how retry logic wins revenue: not by trying harder, but by trying only when trying makes sense.

Frequently asked questions

What are smart retries?

Smart retries are conditional retries of a failed payment. The system reads the decline code, retries only failures that can succeed on the same card, times the attempt for a moment when the original problem is more likely to have cleared, applies an attempt ceiling, and stops on success or on any signal that the card cannot pay.

How many times should a failed payment be retried?

There is no single right number independent of the decline code. Soft declines justify a small set of spaced attempts inside a defined window, while hard declines justify none at all on the same card. What matters is that the cap is set in advance and differs by failure type. Swipe Again, for example, uses up to 6 attempts over about 16 days for failures where retrying makes sense.

What do Stripe Smart Retries do, and what do they not do?

Stripe Smart Retries use network and transaction signals to pick retry times inside Stripe Billing, and Stripe Revenue Recovery adds emails and a hosted payment-update page. They do not provide a cross-platform view of failed payments, a decline-code playbook you control branch by branch, or a coordinated sequence across platforms outside Stripe.

Why does retry timing matter so much?

Because the most common soft declines describe a moment, not a permanent state. An account that was short on the day of the charge may be funded after the next deposit, so attempts spread across different points in the pay cycle, the week, and the day sample genuinely different conditions. Clustered retries mostly repeat the same conditions without adding new chances to succeed.

Can retry logic alone recover a failed payment?

Only when nothing about the card needs to change. Retries re-present the same card, so they can succeed when a temporary condition clears, such as funds arriving. They cannot fix an expired, lost, or replaced card, or lift a bank block. Those cases need the customer, reached through a clear email or SMS with one secure update link.