Card authorization is a real-time “yes/no” decision from an issuing bank. When you understand how it works and how to interpret issuer rejection codes, you stop guessing and start fixing your approval rates.

This guide covers:

• What card authorization is (and what it isn’t)
• The end-to-end authorization flow
• Common authorization failure reasons
• A complete reference table of issuer rejection codes (Visa/Mastercard style)
• Practical recommendations to improve authorization rates

---

What Is Card Authorization?

Card authorization is the process where the issuing bank decides whether to approve or decline a card payment request in real time.

When a customer clicks “Pay,” money does not instantly move. Instead, the system asks the issuer:

“Is this card valid, and should this transaction be approved right now?”

The issuer responds with:

• ✅ Approved (usually with an authorization code)
• ❌ Declined (with an issuer rejection/response code)
• ⚠️ Authentication required (for example 3D Secure)

---

How Card Authorization Works (Step-by-Step)

Typical flow:

1. Customer enters card details and confirms payment
2. Merchant sends request to Payment Gateway
3. Gateway forwards to Acquirer (merchant’s bank / acquiring processor)
4. Acquirer routes through Card Network (Visa/Mastercard/etc.)
5. Card Network sends authorization request to Issuing Bank
6. Issuer evaluates:
   • Available balance/limit
   • Card status (active/expired/lost/stolen)
   • Risk/fraud scoring
   • Transaction context (amount, country, merchant type)
7. Issuer returns approve/decline + a response code
8. Response travels back to merchant

Typical time: 2–5 seconds.

---

What Is an Authorization Code?

An authorization code is a unique identifier generated by the issuing bank when the transaction is approved.

It indicates:

• The issuer approved the transaction at that moment
• Funds/credit were reserved (depending on product rules)
• The merchant can proceed to capture/settlement later

Important: Authorization ≠ Settlement
Authorization reserves funds. Settlement is when funds actually transfer.

---

What Is a Card Authorization Failure?

A card authorization failure occurs when the issuer declines the authorization request.

This is one of the biggest conversion killers for card-based businesses, especially in:

• Cross-border payments
• High-risk verticals
• First-time customer purchases
• Subscription renewals

---

Common Card Authorization Failure Reasons (Human-Readable)

These are the failure categories merchants see most often.

1) Insufficient Funds

Customer doesn’t have enough balance/available credit.

Merchant action: Suggest alternate card/method, optionally allow smaller amount or split tender.

2) Generic Issuer Refusal (“Do Not Honor”)

Issuer declines without giving a helpful reason.

Merchant action: Avoid repeated retries. Ask customer to use another method or contact their bank.

3) Invalid Card Details

Wrong card number, expiry, CVV.

Merchant action: Improve checkout validation and error messages.

4) Suspected Fraud / Risk Decline

Issuer risk engine flags the transaction.

Merchant action: Do not brute-force retries. Consider authentication (3DS), clean data signals, and fraud tooling.

5) Card Restrictions

Card can’t be used online, cross-border, or for a certain type of merchant.

Merchant action: Offer local methods, local acquiring/routing, and clear messaging.

6) Authentication Required (3D Secure)

Issuer demands step-up authentication; transaction fails if not completed.

Merchant action: Support 3DS 2.x and trigger it strategically.

---

Complete Issuer Rejection Codes (Visa & Mastercard Style)

Below is a practical breakdown of common issuer rejection codes, what they mean, and how merchants should respond.

Notes:

• Issuers sometimes reuse “generic” codes (like 05) for many internal reasons.
• Your PSP/acquirer may also map raw codes into “refusal reasons.”

---

Code Reference (Short Explanation + Recommendation)

01 — Refer to issuer

Meaning: Issuer requests cardholder to contact their bank.
Recommendation: Don’t retry immediately. Ask customer to contact issuer or use another method.

02 — Refer to issuer (special condition)

Meaning: Refer with special issuer conditions (often higher risk).
Recommendation: Avoid retries. Suggest alternate payment method.

03 — Invalid merchant

Meaning: Merchant or terminal not recognized/allowed by issuer.
Recommendation: Verify MID/MCC/acquiring configuration and routing.

04 — Pick up card (no fraud)

Meaning: Issuer wants card retained (revoked/invalid).
Recommendation: Do not retry. Ask for another card.

05 — Do not honor

Meaning: Generic decline without specific reason.
Recommendation: Avoid aggressive retries. Offer alternate method; suggest contacting issuer.

06 — Error

Meaning: General issuer/system error.
Recommendation: Retry once after short delay; if persistent, route fallback methods.

