The full numbers
Two figures carry this page: the share of recurring revenue that never arrives because a card declined, and the share of total churn that no customer actually chose.
| Metric | Benchmark | Source |
|---|---|---|
| Recurring revenue lost to failed payments | ~9% | Baremetrics |
| Share of all churn that is involuntary | 20–40% | Paddle / ProfitWell |
| Recovery rate after a rebuilt retry ladder | — | Pointerflow, to publish |
| Decline split, soft versus hard | — | Pointerflow, to publish |
| Reissued cards caught by an account updater | — | Pointerflow, to publish |
| Card-expiry warnings that end in an update | — | Pointerflow, to publish |
An em dash means we hold no sourced figure for that row. We publish our own client data as a benchmark once the sample is large enough to be worth citing — and not before. Estimating into an empty cell is how bad numbers enter circulation.
Where these numbers come from
Both published figures come from subscription billing and analytics companies reporting across their own customer bases — not from Pointerflow client data. We name them, we link them, and we mark what they do not tell us.
| Source | What we cite it for | Population | Sample size |
|---|---|---|---|
| Baremetrics | ~9% of recurring revenue lost to failed payments | Subscription businesses | — |
| Paddle / ProfitWell | 20–40% of all churn is involuntary | Subscription businesses | — |
- Baremetrics — the failed-payment share of recurring revenue.
- Paddle / ProfitWell — the involuntary share of total churn.
Two caveats, stated plainly. Neither figure reaches us with a sample size we can verify, so those cells are em dashes rather than guesses. And we link to the publisher rather than to a snapshot URL, because benchmark reports get moved, merged and re-dated, and a dead link is worse than a named one.
Both figures are cross-industry subscription benchmarks. A DTC brand billing on a schedule sits inside that population, but no vertical is broken out separately in either source, and neither is broken out by revenue band. Treat them as the shape of the problem, then measure your own.
What counts as a good number?
If failed payments are costing you less than about 9% of recurring revenue and involuntary churn is under a fifth of your total churn, you are at the better end of the published ranges. If involuntary churn is running at or above 40% of the total, your retention problem is a billing problem — the customers are still choosing you, the cards are not.
The number worth watching is not your decline rate. Declines are mostly outside your control: expired cards, issuer fraud rules, insufficient funds on the third of the month. What is inside your control is the recovery rate — the share of declined charges that end in a successful payment rather than a cancelled subscription. Most brands have never measured it once, which is the reason a retry-logic audit finds money almost every time.
Read the share against your absolute churn, too. The same involuntary percentage means one thing when total churn is at the category norm and something far worse when it is well above it — a share is a ratio, and both halves of it move.
What moves it
These are the levers, roughly in the order they tend to pay:
- Decline-code-aware retry logic. A flat schedule retries a stolen-card decline the same way it retries insufficient funds. Timing, count and routing should read the code.
- Pre-dunning. Card-expiry warnings sent before the charge fails, which convert far better than any message sent after one.
- An account updater. Reissued cards get caught silently and the customer never learns there was a problem.
- A four-to-six touch dunning sequence across email and SMS, written to be helpful rather than threatening.
- A self-serve payment update page that works on mobile in one tap.
- Decline-reason reporting — soft versus hard, by processor, by cohort — so the next fix is chosen from data.
Every one of those is what payment recovery means as a build. If involuntary churn turns out to be only half your problem, the voluntary half is subscription retention: cancel-flow logic, pause and skip, and replenishment timing.