DEV Community: Paul Hartness

The Dunning Process, Step by Step (with a Stripe Timeline)

Paul Hartness — Tue, 10 Nov 2026 11:00:42 +0000

Originally published on the RetryFix blog.

The dunning process is the cycle a subscription business runs on one failed renewal: retry where a later charge can still collect, tell the customer what to fix, keep a window open while that happens, and apply an ending you chose if the invoice is still open. This page is that cycle, mapped onto Stripe. What the word means, how dunning differs from retry logic and from Smart Retries, and what each notice should say, is in what dunning is.

The window is not an industry standard number of days. It is the retry schedule on the account. The emails are not the charge dates. Stopping means a Stripe outcome you can point at, on a named invoice.

One cycle, one invoice

A dunning cycle is one pass of that process for one invoice. It starts when a renewal charge fails. It ends when that invoice is paid, or when the schedule's maximum days have passed and Stripe applies the ending you set.

The next invoice is a new cycle. If you leave the subscription past_due, Stripe still creates later invoices and attempts them under the same retry settings. Those later charges are not extra attempts on the invoice that already finished its retries. After the final payment attempt, Stripe makes no further payment attempts on that invoice.

This page is the renewal. The first invoice on a new subscription is a different clock. While the subscription is incomplete, Smart Retries and a custom schedule do not retry it. The customer has 23 hours to pay. After that the subscription becomes incomplete_expired and the invoice is void. Do not line the day 1, day 3, and day 7 notices up against that 23-hour window. They belong to a failed renewal.

Stripe does not put the cycle under one control labelled "dunning". Revenue recovery is the set: retries, customer emails, automations, and automatic card updates. The Dashboard path for the clock is Billing → Revenue recovery → Retries. The setup walkthrough is in how to retry failed Stripe payments.

The Stripe timeline, step by step

Read one failed renewal from the decline to the ending. The objects below are the ones Stripe already writes.

1. The renewal fails

Stripe sends invoice.payment_failed. The invoice stays open. attempt_count on that event is how many attempts have been made so far. If another attempt is still allowed, next_payment_attempt is when Stripe will try again. On an account using automations, that field is set on invoice.updated instead of on invoice.payment_failed.

A failed payment on the latest finalized invoice can move the subscription to past_due. That status means the payment failed or was not attempted. It does not, by itself, promise another charge. Your retry settings decide whether one is coming.

The customer still has the product. That is the open window. The written notice, and how a letter, a notice, and an email are the same job in different formats, is in what a dunning letter is.

2. Retries follow the schedule you already set

Stripe gives you two ways to time the next charges. Both live under Retries.

Smart Retries. You set how many retries, and a maximum duration: 1 week, 2 weeks, 3 weeks, 1 month, or 2 months. On a new Stripe account, Smart Retries start on, at up to 8 retries within 2 weeks. Inside that window Stripe chooses the times. You read next_payment_attempt. You do not type the dates. Stripe's revenue-recovery guide says Smart Retries are more effective than scheduled retries. That sentence is Stripe's. It is not a recovery percentage, and this page does not add one.

A custom schedule. You turn Smart Retries off. You get up to three retries. Each one is a number of days after the previous attempt, not a list of calendar dates.

Which of those two to leave on is the retry decision. It is not a second dunning process. The rules for whether to charge again, when, how many times, and when to stop are in what payment retry logic is. Running that policy and the notices as one product is covered in what payment retry software adds beyond Stripe retries.

Both modes use the same payment-method order: the subscription's default payment method, then the subscription's default source, then the customer's default payment method, then the legacy customer default source. If the customer updates a different field from the one that failed, the next attempt misses the new card. The charge and the notice have to name the same method.

Stripe does not run the retry at all when no payment method is available, the card is India-issued, or the Connect account has been disconnected. There is no later attempt to wait for.

3. Some codes stay on the schedule and do not charge

If the issuer returns a hard-decline code on Stripe's published list, Stripe does not execute a live retry. The slot stays. attempt_count still increments. No new Charge is created until a new payment method is attached. A custom schedule does not get a live charge on those codes either.

expired_card is not on that list. A retry can still run against it, and running it does not replace the number. Which codes are which is in hard declines vs soft declines. The process only needs the branch. A soft decline can walk the retries. A code on Stripe's list waits for a new payment method. An expired card needs the customer even when a retry is still scheduled.

