支付回路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使支付基础设施成为增长杠杆：，，，安全性保持不变或得到改善。