接口能打开，先核对接入资料

易支付通常由支付平台提供收银台接口和支付结果通知接口。不同服务商的参数名称、签名规则、请求方式可能不同，手里的平台文档和商户后台配置应当对得上。仅凭一段网上复制的示例代码，页面即使能跳转，也无法确认后续订单能否正确入账。

动手前，把商户编号、密钥、网关地址及当前使用的接口版本放在一起核对。密钥保存在服务端，不写进网页脚本，也不随前端请求传给自己的下单接口。网站接到购买请求后，先生成本地订单并确定应付金额，再由服务端按文档组织参数、计算签名，提交到支付网关。订单号由自己的系统生成并保存，后面收到通知时才有依据可查。

签名是平台用来核对请求内容的凭据。字段排序、空值处理、拼接形式和算法，只按所接平台的文档实现；同样叫“易支付”，也不能直接套用另一家平台的签名函数。联调时可保留脱敏后的请求参数和平台返回信息，别把密钥或完整签名写进公开日志。

页面显示支付成功，订单仍未更新

用户付款后回到网站，常见的现象是页面显示“支付成功”，订单却还停在待支付。页面跳转由用户浏览器完成，用户关闭页面、网络中断，或前端代码未执行，都可能影响这个页面的显示。因此，浏览器带回的结果适合展示，不宜单独作为发货或开通服务的依据。

假设一家网站联调时，测试人员已在收银台完成付款，也看到了返回页面，但后台订单始终未更新。开发者起初反复修改返回页的跳转地址，订单状态没有变化。随后检查商户后台配置，发现异步通知地址仍指向旧测试环境。地址改为当前可从公网访问的服务端接口后，再发起一笔新的测试订单；这一步只解决“通知往哪里发”的问题，不能跳过对通知内容的核验。

该测试订单的后续处理要从服务端记录看起：通知有没有到达，签名校验有没有通过，通知中的订单号能否查到本地订单，金额是否与创建订单时保存的一致。如果平台支持重发通知，可按其文档在测试环境继续验证；不支持重发的情况下，不靠手工改订单状态冒充回调成功。旧测试环境里的记录也暂时保留，便于区分地址变更前后的请求。

收到回调后，检查订单为何重复更新

异步通知到达，不代表订单可以直接改成已支付。接口先按平台规则验签，再核对订单号、商户身份和金额。任一项对不上，记录必要信息供排查，不触发交付。若支付通知中的状态还未达到平台定义的成功状态，也不要仅凭“接口收到了请求”放行商品。

同一笔支付可能收到多次通知，回调接口因而要能重复接收而不重复履约。处理时以本地订单当前状态为依据：待支付订单在核验通过后更新，并记录平台交易号；已经处理过的订单不再次发货或重复增加余额。更新订单与记录交付结果之间若存在失败风险，还要按自己的业务设计事务或补偿方式，避免订单已标记成功、服务却未开通。

接口返回给平台的响应内容也按对接文档写。部分平台要求返回指定的纯文本，格式不符可能持续重试。联调结束前，整理一笔测试订单的创建记录、脱敏后的回调记录和最终订单状态，再检查正式环境的通知地址与密钥配置；测试配置不能直接照搬到正式环境。