Testes financeiros em sandbox: como alcançamos zero incidentes em produção

A lacuna de testes em fintech

A maioria dos testes em fintech usa respostas mockadas. A API de pagamentos retorna { "status": "success" } nos testes, e engenheiros assumem que produção vai fazer o mesmo. Funciona bem até que:

• Uma chave PIX expira entre o lookup e o pagamento
• Um boleto é pago duas vezes (uma no banco, outra via PIX)
• Um charge de cartão é aprovado mas a entrega do webhook falha
• Um split payment parcialmente tem sucesso (2 de 3 sellers creditados, 1 falha)
• Uma colisão de chave de idempotência cria um pagamento duplicado
• Um PSTI cai no meio da transação e a fila store-and-forward entra em ação
• Uma ordem de bloqueio judicial (SisbaJud) chega para uma conta com pagamento de saída pendente

Mocks não capturam nenhum desses. Não conseguem — não modelam a máquina de estados de transações financeiras. Um mock que retorna "success" não sabe que a mesma chave PIX já foi usada em um teste anterior, ou que o boleto venceu 3 minutos atrás, ou que o saldo da conta ficou negativo após um split concorrente.

É por isso que a maioria das fintechs tem seus piores bugs em produção. Não porque seus engenheiros são descuidados, mas porque o ambiente de testes não se comporta como a realidade.

Nossa filosofia de sandbox: replicação comportamental, não mocking de API

O sandbox da Revenu não é um mock server. É um sistema financeiro completo rodando o mesmo código que produção, com a mesma lógica de negócio, as mesmas máquinas de estado, os mesmos edge cases — mas com dependências externas simuladas (bancos, PSTIs, bandeiras de cartão).

O que "mesmo comportamento" significa

Mesmos contratos de API. Cada request e response no sandbox é idêntico à produção. Mesmos campos, mesmas regras de validação, mesmos códigos de erro, mesmos rate limits. Se sua integração funciona no sandbox, funciona em produção.

Mesmas máquinas de estado. Um pagamento PIX no sandbox passa pelos mesmos estados que produção: INITIATED → PROCESSING → CONFIRMED ou FAILED. Um boleto passa por: CREATED → REGISTERED → PAID ou EXPIRED ou CANCELLED. Transições de estado seguem as mesmas regras, com as mesmas restrições de timing.

Mesmos webhooks. Sandbox entrega webhooks com a mesma estrutura de payload, a mesma lógica de retry (3 tentativas, backoff exponencial), e o mesmo mecanismo de assinatura (HMAC-SHA256). Se seu handler de webhook funciona no sandbox, trata webhooks de produção corretamente.

Mesmos edge cases. Saldo insuficiente? Mesmo erro. Chave PIX expirada? Mesmo erro. Chave de idempotência duplicada? Mesmo comportamento. Rate limited? Mesma resposta 429 com header retry-after.

O que é diferente

Dinheiro real não se move. Transações do sandbox não tocam contas bancárias reais ou PSTIs reais. Saldos são simulados. Liquidações são simuladas. Mas os lançamentos contábeis são reais — os mesmos lançamentos de partida dobrada que produção gera.

Timing determinístico. Em produção, uma confirmação PIX leva 1-3 segundos. No sandbox, você pode configurar: confirmação instantânea, confirmação atrasada (para testar tratamento de timeout), ou nunca-confirmar (para testar caminhos de falha).

Falhas controláveis. Em produção, falhas são aleatórias. No sandbox, você pode disparar falhas específicas sob demanda: timeout de PSTI, recusa de cartão com código de motivo específico, falha de entrega de webhook, falha parcial de split.

Time travel: testando edge cases temporais

Sistemas financeiros são cheios de comportamento dependente de tempo: boletos vencem, liquidações têm cronogramas D+N, períodos de escrow terminam, janelas de antecipação abrem e fecham, cálculos tributários mudam em limites de mês.

Testar esses cenários em tempo real é impraticável. Você não pode esperar 30 dias para testar que um escrow D+30 libera corretamente. Não pode esperar até dezembro para testar lógica de 13º salário.

A API de time travel

O sandbox expõe uma API de time travel que permite manipular o relógio do sistema para seu ambiente de teste:

POST /sandbox/time-travel

{ "advance": "30d" }

Isso avança o relógio do sistema em 30 dias. Todos os processos dependentes de tempo executam como se 30 dias tivessem passado:

