What Stripe's Retry Schedule Does Not Do

Eight tries in two weeks is a suggestion, not a rule

Stripe's retry documentation recommends Smart Retries and names a recommended default setting of 8 tries within 2 weeks. It is a setting you configure in the Dashboard, so the policy on your account may differ. Smart Retries can run for 1 week, 2 weeks, 3 weeks, 1 month or 2 months, or you can turn it off and write a custom schedule of up to three retries.

A recommendation is tuned to a typical subscription business. It cannot know what a lost subscriber is worth to you, how long you are willing to leave someone with access and no payment, or whether your customers pay by card at all. Those are your numbers, and the setting only reflects them if somebody typed them in.

Some retries are scheduled and never run

The same page lists hard decline codes that Stripe cannot retry: 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 these, the documentation says retries continue to be scheduled and the attempt count keeps incrementing, but a retry only executes once a new payment method is detected. An unexecuted retry does not create a new charge.

That detail matters if your reminder emails key off the attempt number. On a hard decline the number can climb while no charge is attempted, so "final notice at attempt four" could fire without four real charge attempts. That consequence is my inference from the documented behaviour. Read what the number means in your own setup before you build a message sequence on it.

A decline code still needs a message

Stripe's decline-code table gives a next step per code, and for most card declines that step is for the customer to act. An insufficient_funds decline says the customer should use another payment method. An expired_card says the customer should use another card. For generic_decline and do_not_honor, the table says the customer should contact the card issuer.

Insufficient funds is not on the hard-decline list, so the retry schedule still applies to it. Both pages can be true at once: a retry may land after payday, and the customer may still be better off hearing from you than waiting. That is my reading of the two pages together, not something either page states. The point is that retry timing and customer contact are separate decisions, and a schedule only makes the first one. Our post on decline codes and the state the API cannot give you covers the one failure state that has no code at all.

Local payment methods are off by default

Stripe's page says it does not automatically retry failed payments made with local payment methods unless you turn that on. When you do, the documented limits are narrow. For SEPA Direct Debit the only retryable failure is insufficient funds, with a maximum of 2 retries over 30 days. ACH Direct Debit is also insufficient funds only, with 2 retries over 40 days. Bacs is the same shape at 2 retries over 30 days. The same table lists 1 retry over 30 days for Canadian pre-authorized debit and New Zealand BECS, and 4 over 30 days for Australian BECS.

If you bill European customers by direct debit and never opened that section, a failed debit may simply sit there. A card-shaped retry plan does not carry over to a bank debit.

Three questions before you accept the schedule

None of this says the default is wrong. It says the default answers one question, when to try the charge again, and leaves three to you.

• What does a lost subscriber cost? If one account is worth a lot, a two week silent window is a long time to wait. Our piece on why standard dunning fails high-value accounts goes into that.
• What happens to access while retries run? Stripe lets you cancel the subscription, mark it unpaid, or leave it past due when retries end, and pause it if the subscription is eligible. Each one is a business decision with a different cost, and it only applies after the last attempt.
• Who tells the customer, and when? A retry on its own tells the customer nothing. If the first they hear of a failed payment is a cancellation, the retries ran as configured and the relationship still suffered. See how we think about intercepting a failed payment while the customer can still fix it.

Sources: Stripe documentation pages on automating payment retries and on decline codes, read on 26 October 2026. Check them again before you change a live setting, because Stripe edits these pages. More on how we approach this work is on our failed payment recovery page.