Stripe Billing Recovery Settings: The Recommended Setup

Why Your Stripe Settings Matter More Than You Think

Most SaaS founders turn on Stripe Billing, create a few prices, and never open the revenue recovery settings again. That leaves recovery on whatever defaults the account started with, and those defaults don't always match your business.

Failed payment recovery in Stripe depends on five groups of settings:

1. Retries — how often and for how long Stripe re-attempts a failed charge
2. End-of-retry status — what happens to the subscription when retries run out
3. Customer emails — whether customers are told their payment failed (and how they fix it)
4. Payment update destination — where the "update your card" link sends people
5. Automations — different rules for different customer segments

None of these require code. This guide walks through where each one lives in the Dashboard today, what we recommend setting it to, and why. For the theory behind retry timing, see the best retry schedule for failed payments. For what Stripe's tools can't do on their own, see Stripe Smart Retries vs. dunning software.

1. Retries: Turn On Smart Retries

Where: Billing → Revenue recovery → Retries

Recommended: Smart Retries on, 8 tries within 2 weeks as a starting point.

Stripe offers two retry modes for subscription payments:

| Mode | How it works | Limits | |------|-------------|--------| | Smart Retries | An AI model picks the retry times with the highest predicted chance of success | You choose the number of tries and a window of 1 week, 2 weeks, 3 weeks, 1 month, or 2 months | | Custom retry schedule | You set fixed intervals yourself | Up to 3 retries, each a set number of days after the previous one |

According to Stripe's retry documentation, the recommended default is 8 tries within 2 weeks. Smart Retries uses signals a fixed schedule can't see, such as how recently a card was used on other devices and the time of day when payments from a given card type tend to succeed.

There's rarely a good reason to prefer the custom schedule for card payments. Three fixed retries will cover fewer payday cycles than eight well-timed ones.

When to Stretch the Window

Two weeks suits most monthly B2C and SMB subscriptions. Consider 3 weeks or 1 month if:

• Your customers are mostly businesses paying with corporate cards, where getting a card replaced can take an internal approval
• You sell annual plans with high invoice values, where it's worth waiting longer for one payment
• Your customers are concentrated in markets with monthly (not bi-weekly) pay cycles

A longer window means the subscription stays in past_due longer, so decide how much access a past-due customer keeps in your app.

What Retries Can't Fix

Stripe won't execute a retry if the issuer returned a hard decline. The docs list these as incorrect_number, lost_card, pickup_card, stolen_card, revocation_of_authorization, revocation_of_all_authorizations, authentication_required, highest_risk_level, and transaction_not_allowed. For those, retries stay scheduled but only run once a new payment method is on file.

In other words: for hard declines, recovery depends entirely on the customer updating their card. That's why the email settings below matter as much as the retry settings. More on the difference in soft decline vs. hard decline.

Local Payment Methods

On the same Retries page, there's a Local payment methods section. By default, Stripe does not retry failed debits like SEPA Direct Debit, Bacs, or ACH. If you accept them, turn retries on. Per Stripe's docs, only insufficient-funds failures are retryable for these methods, with network-specific caps (for example, SEPA allows 2 retries within 30 days).

2. End-of-Retry Status: Choose Deliberately

Where: Alongside your retry policy under Billing → Revenue recovery → Retries

Recommended: Mark the subscription as unpaid for most SaaS.

When the last retry fails, Stripe moves the subscription to one of three states:

| Setting | Resulting status | What happens next | |---------|-----------------|-------------------| | Cancel the subscription | canceled | Terminal. The subscription can't be reactivated; the customer must subscribe again | | Mark the subscription as unpaid | unpaid | Invoices keep being generated but stay in draft. Paying the open invoice reactivates the subscription | | Leave the subscription past-due | past_due | Invoices keep being generated and charged per your retry settings |

We recommend unpaid because it keeps the door open. A customer who shows up three weeks later with a new card can pay and pick up where they left off, with the same subscription, price, and history. Canceled subscriptions lose that, and anything grandfathered on an old price goes with it.

The trade-off is reporting hygiene: unpaid subscriptions still exist, so make sure your app revokes access for them and your metrics don't count them as active. We cover the full decision, including when cancel is the right call, in Stripe past_due vs. unpaid vs. canceled.