• Boletos que venceriam nos próximos 30 dias vencem imediatamente
• Contas escrow D+30 liberam seus fundos
• Engine de accrual roda 30 jobs diários de accrual
• Sweeps e liquidações programados executam
• Janelas de bloqueio MED 2.0 expiram

Você também pode definir uma data específica:

POST /sandbox/time-travel

{ "set": "2026-12-20" }

Agora você pode testar comportamento específico de dezembro: processamento de 13º salário, reporting CADOC de fim de ano, impactos de calendário de feriados na liquidação.

Time travel + webhooks

Quando você faz time-travel, todos os eventos que teriam ocorrido no período intermediário são gerados e entregues como webhooks — em ordem cronológica, mas em velocidade acelerada. Seu handler de webhook recebe a sequência completa de eventos como se aqueles 30 dias tivessem realmente passado.

Isso permite testar o comportamento do seu sistema ao longo de períodos longos em segundos, não semanas.

Injeção de caos: quebrando coisas de propósito

Sistemas em produção falham de maneiras imprevisíveis. Sandbox permite simular essas falhas previsivelmente.

API de injeção de falhas

POST /sandbox/chaos

{ "target": "pix", "failure": "psti_timeout", "probability": 0.5, "duration": "10m" }

Isso faz 50% das transações PIX falharem com timeout de PSTI pelos próximos 10 minutos. Seu sistema deveria: detectar as falhas, ativar circuit breaker, enfileirar transações em store-and-forward, tentar novamente quando o PSTI "recuperar", e entregar webhooks de sucesso para transações recuperadas.

Modos de falha disponíveis

Falhas PIX: timeout de PSTI, rejeição de PSTI, DICT indisponível, manutenção SPI, colisão de EndToEndId.

Falhas de boleto: timeout de registro, pagamento duplo, pagamento após vencimento, pagamento parcial.

Falhas de cartão: saldo insuficiente (soft decline), cartão vencido (hard decline), do not honor (genérica), timeout no adquirente, chargeback após captura.

Falhas de webhook: timeout de entrega, erro 5xx no seu endpoint, entrega atrasada, entrega fora de ordem.

Falhas de infraestrutura: lag de ledger (simulação de eventual consistency), colisão de idempotency.

Cenários de caos (pré-construídos)

Para necessidades comuns de teste, fornecemos cenários pré-construídos:

• "Black Friday" — 10x volume normal com 5% de taxa de falha
• "Queda de PSTI" — PSTI primário cai por 15 minutos
• "Rush de fim de mês" — pagamentos de salário + impostos + fornecedores todos chegam simultaneamente
• "Ataque de fraude" — sucessão rápida de PIX pequenos disparando MED 2.0
• "Bloqueio judicial" — ordem SisbaJud chega para uma conta com transações pendentes

Webhooks determinísticos: testando fluxos async sem flakiness

A causa #1 de testes de integração financeira flaky é timing de webhook. Em produção, um webhook pode chegar 200ms após a chamada de API, ou 5 segundos depois, ou 30 segundos depois (após retries). Testes que dependem de timing de webhook são inerentemente não confiáveis.

Modo síncrono de webhook

Sandbox suporta um modo síncrono de webhook onde a chamada de API bloqueia até que o webhook seja entregue:

POST /sandbox/config

{ "webhooks": { "mode": "synchronous" } }

Com isso habilitado, quando você cria um pagamento PIX, a resposta da API não retorna até que o webhook de confirmação de pagamento tenha sido entregue ao seu endpoint. Isso torna testes determinísticos — sem sleep, sem polling, sem flakiness.

Inspeção de webhooks

Todo webhook entregue no sandbox é logado e consultável:

GET /sandbox/webhooks?event=payment.confirmed&last=10

Retorna os últimos 10 webhooks de confirmação de pagamento com payloads completos, timestamps de entrega, códigos de resposta HTTP do seu endpoint, e histórico de retry. Essencial para debugar problemas de integração.

Replay de webhooks

Cometeu um erro no seu handler de webhook? Corrija, depois faça replay:

POST /sandbox/webhooks/{id}/replay

O exato mesmo payload de webhook é re-entregue ao seu endpoint. Sem necessidade de recriar toda a transação.

Gestão de dados de teste: cenários realistas sem bagunça

API de seed data

Sandbox fornece uma API de seed data que cria cenários de teste realistas em uma chamada:

POST /sandbox/seed

