Liquidação não custodial
Os fundos vão direto para a carteira do comerciante. A BoltUtil monitora a blockchain e envia notificações.
Por que um webhook USDT pode funcionar apenas no retry
Quando o pagamento já está completed mas o app do comerciante atualiza só no segundo envio, o problema costuma estar no endpoint, assinatura, timeout ou lógica não idempotente.
- Criado para
- Retry de webhook
- Criado para
- Debug de callback
- Criado para
- Cumprimento idempotente
Diagnóstico de retry webhook
Webhook retry diagnosis
1. Confirm the order status is already completed
2. Open the webhook delivery log for the order
3. Check first attempt HTTP status, timeout, and response body
4. Verify raw body signature before parsing JSON
5. Make fulfillment idempotent by order ID and tx hash
6. Fix the endpoint, then resend or wait for the next retryFluxo de diagnóstico de retry
Ideal para desenvolvedores depurando ordens USDT concluídas cujo primeiro callback falha.
- 01
Confirme que a ordem está completed na BoltUtil.
- 02
Compare a primeira tentativa falha com o retry bem-sucedido: status, latência, timeout e resposta.
- 03
Verifique HMAC usando o raw body antes de parsear JSON.
- 04
Faça o cumprimento idempotente por ID externo e tx hash, depois reenvie.
Três redes USDT
Aceite TRC20, ERC20 e BEP20 com uma única API de pedidos e payload de webhook unificado.
Automação por webhook
Quando o pagamento é detectado e confirmado, seu backend recebe uma chamada assinada para cumprir o pedido.
Notas de integração
O que importa antes da produção
The first attempt often exposes a cold path
Cold serverless functions, sleeping containers, DNS delays, or lazy database connections can make the first webhook exceed the timeout while the retry succeeds.
Signature validation must use the raw body
If middleware parses, formats, or reorders JSON before HMAC verification, the first callback may be rejected even though the payload is valid.
A retry is expected behavior, not a duplicate payment
Merchants should store processed order IDs and transaction hashes, then return a successful response for already-processed callbacks.
Perguntas antes de ir para produção
Estas respostas ajudam desenvolvedores, fundadores e equipes de suporte a entender o ciclo de pagamento antes de aceitar USDT real.
Retry significa que o pagamento USDT foi detectado tarde? +
Não necessariamente. Se a ordem já está completed, o scanner funcionou; o retry é sobre entrega do callback.
O que meu endpoint webhook deve retornar? +
Retorne 2xx depois de verificar a assinatura e registrar o evento de forma durável. Evite redirects e tarefas longas bloqueantes.
Como evito entrega duplicada? +
Armazene IDs externos e tx hashes processados, e faça callbacks repetidos válidos retornarem sucesso sem entregar duas vezes.
Recursos relacionados
Lance um fluxo de pagamento USDT mais limpo
Crie ordens, monitore transferências e notifique seu backend sem pedir comprovantes manuais.
Criar conta grátis