Smart Retries vs a Fixed Retry Schedule: Which Recovers More?

Originally published on the RetryFix blog.

Smart Retries and a fixed retry schedule answer one question: when to charge a failed card again. They do not decide whether that card can still pay, and they do not tell the customer anything. Stripe recommends Smart Retries. Its revenue recovery guide says Smart Retries are more effective than scheduled retries. The Smart Retries page says the model chooses times to increase the chance of paying the invoice, and that this is a more targeted approach than traditional rules-based retry logic. Neither page publishes a recovery percentage, and neither compares Smart Retries with a named calendar such as day 1, day 3, and day 7.

So the answer to "which recovers more" is that qualitative claim from Stripe, plus a limit the claim does not spell out. A soft decline can still clear on a later attempt, and that is where timing can matter. A hard decline, or a card the customer has to replace, will not clear because the clock was smarter.

This page is that comparison. What the setting is, including where it lives in the Dashboard, is in what Stripe Smart Retries are. Why a timing layer on its own still leaves failed payments unrecovered is in why Smart Retries alone are not enough. The rules around a retry (whether to charge again, when, how many times, and when to stop) are in what payment retry logic is.

What each setting actually controls

Stripe gives you two retry modes for a failed subscription or invoice charge. Both are configured under Billing → Revenue recovery → Retries. The docs are Smart Retries.

	Smart Retries	Fixed (custom) schedule
Who picks the moment	Stripe's model, per attempt	You, as a number of days after the previous attempt
How many retries	A count you set, inside a window of 1 week, 2 weeks, 3 weeks, 1 month, or 2 months. Recommended default: 8 tries within 2 weeks	Up to 3
Same gap for every card	No. The model can move an attempt	Yes. The gaps you typed are the gaps every card gets
Emails the customer	No	No

Stripe's wording for the model is specific, and it is not a recovery rate. Using AI, Smart Retries chooses the best times to retry failed payment attempts to increase the chance of successfully paying an invoice. The signals it names are time-dependent: how many different devices have presented that payment method in the last few hours, and time of day. Stripe's own example is that payments on debit cards in certain countries might be slightly more successful at 12:01 AM in the local time zone. It then says it learns from new transactions across Stripe, which makes this a more targeted approach than traditional rules-based retry logic.

People often call this machine-learning timing. Stripe's docs call it an AI model, and they describe it with the signals above rather than with a recovery rate. A custom schedule is the override. You disable Smart Retries and type the gaps yourself. You get at most three retries. Each one is a number of days after the previous attempt, not a list of calendar dates Stripe stores as "day 1, day 3, day 7".

Both modes fire invoice.payment_failed, increment attempt_count, and set next_payment_attempt (with the automations exception Stripe documents on that same page). Both charge the same payment method, in Stripe's order: the subscription default, then the customer default. Both stop according to the ending you chose: cancel, mark unpaid, leave past due, or pause when the subscription is eligible. After the final attempt, Stripe makes no further payment attempts.

The setup walkthrough, including which of those endings to pick, is in how to retry failed Stripe payments.

What a day 1 / day 3 / day 7 schedule means in Stripe

"Payment retry schedule" usually means a fixed calendar: try again the next day, then a couple of days later, then about a week out. That shape is popular because a person can explain it, and because an email can be written to land in a gap you already know.

Stripe's custom control does not ask for those three dates. It asks for up to three gaps, each counted from the previous attempt.

Here is one illustration of how the control can land near that calendar. It is not a preset Stripe publishes, and it is not a recovery rate. The first charge fails on a Monday. You set the retries to 1 day, then 2 days, then 4 days. The next attempts fall on Tuesday, Thursday, and the Monday after that: about day 1, day 3, and day 7 after the failure. Change the failure's weekday and the weekdays move with it. Change any gap and the shape is no longer 1 / 3 / 7.

Smart Retries will not promise those three dates. You choose how many tries, and the longest the window may run. The recommended default is 8 tries within 2 weeks. Inside that window the model picks each moment. You can read next_payment_attempt when you want to know what it chose. You cannot type "Friday" into it.

