Issuer response codes and processing
1) Why understand answer codes
The issuer's response code determines the following action: repeat, repeat with SCA/3DS, route differently, do not repeat or escalate to the user. Correct code classification increases Approval Rate (AR), reduces cost, and reduces the share of disputed transactions.
2) Code taxonomy (overview)
Codes come in authorization (auth) from the acquirer/PSP, map to ISO 8583 and/or circuit directories. iGaming has enough practical grouping:- Success
'00 '- Approved (or' 85'in separate implementations).
Soft declines
`51` — Insufficient funds.
'91 '- Issuer or switch inoperative.
'96 '- System malfunction (general error).
'62/65 '- Restrictions/Exceeds within frequency.
'R1/R3'or soft-decline scheme codes by SCA required/3DS needed.
Hard declines
'05 '- Do not honor (often actually hard, if not marked SCA-soft).
`14` — Invalid card number.
`54` — Expired card.
`57` — Transaction not permitted to cardholder.
`59` — Suspected fraud.
`43/41` — Stolen/Lost card.
'03/04/13' - Invalid merchant/within/amount (parameter error).
3) Decision matrix (processing rules)
Below is a practical code → action matrix for e-commerce (MCC 7995), where 3DS2/SCA and COF/MIT are critical.
4) Retray playbooks and backoff
Idempotency: Each retry must have an idempotency-key and fix the state machine of attempts.
4. 1 General template backoff (soft)
1st failure → repeat in 10-15 min
2nd → in 1-2 hours
3rd → after 24h, then stop
If soft-decline = SCA required → immediately 3DS2 without waiting.
4. 2 Repeats for subscriptions (MIT/COF)
Separate queue of MIT retries (do not interfere with CIT).
Exponential backoff + jitter (random spread) to avoid a "storm" at 00:00.
Store binding to initial CIT (liability/PSD2).
5) Smart-routing by code/BIN/PSP
If '91/96' on specific BIN clusters, switch to PSP-B, which has a higher AR for these issuers.
For '05' after 3DS - try network token + another PSP (sometimes issuer anti-fraud sensitivity helps).
Maintain a stability table: issuer × PSP × 3DS mode → AR/latency.
IF code in {91,96} AND bin_country == "X" THEN route = PSP_B
ELSE IF code == SCA_REQUIRED THEN enforce_3DS = true
ELSE IF code == 05 AND was_3DS == false THEN retry_with_3DS
ELSE IF code in HARD THEN stop_and_prompt_alternative6) Relationship with 3DS/SCA
Soft-decline because of SCA, recognize unambiguously and do not waste attempts on "blind" retrays.
At the CIT, run EMV 3DS 2. x; subsequent MITs - no SCA with correct references.
Transfer maximum context (device, account age, velocity) - increases the chance of frictionless.
7) UX patterns to boost conversion
Clear statuses: "Insufficient funds," "Bank temporarily unavailable," "Bank confirmation required."
Redo button with timer (for '91/96').
Alternative offer: A2A/local wallets, partial amount, other PSP.
In subscriptions - soft notifications with "update payment method" (link to card updater).
8) Disputes and chargebacks: what matters by code
3DS success (ECI/CAVV) reduces the risk of fraud/chargeback and transfers responsibility.
Codes' 59/41/43 'are high-risk: prepare evidence and anti-fraud logs.
'05'without 3DS often goes into "no holder authorization"; repeating with 3DS reduces the risk of dispute.
Keep artifacts: dsTransID/ECI/CAVV, SCA logs, proof of service.
9) Architectural processing components
Payments Orchestrator: rules, idempotency, state machine, smart-routing, 3DS reinitiation.
BIN service: country/scheme/card type → routing and limits policy.
3DS Server: versions 2. 1/2. 2/2. 3, web/mobile SDK, decoupled.
Tokenization: network tokens (VTS/MDES/и т. п.) + vault-fallback.
Card Updater: VAU/ABU/acquiring updates.
Observability: AR/Loss reasons metrics, alerts on '05/91/96' bursts in BIN/issuers section.
10) Metrics and alerts
KPI:- AR by code and by group (soft/hard).
- Soft-decline → successful retray% (common with 3DS).
- Share '05' after 3DS (abnormally high → look at routing/anti-fraud).
- '91/96'by BIN/country (SLO by issuer availability/PSP).
- Time to successful repeat (p50/p95).
- Cost per approved txn (considering retries).
- Spike '91/96'> X% in 15 min in BIN cluster.
- '05'growth> Y% after successful 3DS.
- Retray success
11) Frequent errors
No distinction SCA-soft vs generic '05'.
Multiple repetitions without idempotency → duplicates in ledger.
Ignoring geo-limits and issuer limits ('62/65').
PAN/CVV logging instead of tokens (PCI violation).
"One PSP for all cases" without issuer routing.
12) Implementation checklist
- Code mapping dictionary (ISO/schemas/PSP) → single taxonomy (soft/hard/SCA).
- State machine and idempotency for attempts (keys, TTL).
- Backoff policies and retry limits (separate for CIT/MIT).
- Auto- 3DS2 with SCA-soft; preservation of artifacts.
- Smart-routing by BIN/country/issuer and PSP health.
- Dashboards AR/declines and alerts by code adhesions.
- UX templates for reasons of refusal and suggestions of alternatives.
- Integration with card updater and network tokens.
- Dispute playbooks by cause group.
- PCI policies: PAN-safe, masking, logging without sensitive data.
13) Summary
Answer codes are the issuer's "language." Translate it into understandable actions: where to repeat, where to go to 3DS right away, where to switch PSP, and where to stop and offer an alternative. A strong orchestrator with the correct soft/hard classification, backoff rules, smart routing and observability consistently increases conversion and reduces the cost of processed transactions in iGaming.