4. Notices go in the gaps

The email is a separate switch, Send emails when card payments fail. With it on, Stripe sends an email after each failed payment. It says the subscription charge failed and offers a way to update the payment method. It does not, by itself, change the words on the next send. It follows the attempts. It is not a day 1, day 3, day 7 calendar.

The reminders RetryFix describes publicly are three notes, on day 1, day 3, and day 7. Treat that ladder as illustrative: a worked example of the notices, not a charge calendar, and not a recovery rate. A given failure can use a shorter or longer sequence. Retries can fall on other days. What each note is for is on the definition page. Why an identical Stripe email gets skipped, including an update link that stops working once the subscription has ended, is in why customers ignore Stripe failed-payment emails.

Stripe's hosted update link stops working when the subscription is canceled, incomplete_expired, or unpaid. A final notice after that is an announcement. Send it while the link still loads. Pick one sender. If Stripe's failed-payment email stays on while you also send your own, the customer gets two threads.

5. An illustrative charge calendar, separate from those notes

The custom control can land near a 1 / 3 / 7 shape. This is an illustration of the gaps, not a preset Stripe publishes, and not the email ladder above.

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. That 1 / 3 / 7 shape is not a labelled Stripe setting.

The day 1, day 3, and day 7 emails can sit in the gaps around whichever clock you left on. They are not those charges. Which clock to leave on is in Smart Retries vs a fixed retry schedule.

6. The window closes on the ending you chose

When recovery fails, the subscription follows the setting under Retries, after the maximum number of days defined in the retry schedule. The options are:

Ending	What Stripe does
Cancel the subscription	Status becomes `canceled`. This is terminal. Automatic collection on outstanding invoices stops. A returning customer needs a new subscription.
Mark the subscription as unpaid	Status becomes `unpaid`. Stripe keeps generating invoices, does not attempt payment on them, and leaves them `draft`.
Leave the subscription past-due	Status stays `past_due`. Stripe keeps generating invoices and attempts them under your retry settings. That is a later cycle, not more attempts on the invoice that just finished.
Pause the subscription	If the subscription is eligible, status becomes `paused` and Stripe does not generate new subscription invoices until it resumes. You can pause after the first renewal failure or after retries are exhausted. Eligibility is Stripe's.

Changing the setting affects future retries, not a schedule that has already finished.

The date in the last notice has to be this ending. A final email that says you will cancel, on an account set to leave subscriptions past due, describes a different ending from the one Stripe will apply.

How long the window stays open

There is no single dunning-cycle length to copy.

On Smart Retries the window is the duration you set: 1 week, 2 weeks, 3 weeks, 1 month, or 2 months. The retry count sits inside it. A new account starts at up to 8 retries within 2 weeks. That is Stripe's starting configuration for new accounts. It is not a recovery rate.

On a custom schedule the window is the gaps you typed, and there are at most three of them. The Monday illustration above runs about seven days because the gaps are 1, then 2, then 4. Type different gaps and the cycle is a different length.

Two marks sit on that window. Attempts on this invoice stop after the final payment attempt. The status change happens after the maximum number of days defined in the schedule. Read both before you tell a customer the date.

Bank debits are a different table on the same Stripe page, with their own retry caps. This timeline is the card renewal.

When you stop

Stop is one of these outcomes. Read it off the invoice in front of you.

The invoice is paid. The cycle is over. Stop the notices. If the account resolves subscription status from the most recent invoice, which is Stripe's default, paying that invoice can move the subscription back to active. If the account resolves status from all open invoices, an older unpaid invoice can keep it off active. That setting does not change the retry schedule.

The final attempt has run. Stripe will not attempt this invoice again. Apply the ending you already chose. Do not keep the same invoice open for a week that is not in the schedule. The customer was told a date. The date has to be this one.

This card will not be charged live. The code is on Stripe's hard-decline list, or Stripe will not retry at all. Stop waiting for a charge on that card. The cycle continues only as a request for a new payment method, until one is attached or the ending arrives. An expired card is the middle case: a retry may still run, and it still will not update the card, so the notice goes now.

You pause or cancel before the last retry. Stripe allows an eligible subscription to be paused after the first renewal failure, not only after the last attempt. Cancelling yourself is also an ending. Either one closes the window you had left. Say so in the notice you still have time to send.