Those day-1, day-3, and day-7 labels also show up as an email ladder. That is a different calendar. The reminders RetryFix describes publicly, on day 1, day 3, and day 7, are notices, not charges. Retries can fall on other days. Treat that ladder as an example of the emails, not as a recovery rate, and not as the charge schedule above. The notes are in what dunning is.

Soft declines: where timing can change the result

A soft decline is a refusal that does not say the card is finished. The same card might still pay later, or the customer might need to do one thing first. The codes, and when a retry is worth running at all, are in how to reduce soft declines. The short version for this comparison:

• insufficient_funds. The card did not have enough for this charge. A later attempt can clear if the balance changes. Waiting is the part of the problem a schedule can touch. Stripe's next step for the code is still another payment method. A retry is allowed. It is not a promise.
• do_not_honor and generic_decline. The issuer declined and did not say why. These are not on Stripe's do-not-retry list. A spaced attempt can catch a temporary block. It cannot make the customer call their bank.
• processing_error, issuer_not_available, and reenter_transaction. Something in the path failed. Stripe's next step is to attempt the payment again.

Stripe's next step for each code is on its decline codes page. This is the pile where Smart Retries and a fixed schedule can actually disagree, because a later charge on the same card can still collect.

Smart Retries is built for the case where you do not know when that will be. The model can use signals you do not have, including the time-of-day example Stripe publishes. A fixed 1 / 3 / 7 shape applies the same gaps to every card. It cannot move one attempt to the time of day in Stripe's debit-card example. It uses the gap you typed, including when the balance is not coming back that day.

A fixed schedule is the better fit when you already know a date the model does not. A segment that is paid on a Friday is the usual example. You want the attempt on that Friday, not on a night the model prefers for debit cards in general. You accept the cap of three retries, and you accept that every card on that policy gets the same gaps. That is a reason to type the days. It is not a published lift over Smart Retries. Stripe does not give you one.

If you have no such date, leave Smart Retries on. That is Stripe's recommendation, and it is the setting their docs describe as more targeted than a rules-based schedule. "More targeted" is their claim about the method. It is not a percentage, and this page will not turn it into one.

Hard declines: the schedule does not collect them

Some failures will not pay on this card no matter which minute you pick.

Stripe will not execute a live retry when the issuer returns a hard decline code on its published list, including incorrect_number, lost_card, stolen_card, pickup_card, and authentication_required. The retry slot stays on the schedule, and attempt_count still increments, but the charge does not run until a new payment method is attached. That rule sits on the same page as both modes. A custom schedule does not get a live charge on those codes either.

expired_card is not on that list. Neither is restricted_card. Both settings can still charge an expired card, the same way they charge a soft decline. A better clock does not replace the number. How to split that slice in your own Stripe data, and what it costs to keep retrying it, is in hard declines vs soft declines.

Stripe also skips the retry entirely, under either mode, when no payment method is available, the card is India-issued, or the Connect account has been disconnected. A schedule cannot optimise a charge Stripe will not run.

The customer a retry never reaches

Timing assumes the card can change on its own. A balance can be topped up. A temporary block can lift. An expired card, a cancelled card, and a charge that needs the customer to authenticate do not change because you waited until Friday or until 12:01 AM.

Neither setting writes to the customer. The email is a separate Stripe Billing control, Send emails when card payments fail. Stripe's revenue recovery guide recommends that email alongside retries. The retry still does not send it. The email is what tells the customer which card failed, whether they have to act, and where to add a payment method the next attempt will actually charge. That process, and how the notices sit in the gaps between attempts, is dunning.

This is the gap a schedule comparison cannot close. Smart Retries can pick a better moment for insufficient_funds. A fixed schedule can put that moment on a payday you already know. If the card on the subscription is expired, both of them are charging the wrong object until the customer replaces it. The limitations of stopping at the timing layer are written out in why Smart Retries alone are not enough. This page does not repeat that argument. The comparison only needs the conclusion: pick the schedule for the failures a later charge can still collect, and send the notice for the failures it cannot.

Two practical details sit next to that notice.

The email and the retry have to name the same card. Stripe retries one payment method, subscription default first. If the customer updates a different card, the next attempt misses it. The soft-decline page walks through that order.

