看到一笔“支付成功”，只完成了上线验收的一部分。一次可靠的验收还应回答：顾客关闭页面后怎么办、通知重复时会不会多发货、退款后权益如何调整、发生故障时谁来处理。

先验证完整业务闭环

从真实入口下单，核对商品名称、金额和业务订单号；完成付款后，同时检查支付记录与业务履约记录。购买会员应能看到正确的有效期，购买实物应生成待履约记录，购买数字商品应拿到正确的交付内容。

对每种计划使用的终端分别执行一次。电脑扫码成功不能证明手机浏览器跳转正常，应用内支付成功也不能替代小程序环境测试。把终端、网络环境和测试时间写在结果中。

重点测试“不顺利”的情况

  • 在付款前取消或返回，原订单应保持可解释的状态。
  • 连续点击支付按钮，检查是否出现重复支付单以及如何展示已有订单。
  • 暂时延迟通知，确认服务端查询能够补齐状态，而不是直接要求顾客再次付款。
  • 重放合法通知，确认发货、积分或额度只增加一次。
  • 提交错误签名、金额或商户信息，确认业务不会被错误更新。

失败用例不能只记录“没有报错”。应同时检查数据库记录、处理日志和用户页面，证明该发生的业务动作执行了，不该发生的动作没有执行。

把退款纳入验收

建立退款单并关联原支付单，核对申请金额、已退款金额以及最终查询结果。若有部分退款场景，分别验证首次退款、再次退款和超过可退金额的处理。权限不具备时，应明确提示并停止操作，不能显示虚假的退款成功。

业务侧还需处理库存、课程、会员或分账记录的变化。支付退款与业务权益回收是不同任务，应记录各自是否完成，便于失败后人工跟进。

准备上线观察与回退

记录本次发布的代码版本、参数变化、负责人和恢复步骤。上线初期关注订单成功状态、通知错误、重复履约及退款异常；出现异常时先保留原始订单证据，再决定停用入口、修复还是回退配置。

回退不能抹掉已发生的交易。新旧版本都应能识别各自产生的订单，并继续接收必要的通知。接口字段可核对支付创建文档，异常处理可参考订单问题排查。