What to settle before the next failure

The cycle is already decided by the time the charge fails. Four checks, before that:

The ending is chosen, and the last notice names it: cancel, unpaid, past due, or pause.
One sender. Stripe's failed-payment email, or yours. Not both.
The notice and the retry name the same card. The order in step 2 is the order Stripe will charge.
The email ladder is not the charge calendar. Day 1, day 3, and day 7 are the public reminder example. The attempts are Smart Retries, or the gaps you typed.

Automatic card updates sit before this cycle. They can refresh a reissued number so that renewal does not fail on a stale expiry. They are not a step inside the open window, and they do not replace the notice when the card is simply expired.

Common questions

What is the dunning process? The work after a renewal charge fails: retries where a later charge can still collect, notices that tell the customer how to fix the card, an open window while that happens, and an ending you chose if the invoice is still unpaid. On Stripe that is Revenue recovery, not one switch named dunning.

What is a dunning cycle? One pass of that process for one invoice. It runs from the failed renewal until the invoice is paid, or the schedule reaches its maximum days and Stripe applies your ending. The next invoice is a new cycle.

How long does a dunning cycle last? As long as the retry window you set. Smart Retries use 1 week, 2 weeks, 3 weeks, 1 month, or 2 months, with a retry count inside that window. New Stripe accounts start at up to 8 retries within 2 weeks. A custom schedule is at most three gaps, each a number of days after the previous attempt. There is no second length to pick on top of that schedule.

What is a dunning system? The same cycle, run on purpose: the retry schedule, the notices, the open window, and the ending. Stripe does not gather it into a single control. The letter or email is the part the customer sees. The system is the timeline those messages sit on.

When should you stop retrying a failed payment? When the invoice is paid, when the final attempt on that invoice has run, or when Stripe will not execute a live charge on this card. After the final attempt, Stripe makes no further payment attempts on that invoice. Leaving the subscription past_due does not add attempts to the invoice that just finished. It lets later invoices open their own cycles.

Is day 1 / day 3 / day 7 the Stripe charge schedule? No. That ladder is the reminder example RetryFix describes publicly. It is communication. A custom retry schedule can be illustrated with gaps of 1, 2, and 4 days so the attempts land near those dates. That illustration is not a preset, and it is not the emails.

Does the process cancel the subscription for you? Only if you chose cancel. The other endings are unpaid, leave past due, or pause when the subscription is eligible. After the maximum days in the schedule, Stripe follows that setting.

Where to start

Open Billing → Revenue recovery → Retries. Write down the mode (Smart Retries or a custom schedule), the window, and the ending. Then open one subscription that is past_due and read next_payment_attempt on the open invoice, the decline code, and the last email that customer received. If the date in that email does not match the ending in Retries, that is the first fix. If the email could have gone out unchanged after every attempt, the sequence is the next one. Why those emails get ignored is the page for that.

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), at no extra cost. The emails are the customer-facing sequence on top of your processor's retries. They are not a second retry clock. Who the message appears to come from is in branded dunning emails. RetryFix never holds or moves your money; recovered payments land in your own Stripe account.

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

Paul Hartness — Tue, 03 Nov 2026 09:57:01 +0000

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.

What Is a Dunning Letter?

Paul Hartness — Tue, 27 Oct 2026 09:24:49 +0000

The three classic stages (friendly reminder, firmer notice, final notice) and how they map to dunning emails after a failed Stripe subscription charge.

Originally published on the RetryFix blog.

A dunning letter is a formal written reminder that a payment is overdue. It names what is unpaid, asks the customer to pay or to fix the method, and says what happens if they do not. On a Stripe subscription that letter is almost always a dunning email: a message after a renewal charge fails, sent while a later attempt may still clear.

This page is about the letter: the meaning, the usual stages, what a good one contains, and when automated retries plus email do that job better than a letter in the post. The wider process (which declines get a retry, how long the window stays open, and what you do when it closes) is in what dunning is.

Contracts and local rules sit outside this page. Ask your own advisor before you treat any template as something you must send.

What "dunning letter" means

Dunning is the work of asking again for a payment that did not clear. The letter is the written ask. Accounts-receivable teams have used the name for a notice on a past-due invoice. Search results still mix that older meaning with the email a SaaS company sends after a card decline.

