企业官网建设流程全解析

简介：面向中小商家与PHP开发者的易支付收银台模板，集门店收银管理、云支付收银台于一体，提供美观的前端界面与完整的支付交互流程，并特别支持Apple Pay，可帮助开发者快速搭建或替换收银台界面，优化顾客支付体验，适用于电商、实体门店、聚合支付等多种业务场景。压缩包体积约9.6MB，共含1081个文件，以560个PHP文件为主，搭配275个PNG、64个CSS、50个JS等资源，覆盖后端逻辑、图标素材、页面样式与前端交互；另有SQL数据库脚本、cer/pem证书和配置文件，结构完整，便于按需部署或二次开发。目前已有58人学习浏览。资源附带了收银台与聚合码替换包，可直接用于门店收银系统，也可作为学习支付集成、界面设计与Apple Pay接入的参考案例，内置多种前端框架样式，适合需要快速上线或个性化定制支付收银台的开发者。

1. 易支付收银台不只是张好看的支付页：它背后是一套能落地的门店收款闭环

拿「云支付收银台模板」去搭门店收银管理系统，大多数人第一眼盯的是页面颜值，真动手才会发现，把这套易支付收银台跑起来要过的关都在后面。支付收银台模板负责收款页面的展示与交互，门店收银管理系统负责订单、台座和每日对账，云支付收银台则把这台本地机器上的收款动作搬到浏览器和移动端上。我见过太多把模板改得精美、却因为一行回调地址配错，导致顾客付了款、后台还一直挂着“未支付”的案例。这篇文章会从部署开始，把模板对接、订单回写、对账逻辑和常见故障一次讲完，适合准备给门店做数字化改造的开发者、接单方和想自建收银系统的店主。

2. 在本地把易支付与收银台模板跑通：部署路径与初始化配置

拿到一个“易支付 精美设计的支付收银台模板 门店收银管理系统 云支付收银台.zip”，先别急着解压丢到服务器上。这类包通常揉进了前端模板、易支付系统文件、数据库脚本和接口说明文档四部分，部署之前先弄清楚每一块是干什么的，后面改起来才不会把系统文件当成模板文件一顿乱动。

2.1 源码包里的四类文件：先分清模板、系统、数据库和文档

一个典型的易支付收银台项目解压后，目录大致长这样：

判断一个文件名属于哪一类，有个土办法：看里面有没有 PHP 入口和数据库查询。收银台模板的核心输出是 HTML 和静态资源，易支付系统核心文件则到处是curl、mysqli和签名校验逻辑。把两类文件混在一起改，是后面所有故障的源头。

2.2 从解压到打开收银台：PHP/MySQL/Web 环境的最小部署

我一般先在本地用 Nginx + PHP 7.2+ + MySQL 5.7+ 跑通，再上服务器。这套组合对易支付系统兼容性最好，PHP 版本太高反而会碰上mcrypt这类历史扩展缺失的问题。部署命令如下：

# 解压项目到站点根目录，注意不要带中文目录名 unzip 易支付_收银台模板.zip -d /www/wwwroot/cashier cd /www/wwwroot/cashier # 设置运行用户和目录权限，PHP-FPM 需要读取和写入 session、日志目录 chown -R www:www /www/wwwroot/cashier chmod -R 755 /www/wwwroot/cashier find /www/wwwroot/cashier -type d -name 'runtime' -o -type d -name 'log' | xargs chmod -R 777

chown和chmod是这里最容易出错的一步。PHP-FPM 默认以 www 用户运行，如果文件属主是 root，页面能打开但写入订单时会直接报权限错误。把runtime和log目录放开写权限，是因为易支付系统会把支付日志和调试信息写在这两个目录里，权限不够时回调日志会静默丢失，排查问题会非常被动。

接着创建数据库并导入初始表结构：

CREATE DATABASE cashier DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; -- 进入命令行或 phpMyAdmin 执行项目自带的安装脚本 SOURCE /www/wwwroot/cashier/sql/install.sql;

utf8mb4在这里是硬性要求。订单表里会出现用户昵称、商品名称这类可能带 emoji 的文本，用老式utf8字符集存 emoji 会直接报错或者变成问号，这种问题几乎不可逆。数据库建好后再配置 Nginx 站点，伪静态规则直接关系到后面支付回调路径能不能被正确解析：

