KPI del circuito de pago: auth, capture, refund

TL; DR

El circuito de pago se mide como un embudo: 'Attempt → Auth → Capture → Settle/Refund'. Las métricas clave no son solo la Tasa Approval, sino también las AR puras (después del antifraude y 3DS), el éxito de la captura, el tiempo antes de la cancelación/inscripción, el costo/FX, los errores de idempotencia y la calidad de las devoluciones (TtR y tasa). Gana quien ostenta el AR↑, el TtW↓, el Cost/GGR↓, el Disputes↓, sin romper el perfil de riesgo.

1) Diccionario de etapas y eventos

Attempt: intento de pago (iniciación).
Auth - autorización (banco/billetera/raíles han confirmado la posibilidad de cargo).
Capture (Capture): el cargo real (total/parcial).
Settle - compensación y cálculos.
Refund - devoluciones (completas/parciales), 'TtR = time to refund credit'.
Void - Cancelar hasta capture (si se admite).
3DS/Step-up - fricción en las autorizaciones.
Soft Decline/Hard Decline: fallos recuperables/no recuperables.

💡 База измерений: `country, provider, method, action(deposit/payout/refund), device/os, ticket_size, risk_segment, kyc_tier, bin/asn`.

2) Jerarquía de KPI (árbol de objetivos)

Nivel superior

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 (conclusiones), TtC (captura) p95

Refund Health: Refund Rate, TtR p95, Refund Error Rate

Nivel medio

3DS Challenge Share, Frictionless Share, Abandon on 3DS

Soft Decline Recovery Rate (Retray/Smart Routing)

Partial Capture Share, Capture Latency

Refund to Source %, Duplicate/Idempotency Incidents

Nivel inferior (diagnóstico)

Errores de código (ISO/raíl), p95 de latencia API, SLA de webhooks, fracción 'Do Not Honor', 'Infficient Funds',' Suspected Fraud ',' System Error '.

3) Fórmulas (definiciones precisas)

3. 1 Autorización

`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`

Los cortes son obligatorios: 'BIN × country', 'provider × method', 'device/os', 'ticket _ size' (por ejemplo, ≤€50, 50-200 €,> 200 €).

3. 2 Cargos (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 Costo y FX

`Cost_per_Tx = Fee_fixed + AmountFee_pct + FX_Spread`

`Cost/GGR = ΣCost / GGR`

`Net_Revenue = GGR - ΣCost - Fraud_Loss - Disputes_Cost`

3. 4 Devoluciones (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' - Contador de colisiones idempotentes (debe = 0)

4) Objetivos/puntos de referencia (personalizables para una cartera específica)

AR_gross: tarjetas 3DS2 - 82-92% (por BIN/país), A2A - 90% + (iniciación), vales - 95% + (redeem).
Capture_Success: 98. 5% + (con webhooks y retratos en vivo).
TtC p95: ≤ 5 min (mapas de auto-captura), ≤ 90 segundos (instant A2A/RTP).
Refund Error: < 0. 3%; TtR p95: ≤ T + 1 banco. día (mapas), ≤ 60 segundos (instant rails).
Refund_to_Source%: ≥ 95% (donde los rieles soportan).
Idempotency Incidents: = 0; Webhook SLA: ≥ 99. 9%, p95 < 3 c.

(No «puntos de referencia del mercado», sino corredores prácticos dirigidos a los SLO internos.)

5) Segmentación y atribución

Considere los KPI de la sección: 'country', 'method _ group', 'provider', 'BIN', 'device/os', 'ticket _ size', 'risk _ segment', 'kyc _ tier', 'affiliate', 'new _ vs _ _ returning'.

Cohort AR: AR por cohorte de primer pago (D0/D7/D30).
Ruta AR: AR en las rutas 'PSP_A→PSP_B failover'.
Risk-aware AR: AR por segmentos de riesgo (después de step-up).
BIN-heatmap: emisores vulnerables → reglas de retray/3DS separadas.

6) Modelo de datos (capa plana para BI)

Mínimo «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

La clave es la idempotente 'payment _ key' por etapa y 'idempotency _ key' por refund.

7) Cortes SQL (ejemplo)

7. 1 AR y Capture diarios

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 Salud refundida

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 fricción 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) Dashboard (widgets obligatorios)

1. Funnel: Attempt → Auth → Capture (en absoluto y conversiones).
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. Costo/GGR: por métodos y proveedores.
7. Alertas panel: códigos de fallo superior, degradación AR/latency.

9) SLO, alertas y playbucks

SLO/Alertas (ejemplo):

'AR_gross↓> 3 p.p. a la mediana de 7 días' → ALERT P1 (comprobar BIN/proveedor/ASN).
'Capture _ Success <98% (hora)' o'Webhook p95> 5 c' → ALERT P1 (retroceso/incidente en PSP).
'TtR _ p95> objetivo' por los métodos instant → ALERT P2 (comprobar cola/límites).
`Refund_Error_Rate > 0. 5% 'o' Double _ Refund> 0 '→ ALERT P0 (congelación de refundiciones automáticas, verificación manual).

Playbucks:

Degradación BIN: incluir un ecuador alternativo, aumentar la proporción de 3DS-challenge para BIN, retrae con parámetros 'ECI'.
Soft Declines del sistema: enrutamiento inteligente → PSP_B, limitar la repetición a N, cambiar la política de 3DS.
Capture retrasos: fuerza retraídas, verificación de firma de webhooks, aumento de idempotencia TTL.
Errores de refundición: habilite claves idempotentes, limite el recuadro parcial paralelo, QA manual a duplicados.

10) Gestión de riesgos y cumplimiento en KPI

Reportar AR_clean después de eliminar 'Fraud _ Preblocked' y 'Abandon _ 3DS' es su AR operativo, no se mezcle con el efecto antifraude.
Refund_to_Source% - KPI regulador clave; las excepciones se fijan como aprox-approved.
Dispute/Chargeback Rate vincula a la captured_amount, no a los intentos.

11) Errores frecuentes

Sumando diferentes bases (attempt vs auth vs capture) en una fracción.
La falta de segmentación por 'ticket _ size' → conclusiones falsas sobre AR.
No tiene en cuenta 'User Abandon' en 3DS → «artificialmente» bajo AR.
No 'idempotency _ key' en refund → tomas/pérdidas financieras.
Mezcla de payout y refund en la misma métrica TtW/TtR.

12) Lista de comprobación de implementación

Esquema de eventos armonizado y definiciones de KPI uniformes.
Heatmap por BIN/país y enrutamiento por proveedor.
Dashboard de fricción 3DS y abandon.
SLA webhooks, retraídas, idempotencia (auth/capture/refund).
Informes sobre Salud de Referencia y Refund_to_Source%.
Alertas de degradación AR, Capture_Success, TtR, errores de refundición.
Revisión mensual de R&O: Costo/GGR, Disputes, spreads FX, proveedor-SLA.

13) Resumen

Un circuito de pago fuerte es un embudo transparente con una base correcta para cada participación, disciplina de eventos rígidos, segmentación y playbooks automáticos. Los KPI adecuados convierten la infraestructura de pago en una palanca de crecimiento: AR_net↑, TtC/TtR↓, Cost/GGR↓, Disputes↓, con una seguridad constante o mejorada.