How Issuers Decide to Approve or Decline
- 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.
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 Type | Example |
|---|---|
| Transaction count | Max 5 transactions per hour |
| Daily spend limit | Max $2,000 per day |
| Geographic velocity | Can't transact in two distant cities within an hour |
| Decline count | Too many declines in short period triggers lockout |
| MCC velocity | Unusual 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.
| Code | Meaning | What's Really Happening |
|---|---|---|
| 05 | Do Not Honor | Could be anything: fraud suspicion, velocity, internal policy |
| 14 | Invalid Card Number | Card number doesn't exist or has a typo |
| 41 | Lost Card | Cardholder reported card lost |
| 43 | Stolen Card | Cardholder reported card stolen |
| 51 | Insufficient Funds | Not enough balance available |
| 54 | Expired Card | Card is past expiration date |
| 57 | Transaction Not Permitted | Card restricted for this MCC or transaction type |
| 61 | Exceeds Withdrawal Limit | Hit a daily or transaction limit |
| 65 | Exceeds Activity Count | Hit 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?
- Optimize auth strategy - Merchant-side improvements
- Understand decline codes - Know why you're declined
- Implement 3DS - Issuer authentication improves approval
Understanding why you're declined?
- Check issuer perspective - How issuers think
- Review AVS/CVV - Verification signals you control
- Fix retry strategy - Don't hammer declines
Related Topics
- Why Issuers Decline and Dispute - Understanding issuer constraints
- Authorization Optimization - Improving approval rates
- Decline Codes - Full decline code reference
- AVS & CVV - Verification signals you control
- 3D Secure - Shifting liability through authentication
- Velocity Rules - Rate limiting patterns
- Card Testing - Understanding retry abuse
- Network Programs - Fraud thresholds