A/B testes de cenários de pagamento

1) Por que testar cenários de pagamento

Aumentar aprovações (AR) e reduzir rejeitos (DR).
Reduzir o custo: take-rate (interchange/scheme/markup/fixed) e entre-per-approval.
Reduzir o risco: menos charjbacks/frod com as mesmas aprovações.
Sustentabilidade: escolha o provedor/estratégia 3DS/routing para GEO/BIN/métodos específicos.

2) Design da experiência

2. 1. Unit randomização

User-level (recomendado): Todas as tentativas de um único usuário entram no mesmo ramo → não há «misturar» 3DS/tokens.
BIN-level: Quando o teste é sobre o routing por emissor; risco de mistura cruzada pelo usuário.
Order/Attempt-level: Válido para experiências UI menores (por exemplo, cópia de um erro), não desejado para routing/3DS.

2. 2. Rateio (antes da randomização)

Ratifique por: GEO do jogador, issuer country/BIN6, método de pagamento, canal (web/app), soma-segmento, risco-screen. Isso reduziria a dispersão e o risco de SRM.

2. 3. O que testamos

Routing/cascata: PSP _ A vs PSP _ B, sticky BIN, limite-aware.
Política 3DS: frictionless→challenge, compulsório 3DS para BIN/geo.
X flow: sequência de passos, textos de erro/repetição.
Opções de retração: janelas e códigos soft-decline.
Preço: provedor com IC++ vs blended e impacto no custo all-in.

3) Métricas: destino, secundário, guelrails

3. 1. Principais

AR (Approval Rate) = approved/attempted.
Cost-per-Approval = (auth+decline fees)/approved.
Take-rate% (all-in) = fees/volume (na moeda relatada).
3DS pass-rate; liability shift %.
Latency p95/p99 flow de pagamento.

3. 2. Métricas de risco

Chargeback ratio (CBR), refund rate, fraud alerts/1000 trx.
FX slippage (bps) = effective vs reference FX.

3. 3. Guardrails (termos parados)

Queda de AR> Y bps ou crescimento CBR/Refunds acima do limite.
O SRM (Sample Ratio Mismatch) é um desequilíbrio de tráfego contra o esperado.
Spikes: Latidão, soft-decline surfe, 3DS anataly.

4) Estatísticas e potência

4. 1. Tamanho da amostra (aproximação de participação)

n_per_group ≈ 2 (Z_{1-α/2} + Z_{1-β})^2 p(1-p) / δ^2

onde 'p' é o AR básico, 'se' é o uplift esperado em AR, é o nível de importância, e se é um erro do tipo II.

4. 2. Análise sequencial (paragens iniciais)

Alpha-spending (O'Brien-Fleming/Pocock): Fixamos o cronograma de verificações e desperdiçamos por etapas.
SPRT/Bayes - para soluções operacionais, mas construa o protocolo.

4. 3. Variação-redação

CUPED: 'Y = Y - (X - £ _ X)', onde o X é um cobiçado pré-exportador (AR/DR./risco-score), e o SE é um cobiçado.
Avaliações estraçoadas, erros de cluster robástico (user/BIN).
Bootstrap para take-rate/métricas de valor (caudas pesadas).

4. 4. Testes multivariantes e bandits

MAB (UCB/Thompson): Quando é importante «aprender» a voar e não perder o negócio.
Para as métricas críticas complacentes (CBR, liability) - prefira o clássico A/B com guardrails.

5) Arquitetura plataforma de experimentação

1. Serviço Assignment: hash '(user _ id, experiment _ id, salt)' n' bucket.
2. Função-bandeiras/Rulas-engine: ativação da rota/3DS/retalho no ramo.
3. Eventos: tentativas/resultados (athorize/capture/refund/cb) → pneu (Kafka/PubSub).
4. Idempotidade: geral 'idempotency _ key' para cascata.
5. DWH/Vitrines: estatais normalizadas, fees, FX, bandeiras de risco.
6. Monitoramento: online-SLI (AR/3DS/latency), alertas, cheque SRM.
7. Protocolos: hipótese pré-register, critérios finais, data-frise.

6) Modelo de dados (mínimo)