server { listen 80; server_name cashier.test; root /www/wwwroot/cashier; index index.php index.html; location / { # 优先匹配真实存在的文件，避免静态资源被转发到 PHP try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }

try_files那句$uri $uri/至关重要。没有它时，CSS、JS、图片请求会全部落到index.php上，虽然页面能刷新出来，但样式和脚本全部丢失，收银台会变成纯文字页面。这个规则对伪静态路径和真实文件都有效，是这类系统最通用的配置。

2.3 后台初始化和支付渠道参数：真正决定模板能否收款的是这一段

站点能打开、数据库能连通之后，才开始配置支付渠道。易支付系统后台一般会有一张“支付参数”配置页，需要填写的核心参数不超过五项：

这里有一条血泪经验：密钥和网关地址不要写死在模板页面里，一旦模板文件被误当作普通静态文件上传到 CDN，密钥就裸奔了。正确做法是把参数集中在config.php里，模板只读取常量，不直接拼密钥。

支付渠道配好后，在后台“订单列表”里点一笔测试支付，如果订单状态能变成“已支付”，说明这一层通了。这个步骤不要跳过去，因为后面所有模板对接、门店收银逻辑都建立在这条通道上，底层没通，上面全是空中楼阁。

3. 把收银台模板接到易支付订单系统：页面对接与三个必调参数

模板要跑起来，不只是把 HTML 放到服务器上那么简单。收银台页面和易支付系统之间有下单、签名、跳转、回调四条交互链路，其中金额、订单号、回调地址这三个参数是改动最频繁、也是踩坑最多的位置。

3.1 收银台页面被调用的完整链路：下单、选支付方式、跳转

门店顾客扫码后，请求会经过这样一条链路：扫码落地页 → 收银台模板页面 → 用户选择支付宝或微信 → 模板组装下单请求 → 易支付系统 → 支付服务商收银台 → 用户完成支付 → 同步跳回门店页面、异步通知门店后台。模板页面在整条链路里扮演的是“前端引导员”的角色，真正记账的是易支付系统的订单表。

<?php // cashier/index.php 收银台下单入口 require_once '../include/config.php'; // 金额统一转为元，保留两位小数，拒绝非法输入 $amount = round((float)($_POST['amount'] ?? 0), 2); if ($amount <= 0) { exit('金额无效'); } // 订单号：日期时间 + 机器序号 + 随机数，保证并发不重复 $out_trade_no = date('YmdHis') . str_pad((string)random_int(0, 9999), 4, '0', STR_PAD_LEFT); // 组装易支付下单请求 $params = [ 'pid' => $config['ep_pid'], 'type' => $_POST['pay_type'] === 'wxpay' ? 'wxpay' : 'alipay', 'out_trade_no' => $out_trade_no, 'notify_url' => $config['ep_notify_url'], 'return_url' => $config['ep_return_url'], 'name' => trim($_POST['subject'] ?? '门店订单'), 'money' => $amount, ]; // 易支付签名规则：过滤空值，按参数名排序后拼接字符串，最后附上商户密钥做 MD5 ksort($params); $sign_str = urldecode(http_build_query($params)) . $config['ep_key']; $params['sign'] = md5($sign_str);

这段代码里最容易被忽视的是ksort和urldecode。易支付签名要求按参数名排序后拼接，拼接时还要处理 URL 编码反转，否则带中文的name参数会导致签名永远对不上，返回“签名错误”。这个规则对接的支付服务商不一样，签名算法也可能略有差异，但本质都是“排序后拼接密钥再哈希”。

3.2 模板里改动最多的三个参数：金额、订单号、回调地址

先看金额。门店收银台经常会有“整单优惠抹零”“加收服务费”这类需求，任何金额计算都要在 PHP 层用整数分或者round(x, 2)完成后再传给易支付。直接拿数据库里的浮点数拼接，会出现 9.999999 这种值，支付服务商那边可能直接拒绝或者在账单上出现一分钱差异。

再看订单号。门店场景下订单号往往需要和桌台号、班次关联，常见做法是把桌台号编进订单号里，比如T12开头代表 12 号桌。订单号在支付服务商那里有长度限制，一般不能超过 32 位，所以我建议订单号只包含数字和字母，不要带-和_，某些支付渠道会把连字符当成特殊符号。

最后是回调地址。notify_url必须是公网可访问的完整地址，不能带localhost。在本地联调时可以用内网穿透把本机端口映射出去，把回调地址填成穿透后的临时域名。这里要注意一个极易翻车的点：回调地址在拼接时不要被二次 URL 编码。下面这段就踩过坑：

// 错误写法：notify_url 被 urlencode 后，支付服务商收到的地址变成乱码 $notify_url = urlencode($config['ep_notify_url']); // 正确做法：原样拼接，http_build_query 会自己处理需要编码的部分 $params['notify_url'] = $config['ep_notify_url'];

回调地址错了，顾客付了钱但系统不更新订单，这是收银台类项目里最典型的“黑匣子”问题——页面看起来一切正常，后台数据就是不动。

3.3 处理好前端资源依赖：模板不“翻车”的路径与接口约定

模板关联的 CSS、JS、图片，通常位于assets目录。如果模板代码里写的是/assets/css/app.css这种绝对路径，而模板部署在子目录里，浏览器就会去域名根目录找资源，结果全部 404，收银台页面变成没有样式、没有按钮事件的裸页面。修复方案是让模板动态生成基础路径：

<?php // 在模板入口文件顶部定义 BASE_URL $base_url = rtrim(dirname($_SERVER['SCRIPT_NAME']), '/\\'); ?> <!-- 在 HTML 里用 BASE_URL 拼资源地址 --> <link rel="stylesheet" href="<?php echo $base_url; ?>/assets/css/app.css">

这样无论模板是在域名根目录还是子目录里，资源都能被正确加载。除此之外还要注意模板里的接口请求地址。收银台页面通常需要轮询订单状态，请求的是/api/order_status.php这类接口，这里的路径同样要用$base_url拼接，不能写死成/api/...。

模板的“精美”往往体现在交互上：支付倒计时、支付成功后自动刷新、失败后给出重试按钮，这些都依赖前端和后端接口之间的约定。我给模板对接接口时，会把接口统一返回 JSON 格式，字段固定为code、msg、data三个，前端的按钮状态跟着code走，而不是靠判断页面文本内容，这样后期换模板样式时不用把交互逻辑重写一遍。

4. 门店收银管理系统怎么和支付数据串起来：订单、台座与对账

收银台模板负责让顾客付钱，门店收银管理系统的职责则是把这些支付记录变成门店能用的经营数据：今天开了多少台、每个台座消费多少、微信和支付宝各收了多少钱、有没有顾客付了款但系统漏记。这里面的核心是订单数据的回写和核对。

4.1 打通数据闭环：支付回调后的订单状态回写机制

易支付系统在顾客完成支付后，会收到支付服务商的异步通知，通知带trade_status、out_trade_no、total_amount和签名。易支付系统验签通过后，会把自己订单表里的状态改成已支付，然后回调门店收银管理系统自己定义的通知地址。门店系统要做的事，是在接到通知后把自己业务订单表的状态同步更新。

<?php // api/notify.php 门店收银管理系统接收易支付回调用 require_once '../include/db.php'; // 接收易支付转发过来的异步通知参数 $out_trade_no = $_GET['out_trade_no'] ?? ''; $trade_status = $_GET['trade_status'] ?? ''; $amount = $_GET['money'] ?? 0; // 先验签再更新，签名校验失败的一律不更新状态 if (!verify_sign($_GET, $config['ep_key'])) { exit('fail'); } if ($trade_status === 'TRADE_SUCCESS') { $pdo->beginTransaction(); try { // 更新门店业务订单表 $stmt = $pdo->prepare("UPDATE store_orders SET status = 1, pay_time = NOW() WHERE out_trade_no = ? AND status = 0"); $stmt->execute([$out_trade_no]); // 更新台座表：该台座从“就餐中”变成“已结账待清台” $pdo->prepare("UPDATE store_tables SET status = 'waiter_clean' WHERE current_order_no = ?")->execute([$out_trade_no]); $pdo->commit(); echo 'success'; } catch (Exception $e) { $pdo->rollBack(); exit('fail'); } }

这里有两个关键点。第一，门店业务订单表要用out_trade_no作为关联键，和易支付系统的订单表一一对应，台座字段只存订单号而不是存整条订单数据，这样两端数据才能对上。第二，更新时带了status = 0条件，防止重复通知把状态覆盖成异常值。支付异步通知在网络上会重试多次，接口返回success告诉服务商“不要再发了”，返回fail则服务商继续重试，所以幂等处理必须做。

如果不想依赖回调，收银台模板的轮询接口也可以直接查易支付系统的订单表：

SELECT status FROM ep_user_order WHERE out_trade_no = '202508121230001234';

轮询接口查库的间隔建议控制在 3 到 5 秒，太短会把数据库打成热点，太长则顾客付完款页面迟迟不刷新。

4.2 门店收银场景里常见的功能取舍：台座、挂单、交接班

门店收银管理系统要比纯网店多两个维度：台座和班次。台座解决的是“哪个桌子吃了这单”的问题，班次解决的是“这笔钱算在谁头上”的问题。数据库设计上可以这样拆：

台座操作上有个很容易被忽略的细节：收银台模板只管支付，它并不清楚门店当前有哪些台座。门店收银管理系统在顾客扫码点餐时，先把订单号写到台座上，再拿着这个订单号去收银台模板支付，支付完成后回调自动把台座状态改成“待清台”。这样就算顾客中途换台、拼桌，订单记录也不会错乱。

交接班对账是整个门店管理系统最敏感的功能。我的做法是系统在收银员点击“交接班”时生成一张班次汇总表，列出本班次的应收、实收、退款和差额，然后打印出来让收银员签字。这笔差额如果不写入数据库，只是一张打印纸，第二天对不上账时没有任何追溯依据。

4.3 对账对齐的三种做法：从订单表到门店流水怎么对上

对账的本质是让三个数据源保持一致：支付服务商账单、易支付订单表、门店业务订单表。最简单粗暴的做法是每天凌晨跑一次全量比对，把易支付系统里已支付的订单和门店订单表做 LEFT JOIN，找出门店没有同步的订单。

-- 找出易支付系统已支付、但门店订单表还没同步的记录 SELECT p.out_trade_no, p.money, p.addtime FROM ep_user_order p LEFT JOIN store_orders so ON p.out_trade_no = so.out_trade_no WHERE p.status = 1 AND so.id IS NULL;

这条 SQL 查出的是“顾客付了钱，但门店系统不知道”的订单，通常原因是回调失败或者回调程序报错被拦截。每发现一条，都可以手动触发一次重新通知或者补单操作。第二种做法是反向比对，把门店订单表里标记为已支付、但易支付系统里查询不到对应记录的订单标记为可疑单，这类情况一般是测试环境数据或者程序 bug 误改状态。第三种做法最省事也最实际，直接核对每日汇总金额：把支付服务商后台的日结单金额、易支付系统的当日支付总额、门店收银系统的实收总额三方拉到一张表里对比，差一分钱就回到前面两条 SQL 里找明细。

对账脚本务必放在服务器本地跑，不要挂在收银台模板的页面上。门店收银台机器配置普遍不高，日结查询时间又长，放在前端页面里经常被浏览器标签页崩溃带崩，放在 cron 里定时执行才顺畅可靠。

5. 云收银台上线前后的常见问题排查：从白屏到金额不一致

这一章是给“已经按前面步骤做完、但碰到问题”的人准备的。每条问题我都按“现象 → 原因 → 解决”的套路来写，照着顺序排查能省下大把时间。

5.1 收银台页面白屏或样式丢失，模板资源 404

现象：页面能打开，但全是纯文本，没有按钮背景也没有排版，浏览器控制台报出一排文件 404。原因：模板里的 CSS/JS 地址用了绝对路径，比如/assets/css/app.css，而模板不在域名根目录下。解决：按 3.3 节的做法，在模板入口处定义$base_url，把页面里所有的资源地址都改成动态拼接。如果你的模板里有 AJAX 请求，请求接口路径也要一并检查，这个错法和资源路径错法一样，只是报错晚一点。

5.2 支付成功但订单一直显示未支付，回调链路断了

现象：顾客在支付宝/微信里明明看到了付款成功页，易支付后台订单状态也是已支付，但门店收银管理系统的订单列表还是“未支付”。原因：要么是门店系统的回调地址填错，要么是回调程序验签失败直接返回了fail。解决：第一步，打开易支付后台，找到这笔订单的“通知日志”，看它最后一次尝试回调的地址是什么；第二步，把这个地址复制到浏览器直接访问，带着参数访问一次；第三步，看门店系统有没有把日志写下来。我排查这条链路时的固定套路是先确认地址能不能访问、再确认参数对不对、最后确认验签函数是不是和服务商约定的算法一致。数据库里ep_user_order表的状态字段是 1 不代表回调链路通，门店系统的订单表最终状态才是验收标准。

5.3 数据库连不上或误清空，又没有后悔药

现象：收银台页面报数据库连接错误，或者收银员误操作把今天的订单表清空了。原因：连接配置错误属于低级问题，一般是 MySQL 的监听地址、端口和 PHP 配置里的DB_HOST不一致；误清空则是门店收银管理系统缺少基本的操作保护。解决：数据库连接上，统一把DB_HOST设置为127.0.0.1加明确端口，避免使用localhost时 PHP 解析成 unix socket 而 MySQL 又没开 socket 监听。误清空这块，我给门店系统做的防护是：订单表和台座表的DELETE和TRUNCATE操作在后端必须二次确认，且在删除前先把数据表和全部数据备份成一份 SQL 文件存放着。不要相信“撤销”按钮，SQL 文件才是后悔药。

5.4 订单金额跟实际收款差了几分钱，浮点与精度问题

现象：顾客实际支付 199.99 元，门店订单表里记的是 199.98 元或者 200 元。原因：PHP 浮点数运算和支付服务商那边采用的整数分转换规则不一致，中间经过了一次除法或乘法产生了精度损耗。解决：金额在进入门店收银管理系统时就统一转成“分”为单位存储，也就是整数，显示时再除以 100。如果一定用“元”作单位，所有运算都必须经过round(..., 2)包裹。比较金额时不要用==，用bccomp(amount_1, amount_2, 2)这种二进制安全比较。收银台模板上显示的钱、门店订单表存的金额、易支付回调通知里的money，三者必须完全一致，任何一个环节多算一次round，都会在日结对账时暴露出来。

5.5 支付页和后台反复跳回登录，会话与伪静态配置冲突

现象：收银员登录后台，操作一会儿后页面自动跳回登录页，或者支付回调进来后session丢失。原因：有两个常见来源。第一，Nginx 伪静态规则里没有把静态资源排除出去，CSS/JS 请求被转发到 PHP 后，PHP 执行了session_start()却在同一个进程里互相干扰，把已有的会话数据覆盖了；第二，session.cookie_path或session.save_path配置不当，导致不同路径下的会话文件不一致。解决：先检查伪静态规则是否包含try_files $uri $uri/，确保静态资源不被 PHP 接管。再检查 PHP 的session.save_path是否存在、有写权限。这两种情况在本地 Windows 环境极少出现，上 Linux 服务器后用浏览器无痕模式测试，复现率最高。

6. 收银台模板的进阶用法：扫码点单、小票打印与四步验证

基础流程跑通后，门店收银管理系统还可以往两个方向扩展：一是把支付页面升级成扫码点单入口，二是用验证方法保证模板改完不会在下一次版本更新时出现回归。

扫码点单的实现思路是复用现有收银台模板，不要另起炉灶。顾客扫码后进入的落地页直接读取桌台二维码携带的table_no，用户选完菜品提交后，后端一次性生成整单的out_trade_no并写入store_orders表，同时创建带菜品明细的order_detail表。然后页面跳转到收银台支付模板，顾客付完钱回调更新整单状态。这种方案的优点是门店不需要给每张桌子配一台点菜机，顾客手机就是点菜终端，收银台模板的支付能力刚好够用。

小票打印这一块，我在门店系统里用的是最直接的方案：给单据详情页加了一个“打印”按钮，后端根据out_trade_no查出门店订单和菜品明细，拼接成 58mm 小票的纯文本格式，通过前台浏览器调用本地打印机。要点是打印内容里的金额必须读数据库，不能读模板页面传上来的参数——很多人忽略了这一点，顾客改一下浏览器里显示的金额，小票金额也跟着变，月底对账全是麻烦。

模板改完上线前，我会跑一遍四步验证：

最后一件事是我自己的习惯：所有配置文件和模板入口文件，在改动前先git commit，改坏了随时能回滚。线上门店收银系统不是一个“跑起来就行”的演示项目，它每天承载的是真金白银和顾客的耐心等待。把回调地址和签名算法这类关键逻辑当订书钉一样反复确认，比把模板颜色调得再好看都重要。希望这些经验能帮到你，让你的收银台模板一遍过、少挨骂。

本文还有配套的精品资源，点击获取