易支付对接码支付，回调怎么配置，取决于码支付在当前系统中承担什么角色。没有具体版本和接口文档，无法直接给出通用回调地址；但付款成功后，通知经过哪些服务、由谁更新订单，可以沿实际请求查清。

回调地址填给谁，通知就发到谁

在易支付把码支付作为上游通道的接法中，通知一般分为两段：码支付将结果发给易支付的通道回调入口，易支付处理成功后，再通知业务网站。码支付后台填写的地址，通常是易支付对应插件提供的接收地址；业务网站下单时传入的 notify_url，则用于接收易支付的订单通知。

这两个地址不能混用。把业务网站的地址直接填进码支付后台，可能导致请求到达网站，但网站按易支付规则验签，无法识别码支付发来的参数。若使用的是业务网站直连码支付的方案，链路又不同，配置前要确认实际调用的是哪套接口。

return_url 主要负责付款后的浏览器跳转。用户关闭页面、网络中断，都可能让跳转没有完成。业务订单的支付状态应由服务端确认，不能凭“支付成功”页面或浏览器传来的参数直接更新。

钱已付，订单仍待支付，通知停在哪一段

出现这种情况，先对照码支付的通知记录与易支付订单状态。码支付已记录成功、易支付仍待支付，排查范围落在上游通知这一段；易支付已经显示成功、网站订单未更新，则检查易支付发往网站的通知和网站处理日志。

例如，假设业务网站的回调地址被统一登录规则覆盖。易支付发送通知时，请求被跳转到登录页，网站订单一直没有变化。接收日志里看不到订单处理记录，网关访问日志却能找到跳转响应，这时反复更换支付密钥并不能解决问题。

处理动作是把专用通知路由从登录校验中放行，同时保留支付签名验证。检查该地址的实际响应，确认没有继续跳转，也没有返回普通网页。若平台支持补发通知，用原订单触发补发；若不支持，就按接口提供的查询方式核对状态，不能把用户提供的付款截图当作自动入账依据。

这个情境下，路由调整后还存在一项待确认事项：回调处理程序返回的内容是否符合接口要求。HTTP 请求成功到达，只代表网络层通了；平台是否认可通知已处理，还取决于响应正文。

收到通知后，订单怎样更新和应答

回调处理程序收到参数后，按当前接口文档验签。签名字段的参与范围、空值处理和编码方式可能因版本不同而变化，直接照搬其他项目的签名函数，容易出现“参数都有，但验签失败”。

验签通过后，核对通知中的支付状态、商户订单号与订单金额。接口中的成功状态值、平台交易号字段，以实际文档为准。金额按确定的小数规则或最小货币单位比较，避免浮点运算让同一金额出现误差。金额不符或订单无法匹配时，保留必要日志，停止自动发货。

订单更新还要处理重复通知。上游没收到认可的响应，可能再次发送同一笔订单；网站将状态从待支付改为已支付时，采用数据库事务或原子更新，让发货动作只触发一次。已经处理完成的订单再次收到合法通知，返回接口认可的应答，不重复增加余额或发放商品。

确认支付结果已经可靠落库后，再返回平台规定的成功响应。部分接口使用纯文本 success，但具体内容仍以当前文档为准，响应中不要夹带调试输出或网页模板。

联调时，保存一笔订单的两段通知记录，核对请求到达的位置和响应正文；再用同一笔合法通知测试重复处理，确认订单状态与发货记录没有重复变化。