> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reorderjs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Dunning

> Dunning automatically retries failed subscription payments on a configurable schedule. Learn how cases work, what statuses mean, and how to resolve them.

Dunning is the process of automatically retrying a payment that failed during renewal. When a renewal cycle fails because of a payment error — such as a declined card or insufficient funds — Reorder opens a dunning case for that subscription and begins retrying the payment on a scheduled interval. The goal is to recover the payment without requiring manual intervention for every failure.

## When dunning starts

Dunning starts automatically when a renewal cycle fails after the renewal order has already been created. The failure must be payment-qualified — that is, caused by a payment session, authorization, or capture error — rather than a validation or eligibility issue.

When dunning starts:

* The subscription status moves to `past_due`.
* A dunning case is created, linked to the originating renewal cycle and its order.
* The retry schedule is applied and the first `next_retry_at` is set.

Only one active dunning case can exist per subscription at a time.

## Dunning case statuses

| Status                       | What it means                                                                                       |
| ---------------------------- | --------------------------------------------------------------------------------------------------- |
| `open`                       | The case has just been created and no retry has run yet                                             |
| `retry_scheduled`            | The last retry failed with a retryable error and a future retry is scheduled                        |
| `retrying`                   | A retry is currently in progress                                                                    |
| `awaiting_manual_resolution` | The case cannot continue automatic retries and requires a manual decision                           |
| `recovered`                  | The payment was successfully collected and the subscription is active again                         |
| `unrecovered`                | The case is closed without recovery — either due to exhausted retries or a terminal payment failure |

## Retry intervals and max attempts

The retry schedule defines how long Reorder waits between each payment attempt. Intervals are stored in minutes. The default policy applies a fixed-interval schedule, but you can override the schedule for an individual case from the Admin.

The `max_attempts` field sets the total number of retry attempts allowed. When the attempt count reaches the maximum, the case moves to `awaiting_manual_resolution` if no terminal failure has occurred, or closes as `unrecovered` if the failure is permanent.

<Note>
  Retryable errors include failures like `insufficient_funds`, generic declines, and temporary provider errors. Terminal errors — such as expired payment details or a missing payment method — close the case immediately as `unrecovered` without scheduling further retries.
</Note>

## Recovery flow

When a dunning retry succeeds, Reorder closes the case as `recovered` and restores the subscription to `active`. No further retries run.

When the case cannot be recovered automatically, you have two manual resolution options from the dunning case detail page:

| Action               | What it does                                                                                                                                 |
| -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| **Mark recovered**   | Closes the case as `recovered` and restores the subscription to `active`. Use this when payment was collected outside the normal retry flow. |
| **Mark unrecovered** | Closes the case as `unrecovered`, leaving the subscription in `past_due`. Use this when you have confirmed the debt cannot be collected.     |

Both actions require a reason when marking unrecovered.

## Manual retry now

You can trigger a payment retry immediately from the dunning case detail page without waiting for the next scheduled `next_retry_at`. The retry-now action runs the same payment retry workflow as the scheduler — it does not bypass any validation.

After a manual retry:

* If payment succeeds, the case closes as `recovered` and the subscription returns to `active`.
* If the error is retryable, the case stays in `retry_scheduled` and the next scheduled retry is preserved.
* If the error is terminal, the case closes as `unrecovered`.

## Coexistence with cancellation cases

An active dunning case and an active cancellation case can exist for the same subscription at the same time. A `past_due` subscription is eligible for a retention flow or final cancellation while payment recovery is still in progress. Each domain — dunning and cancellation — manages its own state independently.

See [Cancellation flows and retention offers](/concepts/cancellation-retention) for details on how cancellations work alongside dunning.