Como modelar a jornada?

Modele a jornada completa, desde autenticação e criação do pedido até a geração, consulta e confirmação do PIX. O teste deve diferenciar o tempo da aplicação do tempo das instituições e APIs externas, respeitando limites, regras de autorização e ambientes de sandbox.

A escala real justifica esse cuidado: em 4 de setembro de 2026, o PIX processou 318,1 milhões de transações em um único dia, movimentando R$ 186,9 bilhões — volume que coincidiu com o pagamento de salários próximo ao quinto dia útil, um padrão de pico previsível que se repete todo mês. Em 2025, o sistema somou quase 80 bilhões de operações no ano, um crescimento de 25,7% sobre 2024, com uma média que já passa de 3 mil transações por segundo. Modelar a jornada sem considerar esses picos sazonais e horários — pagamento de salário, datas comemorativas, horário de almoço — é testar um cenário que não corresponde ao dia real de maior risco.

Por que o PIX é um caso à parte

Diferente da maioria dos sistemas internos, a performance do PIX não é apenas uma métrica interna: o Banco Central exige que cada participante do arranjo envie periodicamente seu índice de disponibilidade e os percentis de tempo de resposta do DICT (Diretório de Identificadores de Contas Transacionais) — incluindo o percentil 99 do tempo de consulta e o percentil 95 do tempo de registro de chave. O descumprimento dos acordos de nível de serviço previstos no Manual de Tempos do Pix é uma infração passível de multa, com valores que podem chegar a R$ 1 milhão dependendo da gravidade e da reincidência.

Isso muda o enquadramento do problema: um teste de performance do PIX não está apenas protegendo a experiência do usuário final, está protegendo a instituição de uma penalidade regulatória documentada e mensurável pelo próprio Banco Central.

O que observar?

Observe pool de conexões, locks, filas, idempotência, timeouts e retentativas. Uma falha em um provedor não deve necessariamente bloquear todo o checkout.

Idempotência merece atenção especial: o próprio Manual de Padrões para Iniciação do Pix, publicado pelo Banco Central, define o campo txid como identificador único da transação — a base para garantir que uma retentativa após timeout ou falha de rede não gere uma cobrança duplicada. Na prática, isso significa validar cenários específicos sob carga: o que acontece quando o cliente reenvia a mesma chave de idempotência enquanto a primeira requisição ainda está em processamento (deve retornar um erro controlado, não processar duas vezes); o que acontece quando o servidor falha depois de gerar o QR Code mas antes de confirmar a resposta ao chamador; e se o retorno para uma chave repetida com payload idêntico realmente devolve o resultado da transação original, em vez de criar uma nova.

Um webhook de confirmação que não responde dentro da janela esperada (tipicamente poucos segundos) entra em retentativa — e se o sistema que recebe esse webhook não for idempotente, cada retentativa pode marcar o mesmo pagamento como concluído mais de uma vez, com efeitos diretos no financeiro.

Falha parcial não pode virar falha total

Uma falha em um provedor não deve necessariamente bloquear todo o checkout. Isso exige, na prática, isolar a chamada externa (instituição financeira, gateway, antifraude) atrás de um timeout curto e um circuit breaker, para que a lentidão de uma dependência não consuma todas as threads ou conexões disponíveis da aplicação e derrube também jornadas que não dependem dela. O resultado deve indicar a capacidade observada, os riscos e os componentes que exigem correção. Testes em produção só podem ocorrer com autorização formal e controles específicos — dado o caráter regulado do ambiente, esse não é um detalhe negociável.

Qual o resultado esperado?

O laudo deve indicar a capacidade observada da jornada de pagamento, os gargalos identificados e as recomendações priorizadas. Escolha o fluxo transacional mais importante para sua operação e valide-o antes da próxima janela de maior demanda — considerando não apenas o volume médio, mas os picos sazonais e horários que o histórico de transações do PIX já deixa bastante previsíveis.

Próximo passo: mapeie a jornada completa do PIX e identifique os pontos de dependência de APIs externas antes de modelar o teste — e confirme se sua idempotência realmente segura uma retentativa em todos os pontos de falha, não só no caminho feliz.

Referências