Cascata a livello di provider

1) Cos'è la cascata e perché è nel iGaming

• AR↑/ DR↓ - Aggirare gli emettitori «capricciosi», scegliere il miglior PSP per un particolare metodo BIN/geo.
• Costo ↓: IC + +/markup più basso sulla parte del cestino, minimizzazione della fia fix su micro-ticket.
• Resilienza: failover in caso di incidenti, degrado 3DS, calo dei corridoi di pagamento.
• La compliance è il rispetto delle geopolitiche, delle sanzioni, dei divieti locali e delle licenze.

2) Cartelli di cascata

1. Sequenziale (sequential)

PSP _ A → (soft-decline/guasto tecnico) → PSP _ B → PSP _ C.
Utilizzare la finestra ristretta dei retrai per evitare di creare doppie o rischi di colli multipli.

2. Parallelo (split-traffic/multi-arm)

Distribuzione del flusso (%/regole) tra più PSP per il benchmark, l'apprendimento delle regole e la riduzione dei guasti correlati.

3. Sticky BIN / Sticky GEO

Memorizza il «migliore» PSP per un determinato intervallo BIN/emittente/geo (la cache delle soluzioni con TTL).

4. Method-aware / Feature-aware

Provider diversi per mappe, A2A, portafogli, metodi locali; tenere conto delle specifiche 3DS-rails, DCC/FX, tornizzazione.

5. Limit-aware / SLA-aware

Conteggio dei limiti di provider, riserve, SLA incidenti, cut-off e fondi-ritardi.

3) Motore decisivo (rule-engine) - Segnali di ingresso

Segni di carta: BIN/IIN, brand, debit/credit, commerciale/premium, country of issuer.
Geo e compagine: paese del giocatore (IP/GPS/SIM/KYC), sanzioni, licenze.
Transazione: importo (minor units), valuta, canale (web/app), rischio-scansione.
Storia dei provider: AR/DR secondo BIN/geo/metodo negli ultimi 15-60 min, quota soft-decline, 3DS-pass-rate.
Costo: IC + +/markup/fix, FX-spread, rolling reserve%.
Limitazioni: provider rate-limit, mainenance/incidenti, gap di traffico diurno.

Esci: elenco prioritario di percorsi '[(PSP, MID, sollire _ 3DS, retry _ window _ ms, max _ attemps)]'.

4) Retrai, idemotia e sicurezza

Idempotency-key per tentare (user _ id + order _ id + nonce), comune a tutti i provider a cascata.
Retrai solo su soft-decline (rete/3DS/timeout/insufficient funds), mai con codici «rigidi» (stolen, do not onore di nuovo, ecc.).
Anti-dooling: lo statò AUTHORIZED '/' CAPTURED 'chiude la cascata; Tutti gli altri rami vengono cancellati.
Finestre: 1 ° retro 2-5 secondi, bilancio totale 15-30 secondi, considerando UX.
Politica 3DS: può essere step-up sul secondo/terzo ramo se il primo è caduto senza 3DS.

5) 3DS, liability shift и AR

«Frictionless »/« challenge» dipende dal rischio e dal supporto PSP (delegated auth, TRA, whitelisting).
In «rigidi» geo/emettitori - obbligatorio 3DS su parte del cestino.
Tenere traccia della liability maiusc attraverso i provider, dove è più frequente, trasferire i BIN's rischiosi.

6) Costo: IC++, blended, fisse e FX

Per ogni PSP, leggere effettivo take-rate = interchange + scheme + markup + fixed + FX-slippage.

• `Score = w1AR_live + w2(−Cost_bps) + w3(SLA_health) + w4(FX_quality) +...`
• Micro-ticket - Il peso della fia fix superiore è preferito ai provider a bassa fix.
• Tenere conto separatamente della riserva% e della funding T + N - influisce sulla cache flow.

7) Incidenti, cut-off e routing

