Site Title

When investigating a spike in card declines, the first instinct for many payments analysts and product managers is to check the decline response codes. Terms like “Insufficient Funds”, “Do Not Honor”, and “Transaction Refused” are now part of the shared language across the payments industry. Even senior leaders often ask, “Which response code is spiking?”

Is that a wrong approach? Not entirely—but relying on response codes too heavily can be misleading.

To understand why, let’s trace how a decline message travels back through the system:

When a card issuer declines a transaction, the response is passed back through multiple hops:
Issuer → Card Network (Visa/Mastercard) → Processor → Payment Service Provider (PSP) → Merchant.

All of this happens in milliseconds, but to optimize speed and reduce complexity, each player in the chain may normalize or simplify the decline response. The level of detail a merchant receives ultimately depends on each player’s philosophy and technical capability.

Years ago, I spoke with a major U.S. authorizer. I asked why 70% of their declines were labeled as “51 – Insufficient Funds.” Their answer surprised me:

They advised us to start consuming network response codes, which are passed directly from the card networks and tend to be more granular. But that required PSPs to modify their systems to expose those codes.

Today, most leading PSPs in the U.S. (and likely worldwide) support network response codes. If you’re a merchant not receiving them, ask your PSP.

Let’s now look at some scenarios where response codes can mislead your analysis:

1. Processor Switch: If your PSP switches processors (e.g., from one with generic codes to one with granular codes), it might look like certain decline types are suddenly spiking—when in fact, nothing changed except visibility.
2. Carding or Bot Attacks: Issuers often mask real decline reasons during fraud attempts to avoid helping attackers fine-tune their bots.
3. Aggressive Retry Strategies: If your dunning partner triggers multiple retries per day, the same decline reason may flood your logs—without providing any new insight.
4. New PSP or Processor Integration: Any onboarding of a new provider may change the way responses are logged and categorized.
5. Market Expansion: Launching in a new country may introduce new issuer behaviors that you haven’t previously encountered.

These are just a few examples. Feel free to comment if you’ve seen other situations that impacted decline response patterns.

So, if decline response codes aren’t always reliable, what should you look at to begin a proper decline analysis?

I’ll share my experience in the next blog post. Stay tuned!