How Stripe Smart Retries work, and when to customize retry timing

When a subscription payment fails on Stripe Billing, Stripe can try the charge again automatically. Smart Retries is the setting that decides when. It is Stripe’s recommended option, and many teams turn it on and never look at it again.

That is mostly fine. But it helps to know what Smart Retries actually does, what it cannot do, and the few situations where you should change the defaults. This article sticks to what Stripe’s documentation says, and points out where Stripe does not publish details.

What Smart Retries is

Smart Retries is Stripe’s automatic retry logic for failed invoice payments. Instead of retrying on fixed days (for example 3, 5 and 7 days after the failure), Stripe uses a model to choose when each retry runs. Stripe’s docs describe the model as using time-dependent, dynamic signals to pick the best times.

What Stripe does not publish is the exact list of signals, their weights, or the intervals it will pick for a given payment. Treat Smart Retries as a black box with a few dials around it.

Where it applies

Smart Retries applies to invoices that Stripe collects automatically, which covers most subscription renewals. Invoices you send for manual payment (where the customer pays the invoice themselves) follow Stripe’s automatic collection rules instead, which is a different setup.

Stripe also documents Smart Retries for off-session payments outside of Billing. Check that page for availability in your account, as it may be limited.

The settings you control

In the Stripe Dashboard, the retry settings live in the revenue recovery section of Billing settings. The controls are:

Setting	Options	Stripe’s recommendation
Retry policy	Smart Retries or a custom schedule	Smart Retries
Number of retries (Smart Retries)	Configurable	8 tries
Retry window (Smart Retries)	1 week, 2 weeks, 3 weeks, 1 month or 2 months	2 weeks
Custom schedule	Up to 3 retries, each a set number of days after the previous one	n/a
After the last retry fails	Cancel the subscription, mark it unpaid, or leave it past due	Your choice

The “8 tries within 2 weeks” default comes from Stripe’s Smart Retries page. The labels in your Dashboard may differ slightly over time, so check the page directly.

What the end-of-retries options mean

• Cancel the subscription. The subscription ends. The customer has to start a new one to come back.
• Mark the subscription as unpaid. The subscription stays in place, but Stripe stops attempting payment on new invoices until the situation is resolved. Useful if you want to keep the account and restore access once the customer pays.
• Leave the subscription past due. The subscription keeps running and keeps generating invoices. This is the most lenient option, and it can pile up unpaid invoices if you do not act on it.

Separately, you decide what happens to the unpaid invoice itself (for example, leaving it open or marking it uncollectible). Make both choices on purpose; they change how your MRR and churn numbers look.

What Smart Retries will not do

It will not retry hard declines on its own

Some declines mean the card simply cannot be charged again. Stripe’s docs list the hard decline codes for which it cannot retry automatically:

• 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, Stripe keeps scheduling retries and the invoice’s attempt_count keeps going up, but the charge only actually runs once a new payment method is attached. In other words, the retry schedule is waiting for the customer. If no one asks the customer for a new card, nothing happens.

It does not talk to the customer

Retries are silent. They do not tell the customer anything is wrong. Stripe can send separate customer emails when card payments fail, and a link to confirm payments when the bank requires authentication. Those settings are independent of Smart Retries, so check they are turned on.

It does not know your customers

The model works on payment signals. It does not know that your customers are mostly teachers paid on the last working day of the month, that a customer just emailed support saying they changed banks, or that a B2B customer’s finance team only pays on Tuesdays. That context lives in your systems, not in Stripe’s.

How to see what Smart Retries is doing

You can follow retries in two places:

• In the Dashboard, open the invoice. The timeline shows each attempt and its decline code, plus the next scheduled attempt.
• Through the API and webhooks. The Invoice object has attempt_count and next_payment_attempt fields. Listen to invoice.payment_failed to react to each failure, and invoice.paid to stop any follow-up when it succeeds.

A simple log of each failure (decline code, attempt number, amount, date, whether it was later paid) is enough to measure how retries perform for you. See the measurement section of the complete guide to failed payments for the formulas.

When to customize retry timing

Smart Retries is a good default. Here are the cases where it is worth reconsidering.

1. Your customers are paid on predictable dates

If most of your customers are consumers in the same country, many soft declines will be insufficient_funds near the end of the month. A retry right after common paydays (for example the 1st, the 15th, or the last working day, depending on the country) may do better than a model trained on everyone. You cannot tell Smart Retries about paydays, so this means either a custom schedule or retry logic outside Stripe.

2. Your billing cycle is short

On weekly plans, a 2-week retry window means the next invoice is created before the previous one is resolved. Shorten the window, or use a custom schedule with fewer, closer retries.

3. You sell to businesses

B2B failures are more often about a card that was replaced, an expense limit, or a finance process, and less about timing. Fewer retries and earlier outreach to the right person (often not the user who signed up) tend to matter more than precise retry timing.

4. You need a predictable timeline

A custom schedule makes it easy to align emails with retries (“we’ll try again on Thursday”) and to explain the process to support. Smart Retries is less predictable by design.

5. You want a longer grace period for valued customers

Stripe’s retry settings are account-wide. If you want a longer window for annual or long-tenured customers, you need logic of your own, such as pausing the default flow for those customers and handling them separately.

Smart Retries vs a custom schedule

	Smart Retries	Custom schedule
Timing	Chosen by Stripe’s model	Fixed days you set
Number of retries	Configurable (8 recommended)	Up to 3
Window	1 week to 2 months	Sum of your intervals
Uses your customer data	No	No, but you choose dates with it in mind
Predictable for emails and support	Less	Yes
Effort	None	Low

If you build your own retry logic (for example, retries timed to the customer’s local time and payday), you generally turn Stripe’s automatic retries off for those invoices so the two do not compete. Test this carefully in test mode first.

A practical setup for most SaaS teams

1. Keep Smart Retries on, with the recommended 8 tries in 2 weeks for monthly plans.
2. Set the end-of-retries action deliberately. “Mark unpaid” is a good middle ground if you want to keep the account and restore access on payment.
3. Turn on Stripe’s failed payment emails at minimum, or better, run your own dunning sequence for days 0, 3, 7 and 14.
4. Treat hard declines differently: ask for a new card immediately.
5. Turn on authentication emails if you sell in Europe.
6. Log every failure and measure recovery by cohort.
7. Revisit the settings once you have a few months of data. If most of your failures are end-of-month insufficient_funds, test payday-aligned timing.

How NoChurn helps

NoChurn works alongside Stripe. You can keep Stripe Smart Retries, or let NoChurn retry failed payments at times based on likely paydays and the customer’s local time. Either way, it sends AI-written recovery emails (day 0, 3, 7 and 14 by default) in the customer’s language, reviewed before sending, with a link to a hosted card update page. Card data stays with Stripe; NoChurn never sees card numbers.

It connects to Stripe in one click. Pricing depends only on MRR, with every feature on every plan and no share of recovered revenue. See failed payments and pricing.