Voluntary vs involuntary churn in Stripe: split it before you fix it

The two kinds side by side

Stripe’s reference describes the two values this way: cancellation_requested is “canceled explicitly through the API or Dashboard”, and payment_failed is “canceled automatically after payment failure, according to your billing settings”. The same field has two more values: payment_disputed, a cancel after a dispute was opened, and canceled_by_retention_policy, which Stripe uses for expiring test-mode subscriptions. Because cancellation_requested also covers cancels you make yourself in the Dashboard or API, take those out before you read the bucket as customers choosing to leave.

Split your own churn in three steps

1. List the cancellations. Pull the subscriptions that ended in the period, or collect customer.subscription.deleted events as they arrive.
2. Group by cancellation_details.reason. Four buckets at most: cancellation_requested, payment_failed, payment_disputed, anything else.
3. Add the subscriptions that did not cancel. Stripe lets you choose what happens when retries are exhausted: cancel the subscription, mark it unpaid, leave it past due or pause it. Only the first option moves the status to canceled. Count unpaid and past_due subscriptions as their own line, or an involuntary problem will look smaller than it is.

The result is a split like “N cancelled by the customer, N ended on payment failure, N stuck unpaid”. That split, not the overall churn rate, tells you where to spend the next hour.

What Stripe gives you for the involuntary half

• Smart Retries. Stripe describes it as AI choosing the best times to retry failed payments. For new Stripe accounts it is on by default, configured for up to 8 retries within 2 weeks; you can set the window to 1 week, 2 weeks, 3 weeks, 1 month or 2 months.
• A custom schedule instead: up to three retries, each a set number of days after the previous attempt.
• Customer emails when a payment fails, a card expires or a payment method needs an update, and automatic card updates when a customer gets a new card number.
• Automations, a no-code way to build your own recovery logic and different retry policies for different customer segments.

Two limits to know from Stripe’s retry page. Stripe does not retry when no payment method is available, when the card is India-issued, or when the Connect account was disconnected. For hard declines (such as a lost or stolen card) the scheduled retries stay on the calendar, but the charge only executes once a new payment method is on file. For those customers the lever is getting a new card from them, which is a message to the customer rather than a retry setting.

What a cancel flow does for the voluntary half

A cancel flow acts when a customer starts to cancel: it asks why, then offers a pause, a discount or a lower plan that matches the answer, and lets them cancel anyway. It never sees a customer whose card simply declined, so its results belong in their own column. When you judge it, use the cancellation attempts as the denominator and a holdout as the control, as set out in what counts as a save. The reasons it collects are read in reading cancel reasons.

The two halves also meet at one spot: pausing. Stripe can pause an eligible subscription after a payment failure instead of cancelling it, and a cancel flow can offer a pause to someone who says they do not need the product right now. Both arrive as paused subscriptions, so label which one you are looking at.

A short checklist

• Is Smart Retries on, and is the window long enough for your billing cycle?
• What happens to the subscription when retries are exhausted, and are the unpaid or past-due ones counted somewhere?
• Do you split cancellations by cancellation_details.reason every month?
• Does every voluntary cancel go through a page that asks why and keeps “Cancel anyway” one click away?

Related

• How to read cancel reasons and match an offer to each
• What counts as a saved subscriber?
• How to reduce SaaS churn with a cancel flow