For a founder on Stripe, the split that matters is who the notice is for.

An unpaid invoice. The customer was billed, often by invoice in a B2B relationship, and has not paid. A dunning letter, sometimes called a dunning notice, chases that balance. Some companies still post it, or attach it as a PDF. That world is real. It is not the one a failed card renewal lives in.

A failed subscription charge. The customer did not choose to leave. The card was declined. The notice tells them which product failed, whether they have to act, and how to update the payment method. They usually still have the product. The useful sentence is "your renewal did not go through, here is how to fix it," not "your debt is overdue."

Collections is a later job: chasing a balance after the relationship has already ended. A dunning letter, in the subscription sense, goes out before you cancel.

Stripe does not put this under a control labelled "dunning letter". Revenue recovery is the set of tools: retries, customer emails, and the rule for when retries run out. The Dashboard labels you will actually use are Retries and customer emails.

The stages of a dunning letter

The letters themselves are usually three. People sometimes search for four stages. There is no single official count. When a fourth stage shows up in a template, it is usually what you do after the last letter, not another letter.

Friendly reminder

The first note assumes an oversight. It states what is unpaid (the invoice, the amount, or the renewal), names the product, and gives one way to pay or to update the card. The tone is calm. It does not threaten to close the account.

On a card renewal this is the first email after the decline. It should say which card failed. If a later attempt on that card can still clear, say so, and offer the link anyway. If the card cannot pay, say that in this first note. A friendly reminder that pretends an expired card will be retried is how the next email gets ignored.

Firmer notice

The balance is still open. The second note is shorter than a copy of the first. It repeats what is unpaid, repeats the one link, and names the date you already intend to act on. Its job is to show that nothing has changed since the first note, and that the date is real.

Resending the friendly reminder with a new subject line is how this stage fails. The customer has already archived that sentence. A firmer notice has to add something: the date, or the fact that the card still cannot pay.

Final notice

The last letter says it is the last one, and what happens next. On an invoice, that might be closing the account or passing the balance on. On a subscription, say the thing you will actually do when the retry window ends: cancel the subscription, mark it unpaid, or leave it past due. Send it while the customer can still update the card.

A final notice that arrives after you have already cancelled, with a button that no longer loads, is an announcement. It is not a chance to pay.

Where a fourth stage comes from

Templates that promise "the four stages of a dunning letter" usually add a step after the final notice: cancel, write the invoice off, or hand the balance to someone else. That step is a rule you chose. It is not a fourth letter the customer needs to read. Count the notices you send. Then decide, separately, what the billing system does when the last date arrives.

How those stages become dunning emails

A paper letter and a failed-payment email do the same job at different speeds. The charge failed today. The customer needs a note they can act on before the next attempt, not a letter that arrives after the window has closed.

Classic stage	What the letter asks	The subscription email
Friendly reminder	Pay, or tell us if this is a mistake	First email after the decline. Name the product and the card. On a soft decline, say a later attempt may still clear. On a hard decline, say this card cannot pay.
Firmer notice	Still unpaid; here is the date	A shorter reminder, only if nothing has changed, with the same link and the date you already named.
Final notice	Last chance before the consequence	The last email. Name the date access or the invoice changes. Send it while the update link still works.

RetryFix describes one public example of that ladder: three reminders, on day 1, day 3, and day 7. Treat it as a worked example of the three stages, not as a recovery rate, and not as a promise that every failure gets the same copy. A given failure can use a shorter or longer sequence. The notes, and how they sit next to retries, are written out in what dunning is.

The same words on every stage teach people to archive the mail. With Send emails when card payments fail on, Stripe sends an email after each failed payment. It says the subscription charge failed and offers a way to update the payment method. It does not, by itself, change the words on the next send. One identical email, sent again, is one letter reprinted. Why that gets skipped, including a hosted update link that stops working once the subscription has ended, is in why customers ignore Stripe failed-payment emails.

Which declines belong in the "may still clear" pile, and which mean this card is finished, is in hard declines vs soft declines. The letter only needs the conclusion: act, or wait.

What a good dunning letter contains

A good letter answers four questions. Leave one out and the customer cannot act, whether the notice is a PDF or an email.

What is unpaid. The product, and the amount or the invoice. On a card payment, add the brand and the last four. "Your payment failed" does not say which subscription.