07 — Pick up card (fraud)

Meaning: Suspected fraud.
Recommendation: Do not retry. Flag internally and suggest alternate payment.

10 — Partial approval

Meaning: Approved for partial amount only.
Recommendation: Support split tender or ask customer to pay remaining balance another way.

12 — Invalid transaction

Meaning: Transaction type not supported/incorrect.
Recommendation: Check flags: e-commerce vs MOTO, recurring vs one-time, etc.

13 — Invalid amount

Meaning: Amount format/value invalid.
Recommendation: Validate amount rules (min/max, decimals, currency support).

14 — Invalid account number

Meaning: Card number invalid.
Recommendation: Prompt re-entry; confirm BIN/card number format.

15 — No such issuer

Meaning: BIN/issuer not found or routing issue.
Recommendation: Validate BIN tables and card network routing.

19 — Re-enter transaction

Meaning: Input/processing issue.
Recommendation: Retry once after short delay.

21 — No action taken

Meaning: Issuer unable/unwilling to process request.
Recommendation: Retry once; if repeated, advise alternate payment.

25 — Unable to locate record in file

Meaning: Transaction reference not found (common in adjustments/reversals).
Recommendation: Verify transaction identifiers and timing before resubmission.

28 — File temporarily not available for update or inquiry

Meaning: Issuer database temporarily unavailable.
Recommendation: Retry after short delay (soft decline).

41 — Lost card, pick up

Meaning: Card reported lost.
Recommendation: Do not retry. Request another card.

43 — Stolen card, pick up

Meaning: Card reported stolen.
Recommendation: Do not retry. Flag as high risk.

51 — Insufficient funds

Meaning: Not enough available balance/credit.
Recommendation: Ask for another method or smaller amount.

52 — No checking account

Meaning: Account type not available (often legacy/debit-specific).
Recommendation: Ask customer to use a different card.

53 — No savings account

Meaning: Savings account not available (legacy/debit-specific).
Recommendation: Ask customer to use a different card.

54 — Expired card

Meaning: Expiry date passed.
Recommendation: Ask customer to update card details.

55 — Incorrect PIN

Meaning: PIN incorrect (more common in card-present).
Recommendation: Allow limited retries; if e-commerce, ensure correct auth method.

57 — Transaction not permitted—card

Meaning: Card is restricted for this transaction type/channel.
Recommendation: Offer alternate method; consider local options.

58 — Transaction not permitted—terminal

Meaning: Merchant/terminal restricted for this transaction type.
Recommendation: Review MCC/terminal settings and acquirer configuration.

59 — Suspected fraud

Meaning: Issuer risk decline.
Recommendation: Don’t brute-force retry. Consider 3DS step-up and better data signals.

61 — Exceeds approval amount limit

Meaning: Transaction exceeds issuer’s per-transaction limit.
Recommendation: Suggest smaller amount or split payment.

62 — Invalid/restricted service code

Meaning: Card usage restricted (region/channel).
Recommendation: Offer local payment methods; consider domestic routing.

63 — Security violation

Meaning: Security checks failed (data mismatch/format).
Recommendation: Validate fields, reduce retries, ensure correct CVV/AVS handling.

64 — Transaction does not fulfill AML requirement

Meaning: Blocked by AML/compliance rule.
Recommendation: Do not retry. Trigger compliance review if needed.

65 — Exceeds withdrawal limit

Meaning: Daily usage/withdrawal limit exceeded (common on debit).
Recommendation: Ask customer to retry later or use another method.

70 — PIN data required

Meaning: PIN required but missing.
Recommendation: Use appropriate authentication method for channel (PIN for present, 3DS for e-commerce).

75 — Allowable number of PIN entry tries exceeded

Meaning: PIN locked due to too many attempts.
Recommendation: Stop retries; customer must reset with issuer.

76 — Unsolicited reversal

Meaning: Issuer reversed transaction unexpectedly.
Recommendation: Check reversal/settlement logs; avoid duplicate capture.

78 — Blocked, first use

Meaning: Card needs activation / first-use verification.
Recommendation: Ask customer to activate card via issuer.

79 — Already reversed

Meaning: Transaction has already been reversed.
Recommendation: Do not resubmit; reconcile state.

82 — Negative CAM, dCVV, iCVV, or CVV results

Meaning: CVV/security validation failed.
Recommendation: Prompt customer to re-enter CVV; avoid repeated attempts.

85 — No reason to decline

