Merchant Advice Code (MAC)
Last updated:August 4, 2026
A decline is not always the end of a sale. Sometimes it is an instruction. Anna is a subscription shopper. Her renewal is a merchant initiated transaction, no shopper present to switch cards or try again. The issuer declines it, the merchant's system retries blindly, and both attempts fail the same way. Multiply that across a subscriber base and the noise becomes real, avoidable revenue at risk.
- Every decline can carry more than a reason code: an instruction from the issuer on what to do next.
- That instruction is the Merchant Advice Code (MAC): stop, wait, fix something, or retry later.
- Listening to it, instead of retrying blindly, protects margin and recovers revenue.
What is a MAC?
A MAC is a short code the issuer attaches to a decline response. The decline code explains why the payment failed. The MAC explains what should happen next: stop retrying, wait before retrying, update the card, complete authentication, or retry later when funds may be available.
The card schemes, Visa and Mastercard among them, do not create Merchant Advice Codes. They define the MAC rules and codes, deliver the MAC from issuer to acquirer to merchant, enforce retry rules, and may apply higher fees when issuer advice is ignored.
The issuer decides what should happen next. The scheme delivers that decision. You choose whether to act on it, or absorb the cost of ignoring it.
Why it matters: MACs help you avoid blind retries. Handling them correctly means you:
- Stop retrying payments that should not be retried.
- Wait when the issuer says the timing is not right.
- Fix card, authentication, or agreement issues before trying again.
- Reduce failed retry traffic.
- Avoid unnecessary fees.
- Keep payment data cleaner.
- Recover eligible recurring payments at the right time.
MAC handling is not only about blocking. It is about knowing the difference between a payment that should stop, a payment that should wait, and a payment that can still be recovered.
Reading a MAC's signal
Every MAC falls into one of four groups, and the group determines what happens next:
The table below maps confirmed MAC codes across Visa and Mastercard to the likely decline reason and the issuer's advice, grouped the same way as the signals above.
| MAC | Category | Likely decline reason | Issuer advice |
|---|---|---|---|
01   | Fix first | Account update or SCA needed | Retry with updated card info or 3DS |
02 | Retry later | Insufficient funds or credit limit | Retry after 72 hours |
03 | Do not retry | Account closed or fraud suspected | Do not retry. Obtain a new payment method |
04 | Informational | Token setup issue | Retry with correct token configuration |
21 | Do not retry | Recurring agreement cancelled by customer | Do not retry. Cardholder opted out |
22 | Fix first | Merchant not eligible for instalments | Do not retry |
24 | Retry later | Temporary funding issue | Retry after 1 hour |
25 | Retry later | Temporary funding issue | Retry after 24 hours |
26 | Retry later | Temporary funding issue | Retry after 2 days |
27 | Retry later | Temporary funding issue | Retry after 4 days |
28 | Retry later | Temporary funding issue | Retry after 6 days |
29 | Retry later | Temporary funding issue | Retry after 8 days |
30 | Retry later | Temporary funding issue | Retry after 10 days |
40 | Informational | Consumer non-reloadable prepaid card used | Informational only |
41 | Informational | Single-use virtual card used | Informational only |
42 | Informational | Sanctions screening triggered | Do not retry. Cardholder or transaction matched a sanctions list |
43 | Informational | Multi-use virtual card is used | Informational only. May appear on approved or declined transactions |
MAC Control
MAC Control applies issuer advice automatically. When a declined transaction carries a MAC, MAC Control reads the advice and decides what should happen next: allow the retry, or block it.
MAC Control changes cost, not conversion. Retrying a payment the issuer already told you to stop does not raise your authorization rate, the transaction was never going to clear. What changes is the fee. Card networks mandate a fee on the acquirer for retries that ignore issuer advice, and the acquirer passes that fee on to you. MAC Control removes retries that were never going to succeed, which means removing a fee you would otherwise absorb. It protects margin. It does not create revenue. Recovering revenue is a different job, and it belongs to MAC Scheduler.
Where it applies, and reading it yourself
MAC Control activates when a transaction uses a PAN, wallet DPAN, or network token, and a MAC is present in the decline response. It applies across:
- Saved cards.
- Subscription renewals.
- Wallet payments.
- Online pre-authorizations, debits, rebills, refunds, reversals, and credits.
MAC Control automates the decision, but the signal itself is not locked away. Where an acquiring
connection supports it, the platform returns the issuer's Merchant Advice Code directly in the decline
response, as resultDetails.MerchantAdviceCode. You can read it yourself and build your
own retry logic on top of it, instead of or alongside MAC Control. Coverage depends on the acquiring
connection: not every acquirer exposes a MAC, so support varies by acquirer.
How it decides
MAC Control looks at the type of issue behind the MAC, not just its severity, since that decides what "fixed" actually means.
CIT and MIT handling
MAC Control applies to both customer initiated (CIT) and merchant initiated (MIT) transactions, but the right behaviour differs: only one of the two has a shopper present to act.
How it helps
- Each code gets the right block length, automatically, no manual lookup.
- Retry windows and fee thresholds are applied for you, every time.
MAC Scheduler
MAC Scheduler is used for recoverable MIT payments over a merchant token. It does not apply to CIT payments, because with CIT the shopper is present and controls the next action: retry, top up, switch cards, or choose another method. With MIT, the shopper is not present, the merchant controls the retry logic, and that is where MAC Scheduler adds value: it turns retry later advice into a managed recovery plan. Where MAC Control protects margin, MAC Scheduler recovers revenue.
When it helps
MAC Scheduler is useful when the payment is merchant initiated, the transaction uses a merchant token, the issuer advice says retry later, and the payment may still be recoverable. Typical examples include:
- Subscription renewals.
- Recurring payments.
- Rebills.
- Insufficient funds.
- Temporary credit limit issues.
MAC Scheduler is not for payments where the issuer says do not retry, and not for payments where the shopper must choose the next action. It is for MIT payments where the issuer indicates that retrying later may still make sense.
How it works
- Retries continue only while the payment is inside the recovery window.
- Retries stop once the configured retry limit is reached.
- The plan ends the moment the payment succeeds.
This replaces static retry rules with an adaptive recovery plan. The merchant does not retry blindly. The merchant retries when issuer advice says it still makes sense.
MAC Control and MAC Scheduler together
MAC Control and MAC Scheduler work together. They are not the same capability.
| Situation | What it means | Capability | Outcome |
|---|---|---|---|
| Do not retry | The issuer says stop | MAC Control | Retry is blocked. |
| Fix first | Something must change first | MAC Control | Retry is blocked or delayed. |
| Retry later | CIT, insufficient funds. The shopper is present and may still act. | MAC Control | Configured flexibly to avoid blocking recoverable checkout behaviour. |
| Retry later | MIT, retry later. The shopper is not present, but the payment may be recoverable later. | MAC Control + MAC Scheduler | Retry is blocked now and scheduled for later recovery. |
| Retry later | MIT, recovered. A later scheduled retry succeeds. | MAC Scheduler | The recovery plan ends. |
Put side by side, the split is simple:
What changes for you
A decline is not always a signal to retry immediately, or to give up. The difference is what the issuer already told you in the MAC. MAC Control blocked the retries that should never have been sent, and MAC Scheduler recovered the one that still had a chance. Anna's subscription renews without her ever seeing a declined charge. You get a cleaner retry queue and one less payment to chase.