简介这是一套面向PHP开发者与支付系统集成工程师的聚合支付平台源码聚焦第三方与第四方支付收款能力整合解决多渠道支付接口统一接入、快速部署与安全合规等核心问题适用于电商、SaaS服务、本地生活类平台等需灵活拓展支付方式的业务场景。资源包共2000个文件含39个核心PHP后端逻辑文件、590个JS交互脚本、486个HTML页面及318个CSS样式文件辅以JSON配置、SQL数据库脚本及加密相关C语言实现如xxtea.c整体压缩包达141.56MB结构完整覆盖前端展示、支付路由、回调验签、订单管理与后台监控模块。目前已有82人学习下载。开发者可直接基于该源码快速搭建高可用收款平台完成支付宝、微信等主流通道对接并参考内置的安全传输机制、数据校验逻辑与交易审计设计有效规避支付流程中的常见风险点。 做线上业务的人基本都体会过那种无从下手的烦躁用户要微信支付你接一套用户要支付宝你再接一套突然又有人问支不支持云闪付你嘴上说后续规划心里盘算的其实又是半个多月的开发量。每个渠道接口风格不同、签名方式不同、回调字段不同连坑都坑得各有特色。所谓聚合支付本质上就是在这堆渠道之上加一个统一适配层让业务方只需要调用一套接口、接收一套回调、维护一套订单状态。而第四方支付在聚合的基础上又往前走了一步它自己不碰资金而是整合多家持牌渠道的通道能力统一对外提供路由、分账、退款、对账这些高级能力。本文要聊的就是一套比较典型的PHP聚合支付源码既含第三方支付通道的对接实现也含第四方支付的聚合层设计。我把这套系统的模块结构、关键流程、代码实现思路、上线前必须注意的坑以及合规红线一并讲清楚适合正在做电商平台、多商户系统、或者准备入行支付开发的朋友参考。1. 聚合支付到底解决什么问题为什么你不需要一上来就写四套接口很多人第一次听到聚合支付心里想的是不就是对接多个支付渠道做一层封装吗话是没错但真动手的时候会发现封装只是个开始。1.1 第三方支付和第四方支付的区别先把概念理清楚。第三方支付是持有支付牌照的机构比如微信支付、支付宝、银联商务它们直接提供收款、结算能力商户需要单独签约、单独接入。第四方支付则不是支付机构是服务商角色本身不碰资金技术活是把多家第三方支付能力整合起来给下游商户提供一个统一入口。打个比方第三方支付是各大银行第四方支付是银行之间的一个综合金融服务台。你不需要记住每个银行柜台怎么填单子只需要把需求放到服务台它帮你路由到合适的银行完成交易。本文这套PHP源码就是把服务台的逻辑全部实现了一遍。1.2 谁需要这套系统谁其实不需要这套源码适合几类场景多商户平台比如电商SaaS、外卖平台每个商户都要收款但不可能让每个商户都自己去签微信支付、支付宝平台统一接入再分账到各商户。运营成本敏感的团队直接接多个渠道每增加一个渠道就要改一版业务代码聚合层能把渠道差异隔离在底层业务侧永远面对同一套接口。想要智能路由的团队不同渠道的费率、到账时间、成功率不一样第四方支付层可以根据这些指标自动选择最优渠道。但如果你只是做一个单商户的独立站一天几十单那真没必要上这套东西。直接接官方SDK或者用现成的支付插件更划算。聚合支付是有架构成本的它解决问题的前提是你有多个支付渠道或者多个商户需要管理。1.3 拿需求之前先想清楚的两个问题我见过不少朋友拿着聚合支付源码就开跑结果做出来的东西既不能用也不好维护。动手之前最好先明确两件事第一你的资金流是平台归集还是渠道直连如果是平台归集资金再结算给商户那就涉及二清的合规问题这个后面专门展开。如果只是给商户提供渠道聚合、资金由持牌机构直接结算那合规压力会小很多。两种模式系统设计完全不同。第二你的核心壁垒是什么如果只是简单封装微信支付宝那没有任何壁垒因为渠道API本身就是公开的。真正有价值的是路由策略、对账差错处理、退款状态机、分账引擎这些细节。看源码的时候我建议把重点放在这几个模块上而不是放在怎么调一个下单接口上。2. 一套可落地的PHP聚合支付源码模块和架构长什么样我手里这套PHP源码是比较常见的聚合支付平台结构技术栈是PHP MySQL Redis控制器基于ThinkPHP框架底层大量使用队列和定时任务。下面从模块划分、数据库设计、代码结构三个维度拆一下。2.1 模块规划从商户到对账一个都不能少一个能真正跑起来的聚合支付平台至少需要这几个模块模块核心功能对应表商户管理商户入驻、商户密钥、费率配置、IP白名单merchant、merchant_app支付下单统一下单、计算签名、调用渠道、返回支付参数pay_order回调处理接收渠道异步通知、验签、更新订单、通知商户pay_callback_log订单查询主动查单、处理回调丢失、订单超时关闭pay_order渠道管理渠道参数配置、渠道上下架pay_channel路由中心根据规则选择最优渠道channel_route_rule分账管理平台、商户、代理商之间的分润计算settle_bill、settle_order退款管理发起退款、异步处理、结果回调refund_order对账模块下载渠道账单、逐笔核对、差错生成check_bill、check_diff系统管理RBAC权限、操作日志、系统参数admin_user、admin_role这套划分基本覆盖了支付系统的完整生命周期。很多人写支付系统只关注下单和回调实际上后面这几个模块才是真正占开发量、真正体现系统可靠性的东西。2.2 技术选型背后的理由PHP版本建议7.4以上最好直接用PHP 8.x。源码里如果还带ThinkPHP 3.2.x那就得慎重了。3.2.x是2015年之前的老框架本身已经停止维护存在SQL注入、路由解析等历史问题生产环境建议迁移到TP6或Laravel再跑。我见过不止一个团队拿老源码直接上生产上线一个月被扫描出十几个漏洞天天打补丁。MySQL用来存交易数据Redis的作用更大缓存渠道配置、做分布式锁防并发、做异步队列、做接口频率限制。Redis在整个支付系统里不是缓存可选件而是几乎每个环节都要用的基础设施。2.3 数据库设计几个关键点支付系统数据库设计和大杂烩似的业务系统不一样有几个细节一旦踩错会非常难受金额字段必须用整型存单位分。PHP的float类型在计算金额时会有精度误差比如0.1 0.2 0.30000000000000004在支付场景这是绝对不可接受的。源码表里total_fee、refund_fee这些字段类型都是bigint单位一律是分。订单表必须做唯一索引。out_trade_no商户订单号加唯一索引这是防重复下单的第一道防线。transaction_id渠道交易号如果有也建议加唯一索引因为回调时你要用它来做关联。把回调日志单独存表。这个特别重要。渠道回调是支付链路里最不可控的一环微信可能重复推、延迟推、顺序乱每次回调内容和验签结果都记录下来排查问题的时候就是救命稻草。2.4 代码结构里的核心目录源码目录一般长这样app/ ├── admin/ # 管理后台控制器 ├── api/ # 对外商户接口 ├── callback/ # 渠道回调处理 ├── console/ # 定时任务对账、关单、结算 ├── common/ │ ├── channel/ # 渠道适配器 │ ├── pay/ # 支付核心逻辑 │ └── service/ # 分账、退款等服务 ├── model/ # 数据模型 └── queue/ # 队列消费我的建议是拿到源码之后先不要急着往服务器上丢先把common/channel目录里的适配器代码通读一遍这是整个系统的交通枢纽。3. 第三方支付通道接入从表单到回调的完整链路第三方支付通道的接入逻辑是整个系统的基础层。以微信支付APIv3为例走完一遍流程你就明白其他支付宝、银联差不多都是同一个套路。3.1 从签约到拿到密钥的准备工作想对接微信支付你得先去申请商户号完成签约拿到几样东西商户号mch_id、AppID、商户API私钥自己生成一对RSA密钥把公钥上传给微信、证书系列APIv3密钥、平台证书。这些属于账号资质没有捷径。拿到这些配置之后第一件事是写好请求发起和签名生成这两个基础方法。微信APIv3的逻辑是你的请求体计算SHA256摘要然后使用商户私钥对摘要做RSA-SHA256签名放到HTTP头里。代码示意如下private function buildAuthHeader(string $method, string $url, string $body): string { $timestamp time(); $nonce bin2hex(random_bytes(16)); $message {$method}\n{$url}\n{$timestamp}\n{$nonce}\n{$body}\n; openssl_sign($message, $signature, $this-config[mch_private_key], OPENSSL_ALGO_SHA256); return sprintf( WECHATPAY2-SHA256-RSA2048 mchid%s,nonce_str%s,timestamp%d,serial_no%s,signature%s, $this-config[mch_id], $nonce, $timestamp, $this-config[mch_serial_no], base64_encode($signature) ); }很多新手在这里会犯一个错误把$body直接拼进去之后没有注意URL的路径部分要按实际请求路径计算。如果路径带了查询参数比如?keyvalue那也要完整拼接进去漏一个字符验签就过不去。3.2 统一下单参数与渠道适配器封装微信支付的统一下单接口是POST /v3/pay/transactions/native参数核心包括out_trade_no、amount.total单位分、description、notify_url等。返回的是支付二维码链接code_url。这套源码里做了一个很关键的设计所有的渠道都实现同一个接口而不是每个渠道独立开发一套逻辑。定义一个适配器接口interface PaymentChannelInterface { public function getChannelCode(): string; public function createOrder(PayRequest $request): PayResponse; public function verifyNotify(array $headers, string $body): array; public function queryOrder(string $outTradeNo): array; public function refund(RefundRequest $request): RefundResponse; }微信、支付宝、银联各自写一个实现类。业务层不需要知道当前用的是哪个渠道只需要调用createOrder、verifyNotify。这样一来以后新增一个渠道就是新增一个适配器类不改动业务代码。3.3 回调通知验签、解密、业务处理一个都不能少回调是整个支付流程里最重要的环节也是出问题最多的地方。微信APIv3把回调报文做了两层处理第一层HTTP头里带Wechatpay-Signature用微信平台证书验签第二层如果涉及敏感字段比如transaction_id还要用APIv3密钥解密。用PHP验证微信回调签名大概是这样$signature $_SERVER[HTTP_WECHATPAY_SIGNATURE]; $timestamp $_SERVER[HTTP_WECHATPAY_TIMESTAMP]; $nonce $_SERVER[HTTP_WECHATPAY_NONCE]; $body file_get_contents(php://input); $message {$timestamp}\n{$nonce}\n{$body}\n; // 商户平台下载的微信支付平台证书 $publicKey openssl_pkey_get_public(file_get_contents($this-config[platform_cert_path])); $verifyResult openssl_verify($message, base64_decode($signature), $publicKey, OPENSSL_ALGO_SHA256);验签通过之后还要解密resource字段拿到真正的订单数据解密密钥是APIv3密钥算法是AES-256-GCM注意要校验nonce、关联数据associated_data。我在源码里见过不少回调只要返回success就算成功的写法这是非常危险的。渠道说你收到通知并成功处理了你才应该回复success如果处理过程中出现异常应该返回失败让渠道继续重试。如果不管处理是否成功都回success那这笔订单就可能永久卡在已支付但业务未更新的状态。3.4 订单查询与对账回调不丢单的兜底方案回调通知毕竟是网络请求有可能丢、有可能延迟。订单查询机制就是兜底方案系统定时任务每隔一段时间扫一遍已下单但长时间未回调的订单主动向渠道查询支付状态查到已支付就补单。对账更是每天必须做的事。渠道每天会提供交易账单文件系统下载后和本地订单逐笔核对。核心比对的字段是订单号、渠道流水号、金额、状态。两边不一致的记录生成差错单由人工决定是补单还是退款。这些在源码里对应console目录下的两个定时任务一个是订单状态同步一个是每日对账。4. 第四方支付聚合层的三个核心能力路由、分账、退款第三方支付接入只是把地基打好了聚合支付平台的价值更多体现在这个聚合层。我觉得其中最难也最值得上心的是三块渠道路由、分账结算、退款异常链。4.1 渠道路由不只是随机选一个渠道如果你只是把请求固定打到一个渠道那根本不需要路由模块。所谓路由是要根据规则动态决定每一笔订单走哪个渠道。常见的路由维度有费率优先哪个渠道手续费低就优先走哪个适合成本敏感的交易。成功率优先有的渠道在网络高峰期成功率会波动根据近一小时的成功率动态调整。渠道权重新渠道上线先只切5%流量跑稳了再逐步放量。商户分组某些商户指定只能走某些渠道比如对公客户只走银联渠道。路由模块的代码结构一般是规则引擎 评分器每个规则返回一个分值最后把各规则评分汇总选分最高的渠道。源码里如果只是简单写死按费率排序那建议你自己扩展成可配置的评分模式class RouteScorer { private $rules; public function __construct(array $rules) { $this-rules $rules; } public function score(array $channel, PayRequest $request): int { $score 0; foreach ($this-rules as $rule) { $score $rule-evaluate($channel, $request); } return $score; } }每个规则是一个策略类这比满屏的if/else好维护十倍。4.2 分账引擎多商户平台的利润分配核心如果平台上有多个商户那就涉及分账。第四方支付平台常见的模式是用户付的钱先进平台汇总平台再按规则分配给各个参与方比如商户拿95%、平台拿2%、代理商拿1%、渠道手续费2%。这里面的计算逻辑看起来很简单但真正做起来要考虑的东西很多结算周期T1日结、周结、月结怎么配。结算状态机待结算、结算中、已结算、结算失败、冻结每种状态流转可能涉及人工介入。提现限制最低提现金额、手续费收取、提现频次限制。很多支付平台源码在分账这块就是个半成品只有一张账单表没有自动打款流程。真正能跑通的系统分账之后还需要对接代付接口或者批量转账接口把钱真实打给商户。这部分在源码里如果只有生成账单而没有执行打款说明只是展示型项目离生产还差很远。4.3 退款一个比支付更容易出错的异步链路退款在技术上比支付更烦人。支付是同步请求、异步回调退款也是异步的而且退款结果的通知不如支付通知可靠很多渠道甚至不提供退款回调需要主动轮询退款状态。退款模块必须处理的几个场景全额退款和部分退款部分退款要记录剩余可退金额避免超退。退款幂等同一笔订单同一金额连续发起两次退款第二次必须被拦截。退款失败重试渠道返回余额不足这种错误时不能无限重试要进入人工处理流程。退款退得好不好直接决定平台和商户之间的信任关系。源码里如果只有简单的refund()方法、没有退款状态机和轮询补偿我建议按上面这几个场景补全。这里也建议用Redis队列做按订单串行消费避免同一订单的退款并发冲突// 对同一个退款订单加锁串行处理 $lockKey refund:lock: . $refundNo; if (!$redis-set($lockKey, 1, [NX, EX 60])) { // 已有退款任务在处理直接返回排队中 return $this-json(2003, 退款处理中请稍候); }5. 支付系统最容易踩的坑按严重程度排序这块是我最想说的部分。下面这些坑我基本都在实际项目里或明或暗地见过把它们按严重程度排个序建议重点回避。5.1 回调验签不严格支付系统最严重的缺陷我见过有一个系统回调接口拿到通知之后直接查订单改状态连签名都不验证。这种系统的风险根本不是薅羊毛级别而是资金级别。任何人只要能伪造一个回调请求就能把自己订单改成已支付。防伪的思路非常清晰渠道回调的所有请求必须验签验签通过的数据才能进入业务处理逻辑。同时建议对回调请求来源IP做限定渠道的固定IP写进白名单。5.2 幂等没做好重复通知导致重复入账回调通知在弱网环境可能重复发送很多次。支付渠道的文档一般会明确说通知频率将逐渐提高直到商户正确处理返回成功。如果你的回调逻辑是收到回调 - 查到订单 - 订单置为已支付 - 加商户余额那同一笔回调被重推两次商户余额就可能被加两次。解决方案是幂等控制两个层次配合使用Redis分布式锁以订单号为key加锁同一时间只允许一个回调任务处理这笔订单。数据库状态校验更新订单状态时用UPDATE ... WHERE status 待支付影响行数为0说明已经被处理过直接忽略。两个方案都上双保险。只靠Redis锁有锁过期丢失的风险只靠数据库判断有并发时超卖的风险合起来才是稳的。5.3 金额单位混乱赔钱往往从小数点开始第三方支付的金额单位是分这个我说过一遍了但在这里还是要再强调一次。PHP代码里发起支付时传了10表示1角还是1元回调金额100对的是1元还是100元这种单位换算错误一旦上线轻则退款重灾重则变成支付一分钱买万元商品。安全做法是数据库只存分接口入参只接收分页面展示时才转成元。在回调处理里必须校验订单金额和渠道通知金额完全一致不一致的订单不能自动入账要置为异常单并由人工介入。5.4 回调处理时间过长导致超时重试堆积有些回调逻辑里会同步做很多事写订单、加余额、扣库存、发短信通知商户。这些操作放到一条链路里一旦短信接口超时整个回调处理就卡住了渠道等不到响应就重试重试再次卡住最终形成雪崩。更好的设计是把回调逻辑拆成验签 落库和业务通知两步。回调只做验签、更新订单状态、写回调日志然后立即返回成功。后续的给商户发通知、加余额、扣库存全部丢到队列异步执行。这样回调接口的响应时间基本能做到几十毫秒渠道也愿意跟你说再见。5.5 定时任务重复执行引发重复处理定时任务比如每晚对账、每分钟查单在单台服务器上没什么问题但一旦部署多台机器来实现高可用定时任务就可能被重复执行。要解决这个问题可以用Redis的分布式锁来确保同一时刻只有一个节点在执行或者在入口处加一个任务实例ID的互斥判断。我见过一个平台因为定时任务重复跑把同一个月的对账单下载了三次数据全被覆盖。这事不复杂但教训是真金白银换来的。6. 部署上线之前把这几件事做完再睡个安稳觉系统开发完离能上线还差得远部署和运维环节的坑也很多。这里列一个我从实践中总结的上线前检查清单。6.1 生产环境部署清单PHP-FPM运行用户和目录权限给上传目录、日志目录、会话目录设置最小权限避免文件目录可写导致的webshell风险。Nginx只暴露必要入口支付源码如果有admin后台建议后台单独绑定域名并在防火墙做IP白名单很多攻击都是从后台爆破开始的。HTTPS必须全程开启支付接口如果走明文HTTP商户密钥、回调报文全部裸奔。上云的话直接申请免费SSL证书整条链路TLS加密。MySQL开启binlog既能做数据恢复也能做增量备份。Redis设置密码绑定内网IP禁止外网直接访问。很多源码默认Redis无密码对外扫到就是一锅端。6.2 队列和定时任务的体系怎么搭支付系统里用到队列的场景特别多回调异步通知、退款处理、分账打款、商户通知。如果源码里没有队列只是同步处理建议一定要引入。Redis的list配合一个常驻的worker进程就能实现队列消费不一定要上RabbitMQ这种重量级中间件。定时任务日常要跑的至少有这么几个发布上线前必须全部配好任务执行频率作用订单超时关闭每1分钟把超过支付时效的订单置为已关闭未回调订单主动查单每5分钟补偿回调丢失的订单渠道账单下载每日凌晨下载前一日渠道对账单本地账单比对每日凌晨与渠道账单逐笔核对结算任务按结算周期生成待结算账单并触发打款6.3 监控报警别等商户找你说订单没到账上线之后最怕的不是出问题而是出了问题你最后一个知道。几个关键指标建议每天盯支付成功率前端发起支付到渠道成功回调的转化率突然下滑说明接口链路有问题。回调平均耗时回调接口如果处理时间超过1秒大概率有同步阻塞在链路上。失败订单堆积数数据库里长时间处于未支付、未回调、未退款状态的订单数量超过阈值就报警。报警方式不必复杂接入群机器人异常订单关键字段推送到群里人工判断比什么都管用。6.4 合规红线没有资质不要碰资金归集最后这点非常非常重要。如果你做的是一个多方参与的平台用户的钱先进入平台账户再由平台分给各个商户这种模式在行业里是被严格监管的。资金归集和二次清算需要对应的合法资质普通企业和个人不能自己构建一套资金归集结算体系否则运营风险极高。所以在采用这套源码的时候我建议用不碰资金的模式让资金直接由持牌的支付渠道结算到各商户自己的账户平台只做通道聚合和技术服务不承担资金的二次清算。系统设计上也要刻意避免用户资金进平台账户再转出这种流程。这是一个行业的底线问题也是技术人保护自己的边界。最后补一句实践心得这套源码我从拿到到跑通前后花了一周多最耗时间的地方不是写代码而是把每个渠道的回调报文格式、签名逻辑、异常返回彻底搞清楚。中途最大的体会是支付这个领域文档上写的东西只是基础真正有用的经验全在异常场景里磨出来的。建议你拿到源码后先把调试模式打开用官方沙箱环境把支付成功但不回调回调重复推送金额不匹配退款失败这几个场景全部模拟一遍亲眼看看自己系统的处理逻辑会不会出问题。把这些场景跑通才是真正拥有一套能用、敢用的支付系统。本文还有配套的精品资源点击获取