Payment Recovery Overview

When a recurring payment fails to collect, Acquired Recover is the solution that automatically recovers. Revenue that would otherwise be lost to involuntary churn — expired cards, temporary declines, or insufficient funds — can be recovered without any manual intervention.

This page describes what Acquired Recover does once a failed payment reaches it: the recovery strategies you can apply, the recovery lifecycle, and how to retrieve and manage recoveries.

📘

How a payment reaches Acquired Recover

Today, failed payments can come from Acquired Billing only — see Recovering subscription payments for how to enrol a subscription and what happens when its bills fail.

Support for recovering recurring payments across the Acquired network is planned, and each source will have its own guide.

The behaviour described on this page applies to every recovery, whatever its source.

How payment recovery works

1. A failed recurring payment is sent to Acquired Recover. Acquired creates a payment recovery for it and begins working through the assigned recovery strategy.
2. Acquired retries the payment according to the strategy's schedule. Each recovery attempt's order_id matches the original payment being recovered. The recovery stays in the recovering status while this is in progress.
3. The recovery ends either when a retry succeeds (recovered) or when the strategy gives up (unrecovered).

Retry Advice: the recovery gate

Before any schedule is considered, Acquired Recover first checks whether the failed payment should be retried at all.

Every failed card payment returns a retry_advice object in the API response — see Retry Advice for how it works and the advice categories returned. The advice category indicates whether— and when — it is worth trying the card again. This advice is the gate that decides whether a recovery can begin or continue:

• Retry later — a temporary decline (for example, insufficient funds). Recovery is allowed to proceed.
• Do not retry — the decline is effectively permanent for this card (for example, a blocked or closed card). The gate closes: the recovery stops immediately with advice_do_not_retry, rather than wasting attempts and risking issuer penalties.

Retry advice is re-evaluated on every attempt, not just the first. A recovery that is mid-schedule will stop the moment an attempt comes back as do-not-retry, even if scheduled retries remain. Only once this gate is open does the assigned strategy decide how and when the payment retries happen.

Recovery strategies

A recovery strategy is a named schedule that determines how and when a failed payment is retried. A strategy is a sequence of steps that ends when the payment succeeds or the schedule is exhausted:

The flexibility is in when each retry fires. Acquired Recover supports any strategy your business needs to effectively recover failed payments.

• Fixed delays — wait a set period after the previous attempt (for example, retry one day later).
• Calendar windows — retry only at specific times or on specific days (for example, the next Tuesday or Friday morning, or the last working day of the month). This lets you target times when funds are more likely to be available, such as just after typical pay days.
• Retry advice timing — when retry_advice indicates a decline should be retried after a particular time, the schedule respects that time. This timing advice is abstracted from Mastercard's Merchant Advice Codes (MAC), which provide granular guidance including specific retry timing windows (e.g. retry after 1 hour, after 24 hours, after 2 days, up to 10 days).

When more than one applies, recovery uses the most informed signal: retry advice timing first, then any configured calendar window, then the fixed delay as a fallback.

📘

Retries are measured from the attempt, not from "now"

Each wait is calculated from when the previous attempt actually completed, so if a retry is delayed for operational reasons the intended gap between attempts is still honoured rather than compounded.

Protected dates

A strategy can be configured to avoid certain dates — for example weekends or public holidays such as Christmas Day. If a retry would land on a protected date, it is moved forward to the next allowed day.

Built-in safety limits

Every recovery is bounded so it can never run indefinitely:

• Maximum attempts — once the maximum number of retry attempts is reached, the recovery ends with max_retries_exceeded. Maximum attempts are automatically applied based on scheme limits provided by Mastercard and Visa.
• Maximum age — a recovery running longer than the maximum age ends with payment_too_old.

📘

Recovery strategies

The set of strategies available to you — and their names, such as example_strategy — is provided as part of your onboarding. Use the exact name supplied to you.

The recovery lifecycle

Every payment recovery has a status describing where it is in its lifecycle:

When a recovery reaches a terminal status, the termination_reason field explains why it ended:

While a recovery is still in progress, termination_reason is null.

Retrieving and managing recoveries

Cancel and mark-recovered are only valid while the recovery is in the recovering status; calling them on a terminal recovery returns an error.

Example recovery object:

{
  "id": "01JE3X4Y5Z6A7B8C9D0E1F2G3H",
  "order_id": "01HNY4G8G8P4E1T4YJ9N8B1Z9M",
  "customer_id": "c3e06b6f-bb52-4b2c-81a3-899860652240",
  "status": "recovering",
  "amount": 19.99,
  "currency": "GBP",
  "recovery_strategy": "example_strategy",
  "termination_reason": null,
  "created_at": "2025-11-17T17:00:00Z",
  "next_action_scheduled_date": "2025-11-20T09:00:00Z",
  "payment_retry_attempt_count": 1,
  "links": [
    {
      "rel": "self",
      "href": "/v1/payment_recoveries/01JE3X4Y5Z6A7B8C9D0E1F2G3H"
    }
  ]
}

• order_id identifies the original failed payment this recovery relates to.
• next_action_scheduled_date is when the next retry is scheduled. It is null when the recovery is not in the recovering status or no retry is currently scheduled.
• payment_retry_attempt_count is the number of retry attempts made so far.
• amount is returned in major currency units (e.g. 19.99).