易支付接口对接通常涉及两个动作：商户系统提交订单，引导用户付款；支付完成后，系统接收通知并更新自己的订单。页面能跳到收银台，只代表下单环节走通了。商品能否发放、会员能否开通，还取决于商户系统能否可靠地确认付款结果。

页面显示成功，订单仍停留在待付款

接入时常见的误会，是把用户付款后的页面跳转当作支付凭据。用户可能关闭页面，浏览器也可能没有完成跳转；即使成功返回，页面地址中的参数仍不适合直接触发发货。用于自动处理订单的依据，一般是服务端收到支付平台的异步通知，完成验签，并核对订单信息。

例如，一个售卖数字内容的网站接入易支付后，测试人员完成付款，收银台显示成功，网站订单却一直显示“待付款”。开发者起初检查的是页面返回地址，发现浏览器确实回到了网站。随后查看服务器日志，才发现异步通知请求未进入处理程序。此时继续修改页面提示，并不能让订单自动更新；排查方向应转到通知地址的配置与访问链路。

处理人员核对了提交订单时使用的通知地址和实际部署路径，并从外部访问该路径，确认请求能到达应用。接下来仍要等待平台通知并检查日志：接口被访问，与通知内容被正确解析、签名通过，是不同阶段。在这些信息确认前，先保留该笔订单的支付记录和平台侧状态，避免仅凭用户截图手动发放内容。

收到回调后，订单该怎样更新

通知进入应用后，先按当前易支付服务商的接口文档核验签名，再用商户订单号查找本地订单，同时核对金额和支付状态。不同服务商的参数名称、签名拼接方式及通知应答格式可能不同，不能直接照搬另一套接口的示例代码。密钥也不应放在浏览器脚本或公开仓库中。

回调还可能重复到达。订单已经标记为已付款时，再收到同一笔有效通知，系统可以按接口要求回应，但不能重复发货或重复增加余额。若业务处理失败，也不要提前向平台返回“处理成功”；否则平台可能停止重试，而本地订单仍未完成。涉及库存或发放动作时，支付状态更新与业务执行之间的记录要留清楚，便于定位卡在哪一步。

用户主动刷新页面时，前台可以展示本地订单的当前状态。若长时间没有收到通知，再通过服务商提供的订单查询接口核对支付结果；不要因为浏览器显示“支付成功”，就绕过验签直接改库。平台侧已付款、本地仍待付款的记录，应单独整理，供人工核对与补处理。

上线前，把测试延伸到回调和对账

测试不宜停在“能打开支付页面”。至少走完付款、异步通知、订单更新这一条链路，并重复发送同一笔通知，观察业务是否只执行一次。随后检查通知失败时留下的日志：请求有没有到达、验签在哪一步失败、系统返回了什么内容。这些记录比一句“回调异常”更便于后续定位。

正式接入前，还要确认当前使用的接口文档、商户配置与测试环境一致。有些参数在测试时由开发者临时填写，上线后换了域名或部署路径，通知就可能落到旧地址。支付金额、商户订单号与平台交易记录应能对应起来，方便日后核对退款或遗漏订单。

如果眼下已有“付款成功但未发货”的订单，先核对平台交易记录与本地订单号，保留回调日志，再修复通知链路并处理这笔订单。修复后重新测试一次完整付款过程，不要只用修改订单状态的方式验证。