收款成功之后：让每一笔支付真正完成业务
钱到了，为什么用户还在等待？
用户支付了一笔 100 USDT 的会员订单，收银台显示已支付，但会员权限迟迟没有开通。对于用户，支付体验还没有结束；对于商户，问题可能发生在通知接收、订单匹配或权益发放中的任何一步。
一套完整的收款流程，要回答三个问题：支付是否已确认，通知是否被可靠接收，承诺给用户的服务是否已经交付。把这三个结果记录清楚，客服才能准确说明进度，系统才能从中断的位置恢复。
将支付状态与履约状态分开
支付确认描述资金处理的结果；业务履约描述会员开通、余额增加、数字商品交付等业务动作。建议为它们保留独立状态和时间记录，不要用一个“成功”覆盖所有步骤。
例如，支付已经确认，但会员服务暂时不可用时，订单可以显示“已支付，服务开通处理中”。保留已确认的支付事实，同时记录待恢复的履约任务。不要因为交付失败把订单退回“待付款”，也不要引导用户再次支付。
先可靠接收，再完成交付
回调接收端按 UUGate API 文档验证签名，并核对订单归属、币种、网络、金额和订单状态。浏览器跳转到成功页、用户上传转账截图，都不能替代服务端的支付核验。
验证通过后，将事件与待处理任务可靠保存，再按接口文档返回成功响应。耗时的会员开通或商品交付可以由后续任务处理。只有记录已经持久化，系统才有依据在服务重启后继续执行；仅把数据放进内存就返回成功，仍可能丢失任务。
重复通知，只产生一次业务结果
同一笔订单可能收到重复通知。为业务入账或履约记录建立包含商户标识和订单标识的唯一约束，用事务或条件更新控制状态变更，避免重复增加余额、重复发货或叠加会员时长。
如果业务动作调用外部服务，应同时传递稳定的幂等标识，并保存该服务返回的结果。超时并不一定表示失败：再次执行前，先查询之前的处理结果，或使用对方支持的幂等机制。单纯依赖“这段代码只会跑一次”不足以应对重试。
给异常一个明确的下一步
把“已支付但未履约”的订单放进可查询的待处理列表，记录最后一次错误、尝试时间和处理结果。区分可以自动重试的临时故障与需要人工核对的订单或金额不匹配。
客服查看订单时，应能关联平台订单号、商户订单号、交易哈希和业务交付记录。人工处理也要走同一套幂等与审计流程，不要绕过记录直接加款。钱包真实链上余额与平台费用账户仍分别核对，不能用履约记录代替余额依据。
上线前，用中断场景验收
- 正常支付后，会员或商品只交付一次，用户看到最终结果。
- 连续收到相同通知，不重复加款、不重复发货。
- 保存通知后服务重启，待处理任务仍能恢复。
- 外部服务超时，能查询结果并避免重复交付。
- 支付已确认但交付失败，用户看到“处理中”和可用的查询入口，而不是被要求再次付款。
UUGate 提供支付与通知能力，商户系统负责把核验后的结果落到自己的业务。接入验收应一直走到用户拿到服务的那一步。
通用事件处理参考：Stripe Webhook 文档。UUGate 的签名、字段和响应要求以 UUGate 文档为准。