MAC Control

Last updated:May 11, 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?

Use cases

🟥 Account closed (MAC 03)

The merchant initiates a transaction, but the issuer responds with MAC 🔴03 — the account is permanently closed. This is a hard decline. Retrying won’t 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:

---

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.

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

Sample request:

🟥 Recurring cancelled (MAC 21)

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:

---

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.

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

Sample request:

🟨 Insufficient Funds (MAC 02, MAC 24-30)

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:

---

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.

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

Sample request:

🟧 Update Account Info (MAC 01)

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:

---

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.

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

Sample request:

🟧 SCA Required (MAC 01)

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:

---

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.

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

Sample request:

🟧 Not Eligible for Installment (MAC 22)

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:

---

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.

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).

Sample request:

Configuration

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

See also

• MAC Guide - Learn the full MAC journey, from issuer advice to control and recovery.
• MAC Scheduler - See how retry-later advice is converted into scheduled recovery attempts.