Dashboard KPI de pago

TL; DR

Un dashboard - tres capas: Salud del embudo (Attempt→Auth→Capture), Eficiencia financiera (TtW/TtR, Costo/GGR, FX) y Fiabilidad de la infraestructura (Webhook/Latency/Settlement). El secreto son las bases de cálculo correctas, la segmentación obligatoria (country × provider × method × BIN × ticket _ size × risk), los umbrales SLO y los playbooks listos al salir de los pasillos.

1) Para quién y qué preguntas cerramos

CEO/GM (diario, 3-5 min): "¿La conversión de pagos y la velocidad de los retiros son normales? ¿El costo de tomar el dinero bajo control?"

Head of Payments/Treasury (cada hora): "¿Dónde está la degradación por proveedor/país/método? ¿Hay liquidez suficiente para los pagos instantáneos?"

Fraud/Risk (diario): "¿AR teniendo en cuenta el antifraude? Abandon на 3DS и Soft declines?»

Apoyo/Operaciones (online): "¿Qué ETA por retirada y devolución? ¿Dónde están los webhooks?"

Finance/Recon (D + 1): "¿Settlement a tiempo? ¿Las Comisiones y FX están en línea con el plan?"

2) Métricas principales y definiciones precisas

2. 1 Embudo de pago

Attempt - pagos iniciados.
Auth Approved - autorizaciones aprobadas.
Captured - cancelado correctamente.

