A/B test di script di pagamento

1) Perché testare gli script di pagamento

Aumenta l'approvazione (AR) e riduce i guasti (DR).
Take-rate (interchange/scheme/markup/fixed) e cost-per-approval.
Ridurre il rischio: meno charjbeek/frode con le stesse approvazioni.
Sostenibilità: scegliere il provider/3DS-strategia/routing per GEO/BIN/metodi specifici.

2) Progettazione esperimento

2. 1. Unit randomizzazione

User-level (consigliato) - Tutti i tentativi di un singolo utente entrano in un unico ramo senza «miscelare» 3DS/token.
BIN-level: quando il test riguarda il routing dell'emittente; Rischio di miscelazione cross-utente.
Order/Attempt-level: valido per piccoli esperimenti UI (ad esempio una copia di un errore), non desiderato per routing/3DS.

2. 2. Strazione (prima della randomizzazione)

Ratifica per: GEO giocatore, issuer country/BIN6, metodo di pagamento, canale (web/app), somma-segmento, rischio-score. Ciò riduce la dispersione e il rischio SRM.

2. 3. Cosa stiamo testando

Routing/cascata: PSP _ A vs PSP _ B, sticky BIN, limite-aware.
Politica 3DS: , 3DS per BIN/geo.
X flow: sequenza di passi, testi di errore/ripetizione.
Le opzioni di retrazione sono finestre e codici soft-decline.
Prezzo: provider con IC++ vs blended e impatto sul costo all-in.

3) Metriche: target, secondario, guardrail

3. 1. Principali

AR (Approval Rate) = approved/attempted.
Cost-per-Approval = (auth+decline fees)/approved.
Take-rate% (all-in) = fes/volume (in valuta di report).
3DS pass-rate; liability shift %.
Latency p95/p99 flow di pagamento.

3. 2. Metriche a rischio

Chargeback ratio (CBR), refund rate, fraud alerts/1000 trx.
FX slippage (bps) = effective vs reference FX.

3. 3. Condizioni di arresto

Caduta AR> Y bps o crescita CCR/Refunds sopra la soglia.
SRM (Sample Ratio Mismatch) è uno squilibrio del traffico contro le attese.
Spikes: latitanza, soft-decline surface, 3DS anataly.

4) Statistiche e potenza

4. 1. Dimensione campionamento (approssimazione per quota)

n_per_group ≈ 2 (Z_{1-α/2} + Z_{1-β})^2 p(1-p) / δ^2

dove «p» è l'AR di base, « » è l'uplift previsto in AR, il livello di rilevanza è il livello di valore, il valore è un errore di II tipo.

4. 2. Analisi sequenziale (arresto precoce)

Alpha-spending (O'Brien-Fleming/Pocock) - Fissiamo il grafico dei controlli e lo spendiamo per fase.
SPRT/Bayes è per le soluzioni online, ma fissa il protocollo.

4. 3. Varianza-redazione

CUPED: 'Y = Y - world( X - ansa_ X)', dove X è un cowboy pre-esplicativo (AR/DR/Risk-Score), Beh, è un coefficiente insidioso.
Valutazioni stratificate, errori di cluster robuster (cluster user/BIN).
Bootstrap per take-rate/metriche di valore (code pesanti).

4. 4. Test multivarianti e bandits

MAB (UCB/Thompson): quando è importante «imparare» al volo e non perdere il giro d'affari.
Per le metriche critiche complete (CCR, liability) - Preferire il classico A/B con guardrail.

5) Architettura piattaforma di sperimentazione

1. Assignment utility: hash determinato' (user _ id, experience _ id, salt) '→ bucket'.
2. Feature-flag/Rule-engine - Attiva il percorso/3DS/retrai nel ramo.
3. Eventi: tentativi/risultati (authorize/capture/refund/cb) .
4. Idampotenza: generico «idempotency _ key» a cascata.
5. DWH/Vetrine - States normalizzati, fees, FX, flag a rischio.
6. Monitoraggio: online-SLI (AR/3DS/latency), alert, assegno SRM.
7. Protocolli: ipotesi pre-registrer, criteri finali, data-frise.

6) Modello dati (minimo)

