Zahlungs-KPI-Dashboard

TL; DR

Ein Dashboard - drei Schichten: Trichtergesundheit (Attempt→Auth→Capture), Finanzielle Effizienz (TtW/TtR, Cost/GGR, FX) und Zuverlässigkeit der Infrastruktur (Webhook/Latency/Settlement). Das Geheimnis sind korrekte Berechnungsgrundlagen, obligatorische Segmentierung (country × provider × method × BIN × ticket _ size × risk), Schwellenwerte SLO und vorgefertigte Playbooks beim Verlassen der Korridore.

1) Für wen und welche Fragen schließen wir

CEO/GM (täglich, 3-5 min): "Zahlungsumwandlung und Rücknahmegeschwindigkeit normal? Sind die Kosten für die Annahme von Geld unter Kontrolle?"

Head of Payments/Treasury (stündlich): "Wo ist die Degradierung nach Anbieter/Land/Methode? Gibt es genug Liquidität für sofortige Zahlungen?"

Fraud/Risk (täglich): "AR in Anbetracht der Fraud? Abandon на 3DS и Soft declines?»

Support/Operations (online): "Was ist die ETA für die Ausgabe und Rückgabe? Wo hängen Webhooks?"

Finanzen/Recon (D + 1): "Ansiedlung rechtzeitig? Entsprechen die Provisionen und FX dem Plan?"

2) Hauptmetriken und genaue Definitionen

2. 1 Zahlungstrichter

Attempt - Initiierte Zahlungen.
Auth Approved - genehmigte Berechtigungen.
Captured - erfolgreich abgeschrieben.

• `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 Befunde und Rückgaben

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% - Rücklaufquote der ursprünglichen Methode

2. 3 Kosten und 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 Zuverlässigkeit der Integrationen

Webhook Delivery p95 (сек), Success %

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

Settlement Timeliness = Batches, die zum angegebenen T + N/alle Batches für den Zeitraum kamen

2. 5 3DS/Friktion (für Karten)

3DS Challenge Share = Challenge / 3DS_Total

Frictionless Share = Frictionless / 3DS_Total

Abandon on 3DS = 3DS_Started − 3DS_Completed

3) Schnitte und Filter (Mindestsatz)

Фильтры в шапке: `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) Layout des Hauptbildschirms

1. Obere KPI-Platte (für gestern/heute, Vergleich zu p7 Median):

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

2. Funnel (Attempt→Auth→Capture) mit Segmentauswahl und Anzeige der Fehlerursachen (ISO-Top-Codes/auf Schienen).

3. Heatmap AR durch 'country × provider' und separate BIN heatmap für top-Volumen.

4. 3DS-Panel: Challenge/Frictionless/Abandon + Vergleich zur Benchmark-Linie.

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

6. Kosten & FX: Kosten/GGR nach Methoden, FX slippage/fees nach Standorten.

7. Integrationssicherheit: Webhook-Lieferung p95/Erfolg%, Latenz-API p95/p99, doppelte Rate, SLA-Lieferung melden.

8. Incident-Panel: aktive Alerts (siehe § 8), Failover-Status und Treasury Notes (L0-Salden, Prefund).

5) SLO und Alerts (Korridore)

• 'AR _ gross' Karte 3DS2: 82-92% (nach Segment); 'AR _ net' ≥ 80%
• `Capture_Success` ≥ 98. 5% (stündlich)
• `Webhook p95` ≤ 3 с, Success ≥ 99. 9%
• `Payout TtW p95` instant ≤ 120 с; (T + 1) - 100% am Tag D + 1
• „Refund TtR p95“ Karten ≤ T + 1 bd; instant ≤ 60 с
• `Refund Error %` < 0. 3%
• `Settlement Timeliness` ≥ 99%
• „Cost/GGR“ - individueller Zielkorridor nach Methode

• 'AR_gross↓> 3 pp' zum 7-Tage-Median (nach Land/PSP/BIN) → P1/P0
• `Capture_Success < 98%` (час) → P1
• „Webhook p95> 5 c“ oder Duplikate> 0 → P1
• `Payout TtW p95 > SLO` или Success%<99% → P1
• `Refund Error% > 0. 3%` или `Double Refund > 0` → P0
• `Settlement on-time < 99%` → P1
• „Cost/GGR“ -Korridor nach → P2

Jede Alert öffnet eine Runbook 'a-Karte (Aktionen/Eskalationen/Failover).

6) Formeln und Berechnungsgrundlagen (Detail)

