十四合一代付系统源码拆解：H5收银台与二次开发实战-北京尧图网络

简介这是一套面向支付系统开发者与二次开发者的全开源H5十四合一代付源码基于PHP7.4与MySQL5.7环境运行程序简洁流畅可在微信内正常使用且不易红域名适合需要快速搭建代付平台或进行深度定制的技术团队。资源包共112个文件以25个php核心逻辑文件、6个html页面、5个js脚本、2个css样式及1个sql数据库文件为主体另含31个png与25个jpg模板素材、10个txt说明文档压缩包约9.46MB结构完整便于部署与查阅。目前已有227人学习下载。源码内置美团、京东、拼多多、滴滴、携程、抖音、淘宝、得物、飞猪、猫眼等14套模板支持代理分成、用户提现、推广下级、商品自主上架与后台审核支付接口可对接总后台或由用户自行配置涵盖微信官方、易支付、个人码等。本次更新修复了分享卡片显示、远程资源本地化加载、后台加载慢等问题并新增订单多条件筛选、后台手动添加用户、分享卡片图文自定义等功能具备较高的二次开发价值。1. 十四合一代付系统到底合了什么从聚合支付到二次开发的真实边界很多人第一次听到「十四合一代付系统」这个词脑子里浮现的是十四个支付通道堆在一起。实际做过聚合支付的人知道这里的「十四合一」通常指的是十四类上游通道或结算方式的适配层——银行卡快捷、云闪付、数字人民币受理、各类钱包、聚合码、代收代付分离通道等等具体到某一份源码里合了哪十四家得看它的通道适配目录标题里不会写死。代付也叫下发、出款和代收是两套逻辑代收是用户把钱付进来代付是平台把钱打给商户或用户风控、对账、回调补偿的复杂度完全不在一个量级。这份源码之所以被反复搜核心诉求就三个一是想拿一套能跑起来的 H5 收银台二是想接自己的上游通道做二次开发三是想省掉从零写订单、对账、回调这套脏活。它适合有一定 PHP 或 Java 后端基础、手里已经有上游通道资源、需要快速搭一套代付中台的小团队或个人开发者。不适合完全不懂支付业务、指望改个配置就能上线收单的人——支付这行的坑从来不在代码里在通道规则和资金流里。2. 拆开源码看结构H5 收银台、订单中台、通道适配层怎么分工拿到一套「全开源可二次开发」的代付源码第一件事不是急着composer install而是把目录结构和数据流摸清楚。绝大多数这类系统的骨架是三层面向用户的 H5 收银台、中间的订单与账务中台、底层的通道适配层。三层之间靠订单号和回调串起来任何一层设计得含糊后面二次开发都会翻车。2.1 先认清三个核心目录和它们的数据流典型目录长这样不同源码命名有差异但职责基本一致project/ ├── app/ │ ├── controller/ │ │ ├── Cashier.php # H5 收银台入口渲染支付页、发起下单 │ │ ├── Notify.php # 上游异步回调统一入口 │ │ └── Merchant.php # 商户后台接口 │ ├── service/ │ │ ├── OrderService.php # 订单创建、状态机流转 │ │ ├── PayService.php # 代收/代付业务编排 │ │ └── SettleService.php# 对账与结算 │ └── channel/ │ ├── ChannelA.php # 每个上游通道一个适配类 │ ├── ChannelB.php │ └── ChannelFactory.php # 通道选择与路由 ├── config/ │ └── channel.php # 通道密钥、费率、限额配置 └── public/ └── index.php # 入口数据流是这样的用户在 H5 收银台点支付 →Cashier调OrderService生成订单状态pending→PayService通过ChannelFactory选一个可用通道 → 通道适配类拼装上游请求参数并发出 → 上游返回支付链接或二维码 → 用户完成支付 → 上游异步回调打到Notify→ 校验签名后更新订单状态为paid→SettleService参与后续对账。提示先把这条链路在纸上画一遍再去看代码。直接读代码很容易陷进某个通道的签名细节里忘了整体。2.2 通道适配层是二次开发的主战场二次开发 90% 的需求集中在通道适配层加一个新通道、改一个通道的签名算法、调整通道的限额和费率。所以适配层设计得好不好直接决定你后面改起来是十分钟还是三天。一个干净的通道适配类应该只做四件事拼装下单参数、解析上游返回、校验回调签名、查询订单状态。业务逻辑订单状态机、账务不应该出现在通道类里。判断一份源码值不值得二次开发就看它的通道类有没有偷偷写业务逻辑——如果ChannelA.php里出现了直接改数据库订单状态的代码这份源码的耦合度就偏高后面加通道会越来越痛。// 通道适配类的标准骨架以 PHP 为例 class ChannelA implements ChannelInterface { // 1. 拼装下单参数 public function buildPayParams(array $order): array { return [ merchant_no $this-config[mch_id], order_no $order[order_no], amount $order[amount], // 单位分务必和上游对齐 notify_url $this-config[notify_url], sign $this-sign($order), ]; } // 2. 校验回调签名 public function verifyNotify(array $data): bool { $sign $data[sign] ?? ; unset($data[sign]); return $sign $this-sign($data); } // 3. 签名算法每个通道不同是二次开发最常改的地方 private function sign(array $data): string { ksort($data); $str urldecode(http_build_query($data)) . key . $this-config[secret]; return strtoupper(md5($str)); } }这段代码里三个参数最要命amount的单位分还是元、notify_url是否可被上游公网访问、sign的拼接顺序。金额单位搞错是新手最常见的翻车点上游收 1 分你传 1 元或者反过来对账时能对到你怀疑人生。签名拼接顺序则完全取决于上游文档ksort只是其中一种有的通道要求按固定字段顺序拼改的时候必须逐字对照文档。2.3 订单状态机别让回调把状态改乱订单状态机是这类系统里最容易被忽视、又最容易出事故的地方。一个订单从创建到终态正常路径是pending → paying → paid → settled异常路径有pending → closed超时关单、paid → refunded退款。问题出在回调上上游可能重复回调、可能延迟回调、可能在订单已关闭后才回调。处理原则只有一条状态只能单向流转且每次流转前先查当前状态。回调进来先判断订单是不是已经是paid是就直接返回成功幂等不要再改任何东西。很多源码为了「简单」回调里直接update order set statuspaid一旦上游重推账就乱了。public function handleNotify(string $orderNo, array $data): string { $order $this-orderService-getByNo($orderNo); if (!$order) { return fail; // 订单不存在让上游重试或人工介入 } // 幂等已支付直接返回成功不重复处理 if ($order[status] paid) { return success; } // 已关闭的订单收到支付回调属于异常需要人工核对 if ($order[status] closed) { $this-logger-error(closed order paid: {$orderNo}); return success; // 返回成功避免上游无限重推但必须告警 } if (!$this-channel-verifyNotify($data)) { return fail; } $this-orderService-markPaid($orderNo, $data[trade_no]); return success; }这里的逻辑说明先查订单、再判幂等、再验签、最后改状态。顺序不能反验签放在幂等判断之后能省掉重复回调时的无谓计算。参数上markPaid内部应该用数据库行锁或乐观锁where statuspending来保证并发安全否则两个回调同时进来还是会重复处理。3. 本地把 H5 收银台跑起来环境、配置、下单全流程摸清结构之后下一步是在本地把整套流程跑通。这一步的目标不是上线是让你亲眼看到「下单 → 支付 → 回调 → 状态变更」这条链路走通后面二次开发才有参照。3.1 环境准备与依赖安装这类 PHP 源码通常要求 PHP 7.4 或 8.x、MySQL 5.7、Redis做订单锁和队列。用宝塔或手动装都行关键是版本对齐——PHP 8 跑 PHP 7 写的源码很多老扩展会直接报错。# 以 Ubuntu 为例装基础环境 sudo apt install php8.1 php8.1-fpm php8.1-mysql php8.1-redis php8.1-curl php8.1-mbstring -y sudo apt install mysql-server redis-server nginx -y # 拉代码、装依赖 cd /www/wwwroot git clone 你的源码地址 pay-system cd pay-system composer install --no-dev # 生产环境不装 dev 依赖 # 导入数据库 mysql -uroot -p -e CREATE DATABASE pay DEFAULT CHARSET utf8mb4; mysql -uroot -p pay install.sqlcomposer install --no-dev这个参数值得说一句开发依赖phpunit、faker 之类在生产环境没必要装装了既占空间又可能引入不必要的自动加载。数据库字符集一定用utf8mb4订单备注、商户名里出现 emoji 时utf8会直接截断报错。3.2 配置文件里必须改对的五个参数配置集中在config/目录通常有database.php、channel.php、app.php。下面这张表是我每次部署都会逐项核对的配置项位置说明常见错误数据库连接database.phphost/port/user/pass/dbname用了 127.0.0.1 但 MySQL 只监听 socket回调域名app.phpnotify_url 的域名前缀填了 localhost上游根本访问不到通道密钥channel.php每个通道的 mch_id 和 secret测试密钥和正式密钥混用订单超时app.php未支付订单自动关闭时间设太短用户还没付就关单日志级别app.phpdebug/info/error生产开 debug日志爆炸还泄露敏感信息回调域名是本地调试最大的坎。上游服务器要能访问到你的notify_urllocalhost和127.0.0.1都不行。常见做法是用内网穿透工具把本地端口映射到一个公网可访问的临时域名或者干脆部署到一台有公网 IP 的测试服务器上。这一步没有捷径回调不通整条链路就是断的。3.3 用一条测试订单验证全链路配置改完用系统自带的测试下单接口或后台手动建单走一遍完整流程。# 模拟商户发起一笔代收下单具体接口路径看源码路由 curl -X POST http://your-domain/api/pay/create \ -H Content-Type: application/json \ -d { merchant_no: M10001, order_no: TEST20250101001, amount: 100, channel: channel_a, notify_url: http://your-domain/api/notify/channel_a }参数说明amount这里是 100单位取决于源码约定多数是分即 1 元下单前务必确认。order_no必须全局唯一重复下单会被订单表的唯一索引拦下。channel指定走哪个通道测试阶段建议先用源码自带的沙箱通道或 mock 通道别一上来就接真实通道。下单成功后你会拿到一个支付链接或二维码。用手机扫码或打开链接如果通道是沙箱的通常会有一个模拟支付成功的按钮。点完之后去看Notify的日志确认回调进来了、签名验过了、订单状态变成paid了。这三步任何一步断了都要停下来查别急着往下走。注意本地调试时把日志级别开到 debug重点看回调请求的原始报文。签名验不过十有八九是参数拼接顺序或编码问题原始报文一比就清楚了。4. 二次开发避坑通道对接、回调、对账里最容易翻车的地方这一章是血泪经验集中区。代付系统的坑代码层面的其实好查业务和通道层面的才要命。下面五条是我和身边同行踩过、且反复有人踩的。4.1 现象回调一直验签失败日志里签名怎么算都不对原因通常有三个一是参数里混入了上游没参与签名的字段比如上游回调多带了一个sign_type你把它也算进去了二是编码问题http_build_query默认会把空格转成而上游要求%20三是上游文档写的拼接顺序和你代码里的ksort不一致。解决把回调的原始报文完整打出来手动按文档拼一遍签名和代码算出来的对比。编码问题用http_build_query($data, , , PHP_QUERY_RFC3986)强制 RFC3986 编码。顺序问题就老老实实按文档写死字段顺序别图省事用ksort。4.2 现象订单明明支付成功了状态还是 pending原因回调没进来或者进来了但处理失败。常见的是notify_url配错、服务器防火墙拦了上游 IP、或者回调处理里抛了异常但被吞掉了。解决先确认上游后台能看到回调记录多数通道后台有回调日志。如果上游显示已发送但你这边没收到查防火墙和 Nginx 访问日志。如果收到了但没处理成功看应用日志里的异常。兜底方案是加一个主动查单的定时任务对pending超过一定时间的订单主动调上游查询接口别完全依赖回调。4.3 现象对账时金额对不上差几分钱原因金额单位不统一。上游有的用分有的用元有的用「厘」。你的系统内部如果没统一通道适配层又没做转换就会差出数量级。解决系统内部统一用「分」作为金额单位所有通道适配类在入口和出口做转换转换逻辑写在一个公共函数里别每个通道各写一遍。对账时以分为单位比对差 1 分都要查。4.4 现象并发下单时同一笔订单被处理两次原因回调没有做幂等或者幂等判断和状态更新之间有竞态。两个回调几乎同时进来都查到状态是pending都往下走。解决状态更新用带条件的 SQLupdate orders set statuspaid where order_no? and statuspending根据影响行数判断是否真的更新成功。影响行数为 0 说明已经被别的请求处理过了直接返回成功。4.5 现象代付发出去了但上游返回失败钱却扣了原因代付是资金流出最怕的就是「请求超时但上游实际成功」。你的系统以为失败重试一次结果付了两笔。解决代付接口必须支持幂等用商户订单号作为幂等键传给上游。请求超时时不要立即判定失败先调上游的查询接口确认状态。系统内部对代付订单加唯一约束同一笔业务只允许发起一次代付。这块没有后悔药设计阶段就要想清楚。5. 从能跑到能扛代付系统的对账补偿与灰度上线技巧把系统跑通只是起点真正决定这套源码值不值得投入的是它能不能扛住真实资金流。这里讲两个进阶点对账补偿机制和灰度上线。对账补偿的核心思路是「以 upstream 为准本地主动对齐」。每天定时拉取上游的对账文件或调用对账接口和本地订单逐笔比对分出三类本地有上游无可能下单没成功、本地无上游有回调丢了、金额不一致单位或费率问题。前两类自动补单或关单第三类必须人工介入。# 对账脚本核心逻辑伪代码语言按你系统来 def reconcile(date): upstream fetch_upstream_bills(date) # 拉上游账单 local query_local_orders(date) # 查本地订单 up_map {b[order_no]: b for b in upstream} lo_map {o[order_no]: o for o in local} for no, o in lo_map.items(): b up_map.get(no) if not b: # 本地有上游无下单可能没成功标记待查 mark_suspect(no, no_upstream) elif b[amount] ! o[amount]: # 金额不一致单位或费率问题人工核对 mark_diff(no, b[amount], o[amount]) for no in up_map.keys() - lo_map.keys(): # 上游有本地无回调丢了补单 create_order_from_bill(up_map[no])这段逻辑的关键在最后一步「补单」上游有记录但本地没有说明用户确实付了钱但回调丢了必须补上否则用户投诉你查无此单。补单时要标记来源方便后续审计。灰度上线方面我的习惯是先切 1% 的流量到新系统观察 24 小时的对账差异率和回调成功率没问题再逐步放大。代付这种资金流出业务宁可慢一点也别一次性全量切。上线前把回滚方案写清楚数据库怎么回退、通道配置怎么切回旧系统写在纸上别只存在脑子里。最后说个我自己的习惯每接一个新通道我都会先用最小金额1 分钱跑通全链路包括下单、支付、回调、对账、退款五步全过才算这个通道接完。省这一步后面出问题排查的成本是它的几十倍。希望帮到你。本文还有配套的精品资源点击获取

十四合一代付系统源码拆解：H5收银台与二次开发实战

相关推荐

苹果手机微信记录备份到Win：WX Backup导出与避坑指南

Oracle到瀚高数据库数据抽取环境搭建与避坑指南

Spy++ Lite实战：窗口句柄抓取与Windows消息流排查

更多资讯

extract-xiso完全指南：Xbox光盘镜像提取与打包实战

地铁BAS PLC为何必须用STEP7 V5.5？兼容性与现场准入硬约束

C语言+easyX实现Flappy Bird：图形编程底层实战指南

【纯白嫖】IEC60870-5 中文版下载指南：101/104 协议标准一次拿齐全集

刚更新的首次启动流程：模型来源、系统授权、Agent 配置一次配完

【资源自取】倪海厦软件完整下载指南：人纪、天纪、医案查询系统三步跑通

今日更新

AI智能体开发实战：从技术原理到商业落地

OpenShell 完全定制指南：从安装到深度配置，打造高效 Windows 开始菜单

Superpowers技能体系全解析：从Skills引入到安装的完整指南

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？