Failed payment recovery for Shopify subscriptions

A subscriber whose card declined did not decide to leave. Nobody weighed up the product, read a competitor’s landing page and chose to stop. An issuer returned a code, your subscription platform marked the charge as failed, and somewhere between three and thirty days later the subscription was cancelled by a rule nobody has looked at since the day it was switched on.

Subscription businesses lose an average of around 9% of recurring revenue to failed payments (Baremetrics), and between 20% and 40% of all churn is involuntary (Paddle / ProfitWell) — caused by the payment rather than by the customer. On a brand doing $500,000 a month in subscription revenue, the first figure alone is roughly $45,000 a month moving through a process most teams have never audited once.

This guide is the whole build. Why payments fail, what a complete recovery system contains, how to construct it on Shopify with Recharge, Skio, Smartrr or Stay AI underneath it, what to measure afterwards, and the mistakes that cost the most. It is written for the person who intends to actually build the thing, so it names objects and settings rather than principles. If you would rather have someone build it, that is what we do.

Why do subscription payments fail?

Most failed subscription payments are not fraud, and they are not a customer who has run out of money. They are a card that changed.

Six things account for the overwhelming majority of declines on a recurring charge:

• The card expired. Entirely predictable, and entirely preventable, because you already hold the expiry date.
• The card was reissued. Lost, stolen, or replaced after the issuer’s own breach response. The number changes; nobody tells you.
• The issuer declined a merchant-initiated transaction on risk grounds. Recurring charges are scored differently from a customer sitting at a checkout. A card that works in a shop can decline for you.
• There was not enough money in the account at the moment you charged. Which is a timing problem, not a customer problem.
• Strong Customer Authentication. In the UK and EU, an issuer can soft-decline a recurring charge and demand the cardholder authenticate. No amount of retrying satisfies that: the customer has to be present.
• Address or security-code mismatch. Usually a customer who moved.

Soft declines and hard declines

This is the distinction the entire system turns on.

A soft decline is temporary. Insufficient funds, a processing error, an issuer that was unreachable, a generic risk decline. The same card may well work in two days. Retrying is correct.

A hard decline is final. Lost card, stolen card, pick-up card, closed account, a card the issuer has blocked for this transaction type. The same card will never work again. Retrying it will not succeed, and at volume it adds processor cost and drags on your authorization rate.

Your gateway returns both an outcome and a reason. In Stripe’s vocabulary those are values like insufficient_funds, do_not_honor, expired_card, lost_card and transaction_not_allowed; other processors have their own list with the same shape. That reason field is the most valuable piece of data in the whole system, and almost no default dunning configuration reads it. Every subscriber gets the same four retries and the same three emails whether their card bounced for $12 they will have on Friday or was cancelled by the bank last month.

What you can actually do about each reason

What does a complete recovery system look like?

Five layers, in order of leverage. Most brands have two of them, half-built.

1 — Prevention. Everything that stops the charge failing in the first place: card-expiry warnings sent before the renewal date, an account updater catching reissued cards silently, and a checkout that captures a card in a way your gateway can re-authenticate later. Prevention is the cheapest layer and the one almost nobody builds, because it is invisible when it works.

2 — Retry logic. The schedule and the intelligence behind it. How many attempts, how far apart, at what time of day, and — the part that separates a real system from a default — routed by decline reason so a hard decline stops immediately and a funds problem waits for the weekend.

3 — Dunning communications. Four to six touches across email and SMS, written to be useful rather than threatening, each with a single job: get the customer to a page where they can put in a new card. This is the layer most brands think is the system.

4 — Self-serve recovery. A payment-update page that loads fast, works on a phone, does not require a password, and takes one tap with Apple Pay or Google Pay. If your update flow requires a customer to remember an account login, you have built a wall in the middle of your own recovery funnel.

