GH GambleHub

KPI circuito di pagamento: auth, capture, refund

TL; DR

Il circuito di pagamento è misurato come un vortice: «Attempt n'Auth n'Capture n'Settle/Refund». Le metriche chiave non sono solo Approval Rate, ma anche pura AR (dopo l'antifrode e 3DS), successo capture, tempo fino al prelievo/iscrizione, costo/FX, errori di idempotenza e qualità dei ritorni (TtR e rate). Vince chi tiene il AR↑, TtW↓, Cost/GGR↓, Disputes↓, senza rompere il profilo di rischio.


1) Dizionario di fasi ed eventi

Attempt - Tentativo di pagamento (avvio).
Auth - autorizzazione (banca/portafoglio/binari hanno confermato la possibilità di prelievo).
Capture è un prelievo effettivo (totale/parziale).
Settle - clearing e calcoli.
Rifund - Restituzione (totale/parziale), 'TtR = time to refund credit'.
Void - Annulla a capture (se supportata).
3DS/Step-up - Fricchia per l'autorizzazione.
Soft Decline/Hard Decline - guasti ripristinabili/inattivi.

💡 База измерений: `country, provider, method, action(deposit/payout/refund), device/os, ticket_size, risk_segment, kyc_tier, bin/asn`.

2) Gerarchia KPI (albero degli obiettivi)

Livello superiore

Gross Approval Rate (AR_gross) = Auth/Attempt

Net Approval Rate (AR_net) = Captured/Attempt

Cost/GGR = (Fees + FX + Ops)/GGR

TTW/TtC: Time-to-Wallet (conclusioni), TtC (capture) p95

Refund Health: Refund Rate, TtR p95, Refund Error Rate

Livello medio

3DS Challenge Share, Frictionless Share, Abandon on 3DS

Soft Decline Recovery Rate (Retrai/Smart Routing)

Partial Capture Share, Capture Latency

Refund to Source %, Duplicate/Idempotency Incidents

Livello inferiore (diagnostica)

Errori di codice (ISO/binari), p95 latitanza API, SLA webhoop, quota "Do Not Honor'," Insufficient Funds "," Suspected Fraud "," System Error ".


3) Formule (definizioni precise)

3. 1 Autorizzazione

`AR_gross = Auth_Approved / Auth_Attempted`

`AR_clean = Auth_Approved / (Auth_Attempted - Fraud_Preblocked - User_Abandon_3DS)`

`3DS_Challenge_Share = 3DS_Challenge / 3DS_Total`

`3DS_Frictionless_Share = 3DS_Frictionless / 3DS_Total`

`Abandon_on_3DS = 3DS_Started - 3DS_Completed`

I tagli sono obbligatori: «BIN x country», «provider x method», «device/os», «ticket _ size» (ad esempio, €50-200,> €200).

3. 2 Prelievi (capture)

`Capture_Success = Captured_Tx / Capture_Attempted_Tx`

`Net_Conversion = Captured_Tx / Auth_Attempted_Tx` (= AR_net)

`Partial_Capture_Share = Partial_Captures / Captured_Tx`

`Capture_Latency_p95 = p95(capture_timestamp - auth_timestamp)`

`Void_Rate = Voids / Auth_Approved`

3. 3 Costo e FX

`Cost_per_Tx = Fee_fixed + AmountFee_pct + FX_Spread`

`Cost/GGR = ΣCost / GGR`

`Net_Revenue = GGR - ΣCost - Fraud_Loss - Disputes_Cost`

3. 4 Restituzioni (refund)

`Refund_Rate = Refunded_Tx / Captured_Tx`

`Refund_Amount_Ratio = Refunded_Amount / Captured_Amount`

`TtR_p95 = p95(refund_credit_at - refund_initiated_at)`

`Refund_Error_Rate = Refund_Failed / Refund_Attempted`

`Refund_to_Source_% = Refund_to_Original_Method / Total_Refunds`