Health-fid - Stati PSP/corridoi (auth API, 3DS ACS, payout rails).
Auto-failover: rerute istantanea in caso di caduta di AR/health al di sotto della soglia.
Cut-off-aware - Evitare partial-capture su PSP con T + N scomodo prima di chiudere il settlement.
Throttling - Per evitare che il provider accada, diffondere il traffico.

8) Modello di dati minimo

sql
-- Providers and MIDs
CREATE TABLE ref. providers (
provider TEXT PRIMARY KEY, model TEXT, pricing_model TEXT, fx_policy TEXT, reserve_pct NUMERIC, meta JSONB
);
CREATE TABLE ref. mids (
mid TEXT PRIMARY KEY, provider TEXT REFERENCES ref. providers, country TEXT, method TEXT, descriptor TEXT, meta JSONB
);

-- Cascade Rules/Profiles
CREATE TABLE ref. cascade_profiles (
profile_id BIGSERIAL PRIMARY KEY, name TEXT, version TEXT, enabled BOOLEAN, meta JSONB
);
CREATE TABLE ref. cascade_rules (
rule_id BIGSERIAL PRIMARY KEY, profile_id BIGINT REFERENCES ref. cascade_profiles,
geo TEXT, bin_from TEXT, bin_to TEXT, method TEXT,
provider TEXT, mid TEXT, require_3ds BOOLEAN, priority INT,
retry_on_soft JSONB, max_attempts INT, ttl_seconds INT, enabled BOOLEAN, meta JSONB
);

-- Online Provider Performance Metrics (Sliding Window)
CREATE TABLE live. provider_stats_15m (
provider TEXT, method TEXT, geo TEXT, bin6 TEXT,
approvals INT, declines INT, soft_declines INT, three_ds_pass INT,
avg_latency_ms INT, updated_at TIMESTAMP
);

-- Transactions with idempotency and selected route
CREATE TABLE payments. auth_attempts (
attempt_id BIGSERIAL PRIMARY KEY, idempotency_key TEXT, step INT,
provider TEXT, mid TEXT, require_3ds BOOLEAN, status TEXT, decline_code TEXT,
amount_minor BIGINT, currency TEXT, bin TEXT, geo TEXT,
started_at TIMESTAMP, finished_at TIMESTAMP, meta JSONB
);

9) Modelli di analisi SQL

9. 1. Classifica dei provider online (AR e soft-decline share)

sql
SELECT provider, method, geo,
SUM(approvals) AS appr,
SUM(declines) AS decl,
ROUND(100. 0 SUM(approvals) / NULLIF(SUM(approvals+declines),0), 2) AS ar_pct,
ROUND(100. 0 SUM(soft_declines) / NULLIF(SUM(declines),0), 2) AS soft_share_pct
FROM live. provider_stats_15m
WHERE updated_at > now() - INTERVAL '20 minutes'
GROUP BY 1,2,3
ORDER BY ar_pct DESC, soft_share_pct DESC;

9. 2. Effetto cascata sugli ordini (step-conversion)

sql
WITH s AS (
SELECT idempotency_key,
MAX(step) AS steps,
BOOL_OR(status='APPROVED') AS approved
FROM payments. auth_attempts
WHERE started_at BETWEEN:from AND:to
GROUP BY 1
)
SELECT steps,
COUNT() AS orders,
100. 0 SUM(approved::int) / NULLIF(COUNT(),0) AS conv_pct
FROM s
GROUP BY 1
ORDER BY 1;

9. 3. Sticky BIN è il miglior provider di BIN6

sql
SELECT bin6,
provider,
ROUND(100. 0 SUM(approved)::NUMERIC / NULLIF(COUNT(),0), 2) AS ar_pct
FROM (
SELECT LEFT(bin,6) AS bin6, provider, (status='APPROVED') AS approved
FROM payments. auth_attempts
WHERE started_at BETWEEN:from AND:to
) t
GROUP BY 1,2
QUALIFY ROW_NUMBER() OVER (PARTITION BY bin6 ORDER BY ar_pct DESC) = 1;

9. 4. Costo del provider (all-in take-rate)

