MAC Control

Last updated:August 5, 2026

Use this playground to see how MAC Control reacts when a declined transaction is retried.

When the issuer returns a Merchant Advice Code, MAC Control checks the advice before the next attempt is allowed. Depending on the MAC, the retry may be allowed, temporarily blocked, or stopped to avoid unnecessary retry costs and compliance risk.

In this playground, you can:

  • choose a decline scenario
  • trigger a specific MAC response
  • attempt a retry
  • see whether MAC Control allows or blocks the retry
  • understand the reason behind the decision

The focus here is simple: should this retry happen now, or should it be stopped?

How MAC Control decides
Declined with a MAC
Issuer advice is present
MAC Control checks the code
Decision point
Retry allowed
Retry blocked

Every use case below walks through this same decision, with a different MAC code and outcome.

To consider
  • All examples use the DB (debit) payment type for simplicity.
  • MAC Control supports other types: pre-auths, rebills, refunds, reversals, and credits.
  • MAC Control applies only when MACs are exposed by the acquirer and present in the issuer response.
  • MAC Control works across PANs, wallet DPANs, and network tokens.

Use cases

Account closed (MAC 03)

Do not retry
The merchant initiates a transaction, but the issuer responds with MAC 03. The account is permanently closed. This is a hard decline. Retrying will not work and may lead to higher costs. MAC Control blocks the retry for 30 days to prevent unnecessary costs and ensure compliance.

How it works

1

The merchant initiates a payment

The transaction gets declined with MAC 03 (Account Closed).

2

The merchant attempts a retry

MAC Control blocks the retry for 30 days.

Transactions created
DBDeclined
→
DBBlocked, no retry

1. The merchant initiates a payment

Initiate a server-to-server POST request with the required payment data. Use an amount ending in .03 to simulate MAC 03.

What this creates
The MAC itself is returned under resultDetails.MerchantAdviceCode. That's the only new field on this initial decline, the processingDetails.macControl history described in step 2 only appears once a retry is actually attempted and blocked.

Sample request:

2. The merchant attempts a retry

Retry the same transaction using the same account. Changing the amount, currency, or merchant transaction ID won’t help. The issue is structural, not transactional. MAC Control blocks the retry for 30 days.

Merchant recommendation:

  • Do not retry with the same account
  • Prompt the customer to provide a new payment method

How the block works
A blocked retry never reaches the issuer or network. It returns result code 700.601.003, status 76 (REJECTED_MAC), reason 76.20 (do not retry), and its response carries processingDetails.macControl.originalTxId, linking it back to the original declined transaction. See Result codes for the full list.

Sample request:

Recurring cancelled (MAC 21)

Do not retry
The merchant initiates a recurring payment, but the issuer responds with MAC 21, Recurring Cancelled. This indicates that the cardholder has cancelled their recurring agreement (e.g., subscription, mandate). Retrying the same transaction violates issuer intent. MAC Control blocks the retry for 30 days to enforce compliance and prevent unnecessary costs.

How it works

1

The merchant initiates a recurring payment

The transaction gets declined with MAC 21 (Customer cancelled recurring agreement).

2

The merchant attempts a retry

MAC Control blocks the retry for 30 days.

Transactions created
DBDeclined
→
DBBlocked, no retry

1. The merchant initiates a payment

Initiate a server-to-server POST request simulating a recurring payment. Use an amount ending in .21 to simulate MAC 21.

What this creates
The MAC itself is returned under resultDetails.MerchantAdviceCode. That's the only new field on this initial decline, the processingDetails.macControl history described in step 2 only appears once a retry is actually attempted and blocked.

Sample request:

2. The merchant attempts a retry

Retry the same transaction using the same account, amount, currency, and merchantTransactionId. MAC Control blocks the retry for 30 days.

Merchant recommendation:

  • Do not retry the same recurring transaction
  • Notify the customer that their recurring agreement has been cancelled
  • Offer reactivation options (e.g., opt-in again, re-subscribe)
  • Consider switching to a one-time payment if the customer still wants to complete the transaction

How the block works
A blocked retry never reaches the issuer or network. It returns result code 700.601.021, status 76 (REJECTED_MAC), reason 76.20 (do not retry), and its response carries processingDetails.macControl.originalTxId, linking it back to the original declined transaction. See Result codes for the full list.

