---
title: How dunning works
description: The recovery run that opens when a payment fails, and how it ends.
domain: dunning
status: shipped
visibility: public
last_verified: 2026-07-31
order: 10
---
When an automatic charge on an invoice fails, yRecurring opens a recovery run against that invoice and starts trying to collect. The run tracks the whole effort from the first failure to the moment it either succeeds or gives up.

```viz dunning-run
```

## Automatic collection comes first

Before dunning, there is the charge itself. When an invoice is finalized, yRecurring can [automatically charge](/guide/payments/automatic-collection) the customer's saved payment method. If that charge succeeds, there is nothing to recover. Dunning only begins when the charge fails.

## Soft declines are retried

A soft decline is a temporary problem: insufficient funds, a processing error. These are worth retrying, because they often clear on their own. The run schedules the next attempt and tries again later, on the schedule covered on the next page. Each retry runs the same charge, so there is one path for taking money, whether it is the first attempt or the fifth.

## Hard declines wait for a new card

A hard decline means the card itself is the problem: expired, lost, stolen, or a do-not-honor from the bank. Retrying a dead card just burns attempts and annoys the customer. So instead of retrying, the run parks as "awaiting card" and waits for the customer to update their payment details. No automatic retries happen until they do.

## Some charges need the customer to confirm

Some banks require the customer to confirm a payment before it goes through, a step called 3DS or SCA. This cannot happen while the customer is away, so the run does not retry it. Instead it parks as "awaiting authentication" and emails the customer a link to confirm the payment. No retries happen until they do. This is different from a decline: the card is fine, the bank just wants a confirmation.

## How a run ends

A recovery run can also pause in a waiting state, shown below, before it reaches one of these endings.

A recovery run finishes one of these ways:

| Outcome | What it means |
|---|---|
| Recovered | A retry went through, or the invoice was paid some other way. The balance is clear. |
| Exhausted | The retry schedule ran out. What happens next is your choice, set in dunning settings: alert only (the default: the invoice stays open and owed), pause the subscription (billing stops but nothing is destroyed, and payment lets you resume), write the invoice off, or cancel the subscription. |
| Awaiting card | A hard decline parked the run. It waits for a new card. |
| Awaiting authentication | The bank wants the customer to confirm the payment (3DS / SCA). It waits for them to confirm from the emailed link. No retries until they do. |
| Paused | You paused it by hand. Nothing automatic happens until you resume. |

## Turning dunning on or off

Dunning is an organization setting, and it is on by default, so failed payments are chased automatically out of the box. Turning it off stops the automatic retries: a failed payment is left for you to handle by hand, with no recovery run opened.

You change this, and the retry schedule on the [next page](/guide/dunning/the-retry-schedule), for your whole organization under Settings ([open dunning settings](https://app.yrecurring.com/settings/dunning) if you are signed in).

## Draft a reminder with AI

On the Scale plan, an overdue invoice has a "Draft reminder with AI" button. It writes a short, friendly payment-reminder email for that customer, using the invoice, the amount, how overdue it is, and why the last charge failed. You get a page where you read it, change any of it, and then send it. Nothing goes to the customer until you press Send, and you can edit every word first. On other plans the button shows what the feature does and how to turn it on.

This is a hand-sent nudge, separate from the automatic dunning emails your retry schedule already sends.

## Nothing happens silently

Every milestone of a recovery run, the first failure, each scheduled retry, recovery, and exhaustion, is recorded on the invoice. Each run also has its own page in the Dunning console: the full attempt timeline, what the bank answered each time, and, for every scheduled retry, the reason it was scheduled for that moment. From there you can pause and resume a run, or press "Retry now" to charge again immediately (for example after the customer tells you they've fixed things).

Your customer sees the same truth, in friendlier words. The invoice's hosted page tells them what happened, what happens next and when, and gives them one-tap ways to fix it; the customer portal shows a banner while a payment is being recovered; and every dunning email explains the failure in plain language, never a raw bank code.

The console also counts the money: recovered revenue, the balance still at risk in open runs, and your recovery rate.

## Edge cases

- **The invoice stays collectible after the schedule runs out.** Exhausted does not write it off or cancel anything; it stops the automatic retries and hands the decision to you.
- **A charge that clears any way closes the run.** If the customer pays the invoice through another route, the run is marked recovered.