Skip to main content

Visa 11.2 - Declined Authorization

TL;DR
  • The issuer declined and you charged the card anyway. That's the whole code
  • Liability is yours. This is about as clear-cut as a chargeback gets
  • Dispute window is 120 days from the transaction date
  • You win only by proving the auth was actually approved. Bring the approval code and the full request and response log
  • Never re-run a declined card manually. Ask for another payment method instead

Transaction was processed even though the authorization request was declined by the issuer.

Overview​

A decline is the issuer telling you no. Charge the card anyway and you own the loss. There's no shared liability here.

When This Code Applies​

  • The auth response came back declined
  • You captured and settled the sale anyway
  • Someone at the counter overrode the decline
  • Your system captured without waiting for a response

Conditions for Valid Dispute​

Issuer Must Verify​

  1. An authorization request went out on the sale
  2. The issuer answered with a decline, not an approval
  3. You captured and settled it regardless
  4. The cardholder says they didn't approve it

Response Codes That Decline​

CodeMeaning
05Do not honor
14Invalid card number
51Insufficient funds
54Expired card
57Transaction not permitted
62Restricted card
63Security violation

Time Frames​

ScenarioDispute Window
Standard120 days from transaction date

Representment Options​

Your options are narrow and they all live in the auth logs. Either you have a real approval code for this sale or you don't.

1. Authorization Was Approved​

Evidence required:

  • Auth approval code
  • Full auth request/response log
  • Network transaction records
  • Timestamp matching

2. Different Transaction​

Evidence required:

  • Transaction IDs don't match
  • Declined and processed are separate transactions
  • Approved auth for processed transaction

3. Technical Error​

Evidence required:

  • System logs showing error
  • Processor confirmation of auth issue
  • Proof of good faith processing

Why This Happens​

Common Causes​

  1. Staff override - somebody said "just run it through"
  2. System timeout - the gateway assumed approval and captured
  3. Multiple attempts - the capture matched the wrong auth
  4. Manual entry - the sale bypassed the auth system
  5. Offline processing - the terminal stored and forwarded it

Prevention Strategies​

System Configuration​

  1. No decline override - your POS shouldn't let anyone force a sale
  2. Auth matching - check for a real approval code before capture
  3. Timeout handling - a timeout isn't an approval, so retry
  4. Online-only mode - turn off offline processing everywhere

Staff Training​

  1. Decline means no sale - no exceptions, not even for regulars
  2. Multiple attempts - every retry needs its own fresh auth
  3. Response codes - your team knows what the common ones mean
  4. Escalation path - everyone knows who to call on an edge case

Process Controls​

  1. Auth-capture matching - no approval code, no capture
  2. Decline logging - keep every decline, not just approvals
  3. Override audit - flag every forced sale for review
  4. Daily reconciliation - catch mismatches while they're still fixable

Win Rate Expectations​

Defense TypeExpected Win Rate
Proof of approval (with code)85-95%
Processing error (good faith)30-50%
Override was performedUnder 5%

Common Mistakes​

  1. Re-running a declined card - each attempt is its own violation
  2. Voice auth with no approval code - the call proves nothing
  3. Treating a system error as approval - it isn't one
  4. Bypassing for a "good customer" - you're still liable
  • 11.1 - Card Recovery Bulletin
  • 11.3 - No Authorization
  • 12.1 - Late Presentment

Next Steps​

Got this chargeback?

  1. Check auth logs → Did you get a valid approval code?
  2. Verify no "force" or override was used → Staff bypassed decline?
  3. If you processed after decline → Accept the chargeback (no defense)

Prevent future 11.2 chargebacks:

  1. Never charge a card after a decline response
  2. Train staff to accept "no" from the authorization system
  3. Use proper retry logic for soft declines only
  4. Review auth optimization

See Also​

Last updated on