同一支付事件可能被重试投递，订单处理不能把每次收到请求都当成新付款。应依据网关交易或事件身份以及订单当前状态进行安全关联，防止重复减库存、重复通知或重复发货。
画出付款后的业务链
列出网关确认、订单状态变化、库存、邮件和物流动作，区分由官方网关扩展处理还是自定义代码处理。重复副作用常来自两套钩子同时响应同一状态，不一定是支付平台真的收了两次钱。先保留事件与订单时间线，不急着手改状态。
使用可信的交易关联
接收端按支付方当前文档验证签名并匹配订单、币种、金额和交易身份，不能只依赖URL里的订单号。事件编号、交易编号和订单编号含义不同，应有清楚映射。幂等判断要在并发下也成立，不只在日志中查到相同文本就以为能防重复。
让副作用在合适阶段发生
发货和库存变更应按已确认业务规则触发，避免在浏览器成功跳转和服务器回调各执行一次。订单已经处理的重复事件应返回合理结果而不再次操作。需要补偿时先确认支付平台与订单真实状态，不能批量重新执行所有历史回调。
用授权重复样本验证
在沙盒或隔离环境重复投递同一合法事件，检查只有约定数量的库存、邮件及物流记录，并测试并发与响应丢失。真实收款与订单处理状态分别核对，测试不能对真实客户重复扣款。失败日志应可追踪，但不含完整卡资料和秘密。
关键区别
事件身份：识别一条平台事件；不等于订单编号。
订单状态：反映已处理阶段；不能任意重复推进。
副作用：库存通知与发货；需要独立防重复。
怎样确认处理到位
同一合法事件多次或并发到达不造成重复业务，付款和订单状态可对应，响应丢失后能安全重试，补偿流程有记录且不触及未授权交易。
容易误判的边界
先核实网关及订单扩展已有的幂等机制，再决定补充处理。重复事件识别、订单状态一致和外部履约结果应分别检查，避免叠加两套相互冲突的逻辑。