{ "scenario": "marketplace_with_sellers", "sellers": 5, "transactions": 100, "include_chargebacks": true }

Isso cria: 5 contas de seller com KYC completo, 100 transações distribuídas entre os sellers, split payments com taxas de plataforma, entradas de escrow em vários estágios, 3 chargebacks em vários estados.

Reset de ambiente

POST /sandbox/reset

Limpa todos os dados e retorna o sandbox a um estado limpo. Leva < 3 segundos. Útil no início de cada rodada de testes.

Snapshots

Salvar e restaurar estado do sandbox:

POST /sandbox/snapshot — Salvar estado atual

POST /sandbox/snapshot/{id}/restore — Restaurar para estado salvo

Isso permite montar um cenário de teste complexo uma vez, salvar, e restaurar antes de cada teste. Sem necessidade de recriar 50 contas e 200 transações para cada rodada.

Integração CI/CD: sandbox no seu pipeline

GitHub Actions / GitLab CI

Sandbox integra diretamente em pipelines CI/CD. Fluxo típico:

1. Pré-teste: Reset sandbox, seed de dados de teste

2. Testes unitários: Rodar contra APIs do sandbox (webhooks determinísticos habilitados)

3. Testes de integração: Rodar fluxos completos de pagamento (criar pagamento → receber webhook → verificar ledger)

4. Testes de caos: Injetar falhas e verificar tratamento de erros

5. Testes de time travel: Avançar tempo e verificar liquidação, escrow e comportamento de accrual

6. Testes de compliance: Verificar geração CADOC, atualizações CCS, completude da trilha de auditoria

7. Pós-teste: Consultar sandbox por estados inesperados ou webhooks não entregues

Ambientes de teste paralelos

Cada API key no sandbox recebe um ambiente isolado. Rode 10 suites de teste paralelas sem interferência — cada uma tem suas próprias contas, saldos, transações e relógio de tempo.

Análise what-if: testando lógica de negócio sem risco

Sandbox não é só para engenharia. Times de produto e finanças usam para análise what-if:

Teste de estrutura de taxas

"E se mudarmos a taxa da plataforma de 3% para 2,5%? Como isso afeta a receita por seller?"

Crie 1.000 transações no sandbox com a nova estrutura de taxas. Confira o ledger. Compare com a estrutura atual. Tome a decisão com dados, não com adivinhação.

Otimização de cronograma de liquidação

"E se movermos a Categoria de Seller X de D+14 para D+7? Qual é a exposição a chargebacks?"

Rode 6 meses de transações simuladas com time travel. Confira quantos chargebacks teriam ficado desprotegidos pela janela de escrow mais curta.

Lançamento de novo método de pagamento

"Vamos adicionar PIX Parcelado. O que acontece com o ledger quando um pagamento PIX de 12 parcelas é parcialmente estornado após 4 parcelas?"

Teste no sandbox. Crie o pagamento, faça time-travel por 4 parcelas, emita um estorno parcial, verifique os lançamentos contábeis, confira a liquidação do seller, confirme o valor de estorno do comprador.

Os números de produção

Após 18 meses de desenvolvimento sandbox-driven:

• Zero incidentes de pagamento em produção em 18 meses
• 100% paridade de API entre sandbox e produção
• 47 cenários de caos disponíveis para testes de falha
• < 3 segundos tempo de reset de ambiente
• 12 cenários de seed pré-construídos para setups comuns de teste
• 4.200+ testes de integração rodando no CI/CD por deploy
• 94% dos bugs capturados no sandbox antes de chegar à produção
• Time travel usado por 100% dos clientes para testes de liquidação e escrow
• 23 clientes usando sandbox ativamente para análise what-if

Por que isso importa

Em fintech, bugs em produção não causam apenas downtime — causam perdas financeiras. Um bug de pagamento duplo significa dinheiro real enviado duas vezes. Um erro de cálculo de liquidação significa sellers recebendo o valor errado. Um bug de tratamento de webhook significa que seu sistema não sabe que um pagamento foi confirmado.

Esses bugs são evitáveis. Mas apenas se seu ambiente de testes se comporta como produção. Mocks não bastam. Ambientes de staging com dados de teste criados manualmente não bastam. Você precisa de um sandbox que é uma réplica comportamental de produção, com a capacidade de simular tempo, injetar falhas e testar edge cases que levariam meses para encontrar naturalmente.

É isso que construímos. E 18 meses de zero incidentes em produção provam que funciona.