Merchant Advice Code (MAC)

Last updated:May 11, 2026

You run an online store. Payments happen in the background — subscriptions, recurring purchases, saved cards and wallet payments.
One morning, your system tries to charge a card for a monthly subscription. The transaction is declined.

There is no shopper present. No one can immediately top up the account, authenticate, or choose another payment method.

Your retry logic kicks in. You try again later that day. Then again the next morning. Still declined.
The sale may be lost. And every failed attempt adds cost, noise, and pressure on your approval rates.

But the issuer may already have sent advice with the first decline.
That advice is called a Merchant Advice Code, or MAC.

It can tell you:

  • Do not retry.
  • Retry later.
  • Fix something first.
  • The account is closed.
  • The customer cancelled the recurring agreement.

A MAC is not just technical metadata. It is issuer guidance for your next move.
MAC is how issuers talk to you.
MAC Control and MAC Scheduler help you act on that advice.

What is a MAC?

A short code sent by the issuer in the decline response. It tells you what to do next.
The decline code explains why the payment failed. The MAC explains what action should happen next.

For example:

  • Stop retrying
  • Wait before retrying
  • Update the card
  • Complete authentication
  • Retry later when funds may be available

What do the card networks do?

The card schemes - like Visa and Mastercard - don't create Merchant Advice Codes. But they play a critical role in how MACs work:
  • Define the MAC rules and codes
  • Deliver the MAC from issuer to acquirer to merchant
  • Enforce retry rules
  • May apply higher fees when issuer advice is ignored
In short: Issuer decides → Scheme delivers → Merchant acts (or absorbs higher costs for not acting).

Why MACs matter

MACs help you avoid blind retrues. They help 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.

Simple MAC rules

🔴 Do not retry
The issuer says the payment should not be attempted again.

🟠 Fix the issue first
Something must change before another retry makes sense.

🟡 Wait before retrying
The payment may still succeed later, but not now.

⚪ Informational
The MAC gives context but may not require retry blocking.

MAC Likely decline reason Issuer advice
🟠01 Account update or SCA needed Retry with updated card info or 3DS
🟡02 Insufficient funds or credit limit Retry after 72 hours
🔴03 Account closed or fraud suspected Do not retry. Obtain new payment method
⚪04 Token setup issue Retry with correct token configuration
🔴21 Recurring agreement cancelled by customer Do not retry. Cardholder opted out
🟠22 Merchant not eligible for installments Do not retry
🟡24 Temporary funding issue Retry after 1 hour
🟡25 Temporary funding issue Retry after 24 hours
🟡26 Temporary funding issue Retry after 2 days
🟡27 Temporary funding issue Retry after 4 days
🟡28 Temporary funding issue Retry after 6 days
🟡29 Temporary funding issue Retry after 8 days
🟡30 Temporary funding issue Retry after 10 days
⚪40 Consumer non-reloadable prepaid card used Informational only
⚪41 Single-use virtual card used Informational only
⚪42 Sanctions screening triggered Do not retry. Cardholder or transaction matched a sanctions list
⚪43 Multi-use virtual card is used Informational only. May appear on approved or declined transactions

MAC Control

MAC Control helps you apply issuer advice automatically. When a declined transaction includes a MAC, MAC Control reads the advice and decides what should happen next.

It can:

  • allow the retry,
  • or block the retry.

This helps you avoid retry attempts that are unlikely to succeed or should not be sent.

MAC Control does not create new demand.
It does not guarantee approval uplift.
It removes retries that should not happen.

That means fewer unnecessary declines, fewer wasted attempts, and better retry discipline.

MAC Control prevents the wrong retries.

How MAC Control helps

Let’s say a payment is declined and you receive:

  • 🔴03 — account closed
  • 🟡02 — insufficient funds
  • 🟠01 — card update or authentication needed/li>

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.

Here’s how MAC Control responds:

MAC scenario MAC Control action
🔴03 / 🔴21 Block for 30 days. Issue is permanent or customer opted out.
🟡02 / 🟡24-30 Block temporarily. Retry is allowed after the advised delay.
🟠01 - card update needed Block for 7 days unless the card information is refreshed.
🟠01 - SCA needed Block for 7 days until authentication is completed.
🟠22 Block for 30 days. Merchant is not eligible for the product.

CIT and MIT handling

MAC Control can apply to both:
  • CIT — Customer Initiated Transactions
  • MIT — Merchant Initiated Transactions
But the behaviour should not always be the same.

Customer Initiated Transactions

A CIT happens when the shopper is present. For example, a shopper is checking out and the payment fails because of insufficient funds.

In this case, the shopper may still take action. They may:

  • top up the account,
  • choose another card,
  • change the payment method,
  • reduce the basket amount,
  • or retry after resolving the issue.

For this reason, MAC Control can be configured more flexibly for CIT payments.
For example, it may avoid blocking a present shopper when the issuer advice is related to insufficient funds and the shopper can still fix the problem.

The goal is not to interrupt a recoverable checkout.
The goal is to stop unwanted or repeated retries that add no value.

Merchant Initiated Transactions