One sender. If Stripe's failed-payment email stays on while you also send your own, the customer gets two threads. Pick one.

On RetryFix, recovery emails go out in your company name, with a line saying RetryFix sent them on your behalf. You do not edit the wording. Branded sending is included on both plans, Pay on recovery (10% of recovered revenue) and Flat rate (£49). The emails are the customer-facing sequence on top of your processor's retries. They are not a second retry clock, and they do not replace the Smart Retries or custom schedule you set in Stripe.

Which one to leave on

Decide from the failure in front of you, not from the name of the feature.

Leave Smart Retries on when you do not know the day the balance is likely to change. Use them for soft declines where a later attempt on the same card is still allowed, and where you would rather have Stripe's model space the tries than type three gaps and stop. The recommended default, 8 tries within 2 weeks, is Stripe's, not a recovery target. You can shorten the window. You should not read "8" as "8 will recover more than 3". Stripe does not say that.

Use a fixed schedule when a segment has a date you trust, you want the attempt on that date, and you accept at most three retries with the same gaps for every card on that policy. Switching to it means disabling Smart Retries. Stripe also says you can use automations to create different retry policies for different customer segments. That is a Dashboard feature on the same docs page. It is not a claim that one segment's payday schedule recovers a measured share more than the model.

Do not use either schedule as the recovery plan when the code is on Stripe's do-not-retry list, or when the card is expired or otherwise finished. Stop charging that card. Ask for a new one, the same day, while the update link still works. Then let the next attempt, whichever clock you left on, charge the method the customer just added.

If you want a single default for the whole account and you have no payday to aim at, use the one Stripe recommends. Spend the effort on the split between soft and hard, and on the email in the gap. That split decides the next action. Swapping the model for a calendar, with no date to aim at, does not.

Common questions

Does Stripe Smart Retries recover more than a fixed retry schedule? Stripe's revenue recovery guide says Smart Retries are more effective than scheduled retries. The Smart Retries page says the model chooses times to increase the chance of paying the invoice, and that this is more targeted than rules-based retry logic. Neither page publishes a recovery percentage, or a comparison against day 1, day 3, and day 7. Timing can matter for a soft decline. It does not collect a card Stripe will not charge, or a card the customer has to replace.

What is a fixed retry schedule in Stripe? A custom retry schedule. You turn Smart Retries off and set up to three retries, each a number of days after the previous attempt. A day 1 / day 3 / day 7 calendar is something you can approximate with those gaps. It is not a labelled preset.

Should I turn Smart Retries off? Stripe recommends leaving them on. Turn them off when you have a specific reason to pick the days, such as a known payday for a segment, and you accept the three-retry cap. Do not turn them off in search of a recovery rate. Stripe has not published one.

Will a better retry schedule fix an expired or declined card? Not if this card cannot pay. Codes on Stripe's hard-decline list do not get a live retry until a new payment method is attached, under Smart Retries or a custom schedule. expired_card can still be charged, and charging it again does not update it. The customer has to add a card. That is dunning, not a schedule.

Do Smart Retries email the customer? No. Neither does a custom schedule. Customer emails are a separate revenue-recovery setting. The retry is the attempt. The email is how a customer whose card will not clear finds out, and how they fix it before the next attempt.

Where to start

Open a handful of recent failed subscription invoices. Read the decline code before you read the schedule.

If the code is a soft decline and you have no date the money arrives, confirm Smart Retries are on and that the window is the one you meant. If one segment really is paid on a known day, a custom schedule can put the next attempts on the gaps you choose. Write the date down as the reason. A wish to tighten the retry policy, with no date and no decline code behind it, is not a result.

If the code is on Stripe's do-not-retry list, or the card is expired, the schedule is the wrong tool. Send the notice. Check that an updated card lands on the payment method the next attempt will charge.

On RetryFix, recovery emails go out in your company name, with a line saying RetryFix sent them on your behalf. You do not edit the wording. Branded sending is included on both plans, Pay on recovery (10% of recovered revenue) and Flat rate (£49). RetryFix never holds or moves your money; recovered payments land in your own Stripe account.