支付 Webhook 会以普通方式失败：供应商重试、响应超时、事件延迟、重复投递。可靠集成应围绕这些情况设计，而不是只实现正常支付路径。
先验证，再执行业务动作
在解析支付数据前验证供应商签名和目标端点。记录供应商事件 ID、投递时间和去敏上下文，不要相信未经验证客户端传来的支付状态。
先持久化事件，再处理耗时工作
验证并持久化后快速确认接收，把发货、邮件、记账等耗时工作放入受控的异步流程。
让业务结果具备幂等性
一个事件 ID 只能对应一个业务结果。重复投递不能再次创建订单、重复确认预约或重复发放额度。每次状态变化都要先检查当前状态。
对账本地与供应商状态
定时或按需比较供应商和本地记录。将不一致记录放入异常队列，提供足够信息让人判断应重放、冲正还是调查。
明确恢复责任
写清谁检查失败任务、谁能重放事件、哪些操作需要审批，以及何时联系供应商。恢复是运行流程，不只是一个重试循环。
相关服务
需要处理支付回调、Webhook 与对账时，可查看API、支付与 Webhook 集成。