5 — Measurement. A weekly number: charges attempted, charges failed, revenue at risk, revenue recovered, recovery rate, and the split by decline reason. Without this you cannot tell whether a change helped, and you will end up arguing about it instead.

How do you build it, step by step?

Step 1 — Measure the leak before you touch anything

Pull ninety days of failed charges out of your subscription platform and your gateway. You want, at minimum: charge date, amount, decline code, decline reason, retry attempt number, final outcome, and whether the subscription survived.

Three numbers come out of that export and they are the only three that matter at the start:

1. Total revenue that failed, as a percentage of total recurring revenue billed.
2. The percentage of that revenue that was eventually collected.
3. The split of failures into soft and hard.

Write them down. Every change you make from here is measured against those three, and you will need the baseline in six weeks when someone asks whether any of this worked.

Step 2 — Rebuild the retry ladder

Open your subscription platform’s dunning configuration. Recharge, Skio, Smartrr and Stay AI all expose a retry schedule; the defaults are a flat sequence of attempts a fixed number of days apart, applied identically to every failure.

Replace it with something shaped like this:

• Soft declines: four to six attempts spread across roughly two weeks, weighted so at least one lands after a typical pay date and at least one lands on a different day of the week and time of day from the original attempt. Small variations in timing recover real money, because the most common soft decline is a balance problem that resolves itself.
• Hard declines: stop. One attempt, then straight to the communication track. Every additional attempt on a lost or stolen card is cost with no upside.
• SCA soft declines: stop retrying and route immediately to a customer-present flow. The charge cannot succeed without the cardholder.

If your platform will not branch on decline reason natively, this is the point where a small piece of middleware pays for itself: a webhook from the payment failure into a workflow that reads the reason and decides which track the subscriber enters. That is a couple of days of work and it is usually the highest-return change in the entire build.

Step 3 — Turn on the account updater

Card networks operate an updater service — Visa Account Updater, Mastercard Automatic Billing Updater and the equivalents — which hands merchants the new number when a card is reissued. Depending on your gateway it may be included, may be a paid add-on, and may need enabling per account. Check yours. On a subscriber base of any size this is the single highest-leverage switch available, because it recovers cards without the customer ever knowing there was a problem.

Two caveats worth knowing before you count on it. It does not cover every card type or every issuer, and it is not instant — an updated card can arrive days after the reissue. Treat it as a layer that removes a slice of the problem, not as the solution.

Step 4 — Add pre-dunning

You already hold the expiry date on every card on file. Sending a message thirty and seven days before a card expires, addressed to the specific customer whose card it is, is the cheapest revenue in this guide.

Build it as a scheduled job against your subscription platform’s customer records rather than as a flow triggered by an event, because there is no event — nothing happens when a card is about to expire. That is exactly why it gets skipped.

The same mechanism carries a second message: a pre-renewal notice a few days before the charge, for subscribers on high-value plans. It reduces failures caused by an unexpected debit and it reduces disputes, which are more expensive than the failed charge ever was.

Step 5 — Write the dunning sequence

Four to six touches over the retry window, across email and SMS. The rules that matter:

• Lead with the product, not the invoice. “Your next bag is on hold” outperforms “Payment failed” because it names what the customer loses, not what you failed to collect.
• One link, one job. Every message goes to the update page. No newsletter, no cross-sell, no unsubscribe-shaped footer competing for the click.
• Escalate honestly. Message one is a heads-up. Message four says the subscription will be cancelled on a specific date and means it.
• Put SMS at the sharp end. SMS earns its place on touch three or four, when email has been ignored twice and the deadline is close.
• Suppress on success. The moment a retry succeeds, everything remaining is cancelled. Nothing damages trust faster than a payment-failed message arriving after the money has cleared.

Most subscription platforms can push a charge-failure event into Klaviyo, and that is where the sequence should live — the same place as the rest of your lifecycle programme, so it obeys the same suppression rules. If those events are not arriving, fix that first; a dunning flow that never triggers looks exactly like a dunning flow that does not convert. We wrote the diagnostic for the most common version of that problem in Klaviyo not syncing Shopify orders.

