Skip to main content
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

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