Skip to main content

How Issuers Decide to Approve or Decline

TL;DR
  • The issuer decides in milliseconds, on very little data
  • Rules, ML models and velocity checks, same as your own fraud stack
  • Key signals: cardholder history, transaction patterns, your merchant reputation
  • "Do Not Honor" usually means fraud suspicion. Nobody will confirm that
  • You can lift approvals with cleaner traffic, richer data and 3DS

The issuer approves or declines in under 100 milliseconds. It runs rules, ML models and velocity checks to get there. It sees almost none of your fraud signals. So it leans on cardholder history, transaction patterns and your reputation as a merchant. This page covers what those signals are, why good transactions still get declined, and which levers you hold.

Related: The Issuer Perspective

This page is the technical decisioning process. For the wider view of what issuers see, read Why Issuers Decline and Dispute. For disputes specifically, read Why Chargebacks Favor Cardholders.

What Happens During Authorization

From outside it's one step. Inside the issuer it's a whole decision tree, and it runs in under 100 milliseconds.

The fraud check is where merchant transactions get caught.

Signals Issuers Use

Issuers weigh a mix of factors. Roughly these.

Cardholder History

  • Typical spending patterns (amounts, frequencies, categories)
  • Geographic usage patterns (where has this card been used before?)
  • Previous fraud claims filed by this cardholder
  • Account age and status

Transaction Characteristics

  • Amount (unusually large for this cardholder?)
  • Merchant category (high-risk MCC?)
  • Time of day (consistent with cardholder behavior?)
  • Card-present vs. card-not-present

Merchant Signals

  • Merchant reputation (historical fraud and chargeback rates)
  • AVS result (address match?)
  • CVV result (code match?)
  • 3DS authentication result

Device and Location

  • IP geolocation (does it match cardholder's typical locations?)
  • Distance from last transaction (impossible travel?)
  • Device fingerprint (if available through enhanced data sharing)

Rules vs. Models

Issuers mix rules with machine learning, same as you do.

Rules-based checks:

  • Hard limits: "Decline if card has been used more than 10 times in 1 hour"
  • Category restrictions: "Decline if merchant is in blocked MCC list"
  • Geographic rules: "Decline if transaction is in country where cardholder has never been"

ML models:

  • Pattern recognition across the cardholder's full history
  • Comparison to similar cardholders' behavior
  • Real-time scoring (typically 0-1000 scale)

Visa Advanced Authorization and Mastercard Decision Intelligence score at the network level. They read hundreds of signals and hand back a number in under a millisecond. Issuers fold that score into their own decision.

Velocity Limits

Velocity checks matter most to issuers. They're the brake on a card that just got stolen.

Velocity TypeExample
Transaction countMax 5 transactions per hour
Daily spend limitMax $2,000 per day
Geographic velocityCan't transact in two distant cities within an hour
Decline countToo many declines in short period triggers lockout
MCC velocityUnusual concentration in high-risk categories

See "card_velocity_exceeded" and the cardholder has hit one of these. It isn't negotiable. They'll have to call their bank.

Decline Reason Codes

Issuers send back a response code. Most of them hide behind the generic ones.

CodeMeaningWhat's Really Happening
05Do Not HonorCould be anything: fraud suspicion, velocity, internal policy
14Invalid Card NumberCard number doesn't exist or has a typo
41Lost CardCardholder reported card lost
43Stolen CardCardholder reported card stolen
51Insufficient FundsNot enough balance available
54Expired CardCard is past expiration date
57Transaction Not PermittedCard restricted for this MCC or transaction type
61Exceeds Withdrawal LimitHit a daily or transaction limit
65Exceeds Activity CountHit a velocity limit

Code 05 is a huge share of all declines. It's a catch-all. The issuer reaches for it when it doesn't want to name the reason. Usually the reason is fraud suspicion, and naming it would tip off the fraudster.

Important: 05 can be a soft decline or a hard one, depending on the issuer. Treat it carefully. Two or three retries is reasonable. A retry loop makes it worse.

Soft vs. Hard Declines

Not all declines are equal.

Soft declines are temporary and can be retried:

  • Insufficient funds (customer might add money)
  • Velocity exceeded (limit might reset)
  • Issuer system unavailable (try again later)

Hard declines are permanent and shouldn't be retried:

  • Invalid card number
  • Lost or stolen card
  • Account closed
  • Fraud confirmed

Retrying a hard decline wastes money. You're still paying the network fee. Do it often enough and you trip fraud flags of your own.

Retry guidance: two or three attempts, no more. Space them out over days or billing cycles, not seconds.

Improving Authorization Rates

You do have levers here.

Send Better Data

More context, better decision.

  • Full billing address for AVS
  • CVV for every first-time transaction
  • Merchant name that matches your billing descriptor
  • Level 2/3 data for B2B transactions

Use Enhanced Data Sharing

Some networks, processors and acquirers run data-sharing programs. Your risk scores, model output and 3DS results go straight to the issuer. An issuer that can see somebody trusted already vetted the transaction approves more of them.

VAA and Mastercard Decision Intelligence are the network versions. Some acquirers and PSPs run their own issuer-linking programs.

Authenticate When Appropriate

3D Secure shifts liability. It also lifts approval rates. An issuer that authenticated the cardholder itself has no reason to doubt the transaction.

Keep Credentials Updated

Account updater refreshes expired and reissued card numbers for you. Network tokens help too. A token survives a reissue. A raw PAN doesn't.

Don't Hammer Declines

Aggressive retry logic looks like fraud. Issuers track retry patterns. Ignore their first answer often enough and they start declining you on sight.

What You Can't Control

Some of this isn't yours to fix.

  • Cardholder's account status (frozen, closed, restricted)
  • Cardholder's available balance
  • Issuer's global risk policies
  • International restrictions

When one of these declines you, the customer has to call their bank. Or pay another way.


Next Steps

Improving authorization rates?

  1. Optimize auth strategy - Merchant-side improvements
  2. Understand decline codes - Know why you're declined
  3. Implement 3DS - Issuer authentication improves approval

Understanding why you're declined?

  1. Check issuer perspective - How issuers think
  2. Review AVS/CVV - Verification signals you control
  3. Fix retry strategy - Don't hammer declines