Routing di pagamenti e failover

Routing di pagamenti e failover

1) Perché è necessario

Conversione: la scelta corretta del canale/PSP su BIN/banca/geo/rischio aumenta l'Auth Rate di 5-15 p.
Costo: la scelta dinamica «successo x commissione» riduce l'effettiva rate di 10-30 bps.
Resilienza: isolamento dalle cadute PSP/3DS/banche; Continuare a ricevere e pagare in caso di guasti parziali.
Compilation/RG: implementazione flessibile di limiti, geo-vincoli, auto-esclusioni e regole di sanzione direttamente nel routing.

2) Architettura di destinazione (livelli)

1. Checkout Layer - Localizzazione valute/metodi, APM discovery, 3DS UX.
2. Payment Orchestrator (Rule Engine) - Routing, smart retry, idampotenza, circuito-breaker.
3. Risk/KYT Engine - device/behavior, sanzioni/RER, velocity, limiti RG, criteri 3DS.
4. Compliance Hub - KYC, provider di sanzioni, agevolazioni/limiti, verifiche.
5. Wallet & Ledgers - Soldi e gioco, bonus-passivo, multivaluta.
6. Recordation & Reporting - T + 0/T + 1 crocevia, reason codes, registri fiscali.
7. Osservabilità & Sicurezza - metriche/logs/trace, alert, RBAC, segmentazione PCI.
8. Data/ML è l'analisi del rischio, la previsione della conversione su banche/metodi.

3) Modello di dati e idampotenza

Payment Intent (PI) è un unico oggetto per il deposito/pagamento con campi: amount, currency, method, geo, BIN, risk _ score, rg _ limits, route _ history, idempotency _ key, status.
Idempotenza: ogni hop (PSP-A-PSP-B) viene eseguito con una singola idempotency _ key; Ripetere le chiamate non cambia lo stato del ledger.
Route Journal - Registro percorsi e risposte (PSP id, reason code, latency, 3DS flow, fee), è necessario per i modelli A/B e per la formazione dei modelli.

4) Algoritmo di instradamento (riferimento)

4. 1 Ricezione (Acquiring)

1. Pre-score: GEO, BIN/IIN, banca emittente, dispositivo, assegno, rischio-scansione, stato RG.
2. Filtri della compilazione: sanzioni/RER, geo-blocchi, età/auto-esclusione.
3. Regole di costo/successo: score = w1·AuthRate + w2· (-Fee) + w3· Health - penalties.
4. Criteri 3DS: TRA/whitelisting/step-up, scelta challenge vs frictionless.
5. Selezione percorso: PSP-A → → PSP-B → metodo alternativo (APM/open banking).
6. Smart Retry: cambio della modalità 3DS, MID, mcc/fallback, time-becoff su reason codes (05/51/62 ≠ 91/96).
7. Post-processing - Scrittura su Route Journal, aggiornamento della bilancia.

4. 2 Pagamenti (Payouts)

1. Priorità: velocità (instant/near-instant) per il costo della disponibilità.
2. KYT/AML/RG: velocity, pattern «abbracciato», limiti, sorgente di fondi, elenchi di esclusione.
3. Routing: card-to-card OCT/RTP/Faster Payments/SEPA Instant/Pix/UPI.
4. Failover: queued payouts quando la banca/PSP non è disponibile, coda drain periodico.
5. Confirmation: webhooks firmati per compensare le transazioni in caso di soluzione temporanea.

5) Failover-pattern

5. 1 Circuit-breaker

Locale (PSP) - Funziona quando si error_rate↑, si latency↑, spike in decolli (issuer-specific).
Globale (metodo): in caso di guasto di settore (ad esempio ACS/3DS in una grande banca).
Stati Closed → Open → Half-open; timeout e soglie vengono impostati in base ai segmenti GEO/BIN.

5. 2 Active-Active vs Active-Passive

Metodi PSP paralleli Active-Active bilanciamento secondo regole/costi; miglior RTO/RPO.
Active-Passive: risparmio su commissione/supporto, ma più lungo di RTO adatto per GEO/metodi secondari.

5. 3 Degradation Modes

Disattivare i metodi high-risk, tradurre parte del traffico in open banking/APM.
Obbligatorio 3DS challenge-all per «bruciatori» BIN-ov/banche.
Limite temporaneo per importo/frequenza (RG + rischio).

6) Lavorare con 3DS/SCA (dinamico)

Frictionless predefinito a basso rischio/piccoli assegni, challenge a high-risk.
Eccezioni PSD2: LVA, MOTO, MIT - in un orchestratore, non in un'applicazione.
Fallback - Durante il degrado ACS, aumentare il challenge rate o spostare temporaneamente il traffico in un metodo alternativo (open banking).
KPI: challenge rate, frictionless share, post-3DS approvals.

7) Integrazione con antifrode/KYT/RG

Prima di instradare, comporre (device, comportamento, proxy/VPN, rischio BIN, cronologia).
In instradamento, seleziona 3DS/canale/PSP per risk _ score.
Prima di pagare, KYT/velocity/anti-arb (rapido, multiple card, dispositivi collegati).
I limiti RG e l'auto-esclusione sono regole di stop «rigide» a livello di orchestrazione.

8) Osservabilità e dati

Metriche in tempo reale: auth _ rate, decline _ reason mix, p95 latency, PSP health, 3DS success, payout time, queue depth.
Alert: soglie di banche/metodi, pendenza con pagine di status esterne.
A/B & Lerning: aggiornamento della bilancia di routing basata su conversione/costo; gruppi di controllo privi di retrai per la calibrazione.

