KPI de plată tablou de bord

TL; DR

Un tablou de bord - trei straturi: sănătatea pâlniei (Attempt→Auth→Capture), eficiența financiară (TtW/TtR, cost/GGR, FX) și fiabilitatea infrastructurii (Webhook/Latency/Settlement). Secretul este bazele de calcul corecte, segmentarea obligatorie (țară furnizor metodă BIN ticket _ size), SLO-uri prag și playbook-uri gata făcute la părăsirea coridoarelor.

1) Pentru cine și ce întrebări închidem

CEO/GM (zilnic, 3-5 min): "Conversia plăților și viteza de retragere sunt normale? Este sub control costul acceptării banilor?"

Șeful de plăți/trezorerie (la fiecare oră): "Unde este degradarea de către furnizor/țară/metodă? Există suficientă lichiditate pentru plățile instantanee?"

Fraudă/Risc (zilnic): "AR cu antifraudă? Abandonați на 3DS и Soft scade?"

Suport/Operațiuni (online): "Care este ETA pentru retragere și returnare? Unde atârnă cârligele?"

Finance/Recon (D + 1): "Decontarea la timp? Comisioane și FX se potrivesc planului?"

2) Valorile principale și definițiile exacte

2. 1 Pâlnie de plată

Încercare - plăți inițiate.
Auth Aprobat - autorizații aprobate.
Capturat - a fost eliminat cu succes.

• 'AR _ brut = 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 Ieșiri și returnări

Succes de plată% = Success_Payouts/ Attempted_Payouts

TtW p95 = p95 (payout_credited_at - payout_initiated_at)

Rata de rambursare = Refunded_Tx/ Captured_Tx

TtR p95 = p95 (refund_credit_at - refund_initiated_at)

Eroare de rambursare% = Refund_Failed/ Refund_Attempted

Refund_to_Source% - proporția de reveniri la metoda originală

2. 3 Cost și FX

Cost/Tx = Fee_fixed + AmountFee_pct + FX_Spread

Cost/GGR = Cost Σ/GGR

FX Slippage (bps) = ( )/10 000

2. 4 Fiabilitatea integrărilor

Livrare Webhook p95 (сек), Succes%

API Latency p95/p99 (auth/capture/rambursare/plată)

Decontare Actualitatea = Loturi care au venit la loturile declarate T + N/toate loturile pentru perioada

2. 5 3DS/friction (pentru cărți)

3DS Challenge Share = Provocare/ 3DS_Total

Frictionless Share = Frictionless/ 3DS_Total

Abandonarea pe 3DS = 3DS_Started − 3DS_Completed

3) Secțiuni și filtre (set minim)

Фильтры в шапке: 'data range (UTC)', 'country', 'provider', 'method _ group', 'BIN', 'device/os',' ticket _ size bucket (≤€50/€ 50-200/> €200) ',' risk _ segment ',' kyc _ tier ',' new _ vs _ returning ',' afiliat '.

• țară × furnizor, BIN × țară, metodă × furnizor, dispozitiv/os, ticket_size.

4) Aspectul ecranului principal

1. Placa KPI superioară (pentru ieri/astăzi, comparație cu mediana p7):

'AR _ net', 'Capture _ Success', 'Payout Succes%', 'TtW p95', 'TtR p95', 'Cost/GGR', 'Webhook p95', 'Decontare actualitate'.

2. Pâlnie (Attempt→Auth→Capture) cu selectarea segmentului și afișarea cauzelor de eșec (coduri de top ISO/pe șine).

3. Heatmap AR după „furnizor de × de țară” și o hartă termică BIN separată pentru volumul de top.

4. panoul 3DS: Challenge/Frictionless/Abandon + comparație cu linia de bancă.

5. Plată și restituire Sănătate: Succes%, p95 (TtW/TtR), ошибки, Refund_to_Source%.

6. Cost & FX: Cost/GGR prin metoda, FX derapaj/taxe pe site.

7. Fiabilitatea integrării: Livrare prin broșură web p95/Succes%, Latență API p95/p99, Rată duplicat, Livrare raport SLA.

8. Panoul de incidente: alerte active (a se vedea § 8), statutul feilovers și note de trezorerie (resturi L0, prefund).

5) SLO și alerte (coridoare)

• 'AR _ brut' 3DS2 carduri: 82-92% (pe segment); 'AR _ net' ≥ 80%
• 'Capture _ Success' ≥ 98. 5% (oră)
• 'Webhook p95' ≤ 3 с, Succes ≥ 99. 9%
• „Plată TtW p95” instant ≤ 120 с; (T + 1) - 100% în ziua D + 1
• 'Rambursare TtR p95' card ≤ T + 1 bp; instant ≤ 60 с
• „Eroare de rambursare%” <0. 3%
• „Promptitudinea decontării” ≥ 99%
• „Cost/RGG” - coridor țintă individual conform metodei

