码支付系统收到付款结果后，通常会通过异步通知把订单状态推送给业务系统。网络抖动、服务器短暂不可用、队列拥堵或应用重启，都可能造成通知延迟。可靠的处理方式不是无限等待，也不是简单重复发货，而是建立“可重试、可查询、可补偿、可审计”的完整链路。
一、先区分延迟与丢失
支付平台已经确认到账，而业务订单仍处于待支付状态，才属于通知链路异常。排查时应同时核对商户订单号、平台交易号、支付金额、付款时间和通知日志。若支付平台本身仍未确认到账，应继续按订单查询结果处理，不能提前修改业务状态。
二、通知端采用有限重试
通知失败后可使用指数退避，例如间隔 1 分钟、5 分钟、15 分钟、30 分钟再次发送。每次请求都记录响应码、响应内容、耗时和重试次数。达到上限后将订单转入待人工处理队列，避免无限重试占用资源。
三、业务端必须保证幂等
同一笔支付通知可能重复到达。业务系统应以商户订单号或平台交易号作为唯一键，在数据库事务中完成状态检查和业务交付。只有订单从“待支付”首次变为“已支付”时才能发货、充值或开通服务。后续重复通知只返回成功，不得再次执行交付。
四、增加主动查询作为兜底
对超过预期时间仍未完成的订单，定时任务可以调用订单查询接口。查询结果确认成功后，仍然走同一套幂等入账逻辑。这样即使异步通知长时间不可达，也能通过主动查询恢复订单。
五、设计人工补单流程
人工补单前应核对订单号、交易号、金额、收款账户和到账时间，并记录操作人、原因和处理时间。补单入口必须复用正常支付成功的业务流程，避免后台直接改数据库造成发货记录、余额流水和订单状态不一致。
六、建立监控和告警
建议监控通知成功率、平均延迟、重试次数、待补单数量和异常金额订单。连续失败或延迟明显升高时及时告警，同时保留完整日志，方便定位网络、签名、证书、应用错误或数据库锁等待问题。
稳定的码支付系统应把通知视为可重复的消息，把订单状态视为唯一事实来源。通过有限重试、幂等处理、主动查询和人工补偿，可以在异常发生时恢复业务，又避免重复发货和重复入账。
