Involuntary churn explained, from decline codes to dunning

What involuntary churn is

A subscription churns involuntarily when it ends, or moves to an unpaid state that blocks access, as a result of a failed payment rather than a decision by the customer. The customer may not even know it happened until the product stops working. Voluntary churn is the opposite: a customer decides to leave and cancels.

The split matters because the two respond to different work. Voluntary churn responds to product value, pricing, onboarding and cancel flows. Involuntary churn responds to billing mechanics: retry logic, card updates, payment update pages and clear dunning emails. A business that reports one combined churn rate cannot see how much of its loss is a configuration problem.

• Voluntary churn starts with a cancel action by the customer.
• Involuntary churn starts with a declined charge.
• A cancellation that follows a decline within a few days usually belongs to the involuntary side.

How a card decline happens

When a renewal invoice is due, the billing system asks the payment processor to charge the card on file. The processor sends an authorization request through the card network to the bank that issued the card. The issuer approves or declines and returns a response code. The processor translates that code into its own decline reason, which is what you see in your billing data.

The issuer decides for many reasons: the balance is too low, the card is expired, the card was reported lost, the issuer's fraud model did not like the transaction, the issuer's system was briefly unavailable, or the card does not allow recurring charges from that merchant. Some of these reasons are temporary. Others are permanent for that card.

Soft declines and hard declines

A soft decline means the charge might succeed later on the same card. A hard decline means it will not, and the customer needs to provide a different payment method. Treating the two the same is the most common cause of avoidable involuntary churn.

The generic do not honor response deserves a note. It is the issuer's way of declining without a specific reason. It is usually treated as soft and retried, but with fewer attempts than insufficient funds, because some of these declines are permanent in practice.

Reading decline codes in billing data

Every failed charge carries a reason. In Stripe it appears as a decline code such as insufficient_funds, expired_card, do_not_honor, generic_decline, lost_card, stolen_card, incorrect_number or processing_error. Other billing systems use their own labels for the same issuer responses, and the underlying network codes are similar across processors. Group your failures by these codes before you change anything. The mix tells you where the work is.

• A large share of insufficient funds points to retry timing.
• A large share of expired card declines points to missing card updates before renewal.
• A large share of authentication required points to a missing payment confirmation page.
• A large share of generic declines points to the issuer's risk view, where a clear statement descriptor and consistent billing amounts help.

Card networks also publish rules on how often a declined transaction may be reattempted, and they treat certain codes as do not retry. Retrying a lost or stolen card response is not only useless, it can lead to fees and closer scrutiny of the merchant account. A retry engine should read the code first and decide whether a retry is allowed at all.

Retry timing that matches the reason

A good retry schedule is not a fixed interval. It is a set of rules keyed to the decline code and to what is likely to change between attempts.

For insufficient funds, the balance changes when money comes in. Retrying a few hours later rarely helps. Retrying at the start of the next business day, or around common pay dates such as the first and the fifteenth of the month, gives the charge a better chance. For issuer unavailable or processing errors, the problem is technical and short lived, so a retry within hours is reasonable. For generic do not honor, a small number of spaced retries over a week or two is common, after which the customer should be asked to update the card.

For example, a schedule for insufficient funds might retry on day one at a morning hour, on day three, on the next likely pay date and once more before the end of the grace period. A schedule for an expired card would not retry at all and would send the customer straight to a card update page.

Built-in billing retries are a reasonable start. Our page on Stripe smart retries explains what the built-in logic does and where rules by decline code add recovery on top of it, and failed payment recovery covers the full schedule.

Card expiry, the most predictable failure

Expired card declines are unusual because you can see them coming. The expiry month is stored with the card. Any subscription whose next renewal falls after the card's expiry will fail unless the card is refreshed first.

Account updater services run by the card networks help. When an issuer reissues a card with a new number or expiry date, the processor can receive the new details and update the card on file without the customer doing anything. Coverage is incomplete. Not every issuer takes part, some card types are excluded, and a card that was closed rather than reissued has no replacement to send.

That leaves a share of expiring cards that only the customer can fix. The answer is a pre-expiry email sent ahead of the renewal, typically two to four weeks before, with a single link to a secure page where the customer enters a new card. A second reminder close to the date catches people who missed the first. The card updater page covers detection windows of 30, 60 and 90 days, and our guide to expired cards recurring billing goes deeper into the mechanics.

Dunning emails that get read

Dunning is the sequence of messages a customer receives after a failed payment. Its job is simple: tell the customer what happened, make it easy to fix and give them a clear deadline before access changes. Most dunning fails because the emails are vague, alarming or hard to act on.

• Say what failed and for which product, in the subject line.
• Name the amount and the date of the next attempt, so the customer knows retries continue.
• Give one button that opens a payment update page, already tied to their account, with no login step.
• State the date access will pause, and offer a pause or a lower plan where it fits.
• Send from an address the customer recognizes, at the hour they usually read email.

A typical sequence has three to five emails across the grace period. The first is friendly and short. The middle ones repeat the facts and the link. The last one states that access is paused and how to resume. An in-app notice for logged in users reaches the people who never open billing email. The dunning software page shows such a sequence with its timing.

How to measure involuntary churn

Measure involuntary churn the same way you measure revenue churn, but count only subscriptions that ended because of a failed payment.

Involuntary churn rate = MRR of subscriptions that ended after a failed payment / Starting MRR

Decide one rule for what counts. A common rule is that a subscription is involuntary churn if it ended by the system after the retry schedule ran out, or if the customer cancelled within seven days of a declined charge. Write the rule down and apply it every month.

Alongside the rate, track three supporting numbers.

• Failure rate. Renewal value that failed on the first attempt, divided by renewal value attempted.
• Recovery rate. Failed value that was later collected, divided by failed value.
• Time to recover. Days between the first failure and the successful charge.

For example, a business attempts 80,000 USD of renewals in a month. 4,800 USD fails on the first attempt, a 6 percent failure rate. Retries and emails recover 2,400 USD, a 50 percent recovery rate. The remaining 2,400 USD ends as churn. With 80,000 USD of starting MRR, involuntary churn is 3 percent for the month. If the recovery rate rises to 70 percent, the loss falls to 1,440 USD and involuntary churn to 1.8 percent, with no change in product or price.

These numbers feed directly into gross revenue churn, so read the guide on the net revenue churn formula to see where the involuntary share sits in the wider retention picture. A subscription analytics view that tracks the cohort of failed payments month by month shows whether changes to the schedule actually work.

Gaps that keep involuntary churn high

• One retry schedule for every decline code.
• Retries that continue on hard declines and stop too early on soft ones.
• No pre-expiry email, so expired cards fail every month on schedule.
• Dunning emails with a login wall in front of the payment update page.
• A grace period shorter than the retry schedule, so access ends before the last attempt.
• Cancellations after a decline counted as voluntary, which hides the problem in reports.

See how much of your churn is involuntary

RevenueLeak connects read-only to your billing system, groups failed renewals by decline code, lists cards that expire before renewal and shows the recoverable amount in USD per month with the accounts behind it. Retries by decline code, recovery emails and card updater emails run only once you switch them on.