sql ref. experiments (
exp_id PK, name, hypothesis, owner, start_at, end_at,
unit -- USER      BIN      ORDER,
target_metric, guardrails JSONB, design JSONB, alpha NUMERIC, power NUMERIC, meta JSONB
);

ref. experiment_arms (
exp_id FK, arm_id, name, traffic_share NUMERIC, params JSONB, enabled BOOLEAN
);

assignments. buckets (
exp_id, user_id, assigned_arm, assigned_at, salt, hash_key, PRIMARY KEY (exp_id, user_id)
);

events. payments (
attempt_id PK, user_id, exp_id, arm_id,
provider, method, bin, iso2, risk_score,
status, decline_code, three_ds_used BOOLEAN, liability_shift BOOLEAN,
amount_minor BIGINT, currency, latency_ms INT,
authorized_at, captured_at, settled_at, meta JSONB
);

finance. fees (
attempt_id FK, interchange_amt NUMERIC, scheme_amt NUMERIC, markup_amt NUMERIC,
auth_amt NUMERIC, refund_amt NUMERIC, cb_amt NUMERIC, gateway_amt NUMERIC,
fx_slippage_amt NUMERIC, reporting_currency TEXT
);

risk. outcomes (
attempt_id FK, is_refund BOOLEAN, is_chargeback BOOLEAN, fraud_alert BOOLEAN
);

7) Modelli SQL

7. 1. assegno SRM (parte del traffico per mano)

sql
SELECT arm_id,
COUNT() AS n,
ROUND(100. 0 COUNT() / SUM(COUNT()) OVER (), 2) AS share_pct
FROM assignments. buckets
WHERE exp_id =:exp
GROUP BY 1;

7. 2. Metriche di base per mano

sql
WITH base AS (
SELECT e. arm_id,
COUNT()                  AS attempts,
COUNT() FILTER (WHERE status='APPROVED') AS approvals,
AVG(latency_ms)              AS latency_avg_ms,
AVG((three_ds_used)::int)         AS three_ds_share
FROM events. payments e
WHERE e. exp_id=:exp AND e. authorized_at BETWEEN:from AND:to
GROUP BY 1
),
cost AS (
SELECT e. arm_id,
SUM(f. interchange_amt + f. scheme_amt + f. markup_amt +
f. auth_amt + f. refund_amt + f. cb_amt + f. gateway_amt + f. fx_slippage_amt) AS fees_rep,
SUM(e. amount_minor)/100. 0 AS volume_rep
FROM events. payments e
JOIN finance. fees f USING (attempt_id)
WHERE e. exp_id=:exp AND e. settled_at BETWEEN:from AND:to
GROUP BY 1
)
SELECT b. arm_id,
approvals::numeric/NULLIF(attempts,0)             AS ar,
fees_rep/NULLIF(volume_rep,0)                 AS take_rate,
(SELECT COUNT() FROM risk. outcomes r
JOIN events. payments e2 USING (attempt_id)
WHERE e2. exp_id=:exp AND e2. arm_id=b. arm_id AND r. is_chargeback)=0
AS cb_zero_flag,
latency_avg_ms, three_ds_share
FROM base b LEFT JOIN cost c ON c. arm_id=b. arm_id;

7. 3. CUPED per AR (esempio)

sql
WITH pre AS (
SELECT user_id, AVG((status='APPROVED')::int) AS ar_pre
FROM events. payments
WHERE authorized_at <:pre_from_end
GROUP BY 1
),
cur AS (
SELECT e. user_id, e. arm_id, (e. status='APPROVED')::int AS ar_flag
FROM events. payments e
WHERE e. exp_id=:exp AND e. authorized_at BETWEEN:from AND:to
)
SELECT arm_id,
AVG(ar_flag - theta (ar_pre - mu_pre)) AS ar_cuped
FROM cur
LEFT JOIN pre USING (user_id),
LATERAL (SELECT AVG(ar_pre) AS mu_pre FROM pre) mu,
LATERAL (SELECT COVAR_SAMP(ar_flag, ar_pre)/VAR_SAMP(ar_pre) AS theta FROM cur LEFT JOIN pre USING(user_id)) t
GROUP BY arm_id;

7. 4. Convalida guardrails (esempio)

