易支付对接易商户，目标是让用户付款后，业务系统能够确认订单并完成交付。支付页面能打开，只验证了发起支付这一段；收款成功后，订单状态如何更新，仍要单独验证。

“完整版”对接不能靠一份通用参数表完成。当前没有具体版本和接口资料，接口地址、字段名称、签名方式都不能直接套用。准备接入时，把两端正在使用的文档与后台配置放在一起核对，能减少后面反复修改代码的次数。

后台填完商户信息，支付请求仍被拒绝

先确认接入方向：哪一端创建业务订单，哪一端提供收款接口。易商户后台如果提供易支付兼容配置入口，就按该入口对应的接口说明填写；没有对应入口，则核实它支持的支付协议，不能仅凭产品名称判断兼容。

商户号和密钥正确，请求也可能被拒绝。字段参与签名的规则、空值处理方式以及字符编码，都可能影响验签。此时保留实际发送的请求内容，对照服务端返回信息定位差异，不要一边改金额格式，一边改签名算法，否则很难确定是哪次调整起了作用。

接口域名也要从实际服务商资料中确认。商户后台地址未必就是支付请求地址，网页能访问也不能证明接口路径正确。密钥只保存在服务端，排查时对日志中的密钥和敏感信息做脱敏，避免为了找错把凭证贴进工单或公开群聊。

用户已经付款，易商户订单还在等待支付

付款后的浏览器跳转，和服务端收到的异步通知，是两条不同的链路。用户可能直接关闭页面，跳转链接中的内容也可能被修改，因此不能仅凭“支付成功”页面给订单入账。业务系统通过验签后的通知或接口查询结果确认付款，并核对订单归属与金额。

假设有这样一种情况：收款后台显示交易成功，易商户中的订单却一直未支付。开发者查看接收通知的访问日志，发现请求没有进入业务处理代码，而是在网站安全规则处被拦截。支付页仍能正常打开，所以此前的页面测试没有发现这一问题。

这条处理线围绕通知入口展开。维护者核对回调地址，将该路径从要求浏览器验证的规则中单独调整出来，同时保留应用层验签。随后按接口支持的方式重发通知，或通过查询接口核对原订单；没有重发能力时，就继续保留这笔订单的待核对记录，不直接手工标记成功。

下一轮测试记录通知到达时间和订单更新时间。若请求已经进入程序，订单仍未变化，再查看验签结果与数据库写入情况。排查范围随着日志变化收窄，不必把整套接入配置重新填写一遍。

回调重复到达时，订单怎样避免重复交付

支付通知可能重复发送，网络超时也可能让发送方无法确认接收结果。业务系统不能每收到一次成功通知，就再次充值或发货。对同一笔订单重复处理时，只允许一次有效的状态转换；已经完成的订单，按接口约定返回应答，不再重复执行交付。

验签通过之后，还要核对通知中的金额与本地订单记录。金额比较使用统一的精度规则，避免直接用浮点计算结果作判断。前端传来的金额不作为最终依据，本地创建订单时保存的金额才用于核对。

上线验证保留一笔完整链路记录：从业务订单发起，到通知接收，再到交付状态更新。未收到通知的订单，保留查询和人工核对入口；查询能力、退款处理等功能是否支持，则按两端实际接口确认，不把“兼容易支付”当作全部功能均已实现。

准备切换正式收款前，核对当前回调地址与商户配置，补测重复通知下的订单处理。仍未解决的回调或状态异常，继续留在测试环境定位，不让真实付款承担验证工作。