支付平台为什么会重复通知？
在支付系统中，“同一笔订单收到多次异步通知”通常不是异常，而是可靠投递机制的一部分。当商户服务器响应超时、返回内容不符合要求、网络连接中断，或者平台未能确认处理结果时，支付平台可能按照既定间隔再次发送通知。因此，业务系统不能假设回调只会出现一次，而应按“至少送达一次”的方式设计。
一、先确认订单，而不是直接执行业务
收到回调后，应先使用商户订单号查询本地订单，并核对平台订单号、支付状态、支付金额、币种和商户身份。验签成功只说明消息来源和参数完整性通过验证，并不代表可以跳过订单校验。订单不存在、金额不一致或商户信息不匹配时，应记录异常并停止发货或入账。
二、用唯一标识建立幂等边界
幂等的目标是：同一笔支付通知无论到达多少次，最终业务结果都只生效一次。通常可将商户订单号作为主要幂等键，并对平台交易号建立唯一约束。仅靠“先查询、再更新”仍可能在并发请求下失效，因为两个进程可能同时读到未支付状态。更稳妥的做法是在数据库层设置唯一索引，或使用带条件的原子更新，例如只有订单仍为待支付时才更新为已支付。
三、订单状态与业务动作必须清晰分离
建议为订单设置明确状态，例如待支付、已支付、处理中、已完成、已关闭和异常。回调处理程序只允许合法的单向流转，不应把已完成订单重新改回处理中。发货、开通服务或增加余额等动作，应绑定唯一业务流水号；即使任务被重复执行，也能通过流水记录判断是否已经完成。
四、关键步骤放进同一事务
更新订单状态、写入支付流水和创建待执行的业务任务，最好在同一个数据库事务中完成。这样可以避免“订单显示已支付，但发货任务没有创建”的中间状态。对于耗时操作，可先可靠落库，再交给队列异步处理；队列消费者同样需要幂等检查，不能把防重复责任只放在回调入口。
五、正确响应，并保留重试能力
处理成功后，应严格按照支付平台接口文档返回规定的成功内容，避免因为响应格式错误而持续收到通知。临时故障时不要伪装成功，应记录失败原因并允许重试。对于无法自动处理的金额不一致、订单缺失等情况，可进入异常队列，交由人工核对。
六、日志、告警与对账不可缺少
建议记录回调时间、订单号、平台交易号、验签结果、处理状态和重试次数，但不要在日志中暴露完整密钥、敏感身份信息或无需保存的原始凭证。对重复次数异常、验签连续失败、已支付未完成等情况设置告警，并通过定时对账发现遗漏订单。
上线前自测清单
可以主动模拟同一回调连续提交、多进程并发回调、处理完成后再次通知、数据库短暂失败以及业务任务执行失败等场景。只有在这些情况下都不会重复发货、重复加款或破坏订单状态，幂等设计才算真正有效。
总结
重复通知本身并不可怕，真正的风险是把每次通知都当作新的付款。通过签名与金额校验、数据库唯一约束、条件更新、事务、状态机和可追踪的业务流水，可以把重复回调转化为安全、可恢复的正常流程。