sql ref. experiments (
exp_id PK, name, hypothesis, owner, start_at, end_at,
unit -- USER      BIN      ORDER,
target_metric, guardrails JSONB, design JSONB, alpha NUMERIC, power NUMERIC, meta JSONB
);

ref. experiment_arms (
exp_id FK, arm_id, name, traffic_share NUMERIC, params JSONB, enabled BOOLEAN
);

assignments. buckets (
exp_id, user_id, assigned_arm, assigned_at, salt, hash_key, PRIMARY KEY (exp_id, user_id)
);

events. payments (
attempt_id PK, user_id, exp_id, arm_id,
provider, method, bin, iso2, risk_score,
status, decline_code, three_ds_used BOOLEAN, liability_shift BOOLEAN,
amount_minor BIGINT, currency, latency_ms INT,
authorized_at, captured_at, settled_at, meta JSONB
);

finance. fees (
attempt_id FK, interchange_amt NUMERIC, scheme_amt NUMERIC, markup_amt NUMERIC,
auth_amt NUMERIC, refund_amt NUMERIC, cb_amt NUMERIC, gateway_amt NUMERIC,
fx_slippage_amt NUMERIC, reporting_currency TEXT
);

risk. outcomes (
attempt_id FK, is_refund BOOLEAN, is_chargeback BOOLEAN, fraud_alert BOOLEAN
);

7) Modelos SQL

7. 1. Cheque SRM (proporção de tráfego por mão)

sql
SELECT arm_id,
COUNT() AS n,
ROUND(100. 0 COUNT() / SUM(COUNT()) OVER (), 2) AS share_pct
FROM assignments. buckets
WHERE exp_id =:exp
GROUP BY 1;

7. 2. Métricas básicas por mão

sql
WITH base AS (
SELECT e. arm_id,
COUNT()                  AS attempts,
COUNT() FILTER (WHERE status='APPROVED') AS approvals,
AVG(latency_ms)              AS latency_avg_ms,
AVG((three_ds_used)::int)         AS three_ds_share
FROM events. payments e
WHERE e. exp_id=:exp AND e. authorized_at BETWEEN:from AND:to
GROUP BY 1
),
cost AS (
SELECT e. arm_id,
SUM(f. interchange_amt + f. scheme_amt + f. markup_amt +
f. auth_amt + f. refund_amt + f. cb_amt + f. gateway_amt + f. fx_slippage_amt) AS fees_rep,
SUM(e. amount_minor)/100. 0 AS volume_rep
FROM events. payments e
JOIN finance. fees f USING (attempt_id)
WHERE e. exp_id=:exp AND e. settled_at BETWEEN:from AND:to
GROUP BY 1
)
SELECT b. arm_id,
approvals::numeric/NULLIF(attempts,0)             AS ar,
fees_rep/NULLIF(volume_rep,0)                 AS take_rate,
(SELECT COUNT() FROM risk. outcomes r
JOIN events. payments e2 USING (attempt_id)
WHERE e2. exp_id=:exp AND e2. arm_id=b. arm_id AND r. is_chargeback)=0
AS cb_zero_flag,
latency_avg_ms, three_ds_share
FROM base b LEFT JOIN cost c ON c. arm_id=b. arm_id;

7. 3. CUPED para AR (exemplo)

sql
WITH pre AS (
SELECT user_id, AVG((status='APPROVED')::int) AS ar_pre
FROM events. payments
WHERE authorized_at <:pre_from_end
GROUP BY 1
),
cur AS (
SELECT e. user_id, e. arm_id, (e. status='APPROVED')::int AS ar_flag
FROM events. payments e
WHERE e. exp_id=:exp AND e. authorized_at BETWEEN:from AND:to
)
SELECT arm_id,
AVG(ar_flag - theta (ar_pre - mu_pre)) AS ar_cuped
FROM cur
LEFT JOIN pre USING (user_id),
LATERAL (SELECT AVG(ar_pre) AS mu_pre FROM pre) mu,
LATERAL (SELECT COVAR_SAMP(ar_flag, ar_pre)/VAR_SAMP(ar_pre) AS theta FROM cur LEFT JOIN pre USING(user_id)) t
GROUP BY arm_id;

7. 4. Verificação de guichês (exemplo)

