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.
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.
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. |
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 for details on how cancellations work alongside dunning. 
