How to Reduce Subscription Churn on Shopify: The Payments Layer Nobody Writes About

She never cancelled. She never complained. She is gone anyway.

Her bank reissued her card in March, which she barely noticed because everything else updated automatically. Your April charge declined. Your subscription app retried it on day three, day seven, and day ten, against the same dead card number every time, then marked her inactive and stopped.

She would still be a subscriber if a single one of those retries had asked the card network for her new number instead of guessing at the old one.

That is not a retention problem. Nobody made a decision. It is a systems failure that produced the same outcome as a decision, and it will keep producing that outcome every month until someone changes the plumbing.

Involuntary churn is a systems failure wearing a retention failure’s clothes, and it is why most advice on how to reduce subscription churn on Shopify stops short of anything useful. Set up dunning, offer a pause option, send a win-back email. All correct. All several layers above where the money is actually leaking.

The payments layer is where it leaks. Almost nobody writing about Shopify goes there, partly because it sits across three vendors and belongs to none of them.

Nobody can tell you what dunning recovers

Before anything else, a warning about the numbers you have been reading.

Search this topic and you will be told that dunning recovers 40 to 60% of failed payments. Also 60%. Also up to 70%. Also 80 to 90% within thirty days. Also that the industry median sits near 47.6%.

One vendor’s article cites the same source for both the 40 to 60% figure and the 80 to 90% figure, several paragraphs apart. One publisher went looking for the origin of the widely repeated 40 to 70% claim and reported that it could not be traced to any primary study, recurring instead across dunning-vendor blogs with no shared source behind it.

We are not going to add another number to that pile.

Here is the one statistic you will find below, and it comes with its sample size. PYMNTS and FlexPay surveyed 200 subscription executives in March 2023 and found that only 17% tracked failed payments at all. Fifty-eight percent watched lagging outcome metrics like churn instead of the process metric underneath it. The businesses that did track failed payments lost 37% less revenue and recovered 43% more.

Sit with the first figure for a second, because it explains everything else.

If fewer than one in five subscription businesses measures failed payments, then every published average recovery rate describes a population nobody sampled. Those numbers are not conservative or optimistic. They are guesses, repeated until they acquired the texture of fact.

Your recovery rate is knowable, but only by you, and only from your own billing data.

Your two churn numbers are not one number

Most Shopify stores report a single churn figure, and that figure is two entirely different problems averaged into uselessness.

Voluntary churn is a decision. Someone opened your portal, considered their situation, and chose to leave. That is a product, price, or experience signal, and it is worth listening to.

Involuntary churn is an accident. A card expired, an issuer declined, a retry failed quietly, and a subscription lapsed without anyone intending anything. That customer wanted to keep buying from you.

Averaging them tells you nothing, because the fixes have nothing in common. A better cancel flow does not recover a dead card. Account Updater does not address a subscriber who is bored of your product.

Worse, blending them hides your own progress. Cut involuntary churn by a third and your blended number barely moves, so the work looks ineffective and gets deprioritised in favour of something visible.

The split is usually recoverable from subscription status transitions rather than from any dashboard. A subscription that moved to cancelled following a customer action in the portal is voluntary. One that moved to inactive or expired following a failed billing attempt is involuntary. Pull one quarter, classify every ending by what preceded it, and you will have a more honest picture of your Shopify subscription churn rate than any report your app produces.

Most founders are surprised by the ratio. It is routinely the larger half.

There is a second reason to keep them apart. Involuntary churn responds to work you can finish in a fortnight, while voluntary churn responds to product decisions that take quarters. Knowing which one dominates tells you whether this month’s retention effort belongs to engineering or to the people who decide what you sell.

Not every decline means the same thing

Here is where the engineering starts, and where nearly every article on this topic stops.

When a charge fails, the issuing bank does not just say no. It returns a reason code, carried in field DE 39 of the ISO 8583 authorisation message, and that code is the difference between a retry that recovers revenue and a retry that actively damages you.

Two categories matter.

Soft declines are temporary. Insufficient funds, issuer unavailable, a timeout, a generic refusal. The card is fine and the situation may resolve on its own. These reward well-timed retries, and timing is the whole game.