Sample request:

Insufficient funds (MAC 02, MAC 24-30)

Retry later
The merchant initiates a transaction, but the issuer responds with MAC 02 or 24-30, insufficient funds or credit limit reached. These are transaction-level issues. The cardholder may resolve them (e.g., by adding funds), so retrying can succeed, but only after the issuer-advised delay. MAC Control blocks identical retries during this window to avoid unnecessary costs.

How it works

1

The merchant initiates a payment

The transaction gets declined with MAC 02 / 24-30, credit limits or insufficient funds.

2

The merchant attempts a retry

MAC Control blocks it for the advised delay.

Transactions created
DBDeclined
→
DBBlocked, retry later

1. The merchant initiates a payment

Initiate a server-to-server POST request simulating a payment. Use an amount ending in .02, .24, .25 etc to simulate MAC 02, 24-30.

What this creates
The MAC itself is returned under resultDetails.MerchantAdviceCode. That's the only new field on this initial decline, the processingDetails.macControl history described in step 2 only appears once a retry is actually attempted and blocked.

Sample request:

2. The merchant attempts a retry

Retry the same transaction using the same account, amount, currency, and merchantTransactionId. MAC Control blocks it for the advised delay.

Merchant recommendation:

  • Do not retry immediately - respect the issuer-advised delay
  • Wait for the delay window before retrying the same transaction
  • Optionally retry with a modified transaction (e.g., lower amount)
  • Notify the customer about the failed payment and offer alternative payment methods

How the block works
A blocked retry never reaches the issuer or network. It returns one of 700.600.002 (MAC 02) through 700.600.030 (MAC 30), status 76 (REJECTED_MAC), reason 76.10 (retry after delay), matching the exact window advised for that code. Its response also carries processingDetails.macControl.originalTxId, linking it back to the original declined transaction. See Result codes for the code-by-code breakdown.

Sample request:

Update account info (MAC 01)

Fix first
The merchant initiates a transaction, but the issuer responds with MAC 01, cardholder account needs update. This typically means the card is expired, replaced, or otherwise outdated. Retrying with the same credentials will fail. MAC Control blocks the retry for 7 days, unless updated credentials are received via Real Time Account Updater or Network Token lifecycle events.

How it works

1

The merchant initiates a payment

The transaction gets declined with MAC 01, cardholder account needs update.

2

The merchant attempts a retry

MAC Control blocks it for 7 days unless credentials are refreshed.

Transactions created
DBDeclined
→
DBBlocked until fixed

1. The merchant initiates a payment

Initiate a server-to-server POST request simulating a payment. Use an amount ending in .01 to simulate MAC 01.

What this creates
The MAC itself is returned under resultDetails.MerchantAdviceCode. That's the only new field on this initial decline, the processingDetails.macControl history described in step 2 only appears once a retry is actually attempted and blocked.

Sample request:

2. The merchant attempts a retry

Retry the same transaction using the same account. Changing the amount, currency, or merchant transaction ID won’t help. The issue is structural, not transactional. MAC Control blocks it for 7 days unless credentials are refreshed.

Merchant recommendation:

  • Do not retry with the same outdated credentials
  • Wait for credential refresh via Real Time Account Updater or Network Token rails
  • Prompt customer to update their card details if no automatic update is avaialble
  • Consider offering alternative payment methods

How the block works
A blocked retry never reaches the issuer or network. It returns result code 700.601.001, status 76 (REJECTED_MAC), reason 76.20 (do not retry), and its response carries processingDetails.macControl.originalTxId, linking it back to the original declined transaction. See Result codes for the full list.

Sample request:

SCA required (MAC 01)

Fix first
The merchant initiates a transaction, but the issuer responds with MAC 01, Strong Customer Authentication (SCA) required. This means the transaction must be authenticated using EMV 3DS or another SCA-compliant method. Retrying without authentication will fail. MAC Control blocks the retry for 7 days, giving the merchant time to enable 3DS and meet issuer requirements.

How it works

1

The merchant initiates a payment

The transaction gets declined with MAC 01, Strong Customer Authentication (SCA) required.

2

The merchant attempts a retry

MAC Control blocks it for 7 days.

Transactions created
DBDeclined
→
DBBlocked until fixed

1. The merchant initiates a payment

