简介这是一套面向美团平台代付业务的全开源源码方案适合中小型商家、个人开发者及运营人员快速搭建代付系统。源码支持多套界面模板自由切换集成多种支付通道并附带完整搭建教程与测试环境配置说明PHP7.2MySQL5.6即使开发经验有限也能按指南完成部署。压缩包共约2000个文件大小44.24MB以1272个js脚本、196个html页面、150个css样式及164个json配置为主另含174个md说明文档、1个sql数据库脚本和少量xml、sh等辅助文件前后端结构完整、模块划分清晰。目前已有376人学习下载。读者可获得可直接二次开发的全套源代码、多模板与多支付通道的对接思路、数据库初始化脚本以及详细的搭建与排错参考便于快速构建稳定可靠的代付平台并投入运营。1. 美团代付源码能跑起来吗先看清这套 PHP 代付系统的真实骨架拿到一套「美团代付源码」的人十个里有八个第一反应是直接扔到宝塔里点部署然后卡在支付回调上怀疑人生。这套东西本质是一个 PHP 写的代付订单中转系统用户在前端下单系统生成一笔代付请求通过聚合支付通道把「待支付」状态推给付款方付款方完成支付后回调通知源站更新订单。它解决的核心问题是——让没有支付资质的小型站点也能走通「下单→代付→回调→发货」这条链路。适合谁手里有虚拟商品站、发卡站、资源站想接一套能自己改模板、自己控通道的轻量代付逻辑的站长和 PHP 开发者。不适合谁指望开箱即用、零代码基础、不做任何调试就想上线收款的人。这套源码全开源意味着你能看到每一行回调验签逻辑也意味着每一个坑都得自己填。下面按「它是什么→怎么搭→坑在哪→怎么改」的顺序拆开讲。2. 代付链路拆解从下单到回调钱到底怎么走的2.1 代付和直付的本质区别直付是「用户→平台→商户」用户直接把钱付给平台平台结算给商户。代付是「用户→代付方→商户」中间多了一层系统生成一笔代付订单把付款请求交给第三方通道通道完成收款后再回调通知。这套源码里的「美团代付」并不是真的对接美团官方接口而是借用了代付的业务模型——用一个中间账户或聚合通道来承接付款动作。理解这一点很关键否则你会一直在代码里找「美团开放平台 SDK」那是找不到的。代付链路的核心角色有三个源站发起代付请求的业务系统、代付系统这套源码本身、支付通道实际收款的接口。数据流向是源站调用代付系统的下单接口 → 代付系统生成订单号并向通道发起支付 → 通道返回支付链接或二维码 → 用户完成支付 → 通道异步回调代付系统 → 代付系统验签后回调源站。整条链路里最容易出问题的两个点一是订单号幂等二是回调验签。这两块后面会单独展开。2.2 数据库表结构和订单状态机拿到源码先别急着配环境先把install.sql或database.sql翻出来看表结构。常见的设计是四张核心表order代付订单主表、channel支付通道配置、template多模板配置、log回调与请求日志。订单状态一般有五种pending待支付、paid已支付、notified已回调源站、failed支付失败、expired超时关闭。状态流转必须是单向的不能从paid回退到pending否则会出现重复发货。-- 典型的代付订单主表结构字段名以实际源码为准 CREATE TABLE dp_order ( id int(11) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 代付系统内部订单号, out_trade_no varchar(64) NOT NULL COMMENT 源站传入的商户订单号, channel_id int(11) NOT NULL COMMENT 通道ID, amount decimal(10,2) NOT NULL COMMENT 金额, status tinyint(1) NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已回调 3失败 4超时, notify_url varchar(255) NOT NULL COMMENT 源站回调地址, create_time int(11) NOT NULL, pay_time int(11) DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY order_no (order_no), KEY out_trade_no (out_trade_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这段建表语句里有两个关键设计order_no加了唯一索引防止并发下重复生成订单out_trade_no加了普通索引因为源站回调查询会频繁用到它。status用 tinyint 而不是 enum是为了后续扩展状态时不用改表结构。如果你拿到的源码里order_no没有唯一索引第一件事就是补上否则高并发下会出现两笔订单共用一个订单号的情况回调时直接对不上账。2.3 支付通道的抽象层设计多通道支持是这套源码的卖点之一但很多二开版本把通道逻辑写死在控制器里加一个通道要改五六个文件。合格的抽象应该是定义一个ChannelInterface每个通道实现pay()、notify()、query()三个方法控制器只负责调度。下面是一个简化的接口定义示例?php // 通道接口所有支付通道必须实现这三个方法 interface ChannelInterface { // 发起支付返回支付链接或二维码内容 public function pay(array $order): array; // 处理异步回调返回验签后的订单数据 public function notify(array $params): array; // 主动查询订单状态 public function query(string $orderNo): array; } // 以某聚合通道为例的实现骨架 class AggPayChannel implements ChannelInterface { private $config; public function __construct(array $config) { $this-config $config; // 包含 appid、key、gateway 等 } public function pay(array $order): array { $params [ mch_id $this-config[mch_id], out_trade_no $order[order_no], amount $order[amount], notify_url $this-config[notify_url], sign , // 签名在下面计算 ]; $params[sign] $this-sign($params); // 向网关发起请求返回支付链接 return $this-request($this-config[gateway] . /pay, $params); } public function notify(array $params): array { // 先验签再返回订单数据 if (!$this-verify($params)) { throw new Exception(验签失败); } return [ order_no $params[out_trade_no], trade_no $params[trade_no], amount $params[amount], status paid, ]; } public function query(string $orderNo): array { // 主动查询逻辑 return $this-request($this-config[gateway] . /query, [ out_trade_no $orderNo, sign $this-sign([out_trade_no $orderNo]), ]); } private function sign(array $params): string { ksort($params); $str urldecode(http_build_query($params)) . key . $this-config[key]; return strtoupper(md5($str)); } private function verify(array $params): bool { $sign $params[sign] ?? ; unset($params[sign]); return $sign $this-sign($params); } private function request(string $url, array $data): array { $ch curl_init($url); curl_setopt_array($ch, [ CURLOPT_POST true, CURLOPT_POSTFIELDS http_build_query($data), CURLOPT_RETURNTRANSFER true, CURLOPT_TIMEOUT 10, ]); $res curl_exec($ch); curl_close($ch); return json_decode($res, true) ?: []; } }这段代码的关键点在于sign()方法先ksort对参数排序再拼接key做 MD5。这是绝大多数聚合支付通道的签名规则但不同通道的细节有差异——有的要求urldecode有的不要求有的用 MD5有的用 HMAC-SHA256。改通道时第一个要核对的就是签名规则签名不对回调永远验不过。notify()方法里先验签再返回数据这个顺序不能反否则伪造回调可以直接改订单状态。3. 宝塔环境搭建实操从上传源码到跑通第一笔代付3.1 环境选型和 PHP 版本坑这套源码常见要求是 PHP 7.27.4MySQL 5.7Nginx 1.18。宝塔面板里装环境很快但有两个坑一是 PHP 7.4 默认关闭了putenv和proc_open等函数部分源码的加密逻辑会用到二是 MySQL 8.0 的默认字符集和认证插件跟老代码不兼容建议直接用 5.7。如果你用的是云主机系统选 CentOS 7.9 或 Ubuntu 20.04 都行宝塔对这两个支持最稳。装完环境后在宝塔里新建站点PHP 版本选 7.4然后上传源码到站点根目录。解压后先看根目录有没有install文件夹或install.php有的话直接访问http://你的域名/install走安装向导。如果没有安装向导就手动导入数据库在宝塔的 phpMyAdmin 里新建一个库字符集选utf8mb4然后导入源码里的.sql文件。3.2 配置文件修改和伪静态设置导入数据库后找到源码的配置文件通常在config/database.php或application/database.phpThinkPHP 系。需要改的四个参数数据库地址一般127.0.0.1、库名、用户名、密码。改完后访问站点首页如果报「数据库连接失败」先检查宝塔的数据库权限——默认只允许本地连接如果你改了端口或用了远程库要在宝塔的「数据库」里把权限改成「所有人」。伪静态是第二个容易翻车的地方。这套源码如果是 ThinkPHP 或 Laravel 写的必须配伪静态规则否则除了首页全是 404。宝塔里在站点设置→伪静态里选对应的框架如果没有就手动填# ThinkPHP 5.x 伪静态规则 location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s$1 last; } }配完伪静态后访问/admin或/admin.php看后台能不能打开。后台默认账号密码一般在源码的README或安装说明里常见的是admin/123456。进去第一件事是改密码第二件事是配支付通道。3.3 支付通道配置和回调地址填写后台的通道配置一般需要填通道名称、网关地址、商户号mch_id、密钥key、回调地址notify_url。回调地址必须是公网可访问的 URL格式通常是http://你的域名/notify/通道标识。这里有个血泪经验回调地址不能带参数也不能用localhost通道服务器访问不到你的本地环境。调试阶段可以用内网穿透工具把本地映射到公网但正式上线必须用真实域名。配好通道后在后台建一个测试订单金额设 0.01走一遍完整流程。如果通道返回了支付链接但回调没进来先看宝塔的网站日志/www/wwwlogs/你的域名.log确认通道有没有请求你的回调地址。如果日志里没有回调记录说明通道那边没发过来检查回调地址是否填错或防火墙是否拦了。如果日志里有记录但订单状态没变那就是验签失败或代码逻辑问题去源码的log表里看回调日志。4. 多模板切换和支付通道扩展二开前必须搞清楚的几件事4.1 模板机制和变量替换逻辑多模板是这套源码的另一个卖点但很多版本的「多模板」只是换了个 CSS核心 HTML 结构没变。真正的模板机制应该是模板文件独立存放通过后台切换模板标识系统渲染时加载对应的模板文件。常见的实现方式是template/{tpl_name}/pay.html其中{tpl_name}从数据库或配置里读。改模板时注意两点一是模板里的变量占位符格式常见的是{$order_no}或{{order_no}}改的时候别把占位符删了二是模板里的表单提交地址必须指向代付系统的下单接口不能写死成某个通道的地址。如果你要加一套自己的模板复制一份现有的改 HTML 和 CSS然后在后台的模板管理里注册新模板标识即可。4.2 新增支付通道的完整步骤假设你要加一个通道按这四步走第一步在channel目录下新建一个类文件实现ChannelInterface接口第二步在后台的通道管理里新增一条记录填好配置参数第三步在调度器里注册这个通道的标识让系统能根据channel_id找到对应的类第四步写一个测试脚本模拟下单和回调确认签名和验签逻辑正确。// 通道调度器示例根据 channel_id 实例化对应的通道类 class ChannelFactory { private static $map [ 1 AggPayChannel, 2 AnotherPayChannel, // 新增通道时在这里加映射 ]; public static function create(int $channelId, array $config): ChannelInterface { if (!isset(self::$map[$channelId])) { throw new Exception(通道 {$channelId} 未注册); } $class self::$map[$channelId]; return new $class($config); } }这个调度器的好处是加通道只改$map数组和新增类文件不用动控制器。如果你拿到的源码里通道逻辑是if-else堆在控制器里的建议先重构成这种工厂模式否则后面加通道会越来越乱。重构时注意保持原有通道的channel_id不变否则已配置的订单会找不到通道。4.3 回调验签和订单幂等处理回调验签前面已经提过这里重点说订单幂等。幂等的意思是同一笔订单的回调不管通道发多少次系统只能处理一次。实现方式是在更新订单状态前先查当前状态如果已经是paid或notified直接返回成功不再重复处理。下面是一个典型的幂等处理逻辑// 回调处理中的幂等控制 public function handleNotify(array $params): string { $orderNo $params[out_trade_no]; // 加行锁防止并发回调同时查到 pending 状态 $order Db::name(dp_order)-where(order_no, $orderNo)-lock(true)-find(); if (!$order) { return order_not_found; } // 已经是终态直接返回成功避免重复发货 if (in_array($order[status], [1, 2])) { return success; } // 验签 $channel ChannelFactory::create($order[channel_id], $this-getConfig($order[channel_id])); $notifyData $channel-notify($params); // 更新订单状态 Db::name(dp_order)-where(order_no, $orderNo)-update([ status 1, pay_time time(), ]); // 回调源站 $this-notifySource($order[notify_url], $order); return success; }这段代码里lock(true)是悲观锁防止两个回调同时进来都查到pending状态然后都去更新。如果你的 MySQL 版本不支持行锁或者用的是 MyISAM 引擎这个锁不生效需要改用 Redis 分布式锁。另外notifySource()也要做重试机制源站可能暂时不可用回调失败要记录日志并定时重试不能丢。5. 避坑与排查代付系统上线前必须过的五道坎5.1 回调收不到订单一直 pending现象用户明明付了钱通道也扣了款但代付系统的订单状态还是pending源站没收到发货通知。原因通常有三个回调地址填错、防火墙拦截、验签失败导致回调被丢弃。排查顺序是先看宝塔网站日志有没有通道的 POST 请求记录如果没有检查回调地址是否公网可达用curl从外部请求一下你的回调地址看能不能通如果有请求但状态没变去源码的log表看验签结果大概率是密钥填错或签名规则不一致。解决方式回调地址用域名不用 IP密钥跟通道后台逐字核对验签失败时把原始参数和签名结果都记到日志里方便对比。5.2 订单号重复导致回调串单现象两笔不同用户的订单回调时更新了同一笔订单的状态导致 A 用户付了钱B 用户的订单变成了已支付。原因order_no生成规则有并发问题比如用time()加随机数高并发下可能重复。解决order_no用uniqid()加毫秒时间戳加随机数或者直接用数据库自增 ID 加前缀。同时确保order_no字段有唯一索引插入重复时直接报错而不是静默覆盖。5.3 模板切换后支付链接 404现象后台切了一套新模板用户点支付按钮跳转 404。原因新模板里的表单提交地址写的是相对路径而代付系统的路由规则跟模板目录结构不匹配。解决模板里的表单action必须用完整路由地址比如/pay/submit不能用./submit这种相对路径。另外检查伪静态规则是否覆盖了新模板的路径ThinkPHP 的pathinfo模式对大小写敏感模板文件名和路由大小写要一致。5.4 通道密钥泄露导致被刷单现象后台日志里出现大量金额 0.01 的订单且都支付成功但源站没有对应的业务订单。原因通道密钥或回调地址泄露被人构造了伪造回调。解决密钥不要写在能被外部访问的文件里配置文件权限设为 644 且属主是 www回调地址加签名校验源站回调也要验签后台加 IP 白名单只允许通道服务器的 IP 访问回调接口。如果已经被刷立即在通道后台更换密钥并清理未发货的异常订单。5.5 PHP 版本升级后加密函数报错现象把 PHP 从 7.2 升到 7.4 后后台登录或支付签名报「Call to undefined function」或「mcrypt_encrypt 已移除」。原因PHP 7.4 移除了mcrypt扩展部分老源码的加密逻辑还在用它。解决把mcrypt相关函数替换成openssl对应函数比如mcrypt_encrypt换成openssl_encrypt注意填充模式和 IV 长度的差异。如果源码里加密逻辑封装在单独的文件里改一个文件就行如果散落在多处建议全局搜索mcrypt_逐个替换。6. 进阶技巧用日志和主动查询兜住回调丢失的底回调丢失是代付系统最头疼的问题通道说发了你说没收到扯皮到最后用户投诉。我的习惯是不管回调有没有进来都加一个定时任务每 5 分钟主动查询一次pending状态且创建时间超过 10 分钟的订单。查询到已支付就补回调查询到未支付就继续等超过 30 分钟还没支付就关单。这个兜底逻辑能解决 90% 的回调丢失问题。# 宝塔计划任务每5分钟执行一次主动查询脚本 # 在宝塔面板→计划任务→添加任务类型选 Shell 脚本 # 执行周期选 N 分钟填 5 cd /www/wwwroot/你的站点 /www/server/php/74/bin/php think order:query这个命令调用的是源码里的order:query命令行脚本如果你的源码没有这个脚本需要自己写一个。脚本逻辑是查dp_order表里status0且create_time time()-600的记录逐条调用通道的query()方法如果返回已支付就更新状态并回调源站。注意查询频率不要太高大多数通道限制每分钟查询 1030 次超了会被限流。另一个技巧是日志分级。把回调日志分成info、warning、error三级info记录正常回调warning记录验签失败或重复回调error记录通道请求超时或源站回调失败。这样排查问题时直接看error和warning日志不用在几千条info里翻。日志文件按天切割保留 30 天避免磁盘被写满。最后说一个我踩过的坑有一次上线后一切正常但第二天早上发现所有订单都卡在notified状态源站没收到发货通知。查了半天发现是源站的回调地址在凌晨做了 DNS 切换代付系统的curl请求还解析到旧 IP超时后没有重试。从那以后我每次配回调地址都强制走一遍「失败重试 告警通知」的流程回调失败超过 3 次就发邮件提醒。希望帮到你。本文还有配套的精品资源点击获取