简介适用于门店收银、云支付收银台等场景的易支付聚合收银台模板源码面向需要快速上线美观支付界面的开发者和商户。模板内置Apple Pay支付选项支持Apple设备免输卡密快速完成交易同时随包附带聚合码替换包可无缝切换已有收款码。压缩包共1081个文件以560个PHP后端逻辑文件、275个PNG图片素材、64个CSS与50个JS前端资源为主并含cer/pem证书、SQL初始化、字体及配置文件整体约9.6MB目录划分清晰方便按模块查阅与二次开发。资源已有58人次浏览学习。开发者可直接对照PHP代码理解易支付收银台的请求、回调与验签流程利用前端文件调整品牌风格也可复制SQL和证书完成本地联调测试是一份适合学习支付集成与界面定制的综合参考模板。1. 收到易支付收银台 zip先想清楚它到底要解决什么收到这个 zip 的时候很多人的第一反应是赶紧解压、找到 index.html 看页面长什么样。但标题里三个关键词其实是三套东西易支付负责把微信、支付宝的支付请求收进来并回调通知收银台模板是顾客扫码后看到的那个付款页面门店收银管理系统才是店里每天开台、点单、日结对账用的后台。它们合在一起就是一条从“顾客扫码付款”到“店里结账对账”的完整链路。打算做支付集成的开发者、接门店系统外包的小团队以及不想被平台通道抽太多手续费、想自己部署收银台的商家先把这三者的边界理清楚再动手后面才不会在文件结构里迷路。2. 拆开这个 zip收银台模板、门店收银、云支付的边界在哪这类模板包我见过不少名字叫得花哨内容其实高度相似一个用户端收银台页面、一套对接支付渠道的接口、一个管理订单的门店后台。问题在于它们经常被塞进同一个压缩包目录混在一起新手容易把收银台的静态页面当成全部结果付款流程通了账却没记上。模块职责常见技术形态使用场景收银台模板展示订单金额、支付方式、二维码轮询或长连接刷新支付结果HTML CSS JS可嵌入到任意站点顾客手机扫码付款时看到的页面易支付框架对接微信/支付宝等渠道处理下单、回调、验签PHP 接口 MySQL 订单表服务端接收支付结果更新订单状态门店收银管理系统开台、选商品、收款、退款、日结、小票打印PHP 后台 数据库收银员在电脑或平板上操作这三者的关系一句话说就是收银台模板是皮易支付框架是血管门店收银系统是账本。皮做得再好看血管断了钱进不来账本乱了店就亏了。2.1 收银台模板和门店收银管理系统根本不是一回事收银台模板本质上是面向顾客的一次性页面顾客扫完码、付完钱这个页面就不再有价值。它的核心指标是加载快、二维码清晰、支付状态刷新及时而门店收银管理系统是面向店员的长周期工具要管商品库、桌台、会员、交班报表。两者在包里的目录通常是分开的一个偏静态资源一个偏动态接口。判断方法很简单看有没有 admin 或 manager 这类目录。模板包一般会带一个收银台的入口文件比如 cashier.php 或 pay.html门店后台通常藏在 admin/ 下面进去以后要登录、要连数据库。把这两块混为一谈是后续配置出问题的第一类根源——你会想不通为什么收银台页面能打开后台却一直 500。2.2 解压体检用 unzip -l 先看目录别急着全部解开我解压这类包的第一件事从来不是直接 unzip而是先列清单。zip 包可能很大也可能被套了一层子目录直接解开会把一堆文件撒得到处都是。用 unzip -l 可以不解压就预览目录结构先摸清根目录长什么样。unzip -l 易支付 精美设计的支付收银台模板 门店收银管理系统 云支付收银台.zip | head -50这里的 -l 参数表示只列出压缩包内容不实际解压head -50 限制只看前 50 行避免被大量静态资源刷屏。注意文件名带空格所以整个文件名必须用引号包住否则 shell 会把它拆成多个参数。看到根目录之后再决定用 unzip 直接解到当前目录还是建个子目录。如果执行时提示需要密码说明压缩包被加密过。网上有很多“zip 密码移除”的工具我的习惯是先确认包的来源商家发来的资源包加密是为了防止误改售卖的模板加密是为了控制传播这类包直接放弃解压如果是自己打包时忘了密码用 7z 先看加密标记比盲目找工具靠谱。7z l 易支付 精美设计的支付收银台模板 门店收银管理系统 云支付收银台.zip 2/dev/null | head -207z l 会把每个文件是否加密用 标注出来看到一大片 就说明是整体加密正常渠道该找卖家要密码只有零星几个文件加密的才考虑是不是授权证书类文件被单独保护。2.3 判断技术栈看入口文件是 index.php 还是 index.html模板包是 PHP 做后端还是纯静态直接决定部署方式。纯静态的只能展示页面没法处理回调那就要配上独立的支付接口服务PHP 结构的则一套环境全搞定。判断方法不是看 README而是看入口文件。file index.html index.php 2/dev/null head -30 config.php 2/dev/nullfile 命令会输出文件类型比如 ASCII text 或 PHP scripthead 看配置文件前 30 行能确认里面是不是有数据库连接、商户密钥这类信息。看到 define(DB_HOST, ...) 之类代码基本就是 PHP MySQL 的结构。很多模板包同时带 index.html 和 index.php前者是演示页后者才是真入口别用错了。这一步做完你才知道后面要配的是 Nginx PHP-FPM还是直接扔到任意静态托管平台。3. 本地跑通再到服务器部署PHP 环境与支付参数这样配确认是 PHP 结构后我的建议是先本地跑通再上服务器。本地环境用 Windows 的话常见做法是装一个集成面板比如 PHPStudy 或 Laragon省去手动编译 PHP 的麻烦Linux 服务器则用 apt 或 yum 装 Nginx 和 PHP-FPM。重点不是装环境而是把虚拟主机配置和支付参数对齐这一步错了后面所有页面都会白屏或报 502。3.1 用 Nginx 托管收银台的两个 server 要点收银台入口文件通常在项目的 public 目录下而不是根目录。让 Nginx 的 root 直接指向 public可以避免用户通过 URL 直接访问配置文件这是第一道防线。server { listen 80; server_name pay.example.com; root /var/www/cloud-cashier/public; index index.php; location / { 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 的作用是请求路径不是真实文件时把路由交给 index.php 处理收银台模板的伪静态链接都靠它生效。fastcgi_pass 指向 PHP-FPM 监听的本地端口默认是 9000改成 Unix socket 也行但要注意 php-fpm.conf 里的 listen 配置必须一致。root 指向 public 后静态资源目录可以做成只读后面第 5 章会展开讲为什么这很重要。3.2 支付参数填哪里商户 ID、应用密钥、异步通知地址易支付类框架的配置大同小异通常是一个 config.php里面放商户信息。这是整个部署过程中最不能出错的一个文件填错任何一个字段下单要么报签名失败要么回调永远到不了。?php return [ merchant_id 10234, // 易支付平台分配的商户号 merchant_key 8f3b9c4d2a7e5f1c, // 商户密钥下单与验签都用它 gateway https://pay.example.com/gateway, // 易支付网关地址 notify_url https://cashier.your.com/notify.php, // 异步回调必须公网可访问 return_url https://cashier.your.com/result.php, // 同步跳转支付完回跳到收银台 timezone Asia/Shanghai, // 时区写死防止服务器默认 UTC ];merchant_id 和 merchant_key 必须与易支付商户后台一致key 通常是一串 32 位十六进制字符。notify_url 是服务器对服务器的回调支付成功后由支付平台主动请求所以域名必须能被外网访问不能填 localhost也不能填内网 IP。return_url 是浏览器跳转顾客付完钱的回跳页面填错顶多页面不跳转但 notify_url 填错订单状态就永远不会更新。3.3 用 curl 发起一笔测试订单验证能不能下单配置填完后先用 curl 直接打下单接口确认能拿到支付链接或二维码参数再去页面里点按钮。curl -X POST https://pay.example.com/api/create \ --data-urlencode merchant_id10234 \ --data-urlencode order_idTESTCASHIER20250612001 \ --data-urlencode amount0.01 \ --data-urlencode typealipay \ --data-urlencode sign按商户密钥计算出来的md5值order_id 必须保证唯一同一笔订单号不能重复发起否则支付平台可能直接拒绝。amount 以元为单位测试时填 0.01别第一次就填 100。sign 的计算方式一般是把除 sign 外的所有参数按 key 升序排列拼接成 keyvaluekeyvalue 的形式再加上商户密钥做 md5具体拼接规则以支付平台文档为准。返回结果里如果出现 sign error先检查参数字典序还是不是对的如果出现 no such merchant说明商户号填错了。4. 门店收银管理系统的三张核心表订单、商品、日结门店收银管理系统听起来复杂落到数据库层面大多数模板只需要三张表就能转起来订单表记录每一笔收款商品表维护卖什么、卖多少钱日结则是一张汇总结果或一个查询视图。很多模板把这三样塞进几十张表里反而让维护者看不懂。我会按最小可用模型来讲你拿到手后可以拿这三张表去对照模板里的现有设计。4.1 订单状态机待支付、已支付、已退款、已关闭订单表是整个门店系统的地基。状态字段我建议用 TINYINT 存数字码不要直接用字符串因为支付回调里返回的状态通常就是数字数字判断更省心也避免中英文不一致导致逻辑出错。CREATE TABLE orders ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL UNIQUE, channel TINYINT NOT NULL COMMENT 1微信 2支付宝, amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已退款 3已关闭, paid_at DATETIME NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_status_created (status, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;order_no 设置唯一索引确保同一笔单不会被重复插入。amount 用 DECIMAL(10,2)不要用 FLOAT 或 DOUBLE二进制浮点数存金额会出现 0.1 0.2 不等于 0.3 的问题对账时能把你逼疯。联合索引 idx_status_created 是为了日结查询准备的按状态和时间段过滤时不会全表扫描。4.2 商品表和桌台表门店最少需要记什么商品表不复杂核心字段是名称、单价、状态。桌台表只有在餐饮类门店才需要零售类门店可以忽略。CREATE TABLE products ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100) NOT NULL, price DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1上架 0下架 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE tables ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, name VARCHAR(20) NOT NULL, order_id BIGINT UNSIGNED NULL ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;桌台表省事一点的做法是不单独建表直接在订单表里加一个 table_no 字符串字段。但独立建表的好处是能维护“空台/占用”状态收银台界面上一眼看出哪些桌子可用。order_id 字段记录当前占用的订单订单支付完成后清空桌台自动释放。4.3 日结对账为什么不能只看支付回调支付回调到了、订单状态改成已支付这只代表支付平台收了顾客的钱不代表门店今天的账是平的。日结要按天汇总订单核对支付成功笔数和金额再和支付平台的对账单比对。SELECT DATE(created_at) AS biz_date, channel, COUNT(*) AS order_cnt, SUM(amount) AS total_amount FROM orders WHERE status 1 AND created_at 2025-06-11 00:00:00 AND created_at 2025-06-12 00:00:00 GROUP BY biz_date, channel;GROUP BY 的粒度要和你对账的粒度一致。如果你是按自然日交班就按 DATE(created_at) 分组如果是跨天营业、凌晨 2 点交班那日结的起点应该是交班时间而不是 0 点。很多现成模板只做了按自然日汇总结果开夜宵店的老板每天对账都要手动把昨晚 12 点以后的单子挪到今天这个细节等你上线后一定会遇到。5. 收银台接入易支付的避坑指南验签、回调与目录权限部署收银台最耗费时间的往往不是环境配置而是各种听起来像玄学的异常钱扣了订单没更新、回调偶尔能通偶尔不能、页面能打开但扫码一片黑。这一章把我见过的高频翻车点按现象、原因、解决的顺序写清楚你可以在排查时对号入座。5.1 回调验签不过订单一直显示“待支付”现象顾客扫码付了款支付平台后台显示交易成功但收银台页面一直停在“待支付”手动刷新订单状态也不变。原因异步回调接口收到了通知但验签失败代码直接 return 掉了没有更新订单状态。验签失败最常见的原因是拼接顺序错了参数没有按 ASCII 码升序排列或者把商户密钥拼在了参数串前面而支付平台要求拼在最后。解决按支付平台的验签规范重写校验逻辑。以常见的 md5 验签为例$data $_POST; $sign $data[sign]; unset($data[sign]); ksort($data); $str urldecode(http_build_query($data)) . $merchant_key; if (md5($str) $sign) { // 验签通过更新订单状态 }http_build_query 会把数组拼成 key1value1key2value2 的字符串但布尔值和特殊字符会被编码所以外面套一层 urldecode 还原。ksort 一定要在 unset 之后执行否则签名参数也会参与排序永远对比不上。验签通过后再查订单是否存在、金额是否一致再更新状态顺序不能反。5.2 回调接口裸奔谁都能把订单刷成已支付现象测试期间订单表里突然出现一堆小额“已支付”订单金额还是 0.01 或 0.10 这种整数值但没有一笔是真实顾客付的。原因回调接口只判断了参数里的状态字段没验签或者验签逻辑写了但没跑起来。只要别人知道你的回调地址就能 POST 一个 status1 的单子过来直接把订单刷成已支付。解决第一道关就是验签和处理逻辑放在同一个接口里不验签的直接返回失败第二道关是校验金额和订单号支付的金额必须和订单表里的金额一致不一致说明伪造第三道关是记录回调日志看到大量落后 IP 直接拉黑。别偷懒跳过日志回调问题排查时它就是唯一的目击证人。5.3 微信里扫码打不开收银台现象收银台页面在电脑浏览器、手机浏览器里都能正常打开但生成微信支付二维码后顾客用微信扫码页面提示“该链接无法访问”或“包含诱导分享内容”。原因最常见的是域名没备案或者页面地址里带了特殊参数被微信风控其次是页面打开时没有走 HTTPS微信对纯 HTTP 链接非常敏感。收银台标题里带了“易支付、门店”这类词虽然不影响但页面如果有明显的收款字样容易被误判。解决正式上线前把域名备案好配好 HTTPS 证书用 Nginx 强制跳转测试时不要用生产二维码直接用手机浏览器打开收银台页面测试流程。如果模板自带的页面里放了“充值返现”这类敏感文案先删掉再上线。这一条看起来不技术但十个人里有三个人栽在它上面。5.4 PHP 默认时区导致签名不过现象本地环境测试一切正常部署到服务器后下单接口返回签名错误改什么都不行。原因php.ini 里的 date.timezone 没有配置PHP 默认用的是 UTC 时间和支付平台的北京时间差了 8 小时。签名串里如果带了时间戳参数本地和服务器计算出来的 sign 天然就不一致。解决在项目入口文件顶部加一句date_default_timezone_set(Asia/Shanghai);或者在 php.ini 里改 date.timezone Asia/Shanghai然后重启 PHP-FPM。这一条几乎没有技术难度但特别容易被忽略因为本地开发环境的面板默认就把时区调好了服务器上的最小安装反而没配。5.5 目录权限收太松配置文件被扒走现象线上收银台部署后访问 https://你的域名/config.php 能直接看到数据库地址和商户密钥页面里是一堆明文代码。原因Nginx 的 root 指到了项目根目录而配置文件名叫 config.php直接在 public 下等于把家底亮给所有人看。部分模板为了省事把静态资源和 PHP 文件全堆在同一层上传目录、备份文件也放在 web 根目录非常危险。解决强制把 root 指向 public 子目录第 3 章的 Nginx 配置就是这么做的配置文件放在 public 外层通过 require 引入public 目录只保留 index.php、静态 CSS/JS、图片和上传目录上传目录单独设置为只写不可执行。权限方面public 目录 755配置文件 644runtime 目录 777 但入口禁止访问。别一开始图顺手给整个项目 777后面出问题你会恨不得有后悔药。6. 上线前用一条命令自动验证回调链路收银台的体检脚本支付收银台最怕的不是功能没写好而是回调链路断在半路。页面能下单、顾客能付款但钱到了订单库里没反应这就是典型的“黑匣子”问题。我养成的习惯是每次改动配置或上线前不拿真手机扫码先用一条命令模拟支付平台的回调把整条链路从接口到数据库打通验证一遍。6.1 模拟支付平台回调验证从收银台到订单库是通的先手动在库里插入一笔待支付订单作为测试对象再模拟支付平台回调最后查询订单状态。三步合到一条脚本里反复跑也不心疼。#!/bin/bash BASEhttps://cashier.your.com mysql -u root -p cashier -e \ INSERT INTO orders (order_no, channel, amount, status) \ VALUES (TESTCASHIER001, 1, 0.01, 0); curl -s -X POST $BASE/notify.php \ --data-urlencode merchant_id10234 \ --data-urlencode order_idTESTCASHIER001 \ --data-urlencode amount0.01 \ --data-urlencode sign按商户密钥算出的md5值 mysql -u root -p cashier -e \ SELECT order_no, status, paid_at FROM orders WHERE order_noTESTCASHIER001;curl 的 --data-urlencode 会对参数做 URL 编码中文或特殊符号不会在传输过程中被转义破坏比手拼 -d axxxbyyy 稳当。sign 值可以用 PHP 命令行临时算php -r echo md5(amount0.01merchant_id10234order_idTESTCASHIER001你的密钥);注意参数的字典序要和回调验签一致。跑完这条脚本如果最后查询出来的 status 是 1说明整个环路的验签、查询、更新逻辑都通了如果 status 还是 0先看 curl 的返回内容接口会告诉你卡在验签还是订单查询。我的血泪经验是永远在动手改代码前跑一遍这条命令记录基线改完再跑一遍对比结果比盯着日志猜快得多。门店收银台的坑大多不在代码多难而在链路背后的环节太多了支付网关、回调地址、服务器时区、目录权限任何一个环节断掉表现出来都是“收银台不可用”。把这条脚本变成每次上线前的例行动作能省下大量深夜排查的时间。希望帮到你。本文还有配套的精品资源点击获取