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

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:

1. The ending is chosen, and the last notice names it: cancel, unpaid, past due, or pause.
2. One sender. Stripe's failed-payment email, or yours. Not both.
3. The notice and the retry name the same card. The order in step 2 is the order Stripe will charge.
4. 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.