3. Customer Emails: Turn On the Recovery Emails

Where: Billing → Revenue recovery → Emails, plus Settings → Billing → Subscriptions and emails under Email notifications and customer management

Retries only fix failures that resolve themselves. Everything else needs the customer to act, and they can't act if nobody tells them. Stripe's customer email docs describe these toggles:

| Email | Setting name | Recommended | |-------|-------------|-------------| | Failed payment | Send emails when card payments fail | On — sent after each failed payment, with a link to update the payment method | | Expiring card | Send emails about expiring cards | On — sent 1 month before the default card expires | | Payment needs confirmation (3D Secure) | Send a Stripe-hosted link for customers to confirm their payments when required | On — essential if you have European customers (SCA) | | Confirmation reminders | Send reminders if payment confirmation isn't completed | On | | Upcoming renewal | Send emails about upcoming renewals | On for annual plans; optional for monthly | | Trial ending | Send a reminder email 7 days before a free trial ends | On if you run trials |

The expiring-card email is the cheapest recovery you'll ever get. It prevents failures before they happen, and customers who update a card ahead of time never enter your dunning flow at all. More on this in credit card expiration churn.

The 3D Secure email is easy to overlook. When a bank requires authentication on a renewal, the payment fails with authentication_required, a hard decline that retries can't fix. Without this email, the customer has no way to complete the authentication.

Know the Limits of Stripe's Emails

Stripe's emails use your branding settings (logo, icon, colors), but the copy is Stripe's. You can't write a different message for an expired card vs. insufficient funds, add a save offer, or schedule a multi-step sequence. They're a good baseline, not a full dunning program.

To test them, note that Stripe doesn't send customer emails in a sandbox unless the customer's address belongs to your verified email domain or an active team member.

4. Payment Update Link: Point It at the Customer Portal

Where: Settings → Billing → Subscriptions and emails

Recommended: Link to a Stripe-hosted page, and activate the customer portal so customers can also manage their payment methods themselves.

Failed payment, expiring card, renewal, trial ending, and payment confirmation emails all include a link to update the payment method. You choose the destination:

• A Stripe-hosted page — Stripe generates a secure, private URL where the customer updates the card for that subscription and pays any outstanding invoice
• Your own subscription management page — only worth it if your page is genuinely faster than Stripe's

The Stripe-hosted option wins for most teams: no login, no password reset, mobile-friendly, and localized. Every extra step between "your payment failed" and "card updated" costs recoveries.

Two details worth knowing from Stripe's docs:

• The hosted link stops working if the subscription becomes canceled, incomplete_expired, or unpaid. That's another reason to put your own recovery emails in front of the final retry, not after it.
• A card update is used for the next scheduled attempt. If you want the outstanding invoice paid immediately, the hosted page handles that; a custom page needs to do it too.

While you're in the customer portal settings, look at the cancellation page options. You can collect cancellation reasons and offer a coupon to customers who try to cancel. That's voluntary churn rather than failed payments, but it takes five minutes.

5. Card Updates: Understand What Happens Automatically

Where: No toggle to hunt for. Stripe works with card networks to update saved cards automatically.

Per Stripe's card documentation, when an issuer replaces a card (expiry, loss, theft), Stripe tries to update the saved details so the next charge goes through. Two caveats:

• It's widely supported in the US for Visa, Mastercard, American Express, and Discover. International support varies by country and issuer.
• You can't tell in advance which cards support it.

So if you sell mostly to European customers, don't assume the updater will catch expiring cards. That makes the expiring-card email from step 3 even more important. If you track card changes in your own database, listen for the payment_method.automatically_updated webhook.

6. Automations: Segment Your Recovery

Where: Billing → Revenue recovery → Automations

Recommended: Start with one or two automations. Don't rebuild your whole policy here.

Stripe Billing automations let you attach different recovery behavior to different customers. A workflow has a trigger (for example, Subscription payment fails), optional filter conditions (customer or invoice metadata, invoice amount, subscription interval, product), and actions such as Set retry policy, Mark subscription unpaid, Cancel subscription, Mark invoice uncollectible, or Send team email.

Two automations worth setting up:

