KPIs des Zahlungskreislaufs: auth, capture, refund

TL; DR

Die Zahlungsschleife wird als Trichter gemessen: „Attempt → Auth → Capture → Settle/Refund“. Die wichtigsten Metriken sind nicht nur die Zulassungsrate, sondern auch die reinen ARs (nach Betrugsbekämpfung und 3DS), der Erfassungserfolg, die Zeit bis zur Abbuchung/Gutschrift, die Kosten/FX, Idempotenzfehler und die Qualität der Retouren (TtR und Rate). Der Gewinner ist derjenige, der AR↑, TtW↓, Cost/GGR↓ und Disputes↓ hält, ohne das Risikoprofil zu brechen.

1) Wörterbuch der Stadien und Ereignisse

Attempt - Zahlungsversuch (Initiierung).
Auth - Autorisierung (Bank/Wallet/Rails bestätigt die Möglichkeit der Abbuchung).
Erfassung - Tatsächliche Abschreibung (vollständig/teilweise).
Settle - Clearing und Abrechnung.
Refund - Rendite (vollständig/teilweise), 'TtR = Zeit bis zum Refundkredit'.
Void - Abbrechen bis capture (falls unterstützt).
3DS/Step-up - Friktion auf der Autorisierung.
Soft Decline/Hard Decline - Fehler, wiederherstellbar/nicht wiederherstellbar.

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

2) KPI-Hierarchie (Zielbaum)

Obere Ebene

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 (Schlussfolgerungen), TtC (Erfassung) p95

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

Mittleres Niveau

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

Soft Decline Recovery Rate (Retrays/Smart Routing)

Partial Capture Share, Capture Latency

Refund to Source %, Duplicate/Idempotency Incidents

Untere Ebene (Diagnose)

Codefehler (ISO/Rail), p95 API Latenz, SLA Webhooks, Anteil 'Nicht ehren', 'Insufficient Funds',' Suspected Fraud', 'Systemfehler'.

3) Formeln (genaue Definitionen)

3. 1 Autorisierung

`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`

Die Schnitte sind obligatorisch: 'BIN × country', 'provider × method', 'device/os', 'ticket _ size' (z.B. ≤€50, €50-200,> €200).

