Caminho de pagamento KPI: auth, capture, refund

TL; DR

O circuito de pagamento é medido como um vórtice: 'Attempt → Auth → Capture → Setle/Refund'. As métricas-chave não são apenas Approval Rate, mas também AR limpo (após antifrode e 3DS), sucesso capture, tempo antes de cancelamento/inscrição, custo/FX, erros de idempotação e qualidade de retorno (TtR e rate). Quem segurar, , , , sem quebrar o perfil de risco.

1) Dicionário de estágios e eventos

Attempt - Tentativa de pagamento (iniciação).
Auth - autorização (banco/carteira/roteiros confirmaram a possibilidade de cancelamento).
Capture - cancelamento real (total/parcial).
Setle - Clearing e cálculos.
Refund - Retorno (total/parcial), 'TtR = time to refund credit'.
Void - Cancelamento até capture (se suportado).
3DS/Step-up - fricção de permissão.
Soft Decline/Hard Decline - falhas, restauráveis/não-recuperáveis.

2) Hierarquia KPI (árvore de alvos)

Nível 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 (conclusões), TtC (capture) p95

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

Nível médio

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

Soft Decline Recovery Rate

Partial Capture Share, Capture Latency

Refund to Source %, Duplicate/Idempotency Incidents

Nível inferior (diagnóstico)

Erros de código (ISO/RAIL), p95 latência API, SLA webhooks, parte de "Do Not Honorário", "Insuficient Funds'," Suspected Fraud "," System Error ".

3) Fórmulas (definições precisas)

3. 1 Autorização

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

Os cortes são obrigatórios: «BIN x country», «provider x method», «device/os», «jet _ size» (por exemplo, ≤€50, €50-200,> €200).

3. 2 Débitos (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 Custo e FX

`Cost_per_Tx = Fee_fixed + AmountFee_pct + FX_Spread`

`Cost/GGR = ΣCost / GGR`

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

3. 4 Devoluções (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`

'Duplo _ Refund _ Inventos' - Contador de conflitos de Idumpotentes (deve = 0)

4) Metas/orientações (para uma carteira específica personalizada)

AR _ gross: cartões 3DS2 - 82-92% (BIN/país), A2A - 90% + (iniciação), vales - 95% + (redeem).
Capture_Success: 98. 5% + (em webhooks e retais vivos).
TtC p95: ≤ 5 min (cartões auto-capture), ≤ 90 segundos (momento A2A/RTP).
Refund Error: < 0. 3%; TtR p95: ≤ T + 1 banco. dia (cartões), ≤ 60 segundos (momento rails).
Refund _ to _ Fonte%: ≥ 95% (onde os trilhos são suportados).
Idempotency Incidents: = 0; Webhook SLA: ≥ 99. 9%, p95 < 3 c.

(Não «benchmarks do mercado», mas corredores de destino práticos para SLO interno.)

5) Segmentação e atribuição

Considere o KPI em «country», «method _ group», «provider», «BIN», «device/os», «jet _ size», «risk _ segment», «kyc _ tier», «affiliate», «new _ vs _ returning».

Cohort AR: AR para primeiro pagamento (D0/D7/D30).
Rota AR: AR sobre rotas 'PSP_A→PSP_B failover'.
Risk-aware AR: AR por segmento de risco (após step-up).
BIN-heatmap: emissores vulneráveis → regras individuais de retrações/3DS.

6) Modelo de dados (camada plana para BI)

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

A chave é «payment _ key» idempotental para o estágio e «idempotency _ key» para o refund.

7) cortes SQL (exemplo)

7. 1 AR Diário e Capture

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 Refund saúde

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 3DS fricção

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 obrigatórios)

1. Funtel: Attempt → Auth → Capture (em absoluto e conversões).
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. Costa/GGR: por métodos e provedores.
7. Altos códigos de falha, degradação de AR/latency.

9) SLO, alertas e playbooks

• 'AR_gross↓> 3 p.p para a mediana de 7 dias' → ALERT P1 (verificar BIN/provedor/ASN).
• 'Capture _ Sucess <98% (horário)' ou 'Webhook p95> 5 c' → ALERT P1 (retrai/incidente em PSP).
• 'TtR_p95> destino' em métodos de momento → ALERT P2 (verificar fila/limites).
• `Refund_Error_Rate > 0. 5% 'ou' Duplo _ Refund> 0 '→ ALERT P0 (congelamento de refandos automáticos, verificação manual).

• Degradação BIN: incluir um equador alternativo, aumentar a participação do 3DS-challenge para BIN, retais com parâmetros 'ECI'.
• Soft Declins do sistema: routing inteligente → PSP _ B, limite a repetição para N, altere a política 3DS.
• Atrasos de capture: força-retrai, verificação de assinatura de webhooks, aumento da idempotação TTL.
• Erros de refund: incluir chaves idumpotentes, limitar partial-refund paralelo, QA manual para duplicados.

10) Gerenciamento de risco e complicação no KPI

Reportar AR _ clean após remover 'Fraud _ Preblocked' e 'Abandon _ 3DS' é o seu AR operacional, não misture com o efeito antifrode.
Refund _ to _ Fonte% é um KPI regulatório chave; exceções atinjam como cop-approved.
Dispute/Marceback Rate, vincule-se ao captured _ amount em vez de tentar.

11) Erros frequentes

Some as diferentes bases (attempt vs auth vs capture) em uma única fração.
A falta de segmentação por 'jet _ size' → conclusões falsas sobre AR.
Não contabilizar 'User Abandon' em 3DS → 'artificialmente baixo' AR.
Não há 'idempotency _ key' no refund → duplas/perdas financeiras.
Mistura payout e refund em uma métrica de TtW/TtR.

12) Folha de cheque de controle de implementação

• Esquema de evento concordado e definições KPI unificadas.
• Heatmap por BIN/países e rotação por provedores.
• Dashboard 3DS fricção e abandão.
• SLA webhooks, retraias, idempotidade (auth/capture/refund).
• Relatórios de Refund Health e Refund _ to _ Fonte%.
• Alertas de degradação AR, Capture _ Sucess, TtR, erros de refund.
• Visão mensal de R&O: Vale/GGR, Disperses, Spread FX, Provedor-SLA.

13) Resumos

Um circuito de pagamento forte é um vórtice transparente com base correta para cada fração, disciplina rígida de eventos, segmentação e playbooks automáticos. Os KPI corretos transformam a infraestrutura de pagamentos em uma alavanca de crescimento: AR_net↑, TtC/TtR↓, Cost/GGR↓, Disputes↓, com segurança constante ou melhorada.