用户扫码后回到网站，页面显示“支付成功”，但会员权限还未开通；也有用户付款后直接关闭页面，后台却已经收到通知。这两种现象说明，浏览器页面跳转与服务端订单确认并不是同一件事。把两者分开处理，能减少误判与重复付款。
一、返回页负责展示，服务端负责确认
同步返回通常由用户浏览器发起，目的是把用户带回商户网站。用户可能关闭页面、网络断开或手动刷新，因此不能把“访问到成功页”当成唯一的付款依据，也不能信任地址栏中未经服务端验证的成功参数。
异步通知通常由支付服务向商户服务端发送。商户应按所接平台文档验证通知，核对订单归属、金额与状态，再更新本地订单。通知可能延迟或重复，浏览器返回也可能先于通知到达。具体字段名、签名方法、成功应答格式与重试机制，以实际接入平台文档为准。
二、让支付结果页读取可信的订单状态
结果页拿到订单标识后，应请求商户自己的服务端查询订单。服务端先校验当前用户是否有权查看该订单，再返回必要的状态与展示信息。不能因为请求中带了一个真实订单号，就允许任意访客读取付款与商品信息。
页面可以区分“等待付款”“正在确认”“已确认付款”和“需要人工核对”等状态。其中“已确认付款”也不一定等于“商品已交付”，会员开通或数字内容发放应另外展示处理结果。
三、通知尚未到达时，避免催促重复付款
用户自述已付款、本地订单仍在等待确认时，可以显示“付款结果正在确认，请稍后刷新订单”，并保留订单查询入口。前端可以按有限频率查询本地状态，到达等待上限后停止自动刷新，转为提示稍后查看或联系客服。
不要把前端倒计时结束直接解释为付款失败，也不要在状态不明时自动创建一笔新支付订单。若实际平台支持服务端订单查询，可按其接口权限、频率限制与状态定义进行核验；未确认平台具备该能力前，不应自行拼接猜测的接口。
四、回调与查询必须汇入同一套处理规则
如果通知和主动查询先后确认同一笔付款，两条路径应调用相同的校验与订单更新逻辑。完成状态转换前再次检查当前记录，避免重复入账或重复开通权限。订单已确认后，浏览器反复刷新只能更新显示，不能再次执行发货。
遇到金额不符、订单不存在或记录相互矛盾时，应保留待核对状态和审计记录，不要为了让页面看起来成功而强制更改结果。
五、上线前至少测试六种情况
正常付款后返回网站，订单与交付状态准确展示。
付款后关闭浏览器，服务端仍能独立处理有效通知。
返回页先打开、通知稍后到达，页面能从确认中更新到正确状态。
通知重复到达或结果页多次刷新，没有重复交付。
修改地址栏参数或查询其他用户订单，不能伪造成功或读取他人信息。
通知暂时不可用时，页面有明确的查询与人工核对入口。
联调应使用平台提供的测试环境或明确批准的测试订单，不要通过伪造生产通知验证真实交付。相关基础流程可阅读码支付接入流程；接入参数请从码支付首页进入开发文档核对。
通用异步通知设计参考：Stripe 官方 Webhook 文档。该资料用于说明服务端通知的设计原则，不代表本站采用 Stripe 的接口、签名或应答规则。
