MAC Control

Last updated:August 4, 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.

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

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)

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

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)

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

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)

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

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)

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

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)

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

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

MAC Control requires a commercial agreement and must be activated with support team assistance.

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

See also