Política de retry DLR falho no prepaid: quando retentar e quando parar de gastar

O ticket diz «falhou» e alguém martela retry até esvaziar a carteira prepaid. Falhou não é um estado. undelivered, rejected e expired exigem atos distintos. No prepaid cada retry automático é uma linha de débito, não um favor grátis. Acordem o dicionário antes do ciclo, ou o produto persegue conversão enquanto finanças paga a segunda e a terceira tentativa a um número morto.

IOSOR é prepaid white-label: o mesmo vocabulário DLR no painel, no webhook e na exportação. Um corredor live admite retry com teto; in setup não abre «na próxima». Veja não entregue, rejeitado e expirado e DLR, latência e failover. Perto de USD 1,000+ mensais, débitos de retry por balde de estado entram em leitura comercial mais estreita.

Dicionário de estados antes da lógica de retry

Antes de escrever código de retry, imprimam os estados terminais numa tabela que produto, ops e finanças possam apontar. Retry sem dicionário é um ciclo que queima dinheiro. Para entregabilidade em queda, manual de baixa entregabilidade SMS.

Failed versus rejected versus expired

Failed / undelivered significa que a plataforma entregou o trabalho e o terminal não confirmou. Se o corredor está são, um retry com teto pode salvar uma conversão. Rejected é recusa de rede ou de política: o mesmo número e o mesmo corpo quase sempre voltam a recusar e a debitar. Expired é tempo: TTL mais curto que a latência do corredor, ou uma fila antes do envio. Tratar expired como failed e martelar retries só cria mais linhas expired. Um OTP fora da janela já não converte, mas a carteira paga na mesma.

Tetos de retry e impacto na carteira

Ponham um teto de tentativas automáticas por mensagem e separem o resend do utilizador do failover do sistema. Cada tentativa deve bater com um correlation ID no ledger. «Até entregar» sem teto esvazia prepaid num corredor morto. Finanças deve exportar destino, estado, nº de tentativa e débito. Perto de USD 1,000+, um ciclo sem dono deixa de ser ticket e vira tema comercial. Quando a política diz parar, a carteira para mesmo que o produto queira outra vez.

Dono de produto versus finanças

Produto possui a política: que estados permitem retry, TTL, cooldown de resend. Finanças possui a visibilidade: se cada tentativa debita e se a exportação fecha com o webhook. Ops possui o corte por corredor para que uma média mundial não esconda uma rota partida. Sem a mesma tabela, o prepaid não decide «retentar» contra «parar de gastar». Não deixem o suporte prometer reembolso a palavra enquanto o ledger cobra cada tentativa.

Sinais de alerta

• Só existem sent e failed, mas há retry automático
• Três golpes idênticos a um payload rejected
• Expired tratado como avaria de rede
• Failover de sistema e resend de utilizador na mesma linha de débito
• «Até entregar» sem teto de tentativas
• Retry prometido com o catálogo in setup
• Exportação de finanças sem nº de tentativa

Começar com IOSOR

Preencham o dicionário: failed versus rejected versus expired. Ponham teto no retry automático para que cada DLR falhado não abra um débito prepaid novo. O botão de reenvio do utilizador é distinto da tentativa do sistema. Provem o teto em dois corredores live a baixo volume.

Conclusão IOSOR

O retry de DLR falhado é um teto de gasto, não um ciclo infinito.

Faça: classifique o estado terminal, teto nas tentativas, exporte o reenvio do utilizador à parte da tentativa do sistema. Não faça: retriar rejected ou expired como se fossem failed transitório.