A MIT happens when the merchant initiates the payment without the shopper being present. This is common for:
  • subscriptions,
  • recurring payments,
  • rebills,
  • instalments,
  • saved-card agreements.

In MIT flows, the merchant controls the retry logic. The shopper is not present to choose another payment method or fix the issue immediately.
That makes issuer advice especially important.

MAC Control can block unwanted merchant retries and stop repeated attempts that should not be sent.

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-authorizations, debits, rebills, refunds, reversals, credits

MAC Control works across acquirers — but only where MACs are supported.
Not all acquirers expose MACs, so coverage may vary.

How MAC Control decides

MAC Control looks at the type of issue behind the MAC.

Account-level issues

These are tied to the cardholder account, card status, authentication, or merchant eligibility.
Examples:
  • 🟠01 — card update or SCA needed
  • 🔴03 — account closed or fraud suspected
  • 🟠22 — merchant not eligible for instalments

Changing the amount or order reference will not fix these issues.
The retry should only happen after something changes.

For example:

  • the card is updated,
  • authentication is completed,
  • the shopper provides a new payment method,
  • or the merchant eligibility issue is resolved.

Transaction-level issues

These are tied to the specific payment, agreement, amount, or timing.

Examples:

  • 🟡02 / 🟡24–30 — temporary funding issue
  • 🔴21 — recurring agreement cancelled
For these cases, the right action depends on the issuer advice.

It may mean:

  • retry later,
  • retry with a different amount,
  • retry only with new consent,
  • or stop retrying completely.

MAC Scheduler

MAC Scheduler is used for recoverable MIT payments.
It works only for merchant-initiated payments over a merchant token.
It does not apply to CIT payments.

Why?

Because with CIT, the shopper is present. The shopper controls the next action.
They may retry, top up the account, change the card, or choose another payment method.

With MIT, the shopper is not present. The merchant controls the retry logic.
That is where MAC Scheduler adds value.
It turns retry-later advice into a managed recovery plan.

MAC Scheduler recovers eligible MIT payments later, based on issuer advice.

When MAC Scheduler 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.
It is 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.

MAC Control is required before MAC Scheduler

MAC Control is a prerequisite for MAC Scheduler. This is important.
Before scheduling recovery attempts, the merchant first needs control over unwanted retries.

MAC Control blocks or delays retries based on issuer advice.
MAC Scheduler then uses eligible retry-later cases to create a recovery plan.

In short:

  • MAC Control stops the wrong merchant retries.
  • MAC Scheduler schedules the right merchant retries.

How MAC Scheduler works

A recurring or subscription payment fails. The issuer returns a retry-later MAC.

MAC Control first checks the issuer advice and blocks the immediate merchant retry. This prevents unwanted retry attempts.
MAC Scheduler can then create a recovery plan for the failed MIT payment.

The merchant can configure the maximum number of retry attempts. MAC Scheduler can retry up to 5 times within a 20-day recovery window.

Each retry attempt is treated as a new payment attempt. If the retry is declined again, the new MAC is checked again.
The recovery plan is then adapted based on the latest issuer advice.

For example:

  1. A subscription payment fails.
  2. The issuer returns 🟡02 — retry after 72 hours.
  3. MAC Scheduler schedules the next retry after 72 hours.
  4. That retry is declined again.
  5. The issuer now returns 🟡30 — retry after 10 days.
  6. MAC Scheduler updates the recovery plan.
  7. The next retry is scheduled after 10 days.

The retry only happens if both conditions are still met:

  • the payment is still inside the 20-day recovery window;
  • the merchant’s configured retry limit has not been reached.

If the payment succeeds, the recovery plan ends.
If the retry limit is reached, the recovery plan ends.
If the 20-day recovery window expires, the recovery plan ends.

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.

Example: subscription payment with insufficient funds

A monthly subscription payment fails because the customer has insufficient funds.
The issuer returns: 🟡02 — insufficient funds or credit limit.

Without MAC Scheduler, the merchant may retry too soon or too often.
With MAC Scheduler, the payment is scheduled for a later retry.

The retry happens when the issuer advice allows it.
If the payment is recovered, the schedule is closed.
This helps recover the sale without creating unnecessary retry traffic.

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
🟡 CIT insufficient funds Shopper is present and may take action MAC Control Can be configured flexibly to avoid blocking recoverable checkout behaviour
🟡 MIT retry later Shopper is not present, but payment may be recoverable later MAC Control + MAC Scheduler Retry is blocked now and scheduled for later recovery
🟡 MIT recovered Later retry succeeds MAC Scheduler Recovery plan ends

From blind retries to managed recovery

A declined payment is not always the end of the sale.
But it is also not always a signal to retry immediately.

MACs help you understand the difference.
MAC Control helps you stop retries that should not happen.
MAC Scheduler helps you recover eligible MIT payments that should happen later.

Together, they help you:

  • reduce unnecessary retries,
  • avoid avoidable retry cost,
  • respect issuer advice,
  • keep payment traffic cleaner,
  • protect the checkout experience for present shoppers,
  • and recover eligible recurring revenue.

MAC is how issuers talk to you.
MAC Control helps you listen.
MAC Scheduler helps you recover at the right time.

See also