Involuntary churn

Involuntary churn is when a subscription ends because a payment failed, not because the customer chose to leave. The customer still wants the product. Their card expired, was reissued after a fraud report, hit its limit, or was declined by the bank, and nobody fixed it before the retries ran out.

How involuntary churn happens in Stripe

In Stripe Billing, involuntary churn is the end of a set sequence:

1. A renewal invoice fails and Stripe fires invoice.payment_failed. The charge attempt also fires payment_intent.payment_failed, which carries the decline code.
2. The subscription moves to past_due, and Stripe fires customer.subscription.updated.
3. Smart Retries or your custom schedule tries the payment again. If Stripe's failed payment emails are on, they ask the customer to update their card.
4. If the window closes unpaid, the subscription follows your settings. It is canceled with customer.subscription.deleted, marked unpaid, or left past_due.

Step 4 is where the churn becomes real. Two of those outcomes don't cancel anything. An unpaid or permanently past_due subscription still exists in Stripe but pays you nothing. If you only count churn from cancellations, those accounts hide in your numbers.

Involuntary vs voluntary churn

Voluntary churn is a decision, and you address it with product, pricing and service. Involuntary churn is a payment failure, and you address it with recovery. One churn number that mixes the two hides the part you can fix without changing the product.

Involuntary churn also shows up in MRR movements as a full loss, not a downgrade, so it removes the whole plan value from MRR. One $499 a month renewal that is never recovered is close to $6,000 of yearly revenue, lost from a customer who wasn't unhappy.

Common causes

• Expired cards. Stripe can email the customer a month before a saved default card expires.
• Reissued cards. After a card is reported lost or stolen, the old number stops working. Stripe's automatic card updates can swap in the new details when the issuer takes part, which is common in the US and varies elsewhere. Stripe then fires payment_method.automatically_updated.
• Insufficient funds. Usually a soft decline, and a good candidate for retries.
• Hard declines. Stripe won't retry codes such as lost_card, stolen_card or transaction_not_allowed until the customer adds a new payment method.
• Authentication. Some off-session charges fail with authentication_required, and the customer has to come back and confirm the payment.

How to reduce involuntary churn

1. Turn on Stripe's recovery tools. Smart Retries, failed payment emails and expiring card emails are Dashboard settings and need no code.
2. Run a real [dunning](/glossary/dunning) process. Someone owns follow-up, especially for hard declines and large accounts.
3. Give a fair [grace period](/glossary/grace-period). Keep access while the subscription is past_due, so fixing a card doesn't mean losing access.
4. Measure it on its own. Track failures, recoveries and final losses apart from cancellations, so you can see whether recovery improves.
5. Act while retries are running. Once the window closes, getting the customer back is a sales conversation, not a card update.

Catching involuntary churn with ChargeBell

Nothing reaches your inbox between the first decline and the cancellation two weeks later, unless you set it up. ChargeBell posts those steps to Slack. The invoice payment failed alert posts each declined renewal with the customer, amount and decline reason. It is critical, so it skips quiet hours. A payment recovered alert tells you when a retry works, and a subscription canceled alert shows the ones that didn't. Send all three to #billing or a founders' channel so the same people see each case from start to end. ChargeBell is read-only, so the fix happens in Stripe. The guide to failed payment alerts in Slack walks through the setup.