Дашборд платіжних KPI
TL; DR
Один дашборд - три шари: Здоров'я воронки (Attempt→Auth→Capture), Фінансова ефективність (TtW/TtR, Cost/GGR, FX) і Надійність інфраструктури (Webhook/Latency/Settlement). Секрет - коректні бази розрахунку, обов'язкова сегментація (country × provider × method × BIN × ticket _ size × risk), порогові SLO і готові плейбуки при виході за коридори.
1) Для кого і які питання закриваємо
CEO/GM (щодня, 3-5 хв): "Конверсія платежів і швидкість висновків в нормі? Вартість прийому грошей під контролем?"
Head of Payments/Treasury (щогодини): "Де деградація по провайдеру/країні/методу? Чи вистачає ліквідності для миттєвих виплат?"
Fraud/Risk (щодня): "AR з урахуванням антифроду? Abandon на 3DS и Soft declines?»
Support/Operations (онлайн): "Який ETA з виведення і повернення? Де зависли вебхуки?"
Finance/Recon (D+1): "Settlement вчасно? Комісії та FX відповідають плану?"
2) Головні метрики і точні визначення
2. 1 Воронка платежів
Attempt - ініційовані платежі.
Auth Approved - схвалені авторизації.
Captured - успішно списані.
- `AR_gross = Auth_Approved / Auth_Attempted`
- `AR_net = Captured_Tx / Auth_Attempted`
- `Capture_Success = Captured_Tx / Capture_Attempted_Tx`
- `Capture_Latency_p95 = p95(capture_ts - auth_ts)`
2. 2 Висновки та повернення
Payout Success % = Success_Payouts / Attempted_Payouts
TtW p95 = p95(payout_credited_at - payout_initiated_at)
Refund Rate = Refunded_Tx / Captured_Tx
TtR p95 = p95(refund_credit_at - refund_initiated_at)
Refund Error % = Refund_Failed / Refund_Attempted
Refund_to_Source% - частка повернень на вихідний метод
2. 3 Вартість і FX
Cost/Tx = Fee_fixed + AmountFee_pct + FX_Spread
Cost/GGR = ΣCost / GGR
FX Slippage (bps) = (exec_px − mid_px)/mid_px × 10 000
2. 4 Надійність інтеграцій
Webhook Delivery p95 (сек), Success %
API Latency p95/p99 (auth/capture/refund/payout)
Settlement Timeliness = батчі, що прийшли в заявлений T + N/всі батчі за період
2. 5 3DS/фрикція (для карт)
3DS Challenge Share = Challenge / 3DS_Total
Frictionless Share = Frictionless / 3DS_Total
Abandon on 3DS = 3DS_Started − 3DS_Completed
3) Розрізи і фільтри (мінімальний набір)
Фільтри в шапці: `date range (UTC)`, `country`, `provider`, `method_group`, `BIN`, `device/os`, `ticket_size bucket (≤€50 / €50–200 / >€200)`, `risk_segment`, `kyc_tier`, `new_vs_returning`, `affiliate`.
Обов'язкові розрізи в графіках/таблицях:- country×provider, BIN×country, method×provider, device/os, ticket_size.
4) Розмітка головного екрану (Layout)
1. Верхня плашка KPI (за вчора/сьогодні, порівняння до p7 медіани):
`AR_net`, `Capture_Success`, `Payout Success%`, `TtW p95`, `TtR p95`, `Cost/GGR`, `Webhook p95`, `Settlement Timeliness`.
2. Funnel (Attempt→Auth→Capture) з вибором сегмента і відображенням причин відмов (топ-коди ISO/на рейках).
3. Heatmap AR по'country × provider'і окрема BIN heatmap для топ-обсягу.
4. 3DS панель: Challenge/Frictionless/Abandon + порівняння до бенч-лінії.
5. Payout & Refund Health: Success%, p95 (TtW/TtR), помилки, Refund_to_Source%.
6. Cost & FX: Cost/GGR за методами, FX slippage/fees за майданчиками.
7. Інтеграційна надійність: Webhook delivery p95/Success%, API latency p95/p99, Duplicate rate, Report delivery SLA.
8. Інцидент-панель: активні альберти (див. § 8), статус фейловерів і замітки казначейства (залишки L0, prefund).
5) SLO та алерти (коридори)
Орієнтири (під портфель/ринки калібруються):- 'AR _ gross'карти 3DS2: 82-92% (за сегментом);'AR _ net'≥ 80%
- `Capture_Success` ≥ 98. 5% (годинниковий)
- `Webhook p95` ≤ 3 с, Success ≥ 99. 9%
- `Payout TtW p95` instant ≤ 120 с; (T + 1) - 100% на день D + 1
- 'Refund TtR p95'карти ≤ T + 1 б.д.; instant ≤ 60 с
- `Refund Error %` < 0. 3%
- `Settlement Timeliness` ≥ 99%
- 'Cost/GGR'- індивідуальний цільовий коридор за методом
- 'AR_gross↓> 3 п.п.'до 7-денної медіани (по країні/PSP/BIN) → P1/P0
- `Capture_Success < 98%` (час) → P1
- 'Webhook p95> 5 c'або дублікати> 0 → P1
- `Payout TtW p95 > SLO` или Success%<99% → P1
- `Refund Error% > 0. 3%` или `Double Refund > 0` → P0
- `Settlement on-time < 99%` → P1
- 'Cost/GGR'вихід за коридор за методом → P2
Кожен алерт відкриває картку runbook'a (дії/ескалації/фейловер).
6) Формули і бази розрахунку (деталізація)
Всі частки - з явною базою: вказуйте в тултипі «denominator».
Часи - в UTC; p-квантилі: PERCENTILE_CONT.
'AR _ clean'( операційний) ='Auth _ Approved/( )'
`Net_Conversion` = `Captured_Tx / Auth_Attempted_Tx`
`Refund_to_Source %` = `Refund_to_Original_Method / Total_Refunds`
'Idle Cash%'( в казначейському міні-віджеті) ='( Balance − Target_Balance )/Balance'
7) UX-патерни
Зверху KPI-плашка, нижче - funnel + heatmaps, внизу - інтеграції та фінанси.
Тултипи з формулою/базою/винятками (наприклад, «після антифроду»).
Порівняльна лінія: p7 медіана і «вчора «/» минулий понеділок ».
Drill-down по кліку: з heatmap на таблицю BIN→Issuer→kody відмов.
Снепшоти для RCA: кнопка «закріпити» поточний вигляд для пост-мортема.
8) Плейбуки (вбудовані картки дій)
Auth drop → перемкнути smart-routing, підняти 3DS-challenge на BIN, обмежити ретраї.
Webhook затримки → включити polling, заморозити авто-рефанди/небезпечні авто-виплати, посилити ідемпотентність.
Payout деградація → фейловер рейки, treasury top-up, пріоритизація VIP.
Settlement затримка → StressRes, позначка «Suspense», ескалація в PSP.
Refund помилки/дублі → refund-freeze, звірка, сторно дублів.
(Картка містить чек-лист і контакти ескалації.)
9) Модель даних (мінімально достатня)
events/payments_flat:
payment_id, user_id, country, provider, method_code, action(deposit/refund/payout),
attempt_ts, auth_status, auth_ts, three_ds(flow, challenge_flag, started_ts, completed_ts),
capture_status, capture_amount, capture_ts, partial_flag,
refund_status, refund_amount, refund_initiated_ts, refund_credit_ts,
payout_status, payout_amount, payout_initiated_ts, payout_credited_ts,
fees_fixed, fees_pct, fx_spread, currency, amount,
risk_segment, kyc_tier, bin, asn, device_os, ticket_bucket
events/webhooks:
provider, event_kind, event_ts, delivered_ts, retries, duplicate_flag, idempotency_key
settlements/reports:
provider, batch_id, settlement_date, amount_settled, currency, fee_amount, status
treasury/pockets (mini-widget):
pocket_id, counterparty, currency, balance, target_balance, low_watermark, updated_atІндекси: по `provider`, `method_code`, `country`, `bin`, `event_ts`.
10) SQL-зрізи (приклад)
10. 1 Воронка і AR
sql
WITH base AS (
SELECT
DATE_TRUNC('hour', attempt_ts) AS h,
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 h, 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;10. 2 Webhook SLA
sql
SELECT
DATE_TRUNC('hour', event_ts) AS h, provider,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (delivered_ts - event_ts))) AS wb_p95_sec,
AVG(CASE WHEN retries=0 AND NOT duplicate_flag THEN 1 ELSE 0 END) AS wb_success
FROM webhooks
GROUP BY 1,2;10. 3 Refund & Payout Health
sql
SELECT
DATE_TRUNC('day', COALESCE(refund_initiated_ts, payout_initiated_ts)) d,
method_code, provider,
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,
COUNT() FILTER (WHERE payout_status='ATTEMPTED') AS payout_attempted,
COUNT() FILTER (WHERE payout_status='SUCCESS') AS payout_success,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (payout_credited_ts - payout_initiated_ts))) AS ttw_p95_sec
FROM payments_flat
GROUP BY 1,2,3;10. 4 Cost/GGR
sql
SELECT
DATE_TRUNC('day', capture_ts) d,
method_code, provider,
SUM(fees_fixed + amountfees_pct + fx_spread) AS total_cost,
SUM(capture_amount) AS total_captured,
(SUM(fees_fixed + amountfees_pct + fx_spread) / NULLIF(SUM(total_captured),0)) AS cost_to_captured
FROM payments_flat
WHERE capture_status='CAPTURED'
GROUP BY 1,2,3;11) Додаткові екрани
BIN Drilldown: AR/decline-codes, 3DS-фрикція, latency за емітентами.
Provider Scorecard: SLA-метрики, інциденти, кредити, Cost/GGR.
Treasury Snapshot: L0/L1 залишки, prefund, StressRes, TtF поповнень.
Recon View: Settlement Timeliness, Aging не зшитих батчів, Fee accuracy.
12) Якість даних i治理
Словник KPI з версіонуванням (формули/база/винятки).
Єдина TZ = UTC, p-квантилі - тільки CONT.
Ідемпотентність подій і дедуп вебхуків.
Політика толерансів за часом/сумами/FX (для звірки/латентності).
Data tests в CI: непусті бази дільників, монотонність часових міток, частка NULL.
13) Впровадження: чек-лист
- Визначені KPI/формули/бази і зафіксовані в словнику.
- Налаштований ingestion і нормалізація подій/реєстрів.
- Побудовані вітрини'payments _ flat','webhooks','settlements','treasury'.
- Реалізовані heatmaps, funnel, latency, payout/refund panels.
- Заведені пороги SLO і алерти; пов'язані з плейбуками.
- Ролі доступу: C-level (read-only summary), Ops/Fraud (drill-down).
- Щотижневий QBR по провайдерам на основі Provider Scorecard.
- UAT-набір тестів: демо-датасет, перевірка p-квантилів, коректність баз, алертів.
14) Часті помилки
Змішування баз ('attempt'vs'capture') → помилкові висновки.
Немає сегментації'ticket _ size'→ спотворена картина AR.
Ігнор abandon на 3DS → «завищена» проблема з провайдером.
Відсутність контролю webhook duplicates → подвійні дії.
Неповна вітрина по settlement/fees → неможливо оцінити Cost/GGR.
Без SLO і плейбуків дашборд перетворюється на «вітрину без дій».
Резюме
Дашборд платіжних KPI - це операційний інструмент, а не просто графіки. Він з'єднує воронку, гроші та інфраструктуру, спирається на чіткі формули і сегментацію, дає автоматичні сигнали і відразу пропонує дії. В результаті: AR_net вище, TtW/TtR в коридорах, Cost/GGR під контролем, інциденти локалізуються швидко, а діалог з провайдерами будується на цифрах.