• „AR_gross↓> 3 pp” până la valoarea mediană de 7 zile (ţara/PSP/BIN) → P1/P0
• 'Capture _ Succes <98%' (час) → P1
• 'Webhook p95> 5 c' sau duplicate> 0 → P1
• 'Payout TtW p95> SLO' или Succes% <99% → P1
• Eroare de rambursare%> 0. 3% 'или' Rambursare dublă> 0 '→ P0
• „Decontare la timp <99%” → P1
• "Cost/GGR 'out din coridor folosind metoda P2 →

Fiecare alertă deschide cardul runbook 'a (acțiuni/escaladare/feilover).

6) Formule și baze de calcul (detaliere)

Toate acțiunile - cu o bază explicită: indicați „numitor” în tip.
Times - în UTC; p-cantități: PERCENTILE_CONT.

'AR _ clean' (operațional) = 'Auth _ Approved/( )'

'Net _ Conversion' = 'Capturat _ Tx/ Auth_Attempted_Tx'

'Rambursare _ la _ Sursa%' = 'Rambursare _ la _ Original _ Metodă/ Total_Refunds'

'Idle Cash%' (în trezorerie mini widget) = '(Sold − Target_Balance )/Balance'

7) Modele UX

Mai sus este o placă KPI, mai jos este pâlnie + heatmaps, mai jos este integrarea și finanțe.
Tultips cu formulă/bază/excepții (de exemplu, „după antifraudă”).
Linie comparativă: p7 mediană și „ieri „/” ultima luni „.
Drill-down cu clic: de la heatmap la masa de BIN→Issuer→kody defect.
Instantanee pentru RCA: Butonul „pin” vizualizare curentă pentru post-mortem.

8) Playbooks (built-in carduri de acțiune)

Auth drop → comutați rutarea inteligentă, ridicați 3DS-challenge la BIN, limitați retraiurile.
Webhook întârzieri → permite sondaje, congela auto-refands/auto-plăți periculoase, crește idempotence.
Degradarea plăților → feiler feroviar, reîncărcare trezorerie, prioritizare VIP.
Întârzierea decontării → StressRes, marca „Suspans”, escaladarea în PSP.
Erori de rambursare/duplicate → rambursare-înghețare, reconciliere, inversarea duplicatelor.

(Cardul conține o listă de verificare și contacte de escaladare.)

9) Modelul de date (minim suficient)

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

Indexuri: prin 'provider', 'method _ code', 'country', 'bin', 'event _ ts'.

10) Felii SQL (exemplu)

10. 1 Pâlnie și 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 Rambursare și plată Sănătate

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/RGG

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) Ecrane suplimentare

BIN Drilldown: AR/declin-coduri, 3DS-friction, latență de către emitenți.
Furnizor Scorecard: SLA Metrics, Incidente, Credite, Cost/GGR.
Instantaneu de trezorerie: solduri L0/L1, prefund, StressRes, reaprovizionare TtF.
Recon View: Calendarul de decontare, îmbătrânire Butches non-cusute, Taxa de precizie.

12) Calitatea datelor i治理

Dicționar de KPI-uri cu versioning (formule/bază/excepții).
Singur TZ = UTC, p-cantități numai CONT.
Idempotența evenimentelor și deducerea cârligelor web.
Politica privind toleranțele de timp/sumă/FX (pentru reconciliere/latență).
Teste de date în CI: baze divizoare non-goale, monotonie timestamp, fracție NULL.

13) Implementare: listă de verificare

• KPIs/formule/baze sunt definite și fixate în dicționar.
• ingestia și normalizarea evenimentului/registrului configurat.
• Vitrine construite 'payments',' webhooks', 'decontări', 'trezorerie'.
• Implementat heatmaps, pâlnie, latență, panouri de plată/rambursare.
• SLO și pragurile de alertă stabilite; asociat cu playbook-uri.
• Roluri de acces: C-level (rezumat read-only), Ops/Fraud (drill-down).
• QBR săptămânal de furnizor bazat pe furnizorul Scorecard.
• Suită de testare UAT: set de date demo, verificarea cantității p, corectitudinea bazei de date, alerte.

14) Erori frecvente

Baze de amestecare („încercare” vs „captură”) → concluzii false.
Nu există o segmentare „ticket _ size” → o imagine AR distorsionată.
Ignorați abandonul pe 3DS → o problemă „supraestimată” cu furnizorul.
Lipsa duplicatelor de control al cârligelor web → a acțiunilor duble.
Vitrina incompleta pentru decontare/taxe → Cost/GGR nu poate fi estimata.
Fără SLO-uri și playbook-uri, tabloul de bord se transformă într-o „vitrină fără acțiune”.

Rezumat

KPI-urile de plată sunt un instrument operațional, nu doar grafice. Acesta conectează pâlnie, bani și infrastructură, se bazează pe formule clare și segmentare, dă semnale automate și sugerează imediat acțiuni. Ca urmare: AR_net de mai sus, TtW/TtR în coridoare, Cost/GGR sub control, incidentele sunt localizate rapid, iar dialogul cu furnizorii se bazează pe numere.