Дашборд платежных 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’а (действия/эскалации/фейловер).
6) Формулы и базы расчета (детализация)
Все доли — с явной базой: указывайте в тултипе `denominator`.
Времена — в UTC; p-квантили: PERCENTILE_CONT.
`AR_clean` (операционный) = `Auth_Approved / (Auth_Attempted − Fraud_Preblocked − Abandon_3DS)`
`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→коды отказов.
Снэпшоты для 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) Качество данных и治理
Словарь 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 под контролем, инциденты локализуются быстро, а диалог с провайдерами строится на цифрах.