下单请求发出后，页面没有进入收银台

易支付对接不成功，先确认失败发生在哪里。用户点击付款后，如果商户系统没有拿到支付链接或跳转地址，问题通常还停留在下单请求；若收银台已打开、付款也完成，却没有更新订单，就要转向回调链路。把两种现象统称为“支付接口坏了”，容易反复修改无关配置。

下单阶段保留商户发出的请求、平台返回的原始响应，以及对应的商户订单号。若平台明确返回“签名错误”，就按正在使用的接口文档核对签名：参与签名的字段、字段顺序、空值处理和密钥是否一致。不同易支付系统的接口实现未必相同，不能直接照搬另一套系统的签名代码。密钥不要写进排查截图或公开日志，核对时看配置来源和生成过程即可。

还有一种情况是请求根本没有到达平台。此时商户侧日志可能只留下连接超时、域名解析或证书校验异常，看不到平台业务错误码。继续改商品名称、订单金额没有作用，应检查服务器能否访问接口地址，以及所用地址是否仍与平台提供的文档一致。

付款已经完成，商户订单仍显示未支付

例如，一个网站接入易支付后，用户能进入收银台并完成付款，浏览器也跳回了网站，但后台订单一直停在“待支付”。这只是说明浏览器跳转成功，不能据此确认服务器已收到支付结果。用户可能关闭页面，跳转参数也可能被重复提交，因此订单状态通常应依据经验证的异步通知更新。

这时把排查范围收窄到一笔商户订单：查看支付平台是否发起了异步通知，商户服务器有没有收到请求，收到后停在哪一步。如果商户日志完全没有对应记录，核对提交订单时填写的通知地址，并检查外网能否访问该地址；本机地址、仅内网可访问的域名，都无法供平台正常回调。

若日志里已有通知，却仍未改订单，查看验签结果和商户返回内容。平台可能因验签失败而重复通知，也可能因商户处理完成后没有按其文档返回指定响应，继续重试。同一笔订单收到多次通知并不罕见，更新逻辑要识别重复请求，避免重复记账。

这笔示例订单可以暂时停在“平台显示已付、商户未入账”的状态。开发人员先保留平台交易号、商户订单号及回调日志，再对照平台订单记录确认支付结果；在核清前，不用浏览器跳转结果直接补写“已支付”。

改过配置后，旧问题还在重复出现

签名密钥、通知地址或接口地址调整后，确认运行中的服务已经加载新配置。有的项目修改了配置文件，却没有更新实际运行环境；也有项目在测试环境能下单，正式环境仍使用旧地址。此时对比两次请求的实际参数和响应，比盯着代码里的配置值更直接。

排查结束前，用一笔新的测试订单走完整链路，核对下单响应、支付结果、异步通知和最终订单状态。旧订单的回调仍可能继续到达，相关日志与订单号要保留，避免把重试通知误认成新故障。