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

TL; DR

Платіжний контур вимірюється як воронка: `Attempt → Auth → Capture → Settle/Refund`. Ключові метрики - не тільки Approval Rate, але і чисті AR (після антифроду і 3DS), успішність capture, час до списання/зарахування, вартість/FX, помилки ідемпотентності і якість повернень (TtR і rate). Перемагає той, хто тримає , , , не ламаючи ризик-профіль.

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 перетворюють платіжну інфраструктуру в важіль зростання: , , , при незмінній або поліпшеній безпеці.