下单接口通了，订单却还没支付

易支付通道对接时，最直观的测试是提交订单后能否打开收银页面。但页面正常跳转，只能证明下单请求完成了这一段。用户付款后，商户系统还要依据通道返回的支付结果更新订单；如果这一段没有走通，就会出现“钱付了，商品没发”或“用户已经付款，后台仍显示待支付”。

接入前，先向通道方确认当前使用的接口文档和商户配置。下单请求中的商户订单号、金额、回调地址，以及签名所用的参数规则，都要与实际环境一致。不同服务方可能采用不同字段和通知方式，不能拿另一套易支付接口的示例代码，仅替换商户号就投入使用。

用户付款后，页面显示成功但后台没变化

支付完成后的页面跳转，主要给用户看；服务端支付回调则用于通知商户系统处理订单。用户关闭页面、网络中断，或浏览器没有顺利跳回，都可能影响前者。因此，不能把“用户看到了成功页”直接当成发货依据，也不宜只凭页面返回的参数修改订单。

例如，假设一家销售数字商品的商城接入易支付通道。测试人员付款后看到成功页，商城订单却仍是“待支付”。开发人员先按商户订单号查本地记录，确认下单时保存的金额与订单对应，再查看服务端有没有收到该笔支付回调。如果日志中没有通知记录，排查会落到回调地址是否填对、外部请求能否到达，以及接口收到请求后是否按文档返回了确认信息；如果通知已经到达，却被系统拒绝，就继续核对签名、金额和商户订单号。

这条处理线暂时不会靠手工把订单改成已支付来结束。商城可以通过通道提供的订单查询能力核对支付状态，同时保留本地请求和响应记录。数字商品尚未交付时，先限制自动发货；已付款订单如何交付或退款，则依据核实后的状态处理。回调问题修复后，还要重新发起测试订单，观察通知到达、验签、订单更新是否连续完成。

回调重复到达，订单处理了两次

回调并非只会出现一次。通道没有收到符合约定的响应时，可能再次发送通知；网络延迟也可能让两次通知先后到达。商户系统处理同一个商户订单号时，要核对订单当前状态，让已经完成的订单再次收到通知后只返回处理结果，不重复发货或重复记账。

验签也不能省。收到“支付成功”字段，并不代表通知一定来自所接通道；签名校验通过后，仍要比对商户号、订单号和金额，再更新对应订单。密钥留在服务端，不放进网页或客户端代码。测试环境与正式环境若使用不同配置，上线前还要分别核对，避免测试订单正常、真实付款却无法更新。

对接完成前，可用一笔测试订单串起下单、付款、回调和订单查询。若支付状态仍不一致，保留商户订单号、请求时间及脱敏后的接口日志，按这笔订单继续与通道方核对；不要只凭成功页面截图判断交易已经处理完毕。