支付回调不是最后一步：验签、幂等与日终对账

01 / 明确结果来自哪里

用户从收银台返回，并不能证明支付完成。支付页面可能被关闭，跳转参数可能被修改，银行侧处理也可能尚未结束。前端应展示处理中并按订单号查询服务端状态，不直接根据 URL 参数发放权益。

接收渠道通知时，按照当前商户协议验证签名、商户标识、订单号、金额与币种。签名通常涉及原始报文或约定字段排序，不能先随意转换 JSON 再假设签名仍可验证。具体算法以渠道协议与实际商户配置为准。

验证失败时保留足以排查的摘要与错误类别，不将完整支付凭据写入公开日志。限流需要兼顾渠道正常重试，避免因一段时间的重复通知而完全阻断支付确认链路。

02 / 让重复通知安全落地

为渠道事件或交易建立稳定的唯一键，在事务内核对订单状态并写入处理结果。同一笔交易已完成时，重复通知只返回渠道约定的确认，不再次扣库存、发送兑换码或创建账本记录。

可以先可靠保存通知再异步处理，但落盘失败时不能回复已接收。后台任务必须可重试，并将事件与内部订单及渠道流水关联。订单已取消却收到成功通知时，进入明确的补偿或人工核查流程，而不是静默丢弃。

03 / 用对账补齐通知缺口

通知可能长时间不到达，或在应用不可用期间耗尽重试。定期拉取渠道账单或主动查询交易，与内部支付账本比对，让资金闭环不完全依赖一次 HTTP 回调。

先统一时间区间、时区、币种与金额尺度，再按渠道流水和商户订单匹配。内部缺单、外部缺单、金额不一致与退款差异应分类处理；只比较某天总金额相等，可能掩盖多笔方向相反的错误。

保留对账批次、原始账单摘要、匹配规则版本与人工调整记录。差异修复通过有权限的业务动作执行，不能直接修改历史账本以消除告警。尚未解决的差异需要负责人、处理时限与升级路径。

04 / 上线前验证失败分支

使用渠道沙箱或受控环境覆盖重复通知、乱序通知、验签失败、金额不一致和服务重启。特别验证数据库已提交而回复渠道前连接断开的场景，确保下一次通知仍可安全处理。

监控支付发起到最终确认的耗时、待确认订单数量和对账差异年龄。这些指标用于识别积压与渠道异常，不应脱离测量环境成为性能承诺。

生产接入前再次确认渠道 ACK 格式、通知重试策略、退款接口与商户权限。沙箱验证不能代替真实商户配置核对；受控生产验证应具备可追溯的测试订单和退款处理。

• 按官方协议验签，并核对商户、金额与币种。
• 重复、乱序和晚到通知不会重复发放权益。
• 超时状态有查询任务，对账差异有明确负责人。
• 受控生产验证覆盖实际商户配置与完整退款闭环。