Merchant Advice Codes in Card Payments: How to Tell When a Declined Transaction Should Be Retried

Introduction

In card payments, a decline response is not just a failure message. In many cases, it carries structured guidance from the network or issuer about what should happen next.

Both Visa and Mastercard provide signals that help determine whether a declined authorization should be retried, corrected, or not attempted again. Visa does this through decline response categories, while Mastercard provides Merchant Advice Codes (MACs) that explicitly describe recommended next actions.

Visa explicitly documents this in its Updates to Rules for Declined Transaction Resubmission and Use of Authorization Response Codes.

For payment providers and merchants responsible for approval performance, these signals are operational inputs. Retry decisions that ignore them risk unnecessary authorization traffic, avoidable costs, and reduced effectiveness of recovery strategies.

What Merchant Advice Codes actually do

Mastercard Merchant Advice Codes (MACs) are additional response values returned alongside some authorization declines. They provide instruction on how to proceed after a failed transaction.

According to PayPal Braintree’s Merchant Advice Codes documentation, MACs indicate whether the merchant should retry, update information, or stop attempting the transaction.

Typical categories include:

• New or updated information required
• Retry later
• Do not retry
• Retry after a specific time interval

Checkout.com further documents that some MACs include explicit retry timing guidance in its Recommendation Codes guide, such as retrying after a defined number of hours or days.

The implication is direct: MACs are not descriptive metadata. They are prescriptive signals that should influence retry behavior.

Visa decline categories solve the same decision problem

Visa approaches this through decline response categorization rather than separate advice codes.

In its official rules update on declined transaction handling, Visa states that authorization response codes are grouped into categories and that merchants should manage reattempts based on those categories.

Implementation guidance from CardPointe, in Visa Decline Rules and Responses, operationalizes these categories as:

1. Issuer will never approve - do not retry
2. Issuer cannot approve at this time - retry later
3. Issuer cannot approve based on provided details - correct before retrying
4. Processor- or context-specific handling

CardPointe also notes that retry behavior is constrained, including limits on excessive reattempts within a defined time window.

The key point is that Visa’s model embeds retry eligibility directly into response interpretation rather than through a separate code system.

Why this matters for authorization optimization

Many payment systems still rely on generic retry policies - for example, retrying all soft declines on a fixed schedule. These approaches are simple to implement but do not account for issuer or network guidance.

Visa explicitly requires that reattempts be managed according to response categories in its authorization response code rules update.
Similarly, Mastercard MACs define when retries should occur or be avoided, as described in Braintree’s MAC documentation and Checkout.com’s recommendation codes guide.

Ignoring these signals can lead to:

• Retrying transactions that are unlikely to succeed
• Missing optimal retry timing for recoverable declines
• Generating unnecessary authorization traffic
• Increased exposure to scheme-level constraints or fees

In practice, decline handling becomes a classification problem: identifying whether the failure is permanent, temporary, or correctable.

MAC timing granularity is often underutilized

One underused aspect of Mastercard MACs is timing precision.

Checkout.com documentation shows that certain MAC values correspond to specific retry intervals in its recommendation codes documentation.

For example, retrying after one hour, one day, or multiple days depending on the issuer signal.

This matters particularly for insufficient-funds and velocity-related declines, where timing directly affects the probability of success. A retry clustered too early or too late can materially reduce recovery rates.

A retry system that ignores timing signals effectively compresses distinct issuer instructions into a single strategy.

Visa constraints on reattempt behavior

Visa does not only classify declines - it also constrains how reattempts should be handled.

According to CardPointe’s Visa decline handling guidance:

• Category 1 declines should not be retried
• Category 2 and 3 declines may be retried under controlled conditions
• Excessive reattempts within a 30-day window may trigger additional fees

These constraints mean that retry logic is not purely a conversion optimization problem. It is also a compliance and cost-management problem.

What a well-designed retry policy should evaluate

A robust retry strategy starts with interpreting the signal, not defining retry frequency.

At minimum, a system should evaluate:

1. Network or processor guidance

Visa categories and Mastercard MACs should be primary inputs when present.

2. Underlying decline condition

Different failure types (e.g., insufficient funds vs closed account) require different handling paths.

3. Availability of new information

Some declines require updated credentials or additional authentication rather than resubmission of the same request.

4. Timing and execution layer

Certain recoverable transactions may benefit from immediate handling within the authorization lifecycle, while others are better suited for delayed retries.

Where real-time recovery infrastructure fits

In systems designed for advanced recovery, network signals are inputs into a broader decisioning framework rather than final outcomes.

Better operates as real-time payment recovery infrastructure that integrates alongside existing processors and payment systems, as described on its solution page.

Its role is to evaluate declined transactions and determine whether recovery is possible within the authorization lifecycle, rather than relying solely on scheduled retries.

Within such systems, merchant advice codes and decline categories contribute to - but do not fully determine - the recovery decision. Some transactions should be stopped, some corrected, some retried later, and some resolved immediately based on additional data and timing analysis.

Operational impact

Proper use of issuer and network signals has measurable implications:

• Reduced unnecessary authorization attempts
• Lower exposure to excessive retry fees
• Improved alignment with issuer expectations
• More efficient allocation of retry attempts to recoverable transactions

Over time, this typically results in cleaner authorization traffic and a more stable foundation for improving approval rates.

Technical takeaway

Merchant advice codes and Visa decline categories are not auxiliary fields. They are structured guidance on how to handle a declined transaction.

Visa explicitly instructs merchants to manage reattempts based on response categories in its authorization response code rules.
Mastercard MACs provide actionable next steps, including whether and when to retry, as detailed in Merchant Advice Codes documentation and recommendation codes guidance.

Not all declines should be retried.

Effective systems interpret the signal first, then determine whether to stop, correct, delay, or attempt recovery through more advanced infrastructure.

‍