有些故障并不发生在付款识别阶段：订单已经确认到账，但会员权限、卡密、下载链接或其他数字内容没有成功交付。如果系统只记录“已支付”，却没有独立记录交付结果，后续很难判断应该重试、人工补发，还是已经执行过但响应丢失。
一、先把支付状态与交付状态分开
支付确认回答的是“这笔订单是否收到有效付款”，业务交付回答的是“用户购买的权益是否已经正确生成并授予”。两者发生在不同步骤，应分别记录状态、时间和失败原因。
例如，订单可以是“已确认付款、等待交付”“已确认付款、交付处理中”“已交付”或“交付需人工处理”。不要因为交付失败就把已经确认的付款改回未支付，也不要用浏览器是否停留在成功页判断交付是否完成。
二、定位失败发生在哪个环节
核对商户订单号、用户、商品和实付金额，确认处理的是同一笔订单。
查看有效通知到达时间与订单状态变更记录，确认支付确认已经完成。
检查交付任务是否创建、何时开始、执行了几次，以及最后一次结果。
检查库存、权限服务、数据库、消息队列或第三方业务接口的错误。
从用户账户查询最终权益，不能只看任务返回“成功”。
日志中应使用订单号或内部任务号关联整个过程，同时隐藏密钥、完整收款信息和用户隐私。系统时间与时区保持一致，能减少排查顺序错误。
三、重试前必须确认操作是否幂等
如果同一交付任务重复执行两次，会员时长是否会重复增加、卡密是否会发出两份、余额是否会重复入账？在没有明确答案前，不应盲目点击补发或重新发送通知。
可以为每次业务交付使用稳定的幂等标识，例如商户订单号与交付动作的组合。执行前检查是否已有成功记录，并在数据库层约束不能生成重复的唯一权益。遇到超时而结果未知时，先查询最终业务状态，再决定是否重试。
四、自动重试要有次数、间隔和终点
网络瞬断或下游短时不可用可以重试，但应采用有限次数和逐步延长的间隔，避免故障期间持续轰击依赖服务。参数错误、商品配置缺失、库存不足等通常不会通过重复请求自行恢复，应直接转为待处理状态。
每次尝试记录开始时间、结束时间、结果和错误分类。达到重试上限后生成可追踪的人工任务，并停止自动执行；问题修复后，由受权人员在确认当前权益状态后恢复任务。
五、人工补偿需要可审计
后台应展示订单、付款确认、商品、预期权益、当前权益与历史尝试。人工操作前再次查询用户实际状态，并要求记录原因和操作者。补发成功后更新交付状态，保留原失败记录。
涉及退款、金额调整或资金账户的操作，应按实际平台与业务流程办理，不能通过直接修改数据库状态替代正式处理。无法确认付款或订单归属时，先暂停交付并联系用户核对必要信息。
六、给用户清晰但克制的状态提示
付款已确认但交付未完成时，可以显示“付款已确认，内容正在处理”，并提供订单查询或客服入口。不要提示用户重复付款。状态页只显示当前用户有权查看的信息，不公开内部错误、密钥或其他订单数据。
上线前验证这些场景
正常付款后只交付一次，刷新页面不会重复执行。
通知重复到达、任务重复投递时，最终权益仍只有一份。
交付服务超时但实际成功时，系统能够通过查询避免重复补发。
库存或配置错误时，任务转为可追踪的待处理状态。
人工补发后，审计记录、用户权益和订单展示保持一致。
支付通知的签名、应答和订单字段应以实际接入文档为准。关于付款确认与页面展示的分工，可参考同步返回与异步通知指南；关于重复通知处理，可参考防止重复发货的方法。