«Doppio _ Refund _ Incidents» è un contatore di collisioni idropotenti (deve = 0)


4) Obiettivi/punti di riferimento (personalizzabili)

AR _ gross: mappe 3DS2 - 82-92% (BIN/Paese), A2A - 90% + (iniziazione), voucher - 95% + (redeem).
Capture_Success: 98. 5% + (con webhoop vivi e retrai).
TtC p95: ≤ 5 minuti (mappe auto-capture), ≤ 90 secondi (instant A2A/RTP).
Refund Error: < 0. 3%; TtR p95 ≤ T + 1 banca. giorno (mappe), 60 secondi.
Refund _ to _ Source%: ≥ 95% (dove i binari sono supportati).
Idempotency Incidents: = 0; Webhook SLA: ≥ 99. 9%, p95 < 3 c.

(Non i «benchmark del mercato», ma i corridoi di destinazione pratici per gli SLO interni.)


5) Segmentazione e attribuzione

Considerate KPI in «country», «method _ group», «provider», «BIN», «device/os», «ticket _ size», «risk _ segment», «kyc _ tier», «affiliate», «new _ vs _ returning».

Cohort AR: AR per il primo pagamento (D0/D7/D30).
Route AR: AR su rotte «PSP_A→PSP_B failover».
Risk-aware AR: AR per segmenti di rischio (dopo step-up).
BIN-heatmap - Emettitori vulnerabili → regole separate per i retrai/3DS.


6) Modello dati (livello piatto per BI)

«event-flat» minimo:

payment_id, user_id, country, provider, method_code, action(deposit/refund),
attempt_ts, auth_status, auth_code, auth_ts,
three_ds(flow, started_ts, completed_ts, challenge_flag),
capture_status, capture_amount, capture_ts, partial_flag,
refund_status, refund_amount, refund_initiated_ts, refund_credit_ts,
fees_fixed, fees_pct, fx_spread, currency, amount,
risk_segment, kyc_tier, bin, asn, device_os, ticket_bucket

La chiave è «payment _ key» per la fase e «idempotency _ key» per il refund.


7) Tagli SQL (esempio)

7. 1 AR e Capture giornaliere

sql
WITH base AS (
SELECT
DATE_TRUNC('day', attempt_ts) d,
country, provider, method_code,
COUNT() FILTER (WHERE auth_status='ATTEMPTED') AS auth_attempted,
COUNT() FILTER (WHERE auth_status='APPROVED') AS auth_approved,
COUNT() FILTER (WHERE capture_status='CAPTURED') AS captured_tx
FROM payments_flat
WHERE action='deposit'
GROUP BY 1,2,3,4
)
SELECT d, country, provider, method_code,
auth_approved::decimal / NULLIF(auth_attempted,0) AS ar_gross,
captured_tx::decimal / NULLIF(auth_attempted,0)  AS ar_net
FROM base;

7. 2 Refund salute

sql
SELECT
DATE_TRUNC('day', refund_initiated_ts) d,
country, provider, method_code,
COUNT() FILTER (WHERE refund_status='ATTEMPTED') AS refund_attempted,
COUNT() FILTER (WHERE refund_status='SUCCESS')  AS refund_success,
PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (refund_credit_ts - refund_initiated_ts))) AS ttr_p95_sec
FROM payments_flat
WHERE action='refund'
GROUP BY 1,2,3,4;

7. 3 3DS fricchia

sql
SELECT country, provider,
COUNT() FILTER (WHERE three_ds.flow IS NOT NULL) AS three_ds_total,
COUNT() FILTER (WHERE three_ds.challenge_flag)  AS three_ds_challenge,
COUNT() FILTER (WHERE three_ds.flow='FRICTIONLESS') AS three_ds_frictionless
FROM payments_flat
WHERE action='deposit'
GROUP BY 1,2;

8) Dashboard (widget obbligatori)