1. High-value failure alert. Trigger: Subscription payment fails. Condition: invoice amount above your threshold (say, $500). Action: Send team email. A founder emailing a key account personally recovers payments no automated email will.
2. Longer window for annual plans. Trigger: Subscription payment fails. Condition: subscription interval is yearly. Action: Set retry policy with a longer window. One annual invoice is worth twelve monthly ones, so give it more time.

Automations also change where the next retry time appears: next_payment_attempt is set on invoice.updated webhooks rather than invoice.payment_failed. If your app reads that field, update your webhook handler.

The Recommended Setup: Checklist

| # | Setting | Where | Recommended value | |---|---------|-------|-------------------| | 1 | Retry mode | Revenue recovery → Retries | Smart Retries | | 2 | Retry policy | Revenue recovery → Retries | 8 tries in 2 weeks (3 weeks–1 month for B2B or annual) | | 3 | Local payment method retries | Revenue recovery → Retries | On, if you accept SEPA / Bacs / ACH | | 4 | End-of-retry status | Revenue recovery → Retries | Mark the subscription as unpaid | | 5 | Failed payment emails | Revenue recovery → Emails | On | | 6 | Expiring card emails | Revenue recovery → Emails | On | | 7 | 3D Secure confirmation emails + reminders | Subscriptions and emails | On | | 8 | Renewal reminders | Subscriptions and emails | On for annual plans | | 9 | Payment update link | Subscriptions and emails | Stripe-hosted page | | 10 | Customer portal | Customer portal settings | Activated, payment method updates allowed | | 11 | Branding | Settings → Branding | Logo, icon, and colors set (emails and hosted pages use them) | | 12 | High-value failure alert | Revenue recovery → Automations | Send team email above your threshold |

This takes about 20 minutes and costs nothing beyond your existing Stripe Billing plan.

How to Know If Your Settings Are Working

Settings are a hypothesis. Check the numbers a month later. Stripe's recovery analytics show failure rate and recovery rate over time. They split recoveries into retries, emails and a catch-all "Other", but they don't show recovery by decline code or how much MRR is at risk right now. We cover those blind spots in what Stripe's recovery analytics doesn't tell you, and the manual workaround in how to find failed payments in Stripe.

For a faster snapshot, the free Rechurn audit reads your Stripe account with a restricted, read-only key and reports:

• MRR at risk from past_due subscriptions
• Failed payment volume over the last 30 days
• Failure reasons broken down by decline code
• Retry pattern analysis
• Card brand and country breakdown
• A playbook for your top failure reason

It takes about 3 minutes, needs no account, and the key is discarded after the report. If most of your failures turn out to be hard declines or expired cards, that tells you retry settings alone won't close the gap.

When Settings Aren't Enough

A well-configured Stripe account is the baseline. The limits are structural:

• One generic email per failure. Same copy for an expired card and insufficient funds, no escalation, no personalization.
• No save offers. Customers who fail to pay because the price stopped feeling worth it get no discount, pause, or downgrade.
• Emails come from Stripe's template. They don't read like a message from you.

That gap is where a dedicated dunning tool comes in. Rechurn runs on top of Smart Retries rather than replacing them: a 6-email sequence over 14 days, with decline-aware copy written for each customer, sent during their local weekday business hours, a one-click card update link through the Stripe Billing Portal, and a save offer (discount, pause, or downgrade) on day 12. The sequence stops as soon as the card is updated. Pricing is 15% of the revenue Rechurn's emails recover, with no monthly fee. Payments Stripe recovers on its own retries are never billed.

Whether you add a tool or not, get the settings above right first. They're free, and everything else builds on them.

Key Takeaways

1. Turn on Smart Retries at 8 tries in 2 weeks, and stretch the window for B2B or annual plans
2. Retries can't fix hard declines. Those need the customer to update their card, so emails matter as much as retries
3. Mark subscriptions as unpaid, not canceled, when retries run out, so late payers can reactivate
4. Turn on failed payment, expiring card, and 3D Secure emails. The expiring-card email prevents failures before they happen
5. Send the update link to a Stripe-hosted page and activate the customer portal
6. Don't count on automatic card updates outside the US. Coverage varies by country and issuer
7. Use automations sparingly and always with a filter. An unfiltered automation replaces your defaults
8. Check the results after a month with Stripe's analytics or a free audit