Dashboard de paiement KPI

TL; DR

L'un est trois couches : Santé de l'entonnoir (Attempt→Auth→Capture), Efficacité financière (TtW/TtR, Cost/GGR, FX) et Fiabilité de l'infrastructure (Webhook/Latency/Settlement). Le secret réside dans les bases de calcul correctes, la segmentation obligatoire (country × provider × method × BIN × ticket _ size × risk), les SLO de seuil et les playbacks prêts à sortir des couloirs.

1) Pour qui et quelles questions nous fermons

CEO/GM (quotidien, 3-5 min) : "La conversion des paiements et la rapidité des retraits sont normales ? Le coût de recevoir de l'argent sous contrôle ?"

Head of Payments/Treasury (toutes les heures) : "Où est la dégradation par fournisseur/pays/méthode ? Y a-t-il assez de liquidités pour les paiements instantanés ?"

Fraud/Risk (quotidien) : "AR vu l'antifrode ? Abandon на 3DS и Soft declines?»

Support/Opérations (en ligne) : "Quel ETA de retrait et de retour ? « Où sont les webhooks ? »

Finance/Recon (D + 1) : "Settlement à l'heure ? Les commissions et FX sont-elles conformes au plan ?"

2) Principales mesures et définitions précises

2. 1 Vortex de paiement

Attempt - paiements initiés.
Auth Approved - autorisations approuvées.
Captured - révoqué avec succès.

• `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 Conclusions et retours

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 % - proportion de retours sur la méthode initiale

2. 3 Coût et 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 Fiabilité des intégrations

Webhook Delivery p95 (сек), Success %

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

Settlement Time = Batchi qui sont entrés dans le T + N déclaré/tous les Batchi pour la période

2. 5 3DS/friction (pour les cartes)

3DS Challenge Share = Challenge / 3DS_Total

Frictionless Share = Frictionless / 3DS_Total

Abandon on 3DS = 3DS_Started − 3DS_Completed

3) Coupes et filtres (ensemble minimum)

Фильтры в шапке: `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) Marquage de l'écran d'accueil (Layout)

1. Haut de gamme KPI (pour hier/aujourd'hui, comparaison à la p7 médiane) :

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

2. Funnel (Attempt→Auth→Capture) avec sélection du segment et affichage des causes de défaillance (codes ISO/sur rails).

3. Heatmap AR par 'country × provider' et BIN heatmap séparé pour le volume supérieur.

4. 3DS panel : Challenge/Frictionless/Abandon + comparaison à la ligne de bench.

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

6. Cost & FX : Cost/GGR par méthodes, FX slippage/fees par sites.

7. Fiabilité d'intégration : Webhook delivery p95/Success %, API latency p95/p99, taux de duplication, production de rapports SLA.

8. Panneau incident : alertes actives (voir § 8), état des faussaires et notes du Trésor (soldes L0, préfund).

5) SLO et alertes (couloirs)

• 'AR _ gross 'de la carte 3DS2 : 82-92 % (par segment) ;' AR _ net '≥ 80 %
• `Capture_Success` ≥ 98. 5 % (heure)
• `Webhook p95` ≤ 3 с, Success ≥ 99. 9%
• `Payout TtW p95` instant ≤ 120 с; (T + 1) - 100 % par jour D + 1
• 'Refund TtR p95 'de la carte ≤ T + 1 b.d. ; instant ≤ 60 с
• `Refund Error %` < 0. 3%
• `Settlement Timeliness` ≥ 99%
• 'Cost/GGR '- corridor cible individuel selon la méthode

• « AR_gross↓> 3 pp » à la médiane de 7 jours (par pays/PSP/BIN) → P1/P0
• `Capture_Success < 98%` (час) → P1
• 'Webhook p95> 5 c'ou en double> 0 → P1
• `Payout TtW p95 > SLO` или Success%<99% → P1
• `Refund Error% > 0. 3%` или `Double Refund > 0` → P0
• `Settlement on-time < 99%` → P1
• « Cost/GGR » sortie du couloir selon la méthode → P2

