易支付对接易商户，目标是让付款结果可靠地进入订单处理链路。能打开收银台只是其中一环，用户付款后，易商户还要确认交易、更新订单，并按业务规则交付商品或服务。

“完整版”对接涉及下单、通知和订单处理的衔接。仅凭产品名称无法确定接口细节：不同部署版本采用的请求方式、签名规则和通知响应可能有差异，具体字段以正在使用的接口文档为准。

后台填入参数后，还要核对接口版本

如果当前易商户版本提供易支付兼容接口入口，就按该入口的说明配置。易支付侧提供的接口地址和商户凭据，要与所用接入方式一致；复制其他站点的配置，可能遇到域名正确、接口路径却不匹配的情况。

下单返回签名错误时，直接核对参与签名的字段和拼接规则。空值是否参与、金额格式如何处理，都可能影响签名结果，不要靠反复更换密钥碰运气。密钥只保存在服务端，前端页面和可公开访问的日志里不留完整凭据。

发起支付的金额由服务端订单确定，不能直接采信浏览器传来的价格。订单号也要保留稳定的对应关系，否则用户重试付款时，本地订单与支付平台交易可能难以匹配。

用户已经付款，易商户订单仍未更新

用户返回网站看到“支付成功”，与服务端收到付款通知是两件事。浏览器跳转可能被关闭，也可能被伪造；订单入账应依据通过验签且符合订单信息的异步通知，或通过文档支持的服务端查询确认。

假设有这样一种情况：联调时付款页面显示完成，易商户后台的订单却一直待支付。维护者查看通知记录，发现易支付已请求回调地址，但网站返回的是登录跳转页面。继续检查路由后，发现支付通知入口也被后台登录校验拦住了。

这条处理线不涉及重建订单。维护者将该通知入口从登录校验中单独放行，保留支付验签，再按易支付文档要求返回响应内容。放行登录限制不代表接受任意请求：通知中的商户标识、订单号和金额仍要与本地记录核对，付款状态也要满足接口约定。

接下来的联调继续观察通知能否进入订单处理逻辑。若请求已经到达，但仍返回错误，就沿着这笔订单检查验签记录和状态更新日志，不同时改动多个配置。此前那笔待支付订单暂时保留原状态，待服务端查单确认后再处理；仅凭用户截图，无法排除付款对应另一笔订单的情况。

准备上线时，补齐重复通知和异常订单处理

支付平台可能重复发送通知。订单已完成后再次收到同一交易，业务侧不能重复发货或重复增加余额。处理时围绕唯一订单进行状态判断，配合数据库事务或等效的并发控制，让重复请求得到符合接口要求的响应，同时不再执行交付动作。

正常付款链路跑通后，测试还要覆盖用户关闭支付页面、同一通知重复到达的情况。若当前版本支持查单，未收到通知的订单可进入补查；若没有现成能力，就保留异常订单记录和人工核对入口，不把长时间待支付直接改成失败。

上线前，整理实际使用的接口地址与回调地址，确认测试配置没有混入正式环境。再检查一笔订单从创建到交付的记录能否对应起来，并补测通知中断后的处理。尚未完成的查单或重试能力写清现状，维护人员据此接手未处理订单。