拿到商户信息后，先核对接口类型

“易支付对接码支付”常被理解为填入商户号和密钥就能收款，但“易支付”可能指站点使用的支付系统，也可能指某种接口格式；“码支付”则可能是提供聚合收款接口的服务，也可能依赖收款码与到账通知完成订单匹配。名称相近，不代表请求地址、签名规则和订单状态通知能够直接通用。

拿到码支付服务方的对接资料后，先找创建订单与查询订单的接口说明。站点现有插件如果只支持某一种易支付接口格式，而服务方提供的是另一套字段，就要找对应插件或增加适配层，不能仅改一个网关地址。签名算法、参与签名的字段顺序和金额单位也要按实际文档核对；其中一处不一致，请求就可能被拒绝，或生成订单后无法正确验签。

上线前还要确认收款方式与业务场景相符。若方案依赖个人收款码及设备监听到账消息，设备离线、通知权限变化或收款渠道规则调整，都可能影响自动确认。不能把页面上能显示二维码，当作订单能够稳定完成的依据。

扫码成功后，站内订单仍显示未支付

例如，一个站点已经生成收款二维码，测试人员扫码付款后跳回了成功页面，后台订单却一直停留在“待支付”。此时先保留这笔测试订单的站内订单号，以及码支付平台上的交易记录，不急着把订单改成已支付。页面跳转只是用户浏览器返回站点；确认付款通常依赖服务端收到并核验异步回调，两者可能先后发生，也可能只有前者成功。

排查集中在这笔订单的通知链路。站点记录里若没有收到回调，核对提交订单时填写的通知地址，并从外部网络检查它能否访问。地址指向本地环境、被登录验证拦截，或者服务端收到请求却返回错误，都可能让平台继续重试而订单状态不变。若记录显示已收到通知，则对照接口文档检查验签结果、订单号和实付金额，再看程序有没有把处理结果正确返回给对方。

这条路径仍可能遇到限制：服务方后台显示“通知成功”，站点却找不到请求记录。两边记录使用的订单号、通知时间和目标地址要放在一起核对；在确认付款事实与通知来源前，不用手动改订单来掩盖问题。下一轮测试沿用同一套记录方式，便于区分新旧故障。

准备切换正式收款时

测试订单走通后，正式环境还要单独核对密钥、回调地址和支付完成后的交付动作。测试环境使用过的地址可能仍留在插件配置里，导致正式付款通知发往旧站点。交付动作则应由已核验的订单状态触发，不依赖用户看到的跳转页面。

回调可能重复发送，站点收到同一笔有效通知时，只更新一次订单、执行一次交付，并保留处理记录。正式启用前，再用小范围测试订单核对平台交易记录与站内状态；出现不一致时，沿订单号查通知记录，先定位断在哪一段，再决定调整接口配置还是站点程序。