KPI платежного контура: auth, capture, refund

TL;DR

Платежный контур измеряется как воронка: `Attempt → Auth → Capture → Settle/Refund`. Ключевые метрики — не только Approval Rate, но и чистые AR (после антифрода и 3DS), успешность capture, время до списания/зачисления, стоимость/FX, ошибки идемпотентности и качество возвратов (TtR и rate). Побеждает тот, кто держит AR↑, TtW↓, Cost/GGR↓, Disputes↓, не ломая риск-профиль.

1) Словарь стадий и событий

Attempt — попытка платежа (инициация).
Auth — авторизация (банк/кошелек/рельсы подтвердили возможность списания).
Capture — фактическое списание (полное/частичное).
Settle — клиринг и расчеты.
Refund — возврат (полный/частичный), `TtR = time to refund credit`.
Void — отмена до capture (если поддерживается).
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: Time-to-Wallet (выводы), TtC (capture) p95

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

Средний уровень

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

Soft Decline Recovery Rate (ретраи/смарт-роутинг)

Partial Capture Share, Capture Latency

Refund to Source %, Duplicate/Idempotency Incidents

Нижний уровень (диагностика)

Ошибки по кодам (ISO/рельсовые), p95 латентности API, 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×country`, `provider×method`, `device/os`, `ticket_size` (например, ≤€50, €50–200, >€200).

3.2 Списания (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 Стоимость и 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)

`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 мин (карты с авто-capture), ≤ 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 в разрезе: `country`, `method_group`, `provider`, `BIN`, `device/os`, `ticket_size`, `risk_segment`, `kyc_tier`, `affiliate`, `new_vs_returning`.

Cohort AR: AR по когортам первой оплаты (D0/D7/D30).
Route AR: AR по маршрутам `PSP_A→PSP_B failover`.
Risk-aware AR: AR по сегментам риска (после step-up).
BIN-heatmap: уязвимые эмитенты → отдельные правила ретраев/3DS.

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` на стадию и `idempotency_key` на refund.

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 3DS фрикция

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) Дашборд (обязательные виджеты)

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. Cost/GGR: по методам и провайдерам.
7. Alerts panel: топ-коды отказов, деградации AR/latency.

9) SLO, алерты и плейбуки

SLO/Алерты (пример):

`AR_gross↓ > 3 п.п. к 7-дневной медиане` → ALERT P1 (проверить BIN/провайдера/ASN).
`Capture_Success < 98% (часовой)` или `Webhook p95 > 5 c` → ALERT P1 (ретраи/инцидент у PSP).
`TtR_p95 > целевого` по методам instant → ALERT P2 (проверить очередь/лимиты).
`Refund_Error_Rate > 0.5%` или `Double_Refund > 0` → ALERT P0 (заморозка автоматических рефандов, ручная проверка).

Плейбуки:

BIN-деградация: включить альтернативного эквайера, повысить долю 3DS-challenge для BIN, ретраи с `ECI` параметрами.
Системные Soft Declines: смарт-роутинг → PSP_B, лимитировать повтор до N, изменить 3DS-политику.
Задержки capture: форс-ретраи, проверка подписания вебхуков, увеличенный TTL идемпотентности.
Ошибки refund: включить идемпотентные ключи, ограничить параллельные partial-refund, ручной QA на дубликаты.

10) Управление риском и комплаенсом в KPI

Отчитывайте AR_clean после удаления `Fraud_Preblocked` и `Abandon_3DS` — это ваш операционный AR, не смешивайте с эффектом антифрода.
Refund_to_Source % — ключевой регуляторный KPI; исключения фиксируйте как comp-approved.
Dispute/Chargeback Rate привязывайте к captured_amount, а не к попыткам.

11) Частые ошибки

Суммирование разных баз (attempt vs auth vs capture) в одной доле.
Отсутствие сегментации по `ticket_size` → ложные выводы по AR.
Неучет `User Abandon` на 3DS → «искусственно» низкий AR.
Нет `idempotency_key` на refund → дубли/финансовые потери.
Смешение payout и refund в одной метрике TtW/TtR.

12) Контрольный чек-лист внедрения

Согласованная схема событий и единые определения KPI.
Heatmap по BIN/странам и маршрутизация по провайдерам.
Дашборд 3DS-фрикции и abandon.
SLA вебхуков, ретраи, идемпотентность (auth/capture/refund).
Отчетность по Refund Health и Refund_to_Source %.
Алерты на деградацию AR, Capture_Success, TtR, ошибки refund.
Месячный R&O-обзор: Cost/GGR, Disputes, FX-спреды, провайдер-SLA.

13) Резюме

Сильный платежный контур — это прозрачная воронка с корректной базой для каждой доли, жесткая дисциплина событий, сегментация и автоматические плейбуки. Правильные KPI превращают платежную инфраструктуру в рычаг роста: AR_net↑, TtC/TtR↓, Cost/GGR↓, Disputes↓, при неизменной или улучшенной безопасности.