Chaque alert ouvre la carte runbook 'a (action/escalade/faussaire).

6) Formules et bases de calcul (détail)

Tous les lobes sont avec une base explicite : indiquez dans le tultip 'denominator'.
L'époque est à UTC ; p-quantifié : PERCENTILE_CONT.

'AR _ clean '(opérationnel) =' 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 % '(dans le mini-widget du Trésor) =' (Balance − Target_Balance )/Balance '

7) Modèles UX

En haut de la plaque KPI, en bas - funnel + heatmaps, en bas - l'intégration et la finance.
Tultips avec formule/base/exceptions (par exemple, « après antifrode »).
Ligne de comparaison : p7 médian et « hier « / » lundi dernier ».
Drill-down par clic : de heatmap à la table des échecs BIN→Issuer→kody.
Snapshots pour RCA : bouton « fixer » la vue actuelle pour le post-mortem.

8) Playbooks (cartes d'action intégrées)

Auth drop → commuter smart routing, soulever les 3DS-challenge sur BIN, limiter les retraits.
Webhook retards → allumer polling, geler auto-refands/dangereux auto-paiements, renforcer l'idempotence.
Payout Dégradation → Faylover Rail, top-up treasury, priorité VIP.
Settlement retard → StressRes, marque « Suspense », escalade dans PSP.
Refund erreur/doublures → refund-freeze, rapprochement, doublures inverses.

(La carte contient la chèque et les contacts d'escalade.)

9) Modèle de données (minimum suffisant)

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

Index : par 'provider', 'method _ code', 'country', 'bin', 'event _ ts'.

10) tranches SQL (exemple)

10. 1 Entonnoir et 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) Écrans supplémentaires

BIN Drilldown : AR/decline-codes, friction 3DS, latitude par émetteur.
Fournisseur Scorecard : métriques SLA, incidents, crédits, Cost/GGR.
Trésor Snapshot : soldes L0/L1, préfund, StressRes, TtF recharges.
Recon View : Settlement Time, Aging non cousu trampoline, Fee accuracy.

12) Qualité des données i治理

Dictionnaire KPI avec versioning (formules/base/exceptions).
Un seul TZ = UTC, p-quantili - seulement CONT.
L'idempotence des événements et le dedup des webhooks.
Politique de tolérances par temps/montants/FX (pour le rapprochement/latence).
Tests de données dans CI : bases de diviseurs non vides, monotonie des horodatages, part NULL.

13) Mise en œuvre : chèque

• Les KPI/formules/bases sont définies et fixées dans le dictionnaire.
• L'ingestion et la normalisation des événements/registres sont configurées.
• Les vitrines 'payments _ flat', 'webhooks', 'settlements', 'treasury'ont été construites.
• Mis en œuvre heatmaps, funnel, latency, payout/refund panels.
• Les seuils SLO et alerte sont fixés ; sont liés aux pleybuks.
• Rôles d'accès : C-level (résumé), Ops/Fraud (drill-down).
• QBR hebdomadaire sur les fournisseurs basés sur Provider Scorecard.
• Jeu de tests UAT : démo-datacet, vérification des p-quantiles, exactitude des bases, alertes.

14) Erreurs fréquentes

Mélange de bases ('attempt'vs' capture ') → fausses conclusions.
Pas de segmentation 'ticket _ size' → image déformée AR.
Ignorer l'abandon sur 3DS → un problème « surestimé » avec le fournisseur.
L'absence de contrôle du webhook duplicates → des actions doubles.
Une vitrine incomplète par settlement/fees est → impossible à évaluer Cost/GGR.
Sans SLO et pleyboard, le dashboard devient une « vitrine sans action ».

Résumé

Dashboard Payment KPI est un outil opérationnel, pas seulement graphique. Il relie l'entonnoir, l'argent et l'infrastructure, repose sur des formules claires et la segmentation, donne des signaux automatiques et propose immédiatement des actions. En conséquence : AR_net ci-dessus, TtW/TtR dans les couloirs, Cost/GGR sous contrôle, les incidents sont localisés rapidement et le dialogue avec les fournisseurs est basé sur des chiffres.