Whether they must act. A soft decline may clear on a later attempt, so the friendly reminder can offer the link without a panic. A hard decline will not clear on that card, so the notice has to say that retrying it will not collect. The same sentence for both is how each of them gets treated as noise.

One way to fix it. One link, or one payment instruction. On Stripe, that link has to update the payment method the next attempt will charge. Two links are two threads, and the customer waits to see which one is real.

What happens, and when. The final notice names the date. The earlier notices can name it too, so the last email is not the first time the customer hears a deadline. The date has to match the rule you set for the end of the retry window: cancel, unpaid, or past due.

Who the email appears to come from is a separate choice from what it says. A From line the customer already recognises is easier to trust than a sender they have never paid. On RetryFix the mail goes out in the company name, and a line in the email says RetryFix sent it on the merchant's behalf. How that sender is set up is in branded dunning emails.

When automated retries and email beat a letter

A dunning letter still fits an unpaid invoice that a person pays by bank transfer, and a customer who does not read email. It is a weak tool for a failed card on a subscription.

The card can be tried again without the customer. A soft decline is often a timing problem. Stripe Smart Retries decide when to charge the same card again. They never write to the customer. The email is the notice. The retry is the attempt. A letter does not time itself against the next charge, and it cannot clear a card that was only short of funds on the day the invoice ran.

The fix is a new payment method. The useful action is a link that updates the card the next attempt will use. A letter can ask someone to call or to pay by bank transfer. It cannot sit in the gap between two attempts the way an email can, so the next charge hits the card they just added.

The renewal failed today. The customer may still want the product. A letter in the post arrives after several retries have already run, or after you have already cancelled. The email can go out the same day, in the gap before the next attempt, while access is unchanged.

The stages have to be different sentences. The friendly reminder and the final notice are different jobs. A single printed form, posted three times, has the same problem as one Stripe template sent after every attempt. Write the stage. Reprinting the first letter with a new date is how the final notice gets archived with the rest.

If the card is expired, another attempt on it will not collect. The notice is the recovery path, and it should go out now. If the decline can still clear, the retries do the quiet work and the emails stay in the gaps. Pick one sender. Stripe's failed-payment email can stay on while you also send your own, and the customer then has two letters. Turn one of them off.

Common questions

What does dunning letter mean? A formal reminder that a payment is overdue. It says what is unpaid, how to pay or how to fix the card, and what happens if it stays open. On a Stripe subscription the same reminder is the email you send after a renewal charge fails.

What are the stages of a dunning letter? Usually three: a friendly reminder, a firmer notice, and a final notice. A fourth stage, when a template lists one, is what you do after the final notice (cancel, mark unpaid, or stop). It is a rule, not another letter. There is no single official list.

What is the difference between a dunning letter, a dunning notice, and a dunning email? They are the same job in different formats. A dunning letter is the older written notice, often about an unpaid invoice. A dunning notice is the message, whatever form it takes: letter, PDF, or email. A dunning email is that notice sent by email, which is what a subscription business sends after a card renewal fails. The process those messages belong to (retries, the window, and the ending) is in what dunning is.

Where to start

Read the last three failed-payment emails for one customer, in order. A sequence has a calm first note, a shorter middle note that adds a date, and a final note that says what happens. Three copies of the first email are one letter, reprinted.

The retries belong in the background. Smart Retries time the next charge and do not write the letter. The emails belong in the gaps between those charges. If every send could have gone out unchanged, that is the first thing to fix.

How to Reduce Soft Declines (and When a Retry Will Actually Work)

Paul Hartness — Mon, 19 Oct 2026 12:06:24 +0000

Originally published on the RetryFix blog.

A soft decline is a refused card charge where the issuer has not said the card itself is finished. The charge failed this time. The same card might still pay later, or the customer might need to do one specific thing first: add funds, authenticate, or use another payment method. A hard decline is the other case. This card cannot complete the charge, and another attempt on it will not collect.

This page is the practical half: how to have fewer soft declines in the first place, and when a retry is worth running. Which codes are which, and the slice of failed payments a retry will never collect, is in hard declines vs soft declines.

What a soft decline means

Stripe's decline codes page does not group codes under a heading called "soft declines." Subscription operators use the term for the declines that are not a finished card. On a renewal, the codes this page treats as soft declines are:

