Stripe Dunning Settings That Recover More Failed Payments

Stripe dunning settings live mainly in Billing > Revenue recovery, with subscription retries under Retries and customer messages under revenue recovery emails. Start with Smart Retries at the recommended default of 8 tries within 2 weeks, enable failed card payment emails and expiring card reminders, and send customers to a working card update page. If outreach continues after retries stop, leave subscriptions past due while relying on Stripe's hosted link, or mark them unpaid if you have a separate payment update route and want later invoices kept as drafts.

For a founder or billing lead running a US SaaS on Stripe Billing, that is a workable starting point. The buying question comes next. Does your team have time to handle the failures that settings alone cannot resolve, and can you tell which customers need a different message? Configure the basics before paying for another tool, then judge the remaining workload against the price of recovery software.

Stripe dunning settings at a glance

Stripe renames menus from time to time, so labels may differ slightly. These subscription settings are separate from one-off invoice retries, which live under Settings > Billing > Invoices advanced features.

Stripe dunning retries and the window to use

Smart Retries is the sensible starting point for Stripe billing dunning when you do not already have a recovery system. Its available windows are 1 week, 2 weeks, 3 weeks, 1 month and 2 months. The recommended default is 8 tries within 2 weeks. Start there, then review unresolved renewals against the access and outreach policy your team can actually maintain.

A longer window leaves more time to recover a payment, but also means carrying unresolved accounts longer. Do not extend retries simply to postpone an access decision. If your team uses different recovery policies for different customer segments, Stripe Billing automations can apply those policies by segment.

A custom schedule allows up to 3 retries. Each offset is a number of days after the previous attempt, rather than a date measured from the original failure. Write out the resulting sequence before saving it. Fixed timing can suit a defined billing policy, but it gives you fewer attempts and does not make a blocked card chargeable.

Stripe decline codes that stop retries

Stripe does not retry when no payment method is available, the issuer returns a non-retryable code, the card was issued in India, or a Connect account was disconnected. The non-retryable codes are:

• incorrect_number
• lost_card
• pickup_card
• stolen_card
• revocation_of_authorization
• revocation_of_all_authorizations
• authentication_required
• highest_risk_level
• transaction_not_allowed

For these codes, scheduled attempts keep counting but execute only once a new payment method is attached. An increasing attempt count therefore does not prove Stripe sent another charge to the issuer. Inspect the failure reason before telling a customer that another attempt is on its way. Where authentication is required, give the customer the confirmation route instead of expecting an unattended retry to complete authentication.

Also check which payment method failed. Stripe tries the subscription default payment method first, then the subscription default source, then the customer invoice settings default payment method, then the legacy customer default source. Update the field that supplied the failing method. A new customer default can leave a failing subscription default in place.

These card settings should not become your policy for every payment rail. ACH Direct Debit retries apply only to insufficient funds, with a maximum of 2 retries within 40 days.

Stripe subscription status after the last retry

The final action should match what happens in your application and in your recovery messages. A billing status alone is not a complete access policy. Check how your application handles each status before changing the setting.

When your team keeps contacting customers after Stripe stops retrying, prefer marking unpaid or leaving past due over immediate cancellation. Unpaid avoids continuing to charge later invoices, but disables Stripe's hosted update link. Past due keeps billing active, which can create more invoices while the original renewal remains unresolved. Decide which consequence you want before you enable either option.

Pause is not a universal fallback. Eligible subscriptions can pause at the first failed renewal or after retries are exhausted, with no new invoices until resumed. Confirm eligibility and how resumption affects access before choosing it.

Stripe dunning emails customers can act on

Turn on "Send emails when card payments fail" in revenue recovery emails while Stripe owns the recovery workflow. Stripe sends a message after each failed payment with a link to update the payment method. Review the branding settings and destination together, so the customer recognizes the message and can complete the action it requests.

Enable expiring card emails too. Stripe sends these one month before a default card expires, giving the customer a chance to fix the method before renewal. A payment confirmation link handles 3D Secure, and optional reminders help customers finish that step. Treat confirmation as a different task from replacing a lost card.

If you also configure trial end and upcoming renewal messages, keep their purposes clear. Stripe's trial end reminder goes out 7 days before the trial ends. Upcoming renewal emails apply only to charge_automatically subscriptions. These messages use your branding settings, but they do not replace failed payment outreach.

Stripe reminders for manually paid recurring invoices

For unpaid recurring invoices using send_invoice, configure reminders under Settings > Billing > Subscriptions and emails. These customers are expected to pay an invoice themselves, so a card retry schedule does not cover the collection task. If many customers pay by invoice rather than card, accounts receivable automation that chases each open invoice by email and SMS covers that side.

Review that invoice workflow separately from failed automatic renewals. The customer needs a clear route to pay the open invoice, while your billing team needs to know which balances still require follow-up. Do not assume enabling failed card emails has configured reminders for every manually paid recurring invoice.

Stripe hosted payment links and when they stop working

Stripe lets recovery email links lead to its hosted page or to your own page. The hosted option is a practical starting point because you can configure the email without building a separate update flow. Your own destination makes sense when recovery must fit an existing account or billing experience.

