Dashboard KPI de pagamento

TL; DR

Um dashboard - três camadas: Saúde Vórtex (Attempt→Auth→Capture), Eficiência Financeira (TtW/TtR, Costa/GGR, FX) e Confiabilidade da Infraestrutura (Webhook/Latency/Masslement). O segredo é base de cálculo correta, segmentação obrigatória (country x provider x method x BIN x jet _ size x risk), liminares SLO e playbooks prontos ao sair dos corredores.

1) Para quem e quais questões encerramos

CEO/GM (diariamente, 3-5 min): "Conversão de pagamentos e velocidade de conclusão normal? O valor do dinheiro está sob controlo?"

Head of Payments/Treasury (cada hora): "Onde está a degradação por provedor/país/método? Será que há liquidez suficiente para pagamentos instantâneos?"

Fraud/Risk (diariamente): "AR com antifrode? Abandon на 3DS и Soft declines?»

Suporte/Operations (online): "Qual ETA para retirada e retorno? Onde estão os webhooks?

Finance/Recon (D + 1): "Senslement a tempo? A Comissão e a FX estão de acordo com o plano?"

2) Métricas principais e definições precisas

2. 1 Vórtice de pagamento

Attempt - pagamentos iniciados.
Auth Approved - Autorizações aprovadas.
Captured - Descartado com sucesso.

• `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 Conclusões e devoluções

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 _ Fonte% - Proporção de retorno ao método original

2. 3 Custo e 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 Confiabilidade das integrações

Webhook Delivery p95 (сек), Success %

API Latency p95/p99 (auth/capture/refund/payout)

Senslement Timeliness = batches que apareceram no T + N/todos os batches durante o período

2. 5 3DS/fricção (para cartões)

3DS Challenge Share = Challenge / 3DS_Total

Frictionless Share = Frictionless / 3DS_Total

Abandon on 3DS = 3DS_Started − 3DS_Completed

3) Cortes e filtros (conjunto mínimo)

Фильтры в шапке: `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) Sinalização da tela principal (Layout)

1. Página KPI superior (ontem/hoje, comparação para p7 mediana):

`AR_net`, `Capture_Success`, `Payout Success%`, `TtW p95`, `TtR p95`, `Cost/GGR`, `Webhook p95`, `Settlement Timeliness`.

2. Funnel (Attempt→Auth→Capture) com a seleção do segmento e a exibição das causas de falhas (códigos top ISO/sobre trilhos).

3. Heatmap AR por 'country x provider' e um heatmap BIN separado para o volume top.

4. painel 3DS: Challenge/Frictionless/Abandon + comparação com uma linha bench.

5. Payout & Refund Health: Success%, p95 (TtW/TtR), ошибки, Refund_to_Source %.

6. Costa & FX: Costa/GGR por métodos, FX slippage/fees por local.

7. Confiabilidade de integração: Webhook delivery p95/Sucess%, API latency p95/p99, Duplicate rate, Relatório delivery SLA.

8. Painel de ocorrência: alertas ativas (consult. 8), status de feelowers e notas do Tesouro (sobras L0, prefund).

5) SLO e alertas (corredores)

• 'AR _ gross' cartões 3DS2: 82-92% (por segmento); 'AR _ net' ≥ 80%
• `Capture_Success` ≥ 98. 5% (horário)
• `Webhook p95` ≤ 3 с, Success ≥ 99. 9%
• `Payout TtW p95` instant ≤ 120 с; (T + 1) - 100% por dia D + 1
• 'Refund TtR p95' cartões ≤ T + 1 b.d.; instant ≤ 60 с
• `Refund Error %` < 0. 3%
• `Settlement Timeliness` ≥ 99%
• 'Costa/GGR' - corredor de destino individual pelo método

• 'AR_gross↓> 3 p.p' para a mediana de 7 dias (país/PSP/BIN) → P1/P0
• `Capture_Success < 98%` (час) → P1
• 'Webhook p95> 5 c' ou duplicados> 0 → P1
• `Payout TtW p95 > SLO` или Success%<99% → P1
• `Refund Error% > 0. 3%` или `Double Refund > 0` → P0
• `Settlement on-time < 99%` → P1
• 'Costa/GGR' para sair do corredor através do método → P2

