- Billing-platform research published in 2024 and 2025 puts involuntary churn, meaning customers lost to a declined payment rather than a decision, at roughly 20 to 40% of total subscription churn. Recurly's own published benchmarks show average churn of about 3.27%, split 2.41% voluntary and 0.86% involuntary, which lands near the bottom of that range rather than the top.
- Recovery depends almost entirely on why a payment failed. Vendor datasets published in 2025 and 2026 report processing errors recovering at roughly 80 to 90% and insufficient funds at 70 to 80%, while a generic decline recovers 40 to 60% and a true hard decline recovers 0%.
- That is why a single retry cadence underperforms: it over-retries codes that will never clear and under-serves the ones that would have.
- Card failure rates are structurally higher than bank-debit rates, at roughly 15% against 3 to 5% for ACH and direct debit, per 2025 industry benchmarks. Payment method is a design decision, not a customer preference to be accepted passively.
- The most valuable failure to catch is the one nobody sees. A failed transfer that generates no notification sits in limbo until a human happens to look.
Every business with recurring revenue has a churn number, and most treat it as a product problem. Some of it is not. A share of those departures are customers who never decided to leave: their card expired, their bank declined a transaction, a processor returned an error. They intended to keep paying, and the payment simply did not go through.
That category is worth separating, because the fix is mechanical and the customers are already sold. You do not need to re-win them. You need the charge to clear.
The number worth getting right
A note on sourcing before any numbers. Almost all published data on this topic comes from billing and dunning vendors analyzing their own customer bases, which is not the same as independent research. The figures below are consistent enough across providers to be directionally useful, and specific enough to act on, but they describe those vendors' customers rather than the market. Treat them as a starting hypothesis to test against your own data.
The figure repeated across this topic is that 20 to 40% of subscription churn is involuntary, reported by Recurly and by ProfitWell in 2024. It is a reasonable range, but it circulates as though 40% were typical.
Recurly's published churn benchmarks put average subscription churn at about 3.27%, split roughly 2.41% voluntary and 0.86% involuntary. That works out closer to a quarter of all churn than to 40%, and the share runs higher in consumer-facing and low-ticket segments than in B2B.
Use the range as a prompt to measure rather than as a number to quote. The calculation is simple: subscribers lost to payment failure in a period, divided by total subscribers at the start. If you have never separated the two, do that before sizing any fix, because the difference between 6% and 40% of churn changes what the project is worth.
Recovery is a function of the decline code
This is the part most writing on the subject skips, and it is the part that determines results.
Payments fail for different reasons, and those reasons have wildly different recovery odds. The ranges below come from vendor datasets published across 2025 and 2026 and vary between providers, but the ordering is consistent everywhere and the ordering is what matters. Processing and network errors are transient and recover at roughly 80 to 90% on a prompt retry. Insufficient funds recover at 70 to 80%, because the money often arrives on a predictable cycle. A generic "card declined" recovers at 40 to 60%. A true hard decline, meaning a closed account or a card reported lost, recovers at zero no matter how many times you try.
A single retry schedule applied to all of them does two bad things at once. It burns retries on codes that will never clear, which costs processing fees and can attract scrutiny from your processor. And it under-serves the recoverable ones by retrying at the wrong interval.
The design that works reads the decline reason first and branches: retry transient failures quickly, schedule insufficient-funds retries around likely deposit timing, route generic declines into a customer-facing sequence that asks for a new card, and stop entirely on hard declines while handing the account to a person.
Reduce the failures before recovering them
Recovery has a ceiling. Even at a strong recovery rate you are permanently losing the remainder, so the cheaper work is upstream.
Payment method is a design choice. Card payments fail at roughly 15%, while ACH and direct debit fail at around 3 to 5%. For recurring business relationships, especially higher-value ones, offering bank debit as the default rather than the alternative changes the failure rate structurally. Our notary back-office build runs payouts over ACH with bank accounts verified at onboarding rather than at first payment, which moves the failure from a live transaction to a setup step where it costs nothing.
Expiry is predictable, so it should never surprise you. Cards expire on a known date. A reminder before that date recovers customers at a far higher rate than a decline notice after it.
Verify at onboarding, not at first charge. A payment method confirmed during onboarding fails in front of someone whose job is to fix it. The same failure three weeks later happens silently.
The failure that must never be quiet
The single most damaging pattern in this whole area is a failed transaction that generates no signal.
A payment that fails loudly gets handled. A payment that fails silently sits until someone notices the number is wrong, and by then the customer has been gone for weeks. In the back-office build above, both successful and failed transfers generate a notification for exactly this reason: a payout must never be able to sit in limbo unobserved.
The same principle applies to the accounting side. If a failed charge does not propagate to your records, your revenue reporting quietly diverges from reality, and you get the double data entry problem in its most expensive form, where the two systems disagree about money. Our zero double-entry financial pipeline syncs payment state into accounting automatically so that the books and the billing system cannot drift apart.
What stays human
Hard declines. These need a conversation, not a sequence. A closed account often means a business that has folded or a relationship that has changed.
High-value accounts. A dunning email is the wrong instrument for a client paying meaningfully. Route those to a person on the first failure.
Anything that has already failed repeatedly. After two or three cycles, continued automation reads as harassment and the account is telling you something. Escalate to a human decision about whether to pause, renegotiate, or close.
The decision to cancel. Automation should surface an unrecoverable account, not terminate the relationship on its own.
Where to start
Separate involuntary from voluntary churn first, because until they are separate you are guessing at the size of the problem. Then capture decline codes, since without them you cannot branch and you are stuck with one cadence for every failure type. Then add a notification on every failed transaction, which is the cheapest change on this list and removes the silent-failure case entirely. Only then build the retry logic.
Related reading
The same collection problem on the invoice side is covered in chasing invoices, where the delay is a human forgetting to follow up rather than a processor declining. When payment state fails to reach your accounting system, you get the pattern described in double data entry. And if you are still working out which leak to fix first, the five signs your business is losing hours to busywork is a quick way to narrow it.
Frequently asked questions
What is failed payment recovery?
Failed payment recovery is the process of reclaiming revenue from transactions that declined for mechanical reasons rather than customer intent, such as an expired card, insufficient funds, or a processor error. It usually combines automated retries timed to the type of failure, a customer-facing sequence prompting an updated payment method, and a card-updater service that refreshes expiry details automatically. It is distinct from collections or from winning back a customer who chose to cancel, because in these cases the customer still intends to pay and the obstacle is the transaction itself.
What percentage of churn is caused by failed payments?
Industry estimates commonly place involuntary churn at 20 to 40% of total subscription churn, though that upper figure is often quoted as if typical. Recurly's published benchmarks put average subscription churn near 3.27%, split about 2.41% voluntary and 0.86% involuntary, which is closer to a quarter of total churn. The share tends to run higher for consumer and low-ticket subscriptions and lower for B2B. Rather than adopting a benchmark, divide subscribers lost to payment failure by total subscribers at period start, since the true figure varies enormously by payment method, price point, and customer type.
Why do some failed payments recover and others never do?
Because recovery odds are determined by the decline reason rather than by effort. Transient processing and network errors recover at roughly 80 to 90% on prompt retry, insufficient-funds declines at 70 to 80% when retried around likely deposit timing, generic card declines at 40 to 60%, and hard declines such as closed or reported-lost accounts at zero regardless of retries. This is why a single retry schedule underperforms: it wastes attempts on codes that cannot clear while retrying recoverable failures at the wrong intervals. Reading the decline code and branching on it is the main determinant of results.
How can a business reduce payment failures rather than just recovering them?
By treating payment method and verification as design decisions. Card payments fail at roughly 15% while ACH and direct debit fail at around 3 to 5%, so offering bank debit as the default for recurring relationships lowers the failure rate structurally rather than after the fact. Verifying payment details during onboarding rather than at first charge moves any failure to a moment when someone is present to resolve it. Sending a reminder before a card's known expiry date recovers customers at a far higher rate than a decline notice afterwards. Recovery always leaves a residue, so prevention is the cheaper half of the work.
Think this might apply to your business?
Get the $250 Automation Audit