sql
SELECT provider,
SUM(amount_reporting) AS volume_rep,
SUM(interchange_amt + scheme_amt + markup_amt + auth_amt + refund_amt + cb_amt + gateway_amt + fx_spread_amt) AS fees_rep,
100. 0 SUM(interchange_amt + scheme_amt + markup_amt + auth_amt + refund_amt + cb_amt + gateway_amt + fx_spread_amt)
/ NULLIF(SUM(amount_reporting),0) AS take_rate_pct
FROM finance. settlement_fees
JOIN dw. transactions_flat USING (provider)
WHERE period_start_at >=:from AND period_end_at <:to
GROUP BY 1
ORDER BY take_rate_pct;

10) KPI e dashboard

AR/DR sui provider e BIN/geo/metodo (finestre online 15/60 min e day-to-date).
Step-conversion: percentuale di approvazioni sul ramo 1, 2, 3.
Take-Rate% e FX-slippage per provider/MID.
3DS pass-rate e quota di liability maiusc.
Health/SLA: latency, timeouts, errato rate, incidenti.
Reserve & Funding: riserva% e T + N hit-rate per provider.

11) Alerti e soglie

Routing Degradation: la caduta AR del provider selezionato> Y bps in 10-30 minuti.
Soft-decline surge: la crescita della quota soft-decline consente un ulteriore ramo di cascata.
3DS Anataly: caduta 3DS pass-rate> X% su un particolare emittente/cluster BIN.
Take-Rate Spike: crescita all-in valore> soglia bps.
Health Down: SLA breach (latency/error) — авто-failover.
Policy Draft - Tentativi senza idempotency _ key/senza profilo cascata - P1.

12) Test AB e formazione delle regole

Multi-arm bandit o split-traffic fisso per le nuove rotte.
Explorer/Explorer: parte del traffico da tenere per «training» sticky BIN.
Orizzonti di valutazione online (15/60 min) per gli incidenti e settimana/mese per il costo.
Guardrails: minimo AR/max take-rate per fermare l'esperimento.

13) Complaence e casi «estremi»

Rispetto delle sanzioni/licenze/geoblock: alcuni provider non possono servire i singoli paesi/metodi.
Same-method/Return-to-source - La cascata non deve rompere il criterio di restituzione.
Tokenization/PCI - Un unico token tra PSP (network tokens/vault).
Marcebacks: logica il ramo attraverso cui è passata la capture per i display.

14) Best practices (breve)

1. Ritrae solo soft-decline, con un'unica idempotency _ key.
2. Tieni viva la telemetria AR/3DS/soft-decline e health provider.
3. Costruisci la funzione prezzo percorso (AR vs cost vs SLA vs FX).
4. Utilizzare sticky BIN e test AB; versionare i profili a cascata.
5. Essere cut-off-aware: non fruire partiale-capture alla fine della giornata.
6. Possiede playbooks failover: calo PSP/ACS/corridoio di pagamento.
7. Separare i dati e la responsabilità: chi tiene il PAN, chi gestisce i display.
8. Mantieni i provider riserve-ledger: rilasci e prelievi.

15) Assegno-foglio di implementazione

• Scheda provider/MID, price (IC + +/blended), regole FX, riserve, T + N.
• Rule-engine - Profili, regole, soft-codes, criteri 3DS, limiti.
• Router: idampotenza, retrai, timeout, sticky BIN cache.
• Telemetria: metriche live AR/DR/3DS/latency/health; Gli alert.
• Gestione degli incidenti e playbook failover.
• ETL per fees/FX/reserve; vetrine take-rate e step-conversion.
• Procedure di test AB e guardrail.
• Documentazione: vincoli complessi, rimborsi same-method, responsabilità.

Riepilogo

Lo stunting a livello di provider non è «provare un altro PSP», ma una disciplina: metriche viventi, rule-engine intelligenti, idempotia rigorosa, tattiche 3DS corrette, contabilità dei costi/FX/riserve e scenari failover pronti. Questa architettura aumenta AR, riduce all-in take-rate e rende il circuito di pagamento resistente a guasti e restrizioni regolatorie.