稳定币收款回调失败怎么办：重试、验签与重复入账处理
用户已经转账，业务余额却没有更新，问题不一定出在链上。回调地址不可访问、验签失败或商户系统处理超时，都可能让支付状态与业务状态暂时不一致。排查时要分别确认链上交易、网关订单和商户入账记录。
先确认卡在哪一步
- 查询网关订单，确认是否已经满足支付成功条件。
- 检查回调地址是否可从公网访问，以及 HTTPS 证书、路径和反向代理是否正常。
- 查看商户接收日志，区分未收到请求、验签未通过、业务处理失败和响应超时。
- 保存订单号、请求时间、响应状态和处理结果，避免把密钥或完整敏感数据写入日志。
回调送达与业务入账是两件事。返回成功响应并不能证明会员余额已经更新，商户仍需要能够追踪后续处理结果。
用正确的密钥和原始请求体验签
UUGate 的回调验签使用 callbackSecret，它与商户 OpenAPI 请求使用的 API Key 用途不同。应按接口文档保留原始请求体，并核对时间戳、随机串与签名；不要先格式化 JSON 再验签。签名不通过时不能更新业务订单，也不应通过关闭验签来恢复收款。
重复通知只入账一次
以商户身份和网关订单号建立业务唯一约束，在数据库事务内完成订单状态更新与余额入账。两个回调并发到达时，不能仅依赖“先查询、再加款”的应用逻辑；唯一约束和事务应保证最多入账一次。
同一地址可能收到多笔充值，因此不能用收款地址作为唯一去重依据。回调和主动查询补偿也应共用同一套入账逻辑，避免两条路径分别加款。
持久化后再确认接收
如果处理能快速完成，在事务提交后返回接口约定的成功响应。需要异步处理时，先验签并将事件可靠写入持久化队列，再返回成功；随后监控消费失败与积压。只写入进程内存就确认接收，可能在重启时丢失待处理事件。
用查询找回遗漏订单
服务恢复后，对仍未完成的业务订单查询网关状态，再使用与回调处理相同的业务校验和幂等入账规则补齐记录。查询结果还应核对商户、订单、币种、网络和金额。不要因为浏览器显示成功，或用户提供了付款截图，就直接加款。
上线前至少验证重复通知、并发通知、入账后响应丢失、服务重启和查询补偿这几类情况。具体字段、成功状态与签名算法以 API 文档为准；业务流程可参考支付接口接入方案，使用额度可查看套餐说明。