MAC Scheduler

Last updated:August 5, 2026

Use this playground to see how retry-later advice is turned into a scheduled recovery attempt.

Some declines should not be retried immediately. For example, insufficient funds or temporary funding issues may become recoverable later. MAC Scheduler takes this retry-later advice and creates a scheduled retry instead of leaving the merchant to retry blindly.

In this playground, you can:

  • trigger a retry-later MAC, such as MAC 02 or MAC 24-30
  • see when the retry is scheduled
  • follow each retry attempt through the recovery window
  • see how the MAC is re-evaluated after every declined retry
  • understand when retries continue, change, or stop

MAC Scheduler does not change the issuer’s authorization decision. The focus here is simple: if the retry should not happen now, when should recovery be attempted?

How MAC Scheduler recovers a decline
Declined
Retry later
Recovery plan created
Up to 5 retries, merchant configurable
20 day window
Retries follow issuer timing
72 hours, then 10 days after new advice
Example: attempt 3 of up to 5 succeeds
Recovered
Plan ends

Every use case below walks through this same recovery plan, with a different MAC code and timing.

To consider
  • All examples use the DB (debit) payment type for simplicity.
  • MAC Scheduler also supports pre-auths, rebills, refunds, reversals, and credits.
  • Scheduling applies only when MACs are returned by the issuer and exposed by the acquirer.
  • MAC Scheduler works across PANs, wallet DPANs, and network tokens.

Use cases

Insufficient funds (MAC 02)

Retry later
The merchant initiates a transaction, but the issuer responds with MAC 02, insufficient funds or credit limit. This is a temporary decline. Retrying immediately is unlikely to succeed and may increase costs. MAC Scheduler schedules the retry for later, following issuer guidance, to maximise recovery chances safely.

How it works

1

The merchant initiates a payment.

The transaction is declined with MAC 02 (Insufficient Funds).

2

The merchant checks the retry status.

The merchant views scheduled retry attempts and outcomes.

Transactions created
DBDeclined
→
SDPlan created
→
DBRetry declined
→
DBRetry succeeds
→
DSPlan ends

1. The merchant initiates a payment

Initiate a server‑to‑server POST request with the required payment data. MAC values and retry timing are simulated using custom parameters to control the retry flow. Use:

  • customParameters[MacRetry.testMacs] to return the same MAC on each retry
  • customParameters[MacRetry.timeProfile] to define retry delays in minutes
When each retry returns MAC 02, MAC Scheduler keeps the same recovery plan.
The recovery plan is automatically ended (DS) when a retry succeeds or the maximum retry limit is reached.

What this creates
A declined payment that qualifies for scheduling creates a linked SD transaction. Its id and next attempt time appear in the response under processingDetails.macScheduler, as scheduledTxId and nextAttemptAt. nextAttemptAt is present whenever a retry is still scheduled.
"processingDetails": {
  "macScheduler": {
    "scheduledTxId": string,
    "nextAttemptAt": datetime
  }
}

Sample request:

2. The merchant checks the retry status

The recovery plan runs for up to 20 days, with up to 5 attempts (merchant configurable). The merchant needs to know, at any point, whether a retry has already recovered the payment or whether the plan is still waiting. Three ways to check, in order of how much work they save:

Recommended

Watch webhooks

  • Notified whenever a retry runs.
  • Updates the original transaction's history.
  • No polling required.
Alternative

Query the transaction

  • Query the original declined transaction by id.
  • Full history under attempts.
  • Most recent attempt listed first.
Alternative

Query by reference

  • Search using merchantTransactionId instead.
  • Locates the same transaction and history.
  • Useful when the id was not stored.
How to read the outcome
  • Recovered: any attempt in attempts shows a successful result, wherever it sits in the sequence.
  • Not recovered: the plan closes (DS) before that happens, either the 20 day window elapsed or the retry limit was reached with no success.
  • Still pending: nextAttemptAt is present in the response, meaning a further retry is still scheduled.

Sample request:

Temporary funding issue (MAC 24-30)

Retry later
The merchant initiates a transaction, but the issuer returns MAC 24-30, a temporary funding issue. Funds may become available later. Immediate retries are discouraged. MAC Scheduler automatically delays and schedules the retry at an issuer‑compliant time.

How it works

1

The merchant initiates a payment

The transaction is declined with MAC 24-30 (Temporary Funding Issue).

2

The merchant checks the retry status

The merchant views scheduled retry attempts and outcomes.

Transactions created
DBDeclined
→
SDPlan created
→
DBRetry declined
→
DBRetry succeeds
→
DSPlan ends

1. The merchant initiates a payment

