A Mastercard decline is not just a yes/no signal. In many cases, the issuer also sends a Merchant Advice Code (MAC) that tells you what to do next: retry later, stop retrying, update payment credentials, or wait a specific number of days.
If you ignore MACs and keep re-attempting the same card-not-present (CNP) authorization, you can pay network penalties under Mastercard's Transaction Processing Excellence (TPE) programs. The goal of this guide is simple: help you treat MACs as hard decisioning inputs so you recover more revenue with fewer retries and fewer fees.
A Mastercard Merchant Advice Code (MAC) is guidance returned with a declined authorization that indicates the next best action for the merchant. In practice, MACs are most relevant for subscription billing, merchant-initiated transactions (MITs), and other CNP scenarios where retry logic is automated.
Think of it like this:
If your processor surfaces MACs, you should treat them as first-class data in your decline handling, similar to how you treat AVS/CVV responses or 3DS outcomes.
Most merchants do not "turn on" MACs. They are typically included in the issuer response and then passed through the network and acquirer to your gateway or processor. The problem is that different platforms expose them differently:
Action step: ask your processor or gateway support for a sample decline payload that includes "Merchant Advice Code" or "MAC" and confirm the exact JSON field name and set of possible values.
MAC 01 is your cue to treat the decline as a credentials problem, not a customer intent problem. Before you retry, run account updater (if you are enrolled) and verify that your gateway will actually use the refreshed credentials on the next attempt.
If you are using network tokens (Apple Pay, Google Pay, card-on-file tokens, etc.), make sure you understand whether the update is happening on the PAN record, the token record, or both. A surprising number of retry loops happen because the merchant updates the customer record in their app, but the processor is still attempting the original credential.
MAC 02 is the classic "soft decline" instruction. The issuer is telling you the transaction cannot be approved right now, but that a later attempt could succeed.
Spacing matters. If you retry immediately, you are effectively testing the same issuer decision again with no new information. Better patterns are time-based:
For subscription businesses, the right schedule depends on your dunning window. A five-day window cannot support a ten-day wait. In those cases, treat MAC 02 as "retry later" but still stay inside your cancellation policy.
When you receive MAC 03 (do not try again) or MAC 21 (payment cancellation), the safest interpretation is that the issuer does not want you to keep attempting that transaction.
Your best next steps are usually non-technical:
Below is a practical "decision table" you can use to implement safe retry logic. Do not treat this as a complete list for every region or program, but it covers the codes you are most likely to see in recurring billing.
| MAC | Meaning (plain English) | What to do next |
|---|---|---|
| 01 | New account information may be available | Run account updater before retrying. |
| 02 | Cannot approve now, try later | Retry later using a capped schedule. |
| 03 | Do not try again | Stop retries. Trigger cardholder outreach. |
| 04 | Token requirements not fulfilled for this token type | Fix tokenization and credential storage, then request a new payment method. |
| 21 | Payment cancellation | Stop retries immediately. |
Implementation tip: treat MAC 03 and MAC 21 as "hard stops" for automated retries unless your processor gives you a compliant exception path.
It is safest to retry when the issuer is telling you the decline is temporary. MAC 02 is the common example.
A good default pattern:
If you want a payment-ops style checklist, here is a simple starting point:
Retries are not free for the network. Every attempt consumes issuer authorization capacity and contributes to fraud monitoring signals. Large retry storms, especially during card testing attacks, can degrade authorization performance for everyone.
From the merchant side, too many retries also create operational side effects:
Mastercard's Transaction Processing Excellence (TPE) programs are designed to discourage behavior that harms the network, such as excessive authorization retries after declines.
Two common penalty categories merchants run into:
1) **Excessive authorization attempts**
If your system keeps hammering the same PAN with repeated declines (common during a BIN attack or poorly designed retry loop), you can trigger excessive attempt fees and additional compliance attention.
2) **Retrying after "do not retry" signals**
Mastercard introduced a Merchant Advice Code fee within TPE for certain CNP reattempt patterns. One practical interpretation: when the network tells you "do not retry," your retry engine must comply.
The operational point is not the fee amount. It is that your retry logic can become a direct line item on your monthly statement.
Your processor statement may list something like "Merchant Advice Code fee" or a TPE program fee.
According to Moneris' published network fee updates, Mastercard introduced a Merchant Advice Code (MAC) fee as part of TPE in May 2022, applying to certain CNP transactions after a reattempt following specific "do not retry" responses, using a 30-day lookback window.
Moneris also notes that Mastercard updated the MAC fee amounts over time and ties the fee to non-compliant retry behavior in its TPE initiatives.
Practical takeaway: if you retry after a decline that is effectively telling you to stop (MAC 03/21 style outcomes), you should assume you can pay a fee and also degrade your approval rate.
This is intentionally conservative and designed to avoid rapid-fire reattempts:
Stop early if you receive a stop MAC, if the customer cancels, or if your fraud tools flag the pattern.
If you run a higher-ticket subscription, you may also require a manual review before the final attempt.
Here is a conservative, compliance-first policy you can adapt.
Store, at minimum: network, decline code, MAC, attempt number, time since last attempt, and whether 3DS was used.
Networks increasingly want you to include data from the original authorization response in follow-on attempts.
For example, Worldpay documents a Mastercard requirement (effective October 23, 2026) to send the Transaction Link Identifier (TLID) from the original cardholder-initiated response in subsequent merchant-initiated authorization requests.
Even if your system is not sending TLID directly, this trend matters: the network wants retries to be traceable and well-behaved.
Sometimes. If the issuer is declining because it wants more confidence that the cardholder is present, step-up authentication can improve authorization outcomes.
For ecommerce, see our guide to 3DS2 here: 3D Secure 2 Merchant Guide.
3DS is not a workaround for MAC 03/21 style "do not retry" outcomes. It is a tool for the right bucket of soft declines.
If you are not sure whether you are getting MACs today, send these questions to your processor or gateway:
Documenting the answers now saves time if your account later gets flagged for excessive retries.
If you only implement one change this quarter, implement MAC parsing plus a hard stop for do-not-retry signals.
No. Some processors do not expose MACs in their API payloads, or they only expose them for specific products. Ask support for a sample response that includes MAC and confirm where it appears in your integration.
No. MAC is guidance after a decline. MCC is your merchant category classification used for risk and interchange.
As a default, no. Treat these as stop signals for automated retries. If you believe the decline is incorrect, move to customer outreach or manual review instead of automated reattempts.
There is no single safe universal number because it depends on your processor, your decline mix, and Mastercard monitoring programs. A conservative approach is to keep retries low, spaced out, and always compliant with the MAC guidance.
Often yes. Many processors pass network fees through as line items, including TPE-related fees.
You can apply for a merchant account through Easy Pay Direct or another processor that fits your model. Other options worth a look:
Internal links used in this article:
Sources: