What Is Involuntary Churn? An Operator's Definition

Involuntary churn is what a Shopify subscription loses when a card fails at the billing attempt — expired, declined, blocked by the issuer, or renumbered after a reissue — rather than when a customer actively decides to leave. Both events end the subscription. Underneath, they are different problems with different fixes. A customer who cancels because the product stopped working needs a better product, a better offer, or a better cancellation flow. A customer whose card was declined on the third of the month needs a retry, a dunning message and a payment page that works on a phone. Treating every cancellation as a customer’s verdict, and building retention work only for that half, is why so much of the actual gap goes unrecovered.

What Actually Changes for a Shopify Merchant Once Churn Turns Out to Be Involuntary?

Once a cancellation is identified as involuntary churn, the fix stops being a product or offer decision and becomes a billing-systems decision — ownership moves from whoever runs retention or marketing to whoever owns the payment stack, because nothing about the product or the offer caused the loss.

That shift matters at the scale these numbers describe: Baremetrics reports that around 9% of recurring revenue is lost to failed payments across the subscription businesses it measures (Baremetrics, vendor-reported), and Paddle and ProfitWell put involuntary churn at 20% to 40% of all subscription churn (Paddle / ProfitWell, vendor-reported). Both are cross-industry averages spanning many kinds of recurring billing, not figures measured for Shopify stores or DTC ecommerce subscriptions specifically, and neither is broken down by store size or catalogue.

What that means in practice is that a meaningful share of a store’s total “churn” number was never a retention failure at all — it was a billing failure nobody built a system to catch. Retry logic, a pre-expiry warning, an account updater and a dunning sequence are not retention tactics in the loyalty-programme sense. They are the mechanism that closes this specific gap, and they close it whether or not anything about the product, the price or the offer ever changes.

How Much Does Involuntary Churn Actually Cost a Shopify Merchant, Per Order or Subscription SKU?

The actual per-order or per-SKU dollar cost of involuntary churn for a specific Shopify subscription catalogue is — metric to confirm. No processor, subscription app or industry report publishes a figure broken out by SKU or by store; the 9% and 20–40% figures above are whole-industry averages, and applying either one directly to a single store’s numbers treats a cross-industry median as if it were a measurement of that store, which it is not.

The method is more useful than a borrowed number would be, because it runs on a store’s own data instead of somebody else’s average across thousands of unrelated businesses. Four inputs make the calculation: the number of active subscribers on the SKU or plan, its average order value, the store’s own decline rate for that cohort — pulled from the subscription app’s own billing reports or Shopify Payments’ transaction data, never assumed from an industry figure — and the recovery rate after dunning, which most subscription apps report per billing cycle once someone actually asks for it.

Running that method with invented inputs, not measured data, produces the following illustrative per-SKU calculation, structured so the arithmetic is checkable line by line.

800 subscribers × 8% decline = 64 declining charges a month. 64 × 50% recovered = 32 recovered, leaving 32 net lost. 32 × $50 = $1,600 lost a month, or $19,200 a year on this one SKU alone — every figure in this table is invented for illustration, not a benchmark to reuse.

Run the same four inputs through the failed payment calculator using a store’s real subscriber count, average order value and recovery rate, and the store-wide version of this same maths comes out at the whole-MRR level rather than the single-SKU level shown here. Neither replaces the other: the calculator is the fast whole-catalogue check, and the SKU-level version is worth rerunning wherever one plan or bundle carries most of the subscriber base, because a catalogue-wide recovery rate can hide one badly-performing SKU behind several healthy ones.

The decline-rate input is the one most stores cannot pull without a specific report open. Shopify’s own admin does not surface a standing “decline rate” figure anywhere in the default dashboard — it shows order and payment status per order, not an aggregate failure percentage — so the number has to come from whichever system is actually billing the subscription: a subscription app’s own order-error or failed-charge report, or Shopify Payments’ transaction list filtered to declined attempts. A store that has never opened that report is, in effect, trying to run the calculation — active subscribers, average order value, decline rate, recovery rate — with one of those four inputs missing, which is the most common reason the per-SKU figure never gets calculated at all.

Does Recovery Performance Actually Differ by Payment Processor — Shopify Payments, Stripe or a Third-Party Gateway?

No published benchmark breaks Shopify subscription recovery rates out by processor, so the honest answer to how much they differ is — metric to confirm, tracked by segmenting a store’s own decline and recovery reporting by which gateway actually handled the charge. What is documented, and checkable directly against Shopify’s own help pages, is a structural difference likely to drive that number in one direction: Shopify’s own documentation states that Shopify Payments “collaborates with major card networks to automatically update saved card details when customers receive new cards,” while a merchant using “another supported gateway… might need customers to update their payment details manually to continue being charged” (Shopify Help Center, “Considerations and payment gateways for subscription products”).

Source: Shopify Help Center, "Considerations and payment gateways for subscription products." Shopify's documentation does not publish a recovery-rate difference between these gateways — only the account-updater capability itself.

That asymmetry does not by itself say how much recovery rate it is worth — that is exactly the number nobody has published — but it does say where to look first. A store not on Shopify Payments should expect a larger share of its involuntary churn to trace back to reissued or renumbered cards specifically, because nothing refreshes those automatically on the other four gateways, and that share is measurable by filtering a store’s own decline-reason report against which processor ran the charge, even with no industry benchmark to compare the result against.