sql
SELECT arm_id,
100. 0 SUM(is_chargeback::int)::numeric / NULLIF(COUNT(),0) AS cbr_pct,
100. 0 SUM(is_refund::int)::numeric  / NULLIF(COUNT(),0) AS refund_pct
FROM risk. outcomes r
JOIN events. payments e USING (attempt_id)
WHERE e. exp_id=:exp AND e. settled_at BETWEEN:from AND:to
GROUP BY 1
HAVING 100. 0 SUM(is_chargeback::int)::numeric / NULLIF(COUNT(),0) >:cbr_threshold
OR 100. 0 SUM(is_refund::int)::numeric  / NULLIF(COUNT(),0) >:refund_threshold;

8) Processo de teste (e-to-end)

1. Pré-registração: hipótese, métricas, design, tamanhos, regras paradas.
2. Teste SRM/AA para efeito «vazio» (alguns dias).
3. Lançamento: assignment freeze, lógica em rulas-engine/fichiflags.
4. Monitoramento online: AR/3DS/latency/health + guardrails.
5. Verificações intermediárias por alpha-spending (se planejado).
6. Meta e data-frise: somente depois de contabilizar funding/reservas/CB/refunds tardios.
7. Analista: CUPED/rateio, sensibilidade, heterogêneo por GEO/BIN/método/canal.
8. Solução: roll-out, roll-back, ou teste de follow-up; atualizações de regras/roteamento.
9. Documentação e retrospectiva: aulas, atualização de liminares/balanças.

9) Anti-pattern e armadilhas

Peeking/pere-visualização sem protocolo → falsas vitórias.
Order-level randomização em testes de routing → vazamento entre as mãos.
Jogo de multiplicidade (muitas métricas/cortes) sem correção.
Custo incompleto (esquecido FX/reserva/refund fees) → take-rate errado.
Nenhum cheque SRM → conclusões deslocadas.
Retraias não identificáveis → permissões duplas/distorções de AR.

10) Segurança, complacência e ética

Same-method/return-to-nature não deve ser quebrado pelo teste.
Sanções/licenças/políticas GEO - fora da experiência.
RG/jogo responsável: não piorar os mecanismos de defesa por AR.
PCI/GDPR: tokens em vez de PAN, minimização de dados pessoais, DPA/SOC2.

11) KPI dashbord experiência

AR/DR., uplift e espaçamento de confiança em mãos e edições-chave (GEO/BIN/método).
Cost-per-Approval, take-rate %, FX slippage (bps).
3DS pass/liability shift, soft-decline share.
Latency p95/p99, erros/temporizações.
CB/Refunds (lag-aware), SRM, abrangência, duração.

12) Best pratices (curta)

1. Randomize ao nível do usuário e ratifique.
2. Use guardrales e cheque SRM; construa o protocolo.
3. Leia o valor total (fees + FX + reserve) e o custo-per-approval.
4. Aplique CUPED, erros de cluster e bootstrap para as métricas de valor.
5. Para riscos críticos - clássico A/B; bandits - principalmente para tarefas de preço/AR.
6. Leve em conta funding/reservas/CB tardios antes da saída final.
7. Documente e versionize as regras; faça o post-mortem.

13) Folha de cheque de lançamento

• Hipótese, métricas, efeito, design, tamanho da amostra, prazo.
• Unit randomização e estrações, serviço de assignment, ficheflags.
• Guardrails/liminares, SRM/AA-precheck, alertas.
• Logs/eventos, idimpotência, normalização de estatais.
• Vitrines de fees/FX/reserve; A moeda dos relatórios.
• Plano de paragem (alpha-spending) e data-frise.
• Playbooks roll-out/roll-back; documentação de resultados.

Currículo

A/B testes de cenários de pagamento são uma disciplina de engenharia: randomização e stratação adequada, métricas completas de custo e risco, guardrais e SRM, analista cuidadoso (CUPED/cluster-robasting/análise consistente) e infraestrutura «capaz» (Idempotência, telemetria, recepção). Seguindo esta metodologia, você aumenta o AR, reduz o all-in take-rate e não paga por «falsas vitórias» com o aumento de charjbacks e riscos regulatórios.