The Stripe hosted link stops working when the subscription becomes canceled, incomplete_expired or unpaid, or when the current renewal period has expired. Check those conditions against every message you plan to send after retries end. Leaving a subscription past due does not remove the renewal period limit.

This is why marking unpaid needs an explicit follow-up plan. Do not keep sending a hosted link after changing the subscription to a status that disables it. If you use your own page, verify both the payment update and what should happen to the outstanding invoice and subscription afterward. Saving a card alone is not evidence that the overdue balance was collected.

Stripe dunning testing before customer rollout

Test the complete Stripe dunning process in a sandbox, including the email, destination page, payment method update and final status. Stripe only emails addresses on your verified email domain or active team members in a sandbox. A missing message to an unrelated test address can be a delivery restriction rather than a broken recovery setting.

Use email logs on the Customers page to inspect what Stripe sent. Logs are available for 60 days. Check that a customer can follow the message while the subscription is in the status your policy creates, then confirm what your application does with that status.

For operational checks, invoice.payment_failed carries attempt_count, and the invoice's next_payment_attempt shows the next try. Compare those fields with the actual failure reason. With non-retryable declines, counting a scheduled attempt is different from executing a payment. Your team should be able to explain the next customer action without guessing from the counter.

Where Stripe's dunning settings stop

Stripe covers basic retries and recovery emails, but its standard failed payment email is the same whatever the decline reason. It does not include the next retry date. A customer whose card was stolen needs a replacement card request, while someone facing a temporary funds issue needs a clear account of what happens next. The standard message does not make that distinction.

Hard declines wait for a new card rather than becoming recoverable through more scheduled attempts. Custom schedules stop at three retries. Stripe's dunning settings do not add SMS or an in-app banner, and they do not give you a recovered revenue report by decline reason. Those limits matter when the billing lead is manually sorting failures, rewriting messages and checking which customers have already responded.

RevRescue adds retries timed by decline code and a separate email for each decline reason. Messages include the next retry date in the customer's time zone, use your brand and set Reply-To to your address. The same message goes to the same customer at most once every 20 hours. Our Stripe dunning emails and smart payment retries pages explain those parts of the workflow.

Customers get a secure one click card update page. RevRescue also provides expiring card and unpaid invoice reminders, plus the Revenue at Risk dashboard. Growth and higher plans add SMS with consent and an in-app banner. These are concrete reasons to consider a dedicated dunning software tool when the standard email and manual follow-up leave work unfinished.

The Stripe integration uses a restricted key. When switching retry timing to RevRescue, we recommend turning off Smart Retries so one system owns the schedule. Review overlapping emails at the same time. Plan the handoff around outstanding invoices and your final status policy, using the subscription payment recovery workflow to assess what the customer needs from failure through payment.

How do I set up dunning in Stripe?

Set up dunning in Stripe by opening Billing > Revenue recovery > Retries and choosing your retry policy and final subscription action. Start with 8 tries within 2 weeks, enable failed payment emails, and test the update link. Check manually paid recurring invoice reminders separately under Settings > Billing > Subscriptions and emails.

Does Stripe have dunning management?

Yes, Stripe has dunning management through retry schedules, recovery emails and subscription actions after failed payments. Stripe dunning management is enough for a basic workflow your team can monitor. Add a dedicated tool when you need messages by decline reason, next retry dates, SMS with consent or an in-app banner.

How many times does Stripe retry a failed payment?

Stripe's recommended Smart Retries default is 8 tries within 2 weeks, while a custom schedule allows up to 3 retries. Smart Retries windows range from 1 week to 2 months. Non-retryable declines can keep increasing the scheduled attempt count without executing another payment until a new payment method is attached.

Should I cancel or mark a subscription unpaid after failed payments?

Mark a subscription unpaid when outreach continues through a separate payment route and you want later invoices held as drafts. Cancel when you intend to end the subscription. If outreach relies on Stripe's hosted update link, consider leaving it past due instead, because marking unpaid disables that link and past due continues billing.

When Stripe settings are enough and when to add a dunning tool

Put your MRR into the recovery calculator first. Use its estimate as a starting point, then check your actual failed renewal volume and unresolved balances in Stripe. MRR tells you the applicable plan band. Failure volume tells you whether there is enough recovery work to justify the purchase.

If you are within the Starter MRR band and failures are infrequent enough to review individually, Stripe's settings plus an accountable billing owner can be enough. Keep that setup while customers receive useful messages, update their cards and pay without a growing manual queue. A higher MRR alone is not a reason to add software if failed payment volume remains manageable.

Buy when failed renewals repeatedly exceed what the team can follow up on, or when decline-specific outreach and additional channels address a visible gap. Review failures that remained unpaid after Stripe's sequence and identify the missing action. Compare plausible additional recovery with the plan fee, rather than treating every recovered payment as a gain caused by the new tool.

Yearly billing is 50 percent off, and RevRescue never takes a share of recovered revenue. Choose Starter when you need core recovery within its MRR band. Choose Growth or higher when your MRR requires it or you need SMS with consent and the in-app banner. Check the full pricing, select the plan that fits your MRR and channels, then connect RevRescue and hand over retry timing with a clear policy for outstanding invoices.