下载程序前，先确认收款渠道

搜索“易支付搭建教程”时，常会看到上传源码、填写数据库、打开安装页这类操作。照着完成，网站可能很快出现收银台，但收银台能打开，不代表已经具备收款条件。易支付类程序主要承担订单创建、渠道对接和支付结果通知；资金由实际接入的支付渠道处理，程序本身不会凭空提供可用的收款接口。

动手前，先确认所用源码的来源、版本说明和运行环境要求，再核对支付渠道是否提供商户号、接口密钥及接入文档。不同渠道的申请条件和接口格式可能不同，不能把一套示例配置直接填到另一套渠道里。遇到要求交出账户密码、绕过渠道审核的“免签”方案，暂停接入，核实其授权和资金处理方式。

服务器还要有能被支付渠道访问的公网地址，并配置有效的 HTTPS。只在本机打开页面，足以检查样式，却无法完成真实的异步通知测试。

安装页打开后，检查配置有没有写到正确位置

部署时，按照当前源码文档配置网站运行环境，创建独立数据库和数据库账户，将程序文件放到网站目录，再访问安装入口。PHP 版本、扩展和目录权限以该版本的安装说明为准；看到报错就直接改成“全部可写”，容易留下不必要的权限风险。安装完成后，删除或限制安装入口，修改默认管理密码，并确认配置文件没有被网站直接下载。

支付接口配置里容易混淆两个地址：用户付款后返回的网站页面，以及支付渠道向服务器发送结果的通知地址。前者供用户查看，后者用于更新订单。填写回调地址时，核对域名、路径和 HTTPS；如果网站经过反向代理或访问控制，还要确认外部请求能到达通知路径。

上线前用渠道提供的测试环境或小额测试订单走一遍完整过程。测试订单与正式订单分开记录，避免调试时把测试成功当作真实成交。密钥不要贴进公开截图或提交到公开代码仓库；更换密钥后，网站配置也要同步更新。

用户付款了，订单仍显示未支付

例如，假设一个网站的收银台能正常跳转，付款后用户也回到了“支付完成”页面，后台订单却一直停在待支付。管理员查看通知日志，发现支付渠道的请求没有进入程序；检查网站访问规则后，发现通知路径被登录验证拦住了。这是一种可能的故障路径，不能仅凭订单未更新就认定原因相同。

此时先保留该笔订单的编号和渠道侧交易记录，不要手动把所有待支付订单批量改成成功。管理员调整通知路径的访问规则，使渠道请求能够到达接口，同时保留签名校验。随后重新发起一笔测试订单，查看服务器是否收到通知、程序是否返回渠道要求的响应，以及订单状态是否只更新一次。

浏览器返回页面显示“成功”，不能替代服务端收到并核验支付通知。处理通知时，程序还应核对订单号、金额和渠道返回的状态；重复通知到达时，避免重复发货或重复记账。如果渠道后台显示已发送通知，而服务器日志仍没有记录，就继续核对回调地址、证书和代理转发配置。旧订单的状态则依据可核对的交易记录单独处理，不靠重新打开付款页面来推断结果。