付款成功后，页面跳回了网站，订单仍未更新

用户付完款返回商户页面，看到“支付成功”，后台订单却还是待支付，这是对接易支付时常见的困惑。收银台跳回商户网站，一般由同步跳转地址 return_url 承接；它主要用于展示页面，用户关闭浏览器或网络中断时，这次跳转可能根本不会发生。

订单入账通常依靠异步通知地址 notify_url。支付平台确认交易后，向商户服务器发起请求，带上商户订单号、平台交易号、金额、交易状态及签名等信息。商户系统核实通知，再修改本地订单状态。因此，不能仅凭用户浏览器跳到了成功页，就把订单标记为已付款。

这里还要确认“码支付”指的是哪一方的接口。若码支付负责实际收款、易支付作为接入层，通知是先到易支付，再由易支付通知商户，还是码支付直接通知商户，取决于实际部署方式。沿着收款平台、易支付、商户站点这条链路查通知地址，才不会把回调配置到错误的一端。

通知地址已填写，服务器却没有收到请求

假设有这样一种情况：商户站点配置了 return_url 和 notify_url，测试付款后页面正常跳回，订单始终待支付。开发者起初反复修改成功页文案，后来查看服务器访问日志，发现成功页有访问记录，通知接口却没有请求记录。排查方向便转到异步通知链路。

他核对平台后台实际保存的通知地址，发现填写的是只能在本机访问的测试域名。浏览器在开发者电脑上能打开它，支付平台的服务器却无法访问。将地址改为已部署的公网接口后，先从外部网络访问该路径，确认请求能到达应用，再发起一笔测试订单，查看平台提供的通知记录与商户日志。至于通知失败后平台会不会重试、间隔多久，仍要以所接平台的接口文档和后台记录为准。

若访问日志已有请求，问题就不在“平台没回调”，而在接口收到请求后的处理。此时记录请求时间、商户订单号和处理结果；日志中的密钥、完整签名参数等敏感内容应避免直接暴露。

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

回调接口收到通知，不宜直接读取一个“成功”字段就改订单。先按当前接入平台的文档核对签名规则与密钥，确认消息确实来自预期平台；再用商户订单号找到本地订单，比对通知金额与下单金额，并确认交易状态为成功。不同易支付系统及码支付服务的参数名、签名算法和成功响应文本可能不同，照搬另一套接口的示例代码，容易出现“能收到通知，却始终验签失败”。

同一笔交易也可能收到不止一次通知。订单已经入账时，再次回调应识别为已处理，避免重复发货或重复增加余额。商户系统完成必要的订单记录后，按平台要求返回指定的成功响应；若接口报错、返回内容不符，平台可能继续重试。

遇到“用户已付款、订单未更新”，先保留商户订单号和平台交易号，核对支付平台的交易状态，再查通知是否到达、验签为何失败。不要仅凭用户提交的截图手工改成已支付。通知链路修复后，用一笔测试订单走完整个收款与回调过程，并检查重复通知到来时订单是否仍只处理一次。