insufficient_funds. The card did not have enough for this charge. Stripe's next step is that the customer needs another payment method. The code is not on the list Stripe refuses to retry, so a later attempt is still allowed.
do_not_honor and generic_decline. The issuer declined and did not say why. Stripe's next step for both is that the customer contacts their card issuer. These are also not on Stripe's do-not-retry list.
processing_error, issuer_not_available, and reenter_transaction. Something in the path failed. Stripe's next step is to attempt the payment again, and to involve the customer if it still will not go through.
authentication_required. The issuer wants the customer to authenticate, often with 3D Secure. Stripe's decline-code page uses "soft decline" for the issuer response that, on Stripe's front ends, in most cases starts an authentication flow. authentication_required is the code when that step is still outstanding, and it is on the list of codes Stripe will not run a live automatic retry against until a new payment method is attached.

The sharper signal, when the issuer sends one, is the advice code on the charge, not the decline name alone. Stripe documents three:

try_again_later. You can retry.
do_not_try_again. Do not use this card again for the same transaction.
confirm_card_data. Some of the card data was wrong. Fix it before you charge again.

A retry only helps if something can still change. That is what payment retry logic is deciding: whether to charge again, when, how many times, and when to stop.

How to reduce soft declines before the renewal

A retry recovers a charge that already failed. The cheaper result is a renewal that never declines. The steps below are the ones Stripe documents. A longer retry list is not one of them.

Let the network update the card

When an issuer replaces a card, the number and expiry you have saved can be wrong before the customer tells you. Stripe works with the card networks and automatically attempts to update saved card details when the customer receives a new card, including a replacement for one that expired or was reported lost or stolen. The next renewal can then use the new details instead of failing.

That only happens when the issuer participates. Stripe says support is wide for American Express, Visa, Mastercard, and Discover cards issued in the United States. Support in other countries varies. You cannot tell in advance which saved cards will update. If you keep your own copy of the last four and the expiry, listen for payment_method.automatically_updated.

This prevents a decline. It is not a retry. If the update never arrives and the charge comes back expired_card, the customer needs another card. That code is a hard decline, covered on the hard vs soft page.

Email before a default card expires

Send emails about expiring cards, in Stripe's revenue recovery email settings, sends one email a month before a card expires, when that card is the customer's default payment method or default source. The renewal should not be the moment anyone learns the card is ending.

That email does not replace the note after a charge has already failed. Send emails when card payments fail is a separate switch, and it sends after each failed payment. If you also send your own failed-payment mail, the customer gets two threads. Pick one sender. What those notes should say is in what dunning is, including the day 1, day 3, and day 7 reminder ladder RetryFix describes publicly. Treat that ladder as an example of the emails, not as a recovery rate.

Put a second card where the retry will actually use it

A backup card helps only if the next attempt charges it. When Stripe retries a subscription invoice, it uses one payment method, in this order: the subscription's default payment method, then the subscription's default source, then the customer's default payment method, then the customer's default source. It does not try every card saved on the customer.

There is a trap in that order. If the subscription has its own default payment method, and a card update only changes the customer's invoice default, Stripe keeps retrying the subscription's card. Update the field the failed attempt used.

Asking for a second card at signup, or in the product before renewal, is what makes an insufficient_funds decline recoverable without waiting on a balance that may not change. Stripe's written next step for that code is an alternative payment method.

Use a recognisable descriptor, and authenticate while the customer is present

A statement descriptor is the text on the bank or card statement. Stripe's docs say a clear, accurate descriptor can reduce chargebacks and disputes, and that it should reflect the name you do business under. For card charges the account has a short prefix. A per-charge suffix is for one-time card payments. Stripe creates subscription charges itself, so you cannot set that suffix on the subscription's PaymentIntent. Subscription and invoice charges use the account descriptor unless you set one on the invoice.

A clearer name will not turn an insufficient-funds decline into an approval. It is still worth setting, because a renewal the customer does not recognise is how a real charge gets queried or stopped. Most banks show the descriptor. Some do not.

Authentication is the other step you can take before the decline. Some issuers, especially in Europe and India, want the customer to confirm the payment. Stripe's card declines guide says using 3D Secure can lower decline rates in countries that support it. On Stripe's front ends, an issuer soft decline that wants authentication usually becomes a prompt while the customer is still there.

