简介这份PHP聚合支付源码面向需要快速搭建第三方、第四方收款平台的开发者与中小型支付服务团队解决从零对接多渠道支付接口、统一收银流程的技术门槛问题。资源包共2000个文件压缩后约141.56MB以590个js脚本、486个html页面、318个css样式及148张png、127个gif等前端资源为主同时包含39个php核心文件、27个json配置、11个md说明文档并附带sql建表脚本、htaccess伪静态规则及多语言上传组件覆盖前后台页面、接口逻辑与部署配置。目前已有87人学习下载。借助该源码开发者可快速部署运行环境对接支付宝、微信支付等主流及区域性支付通道实现多支付方式聚合收款同时可参考其目录结构与接口组织方式理解交易数据加密传输、回调校验与订单监控等关键环节为后续业务逻辑扩展和界面优化节省大量基础开发时间。1. 从一笔订单说起PHP聚合支付源码到底在解决什么问题假设你手上有个商城或者一个知识付费站用户下单后要付款。如果只接微信用户想用支付宝就得退出重来如果两个都接你得维护两套回调、两套对账、两套退款逻辑订单状态还经常对不上。PHP聚合支付源码要干的事就是把微信、支付宝、云闪付这些渠道收拢到一个入口对外只暴露一套下单、回调、退款接口对内做渠道路由和状态归一。第四方支付收款平台源码则更进一步它不只服务自己一个站而是给多个商户开号、分账、结算本质是一个小型的支付中台。这套东西适合谁适合手里有多个收款场景、被多渠道回调折磨过的 PHP 后端也适合想搭一套自用收款系统、又不想每家渠道单独写一遍的独立开发者。它不解决“怎么拿到支付牌照”只解决“怎么把已有渠道的接口用工程化的方式管起来”。2. 聚合支付的账本模型订单、流水、渠道单为什么要拆三张表很多人第一次写支付喜欢把订单和支付记录塞一张表加几个字段就完事。单渠道时能跑一旦上聚合退款、补单、对账全乱。核心原因是一笔业务订单可能对应多次支付尝试一次支付尝试又可能因为渠道切换产生多条渠道流水。这三者的生命周期不一样必须拆开。2.1 业务订单、支付流水、渠道单的职责边界业务订单order记录的是“用户想买什么、应付多少”它的状态只有待支付、已支付、已关闭、已退款这几种由业务系统关心。支付流水payment记录的是“这一次收款动作”一个订单可以有多条流水比如用户第一次用微信没付成功第二次换支付宝付了就有两条流水但只有一条是成功的。渠道单channel_order记录的是“发给微信/支付宝的那一笔请求”它带着渠道返回的 transaction_id、原始报文、签名串是排查问题时唯一的黑匣子。拆开之后对账逻辑就清晰了拿渠道单去和渠道对账单核对核对结果回写支付流水支付流水汇总后驱动业务订单状态。退款也一样退款单挂在支付流水下而不是挂在业务订单下因为退的是某一笔具体的收款。2.2 建表语句与关键字段说明下面是一套最小可用的表结构MySQL 8 下直接能跑。注意金额字段统一用 int 存分别用 decimal浮点误差在支付里是血泪教训。-- 业务订单表 CREATE TABLE pay_order ( id bigint unsigned NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 业务订单号全局唯一, merchant_id int NOT NULL COMMENT 商户号第四方场景下必填, amount int NOT NULL COMMENT 应付金额单位分, subject varchar(128) NOT NULL COMMENT 商品标题, status tinyint NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已关闭 3已退款, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, paid_at datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_merchant_status (merchant_id,status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 支付流水表 CREATE TABLE pay_payment ( id bigint unsigned NOT NULL AUTO_INCREMENT, payment_no varchar(32) NOT NULL COMMENT 支付流水号, order_no varchar(32) NOT NULL, channel varchar(16) NOT NULL COMMENT wechat/alipay/unionpay, amount int NOT NULL, status tinyint NOT NULL DEFAULT 0 COMMENT 0处理中 1成功 2失败, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_payment_no (payment_no), KEY idx_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 渠道单表 CREATE TABLE pay_channel_order ( id bigint unsigned NOT NULL AUTO_INCREMENT, payment_no varchar(32) NOT NULL, channel varchar(16) NOT NULL, channel_trade_no varchar(64) DEFAULT NULL COMMENT 渠道返回的交易号, request_body text COMMENT 请求原始报文, response_body text COMMENT 回调或查询原始报文, status tinyint NOT NULL DEFAULT 0, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_payment_no (payment_no), KEY idx_channel_trade (channel,channel_trade_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;order_no和payment_no都建唯一索引是因为支付回调可能重复推送靠数据库唯一约束兜底比在代码里判重可靠。request_body和response_body用 text 存原始报文别只存解析后的字段渠道改字段时你会感谢自己留了原文。merchant_id在自用场景可以固定为 1第四方场景下它是分账和结算的依据。2.3 状态机怎么设计才不会出现“已支付又变待支付”状态流转必须单向。业务订单只允许 0→1、0→2、1→3任何反向流转都要在代码层拒绝。支付流水只允许 0→1、0→2。渠道单的状态跟着渠道回调走但渠道单状态变化不直接改业务订单而是通过支付流水这个中间层。常见翻车是回调里直接UPDATE pay_order SET status1结果重复回调把已退款的订单又改回已支付。正确做法是回调先落渠道单再更新支付流水最后用一个独立的结算任务根据流水汇总更新订单每一步都带WHERE status前一个状态的条件更新靠 affected rows 判断是否重复。3. 渠道路由与签名PHP 里怎么把微信支付宝收进同一个入口聚合支付的核心不是“聚合”这个词而是“统一”。对外一套参数对内适配各家差异。这一章讲路由怎么选、签名怎么统一、回调怎么归一。3.1 统一下单参数与渠道路由策略对外暴露的下单接口参数应该只有商户号、商户订单号、金额、商品标题、支付方式可选、异步通知地址。支付方式不传时由路由策略决定走哪个渠道。路由策略常见有三种按权重轮询、按费率最低、按渠道可用性。自用场景我一般用“指定优先 兜底轮询”即用户选了微信就走微信没选就按配置的权重轮。?php // 统一下单入口路由到具体渠道 class PayGateway { // 渠道权重配置值越大越优先 private array $channelWeight [ wechat 80, alipay 60, unionpay 20, ]; public function createOrder(array $params): array { // 参数校验金额必须是正整数分 if (empty($params[order_no]) || empty($params[amount])) { throw new InvalidArgumentException(订单号和金额必填); } if (!is_int($params[amount]) || $params[amount] 0) { throw new InvalidArgumentException(金额必须为正整数分); } // 路由指定渠道则直连否则按权重选 $channel $params[channel] ?? $this-routeByWeight(); $handler $this-getHandler($channel); // 生成支付流水号落库后再请求渠道 $paymentNo date(YmdHis) . mt_rand(100000, 999999); // ... 此处落库 pay_payment 和 pay_channel_order return $handler-unifiedOrder($params, $paymentNo); } private function routeByWeight(): string { $total array_sum($this-channelWeight); $rand mt_rand(1, $total); foreach ($this-channelWeight as $ch $w) { $rand - $w; if ($rand 0) { return $ch; } } return wechat; } private function getHandler(string $channel): object { // 简单工厂实际项目建议用容器绑定 return match ($channel) { wechat new WechatHandler(), alipay new AlipayHandler(), default throw new RuntimeException(不支持的渠道), }; } }channelWeight是路由的核心参数改权重就能调整流量分配不需要动业务代码。routeByWeight用累减法实现加权随机比先算区间再判断更直观。paymentNo在请求渠道之前生成并落库是为了防止渠道请求超时后无法追溯——先有流水号再去请求超时了也能凭流水号去查渠道。注意金额校验用is_int因为 HTTP 传过来的都是字符串入口处要显式转成 int别指望 PHP 自动转换。3.2 各渠道签名差异与统一封装微信 v3 用 SHA256-RSA 签名支付宝用 RSA2云闪付用 SHA256。差异在于待签名串的拼接规则和密钥格式。统一封装的做法是每个 Handler 实现sign(array $data): string和verify(array $data, string $sign): bool上层不关心具体算法。?php // 微信 v3 签名示例 class WechatHandler { public function sign(array $data): string { // 待签名串METHOD\nURL\nTIMESTAMP\nNONCE\nBODY\n $message $data[method] . \n . $data[url] . \n . $data[timestamp] . \n . $data[nonce] . \n . $data[body] . \n; // 私钥签名OPENSSL_ALGO_SHA256 openssl_sign($message, $signature, $this-privateKey, OPENSSL_ALGO_SHA256); return base64_encode($signature); } public function verifyNotify(array $headers, string $body): bool { // 回调验签用平台证书公钥验 Wechatpay-Signature $message $headers[Wechatpay-Timestamp] . \n . $headers[Wechatpay-Nonce] . \n . $body . \n; $sign base64_decode($headers[Wechatpay-Signature]); return openssl_verify($message, $sign, $this-platformCert, OPENSSL_ALGO_SHA256) 1; } }微信 v3 的待签名串里BODY后面必须带一个换行少这个换行签名必错这是最常见的翻车点。openssl_verify返回值是 1 表示成功0 表示失败-1 表示错误判断时必须用 1别用if (openssl_verify(...))因为 -1 也是真值。支付宝的签名串是把参数按 key 字典序拼接空值不参与和微信完全不同所以每个渠道的 Handler 要独立实现不要试图抽一个“通用签名函数”。3.3 异步回调的统一入口与幂等处理回调是聚合支付最容易出问题的地方。统一入口的做法是URL 形如/notify/{channel}路由到对应 Handler 的verifyNotify验签通过后把原始报文落渠道单然后触发幂等更新。?php // 统一回调入口 public function notify(string $channel): string { $handler $this-getHandler($channel); $body file_get_contents(php://input); $headers getallheaders(); if (!$handler-verifyNotify($headers, $body)) { return $handler-failResponse(验签失败); } // 落渠道单response_body 存原始报文 $channelTradeNo $handler-extractTradeNo($body); $paymentNo $handler-extractOutTradeNo($body); // 幂等先查渠道单是否已处理 $exists $this-db-query( SELECT id FROM pay_channel_order WHERE channel? AND channel_trade_no? AND status1, [$channel, $channelTradeNo] ); if ($exists) { return $handler-successResponse(); // 重复回调直接返回成功 } // 条件更新支付流水affected rows 为 0 说明已处理过 $affected $this-db-exec( UPDATE pay_payment SET status1 WHERE payment_no? AND status0, [$paymentNo] ); if ($affected 0) { // 只有真正更新成功才触发订单结算 $this-settleOrder($paymentNo); } return $handler-successResponse(); }幂等的关键在WHERE status0这个条件重复回调时 affected rows 为 0不会重复触发结算。file_get_contents(php://input)读原始 body不要用$_POST因为微信 v3 回调是 JSON body$_POST读不到。返回给渠道的响应体必须符合各渠道格式微信要{code:SUCCESS}支付宝要纯文本success返回错了渠道会一直重推直到把你服务器打满。4. 第四方收款平台的多商户与分账从单商户到平台化要补什么自用聚合支付和第四方收款平台源码的差距就在多商户和分账。第四方场景下一个平台要服务 N 个商户每个商户有自己的密钥、费率、结算周期资金先到平台再结算给商户。这一章讲清楚要补哪些模块。4.1 商户隔离密钥、费率、结算周期怎么存商户表是第四方平台的核心。每个商户要有独立的 API 密钥用于商户请求平台时验签、独立的渠道配置商户自己的微信/支付宝商户号或者平台代收、独立的费率平台抽成比例、独立的结算周期T1 或 T0。CREATE TABLE pay_merchant ( id int NOT NULL AUTO_INCREMENT, merchant_no varchar(16) NOT NULL COMMENT 商户号, api_key varchar(64) NOT NULL COMMENT 商户请求平台的签名密钥, rate int NOT NULL DEFAULT 0 COMMENT 费率万分之几, settle_cycle tinyint NOT NULL DEFAULT 1 COMMENT 0 T0 1 T1, channel_config json DEFAULT NULL COMMENT 各渠道商户号配置, status tinyint NOT NULL DEFAULT 1, PRIMARY KEY (id), UNIQUE KEY uk_merchant_no (merchant_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;rate用万分之几存整数避免小数。channel_config用 JSON 存各渠道的商户号、密钥引用比开一堆列灵活。注意api_key不要明文存至少用 AES 加密后存密钥管理是第四方平台的安全底线。4.2 分账逻辑平台抽成与商户结算怎么算分账的核心是用户付 100 元平台费率万分之六平台抽 0.6 元商户得 99.4 元。但实际结算时还要考虑渠道成本微信收 0.6%、退款、冻结期。常见做法是记两笔账平台收入账和商户待结算账。?php // 支付成功后的分账记账 public function settleOrder(string $paymentNo): void { $payment $this-getPayment($paymentNo); $merchant $this-getMerchant($payment[merchant_id]); // 平台抽成 金额 * 费率 / 10000向下取整 $platformFee intdiv($payment[amount] * $merchant[rate], 10000); $merchantAmount $payment[amount] - $platformFee; // 记平台收入 $this-db-insert(pay_platform_income, [ payment_no $paymentNo, amount $platformFee, ]); // 记商户待结算T1 则结算日期为次日 $settleDate $merchant[settle_cycle] 0 ? date(Y-m-d) : date(Y-m-d, strtotime(1 day)); $this-db-insert(pay_merchant_settle, [ merchant_id $merchant[id], payment_no $paymentNo, amount $merchantAmount, settle_date $settleDate, status 0, // 待结算 ]); }intdiv做整数除法避免浮点。platformFee向下取整差额归商户这样平台不会因为四舍五入多收钱。settle_date决定什么时候能提现T0 当天可结T1 次日。注意退款时要反向记账从商户待结算里扣回如果已结算则记商户欠款这个逻辑必须在退款回调里同步处理否则账会对不上。4.3 对账任务怎么用渠道账单核对本地流水对账是第四方平台的后悔药。每天凌晨拉取各渠道的对账单和本地渠道单逐笔核对。差异分三种本地成功渠道没有可能渠道延迟、渠道成功本地没有可能回调丢失、金额不一致严重要人工介入。?php // 简化的对账流程 public function reconcile(string $channel, string $billDate): array { // 1. 拉取渠道对账单解析成 [channel_trade_no amount] $channelBills $this-fetchChannelBill($channel, $billDate); // 2. 查本地当天成功的渠道单 $localOrders $this-db-query( SELECT channel_trade_no, amount FROM pay_channel_order WHERE channel? AND status1 AND DATE(created_at)?, [$channel, $billDate] ); $diff [local_only [], channel_only [], amount_mismatch []]; $localMap array_column($localOrders, amount, channel_trade_no); foreach ($channelBills as $tradeNo $amount) { if (!isset($localMap[$tradeNo])) { $diff[channel_only][] $tradeNo; // 渠道有本地无补单 } elseif ($localMap[$tradeNo] ! $amount) { $diff[amount_mismatch][] $tradeNo; // 金额不一致人工 } unset($localMap[$tradeNo]); } $diff[local_only] array_keys($localMap); // 本地有渠道无排查 return $diff; }channel_only的差异通常用补单任务处理拿渠道交易号反查本地支付流水如果本地流水存在但状态是处理中就补一次结算。local_only要警惕可能是渠道请求根本没成功但本地记了成功属于严重 bug。amount_mismatch必须人工任何自动处理都可能掩盖资金问题。对账任务要幂等同一天重复跑不能产生重复补单靠补单记录的唯一索引兜底。5. 避坑与排查聚合支付源码上线后最容易翻车的 5 个点这一章全是踩过的坑每条按现象、原因、解决写。上线前对着过一遍能省很多半夜爬起来查日志的时间。5.1 回调重复推送导致重复发货现象用户付了一笔系统发了两次货或者订单状态被改了两次。原因渠道回调是 at-least-once 语义网络抖动、你响应超时都会触发重推而代码里没有幂等判断每次回调都执行发货。解决回调入口先查渠道单表用channel_trade_no做唯一约束重复的直接返回成功更新支付流水时带WHERE status0靠 affected rows 判断是否首次处理。发货动作挂在“首次更新成功”之后不要挂在回调入口。5.2 金额用浮点导致对账差一分钱现象本地订单金额 99.99渠道对账单 99.98差一分。原因PHP 浮点运算0.1 0.2 ! 0.3金额在传参、计算费率、分账时经过多次浮点运算误差累积。解决全链路用整数分。入口处把元转分用intval(bcmul($yuan, 100))别用$yuan * 100。费率计算用intdiv分账差额归一方。数据库金额字段用 int不用 decimal 也不用 float。5.3 签名串拼接错误导致渠道一直报签名失败现象本地自测签名通过一上生产就报签名错误。原因签名串里的换行符、空值处理、参数排序和渠道文档不一致。微信 v3 的 BODY 后必须带换行支付宝空值参数不参与签名云闪付要按 ASCII 排序。解决每个渠道单独写签名函数用渠道官方提供的签名校验工具先验证再接入。签名串拼接时用\n而不是PHP_EOL因为PHP_EOL在 Windows 下是\r\n会导致签名不一致。5.4 异步通知地址配错导致回调收不到现象用户付款成功但本地订单一直待支付手动查渠道显示已支付。原因异步通知地址填的是内网地址、带端口的地址、或者有重定向的地址渠道服务器访问不到。解决通知地址必须是公网可访问的 HTTPS 地址不能带非标准端口不能有 301/302 跳转。上线前用 curl 从外网模拟渠道回调确认能通。如果用了 CDN 或 WAF确认没有拦截渠道的 IP 段。5.5 渠道证书过期导致批量下单失败现象某天早上所有微信支付下单全部失败报证书错误。原因微信 v3 的平台证书有有效期过期后验签和请求都会失败。解决把证书有效期做成监控项提前 30 天告警。代码里不要硬编码证书路径用配置中心下发支持热更新。微信平台证书可以通过接口自动下载更新写个定时任务每天检查一次比人工换证书可靠。6. 把聚合支付源码跑稳之后我习惯做的两件事第一件事是压测回调入口。聚合支付的瓶颈从来不在下单在下单之后的回调处理。我一般用ab或wrk对回调 URL 打 500 并发看数据库连接池和锁等待。如果回调里用了SELECT ... FOR UPDATE高并发下很容易死锁改成条件更新UPDATE ... WHERE status0能绕开行锁竞争。压测时重点看两个指标回调平均响应时间和数据库慢查询数量。响应超过 3 秒渠道就会重推慢查询超过 10 条说明索引没建对。第二件事是给对账任务加一个“差异看板”。不用很复杂一张表记录每天的差异笔数和差异金额超过阈值就发告警。我自己的习惯是差异笔数超过当天总笔数的 0.1% 就人工介入金额差异超过 100 元直接电话。这个看板跑一个月你就能摸清各渠道的脾气哪个渠道回调延迟高、哪个渠道对账单出得晚、哪个渠道偶尔丢回调。摸清之后补单策略就能按渠道定制而不是一刀切。最后说个具体技巧所有渠道的原始报文不管是请求还是回调都落库保留至少 180 天。我吃过亏有一次渠道改了字段含义本地解析全错全靠原始报文回放才定位到问题。存报文的成本很低一张 text 字段加个索引比出事之后抓瞎强太多。这套东西值不值得做如果你只有一个站、只接一个渠道没必要上聚合直接调官方 SDK 更省事。但只要你有两个以上收款场景或者要给别的商户开号这套账本模型和幂等回调的底子早晚要补。希望帮到你。本文还有配套的精品资源点击获取