Meaning: Informational code typically treated as approval/no decline reason.
Recommendation: No action required (confirm your PSP mapping).

86 — Cannot verify PIN

Meaning: PIN verification unavailable.
Recommendation: Retry once; fallback authentication if possible.

91 — Issuer or switch unavailable

Meaning: Issuer system down/unreachable.
Recommendation: Soft decline. Retry after delay; consider routing fallback.

92 — Unable to route transaction

Meaning: Network routing issue.
Recommendation: Retry; if possible, route via alternate path/acquirer.

93 — Transaction can’t be completed—violation of law

Meaning: Regulatory/compliance block.
Recommendation: Do not retry. Compliance escalation required.

96 — System error

Meaning: Processing system malfunction.
Recommendation: Retry once after delay; if persists, fallback methods.

97 — Invalid CVV

Meaning: CVV incorrect/invalid.
Recommendation: Ask customer to re-check CVV. Limit retries.

9G — Blocked by cardholder / contact cardholder

Meaning: Cardholder has blocked the transaction or issuer requires contact.
Recommendation: Ask customer to contact issuer; suggest alternate method.

---

Hard Declines vs Soft Declines (How to Retry Without Making It Worse)

Hard declines: don’t retry
Examples: 04, 07, 41, 43, 54, 57 (often), 93

Soft declines: retry may succeed
Examples: 06, 19, 28, 91, 92, 96, and “authentication required” scenarios

Rule of thumb: Retry only when something changes (time delay, authentication, corrected data), not because you’re bored.

---

How to Improve Card Authorization Rate (Merchant Playbook)

Improving authorization rate is usually a mix of better data, smarter routing, and fewer self-inflicted wounds.

1) Improve Transaction Data Quality

• Clean billing data (name/address where relevant)
• Correct MCC and merchant descriptor
• Accurate currency and amount formatting
• Correct transaction flags (recurring, CIT/MIT, MOTO/e-commerce)

2) Use Smart Retry Logic

• Retry soft declines only
• Add spacing (seconds/minutes), not instant spam
• Stop after limited attempts
• Never retry hard declines

3) Add Authentication Strategically (3D Secure)

• Trigger 3DS when risk is high or issuer indicates need
• Optimize for frictionless where possible
• Don’t force 3DS for everything unless regulation requires it

4) Consider Local Acquiring / Domestic Routing

Especially for cross-border and SEA markets:

• Domestic routing increases issuer trust
• Reduces cross-border decline risk
• Can improve approval rates materially

5) Monitor Declines Like a Product Metric

Track:

• Authorization rate by issuer and BIN
• Declines by code (05, 51, 91 are the big ones)
• Cross-border vs domestic performance
• Retry success rate
• Fraud false positives

---

How Pivot Exposes Issuer Rejection Codes Transparently

Understanding issuer rejection codes is only useful if your payment system actually exposes them.

Many payment providers mask raw issuer responses behind generic messages like:

“Payment failed”
“Transaction declined”

That is operationally useless.

With Pivot, the raw issuer response code is available directly in the charge object under the card charge structure.

Full API reference

Through this object, merchants can access:

• Raw issuer response code
• Refusal reason
• Recommendation on what to do as customer & merchant
• Transaction status
• Authentication details (if applicable)

This level of transparency allows you to:

• Distinguish hard vs soft declines accurately
• Build intelligent retry logic
• Analyze approval rates per issuer and BIN
• Detect routing or configuration issues
• Reduce revenue loss caused by blind retries

Instead of reacting to generic “declined” responses, your product and fraud teams can act based on real issuer signals.

---

Ready to Improve Your Card Authorization Rate?

If your business depends on card payments, authorization rate is not a backend metric.

It is revenue.

With Pivot, you get:

• Access to raw issuer response codes
• Detailed decline analytics
• Smart retry logic support
• Flexible 3D Secure orchestration
• Domestic and cross-border routing optimization
• Full transparency via structured API objects

Stop losing revenue to declines you don’t analyze.

https://YOUR_DOMAIN.com/contact

Or speak with our team to discuss how to optimize your card authorization performance.

---

Ready to Improve Your Card Authorization Rate?

If your business depends on card payments, authorization rate is not a backend metric.

It is revenue.

With Pivot, you get:

• Access to raw issuer response codes
• Detailed decline analytics
• Flexible 3D Secure orchestration
• Domestic and cross-border routing optimization
• Full transparency via structured API objects

Stop losing revenue to declines you don’t analyze.

👉 Learn more or start onboarding:

Or speak with our team to discuss how to optimize your card authorization performance.