Initiate a server-to-server POST request simulating a payment. Use an amount ending in .11 to simulate MAC 01.

What this creates
The MAC itself is returned under resultDetails.MerchantAdviceCode. That's the only new field on this initial decline, the processingDetails.macControl history described in step 2 only appears once a retry is actually attempted and blocked.

Sample request:

2. The merchant attempts a retry

Retry the same transaction using the same account Changing the amount, currency, or merchant transaction ID won’t help. The issue is structural, not transactional. MAC Control blocks it for 7 days.

Merchant recommendation:

  • Do not retry without authentication
  • Enable EMV 3DS on your merchant channel and account

How the block works
A blocked retry never reaches the issuer or network. It returns result code 700.601.001, status 76 (REJECTED_MAC), reason 76.20 (do not retry), and its response carries processingDetails.macControl.originalTxId, linking it back to the original declined transaction. See Result codes for the full list.

Sample request:

Not eligible for installment (MAC 22)

Fix first
The merchant initiates a transaction using an installment product, but the issuer responds with MAC 22, not eligible for product. This means the merchant is not enrolled in the scheme’s installment program or the product is not supported for the cardholder. Retrying with the same account and product will fail. MAC Control blocks the retry for 30 days, allowing time to review eligibility and avoid repeated declines.

How it works

1

The merchant initiates a payment

The transaction gets declined with MAC 22, merchant not eligible for installment product.

2

The merchant attempts a retry

MAC Control blocks it for 30 days.

Transactions created
DBDeclined
→
DBBlocked until fixed

1. The merchant initiates a payment

Initiate a server-to-server POST request simulating a payment. Use an amount ending in .22 to simulate MAC 22.

What this creates
The MAC itself is returned under resultDetails.MerchantAdviceCode. That's the only new field on this initial decline, the processingDetails.macControl history described in step 2 only appears once a retry is actually attempted and blocked.

Sample request:

2. The merchant attempts a retry

Retry the same transaction using the same account Changing the amount, currency, or merchant transaction ID won’t help. The issue is structural, not transactional. MAC Control blocks it for 30 days.

Merchant recommendation:

  • Do not retry with the same product and account
  • Review your eligibility for the installment program with your acquirer or scheme
  • Switch to a standard payment product if installment is not supported
  • Notify the customer and offer alternative payment options (e.g., pay in full, use a wallet).

How the block works
A blocked retry never reaches the issuer or network. It returns result code 700.601.022, status 76 (REJECTED_MAC), reason 76.20 (do not retry), and its response carries processingDetails.macControl.originalTxId, linking it back to the original declined transaction. See Result codes for the full list.

Sample request:

Result codes

Every blocked retry returns a dedicated result code, so merchants always know exactly why a retry was stopped and, where applicable, when to try again. All of them carry status code 76 (REJECTED_MAC) and one of two reason codes: 76.10 (retry after delay) or 76.20 (do not retry). The blocked retry's own response also carries processingDetails.macControl.originalTxId, linking it back to the original declined transaction. Codes below are pulled live from the platform, so this list stays current automatically as codes are added or changed.

Do not retry Retry later Fix first
Retry after delay, Group 700.600.xxx (reason 76.10)
Result codeDescription
700.600.002Retry blocked (Retry after 72 hours)
700.600.024Retry blocked (Retry after 1 hour)
700.600.025Retry blocked (Retry after 24 hours)
700.600.026Retry blocked (Retry after 2 days)
700.600.027Retry blocked (Retry after 4 days)
700.600.028Retry blocked (Retry after 6 days)
700.600.029Retry blocked (Retry after 8 days)
700.600.030Retry blocked (Retry after 10 days)
700.600.031Auto Retry blocked. Max retries exceeded.
Do not retry, Group 700.601.xxx (reason 76.20)
Result codeDescription
700.601.001Retry blocked (Update card info or use 3D Secure before retrying)
700.601.003Retry blocked (Account closed or flagged for fraud. Request a new payment method)
700.601.021Retry blocked (Recurring payment canceled by cardholder. Stop billing and remove card)
700.601.022Retry blocked (Merchant not eligible for product. Contact your acquirer)

For every other result code family beyond MAC Control, see Result codes, section 4.5.

Configuration

To consider
  • Requires a commercial agreement and support team activation.

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

See also