Last updated: 2026-01-25

You run a successful online store. Orders come in, and your system handles payments in the background - subscriptions, recurring purchases, saved cards. One morning, your system tries to charge a card for a monthly subscription. The system declines the transaction. No explanation. No shopper to ask. Just a failed payment.

Your retry logic kicks in. You try again later that day. Then again the next morning. Still declined. Finally, the system drops the transaction. You lose the sale. And your system has logged three failed attempts - each one costing you time, network fees, and a hit to your approval rate.

But this is the part most merchants never see: the issuer had already sent a signal. With the first decline, they include a small code - a Merchant Advice Code (MAC). It might have said: Do not retry right now. Wait. Or, This account is closed. Stop trying. But your system did not act on it. Not because it ignored the advice - but because it did not understand it. MACs are quiet, useful messages from the issuer, passed through the card network, meant to guide your next move. They are not just technical metadata. They are a way to make smarter retry decisions, reduce unnecessary retries, and avoid higher fees that can come from repeated failed attempts.

MAC is how issuers talk to you. MAC Control is how you learn to listen.

What is a MAC

A short code sent by the issuer in the decline response to tell the merchant what to do next (retry, wait, or stop). Think of it as issuer guidance for your next move.

What do the card networks do

The card schemes - like Visa and Mastercard - do not create Merchant Advice Codes. But they play a critical role in how MACs work:

• They define the MAC rules and codes.
• They deliver the MAC from issuer to acquirer to merchant.
• They enforce the rules, including applying higher fees if you ignore MAC guidance.

In short: Issuer decides -> Scheme delivers -> Merchant acts (or absorbs higher costs for not acting).

Why MACs matter

MACs help you:

• Avoid unnecessary retries - stop sending transactions that fail due to MAC warnings.
• Reduce noise in your traffic - fewer failed attempts means cleaner data and better performance metrics.
• Stay compliant with scheme rules - avoid penalties for ignoring issuer guidance.

MAC Control does not boost approvals - it filters out the failures. That means fewer declines, fewer fees, and a clearer view of what is working.

Normalised MAC codes

Simple rules for merchants:

• 🔴 Do not retry - the issuer has indicated that you should not attempt the transaction again. Retrying may lead to higher costs.
• 🟠 Fix the issue first - something needs attention (for example, expired card, insufficient funds). Retry only after resolving it.
• 🟡 Wait before retrying - the timing is not right. Retrying too soon could result in extra fees or lower approval rates.

How MAC Control helps merchants

Go back to that moment - the system declines a transaction and must decide: retry or not? You received a:

• 🔴 03 - the account is closed.
• 🟡 02 - insufficient funds.
• 🟠 01 - the card needs updating.

Now what?

You could build logic to interpret each MAC. You could track scheme rules, retry windows, and fee thresholds. And yes - it is the merchant's responsibility to follow issuer advice. But MAC Control simplifies this by automating the complexity. Once enabled, MAC Control reads the MAC, understands the issuer's advice, and makes the decision for you instantly.

MAC Control responses:

• 🔴 03 / 🔴 21: Block for 30 days - issue is permanent or customer opted out.
• 🟡 02 / 🟡 24-30: Block temporarily - retry allowed after delay.
• 🟠 01 (card update): Block for 7 days - unless card info is refreshed.
• 🟠 01 (SCA needed): Block for 7 days - until 3DS is enabled.
• 🟠 22: Block for 30 days - merchant not eligible for product.

MAC Control = smarter retries, fewer costs, better compliance.

Where MAC Control applies

MAC Control activates when:

• A transaction uses a PAN, wallet DPAN, or network token.
• A MAC is present in the decline response.

It applies across:

• Saved cards
• Subscription renewals
• Wallet payments
• Online pre-auths, debits, rebills, refunds, reversals, credits

MAC Control works across acquirers that support MACs. Not all acquirers expose MACs, so coverage may vary.

How MAC Control decides

Account-level issues

These account-level issues are cardholder or merchant issues, not transaction issues. MAC Control blocks retries unless something changes.

• 🟠 01 - card needs update or SCA not completed.
• 🔴 03 - account closed or flagged for fraud.
• 🟠 22 - merchant not eligible for instalment product.

Changing the amount or merchant transaction ID does not help. Retry only works if the card or merchant status changes. The issue is structural, not transactional.

Examples:

• Card expired -> retry only after update.
• Strong Customer Authentication (SCA) required -> retry only after authentication.

Transaction-level issues

These transaction-level issues are transaction issues, related to things such as amount or agreement. MAC Control blocks retries that are the same, but allows changes.

• 🟡 02 / 🟡 24-30 - cardholder may add funds. Retry later or with smaller amount.
• 🔴 21 - customer cancelled agreement. Retry only with new consent.

Examples:

• Retry later with a new amount.
• Retry with a new order or updated agreement.