IOSOR Guias
Portão de assinatura e janela de replay
Portão de produção: verifique a assinatura e limite a janela de replay antes que qualquer webhook vire verdade de dinheiro ou status — eventos sem assinatura ou antigos continuam bloqueados.
Aceitar payloads de webhook não verificados ou atrasados expõe contas pré-pagas a saldos forjados e débitos duplos por ataques de replay. Você deve aplicar um portão inicial que valide as assinaturas criptograficamente e descarte qualquer evento com timestamp fora de uma janela de tolerância rígida antes de alterar os fundos. Relacionado: assinatura do webhook e janela de replay, retries do webhook de entrada, Linguagem de status compartilhada para produto e finanças, linhas de débito e estado de entrega no mesmo ledger.
A verificação de assinatura é um portão financeiro
A verdade de dinheiro e status só começa após a aprovação da checagem de assinatura. Assinaturas ausentes, divergentes ou ignoradas falham de forma fechada — sem linha no razão, sem «entregue de qualquer forma para o piloto». O Catálogo Live não abre mão do portão. Profundidade de hábitos: assinatura do webhook e janela de replay. O valor de USD 1,000/month trata aceitar dados sem assinatura em staging como dívida técnica.
Janela de replay antes da verdade de status
| Verificação do portão | Passar significa | Falhar significa | |
|---|---|---|---|
| Assinatura presente + válida | Evento autenticado | Rejeitar; sem escrita de dinheiro/status | |
| Timestamp dentro da janela | Fresco o bastante para confiar | Rejeitar como replay/antigo | |
| ID de evento não visto | Primeiro aceite | ACK sem segundo débito | |
| Evento de contrato listado | No menu de eventos do comprador | Descartar tipo desconhecido | . |
A entrega «pelo menos uma vez» tentará novamente. Um retry tardio fora da janela não é «talvez entregue». Registre as rejeições de janela separadamente das falhas de assinatura. Profundidade de retry: retries do webhook de entrada.
Falhar fechado quando o portão rejeita
Eventos rejeitados nunca inventam sucesso. Produto e finanças compartilham as mesmas palavras de rejeição — sem códigos heróis a montante: Linguagem de status compartilhada para produto e finanças. As linhas de débito permanecem alinhadas apenas com eventos aceitos: linhas de débito e estado de entrega no mesmo ledger. Efeitos colaterais ocorrem apenas após o ACK.
Produto, finanças e operações compartilham uma prova
Produto: um evento assinado e dentro da janela pode atualizar o status uma vez? Finanças: cada evento que afeta o dinheiro mostra a passagem pelo portão na mesma janela UTC? Operações: exporte falhas de assinatura versus rejeições de janela sem arqueologia no Slack.
Checklist do comprador para o portão de replay
Verifique se o segredo compartilhado não está exposto em logs. Garanta que o timestamp seja UTC estrito. Valide se o ID do evento é único por contrato. Confirme que a rejeição do portão retorna um erro 4xx para parar o retry.
Comece com IOSOR
No console: Signature + replay window gate before first webhook accept.. Nomeie o dono e os gates antes de escalar.
Relacionado: webhook signature replay window inbound sms webhook retries idempote.
Resumo IOSOR
Disciplina ops de plantão—não brochure.
Faça: name owner + gate. Não: skip the gate.
Este guia foi útil?
Guias relacionados
- Monitoramento de métricas de saúde de endpoints de Webhook
Aprenda a rastrear a latência de resposta do receptor e códigos de status na plataforma IOSOR para gerenciar proativamente a saúde dos webhooks.
- Configuração de alertas de Webhook para limites de saldo pré-pago
Aprenda a configurar webhooks de limite de saldo automatizados no IOSOR para monitorar contas pré-pagas, evitar interrupções e gerenciar o provisionamento JIT.
- Processamento de eventos de webhook de provisionamento Just-in-Time
Domine o ciclo de vida em tempo real dos canais de entrada usando webhooks de provisionamento JIT da IOSOR. Automatize a atribuição de números e atualizações de ledger para seu CPaaS white-label.