# O que é uma cascata de PSP e por que a ordem das tentativas importa

URL: https://betzhub.com/pt/d/3/o-que-e-uma-cascata-de-psp-e-por-que-a-ordem-das-tentativas-importa
Categoria: Deposits & PIX
Tipo: article
Autor: Rodrigo Sampaio, Head of Retention (Operador nacional) [verificado]
Publicado: 2026-08-24T00:23:45+00:00
Atualizado: 2026-08-25T02:23:45+00:00
Tópicos: payments, pix, psp
Respostas: 2 · Úteis: 3
Licença: conteúdo de membros do BetzHub; citação permitida com atribuição e link.

Cascata é a lógica que decide para qual provedor de pagamento uma transação vai, e para onde ela vai quando a primeira tentativa falha. Parece detalhe de infraestrutura; na prática é uma das alavancas mais diretas sobre receita.

## O mecanismo
Uma transação chega. O roteador escolhe um PSP com base em regras: método, valor, moeda, histórico do jogador, custo e disponibilidade. Se a tentativa é recusada por um motivo **reprocessável** (timeout, indisponibilidade momentânea, limite do provedor), a transação cai para o próximo provedor da fila. Se a recusa é **definitiva** (dado inválido, suspeita de fraude, bloqueio do emissor), reprocessar só aumenta custo e risco.

## Onde as cascatas quebram
- **Retentar o que não deveria ser retentado.** Sem tratar o código de recusa, a cascata vira uma máquina de repetir erro, e alguns provedores cobram pela tentativa.
- **Otimizar só por custo.** O PSP mais barato com aprovação pior costuma sair mais caro. O que importa é custo por transação **aprovada**.
- **Ordem estática.** Disponibilidade de provedor varia ao longo do dia. Ordem fixa ignora exatamente a informação mais útil.
- **Sem observabilidade por provedor.** Se você não consegue ver aprovação, latência e erro segmentados por PSP e por método, você não tem cascata: tem sorte.

## O mínimo que vale medir
Taxa de aprovação por provedor e por método, tempo até a confirmação, custo por transação aprovada, taxa de duplicidade e proporção de transações que precisaram de segunda tentativa. Sem essa base, qualquer mudança de ordem é palpite.

Como está desenhada a cascata de vocês hoje, e o que vocês usam para reordenar?

## Respostas

### 1. André Beltrão, Payments Manager

Perfil: https://betzhub.com/pt/u/Andre.beltrao · Standing 192 · Úteis: 2 · 2026-08-24T04:23:45+00:00

Assino tudo, e reforço o ponto da observabilidade porque é onde quase toda operação quebra.

Na nossa cascata, o que mudou o jogo foi separar **recusa técnica** de **recusa de risco**. Antes tratávamos tudo como "não aprovado" e retentávamos igual. Quando quebramos por código, apareceu que uma parte relevante da nossa "queda de aprovação" era timeout de um provedor específico em faixa de horário, o que se resolve reordenando, não trocando de fornecedor.

Duas coisas que eu colocaria na lista de mínimo:

- **Janela de reordenação curta.** A gente reavalia a ordem a cada 15 minutos com base em aprovação e latência da última hora. Ordem estática ignora exatamente o dado mais fresco.
- **Circuit breaker por provedor.** Se a aprovação de um PSP cai abaixo de um piso por N minutos, ele sai da fila sozinho e volta em teste com uma fração do tráfego. Sem isso, alguém precisa perceber o problema no gráfico, e às nove da noite de domingo ninguém percebe.

### 2. Soletr, Analista de Risk & Fraud

Perfil: https://betzhub.com/pt/u/Soletr · Standing 151 · Úteis: 2 · 2026-08-25T02:23:45+00:00

Do lado de risco, um alerta sobre retentativa: cascata agressiva demais gera efeito colateral que não aparece no painel de pagamentos, aparece no de fraude.

Quando você retenta a mesma transação em provedores diferentes, aumenta a chance de duplicidade e de o mesmo instrumento ser testado em sequência, que é literalmente o padrão que os modelos antifraude dos adquirentes procuram. Já vimos conta legítima entrar em lista de risco por causa da nossa própria cascata.

Sugestão prática: limite duro de tentativas por intenção de depósito, com janela mínima entre elas, e nunca retentar depois de recusa por suspeita de fraude. Custa um pouco de conversão imediata e evita um problema muito mais caro depois.