Cada alert abre o cartão de runbook 'a (ação/escalação/feelover).

6) Fórmulas e bases de cálculo (detalhe)

Todas as participações são de base explícita: especifique no tultipo 'denominator'.
Tempos em UTC; p-quantili: 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%' (em mini-widget do Tesouro = '(Balanceamento/Balança)

7) Pattern UX

Acima KPI, abaixo - funno + heatmaps, abaixo - integração e finanças.
Tultipes com fórmula/base/exceções (por exemplo, «após antifrode»).
Linha de comparação: p7 mediana e «ontem «/» segunda-feira passada ».
Drill-down por clique: de heatmap para tabela BIN→Issuer→kody falhas.
Snapshots para RCA: botão «fixar» a vista atual para o pós-mortem.

8) Playbooks (cartões de ação incorporados)

Auth drop → alternar smart-routing, elevar 3DS-challenge para BIN, limitar retraí.
Webhook atrasos → incluir polling, congelar carros refanda/pagamentos de carros perigosos, aumentar a idempotação.
Payout degradação → feelover de trilho, treasury top-up, priorizar VIP.
Senslement atraso → StressRes, marca «Suspense», escalação em PSP.
Refund erros/duplicações → refund-freeze, confecção, dublagem estonteante.

(O cartão contém folha de cheque e contatos de escalação.)

9) Modelo de dados (mínimo suficiente)

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

Índices: 'provider', 'method _ código', 'country', 'bin', 'event _ ts'.

10) cortes SQL (exemplo)

10. 1 Vórtice e 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) Telas adicionais

BIN Drilldown: AR/decline-codes, fricção 3DS, latency por emissores.
Provider Scorecard: Métricas SLA, Incidentes, Empréstimos, Costa/GGR.
Treasury Snapshot: L0/L1 sobras, prefund, StressRes, TtF de reposição.
Recon View: Senslement Timeliness, Aging não costurado batches, Fee accuracy.

12) Qualidade dos dados i治理

Dicionário KPI versionizado (fórmulas/base/exceções).
TZ único = UTC, p-quantili - apenas CONT.
Idempotidade dos acontecimentos e dedupo dos webhooks.
Política de tempo/soma/FX (para confecção/latência).
Data tests em CI: bases de divisores impróprias, monotonia de marcas de tempo, participação NULL.

13) Implantação: folha de cheque

• Os KPI/fórmulas/base foram definidos e estão registrados no dicionário.
• Configurou o investimento e normaliza os eventos/registros.
• Foram construídas vitrines de 'payments _ flat', 'webhooks', 'senslents', 'treasury'.
• Implementados heatmaps, funnel, latency, payout/refund panels.
• As liminares do SLO e da alerta estão estabelecidas; estão associados a playbooks.
• Papéis de acesso: C-level (read-only summary), Ops/Fraud (drill-down).
• QBR semanal para provedores baseados no Provider Scorecard.
• Conjunto UAT de testes: dataset demo, verificação de p-quanteis, correção de bases, alertas.

14) Erros frequentes

A mistura de bases ('attempt' vs' capture ') → conclusões falsas.
Não há segmentação de 'jet _ size' → quadro de AR distorcido.
Ignorar abandon em 3DS → um problema «exagerado» com o provedor.
A falta de controle do webhook duplicates → ações duplas.
Vitrine incompleta por senslement/fees → não é possível estimar a Costa/GGR.
Sem SLO e playbooks, o dashboard torna-se uma «vitrine sem ação».

Currículo

Dashboard KPI de pagamento é uma ferramenta operacional, não apenas gráficos. Ele conecta vórtice, dinheiro e infraestrutura, baseia-se em fórmulas claras e segmentação, dá sinais automáticos e oferece ações imediatas. Como consequência: AR _ net acima, nos corredores, a Costa/GGR sob controle, os incidentes são localizados rapidamente e o diálogo com os provedores é baseado em números.