易支付API接入看起来是把订单信息提交给支付接口，再接收支付结果。但页面跳转顺利，并不代表商户系统已经确认收款。接入前先核对所用平台的接口文档：不同平台在参数名称、签名规则、通知内容和返回格式上可能不同，不能直接照搬另一套代码。

支付页面返回了，订单仍显示未付款

用户完成支付后，浏览器可能跳回商户页面。这个页面适合展示“正在确认支付结果”，不宜单凭跳转地址中的参数把订单改成已付款。用户可能中途关闭页面，跳转也可能失败；反过来，浏览器到达了页面，服务端却还没收到支付平台的通知。

假设一个网站接入易支付后，用户反馈“钱已付，订单没开通”。开发者检查发现，支付完成后浏览器返回正常，但接收异步通知的地址一直没有留下请求记录。此时反复修改前端成功页没有帮助。处理方向转向通知链路：核对提交订单时填写的通知地址与线上实际路由是否一致，再检查该地址能否被平台访问。若请求已到达服务器，还要查看应用是否在验签或读取参数时提前报错。

这类排查不宜直接把用户截图当作改订单的依据。截图可用于定位订单，最终状态仍要通过平台通知或文档提供的订单查询接口核对。若平台暂时没有返回可核对的信息，先保留待确认状态和相关日志，避免同一笔订单被人工开通后，又被迟到的通知处理一次。

通知到了，为什么还要核对订单

异步通知可能重复发送。商户系统收到通知后，按当前平台文档验签，并用商户订单号找到原订单；金额及支付状态也要与本地记录对应。验签失败的通知不能用来更新订单。即使签名正确，金额与原订单不符，也应停下自动交付，保留记录供排查。

订单状态更新还要考虑重复通知。已处理过的订单再次收到同一笔成功通知时，接口按文档要求响应即可，不要重复发货、充值或开通服务。对于“更新订单”和“发放权益”分开执行的系统，单纯判断页面上显示“已支付”还不够：中间一次异常可能造成订单改了状态，权益却没有发放。把支付处理结果与交付记录关联起来，后续补处理才有依据。

回调接口给平台的响应内容也要对照文档填写。服务器已经处理成功，却返回了平台不认可的内容，平台仍可能继续通知；把重复通知直接视为攻击，又可能漏掉正常的重试。

上线前留出一次完整的支付验证

发起支付时，商户订单号由自己的系统生成并保存，签名密钥留在服务端，不放进网页或移动端安装包。日志记录订单号、接口响应和通知处理结果即可，密钥及完整敏感参数不要原样写入日志。签名总失败时，再按文档逐项核对参与签名的字段、排序与编码方式，不要靠更换密钥反复碰运气。

上线前用测试订单走完整链路：创建订单、完成支付、接收通知、更新状态，并观察重复通知会不会造成重复交付。还要试一次用户付款后关闭浏览器的情形，确认订单不会依赖返回页才能完成处理。如果测试支付只能在正式环境进行，就控制测试范围，并按平台规则处理测试款项。测试结束后，核对仍处于“待支付”或“待确认”的订单记录，再开放给真实用户使用。