支付回路KPI： auth, capture, refund

TL;DR

支付回路的尺寸為漏鬥：「Attempt → Auth → Capture → Settle/Refund」。關鍵指標不僅是Approval Rate，而且是純AR（在防凍劑和3 DS之後），捕獲成功，註銷/入賬前時間，成本/FX，冪等誤差和回報質量（TtR和rate）。擁有AR↑的人獲勝，TtW↓，Cost/GGR↓，Disputes↓，不打破風險形象。

1）階段和事件詞典

Attempt-嘗試付款（啟動）。
Auth-授權（銀行/錢包/鐵路確認了註銷的可能性）。
捕獲-實際註銷（完整/部分）。
定位-清算和結算。
退款-退款（完整/部分），「TtR=退款時間」。
Void-取消捕獲（如果支持）。
3DS/Step-up是授權摩擦。
Soft Decline/Hard Decline-可恢復/不可恢復的故障。

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

2） KPI層次結構（目標樹）

上層

Gross Approval Rate (AR_gross) = Auth/Attempt

Net Approval Rate (AR_net) = Captured/Attempt

Cost/GGR = (Fees + FX + Ops)/GGR

TTW/TtC： 時間到錢包（結論），TtC（捕獲）p95

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

平均水平

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

軟解鎖恢復率（轉發/智能路由）

Partial Capture Share, Capture Latency

Refund to Source %, Duplicate/Idempotency Incidents

下層（診斷）

代碼錯誤（ISO/導軌），API潛伏期p95，webhook SLA，「Do Not Honor」份額，「Insufficient Funds」，「Suspected Fraud」和「System Error」。

3）公式（精確定義）

3.1個授權

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

切口必須是：「BIN ×國家」，「provider × method」，「device/os」，「ticket_size」（例如，≤€50，50-200歐元，>200歐元）。

3.2註銷（捕獲）

`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成本和FX

`Cost_per_Tx = Fee_fixed + AmountFee_pct + FX_Spread`

`Cost/GGR = ΣCost / GGR`

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

3.4退款（退款）

`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」-偶數沖突計數器（必須=0）

4）目標/基準（針對特定產品組合進行調整）

AR_gross：3DS2卡-82-92％（根據BIN/國家/地區），A2A-90％+（啟動），憑證-95％+（redeem）。
Capture_Success: 98.5%+（使用實時網絡和靜止）。
TtC p95： ≤ 5分鐘（自動捕獲卡），≤ 90秒（instant A2A/RTP）。
Refund Error: < 0.3%;TtR p95：≤ T+1銀行。每天（地圖），≤ 60秒（instant rails）。
Refund_to_Source%：≥ 95%（鐵路支持的地方）。

Idempotency Incidents: = 0;Webhook SLA: ≥ 99.9%, p95 < 3 c.

（不是「市場基準」，而是內部SLO的實用目標走廊。）

5）分割和歸屬

從以下方面考慮KPI：「鄉村」，「method_group」，「provider」，「BIN」，「device/os」，「ticket_size」，「risk_segment」，「kyc_tier」，「附屬」，「new_vs_returning」。

Cohort AR：第一付費隊列（D0/D7/D30）的AR。
AR路線：沿「PSP_A→PSP_B失敗」路線行駛的AR。
Risk-aware AR：按風險細分市場劃分的AR（步入式之後）。
BIN-heatmap：易受攻擊的發行人→ 單獨的撤回/3 DS規則。

6）數據模型（用於BI的平面層）

最小「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

關鍵是每個階段的「payment_key」和refund的「idempotency_key」。

7） SQL切片（示例）

7.1每日AR和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健康

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 3 DS摩擦

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）Dashbord（強制性小部件）

1.Funnel：Attempt → Auth → Capture（絕對和轉換）。

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.費用/GGR：按方法和提供商。
7.Alerts面板：頂級故障代碼，AR/latency降解。

9）SLO，Alerta和花花公子

SLO/Alerta（示例）：

"AR_gross↓> 3個百分點到7天的中位數'→ ALERT P1（檢查BIN/提供商/ASN）。
「Capture_Success <98％（小時）」或「Webhook p 95>5 c」 → ALERT P1（PSP的轉播/事件）。
「TtR_p95>目標」關於instant → ALERT P2方法（檢查隊列/限制）。
`Refund_Error_Rate > 0.5%'或'Double_Refund> 0' → ALERT P0（自動反射凍結,手動檢查）。

花花公子：

BIN降解：包括替代購買者，增加BIN的3DS-challenge份額，帶有「ECI」參數的後繼。
系統Soft Declines：智能路由→ PSP_B,將重播限制為N,更改3 DS策略。
捕獲延遲：fors-retrai，webhook簽名驗證，TTL相等性增加。
Refund錯誤：啟用等效鍵,限制並行部分還原,手動QA重復。

10）在KPI中管理風險和合規性

在刪除「Fraud_Preblocked」和「Abandon_3 DS」後責備AR_clean是您的操作AR，不要與防凍效果混合。
Refund_to_Source％-關鍵監管機構KPI；將異常捕獲為comp-approved。
Dispute/Chargeback Rate綁定到captured_amount而不是嘗試。

11）常見錯誤

將不同的基數（attempt vs auth vs capture）加成一個比例。
缺少「ticket_size」分段→ AR的錯誤推斷。
不考慮3 DS上的「User Abandon」 →「人為」低AR。
refund上沒有「idempotency_key」 →雙打/財務損失。
在單個TtW/TtR度量中混合付費和捐贈。

12）實施控制清單

統一事件圖和統一的KPI定義。
Heatmap通過BIN/國家/地區,並通過提供商路由。
Dashbord 3 DS摩擦和abandon。
SLA webhook, retrai,等效性（auth/capture/refund）。
Refund Health報告和Refund_to_Source％。
Alerta對AR降解，Capture_Success，TtR，refund錯誤。
月度R&O評論：成本、GGR、Disputes、FX利差、SLA提供商。

13）摘要

強大的支付回路是一個透明的漏鬥，每個份額都有正確的基礎，嚴格的事件紀律，細分和自動花花公子。正確的KPI使支付基礎設施成為增長杠桿：，，，安全性保持不變或得到改善。