MAC Scheduler

Last updated:May 12, 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 authorisation decision. It decides when the next attempt should happen.

The focus here is simple: if the retry should not happen now, when should recovery be attempted?

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 - 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:
DB
DB
DB
DB

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.

Sample request:

2. The merchant checks the retry status

Watch webhooks (recommended)

  • The merchant receives notifications whenever an automatic retry is executed.
  • Each retry updates the history of the original declined transaction.
  • This provides continuous visibility without actively querying transactions.

Query the original declined transaction

  • The merchant queries the original declined transaction.
  • The full retry history is stored on the original transaction, under processingDetails.
  • All retry attempts are listed with result codes and timestamps; if any retry is successful, the payment has been recovered.

Query by merchantTransactionId

  • The merchant searches using their own reference.
  • This locates the original transaction and its retry history.
  • Useful when the original transaction ID is not available.

Sample request:

🟡Temporary funding issue - Retry later

The merchant initiates a transaction, but the issuer returns 🟡 MAC 24–30 — 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 queries the retry status

The merchant views scheduled retry attempts and outcomes.

Transactions:
DB
DB
DB
DB

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.

Sample request:

2. The merchant queries the retry status

Watch webhooks (recommended)

  • The merchant receives notifications whenever an automatic retry is executed.
  • Each retry updates the history of the original declined transaction.
  • This provides continuous visibility without actively querying transactions.

Query the original declined transaction

  • The merchant queries the original declined transaction.
  • The full retry history is stored on the original transaction, under processingDetails.
  • All retry attempts are listed with result codes and timestamps; if any retry is successful, the payment has been recovered.

Query by merchantTransactionId

  • The merchant searches using their own reference.
  • This locates the original transaction and its retry history.
  • Useful when the original transaction ID is not available.

Sample request:

Adaptive MAC retry

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 queries the retry status

The merchant views scheduled retry attempts and outcomes.

Transactions:
DB
DB
DB
DB

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.

Sample request:

2. The merchant queries the retry status

Watch webhooks (recommended)

  • The merchant receives notifications whenever an automatic retry is executed.
  • Each retry updates the history of the original declined transaction.
  • This provides continuous visibility without actively querying transactions.

Query the original declined transaction

  • The merchant queries the original declined transaction.
  • The full retry history is stored on the original transaction, under processingDetails.
  • All retry attempts are listed with result codes and timestamps; if any retry is successful, the payment has been recovered.

Query by merchantTransactionId

  • The merchant searches using their own reference.
  • This locates the original transaction and its retry history.
  • Useful when the original transaction ID is not available.

Sample request:

Configuration

MAC Scheduler requires a commercial agreement and must be activated with support team assistance.
MAC Scheduler requires MAC Control to be enabled.
MAC Control guarantees that blind or non‑compliant retries are blocked, allowing MAC Scheduler to safely schedule retries later only when issuer guidance permits it.

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

See also