## TL;DR

Set your retry and cancellation policy in the billing settings (or via subscription schedules): define max retry attempts and what happens at exhaustion, usually canceling the subscription. Stripe's default Smart Retries handle spacing; you define the end. After cancellation, route the customer to a win-back flow instead of silent churn.

## Steps

1. Open billing settings and find the failed-payment retry configuration.
   Expected: You see the current attempt count and timing policy.
2. Set the maximum attempts (common: 4 attempts over ~2-3 weeks) and the terminal action: cancel the subscription.
   Expected: Dunning now has a defined end instead of running forever.
3. Confirm Smart Retries is on so attempt timing adapts to decline-code signals.
   Expected: Retries land at the most likely-to-succeed times.
4. Build the terminal webhook handler: on customer.subscription.deleted after dunning, trigger win-back outreach.
   Expected: Exhausted dunning converts into a recovery campaign.
5. Monitor the involuntary churn rate before and after the change.
   Expected: You can prove the bounded policy beats endless retries or none.

## When to use

- You want dunning to end after N failures
- Endless retries annoy customers or waste fees
- Involuntary churn needs a defined process

## When not to use

- You run dunning emails manually outside Stripe
- You want to keep retrying indefinitely for high-value accounts (segment instead)
- Failures are authentication_required (fix the 3DS flow first)

## Compatibility

Stripe Billing; retry settings in dashboard billing configuration. Smart Retries available on Billing Scale and by request.

## Variant phrasings

### ### Stripe stop retrying failed payments

### ### cancel subscription after failed payments Stripe

### ### dunning attempt limit Stripe Billing

## Root cause

Unbounded retries cost transaction fees, train customers to ignore billing emails, and keep dead subscriptions inflating MRR. A bounded policy with a terminal action converts ambiguous non-payment into a clean cancel event your win-back system can actually work with.

## Edge cases

- High-value accounts deserve a manual-review exception before auto-cancel
- Pause instead of cancel can preserve the subscription for win-back; choose deliberately
- Changing the policy mid-dunning affects in-flight retry sequences; check current behavior first

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MXNJK6ahobaz6Pp6bSLkpA