Step 6 — Build a payment-update page that survives a phone

Open your own update flow on a phone, on mobile data, and count the taps from message to saved card. Under three is good. Over five and you are the reason the recovery rate is low.

What a working page does: opens from a tokenised link with no login, shows the customer which subscription is affected and what it costs, offers the wallet payment methods first, saves and confirms in place, and tells them the next charge date. What it must never do: ask them to remember a password, bounce them through an account area, or fail silently on a card the gateway rejected for a different reason.

Step 7 — Decide what happens at the end of the ladder

At the end of the retry window you have three options and you should choose deliberately: cancel, pause, or move to a long-tail winback.

Cancelling immediately is tidy and loses subscribers who would have come back. Pausing keeps the record alive and keeps the customer addressable, which is usually right for a product with a known reorder rhythm. Whatever you choose, the state should be explicit in the platform and visible in your reporting, not an accident of a default setting.

The customers who fall out of the bottom belong in a separate winback track with a different message, not in the same dunning sequence running forever. That track is part of subscription retention rather than payment recovery, and it should be built as such.

Step 8 — Report it every week

One dashboard, six numbers: charges attempted, charges failed, revenue at risk, revenue recovered, recovery rate, and failures by decline reason. Weekly, in front of whoever owns the number.

Recovery systems decay. Gateways change rules, a platform update resets a retry setting, an email template stops rendering, a flow gets accidentally paused during a campaign. Without a weekly number, the decay is silent and you find out a quarter later.

What tooling does this need?

You do not need to migrate platforms to do any of this. Almost every brand that asks us whether they should move to a different subscription app has a configuration problem rather than a platform problem, and a migration would postpone the fix by a quarter.

What does good look like?

We are not publishing a recovery-rate benchmark we cannot source. The two figures above are quoted with their publishers named; the two below them are the numbers we are collecting from our own engagements and will publish on the benchmarks pages when the sample is large enough to mean something. A recovery rate quoted without a baseline and a sample size is marketing, not data.

What you can do in the meantime is measure yourself against yourself. Take the three numbers from Step 1, rebuild the five layers, and read them again ninety days later. That comparison is worth more than any category average, because it is yours.

What are the mistakes that cost the most?

• Treating every decline the same. One retry schedule and one email sequence for a temporary funds problem and a stolen card. This is the default in most stacks and it is the single most expensive setting on the site.
• Retrying a hard decline five times. Costs money, recovers nothing, and irritates the issuer.
• Cancelling on the last retry with no warning. The subscriber finds out when the product does not arrive. That is a support ticket and a refund request, not a churn event you saved money on.
• Writing dunning emails like collections letters. The customer is not delinquent; their bank replaced a card. Language that implies otherwise loses people who would have stayed.
• An update page behind a login. Every password reset in a recovery flow is a customer you have lost to your own security.
• No suppression on success. A “your payment failed” message the day after the charge cleared reads as incompetence, and it is.
• Never looking at the number again. The build is a project; the recovery rate is an operation. Something breaks it every quarter.

The failed-payment recovery checklist

• Baseline capturedNinety days of failed charges exported, with decline codes, and the three baseline numbers written down.
• Retry ladder branchedSeparate schedules for soft declines, hard declines and SCA soft declines. No flat sequence.
• Account updater confirmed onChecked at the gateway, not assumed from the plan description.
• Pre-dunning liveCard-expiry warnings at 30 and 7 days, running as a scheduled job.
• Dunning sequence builtFour to six touches, email plus SMS, one link, escalating honestly, suppressed on success.
• Update page tested on a phoneNo login, wallet payment first, under three taps from message to saved card.
• End state chosenCancel, pause or winback decided deliberately and set explicitly in the platform.
• Weekly report runningSix numbers in front of an owner, every week, with the decline-reason split.