1. Funnel: Attempt → Auth → Capture (in assoluto e in conversione).
2. AR heatmap: по `country×provider` и `BIN×country`.
3. 3DS Quality: Challenge/Frictionless/Abandon.
4. Capture Latency p50/p95 и Webhook SLA.
5. Refund Health: Refund Rate, TtR p95, Refund Error, Refund_to_Source %.
6. Cost/GGR per metodi e provider.
7. Alerts panel: codici top di guasto, degrado AR/latency.


9) SLO, alert e playbook

SLO/Alert (esempio):
  • ' > 3 p.p. alla mediana di 7 giornì ALERT P1 (controlla BIN/provider/ASN).
  • "Capture _ Success <98% (orologio)" o'Webhook p95> 5 c "→ ALERT P1 (retrai/incidente PSP).
  • 'TtR_p95> target', secondo i metodi istant → ALERT P2 (controlla coda/limiti).
  • `Refund_Error_Rate > 0. 5% 'ó Doppio _ Refund> 0' → ALERT P0 (congelamento dei refandi automatici, controllo manuale).
Playbook:
  • Degrado BIN: includere Equayer alternativo, aumentare la quota di 3DS-challenge per BIN, retrai con parametri ECI.
  • Soft Declins di sistema: routing avanzato PSP _ B, limitare la ripetizione a N, modificare il criterio 3DS.
  • Ritardi capture: forza-retrai, controllo firma webhoop, idempotenenza TTL aumentata.
  • Errori di rifund: abilita le chiavi idempotenti, limita i partial-refund paralleli, il QA manuale per i duplicati.

10) Gestione del rischio e della compliance in KPI

Segnalare AR _ clean dopo aver eliminato Fraud _ Preblocked'e'Abandon _ 3DS 'è il tuo AR operativo, non miscelarlo con l'effetto antifrode.
Refund _ to _ Source% è un KPI di regolazione chiave; le eccezioni vengono fissate comp-approved.
Dispute/Marceback Rate, aggancialo a captured _ amount, non a tentativi.


11) Errori frequenti

Riassume le diverse basi (attempt vs auth vs capture) in una sola quota.
Nessuna segmentazione dì ticket _ size "mostra false conclusioni su AR.
Non conta «User Abandon» su 3DS → «artificialmente basso» AR.
No 'idempotency _ key', su un refund sono state prese/perdite finanziarie.
Miscelare payout e refund in una sola metrica.


12) Foglio di controllo dell'implementazione

  • Schema di eventi coerente e definizioni KPI unificate.
  • Heatmap per BIN/paesi e routing per provider.
  • Dashboard 3DS-frizione e abandon.
  • SLA webhook, retrai, idampotenza (auth/capture/refund).
  • Report su Refund Health e Refund _ to _ Source%.
  • Alert di degrado AR, Capture _ Success, TtR, errori di rifund.
  • Panoramica R&O mensile: Cost/GGR, Dispute, spread FX, provider-SLA.

13) Riepilogo

Un tracciato di pagamento forte è un vortice trasparente con una base corretta per ciascuna quota, disciplina rigorosa degli eventi, segmentazione e playbook automatici. I KPI corretti trasformano l'infrastruttura dei pagamenti in una leva per la crescita: AR_net↑, TtC/TtR↓, Cost/GGR↓, Disputes↓, con sicurezza costante o migliorata.

Contact

Mettiti in contatto

Scrivici per qualsiasi domanda o richiesta di supporto.Siamo sempre pronti ad aiutarti!

Avvia integrazione

L’Email è obbligatoria. Telegram o WhatsApp — opzionali.

Il tuo nome opzionale
Email opzionale
Oggetto opzionale
Messaggio opzionale
Telegram opzionale
@
Se indichi Telegram — ti risponderemo anche lì, oltre che via Email.
WhatsApp opzionale
Formato: +prefisso internazionale e numero (ad es. +39XXXXXXXXX).

Cliccando sul pulsante, acconsenti al trattamento dei dati.