How Does Involuntary Churn Interact With Shopify’s Native Retry Logic Versus a Subscription App’s Own Billing Engine?

Involuntary churn is handled by whichever system actually owns the retry schedule for a given subscription, and that system is not always Shopify itself — a store running Recharge, Bold Subscriptions or Skio is billing through that app’s own engine, with its own dunning settings, independent of Shopify’s native subscription billing and independent of which payment processor sits underneath it.

Shopify’s own native Subscriptions app lets a merchant set the number of retry attempts and the number of days between them, and choose to skip, pause or cancel a subscription once retries are exhausted — but Shopify’s own documentation for that app describes no decline-code-specific routing; the schedule is one merchant-set cadence applied to every failure the same way (Shopify Help Center, “Managing Shopify Subscriptions app settings”). Recharge’s own Help Center describes a different default entirely: a charge is retried the day after the first failure, then every six days for six further attempts (Recharge Help Center, “Managing max retry order errors”) — a fixed schedule too, just a different one, and one that a store running Shopify’s native app instead never touches. Bold Subscriptions lets a merchant choose between 1 and 15 retry attempts in its own dunning settings (Bold Commerce Help Center, “Cancellation & Dunning Management in Subscriptions for Shopify Checkout”). Skio describes its own “Smart Retries” as varying the time of day, day of week and day of month per failed charge according to its own data model, and falling back automatically to a stored backup card where one is on file — a claim about that app’s own product design, labelled vendor-reported rather than an independently measured recovery lift (Skio Help Center, “Payment Recovery”).

The consequence worth acting on is not which of these four is “best” — none publishes a recovery rate a reader could actually compare against the others. It is that changing subscription apps changes the dunning engine even when nothing about the underlying payment processor changes at all, and a store running more than one billing method across its catalogue — a native Shopify plan for one product line, a Recharge subscription for another — is running two independent retry schedules that need auditing separately, not one shared number to check.

Running more than one billing method on a single catalogue also means an audit has to confirm which engine is live for a given customer, not just which app is installed. A store that migrated from Bold Subscriptions to Skio, or turned on Shopify’s native app for new signups while leaving existing subscribers on the app they started on, can end up with two cohorts running two different retry cadences at once — and a support ticket about a “failed payment that never retried” is unanswerable until someone checks which engine actually owns that specific subscription.

Where Do Shopify Merchants Get Involuntary Churn Wrong?

The most common mistake is treating the whole churn number as a retention problem, when 20% to 40% of it, by Paddle and ProfitWell’s own figure, never involved a customer decision at all. A win-back email to a subscriber whose card simply expired addresses nothing, because there was never a “why did you leave” for the message to answer — the subscriber never left in any sense that a better offer could reach.

The second mistake is assuming one fix closes the whole gap. An account updater catches reissued or renumbered cards silently, but it does nothing for a decline caused by insufficient funds or an issuer’s fraud hold, both of which need a retry timed for when the underlying cause has likely cleared rather than an instant re-attempt that fails for the identical reason seconds later. A four-to-six-touch dunning sequence catches most of what an updater misses, but only if the message and timing differ by decline reason — a generic “your payment failed” sent the same day to every decline type reads as noise to the subscriber whose bank simply flagged one purchase as unusual, and it gets ignored at a materially different rate than a message that actually says so.

The third mistake is not knowing which decline reasons are actually occurring, because most stores never pull that report. Soft declines — insufficient funds, a bank’s temporary hold, a mismatched security code — are worth retrying on a delay, since the underlying cause is often gone within days. Hard declines — a closed account, a card reported lost or stolen — are not worth retrying on the same schedule; doing so wastes attempts and, in the stolen-card case, sends a repeat charge attempt against a card the customer has likely already cancelled with their bank.

The fourth mistake is reviewing churn on a cadence too slow to catch the dunning window while it is still open. A monthly or quarterly churn review looks at cancellations that already happened; by the time a failed-payment cohort shows up in that report, the retry attempts that could have recovered most of it are long finished. The window that actually matters is the one between the first decline and the last retry — days, not the reporting period — which is why a recovery dashboard checked weekly catches money a churn report checked monthly never will.

How Is Involuntary Churn Different From Voluntary Churn?

Most churn dashboards — Shopify’s included — hide the difference between voluntary and involuntary churn rather than showing it: a cancellation is recorded at the point the subscription actually ends, not at the point the underlying cause occurred, so a subscription that exhausts every retry attempt and cancels automatically looks identical to one a customer cancelled deliberately from their account page. Nothing upstream separates the two unless a store or its subscription app tags the reason before that record is written. The failed payment and involuntary churn benchmarks page carries the sourced split between the two categories and what tends to move each one, for a Shopify merchant checking where their own number sits against the published range.

Getting that split right changes what gets built next. A voluntary-churn problem calls for offer, product or cancellation-flow work — the kind of retention project most teams already know how to run and already have an owner for. An involuntary-churn problem is a payment-recovery problem: retry logic that reads the decline code instead of running one schedule for every failure, an account updater, pre-expiry warnings sent before the charge fails rather than after, and a self-serve card-update page that works on a phone in one tap. That is systems work sitting inside the billing stack, not a marketing campaign, and it is what payment recovery means as a build — closing the gap between a card that failed and a customer who never actually chose to leave.