A renewal is off-session. The customer is not on a page to complete a prompt. An authentication_required result then needs a message, not another silent charge. Stripe can email a hosted confirmation link when Send a Stripe-hosted link for customers to confirm their payments when required is on. While the customer is still in checkout, Stripe's front ends can turn the issuer's soft decline into an authentication step instead.

When a retry will actually work

Retry the same card when the issuer has left the door open. Stop when they have not.

A later attempt on the same card can be worth it

The advice code is try_again_later.
The decline is processing_error, issuer_not_available, or reenter_transaction. Stripe's next step is to attempt again.
The decline is insufficient_funds, do_not_honor, or generic_decline, and you still have a sensible number of attempts left. These codes are not on Stripe's do-not-retry list. They are also not a promise. For insufficient funds, the written next step is still another payment method. For a do-not-honor or a generic decline, the written next step is that the customer contacts the issuer. A spaced retry can catch a balance that has been topped up, or a temporary block that has cleared. It cannot make the customer call their bank.
The decline is card_velocity_exceeded: a balance, credit, or amount limit on the card. Stripe's next step is that the customer contacts the issuer. Waiting is reasonable. Charging again immediately is how you hit the same limit.

The customer has to act

The advice code is do_not_try_again or confirm_card_data.
The code is authentication_required. Ask the customer to confirm the payment. Stripe keeps the retry on the schedule, and it will not run the charge until a new payment method is attached.
The card cannot pay: expired_card, or a code on Stripe's do-not-retry list such as lost_card, stolen_card, or incorrect_number. Stop charging this card and ask for a new one. Stripe already withholds a live retry on that published list. expired_card is not on the list, so an expired card can still be charged again unless something else in your setup stops it.

What Stripe Smart Retries are: a Billing setting that picks each attempt time from Stripe's network data, inside a window you choose, from 1 week up to 2 months. The recommended default is 8 tries within 2 weeks. A custom schedule is the other option: up to three retries, each a set number of days after the previous attempt. Card networks limit how often a single charge can be reattempted. Stripe recommends a maximum of eight retries for charges that permit retries, and says issuers may treat further retries as possible fraud, which can increase declines on legitimate charges.

Space matters more than adding attempts. Several charges a few hours apart do not create funds on an insufficient-funds card. They use up attempts the network will tolerate. A practical shape for which soft decline to leave for a few days is in how to retry failed Stripe payments. Put the customer email in the gap before the next attempt, so that attempt can use an updated card.

Common questions

What is a soft decline? A card charge the issuer refused without saying the card is finished. For a subscription renewal, that means insufficient funds, a generic or do-not-honor response, a processing error, or a request to authenticate.

How do you reduce soft declines? Keep the saved card current, with network card updates and an email a month before a default card expires. Store a second payment method on the field Stripe will actually charge. Authenticate while the customer is present. Set a statement descriptor the customer can recognise, so a real renewal is less likely to be queried or stopped. Then retry only where a later attempt is allowed, with space between tries.

Should you retry every soft decline? No. Retry when the advice code is try_again_later, or when the decline is a processing or issuer-unavailable error. For insufficient funds, do-not-honor, or a generic decline, a small number of spaced retries can be worth it, and the customer may still have to act. Do not retry when the advice code says not to. Do not keep charging a card that needs authentication or a new number.

Does Stripe retry soft declines for you? On subscription invoices, Smart Retries will retry many of them inside the window you set. It will not run a live charge for a code on its published hard-decline list, which includes authentication_required. It also will not retry when no payment method is available, when the card is India-issued, or when the Connect account has been disconnected. After the final attempt, Stripe makes no further payment attempts.

What is the difference between a soft decline and a hard decline? A soft decline can still clear later, or after the customer does one thing. A hard decline means this card cannot pay, so the path is a new payment method. How to split the codes in your own Stripe data is in hard declines vs soft declines.

Where to start

In the Stripe Dashboard, open Billing → Revenue recovery. Confirm Smart Retries are on, and that the window is the one you meant rather than a long run of extra attempts. Turn on Send emails about expiring cards. On a handful of recent failures, read the decline code and the advice code, and separate the ones that can wait from the ones that need the customer today.

Then open one subscription that failed for insufficient funds. If it has its own default payment method, that is the card the next retry will charge, including when the customer has just added a different card on their profile.

Try the demo: https://retryfix.com/demo/start