> ## 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
> Use the Dunning queue to monitor payment recovery cases, retry payments, override retry schedules, and manually close cases as recovered or unrecovered.
When a renewal payment fails, Reorder creates a dunning case and begins automatically retrying the payment according to the retry schedule configured in **Settings → Subscription Settings**. The Dunning queue at `/app/subscriptions/dunning` gives you a live view of every active and historical dunning case. From here you can inspect the retry history, trigger an immediate retry, override the retry schedule for a specific case, or manually close a case as recovered or unrecovered.
## The dunning queue
Navigate to **Subscriptions → Dunning** to open the queue.
### Columns
| Column | What it shows |
| ---------------- | ---------------------------------------------- |
| **Subscription** | The linked subscription reference and customer |
| **Status** | Current recovery state of the case |
| **Next retry** | When the next automatic retry is scheduled |
| **Attempts** | Total number of retry attempts made |
| **Last error** | The most recent payment error code or message |
Click any row to open the detail page for that case.
### Search
Use the search input to find cases by subscription reference, customer name, product title, variant title, SKU, payment provider, or last payment error code.
### Filters and inputs
Click **Add filter** to filter by **Status**. Applied status filters appear as chips in the toolbar.
The queue also exposes dedicated inputs that let you narrow results further:
| Input | Description |
| ------------------------ | -------------------------------------------------------------------- |
| **Provider ID** | Filter by payment provider |
| **Error code** | Filter by the payment error code |
| **Attempts min / max** | Filter by number of retry attempts |
| **Next retry from / to** | Filter by the scheduled next-retry date range (defaults to ±30 days) |
### Sorting
Use the sorting menu to sort by **Status**, **Next retry**, **Attempts**, or **Last attempt**.
## Dunning case statuses
| Status | What it means |
| ---------------------------- | ---------------------------------------------------------------------------------------------- |
| `open` | The case was just 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` | Automatic retries cannot continue — a manual decision is required |
| `recovered` | The payment was collected and the subscription returned to `active` |
| `unrecovered` | The case is closed without payment recovery — retries exhausted or a terminal failure occurred |
## Dunning case detail
Click a row in the queue to open the detail page. The detail page is split into two columns:
* **Left column** — Case overview, payment summary, retry schedule, attempt timeline, and technical metadata
* **Right column** — Linked subscription card, linked renewal cycle card, and linked order / payment card (where records exist)
### Detail actions
The action menu in the top-right of the detail page provides the following actions:
| Action | When it's available |
| ----------------------- | ------------------------------------------------------------------ |
| **Retry now** | Case is open or retry\_scheduled; blocked during in-flight retries |
| **Mark recovered** | Case is not yet terminal; blocked during in-flight retries |
| **Mark unrecovered** | Case is not yet terminal; blocked during in-flight retries |
| **Edit retry schedule** | Case is not yet terminal; blocked during in-flight retries |
Actions are disabled while a mutation is in progress.
## Retrying a payment immediately
Use **Retry now** to attempt payment recovery without waiting for the next scheduled retry.
Click the dunning case row in the queue to open the detail page.
From the action menu, select **Retry now**. A confirmation prompt appears.
Confirm the action. Reorder immediately attempts to charge the payment method.
Retrying now triggers an immediate payment attempt. Make sure the customer's payment method is in a state that can succeed before proceeding.
## Marking a case recovered
Use **Mark recovered** to manually close a dunning case when payment has been handled outside of the automatic retry flow — for example, after resolving an issue directly with your payment provider.
Click the dunning case row in the queue to open the detail page.
From the action menu, select **Mark recovered**. A confirmation prompt appears.
Confirm the action. The case is closed as `recovered` and the linked subscription returns to `active`.
## Marking a case unrecovered
Use **Mark unrecovered** to close a dunning case when you've determined the payment cannot be collected.
Click the dunning case row in the queue to open the detail page.
From the action menu, select **Mark unrecovered**. A confirmation prompt appears.
Confirm the action. The case is closed as `unrecovered`.
## Overriding the retry schedule
Use **Edit retry schedule** to change the retry intervals or maximum attempts for one specific dunning case without changing the global settings.
Click the dunning case row in the queue to open the detail page.
From the action menu, select **Edit retry schedule**. A drawer opens with the current schedule pre-filled.
Adjust the **Intervals** (in minutes) and **Max attempts** for this case. The drawer shows a warning if the override creates a risky schedule configuration.
Enter an optional reason for the override to capture context in the audit trail.
A final confirmation prompt appears before the override is saved.
Retry schedule overrides apply only to the specific dunning case you're editing. The global retry policy in **Settings → Subscription Settings** is not affected.