Merchant Advice Codes (MAC): How to Stop Costly Retries and Recover Declined Transactions

By Risk Team, CatalystPay 

 

Quick Answer A Merchant Advice Code (MAC) is a short code the issuer attaches to a declined card payment telling you what to do next: stop, fix something first, or retry after a set delay. Card schemes expect you to follow it, and retries that ignore the advice can attract scheme fees that your acquirer passes on to you. On the CatalystPay gateway, where available on your acquiring connection, MAC Control reads the code and blocks retries that cannot succeed, and MAC Scheduler turns "retry later" advice on merchant-initiated payments into a timed recovery plan.

Table of contents

1. What is a Merchant Advice Code?
2. Decline code vs Merchant Advice Code: what's the difference?
3. The MAC codes you need to know (table)
4. Why MACs matter more for high-risk and subscription models
5. CIT vs MIT: where MAC handling actually pays off
6. MAC Control: blocking retries that will never succeed
7. MAC Scheduler: turning "retry later" into recovered revenue
8. A practical MAC playbook by code group
9. How CatalystPay helps
10. FAQ

What is a Merchant Advice Code?

A Merchant Advice Code is the issuer's instruction on a declined transaction. It travels from the issuer, through the scheme and your acquirer, back to you alongside the decline.

Visa and Mastercard define the codes and the retry rules around them. The issuer chooses which code to send. Your job is to act on it.

If you bill on stored cards, run rebills or process subscription renewals, MACs are the difference between a retry strategy and a guess.

Decline code vs Merchant Advice Code: what's the difference?

The two answer different questions:

In practice, you need both. The decline code tells your support team what to say to the customer; the MAC tells your billing engine whether, and when, to try again.

The MAC codes you need to know

Codes fall into four practical groups: do not retry, fix first, retry later and informational.

One distinction is worth building into your logic from day one:

• Account-level issues (01, 03, 22): nothing about the transaction will fix these. Changing the amount, currency or order reference does not help. Something has to change first: a card update, completed authentication, a new payment method or resolved eligibility.
• Transaction-level issues (02, 21, 24–30): the right move depends on the advice: wait and retry, retry with a different amount, retry only with fresh consent, or stop.

Why MACs matter more for high-risk and subscription models

If you run a subscription or rebill model in dating, adult, CBD and nutra, digital goods or skill-game memberships, a meaningful share of your revenue lives in merchant-initiated renewals. That is exactly where blind retry loops tend to hide.

Three reasons to take MACs seriously:

1. Cost. Card networks charge acquirers for retries that ignore issuer advice, and acquirers pass that cost on to merchants. Every retry against a closed account (MAC 03) or a cancelled agreement (MAC 21) is spend with no chance of return.
2. Customer experience. Retrying a customer who has cancelled their recurring agreement is not only wasted, it is how you turn a churned customer into a complaint or a dispute.
3. How your processing looks. Your retry behaviour is visible to your acquirer and the schemes. Disciplined, advice-led retries are part of running a well-managed card programme, something that matters when you depend on acquirer appetite for your vertical.

CIT vs MIT: where MAC handling actually pays off

Not every payment flow benefits in the same way.

If you are mostly CIT, typical for Forex and iGaming deposit flows, the win is reading the MAC at checkout: prompt 3DS on a MAC 01, or offer an alternative payment method straight away on a MAC 03.

If you are mostly MIT, you get both: fewer wasted retries and a structured way to recover the declines that are genuinely recoverable. 

You might want to check as well why Forex deposits fail.

MAC Control: blocking retries that will never succeed

MAC Control checks the MAC on a declined transaction before any retry goes out, then allows it, blocks it temporarily or stops it.

A blocked retry never reaches the issuer or the network. That is the point: you do not pay for an attempt the issuer has already told you will fail.

How the blocks work:

MAC Control covers PANs, wallet DPANs and network tokens, across saved cards, subscription renewals, wallet payments and online pre-authorisations, debits, rebills, refunds, reversals and credits.

Be clear-eyed about what it does: MAC Control does not raise authorisation rates. It removes retries that were never going to succeed and the fees that come with them.

MAC Scheduler: turning "retry later" into recovered revenue

Blocking the wrong retries is half the job. The other half is retrying the right ones at the right time.

MAC Scheduler takes "retry later" advice on merchant-initiated payments over a stored merchant token and builds a recovery plan around the issuer's timing:

• Eligible codes: MAC 02 and MAC 24–30.
• Attempts: up to 5, configurable by you.
• Window: up to 20 days.
• Timing: follows the issuer — for example, 72 hours after the first decline, then 10 days after new advice.
• Adaptive: each retry is a fresh attempt and the MAC is re-checked every time. If the issuer's advice changes mid-plan, the plan reschedules or stops.
• End state: the plan closes when a retry succeeds, the attempt limit is reached or the 20-day window ends.

MAC Scheduler does not change the issuer's decision. It decides when recovery is worth attempting. It requires MAC Control to be enabled first, so an immediate non-compliant retry cannot slip through. It is not used for CIT payments or "do not retry" advice.

For your developers Where your acquiring connection supports it, the issuer's MAC comes back on the decline in resultDetails.MerchantAdviceCode, so you can use it in your own retry logic or let MAC Control and MAC Scheduler handle it. Blocked retries return a dedicated status that links back to the original decline, and webhooks keep you updated on every scheduled retry. Full field-level detail is in our developer documentation.

Not sure how your current billing engine handles "retry later" declines? Ask our team to take a look

A practical MAC playbook by code group

Do not retry (03, 21, 42) Stop. For 03, ask the customer for a new payment method. For 21, stop billing, tell the customer, and offer reactivation or a one-off payment. For 42, do not retry.

Fix first (01, 22) For an account update, refresh credentials (account updater or network token lifecycle) or ask the customer to update their card. For SCA, make sure EMV 3DS is enabled on your channel and account, then retry with authentication. For 22, review instalment eligibility with your acquirer or switch to a standard product.

Retry later (02, 24–30) Wait for the advised window. Consider a modified transaction - for example, a lower amount and offer an alternative payment method. For recoverable MIT payments, let MAC Scheduler handle the timing.

Informational (04, 40, 41, 43) Use them to fix configuration (04: token set-up) or to enrich reporting on prepaid and virtual card usage.

Across all of them: retire blind, fixed-interval retry loops. Let issuer advice drive the decision.

How CatalystPay helps

Most retry problems are not visible until they show up as scheme fees, disputes or renewals that quietly stopped converting. If you run subscriptions or rebills in a high-risk vertical, that is usually the moment you need someone who can look at the whole picture, not just one setting.

At CatalystPay, we review how your retries behave today, check where issuer advice actually reaches you, and help you set up MAC Control and MAC Scheduler around your billing model — alongside the right acquiring arrangement for your vertical and markets.

You work with CatalystCare, our human support team, throughout.

MAC Control and MAC Scheduler run on the CatalystPay gateway, where available on your acquiring connection.

Talk to us about your retry set-up Tell us your vertical, your main markets and how you bill today, and we'll come back with a view on where your declines are costing you and what we'd change.

Get in touch with our team