Hard declines are permanent. Lost card, stolen card, closed account, invalid number. The credential is dead and no amount of retrying revives it. Worse, hammering a flagged card risks getting you soft-blocked at the issuer, which quietly degrades approval rates on your other customers at the same bank.

Most stacks apply one retry schedule to everything, which means they simultaneously give up too early on recoverable failures and keep pounding on dead ones.

Mastercard makes the correct response explicit if you are listening. MAC 01 means new account information is available, so pull it from the account updater rather than retrying blindly. MAC 02 means try again later. MAC 03 and MAC 21 mean stop all attempts.

Reading these codes properly is the difference between a recovery programme and a retry loop. It is also the part that no subscription app markets, because it happens underneath them.

There is a catch, and it is not within your control. Whether you can see any of this depends on your gateway. Stripe exposes raw network codes. Braintree explicitly labels soft against hard. Adyen infers the real reason with its own models. Square hides network codes entirely.

Which means your ability to run intelligent recovery was partly decided by a gateway choice you probably made for pricing or convenience, long before subscriptions were part of the plan.

Worth checking what yours actually surfaces before you invest in anything downstream of it. A reason-aware retry strategy needs reasons, and if your gateway does not pass them through, every clever sequence you design collapses back into a fixed schedule wearing a better name.

The failure that never happens

The best recovery is the charge that never fails.

When an issuer reissues a card, the new details are available to merchants through Visa Account Updater and Mastercard Automatic Billing Updater. Your stored credential gets refreshed, the next charge goes through, and no email is sent, no dunning sequence fires, and no churn event is recorded. The customer never learns anything happened.

Network tokens take the same idea further. Instead of storing a card number, you store a cryptographic token issued by the scheme itself. Tokens update automatically when a card is reissued, and they carry higher approval rates across the board, so they reduce failures you were not attributing to card data at all.

The part worth building on is the lifecycle signal. A network token carries a status. ACTIVE means charge normally. SUSPENDED means the account is on hold, and the token returns to ACTIVE when the hold lifts, so you can retry later without re-provisioning anything. DELETED means the account is permanently closed.

That last one is the useful one. A DELETED status tells you the credential is dead before you attempt a charge. Instead of a failed payment followed by an apologetic email, you ask for a new card while the subscription is still healthy and the customer still feels like a customer rather than a problem.

Very few Shopify merchants have ever asked whether this is switched on for their stored credentials. It is not a default everywhere, and it is not always visible in an admin panel.

The economics are unusual too. Every other retention lever costs something per use: a discount to save a cancellation, a credit to apologise for a late box, engineering time on a portal redesign. A credential that quietly refreshes itself costs nothing per subscriber and works while nobody is watching.

That is the question to take to your gateway and your subscription app this week. Are network tokens provisioned for subscription payment methods, is Account Updater enabled, and does your subscription app act on the results or ignore them.

The answers vary more than you would expect between platforms, and it is a materially larger lever than anything in your cancel flow.

Who actually controls your retry schedule

Three layers touch a failed subscription payment. Your subscription app, your gateway, and the card network. The merchant typically controls the least of the three and is the only one being judged on the outcome.

Your app decides how many attempts and at what intervals. Your gateway decides what reason data you receive and whether updated credentials get used. The network decides what it tells anyone.

One consequence is worth knowing. Platforms commonly batch subscription retries during off-peak hours, because that is when their infrastructure has room. Three in the morning is convenient for a billing system and unrelated to when a cardholder has money in their account, which is usually payday.

A retry scheduled around the platform’s load profile rather than the customer’s balance is throwing away attempts on a card that would have worked on Friday.

So ask each layer a specific question. Of your app: can retry intervals be configured, and does the schedule vary by decline reason or is it one sequence for everything. Of your gateway: which decline data reaches your app, and are Account Updater and network tokens active. Of your own team: does anyone look at recovery rate broken down by decline code, or only at the blended number.

Where custom work legitimately earns its cost is the layer between those systems. A pre-billing check that catches a DELETED token before the charge attempt. Reason-aware sequencing where a funds decline waits for payday and a technical decline retries the same day. A payment update link that takes one tap rather than a login, a password reset, and an account page.

