What Visa Reason Code 11.2 Means
Visa reason code 11.2 falls under the Authorization category and is titled Declined Authorization. It is filed when a merchant completed and settled a transaction after the issuing bank explicitly returned a decline response during the authorization process. By processing the transaction anyway, the merchant violated the card network's core rules: you must honor the issuer's authorization decision.
This is a procedural violation, not a fraud dispute or consumer complaint. The cardholder may not have even contacted their bank — Visa's monitoring systems can detect that a settlement was processed without a corresponding approved authorization, triggering the chargeback automatically in some cases.
Under Visa rules, merchants are required to obtain a valid authorization approval before completing a transaction. A decline response — regardless of the reason code returned (insufficient funds, card restricted, do not honor) — means the transaction must be stopped. Processing after a decline is a per-se violation with essentially no winning defense when the decline on record is confirmed.
Cross-Network Equivalent Codes
| Network | Code | Title | Notes |
|---|---|---|---|
| Visa | 11.2 | Declined Authorization | This page |
| Visa | 11.3 | No Authorization | Transaction without any authorization attempt; related but distinct |
| Mastercard | 4834 | Point of Interaction Error | Covers some authorization error scenarios |
Common Trigger Scenarios
- Staff overriding a decline. A cashier or sales associate receives a decline but completes the sale anyway to avoid customer embarrassment or to retain the sale. This is the most frequent cause and is entirely preventable through staff training.
- Offline processing after a prior decline. Payment systems that queue transactions when connectivity is lost may process a transaction offline that was already declined while the connection was active. The offline record and the decline record conflict.
- Split-tender scenarios. In split payment situations, one card is declined and staff attempt to process the full amount on a second card without voiding the first attempt cleanly. The declined card still ends up in the settlement batch.
- Force-posting without approval. Some older POS systems allow "force" transactions where a numeric code is entered manually. If a decline was received and a false approval code is force-posted, this is both a 11.2 violation and potentially fraud.
- Automated retry violations. E-commerce platforms that automatically retry a payment after a decline — without cardholder action — can generate 11.2 disputes if the retry is not a legitimate re-attempt with fresh cardholder authorization.
Key Deadlines & Timeframes
| Milestone | Timeframe | Notes |
|---|---|---|
| Cardholder Filing Window | 75 days | From the transaction date |
| Merchant Response Window | 30 days | From acquirer receipt of chargeback notification |
| Pre-Arbitration | 30 days | If issuer rejects representment, merchant may escalate |
Evidence You Will Need
The only viable defense for an 11.2 dispute is proving that the authorization on record was actually approved — that the "decline" the issuer is citing was for a different authorization attempt and a separate, valid approval was obtained for the settled transaction.
- Authorization approval code matching the settled transaction — this is the core of any representment
- Full authorization request and response logs from your payment gateway or POS system showing the exact sequence of events
- Timestamp correlation between the authorization approval and the settlement record
- Acquirer authorization records confirming the approval code is valid and matches the settled amount
- Documentation of any legitimate retry scenario — if the first attempt was declined and a second was approved, evidence that the cardholder initiated the retry
How Merchants Lose This Dispute
- Processing after a confirmed decline. If your own gateway logs confirm a decline was received and the transaction was processed anyway, there is no representment path. Accept the chargeback and fix the operational issue.
- Force-posting with invalid approval codes. Entering a fake or recycled approval code on a force transaction creates additional liability exposure beyond the chargeback itself.
- Incomplete authorization logs. If you cannot produce a complete authorization trail, the issuer's decline record stands unchallenged. Incomplete records are nearly as bad as a confirmed decline.
- Conflating authorization codes across transactions. Attempting to use an approval code from one transaction to defend a different settled transaction is detectable and will result in arbitration loss with penalties.
Response Framework Overview
- Pull your full authorization log immediately. Retrieve every authorization attempt, response, and approval code associated with this transaction from your gateway.
- Determine if a valid approval exists. If the log shows a decline with no subsequent approval, the chargeback is correct. If it shows a decline followed by a new authorization that was approved, proceed to representment.
- Match amounts and timestamps exactly. The approval code in your representment must correspond to the exact settled amount and must predate the settlement batch.
- Submit the complete authorization trail. Do not summarize — provide the raw gateway log or processor report showing every request and response in sequence.
Prevention Tips
- Disable manual override capabilities on POS terminals. If staff cannot override a decline, they cannot create an 11.2 violation. Remove the ability or require dual authorization for any override.
- Audit your offline processing configuration. Any payment system that can queue and process transactions offline must be configured to check for prior declines before posting. Review this with your payment processor.
- Train staff that a decline is final. "Do not honor" and similar decline codes are not negotiable. Staff should never retry the same card, try a different amount, or process the sale by another means after a decline.
- Review retry logic in e-commerce platforms. Automated retry rules should only retry on soft decline codes (insufficient funds, temporary hold) and must require cardholder re-authorization rather than automatic resubmission.
Frequently Asked Questions
Is there any way to win a Visa 11.2 chargeback?
In most cases, no. Code 11.2 is filed when a transaction was completed after the authorization was explicitly declined. If your authorization records confirm a decline response was received, you have no procedural defense. The only viable path is proving the decline on record was for a different transaction and a subsequent authorization was approved — this requires exact matching of authorization codes, amounts, and timestamps.
How does a declined authorization happen in practice?
Common scenarios include POS systems configured to override declines in certain situations, staff who manually override declines to avoid losing a sale, split-tender situations where one payment method is declined and the transaction proceeds anyway, and payment systems that process offline when connectivity is lost without confirming a prior decline.
What is the filing window for a Visa 11.2 dispute?
The cardholder has 75 days from the transaction date to file a Visa 11.2 chargeback. Your acquirer will notify you and you typically have 30 days to respond, though your processor's internal deadline may be shorter.
Can a soft decline lead to an 11.2 chargeback?
A soft decline (where the issuer suggests retrying with additional verification) is different from a hard decline. If you retried without following the soft decline instructions and the transaction was declined on the retry, subsequent processing can still result in an 11.2 dispute. Always follow the decline response type exactly as received.