3. 2 Abschreibungen (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 Kosten und FX

`Cost_per_Tx = Fee_fixed + AmountFee_pct + FX_Spread`

`Cost/GGR = ΣCost / GGR`

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

3. 4 Rücksendungen (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`

„Double _ Refund _ Incidents“ - Zähler für idempotente Kollisionen (muss = 0)

4) Ziele/Benchmarks (auf das jeweilige Portfolio anpassbar)

AR_gross: 3DS2-Karten - 82-92% (nach BIN/Land), A2A - 90% + (Initiation), Gutscheine - 95% + (Redeem).
Capture_Success: 98. 5% + (bei Live-Webhooks und Retrays).
TtC p95: ≤ 5 Minuten (Karten mit Auto-Capture), ≤ 90 Sekunden (Instant A2A/RTP).
Refund Error: < 0. 3%; TtR p95: ≤ T + 1 Bank. Tag (Karten), ≤ 60 Sekunden (Instant Rails).
Refund_to_Source%: ≥ 95% (wo die Schienen stützen).
Idempotency Incidents: = 0; Webhook SLA: ≥ 99. 9%, p95 < 3 c.

(Keine „Markt-Benchmarks“, sondern praktische Zielkorridore für interne SLOs.)

5) Segmentierung und Attribution

Betrachten Sie die KPI im Schnitt: 'country', 'method _ group', 'provider', 'BIN', 'device/os', 'ticket _ size', 'risk _ segment', 'kyc _ tier', 'affiliate', 'new _ vs _ returning'.

Cohort AR: AR nach Erstbezahlerkohorten (D0/D7/D30).
Route AR: AR auf den Routen „PSP_A→PSP_B failover“.
Risk-aware AR: AR nach Risikosegmenten (nach Step-up).
BIN-heatmap: Anfällige Emittenten → separate Retray-/3DS-Regeln.

6) Datenmodell (flache Schicht für BI)

Minimale "Event-Flat':


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

Der Schlüssel ist der idempotente' payment _ key 'auf der Bühne und' idempotency _ key 'auf dem refund.

7) SQL-Schnitte (Beispiel)

7. 1 Tägliche AR und Capture

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 Gesundheit

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 Reibung

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 (erforderliche Widgets)

1. Funnel: Attempt → Auth → Capture (in absoluten Zahlen und Konvertierungen).
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. Kosten/GGR: nach Methoden und Anbietern.
7. Warnungen Panel: Top-Fehlercodes, AR/Latenz Degradation.

9) SLO, Alerts und Playbooks

SLO/Alerta (Beispiel):

'AR_gross↓> 3 pp. zum 7-Tage-Median' → ALERT P1 (überprüfen BIN/Provider/ASN).
"Capture _ Success <98% (hours)" oder "Webhook p95> 5 c' → ALERT P1 (Retrays/Incident bei PSP).
'TtR _ p95> target' für Instant → ALERT P2-Methoden (Warteschlange/Limits überprüfen).
`Refund_Error_Rate > 0. 5% "oder" Double _ Refund> 0 "→ ALERT P0 (Einfrieren automatischer Refands, manuelle Überprüfung).

Playbooks:

BIN-Degradation: Aktivieren Sie einen alternativen Acquirer, erhöhen Sie den Anteil der 3DS-challenge für BIN, Retrays mit „ECI“ -Parametern.
System Soft Declines: Smart Routing → PSP_B, begrenzen Sie die Wiederholung auf N, ändern Sie die 3DS-Richtlinie.
Capture Verzögerungen: Force Retrai, Überprüfung der Unterzeichnung von Webhooks, erhöhte TTL Idempotenz.
Refund-Fehler: Aktivieren Sie idempotente Schlüssel, beschränken Sie parallele partielle Refund, manuelle QA auf Duplikate.

10) Risiko- und Compliance-Management in KPIs

Melden Sie AR_clean nach dem Entfernen von 'Fraud _ Preblocked' und 'Abandon _ 3DS' ist Ihr operatives AR, mischen Sie nicht mit dem Anti-Fraud-Effekt.
Refund_to_Source% - ein wichtiger regulatorischer KPI; Ausnahmen als comp-approved festlegen.
Dispute/Chargeback Rate an captured_amount binden, nicht an Versuche.

11) Häufige Fehler

Summieren Sie verschiedene Basen (attempt vs auth vs capture) in einem einzigen Anteil.
Keine Segmentierung durch 'ticket _ size' → falsche Schlussfolgerungen über AR.
Nicht berücksichtigt „User Abandon“ auf 3DS → „künstlich“ niedrige AR.
Keine' idempotency _ key 'auf refund → takes/finanzielle Verluste.
Mischung aus Auszahlung und Refund in einer TtW/TtR-Metrik.

12) Checkliste zur Umsetzung

Konsistentes Ereignisschema und einheitliche KPI-Definitionen.
Heatmap nach BIN/Land und Routing nach Provider.
Dashboard 3DS-Friktion und Abandon.
SLA von Webhooks, Retrays, Idempotenz (auth/capture/refund).
Berichte über Refund Health und Refund_to_Source%.
Alerts auf den Abbau von AR, Capture_Success, TtR, refund Fehler.
Monatliche R & O-Bewertung: Kosten/GGR, Disputes, FX-Spreads, Provider-SLA.

13) Zusammenfassung

Ein starker Zahlungskreislauf ist ein transparenter Trichter mit der richtigen Basis für jeden Anteil, eine strenge Disziplin von Ereignissen, Segmentierung und automatische Playbooks. Richtig KPI wandeln die Zahlungsinfrastruktur in den Hebel der Größe um: AR_net ↑, TtC/TtR ↓, Cost/GGR ↓, Disputes ↓, bei der unveränderlichen oder verbesserten Sicherheit.