Alle Aktien - mit einer expliziten Basis: Geben Sie im Tulltyp 'denominator' an.
Zeiten - in UTC; p-Quantile: PERCENTILE_CONT.

' AR_clean ' (operativ) = ' 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%“ (im Treasury-Mini-Widget) = „(Balance − Target_Balance )/Balance“

7) UX-Muster

Oben KPI-Würfel, unten - Funnel + Heatmaps, unten - Integrationen und Finanzen.
Tulpentypen mit Formel/Basis/Ausnahmen (z.B. „nach Fraud“).
Vergleichslinie: p7 median und „gestern „/“ letzter Montag “.
Drill-down per Klick: Mit der Heatmap auf die Tabelle BIN→Issuer→kody Bounce.
Schnappschüsse für RCA: „Pin“ -Taste der aktuellen Ansicht für Post-Mortem.

8) Playbooks (integrierte Aktionskarten)

Auth Drop → Schalten Sie Smart-Routing, heben Sie 3DS-challenge auf BIN, begrenzen Sie Retrays.
Webhook-Verzögerungen → Polling aktivieren, Auto-Refands/gefährliche Auto-Auszahlungen einfrieren, Idempotenz verstärken.
Payout Degradierung → Schienen-Failover, Treasury Top-up, VIP-Priorisierung.
Settlement Verzögerung → StressRes, Markierung „Suspense“, Eskalation in der PSP.
Refund Fehler/Takes → Refund-Freeze, Abstimmung, storno Takes.

(Die Karte enthält eine Checkliste und Eskalationskontakte.)

9) Datenmodell (minimal ausreichend)

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

Indizes: nach 'provider', 'method _ code', 'country', 'bin', 'event _ ts'.

10) SQL-Schnitte (Beispiel)

10. 1 Trichter und 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) Zusätzliche Bildschirme

BIN Drilldown: AR/Decline-Codes, 3DS-Friktion, Latenz nach Emittenten.
Anbieter Scorecard: SLA Metriken, Incidents, Credits, Cost/GGR.
Treasury Snapshot: L0/L1 Reste, Prefund, StressRes, TtF Nachschub.
Recon View: Settlement Timeliness, Aging ungenäht Schlachten, Fee accuracy.

12) Datenqualität i治理

KPI Wörterbuch mit Versionierung (Formeln/Basis/Ausnahmen).
Einheitliches TZ = UTC, p-Quantile - nur CONT.
Idempotenz von Ereignissen und Dedup von Webhooks.
Toleranzrichtlinie für Zeit/Beträge/FX (für Abgleich/Latenz).
Datentests in CI: nicht leere Teilerbasen, Zeitstempelmonotonie, NULL-Anteil.

13) Umsetzung: Checkliste

• KPIs/Formeln/Basen sind definiert und im Wörterbuch festgehalten.
• ingestion und Normalisierung von Ereignissen/Registern eingerichtet.
• 'payments _ flat',' webhooks', 'settlements', 'treasury' Vitrinen wurden gebaut.
• Implementiert heatmaps, funnel, latency, payout/refund panels.
• Es wurden SLO-Schwellenwerte und Warnmeldungen festgelegt. mit Playbooks verknüpft.
• Zugriffsrollen: C-Level (Read-Only Summary), Ops/Fraud (Drill-Down).
• Wöchentliche QBR nach Anbietern basierend auf Provider Scorecard.
• UAT-Test-Set: Demo-Dataset, Überprüfung der p-Quantile, Korrektheit der Basen, Alert.

14) Häufige Fehler

Die Vermischung von Basen ('attempt' vs' capture') → falsche Schlussfolgerungen.
Keine Segmentierung 'ticket _ size' → verzerrtes AR-Bild.
Ignorieren Sie abandon auf 3DS → ein „übertriebenes“ Problem mit dem Anbieter.
Keine Kontrolle über Webhook-Duplikate → Doppelaktionen.
Ein unvollständiger Showcase von settlement/fees kann → nicht bewertet werden Cost/GGR.
Ohne SLO und Playbooks verwandelt sich das Dashboard in ein „Schaufenster ohne Action“.

Zusammenfassung

Das Zahlungs-KPI-Dashboard ist ein betriebliches Werkzeug, nicht nur Grafiken. Es verbindet Trichter, Geld und Infrastruktur, setzt auf klare Formeln und Segmentierung, gibt automatische Signale und schlägt sofort Maßnahmen vor. Das Ergebnis: AR_net oben, TtW/TtR in den Gängen, Cost/GGR unter Kontrolle, Vorfälle schnell lokalisiert und der Dialog mit den Anbietern auf Zahlen aufgebaut.