源码下载后，先确认它接在网站哪里

易支付对接插件源码通常承担两件事：向支付平台发起订单，以及接收支付结果并更新网站订单。拿到源码后，不宜直接覆盖到网站目录。先看它写给什么系统使用：插件目录结构、安装说明和后台配置入口，能否与当前网站的插件机制对应。如果源码只有独立的 PHP 文件，网站却要求通过特定接口注册支付方式，就不能靠复制文件完成接入。

打开配置文件时，常会看到商户号、密钥和接口地址。字段名称相似，不代表不同平台可以直接混用；签名算法、参与签名的字段以及回调返回格式，都要以当前支付平台的接口文档为准。密钥保留在服务端配置中，不放进网页脚本，也不要连同源码上传到公开仓库。若插件来历不明，还需检查下单和回调文件有无指向无关域名的请求。

支付页面能打开，订单却没有变更

这类情况往往发生在用户付款之后。浏览器跳回网站，只能表明用户访问了返回页面，不能据此把订单标为已支付。订单状态通常由支付平台向网站服务器发送的异步通知更新；插件中的“同步返回”和“异步回调”若写在不同文件里，排查时也要分开看。

例如，某网站接入插件后，付款页面可以正常打开，但后台订单一直显示“待支付”。开发者查看网站请求记录，发现异步回调地址没有收到请求。此时修改订单更新代码不会改变现象，处理方向转向平台后台填写的通知地址：核对域名、路径是否与插件实际路由一致，并从外网访问该地址，确认请求能到达网站。若服务器记录随后出现回调请求，再检查返回的状态码和插件日志；记录仍为空，就继续核对平台后台配置及服务器对外访问情况。

这一情境只覆盖“请求未到达”的路径。若日志已经收到通知，问题便转到验签或订单处理：记录必要的错误信息，避免把密钥和完整敏感报文写入日志。浏览器返回页显示“支付成功”而后台未更新时，也应以服务端核实的订单状态为准。

修改回调代码时，核对订单如何被确认

支付回调是使用源码时风险较集中的位置。平台发来的订单号、金额和支付状态，需要经过签名验证，再与网站原订单核对。不能仅凭请求里带有“成功”字样就发货或开通服务；金额应与网站创建订单时保存的金额一致，避免直接采用回调参数覆盖原订单金额。

支付平台可能重复发送同一笔通知，插件也要避免重复执行发货、充值等动作。查看源码时，找到更新订单状态的位置，确认同一订单已完成后再次收到通知会怎样处理。订单状态写入成功，才按平台文档返回约定的确认内容；否则平台可能持续重试，而网站日志里只留下多条相同请求。

正式启用前，用一笔可控的测试订单走完下单、支付和回调，查看平台订单与网站订单是否对应。测试结束后，再核对后台配置的通知地址与当前部署地址，整理本次修改过的文件和配置项。后续更换域名或升级网站时，这两处最容易被旧配置留在原处。