Initiate a server‑to‑server POST request with the required payment data. MAC values and retry timing are simulated using custom parameters to control the retry flow. Use:

  • customParameters[MacRetry.testMacs] to return the same MAC on each retry
  • customParameters[MacRetry.timeProfile] to define retry delays in minutes
When retries continue to return MAC 24-30, MAC Scheduler maintains the original recovery plan.
The recovery plan is automatically ended (DS) when a retry succeeds or the maximum number of retries is reached.

What this creates
A declined payment that qualifies for scheduling creates a linked SD transaction. Its id and next attempt time appear in the response under processingDetails.macScheduler, as scheduledTxId and nextAttemptAt. nextAttemptAt is present whenever a retry is still scheduled.

Sample request:

2. The merchant checks the retry status

The recovery plan runs for up to 20 days, with up to 5 attempts (merchant configurable). The merchant needs to know, at any point, whether a retry has already recovered the payment or whether the plan is still waiting. Three ways to check, in order of how much work they save:

Recommended

Watch webhooks

  • Notified whenever a retry runs.
  • Updates the original transaction's history.
  • No polling required.
Alternative

Query the transaction

  • Query the original declined transaction by id.
  • Full history under attempts.
  • Most recent attempt listed first.
Alternative

Query by reference

  • Search using merchantTransactionId instead.
  • Locates the same transaction and history.
  • Useful when the id was not stored.
How to read the outcome
  • Recovered: any attempt in attempts shows a successful result, wherever it sits in the sequence.
  • Not recovered: the plan closes (DS) before that happens, either the 20 day window elapsed or the retry limit was reached with no success.
  • Still pending: nextAttemptAt is present in the response, meaning a further retry is still scheduled.
  • Response shape: same as Insufficient funds retry, scheduledTxId and nextAttemptAt after step 1, an attempts array after step 2.

Sample request:

Adaptive MAC retry

Retry later
A retry is successfully scheduled based on issuer guidance, but the issuer returns a different MAC on a subsequent retry. This indicates a change in conditions. MAC Scheduler dynamically adapts, reschedules, or stops retries based on the latest MAC.

How it works

1

The merchant initiates a payment

The transaction is declined with MAC 24-30 (Temporary Funding Issue) or MAC 02 (Insufficient Funds).

2

The merchant checks the retry status

The merchant views scheduled retry attempts and outcomes.

Transactions created
DBDeclined
→
SDPlan created
→
DBRetry declined (new MAC)
→
RSPlan updated
→
DBRetry succeeds
→
DSPlan ends

1. The merchant initiates a payment

Initiate a server‑to‑server POST request with the required payment data. MAC values and retry timing are simulated using custom parameters to control the retry flow. Use:

  • customParameters[MacRetry.testMacs] to define MAC values for each retry attempt
  • customParameters[MacRetry.timeProfile] to define retry delays in minutes
When a retry returns a different MAC, MAC Scheduler automatically updates the recovery plan.
When a retry succeeds or the maximum number of retries is reached, the recovery plan is automatically ended (DS).
This allows fast and predictable testing of retry‑later behaviour.

What this creates
A declined payment that qualifies for scheduling creates a linked SD transaction. Its id and next attempt time appear in the response under processingDetails.macScheduler, as scheduledTxId and nextAttemptAt. nextAttemptAt is present whenever a retry is still scheduled. If a later retry comes back with a different MAC, the plan itself is updated and that update is its own RS transaction.

Sample request:

2. The merchant checks the retry status

The recovery plan runs for up to 20 days, with up to 5 attempts (merchant configurable), and can be rescheduled mid-plan if the MAC changes. The merchant needs to know, at any point, whether a retry has already recovered the payment or whether the plan is still waiting. Three ways to check, in order of how much work they save:

Recommended

Watch webhooks

  • Notified whenever a retry runs, including reschedules.
  • Updates the original transaction's history.
  • No polling required.
Alternative

Query the transaction

  • Query the original declined transaction by id.
  • Full history under attempts.
  • Most recent DB attempt listed first.
Alternative

Query by reference

  • Search using merchantTransactionId instead.
  • Locates the same transaction and history.
  • Useful when the id was not stored.
How to read the outcome
  • Recovered: any attempt in attempts shows a successful result, regardless of how many times the plan was rescheduled along the way.
  • Not recovered: the plan closes (DS) before that happens, either the 20 day window elapsed or the retry limit was reached with no success.
  • Still pending: nextAttemptAt is present in the response, meaning a further retry is still scheduled.
  • RS updates: recorded as their own transactions in the merchant's full transaction history, not nested inside attempts, which lists only the DB retries.

Sample request:

Configuration

To consider
  • Requires a commercial agreement and support team activation.
  • Requires MAC Control to be enabled first.
  • MAC Control blocks non‑compliant retries so scheduling stays safe.

Please log in to view and manage MAC Scheduler configuration settings.

See also