Key Takeaways

• The moment a lapsed account closes is a merchant setting, not an industry standard, and most companies run whatever default shipped with their billing system.

• Stripe's end-of-dunning setting offers three outcomes: cancel the subscription, mark it unpaid, or leave it past_due. Only the first is terminal.

• Stripe names the access decision for one state only: "Revoke access to your product when the subscription is unpaid." What a past_due customer can still reach is your call.

• Chargebee's subscription statuses carry no failed-payment value. The subscription reads Active while the invoice sits in Payment Due, so nothing on the record marks the lapse.

• A customer who lapses on a card decline and returns three weeks later books as churn plus reactivation, hitting one cohort's loss column and a later month's acquisition column.

Who decides how long an account survives a failed payment?

You do, and in most companies nobody made that call on purpose. Every major billing platform exposes the end of the grace window as a setting, and the options differ enough that two teams comparing involuntary churn can be measuring different events.

Stripe's recovery settings resolve a failed subscription into one of three states once attempts stop:

Stripe's recommended default spans two weeks, so a company that never opened that screen has a two-week grace period by accident. Chargebee narrows the same choice to "let the subscription remain active or cancel the subscription at once", and its statuses never mark a failure at all.

Two separate decisions hide inside that window:

• Suspension. Access stops, the record survives, the balance stays collectible. Stripe names this only for unpaid. Access during past_due is left to you, which is why some products lock on day one and others never do.

• Termination. The subscription ends. Stripe's canceled state can't be updated, so the route back is a fresh signup, not a paid invoice.

The customer's view runs on a third clock. Chargebee notes that dunning "emails can be sent irrespective of the dunning attempts", so what the account holder reads bears no fixed relationship to what the processor is doing. Someone can lose access before the first notice arrives. The payment retry schedule is the machine's half of this. The notice cadence and the suspension date are yours.

Does a customer who returns after a card failure belong in the churn count?

Only if the account actually closed and they had to start over. ChartMogul books the return movement when "a formerly paying customer (who had previously churned) moves back onto a paid plan", and books churn when a customer cancels their last subscription. Neither test asks whether the customer chose to leave, so a dead card sorts where a deliberate cancellation does.

Sort the lapse by what happened to the subscription record, not by what happened to the charge:

Rows two and three look identical on a dashboard and behave nothing alike. I've watched the damage surface downstream:

• Cohort curves read tenure from the subscription start date. Terminate at month 26, re-sign at month 27, and a 26-month relationship reports as a dead cohort member plus a new one.

• Acquisition counts inflate, because the returning account lands in a later month's new-logo total.

• Payback and lifetime value run short, since the tenure funding them got cut at a card decline.

Keep the involuntary line out of the churn count until termination fires, tag every closure with the processor's reason code, and link the old subscription to the new one when a terminated account comes back. That last step turns a phantom churn-and-reacquire into a visible MRR movement and keeps revenue churn pointed at customers who left on purpose.

Related terms

A failed payment passes through all of the following before anyone books it as churn:

• Payment retry covers the mechanics that run before the grace window closes, decline codes and network caps included.

• Subscription lifecycle is the state machine a lapsed account moves through.

• MRR movements is where a churn-and-return pair shows up, correctly or otherwise.

• Revenue churn is the dollar-weighted line a mis-booked lapse distorts.

• Gross revenue retention drops on the same event, with no expansion to hide it.

• Revenue leakage is the wider category of earned money that never lands.

FAQ

Is involuntary churn the same thing as passive churn?

Yes. Passive churn, delinquent churn, and payment failure churn all name one event: a subscription ending because a charge didn't clear. Agree on the label and the closure trigger before comparing numbers across two companies.

Which team owns involuntary churn?

Ownership splits, which is why the number often has no owner. Payments owns the credential and the attempt, billing owns the state change and the reason code, finance owns whether the lapse reaches the retention report. Name someone accountable for the grace window or nobody tunes it.

Does an annual renewal that fails count as involuntary churn?

Yes, and it costs more per event than a monthly failure. The charge is larger, so issuer checks flag it more often, and the account has gone twelve months without exercising the stored credential. A monthly subscriber's card gets tested every cycle; an annual one gets tested once.

Should you report involuntary churn as one number to the board?

No. Report it beside voluntary churn, because the two point at different teams. A blended figure sends a retention review hunting for a product problem when the cause sits in payment operations, and it hides that part of the loss is still collectible.