用户完成微信支付后，浏览器跳回成功页，订单仍显示“待支付”，排查时不要只盯着页面。页面跳转发生在用户设备上；微信支付异步通知由微信支付服务器发往商家服务器，两条链路互不替代。页面即使关闭，回调接口仍要能独立更新订单。

创建支付订单时，回调地址填在哪里

接入微信支付 API v3 时，在创建支付订单的请求中填写 notify_url。它是商家服务端接收通知的地址，不是付款后展示给用户的页面地址。接口必须能从公网访问，接收微信支付发来的 POST 请求，并避免跳转到登录页或其他地址。

填写前，把测试环境和正式环境的域名分开核对。常见的偏差是代码调用了正式支付接口，却把 notify_url 留在测试服务器；用户能够付款，正式订单库却一直没有变化。后台若有网关、反向代理或访问控制，也要确认回调路径没有被拦截。

微信支付不同版本的接口报文和应答格式并不相同。若项目使用的是 API v2，不要照搬 API v3 的通知解析与响应代码；先确认创建订单调用的是哪一版接口，再对照该版本的官方文档处理。

收到通知后，订单为什么还没变

假设一家商店把回调地址接到了新接口，付款后服务器日志已经出现请求，订单却仍是待支付。排查发现，接口按普通表单读取参数，拿不到 API v3 通知的 JSON 报文，于是直接返回错误。此时继续改支付成功页没有作用：请求已到达，问题落在回调接口的解析和处理上。

开发者将接口改为按 API v3 通知格式读取报文，先验证通知签名，再用 API v3 密钥解密资源数据。验签用于确认消息来源和内容未被篡改，不能因为请求里写着“支付成功”就直接发货。解密后，还要核对商户订单号、支付状态和订单金额，再把本地订单更新为已支付。

改动上线后，仍需用一笔测试订单观察完整链路：服务器是否收到请求、验证是否通过、数据库是否成功提交。若处理失败，接口应按对应版本的协议返回失败响应，便于微信支付重试；成功处理后再返回成功响应。此前那笔待支付订单则要通过查单接口核实支付结果，不能靠重新打开成功页补状态。

回调重复到达，或一直没有到达

同一笔交易的通知可能重复发送。订单更新逻辑要具备幂等性：订单已经记为已支付时，不再重复增加余额、生成发货任务或发放权益。把订单状态变更和后续业务记录放进可靠的事务处理，并记录通知中的交易信息，排查时才分得清“收到两次”和“处理了两次”。

如果日志里完全找不到请求，检查创建订单时实际提交的 notify_url，再查看域名解析、HTTPS 证书、网关和服务端访问日志。若接口收到了请求却没有更新订单，沿着验签、解密、订单核对及数据库写入的位置查错误记录。

异步通知可能延迟或因网络问题暂时无法送达。对状态长时间未更新的订单，可调用微信支付查单接口核实，再处理本地订单。下一次联调时，保留创建订单请求中的回调地址和服务端接收日志，用同一笔测试订单把这两端对应起来。