易支付使用接口对接，常见需求是让用户从业务订单跳转到收银台，付款后自动开通服务或发货。支付页面能够打开，只完成了链路的一部分；订单状态怎样确认、到账后怎样触发业务处理，还要由服务端衔接。

不同平台即使都使用“易支付”这一名称，接口版本和签名规则也可能不同。接入时以实际服务商提供的文档为准，网上找到的示例代码只能作为参考。

请求发出后，签名一直不通过

签名失败时，直接更换密钥或反复提交，往往定位不到问题。把本地参与签名的字符串与文档中的拼接规则核对，才能发现参数排序、空值处理或编码方式上的差异。

金额也会影响校验。同一个金额在程序里经过数值转换后，文本格式可能变化；如果签名使用一种格式，实际提交又使用另一种格式，校验就可能失败。订单金额由服务端根据商品和订单记录生成，前端传来的价格不能直接用于收款。

有的平台采用参数拼接后计算摘要，有的平台使用其他签名方式。不要把某份示例里的算法直接套到另一套接口上。联调日志记录参与签名的字段和请求响应，密钥不写入日志，也不放进网页脚本。遇到无法解释的差异，把脱敏后的请求内容交给平台技术支持核对，比只发送“支付失败”的截图更容易获得有效回应。

付款完成后，订单仍停在待支付

浏览器跳回商户页面，不能作为发货依据。用户可能关闭页面，跳转参数也可能被修改。业务系统应依据经过验证的服务端异步通知更新订单；通知缺失或处理失败时，再通过平台提供的查单接口核验。

例如，假设一个售卖数字内容的网站已经接入收银台，用户付款后返回网站，订单却仍显示待支付。服务器访问日志中能够找到通知请求，但响应内容是登录页。沿着这条记录检查，发现支付通知地址被网站统一登录校验拦截，订单处理代码根本没有执行。

这个情境下，调整的是通知地址的访问规则：让平台请求能够进入处理逻辑，同时保留签名校验，不能把整个订单接口都开放。通知进入后，还要把其中的商户订单号和金额与本地记录对应起来。签名正确但金额不符的请求，不进入发货逻辑。

调整后，未更新的订单仍需核验。平台是否重发通知、重试会持续多久，取决于它的实际机制。开发者保留受影响的订单记录，通过查单确认支付状态，再处理遗漏的交付；不能仅凭用户返回了成功页面就批量补发。

重复通知到达时，避免再次发货

通知可能因响应超时而重发，同一笔支付也可能被并发处理。订单从待支付变为已支付时，用数据库条件更新或事务限制状态转换，只有成功完成这次转换的处理逻辑才触发交付。这就是幂等处理在支付业务中的具体作用。

支付状态已经写入、交付却未完成的订单，要留下可重试的任务记录。收到重复通知时，系统核对已有状态，而不是再次开通服务。通知确认响应按平台文档返回，不能照搬其他接口要求的文本。

上线前，用测试订单核对正常通知和重复通知的处理结果，并确认查单能力。正式收款前还要核对服务商主体及结算约定，接口调通本身无法证明服务可靠。下一轮联调，就从待支付订单的通知日志和未完成的交付记录查起。