9) KPI e target

Auth Rate (mappe): EU 85-92%, US 80-88%, LATAM 70-85% (senza orchestrazione - bordo inferiore).
p95 latency auth API: < 3 c; webhooks: < 60 c.
Share of Instant Payouts ≥ il 70% degli assegni «leggeri».
Routing Efficiency (conversione del valore): + 5-10% alla baseline nel trimestre successivo al tuning.
Circuito-break RTO: <2 minuti per il cambio; RPO: 0 (idampotenza).
Chargeback rate: < 0. 5% count (dipende dal prodotto/GEO).

10) Playbook incidenti (scaffale)

10. 1 Decolli di massa per banca emittente

1. Conferma spike su BIN/issuer.
2. Aprire il circuito locale-breaker e ridistribuirlo in alt-PSP/metodo.
3. Aumentare il challenge rate per i BIN interessati, abilitare smart retry.
4. Comunicazione a canali statali; RCA con dati reason codes.

10. 2 Caduta 3DS/ACS

1. Un oggetto per la crescita timeouts/» soft decline».
2. Tradurre parte del traffico in open banking/APM; attivare «challenge-all» dove l'ACS è vivo.
3. Ridurre il rischio-assegno (limiti di importo/velocità), aumentare il monitoraggio.

10. 3 Instabilità PSP

1. L'health-alert dell'open breaker ha funzionato.
2. Migrazione a PSP/MID di riserva divieto di metodi «pesanti» ad alta latenza.
3. Ripristino tramite half-open con canarini (1-5% del traffico), seguito da gradation.

10. 4 Ritardi nei pagamenti

1. Trasferimento in queued payouts con priorità (VIP, limite di importo).
2. Spostamento della parte su binari alternativi (RTP/FPS/SEPA Instant/Pix).
3. Notifiche trasparenti ai giocatori; escalation manuali> X ore.

11) SLA e ancoraggi contrattuali (cosa richiedere da PSP)

Disponibile: ≥ 99. 95% di ricezione; p95 latency < 3 c; webhooks < 60 c.
Incidenti: TTA 15 minuti, strada di percorrenza (fallback MID/APM), RCA 5 giorni.
Dati: reason codes crudi, dettagli bancari, restituzione di token per 10 giorni dopo l'uscita.
Finanza: limitazione delle riserve/holdback, fees trasparenti (attivato 3DS/network tokens), cap per aumenti FX.
Sicurezza: PCI-AOC, firme webhooks, key rotation, SOC2/ISO 27001 (preferibilmente).

12) Pattern regionali

EC/UK: PSD2/SCA; carte + open banking (SEPA Instant/FPS). Forte orchestra 3DS, TRA e whitelisting.
USA: mappe + ACH; priorità dei pagamenti immediati (push-to-card, RTP). I tracciati Charjback sono obbligatori.
LATAM: Pix (BR), SPEI (MX), PSE (CO) APM-heavy; focus sul rischio device e il documento-KYC.
Turchia/CA traduzioni locali/portafogli; tracciato di sanzione/AML rafforzato, limiti di importo/velocità.
Asia/India: UPI/e-portafogli; Regole velocity rigorose Routing per banche emittenti.

13) Assegni di implementazione

Architettura/dati

• Payment Intent + idampotenza su tutti gli hop.
• Route Journal, crudi reason codes, webhooks firmati.
• Separazione di contanti/giochi transazioni compensative.

Routing/regole

• Rule-engine per GEO/BIN/issuer/rischio/costo.
• Smart retry con timeout e cambio 3DS/MID.
• Circuiti-breakers locali e globali; Restituzione canary.

Rischio/compilazione

• Integrazione risk/KYT/RG prima e dopo il routing.
• Sanzioni/RER, età/auto-esclusione - come filtri «rigidi».
• Limiti velocity/importi; Registro delle soluzioni.

Osservabilità/SLA

• Dashboard per Auth Rate, latency, decline mix, payout time.
• Alert a soglie; runbooks sugli incidenti.
• SLA nel contratto, QBR e multe per violazioni.

14) Pseudo-codice strategia (per il comando)

on PaymentRequest(PI):
ensureIdempotency(PI.key)
risk = RiskEngine.score(PI)
if not ComplianceHub.pass(PI, risk): reject()

candidates = RouteCatalog.filter(PI.geo, PI.method, PI.bin, risk)
for route in rankBy(Score(AuthRate, Fee, Health, Risk), candidates):
res = PSP.call(route, PI, policy=ThreeDS.select(risk))
log(RouteJournal, route, res)
if res.approved: return approve(PI)
if isRetryable(res.reason): continue with SmartRetryAdjustments()
return decline(PI)

15) Economia e A/B-ottimizzazione

Считайте effective rate = (Fees + 3DS + FX + chargeback cost − interchange rebates) / Approved Volume.
A/B: minimo 10k transazioni/ramo, 2-4 settimane; fissa per banche/metodi.
Ottimizzare il peso del AuthRate vs Fee per GEO/stagionalità; controllate la distorsione nei binari costosi, ma di conversione.

16) Cosa è importante ricordare

Orchestratore + regole + dati - il cuore della stabilità dei pagamenti e della conversione.
Idampotenza/Payment Intent escludono la doppia cancellazione e semplificano la failover.
Il circuito-breakers e il canary recovery consentono una rapida stabilizzazione senza «altalena».
Le SLA contrattuali e i dati trasparenti di PSP non sono un'opzione, ma un requisito.
I binari regionali (open banking, RTP, Pix/UPI) sono spesso migliori delle carte in velocità/costo - tenere conto nel routing.