Stripe has a set of built-in dunning settings that control what happens when a subscription payment fails. These settings are buried in the Dashboard under multiple sections, and the defaults aren't always right for your business. Misconfigured settings can mean the difference between recovering a payment and losing a customer.
This guide walks through every relevant setting, explains what it does, and tells you when to change it.
Where to find the settings
In your Stripe Dashboard, go to Settings > Billing > Subscriptions. This page contains the core dunning configuration. There's also a related section under Settings > Billing > Customer emails for controlling Stripe's built-in email notifications.
The settings are grouped into a few categories: retry logic, customer notifications, subscription behavior, and revenue recovery.
Smart Retries
What it is
Smart Retries is Stripe's machine learning system that determines the optimal time to retry a failed payment. Instead of retrying on a fixed schedule (e.g., every 3 days), Stripe analyzes patterns across its network to pick the retry time most likely to succeed.
The setting
Toggle: Smart Retries on/off
When on, Stripe handles the retry schedule automatically. When off, you configure a manual retry schedule (e.g., retry after 3 days, then 5 days, then 7 days).
Recommendation
Keep Smart Retries on. Stripe processes billions of transactions and their retry timing model outperforms fixed schedules for most businesses. They report that Smart Retries recover up to 38% more revenue than manual retry schedules.
The only reason to turn it off: you need precise control over retry timing because your dunning emails are tightly synchronized with specific retry dates. If your Email #2 says "we'll retry tomorrow" but Smart Retries doesn't retry until three days later, the experience is inconsistent.
If you're using a dedicated dunning tool like Rekko that manages its own communication timing, keep Smart Retries on and let the tool handle messaging independently of Stripe's retry schedule.
Retry schedule (manual)
What it is
If you turn off Smart Retries, you configure a manual retry schedule. You specify how many retries and the interval between each.
The setting
Number of retries: 1-4 retries after the initial failure Retry intervals: Number of days between each retry
A common manual schedule:
- First retry: 3 days after initial failure
- Second retry: 5 days after initial failure
- Third retry: 7 days after initial failure
Recommendation
If you insist on manual retries, space them out. Three retries over 7-10 days is a solid default. Front-loading retries (Day 1, Day 2, Day 3) doesn't help because the underlying issue rarely resolves that quickly. A customer with insufficient funds on Monday probably won't have funds on Tuesday, but they might by Friday.
For most businesses, Smart Retries is the better choice. Manual schedules made sense before Stripe had ML-based retry logic. Now they're primarily useful for specific compliance or synchronization needs.
Customer emails
What it is
Stripe can send automated emails to customers when payments fail. These are basic templated emails that notify the customer and include a link to update their payment method.
The settings
Failed payment email: Toggle on/off. Sends an email when a payment attempt fails.
Expiring card email: Toggle on/off. Sends an email before a card expires, prompting the customer to update.
Upcoming renewal email: Toggle on/off. Sends an email before a subscription renews (required in some jurisdictions).
Customization
Stripe lets you customize these emails to a limited degree. You can add your logo, adjust the color scheme, and modify some text. But you can't control the layout, add dynamic content, segment by customer type, or A/B test. The templates are functional but generic.
Recommendation
If you have no other dunning solution: Turn on the failed payment email and the expiring card email. They're better than nothing. Stripe's emails recover some payments with zero effort on your part.
If you use a dedicated dunning tool: Turn Stripe's customer emails off. Running Stripe's emails alongside your own dunning sequence creates confusion. The customer gets two sets of emails about the same problem, often with different wording and different CTAs. Your dunning tool handles this better with proper sequencing, timing, and multi-channel support.
Always keep the expiring card email on unless your dunning tool sends its own pre-expiration notices. Catching an expiring card before the payment fails is strictly better than recovering after failure.
Subscription status after all retries fail
What it is
This setting determines what happens to the subscription when all retry attempts are exhausted and the payment still hasn't been collected.
The options
Mark the subscription as unpaid: The subscription stays active in Stripe's system but is flagged as unpaid. You're responsible for deciding what to do (restrict access, cancel, etc.). The subscription can be reactivated if the customer pays.
Cancel the subscription: Stripe automatically cancels the subscription. The customer loses their subscription entirely. To come back, they'd need to create a new subscription.
Leave the subscription as-is (past_due): The subscription remains in a past_due status indefinitely. Stripe doesn't take further action.
Recommendation
For most SaaS companies, "mark as unpaid" is the right choice. It gives you the most flexibility. You control what happens to the customer's access in your application based on the subscription status. And the subscription isn't destroyed, so reactivation is simple.
"Cancel the subscription" is too aggressive for most cases. It creates friction for customers who want to come back. They need to re-subscribe, potentially losing their plan pricing if rates have changed.
"Leave as past_due" is too passive. Without intervention, customers sit in limbo forever. Your MRR reports become inaccurate because you're counting revenue you'll never collect.
The "unpaid" status strikes the right balance. Your application checks subscription status and restricts access. The customer gets a clear reactivation path. The subscription record stays intact for when they return.
Invoice settings for failed payments
There are additional settings under Settings > Billing > Invoices that affect dunning behavior.
Finalization and payment
Auto-advance invoices: When on, Stripe automatically attempts to collect payment on finalized invoices. Keep this on for subscription invoices.
Days until invoice is due: For invoices that aren't auto-collected, this sets the due date. Typically irrelevant for subscription billing (those are collected immediately), but relevant if you send manual invoices.
Recommendation
Leave auto-advance on. For subscription billing, you want Stripe to attempt collection automatically. The only exception is if you generate invoices that require manual approval before charging (uncommon for SaaS subscriptions).
Revenue Recovery (Stripe-hosted recovery page)
What it is
When enabled, Stripe adds a link to its automated failed payment emails that takes the customer to a Stripe-hosted page where they can update their payment method. This page is branded with your company name and logo.
The setting
Toggle: Revenue Recovery on/off
Recommendation
Turn it on if you're using Stripe's customer emails. It provides a clean, Stripe-hosted payment update page without any development effort on your part. Customers click the link, enter a new card, and the payment is retried automatically.
If you're using a dedicated dunning tool, you might turn this off to avoid conflicting payment update experiences. Your tool likely generates its own payment update links. Having two different update pages (Stripe-hosted and your tool's) can confuse customers.
Card updater
What it is
Stripe participates in card network account updater programs (Visa Account Updater, Mastercard Automatic Billing Updater). When a customer's card is reissued by their bank (new number, new expiration), the card network can automatically provide the updated details to Stripe. The payment method updates silently, and the next charge succeeds without the customer doing anything.
The setting
This isn't a toggle you control directly. Stripe automatically participates in card updater programs for stored payment methods. But you should know it exists because it affects your involuntary churn data.
What to know
Card updater prevents some failures from happening at all. Stripe reports that account updaters prevent roughly 2-3% of subscription payments from failing. That's meaningful.
However, card updater doesn't work in all cases:
- Not all banks participate
- Not all card types are covered
- Some reissuances (e.g., due to fraud) deliberately don't propagate updates
- Debit cards are less consistently covered than credit cards
You'll still have failures that need a dunning workflow. Card updater reduces the volume but doesn't eliminate it.
Payment method settings
Under Settings > Payment methods, you can configure which payment methods are accepted. This indirectly affects dunning.
ACH Direct Debit and SEPA
If you accept bank transfers (ACH in the US, SEPA in Europe), failure patterns differ from cards. Bank debits can fail for insufficient funds, account closed, or authorization revoked. The retry and dunning approach is similar, but bank debit failures typically have fewer retry opportunities and longer settlement times.
Recommendation
Offering multiple payment methods (card + bank debit) can reduce involuntary churn. Customers whose cards frequently fail can switch to bank debit, which has different (and sometimes lower) failure rates. But managing dunning across multiple payment types adds complexity.
Settings for connected accounts (Stripe Connect)
If you're a platform using Stripe Connect, dunning settings work differently.
For Direct charges on connected accounts, the connected account's own settings apply.
For Destination charges or Separate charges and transfers, the platform's settings apply.
If your connected accounts handle their own billing, make sure they've configured their dunning settings appropriately. Many connected accounts use Stripe's defaults and never optimize.
A recommended configuration
Here's a solid baseline configuration for most SaaS companies:
| Setting | Value | Why |
|---|---|---|
| Smart Retries | On | ML-based timing outperforms manual schedules |
| Failed payment email (Stripe) | Off* | Your dunning tool handles this better |
| Expiring card email | On | Prevents failures before they happen |
| Subscription status after retries | Mark as unpaid | Maximum flexibility for reactivation |
| Revenue Recovery page | Off* | Your dunning tool provides its own payment links |
| Auto-advance invoices | On | Standard for subscription billing |
*Turn these on if you're not using a dedicated dunning tool.
When defaults are fine
If you're a small SaaS (under $10K MRR) with limited engineering bandwidth, Stripe's defaults are a reasonable starting point:
- Smart Retries: on
- Customer emails: on
- Revenue Recovery: on
- Subscription status: cancel after all retries fail
This gives you basic dunning with zero engineering effort. You'll recover some failed payments automatically. It's not optimal, but it's infinitely better than having no recovery process.
When to customize
Customize when:
Your involuntary churn rate is above 1% of MRR per month. The defaults aren't recovering enough. You need a dedicated dunning tool with multi-channel sequences, better templates, and proper analytics.
You're above $20K MRR. The absolute dollar amount lost to involuntary churn justifies the time and cost of optimizing. At $50K MRR with 1.5% monthly involuntary churn, you're losing $9,000/year in direct revenue (and much more in compounding loss).
You have specific compliance requirements. Some industries or regions require specific notification language, timing, or opt-out mechanisms that Stripe's default emails don't support.
You want to use SMS. Stripe's built-in dunning is email-only. Adding SMS to your recovery sequence requires a third-party tool.
You need analytics. Stripe shows basic retry success rates. A dedicated tool shows recovery rate by email, by channel, by decline type, by customer segment, and lets you optimize based on data.
The settings described in this guide are the foundation. They determine how Stripe handles retries and basic notifications. Layering a dedicated recovery tool on top gives you the multi-channel sequences, testing capabilities, and analytics needed to maximize recovery.