• `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 Conclusiones y devoluciones

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% - porcentaje de devoluciones al método original

2. 3 Costo y 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 Fiabilidad de las integraciones

Webhook Delivery p95 (сек), Success %

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

Settlement Timeliness = batches que llegaron a T + N/todos los batches declarados durante el período

2. 5 3DS/fricción (para tarjetas)

3DS Challenge Share = Challenge / 3DS_Total

Frictionless Share = Frictionless / 3DS_Total

Abandon on 3DS = 3DS_Started − 3DS_Completed

3) Cortes y 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) Marca de la pantalla de inicio (Layout)

1. Troquel superior del KPI (para ayer/hoy, comparación a la mediana p7):

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

2. Funnel (Attempt→Auth→Capture) con selección de segmentos y visualización de las causas de fallas (códigos ISO superiores/en raíles).

3. Heatmap AR por 'country × provider' y un BIN heatmap separado para el volumen superior.

4. Panel 3DS: Desafío/Frictionless/Abandon + comparación a la línea de bench.

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

6. Costo & FX: Costo/GGR por método, FX slippage/fees por sitio.

7. Fiabilidad de integración: Webhook delivery p95/Success%, API latency p95/p99, Duplicate rate, Report delivery SLA.

8. Panel de incidentes: alertas activas (ver § 8), estado de Feilover y notas del Tesoro (saldos L0, Prefund).

5) SLO y alertas (pasillos)

• 'AR _ gross' de la tarjeta 3DS2: 82-92% (por segmento);' AR _ net '≥ 80%
• `Capture_Success` ≥ 98. 5% (hora)
• `Webhook p95` ≤ 3 с, Success ≥ 99. 9%
• `Payout TtW p95` instant ≤ 120 с; (T + 1) - 100% por día D + 1
• 'Refund TtR p95' de la tarjeta ≤ T + 1 b.d.; instant ≤ 60 с
• `Refund Error %` < 0. 3%
• `Settlement Timeliness` ≥ 99%
• 'Costo/GGR' - Corredor de destino personalizado por método

• 'AR_gross↓> 3 p.p.' a la mediana de 7 días (por país/PSP/BIN) → P1/P0
• `Capture_Success < 98%` (час) → P1
• 'Webhook p95> 5 c' o duplicados> 0 → P1
• `Payout TtW p95 > SLO` или Success%<99% → P1
• `Refund Error% > 0. 3%` или `Double Refund > 0` → P0
• `Settlement on-time < 99%` → P1
• 'Costo/GGR' salida por corredor por el método de → P2

Cada alerta abre una tarjeta de runbook 'a (acciones/escaladas/failover).

6) Fórmulas y bases de cálculo (detalle)

Todos los lóbulos son con una base explícita: especifique en el tultipo 'denominator'.
Los tiempos están en UTC; p-cuantili: PERCENTILE_CONT.

' AR_clean ' (de operaciones) = ' 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%' (en mini widget del Tesoro) = '(Balance − Target_Balance )/Balance'

7) Patrones UX

En la parte superior del KPI, debajo de funnel + heatmaps, en la parte inferior están las integraciones y las finanzas.
Tultipos con fórmula/base/excepciones (por ejemplo, «después del antifraude»).
Línea comparativa: p7 mediana y «ayer «/» lunes pasado ».
Drill-down por clic: con heatmap a la tabla de BIN→Issuer→kody de fallos.
Snapshots para RCA: botón para «fijar» la vista actual para el post-mortem.

8) Playbucks (tarjetas de acción incorporadas)

Auth drop → cambiar smart-routing, elevar el 3DS-challenge a BIN, limitar retraídas.
Webhook retardo → encender polling, congelar auto-refundido/auto-pago peligroso, aumentar la idempotencia.
Payout degradación → Feilover rail, treasury top-up, priorización VIP.
Settlement retraso → StressRes, marca «Suspense», escalada en PSP.
Refund errores/tomas → refund-freeze, la conciliación, estorbando las tomas.

(La tarjeta contiene una lista de comprobación y contactos de escalamiento.)

9) Modelo de datos (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: por 'provider', 'method _ code', 'country', 'bin', 'event _ ts'.

10) Cortes SQL (ejemplo)

10. 1 Embudo y 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) Pantallas adicionales

BIN Drilldown: AR/decline-codes, 3DS-fricción, latency por emisor.
Provider Scorecard: métricas de SLA, incidentes, préstamos, Costo/GGR.
Treasury Snapshot: L0/L1 saldos, Prefund, StressRes, TtF reposiciones.
Recon View: Settlement Timeliness, Aging batches no cosidos, Fee accuracy.

12) Calidad de los datos i治理

Diccionario de KPI versionados (fórmulas/base/exclusiones).
Una sola TZ = UTC, p-cuantili - sólo CONT-.
La idempotencia de los eventos y el dedoup de los webhooks.
Política de tolerancias por tiempo/sumas/FX (para conciliación/latencia).
Pruebas de datos en CI: bases de divisores no vacías, monotonía de las marcas de tiempo, proporción NULL.

13) Implementación: lista de verificación

• Los KPI/fórmulas/bases están definidos y registrados en el diccionario.
• Configurado por ingestión y normalización de eventos/registros.
• Se han construido vitrinas de 'payments _ flat', 'webhooks',' settlements', 'treasury'.
• Implementados heatmaps, funnel, latency, payout/refund panels.
• Se establecen umbrales de SLO y alertas; asociados con playbucks.
• Roles de acceso: C-level, Ops/Fraud (drill-down).
• QBR semanal para proveedores basados en Provider Scorecard.
• Conjunto de pruebas UAT: demo-dataset, comprobación de p-cuantiles, corrección de bases, alertas.

14) Errores frecuentes

La mezcla de bases ('attempt' vs 'capture') → conclusiones falsas.
No hay segmentación 'ticket _ size' → una imagen distorsionada de AR.
Ignorar abandon en 3DS → un problema «inflado» con el proveedor.
Sin control de duplicates webhook → doble acción.
Un escaparate incompleto por settlement/fees → imposible de evaluar por Costo/GGR.
Sin SLO y playbooks, el dashboard se transforma en un «escaparate sin acción».

Resumen

Los KPI de pago Dashboard son una herramienta operativa, no solo gráficos. Conecta embudo, dinero e infraestructura, se apoya en fórmulas claras y segmentación, da señales automáticas e inmediatamente ofrece acciones. Como resultado: AR_net arriba, TtW/TtR en los corredores, Costo/GGR bajo control, los incidentes se localizan rápidamente y el diálogo con los proveedores se basa en cifras.