Liquidación no custodial
Los fondos llegan directamente a la billetera del comercio. BoltUtil solo monitorea la cadena y envía notificaciones.
Por qué un webhook USDT puede funcionar solo en el reintento
Si el pago ya está completed pero la app del comercio se actualiza en el segundo intento, el problema suele estar en disponibilidad, firma, timeout o cumplimiento no idempotente.
- Diseñado para
- Reintentos webhook
- Diseñado para
- Debug de callback
- Diseñado para
- Cumplimiento idempotente
Diagnóstico de reintento 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 retryFlujo de diagnóstico de reintentos
Ideal para desarrolladores que depuran órdenes USDT completadas cuyo primer callback falla.
- 01
Confirme que la orden está completed en BoltUtil.
- 02
Compare el primer intento fallido con el reintento exitoso: código, latencia, timeout y respuesta.
- 03
Verifique HMAC usando el raw body antes de parsear JSON.
- 04
Haga el cumplimiento idempotente por ID externo y tx hash, luego reenvíe.
Tres redes USDT
Integre TRC20, ERC20 y BEP20 con una sola API de órdenes y un payload de webhook unificado.
Automatización por webhook
Cuando el pago se detecta y confirma, su backend recibe una devolución firmada para activar, entregar o acreditar.
Notas de integración
Lo importante antes de producción
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.
Preguntas antes de salir a producción
Estas respuestas ayudan a desarrolladores, fundadores y equipos de soporte a entender el ciclo de pago antes de aceptar USDT real.
¿Un reintento significa que el pago USDT se detectó tarde? +
No necesariamente. Si la orden ya está completed, el scanner funcionó y el reintento pertenece a la entrega del callback.
¿Qué debe devolver mi endpoint webhook? +
Devuelva 2xx después de verificar la firma y registrar el evento de forma durable. Evite redirecciones y trabajo bloqueante largo.
¿Cómo evito cumplimiento duplicado? +
Guarde IDs externos y tx hashes procesados, y haga que callbacks repetidos válidos devuelvan éxito sin entregar dos veces.
Recursos relacionados
Lance un flujo de pago USDT más claro
Cree órdenes, monitoree transferencias y notifique a su backend sin pedir capturas de pago.
Crear cuenta gratis