sql
SELECT arm_id,
100. 0 SUM(is_chargeback::int)::numeric / NULLIF(COUNT(),0) AS cbr_pct,
100. 0 SUM(is_refund::int)::numeric  / NULLIF(COUNT(),0) AS refund_pct
FROM risk. outcomes r
JOIN events. payments e USING (attempt_id)
WHERE e. exp_id=:exp AND e. settled_at BETWEEN:from AND:to
GROUP BY 1
HAVING 100. 0 SUM(is_chargeback::int)::numeric / NULLIF(COUNT(),0) >:cbr_threshold
OR 100. 0 SUM(is_refund::int)::numeric  / NULLIF(COUNT(),0) >:refund_threshold;

8) Processo di test (e-to-end)

1. Pre-registrazione: ipotesi, metriche, design, dimensioni, regole di arresto.
2. Prova SRM/AA per effetto «vuoto» (un paio di giorni).
3. Avvio: Assignment freeze, logica in rule-engine/ficcioflagi.
4. Monitoraggio online: AR/3DS/latency/health + guardrail.
5. Controlli di alpha-spending intermedi (se pianificati).
6. Finish e data-frise solo dopo la contabilità di funding/riserve/CB/refunds tardivi.
7. Analista: CUPED/stratificazione, sensibilità, eterogeneità GEO/BIN/metodo/canale.
8. Soluzione roll-out, roll-back, o test follow-up; aggiornamento delle regole/routing.
9. Documentazione e retrospettiva: lezioni, aggiornamento delle soglie/bilancia.

9) Anti-pattern e trappole

Peeking/Peeking-Vision senza protocollo per ottenere false vittorie.
Randomizzazione order-level nei test di routing → tra le mani.
Gioco con molteplicità (un sacco di metriche/tagli) senza correzione.
Costo parziale (dimenticato FX/riserva/refund fees) non valido.
L'assenza di un assegno SRM ha portato a conclusioni spostate.
I retrai non identificabili → doppie autorizzazioni/distorsioni AR.

10) Sicurezza, compliance ed etica

Same-method/return-to-source non deve essere interrotto dal test.
Sanzioni/licenze/GEO policy - fuori esperimenti.
RG/gioco responsabile: non compromettere i meccanismi di difesa per l'AR.
PCI/GDPR: token invece di PAN, riduzione dei dati personali, DPA/SOC2.

11) KPI dashbord esperimento

AR/DR, uplift e intervalli di confidenza per mani e strati chiave (GEO/BIN/metodo).
Cost-per-Approval, take-rate %, FX slippage (bps).
3DS pass/liability shift, soft-decline share.
Latency p95/p99, errori/timeout.
CB/Refunds (lag-aware), SRM, copertura del traffico, durata.

12) Best practices (breve)

1. Randomizzare a livello utente e strattonare.
2. Utilizzare lo scontrino e lo scontrino SRM; fissa il protocollo.
3. Contate il costo totale (fees + FX + reserve) e il costo-per-approval.
4. Utilizzare CUPED, cluster e bootstrap per le metriche di valore.
5. Per i rischi critici - classico A/B; bandits - per attività principalmente di prezzo/AR.
6. Tenere conto di funding/riserve/CB tardivi prima dell'output finale.
7. Documentate e versionate le regole; Fai post-mortem.

13) Assegno foglio di avvio

• Ipotesi, metriche, effetto, design, dimensione del campione, scadenza.
• Unit randomizzazione e strati, assignment-service, phicheflagi.
• Guardrail/soglie, SRM/AA-precheck, alert.
• Logi/eventi, idemotia, normalizzazione degli stati.
• Vetrine fees/FX/reserve; valuta di segnalazione.
• Piano di arresto (alpha-spending) e data-freeze.
• playbook roll-out/roll-back; documentazione dei risultati.

Riepilogo

I test A/B degli scenari di pagamento sono una disciplina di ingegneria e statistica: corretta randomizzazione e stratificazione, metriche complete di costo e rischio, guardia e SRM, analisi attenta (CUPED/cluster-robasting/analisi sequenziale) e infrastruttura «combattiva» (idemotia, telemetria, riconciliazione). Seguendo questa tecnica, si aumenta AR, si riduce all-in take-rate e non si paga per «false vittorie» con la crescita di charjbeek e rischi regolatori.