Codici di risposta emittente e elaborazione
1) Perché capire i codici di risposta
Il codice di risposta dell'emittente definisce l'azione seguente: ripetere, ripetere con SCA/3DS, instradare altrimenti, non ripetere o scalare l'utente. La classificazione corretta dei codici aumenta l'Approval Rate (AR), riduce i costi e riduce la percentuale di transazioni controverse.
2) Tassonomia codice (visualizzazione generale)
I codici vengono visualizzati nelle autorizzazioni (auth) dall'equatore/PSP, vengono applicati su ISO 8583 e/o schemi di riferimento. Il iGaming è abbastanza pratico:- Successo
«00» - Approved (o «85» nelle singole implementazioni).
Decolli (condizioni temporanee/regolabili)
`51` — Insufficient funds.
«91» - Isuer or switch inoperative (non disponibile temporaneamente).
«96» - System malfunction (errore generale).
'62/65' - Restrizioni/Exceeds withdrawal frequency (limiti, soglie diurne).
«R1/R3» o codici di schema soft-decline SCA richiesto/3DS needed.
Decolli (motivi permanenti/definitivi per questo tentativo)
«05» - Do not onore (spesso effettivamente hard se non contrassegnato come 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/withdrawal/amount (errore di impostazione).
3) Matrice di soluzioni (regole di elaborazione)
Di seguito è riportata la matrice pratica «codice azione» per l'e-commerce (MCC 7995), dove 3DS2/SCA e COF/MIT sono critici.
4) Playbook di retrai e backoff
Idampotenza: ogni ripetizione deve avere idempotency-key e fissare la macchina di tentativo state.
4. 1 Modello di backoff condiviso (soft)
1 ° fallimento di ripetizione dopo 10-15 minuti
2 ° → tra 1-2 ore
3 ° → dopo 24 ore, poi fermata
Se soft-decline = SCA prescrired, 3DS2 non è in attesa.
4. 2 Ripetizioni per iscrizioni (MIT/COF)
Coda di retries MIT separata (non interferire con il CIT).
Backoff esponenziale + jitter (spaccatura accidentale) per evitare la «tempesta» alle 00:00.
Memorizza il riferimento al CIT iniziale (liability/PSD2).
5) Smart-routing codici/BIN/PSP
In caso dì 91/96 "per cluster BIN specifici, passare a PSP-B che ha l'AR superiore per questi emettitori.
Per '05' dopo 3DS - prova il network token + un altro PSP (a volte aiuta la sensibilità dell'emittente antifrode).
Supporta la tabella di stabilità: emittente x PSP x 3DS in modalità 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) Relazione con 3DS/SCA
Soft-decline a causa di SCA riconoscere in modo chiaro e non sprecare tentativi per i retrai «ciechi».
Su CIT eseguire EMV 3DS 2. x; MIT successivi - senza SCA per i collegamenti corretti.
Trasmettere il massimo del contesto (device, account age, velocity) - Aumenta la possibilità di frictionless.
7) pattern UX per migliorare la conversione
Stato comprensivo: «Insufficienza di fondi», «Banca temporaneamente inaccessibile», «Richiesta conferma in banca».
Pulsante Ripeti con timer (per '91/96').
Offerta alternativa: A2A/portafogli locali, importo parziale, altro PSP.
Le sottoscrizioni includono notifiche lievi con «aggiornare il metodo di pagamento» (link su card updater).
8) Discussioni e Charjbeck: cosa conta per i codici
3DS success (ECI/CAVV) riduce il rischio di frode/charjbeck e trasferisce la responsabilità.
I codici «59/41/43» sono ad alto rischio, preparate le prove e gli antifrode.
«05» senza 3DS viene spesso «nessuna autorizzazione del titolare»; Ripetere con 3DS riduce il rischio di display.
Condurre manufatti, , SCA, prova del servizio.
9) Componenti di lavorazione architettonici
Payments Orchestrator: regole, idimpotenza, state-machine, smart-routing, 3DS-ridefinizione.
Servizio BIN: paese/schema/tipo di mappa, politica di routing e limiti.
3DS Server versione 2. 1/2. 2/2. 3, web/mobile SDK, decoupled.
Tokenization: network tokens (VTS/MDES/и т. п.) + vault-fallback.
VAU/ABU/Updater Card.
Osservabilità: metriche AR/Loss reasons, alert per i picchi «05/91/96» nel taglio BIN/emettitori.
10) Metriche e alert
KPI:- AR per codice e per gruppo (soft/hard).
- Soft-decline è un retrai di successo% (totale e con 3DS).
- Quota «05» dopo 3DS (
- '91/96' su BIN/Paesi (SLO sulla disponibilità di emittenti/PSP).
- Tempo fino al successo della ripetizione (p50/p95).
- Cost per approved txn (considerando i tentativi ripetuti).
- Spike '91/96'> X% per 15 minuti nel cluster BIN.
- «05» crescita> Y% dopo successo 3DS.
- Successo dei retrai
11) Errori frequenti
Nessuna distinzione SCA-soft vs generico «05».
Ripetizioni multiple senza idepotenza, doppie in ledger.
Ignora i limiti geo e emettitori ('62/65').
Logifica PAN/CVV al posto dei token (violazione PCI).
«Un PSP per tutti i casi» senza routing per emittenti.
12) Assegno foglio di implementazione
- Il dizionario di codice mapping (ISO/schemi/PSP) → una singola tassonomia (soft/hard/SCA).
- Stato-macchina e idemotia per tentativi (chiavi, TTL).
- Criteri backoff e limiti di tentativo (separati per CIT/MIT).
- Flusso automatico in 3DS2 con SCA-soft; salvare gli artefatti.
- Smart-routing su BIN/paese/emittente e PSP.
- I decolli AR/decolli e gli alert per gli spiriti dei codici.
- Modelli UX per motivi di rifiuto e offerte alternative.
- Integrazione con card updater e network tokens.
- Playbook di display per gruppi di motivi.
- Criteri PCI: PAN-safe, occultamento, loging senza dati sensibili.
13) Riepilogo
I codici di risposta sono il linguaggio dell'emittente. Tradurlo in azioni chiare: dove ripetere dove andare direttamente a 3DS, dove cambiare PSP e dove fermarsi e offrire un'alternativa. Un forte orchestratore con corretta classificazione soft/hard, regole backoff, smart-routing e osservabilità migliora stabilmente la conversione e riduce il costo delle transazioni elaborate nel iGaming.