点击支付后，订单停在哪一步

易支付接口对接不成功，先留意失败发生的时间。用户点击支付后就报错，或一直拿不到支付链接，问题多半还在网站向支付接口发起请求的阶段；页面已经跳转、付款也完成，但本站订单仍显示“未支付”，则要查看支付结果有没有传回网站。

这两个现象容易混在一起，因为用户看到的都是“订单没完成”。只改前端的成功提示，无法让后台订单自动入账；反过来，支付请求尚未成功时，反复修改回调地址也难有进展。记录一次测试对应的本站订单号，以及发起请求、跳转和返回页面的时间，后续查日志才不会把不同订单的报错拼在一起。

如果请求阶段直接返回签名错误，核对商户标识、密钥和接口文档要求的签名规则。参与签名的字段、排序方式或编码与平台要求不一致，都可能导致请求被拒绝。查看日志时保留错误信息即可，密钥不要写进公开截图，也不要直接发给无关人员。

付款完成了，本站订单仍显示未支付

在类似情况下，假设一个网站能正常跳转到收银台，测试付款后也返回了网站页面，订单却一直没有更新。开发者只检查浏览器跳转地址，看到“支付成功”字样，便以为易支付没有返回结果。随后查看服务器记录，发现支付平台发往异步通知地址的请求收到了 403 响应：这个地址被网站的登录限制拦住了。

浏览器返回页面供用户查看，异步通知则由支付平台请求网站服务器；两者不能互相代替。这个情境下，处理范围是通知地址对应的路由：允许平台请求到达该接口，同时保留签名校验，并核对通知里的订单号、金额和支付状态。不能因为要消除 403，就把整站的访问限制关掉，或让任何请求都能把订单改成已支付。

调整后，用新的测试订单观察通知请求能否进入接口、接口如何响应，以及本站订单何时更新。若此前那笔订单仍未入账，不要仅凭用户返回页面手动补单；先向支付平台核对交易结果，再依据可核对的交易记录处理。旧通知能否重新发送，取决于所用平台的规则，不能假定修改地址后它会自动补到。

日志显示收到通知，订单却没有变化

通知进入网站后，故障位置又往后移了一段。签名校验失败时，对照平台当前使用的密钥和签名规则；校验通过但订单没有更新，则查订单号能否匹配本站记录、金额是否一致，以及更新数据库时返回了什么错误。这里保留原始请求的必要记录和处理结果，往往比反复点击“重新支付”有用。

还要留意重复通知。同一笔支付结果可能被再次发送，订单处理应识别已完成的状态，避免重复发货或重复增加余额。网站向平台返回什么内容才算成功接收，应以所接接口的文档为准；仅在页面上输出“成功”，不一定符合通知接口要求。

测试仍未通过时，把一笔订单的请求时间、订单号、平台返回的错误信息和本站对应日志整理在一起，再联系接口提供方核对。上线前则用新订单走完付款、通知和订单更新的过程；仍卡在某一步，就停在那一步定位，不用用户端的“支付成功”提示代替后台结果。