Dashboard dei pagamenti KPI

TL; DR

Un dashboard è composto da tre strati: Salute del vortice (Attempt→Auth→Capture), Efficienza finanziaria (TtW/TtR, Cost/GGR, FX) e Affidabilità dell'infrastruttura (Webhook/Latency/Settlement). Il segreto sono basi di calcolo corrette, segmentazione obbligatoria (country x provider x method x BIN x ticket _ size x risk), soglie SLO e playbook finite quando si esce dai corridoi.

1) Per chi e quali domande chiudiamo

CEO/GM (giornaliero, 3-5 min): "La conversione dei pagamenti e la velocità di output sono normali? Il costo del denaro è sotto controllo?"

Head of Payments/Treasury (ogni ora): "Dov'è il degrado del fornitore/paese/metodo? La liquidità per i pagamenti immediati è sufficiente?"

Fraud/Risk (ogni giorno): "AR con antifrode? Abandon на 3DS и Soft declines?»

Support/Operations (online): "Quale ETA di ritiro e restituzione? «Dove sono finiti i webhook?»

Finance/Recon (D + 1): "Settlement in tempo? La Commissione e la FX sono in linea con il piano?"

2) Metriche principali e definizioni precise

2. 1 Vortice di pagamento

Attempt - pagamenti iniziati.
Auth Approved - Autorizzazioni approvate.
Captured - Cancellato correttamente.

• `AR_gross = Auth_Approved / Auth_Attempted`
• `AR_net = Captured_Tx / Auth_Attempted`
• `Capture_Success = Captured_Tx / Capture_Attempted_Tx`
• `Capture_Latency_p95 = p95(capture_ts - auth_ts)`

2. 2 Conclusioni e restituzioni

Payout Success % = Success_Payouts / Attempted_Payouts

TtW p95 = p95(payout_credited_at - payout_initiated_at)

Refund Rate = Refunded_Tx / Captured_Tx

TtR p95 = p95(refund_credit_at - refund_initiated_at)

Refund Error % = Refund_Failed / Refund_Attempted

Refund _ to _ Source% - Percentuale di ritorni al metodo originale

2. 3 Costo e FX

Cost/Tx = Fee_fixed + AmountFee_pct + FX_Spread

Cost/GGR = ΣCost / GGR

FX Slippage (bps) = (exec_px − mid_px)/mid_px × 10 000

2. 4 Affidabilità delle integrazioni

Webhook Delivery p95 (сек), Success %

API Latency p95/p99 (auth/capture/refund/payout)

Settlement Timelover= Battelli giunti a T + N/tutti i battelli del periodo

2. 5 3DS/frizione (per carte)

3DS Challenge Share = Challenge / 3DS_Total

Frictionless Share = Frictionless / 3DS_Total

Abandon on 3DS = 3DS_Started − 3DS_Completed

3) Tagli e filtri (set minimo)

Фильтры в шапке: `date range (UTC)`, `country`, `provider`, `method_group`, `BIN`, `device/os`, `ticket_size bucket (≤€50 / €50–200 / >€200)`, `risk_segment`, `kyc_tier`, `new_vs_returning`, `affiliate`.

• country×provider, BIN×country, method×provider, device/os, ticket_size.

4) Schermatura principale (Layout)

1. Piastra superiore KPI (ieri/oggi, confronto a p7 mediana):

`AR_net`, `Capture_Success`, `Payout Success%`, `TtW p95`, `TtR p95`, `Cost/GGR`, `Webhook p95`, `Settlement Timeliness`.

2. Funnel (Attempt→Auth→Capture) con la selezione del segmento e la visualizzazione delle cause di guasto (top codici ISO/binari).

3. Heatmap AR per «country x provider» e un heatmap BIN separato per il volume superiore.

4. Pannello 3DS: Challenge/Frictionless/Abandon + confronto alla linea bench.

5. Payout & Refund Health: Success%, p95 (TtW/TtR), ошибки, Refund_to_Source %.

6. Cost & FX: Cost/GGR per metodi, FX slippage/fees per sito.

7. Affidabilità di integrazione: Webhook delivery p95/Success%, API latency p95/p99, Duplicata rate, Report delivery SLA.

8. Gli alert attivi (vedere l'articolo 8), lo stato dei feelovers e le note del Tesoro (residui L0, prefund).

5) SLO e alert (corridoi)

• «AR _ gross» mappa 3DS2: 82-92% (segmento); «AR _ net» 80%
• `Capture_Success` ≥ 98. 5% (ore)
• `Webhook p95` ≤ 3 с, Success ≥ 99. 9%
• `Payout TtW p95` instant ≤ 120 с; (T + 1) - 100% al giorno D + 1
• «Refund p95» della carta T + 1 b.d.; instant ≤ 60 с
• `Refund Error %` < 0. 3%
• `Settlement Timeliness` ≥ 99%
• «Cost/GGR» è un corridoio di destinazione individuale con metodo

• 'AR_gross↓> 3 p.p.p. alla mediana di 7 giorni (paese/PSP/BIN) → P1/P0
• `Capture_Success < 98%` (час) → P1
• 'Webhook p95> 5 c' o duplicati> 0 → P1
• `Payout TtW p95 > SLO` или Success%<99% → P1
• `Refund Error% > 0. 3%` или `Double Refund > 0` → P0
• `Settlement on-time < 99%` → P1
• «Cost/GGR» uscita dal corridoio secondo il metodo di → P2

Ogni alert apre la scheda runbook a (azioni/escalation/feelover).

6) Formule e basi di calcolo (dettagli)

Tutte le quote sono basate esplicitamente su «denominator».
I tempi sono in UTC; p-quantili: PERCENTILE _ CONT.

