Stripe dunning: how to stop retries and cancel after N failed attempts

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.

1. 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.

1. Confirm Smart Retries is on so attempt timing adapts to decline-code signals.

Expected: Retries land at the most likely-to-succeed times.

1. Build the terminal webhook handler: on customer.subscription.deleted after dunning, trigger win-back outreach.

Expected: Exhausted dunning converts into a recovery campaign.

1. 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