None of that is exotic engineering. It is unglamorous plumbing that sits in the gap between three vendors, and the gap is precisely where nobody’s product roadmap lives.

Four voluntary churn bugs that look like preference

The voluntary side has its own engineering problems, and they get misread as customers simply losing interest.

Pause implemented as cancel and recreate. Some setups handle a pause by cancelling the subscription and creating a new one on resume. That loses the payment credential, resets subscription age, and corrupts every cohort report you run afterwards. Customers who paused correctly show up in your data as churned and reacquired. Check what yours actually does, because the button says pause either way.

Recovery emails that land in a login loop. The customer opened the email, intended to pay you, and hit a password reset. Intent was not the constraint. Your account page was.

Missed webhooks. A payment fails, the webhook does not arrive, the pre-dunning email never sends, and nobody notices because the absence of an event is silent. This one hides for months, because there is nothing in any dashboard that shows you what did not happen.

Skip buried deeper than cancel. If skipping a month takes four taps and cancelling takes two, people cancel. They did not prefer cancelling. They found it first. This is the single most common cause of churn that gets attributed to product dissatisfaction, and it is the cheapest thing on this list to fix.

There is a related pattern where the subscription is technically working and still failing the customer, which we covered in why supplement subscribers cancel in month three. The shipment schedule was fine. It just had nothing to do with how the product got used.

Dunning quality also varies enormously between platforms, and it is rarely what merchants compare on. We broke that down in our guide to the best Shopify subscription apps and where each breaks.

Measure this before you fix anything

Four things, and none of them requires buying software.

Split voluntary from involuntary churn for the last quarter, classified by what preceded each ending rather than by what your dashboard labels it.

Pull the decline codes from one billing cycle and count how many hard declines you retried. That number is wasted attempts and issuer goodwill, and it is usually higher than anyone expects.

Ask your gateway whether Account Updater and network tokens are active on your stored subscription credentials, and ask your subscription app whether it does anything with the results.

Then try to skip a month on your own store, on a phone, as a customer. Count the taps. Compare it to cancelling.

Those four answers will tell you more than any benchmark, because they describe your subscribers rather than an average of a population nobody measured.

None of it requires a platform migration, and none of it is what you get sold when you ask a vendor how to reduce subscription churn on a Shopify store. Subscription retention engineering is mostly this: unglamorous checks on plumbing that three different companies each assume somebody else owns.

Start with the split. If involuntary churn turns out to be the larger half, you have found revenue that is already yours, from customers who never wanted to leave, and none of it costs a discount to recover.

The subscriber who left in April did not choose to leave. Find out how many of yours did.

Frequently Asked Questions

What is involuntary churn?

Involuntary churn is a subscription ending because a payment failed rather than because a customer decided to leave. Expired cards, reissued cards, and issuer declines are the usual causes, and those subscribers usually intended to keep buying.

What recovery rate should dunning achieve?

Published figures range from 40% to 90% and are largely untraceable to primary research. Since only about 17% of subscription businesses track failed payments at all, no reliable industry benchmark exists. Measure your own rate from your billing data instead.

Should you retry a declined subscription payment?

Only for soft declines such as insufficient funds or issuer timeouts. Retrying hard declines like lost, stolen, or closed cards cannot succeed and risks getting you soft-blocked at the issuer, which lowers approval rates for other customers at that bank.

What are network tokens and do they reduce churn?

Network tokens are scheme-issued cryptographic credentials that replace stored card numbers. They update automatically when a card is reissued and carry higher approval rates, so charges that would have failed simply succeed instead.

Does Shopify handle failed subscription payments automatically?

Retry behaviour comes from your subscription app and gateway rather than from Shopify itself, and depth varies considerably between apps. Shopify’s free Subscriptions app offers limited retry configuration compared with paid platforms.

How do you separate voluntary from involuntary churn?

Classify each ended subscription by the event preceding it. A cancellation following a customer action in the portal is voluntary. A lapse following a failed billing attempt is involuntary. Most billing exports contain enough status history to do this.