«AR _ clean» = «Auth _ Approved/( Auth _ Attempted - Fraud _ Preblocked - Abandon _ 3DS)»

`Net_Conversion` = `Captured_Tx / Auth_Attempted_Tx`

`Refund_to_Source %` = `Refund_to_Original_Method / Total_Refunds`

"Idle Cash%" (nel mini-widget del Tesoro) = "(Bilancia - Target _ Bilancia )/Balance'

7) pattern UX

Sopra KPI piastra, sotto funnel + heatmaps, sotto integrazione e finanza.
Tultipi con formula/base/eccezioni (ad esempio, «dopo l'antifrode»).
La linea di confronto è p7 mediana e «ieri «/» lunedì scorso ».
Drill-down click: da heatmap a tabella di guasti.
Snapshot per RCA - Il pulsante blocca la vista corrente per il post mortem.

8) Playbook (schede attività incorporate)

Auth drop → cambiare smart-routing, sollevare 3DS-challenge su BIN, limitare i retrai.
Webhook ritardi attivare polling, congelare auto-rifanda/rimborsi auto pericolosi, aumentare l'idampotenza.
Payout degradazione del feelover del binario, treasury top-up, priorità VIP.
ritardo di , contrassegno « ense», escalation in PSP.
Rifund errori/doppie refund-freeze, compressione, doppie.

(La scheda contiene il foglio di lavoro e i contatti dell'escalation).

9) Modello di dati (minimo sufficiente)

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

events/webhooks:
provider, event_kind, event_ts, delivered_ts, retries, duplicate_flag, idempotency_key

settlements/reports:
provider, batch_id, settlement_date, amount_settled, currency, fee_amount, status

treasury/pockets (mini-widget):
pocket_id, counterparty, currency, balance, target_balance, low_watermark, updated_at

Indici: «provider», «method _ code», «country», «bin», «event _ ts».

10) Tagli SQL (esempio)

10. 1 Vortice e AR

sql
WITH base AS (
SELECT
DATE_TRUNC('hour', attempt_ts) AS h,
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 h, 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;

10. 2 Webhook SLA

sql
SELECT
DATE_TRUNC('hour', event_ts) AS h, provider,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (delivered_ts - event_ts))) AS wb_p95_sec,
AVG(CASE WHEN retries=0 AND NOT duplicate_flag THEN 1 ELSE 0 END) AS wb_success
FROM webhooks
GROUP BY 1,2;

10. 3 Refund & Payout Health

sql
SELECT
DATE_TRUNC('day', COALESCE(refund_initiated_ts, payout_initiated_ts)) d,
method_code, provider,
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,
COUNT() FILTER (WHERE payout_status='ATTEMPTED') AS payout_attempted,
COUNT() FILTER (WHERE payout_status='SUCCESS')  AS payout_success,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (payout_credited_ts - payout_initiated_ts))) AS ttw_p95_sec
FROM payments_flat
GROUP BY 1,2,3;

10. 4 Cost/GGR

sql
SELECT
DATE_TRUNC('day', capture_ts) d,
method_code, provider,
SUM(fees_fixed + amountfees_pct + fx_spread) AS total_cost,
SUM(capture_amount) AS total_captured,
(SUM(fees_fixed + amountfees_pct + fx_spread) / NULLIF(SUM(total_captured),0)) AS cost_to_captured
FROM payments_flat
WHERE capture_status='CAPTURED'
GROUP BY 1,2,3;

11) Schermate aggiuntive

BIN Drilldown: AR/decline-codes, frizione 3DS, latency per emittenti.
Provider Scorecard: metriche SLA, incidenti, prestiti, Cost/GGR.
Treasury Snapshot: L0/L1 residui, prefund, , rifornimenti.
Recon View: Settlement Timelover, Aging non cucite batch, Fee accuracy.

12) Qualità dei dati

Dizionario KPI con versioning (formule/base/eccezioni).
TZ singolo = UTC, p-quantili solo CONT.
Idemoticità degli eventi e dedotto dei webhoop.
Politica di tempo/somma/FX (per la compressione/latitanza).
Data test in CI: basi di divisori non vuote, monotonia delle etichette temporali, quota NULL.

13) Implementazione: foglio di assegno

• Definiti KPI/formule/basi e registrati nel dizionario.
• È stato configurato l'ingestione e la normalizzazione degli eventi/registri.
• Sono state costruite vetrine «payments _ flat», «webhooks», «settlements», «treasury».
• Implementati heatmaps, funnel, latency, payout/refund panels.
• Sono fissate soglie di SLO e alert; sono collegati ai playbook.
• Ruoli di accesso: C-level (read-only summary), Ops/Fraud (drill-down).
• QBR settimanale per provider basato su Provider Scorecard.
• Set di test UAT: dataset demo, controllo dei quantili p, correttezza delle basi, alert.

14) Errori frequenti

La miscelazione delle basi («attempt'vs'capture») è una falsa conclusione.
Nessuna segmentazione «ticket _ size» → un quadro AR distorto.
Ignorare abandon su 3DS è un problema «eccessivo» con il provider.
La mancanza di controllo su webhook duplicates consente di eseguire doppie azioni.
Una vetrina incompleta per settement/fees non può essere valutata da Cost/GGR.
Senza SLO e playbook, il dashboard diventa una vetrina senza azione.

Riepilogo

Il dashboard dei pagamenti KPI è uno strumento operativo, non solo grafici. Connette il vortice, il denaro e l'infrastruttura, si basa su formule chiare e segmentazione, dà segnali automatici e offre azioni immediate. Di conseguenza: AR _ net superiore, in corridoio, Cost/GGR sotto controllo, gli incidenti si localizzano rapidamente e il dialogo con i provider si basa sui numeri.