Decline codes are signals, not failures

6 min read

Much of the conversation around payment optimization focuses on what happens after a failure: how often to retry, when to fall back, and which paths recover the most revenue. 

While working on retry and fallback strategies at scale, we realized that effective decisions depend less on the mechanics of retries and more on interpreting what the network is signalling before those decisions are made.

Every declined card payment already comes with guidance from the network. Not just a pass or fail response, but structured information that places limits on what should happen next. In practice, much of this data has been difficult to use. Networks expose different decline codes, issuers apply them inconsistently, and the same issue can surface in multiple ways depending on context. 

To make this manageable, teams often reduce declines to broad categories like soft and hard. That simplification helps with analysis, but it obscures signals that were designed to shape behavior, not just summarize outcomes.

So, the real challenge for merchants is not access to this data, but knowing how to interpret it appropriately and act on it safely.

What card networks actually send when a payment is declined

When a card payment is declined, networks return more than a simple failure response. 

Alongside the decline, Visa and Mastercard provide structured codes that distinguish between different failure scenarios such as insufficient funds, expired credentials, invalid transaction data, or issuer-imposed restrictions. The goal is not just to label a failure, but to describe the conditions under which it occurred.

What’s more, networks also expose additional fields beyond the decline reason itself. For instance, Visa groups certain declines into categories that constrain acceptable next steps, while Mastercard provides Merchant Advice Codes (MACs) that add context to guide merchants further.

At scale, merchants typically unify this information across networks and payment methods to reason about performance consistently. That abstraction works for monitoring, but it becomes limiting once retry decisions are automated. In those cases, the nuance embedded in raw network signals directly affects how failures should be handled.

Why there’s no such thing as a free retry

Decline and advice data exists because networks are responsible for the health of the entire payments ecosystem. Their role is to ensure that authorization traffic remains reliable and trusted.

When a payment fails, networks sit between competing incentives. Merchants want to recover revenue and improve approval rates. Issuers need to protect cardholders, manage risk, and avoid being overwhelmed with unnecessary authorization requests. Without constraints, repeated retries would quickly degrade issuer systems and erode the network’s performance.

By returning structured information with each failed transaction, networks communicate issuer intent and define boundaries around acceptable next actions. Some failures indicate temporary conditions, others signal missing or outdated data, and in some cases, codes explicitly discourage further attempts.

This guidance is reinforced through enforcement mechanisms. Networks apply rules, thresholds, and fees to discourage retry behaviour that falls outside expected patterns. Both Mastercard and Visa enforce retry limits through fees, charged when merchants exceed defined thresholds or ignore explicit network advice.

Examples of network retry fees

  • Mastercard charges Transaction Processing Excellence (TPA) fees if authorization attempts on a single card exceed 10 in 24 hours or 35 in 30 days, or if a merchant retries after a MAC 03 or MAC 21 decline.
  • Visa charges Excessive Retry Fees and a €1 Stop Payment Service fee per retry when retries continue after authorization has been revoked.

Learn more about decline codes, advised actions, and fees in our documentation.

These mechanisms are not punitive by design. They exist to protect issuers, merchants, and network performance at scale. 

From raw decline codes to safer retries

Understanding network intent is one thing, but operationalizing it consistently is another.

Enterprise merchants operate across multiple networks, issuers, and payment methods, each with evolving decline semantics and enforcement rules. Reasoning directly on raw network signals requires ongoing scheme expertise, continuous monitoring, and regular adjustments as thresholds and fee structures change. For most teams, that level of operational focus is difficult to sustain alongside day-to-day payments performance.

Unified decline reasons make it possible to monitor outcomes at scale. But safe retry decisions depend on preserving the nuance embedded in network-level signals.

That's why Primer standardizes decline data across payment methods while retaining the network context that matters for retry decisions. Primer also translates Network advice and constraints into clear guidance, allowing merchants to recover payments where appropriate and avoid retries that increase cost or risk, without managing this complexity themselves. 

Ready to see how Primer can help you? Get in touch.

Want to learn more KEY FACTS?

To download, please fill in your email

Stay up to date

Subscribe to get the freshest payment insights.