为什么 USDT 支付 Webhook 可能重试后才成功

当链上支付已经完成，但商户系统只有第二次 Webhook 重试后才更新时，问题通常在回调接口可用性、签名验证、超时行为或非幂等履约逻辑。

适用于: Webhook 重试
适用于: 回调排查
适用于: 幂等履约

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 retry

Webhook 重试排查流程

适合开发者排查 USDT 订单已经完成，但第一次回调失败、后续重试才成功的情况。

01
先确认 BoltUtil 中订单已经 completed，说明链上扫描和订单匹配已成功。
02
对比失败的首次投递和成功的重试：HTTP 状态码、耗时、超时和响应体。
03
确认接口使用 raw body 做 HMAC 验签，再进行 JSON 解析。
04
按商户订单号和 tx hash 做幂等处理，修复原因后再重发 Webhook。

非托管结算

资金直接进入您配置的商户钱包。BoltUtil 只负责监听链上交易和发送通知，不接触也不托管用户资金。

三条 USDT 网络

通过同一套订单 API 和统一 Webhook，接入 TRC20、ERC20、BEP20 三条主流 USDT 网络。

Webhook 自动化

当链上交易被检测并确认后，您的系统会收到带签名的回调，可自动发货、开通会员或入账。

接入要点

上线前真正重要的细节

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.

上线前商户常问的问题

这些回答帮助开发者、创始人和客服团队在接收真实 USDT 付款前理解完整支付生命周期。

Webhook 重试代表链上支付识别慢了吗？ +

不一定。如果订单已经 completed，说明支付识别已完成，重试通常是商户回调接口投递或处理失败。

Webhook 接口应该返回什么？ +

验签成功并持久化记录后返回 2xx。避免重定向、长时间阻塞任务和不稳定的 5xx。

如何避免重试导致重复发货？ +

用 externalOrderId 和 tx hash 做幂等记录。重复收到同一笔有效回调时返回成功，但不要重复入账或发货。

上线更清晰的 USDT 收款流程

创建订单、监听转账并通知您的后端，不再要求客户发送付款截图。

创建免费账户