接入易支付时，调出付款页面只是交易链路的一部分。用户付完款后，网站还要确认对应订单、核对金额，再更新状态或发放商品。搜索“易支付对接接口”，除了找请求示例，还要弄清手中的文档对应哪个平台、哪个版本，以及付款结果如何传回自己的系统。

示例能运行，换到自己的平台却报错

“易支付”这一名称下存在不同平台和兼容实现，接口路径、签名方式可能有差异。网上找到的代码能在演示站运行，复制到自己的项目后却提示签名错误，未必是密钥填错。

拿商户后台提供的文档核对当前代码，重点查看请求入口与签名规则。部分传统实现采用参数排序后拼接密钥的方式，其他实现可能不同，不能把某份示例里的算法当成统一标准。空值是否参与签名、字符串怎样编码，都可能影响验签结果。

排查时，保留脱敏后的请求内容和参与签名的原始字符串，与平台示例逐项比较。金额经过浮点运算后被改写，或中文商品名称在编码转换中发生变化，都可能让两端签名不一致。密钥留在服务端，不放进网页脚本，也不把含密钥的调试信息贴到公开论坛。

文档没有写清的地方，向平台确认具体规则；仅凭“兼容易支付”几个字，无法确定所有接口行为。

用户已付款，网站订单仍显示待支付

同步跳转是用户付款后浏览器返回商户页面的动作，异步通知则由支付平台向商户服务器发送。用户关掉页面、网络中断，都可能使跳转没有完成。订单确认应以经过验签和业务核对的服务端结果为依据，而不是凭浏览器显示“支付成功”就发货。

例如，一个接入易支付的数字商品网站，付款页显示成功，后台订单却仍是待支付。开发者查看访问日志，发现返回页面收到请求，通知地址没有访问记录。此时先排查通知能否抵达网站，不急着修改订单状态。

在这个假设情境中，通知地址被登录校验拦截，平台请求拿到的是登录页面。开发者将该地址从登录校验中单独放行，但保留支付签名验证。补发通知后，请求进入处理程序，再核对商户归属、订单金额及支付状态，确认匹配后更新订单。

原来那笔交易仍要通过平台订单查询或商户后台核实。若平台不支持补发通知，就依据查到的交易记录补单，并保留处理记录；不能把未收到回调的订单直接标记为成功。

通知重复到达，商品会不会再次发放

异步通知可能重复发送，尤其是商户响应超时、返回内容不符合平台要求时。接口对接程序要容纳这种重复，不能把每次通知都当成一笔新交易。

同一订单第一次确认成功时更新状态，后续通知识别到已经处理，就按平台文档返回确认内容。检查状态和修改状态之间若没有并发控制，两个请求仍可能同时通过检查。数据库条件更新或唯一约束，能够限制同一笔订单重复进入履约处理。

发货、充值等动作也要保留独立的处理记录。订单已经改成已支付，发货服务却暂时失败时，后续任务处理的是未完成的发货，不应再次增加支付金额或重复记账。

上线前，用平台允许的测试方式走通一笔完整交易，核对回调验签、金额匹配和订单更新。再检查重复通知到达后的处理结果，以及暂未确认订单的查询入口。后台仍有待支付记录时，先查平台交易状态，再决定补单或继续等待通知，留下本次查询与处理记录。