企业官网建设流程全解析

简介：这是基于ThinkPHP框架开发的四方支付系统商业版源码，面向需要快速搭建聚合支付平台的企业开发者与二次开发商，支持支付宝、微信、银联等多渠道一站式接入，并内置商户管理、订单处理、资金结算与风险控制等完整支付闭环。压缩包共2000个文件，约47.73MB，核心逻辑为849个PHP文件，另有大量gif/png/jpg图片资源、html/js/css前端页面、dat数据文件及配置文件，整体目录结构清晰，便于按模块查阅与定制。目前已吸引2661人学习下载，在中小型支付系统选型中有一定参考价值。资源附有完整的接口文件及API文档，开发者可获得支付请求、回调处理、对账结算等关键环节的实现参考，并能基于ThinkPHP的MVC架构快速扩展或改造，适合具备PHP开发经验、希望自主掌控支付流程的团队实践使用。

1. 四方支付源码：别把聚合支付想成一层壳，它其实是个可插拔的支付网关

我有段时间接连接了多个支付项目，最深的体会是：换一个支付通道，业务代码就要从头改一遍。后来拆了一套基于ThinkPHP的四方支付源码，才真正意识到四方支付要解决的不是“多接几个通道”，而是把通道差异、回调安全、账务一致这些脏活隔离到独立层。这套源码自带商户管理、订单管理、异步通知、定时查单、每日对账和清晰的结构化扩展点，适合想快速搭起聚合支付平台的开发者，也适合想看看策略模式和状态机怎么落到真实业务里的PHP后端。

2. 技术选型与整体架构：ThinkPHP如何撑起一个多通道支付系统

2.1 四方支付要解决的核心问题：通道差异、回调安全和账务一致

四方支付的“四方”是相对第三方支付平台而言的。第三方支付直接跟商户和银行结算，四方支付则夹在商户与多个第三方通道之间，做统一接入、统一验签、统一通知。它不碰资金，只维护一份订单账本，所以整个系统的核心诉求是账务一致，而不是资金安全。这一点很容易被误解，很多人把四方支付当成一个多通道转发工具，忽略了账务对账才是生命线。

基于这个边界，系统至少要拆出三个域。通道域负责把不同支付平台的接口差异封装起来，对外暴露统一的下单、验签、退款、查单能力。业务域负责订单状态机、商户信息、费率和通知发送。管理域提供平台管理端和商户端，维护渠道配置、密钥和IP白名单。三个域通过订单表和商户表串起来，业务代码不直接访问通道接口，而是通过一个工厂类去拿通道实例。

我拆源码时有个习惯：先看通道域能不能满足“新增一个通道不动业务代码”这个条件。如果整个项目里用大量 if...else 判断通道类型，那这个四方支付多半只是个壳，谈不上架构。合格的实现一定把通道看成一等公民，每个通道是一个策略类，所有通道遵守同一个接口。

2.2 总体架构：从商户请求到通道响应，中间有三层

这个源码的纵向链路可以理解成三层。最前面是接口层，集中在 app/pay/controller 目录，所有面向商户的支付接口都在这里收口，负责参数校验、公共错误码、以及叫醒后续服务层。中间是服务层，在 app/pay/service 目录下，订单创建、退款申请、通知重试这些真正的业务逻辑都在这里，服务层只认订单状态，不认具体通道。最后是策略层，在 app/pay/strategy 目录下，每个通道一个类，实现统一的 PayChannelInterface 接口。

分层之后收益非常直接。你要加一个通道，接口层和服务层一个字都不用改，只需要在策略层新增一个类，然后在工厂里注册。反过来，某个通道的签名规则变了，也只在对应策略类里修，不会牵扯到订单生成逻辑。我见过不少项目把通道参数塞在下单方法里，结果一个通道改字段，所有业务代码跟着抖。

用 ThinkPHP 做这个架子，图的是它的几样现成能力：验证器把参数校验写在入口，命令行指令天然配合定时任务，ORM 能少写很多 SQL。支付系统的特点是接口多、状态多、回调多、定时任务多，这些在 ThinkPHP 里都能做到模块化挂载，不需要再引入一套微服务框架。

2.3 目录结构和数据库设计：订单、商户、渠道三张表怎么落库

拿到源码后建议先花一刻钟把目录读一遍。常见的四方支付源码会按模块拆成这样：

app ├── admin // 平台管理端 ├── index // 商户门户 ├── pay // 支付网关核心 │ ├── controller │ ├── service │ └── strategy ├── common // 公共模型和助手函数 └── api // 对外开放API

pay/strategy 是整套源码的灵魂。它下面每个通道类都需要实现四个能力：pay（发起支付）、verify（验签）、refund（退款）、query（查单）。只要接口统一定义好，后续扩展只是新增文件的问题。

数据库层面，最核心的是订单、商户、渠道、回调日志这四张表：

pay_order 里的 status 建议用整数状态机：0 待支付、1 支付成功、2 退款中、3 已关闭、4 已退款。金额字段 amount 用整数分存储，不要用 float，这个决定直接影响后面的对账能不能做平。pay_notify_log 看起来不起眼，但回调排查和防重复通知都要靠它。每次收到回调先落库，再走业务逻辑，出问题能回溯到原始报文。

建表的时候还要注意两个索引：pay_order 的 order_no 唯一索引，pay_order 的 merchant_id + create_time 联合索引。前者是并发下单的防重手段，后者是后台按商户查订单的核心路径。没有唯一索引，后面代码里的幂等处理会失去最重要的兜底。

3. 核心模块拆解：一次支付从下单到异步回调的完整链路

3.1 下单入口：参数校验与订单生成

第一次翻开这个源码，建议从 PayController 的 createOrder 方法开始看。它把外部请求挡在最外面，先做参数校验，再交给服务层。

<?php namespace app\pay\controller; use app\pay\service\PayService; use think\Request; use think\exception\ValidateException; class PayController { public function createOrder(Request $request) { $data = $request->post(); try { validate([ 'merchant_id' => 'require|integer', 'channel_code' => 'require|alphaDash', 'amount' => 'require|integer|between:1,100000000', 'notify_url' => 'require|url|max:255', 'sign' => 'require|length:32', ])->check($data); } catch (ValidateException $e) { return json(['code' => 40001, 'msg' => $e->getError()]); } $orderNo = $this->payService->createOrder($data); return json(['code' => 0, 'data' => ['order_no' => $orderNo]]); } }

校验规则里有几个细节值得注意。amount 必须是整数，最小 1，最大限制到一亿元，单位是分，从入口就避免浮点数和超范围金额。sign 要求 32 位，这是这类支付系统最常见的签名长度，但真正的验签不会只靠长度判断，要在服务层用商户密钥重新计算。notify_url 必须是 URL，否则异步回调发不出去。

这里顺带提一句：实际上下单接口里还应该有一个对商户密钥的验签动作，很多源码把它放在一个 BaseController 的构造方法里，每个商户请求进来先验一次。验签失败的请求直接返回签名错误，根本不会进到 createOrder。这样的好处是后续新增任何商户接口，都能自动带上验签拦截，而不是每个方法都写一遍。

服务层 createOrder 做的事情也不复杂，但顺序很重要：先查商户是否存在且状态正常，再生成订单号，最后插入订单表。

public function createOrder(array $data): string { $merchant = Db::name('pay_merchant') ->where('merchant_id', $data['merchant_id']) ->find(); if (!$merchant || $merchant['status'] !== 1) { throw new BizException('商户不存在或已被关闭'); } $orderNo = $this->generateOrderNo(); Db::name('pay_order')->insert([ 'order_no' => $orderNo, 'merchant_id' => $data['merchant_id'], 'channel_code' => $data['channel_code'], 'amount' => $data['amount'], 'status' => 0, 'create_time' => time(), ]); return $orderNo; }

订单号生成我这里会特别看一下。单纯用 uniqid() 在并发下会重复，同一秒两个请求生成同一个订单号会导致唯一索引冲突。比较稳妥的做法是日期时间加随机数，再拼上数据库自增ID的最后几位；高级一点可以在内存里维护一个序列号。下面是一个够用的写法：

private function generateOrderNo(): string { $date = date('YmdHis'); $rand = str_pad(random_int(0, 9999), 4, '0', STR_PAD_LEFT); return $date . $rand; }

这个写法在单机低并发下能扛住大部分场景。如果真正上线后并发很高，可以把随机数换成 Redis 自增序列，或者干脆由数据库自增ID反哺订单号一部分。生成订单号后，插入时如果碰到 Duplicate entry，说明商户端重复提交了同一笔单，要捕获异常并返回已有订单号，而不是报错。这段逻辑放在服务层还是数据库层不是重点，重点是必须兜住唯一索引冲突。

3.2 通道选择：策略模式下的渠道路由

订单入库以后，需要根据 channel_code 选择一个通道去发起支付。这个源码的做法是维护一个 ChannelFactory，把通道编码映射到具体策略类。

<?php namespace app\pay\strategy; use app\pay\strategy\contract\PayChannelInterface; class ChannelFactory { private array $channels = [ 'platform_a' => PlatformAChannel::class, 'platform_b' => PlatformBChannel::class, ]; public function make(string $channelCode): PayChannelInterface { if (!isset($this->channels[$channelCode])) { throw new \RuntimeException('不支持的支付通道'); } $class = $this->channels[$channelCode]; return new $class(); } }

配合这个工厂的是一个接口约束：

namespace app\pay\strategy\contract; interface PayChannelInterface { public function pay(array $params): array; // 返回二维码内容或跳转URL public function verify(array $data): bool; // 对异步通知验签 public function refund(array $params): bool; // 发起退款 public function query(string $tradeNo): array; // 主动查单 }

服务层在发起支付时只做一件事：拿到通道实例，调用 pay 方法。至于 platform_a 需要把参数按 ASCII 排序后拼 key，platform_b 要做 RSA 验签，这些差异全部藏在各自策略类里。新增通道时在 channels 数组加一行就够了，这是策略模式在支付系统里最典型的应用场景。唯一要注意的是这个工厂不能做成上帝类，如果通道数量膨胀到几十个，应该改成配置驱动，从 pay_channel 表读渠道编码映射到完整类名，而不是在代码里维护一个越来越大的数组。

3.3 生成支付页：二维码和跳转链接的统一返回

通道 pay 方法返回的数据源头上分两种，一种返回二维码字符串，一种返回跳转链接。服务层要做的是把它们转成一个稳定的响应结构，前端才好统一渲染。

$channel = (new ChannelFactory())->make($order['channel_code']); $result = $channel->pay([ 'order_no' => $order['order_no'], 'amount' => $order['amount'], 'notify_url' => $this->getNotifyUrl($channelCode), ]); if (isset($result['qr_code'])) { return json(['type' => 'qr_code', 'content' => $result['qr_code']]); } if (isset($result['redirect_url'])) { return json(['type' => 'redirect', 'url' => $result['redirect_url']]); }

我在这类项目里吃过一个亏：如果直接把通道返回的完整 HTML 塞给前端，后面想统一改页面风格就非常麻烦。正确的做法是先把上游返回的支付标识解析成纯数据，再承载到 response 结构里。二维码 content 可能是一个字符串 URL，也可能是一串参数，对前端来说都是 content 字段，透明处理就好了。

3.4 异步回调：验签、防重复与状态机推进

回调接口是整个四方支付源码里最容易写错的地方。它跟普通接口不一样，上游通道会多次重试，你必须在入口处理好三件事：验签、幂等、状态流转。

public function notify(string $channelCode, Request $request) { $payload = $request->post(); $channel = (new ChannelFactory())->make($channelCode); if (!$channel->verify($payload, $payload['sign'] ?? '')) { return 'fail'; } $order = Db::name('pay_order') ->where('order_no', $payload['order_no'] ?? '') ->find(); if (!$order) { return 'fail'; } if ($order['status'] === 0) { $updated = Db::name('pay_order') ->where('order_no', $order['order_no']) ->where('status', 0) ->update([ 'status' => 1, 'pay_time' => time(), 'channel_trade_no' => $payload['trade_no'] ?? '', ]); if ($updated) { $this->pushMerchantNotify($order); } } return 'success'; }

这段代码的关键在第4步的条件更新。where 条件里多一个 status = 0，意味着只有待支付订单能被更新成成功。如果是定时查单任务先更新了状态，回调再来时更新行数为 0，就不会触发重复通知。返回 'success' 也是告诉通道不要再重试，但如果这里因为校验失败返回异常，几乎所有通道都会继续重试，所以验签失败要用 fail 而不是抛异常。

回调原始报文最好先落一张 notify_log 表，再走业务逻辑。后面排查问题，直接查这张表就能看到通道到底发了什么，比靠猜强得多。这个设计不复杂，但很多只求功能跑通的项目都不做，真出问题才到处抓包。落库的字段至少包括：订单号、请求方IP、原始报文、接收时间、处理结果。

4. 定时任务与对账：主动查单、补单与系统稳定性

4.1 超时订单扫单：为什么除了回调还要主动去查

异步回调再快也只是通知，网络抖动、商户服务重启、防火墙拦截都可能导致通知丢失。四方支付系统必须有一个兜底机制：定时扫描待支付订单，主动去通道侧查询真实支付状态。常见做法是用 ThinkPHP 的独立指令进程处理，不写进 Web 请求里。

namespace app\pay\command; use think\console\Command; use think\console\Input; use think\console\Output; use think\facade\Db; class CheckTimeoutOrder extends Command { protected function configure() { $this->setName('pay:checkTimeout')->setDescription('扫描超时未支付订单'); } protected function execute(Input $input, Output $output) { $deadline = time() - 600; $orders = Db::name('pay_order') ->where('status', 0) ->where('create_time', '<', $deadline) ->limit(200) ->select(); foreach ($orders as $order) { $this->queryOrder($order); } $output->writeln('check done'); } }

这里的 limit(200) 不是随意写的。一次拉太多订单会让通道的查询接口瞬间被打满，尤其定时任务重启或者堆积大量订单时，通道会直接拒掉请求。每5分钟跑一次、每次处理200单，是大多数四方支付源码在中小并发下的安全值。如果要处理更高量级，应该增加分页和游标方式。

命令名配置在 config/console.php 里，注册后通过php think pay:checkTimeout执行。cron 里写成*/5 * * * * /usr/bin/php /项目目录/think pay:checkTimeout就行。要注意不能让两个进程同时跑同一个扫单任务，简单做法是在任务入口用 Redis 或数据库加一个锁，拿到锁才执行。

4.2 主动查单与状态修复：并发更新的关键一步

queryOrder 的任务是根据通道查询结果刷新本地订单状态。状态从0变成1或者变成3，都必须使用条件更新。

private function queryOrder(array $order) { $channel = (new ChannelFactory())->make($order['channel_code']); $result = $channel->query($order['order_no']); if ($result['status'] === 1) { $updated = Db::name('pay_order') ->where('order_no', $order['order_no']) ->where('status', 0) ->update(['status' => 1, 'pay_time' => time()]); if ($updated) { $this->pushMerchantNotify($order); } } elseif ($result['status'] === 2) { Db::name('pay_order') ->where('order_no', $order['order_no']) ->where('status', 0) ->update(['status' => 3, 'close_time' => time()]); } }

条件更新在这里有一个额外作用：天然做了并发保护。定时任务在跑的同时，异步回调可能也在处理同一笔订单。两个流程都读到 status = 0，但如果都直接用上一个流程读到的订单对象做 update，第二个更新会覆盖第一个的 pay_time，造成状态混乱。加上 where status = 0 和判断影响行数，只有一条流程能真正完成状态流转，另一个更新行数为0时直接跳过。

pushMerchantNotify 的实现通常会放进一个 beantask 队列或 notify_queue 表。通知也讲究幂等：只有状态机真正更新成功的那一次流程才允许写通知，否则商户会收到两条相同结果。如果通知失败，还要有重试机制，常见做法是记录 notify_count 和 last_notify_time，超过最大重试次数后人工介入。

4.3 每日对账：通道账单与本地订单逐行比对

对账是支付系统最后一道安全网。每天凌晨从通道侧拉取前一天的交易账单，按订单号或者通道流水号逐行跟本地 pay_order 比对，把不一致的记录抽出来。

public function dailyReconciliation(string $date) { $billList = $this->pullChannelBill($date); foreach ($billList as $bill) { $order = Db::name('pay_order') ->where('channel_trade_no', $bill['trade_no']) ->find(); if (!$order) { $this->misMatchRecord[] = ['type' => 'no_local_order', 'trade_no' => $bill['trade_no']]; } elseif ($order['amount'] != $bill['amount']) { $this->misMatchRecord[] = ['type' => 'amount_mismatch', 'order_no' => $order['order_no']]; } } // 生成汇总报告，推送给平台运营人员 }

对账的金额比较必须用整数，因为本地订单 amount 和通道账单的金额单位都是分。如果之前用了 float，这里会不断出现一分钱两分钱的差异，排查到最后通常是乘法的精度问题。对账单拉取频率一般一天一拉，但量大的项目可以做成每小时增量对账。

对账任务不适合放在 Web 请求里执行，因为账单数据量大时会超出 PHP 默认运行时限。标准的姿态同样是指令任务，在 cron 里配置php think pay:reconcile运行。对账结果可以输出成一个 CSV 文件，也可以直接插表，由后台页面展示不一致列表。无论哪种，目标都是把差异暴露出来，而不是自动修掉所有异常。

4.4 避坑：这些现象我在同类支付项目里见过不止一次

现象一：回调偶尔丢单，但跑一遍查单任务就能补回来。原因是商户配置的 notify_url 写成了内网地址，或者通知在网关层被拦掉。解决：回调地址统一放到配置表里，后台可灵活修改，调试时用同网段可访问的域名，不要用 localhost。

现象二：定时任务和回调同时更新同一笔订单，商户被通知了两次。原因是两个流程各自做了 update，没有条件约束。解决：所有状态刷新都用 where status = 0 的条件更新，并检查 update 返回的影响行数。这也是这个源码里最值得学的写法。

现象三：每天对账都差几分钱。原因是下单时用 float 计算了手续费，比如乘以 0.006 得到 0.599999。解决：金额和费率全部换算成整数分，PHP 里用 int 处理，最后入库的也是 int。这是支付系统的底线约定，不管下游通道文档怎么写，本地账本必须坚持整数。

现象四：回调返回 success，通道仍然不停重发。原因是通道要求返回 SUCCESS（大写），或者固定字符串。解决：把回调返回值做成通道级别的配置，在策略类里定义 notifySuccess() 和 notifyFail() 两个方法，统一由接口层调用，不要全局写死。

注意：在接入任何新通道前，先看它文档里的回调返回协议写的是什么，很多通道只看响应体内容，不看状态码。

现象五：新增了通道，工厂里也注册了类，但管理后台看不到新通道。原因是只改了代码，没往 pay_channel 表里插渠道配置。解决：后台渠道管理在新增操作里同时写数据库配置和生成代码占位，前端再读 pay_channel 表展示，数据与代码分离而不是只靠硬编码。

5. 安全设计与权限控制：四方支付源码里值得反复看的细节

5.1 商户签名机制：请求到网关前先过验签

四方支付源码里最基础的安全设计是商户签名。商户每次请求都带着 api_key、业务参数和一个 sign，网关拿到参数后按既定规则重新计算一遍 sign，比对通过才继续。

public function verifySign(array $data, string $secretKey): bool { $sign = $data['sign'] ?? ''; unset($data['sign']); ksort($data); $str = urldecode(http_build_query($data)) . '&key=' . $secretKey; return md5($str) === $sign; }

这里的细节是：去掉 sign 字段后用 ksort 保证拼接顺序，两边一致才能算出相同签名。http_build_query 会对参数做 URL 编码，所以计算前要 urldecode 一次，不然中文参数和特殊字符会让两端签名不一致。secret_key 只在服务端保存，不在请求中传输。

md5 签名在今天的安全强度里已经不算高，但胜在实现简单、兼容性好，很多通道仍然在用。源码里通常会把验签逻辑收敛到通道策略类的 verify 方法，这样以后要升级成哈希消息认证码或非对称加密，替换位置非常集中。

密钥管理是另一个值得学习的地方。优秀的四方支付源码会把 secret_key 用可逆加密后存入数据库，后台列表和接口日志里只显示前几位字符，比如sk_****abc123。这样即使数据库被拖走，也拿不到能直接算签名的明文密钥。

5.2 IP白名单与权限控制：哪些接口需要额外拦一层

商户后台登录、退款申请这类高风险操作，通常需要额外限制来源 IP。源码里会维护一张 pay_merchant_ip 表，在进入业务逻辑前先校验请求 IP 是否在允许范围。

$allowedIps = Db::name('pay_merchant_ip') ->where('merchant_id', $order['merchant_id']) ->column('ip'); if (!in_array($request->ip(), $allowedIps)) { return json(['code' => 403, 'msg' => 'IP not allowed']); }

但回调接口不建议直接套用这个逻辑，因为通道的回调来源 IP 可能经常变。常见的做法是把 IP 白名单做成一个配置项，只在后台手动开启的商户上生效。普通商户仅靠验签和订单状态机，已经能挡住绝大多数伪造请求。

后台权限控制也会在管理端模块里分层。平台管理员能管理渠道和商户，商户管理员只能查看自己名下的订单和退款记录。这类权限用规则的 RBAC 实现，重点不是写多少条 else if，而是把实体关系绑定清楚：商户下的子账号不能越权读其它商户数据。数据隔离比接口隔离更容易被忽视，支付项目里一旦越权，就是资金层面的泄露。

5.3 幂等处理：并发下单、重复通知、重复退款

支付系统的幂等体现在三个位置。第一个是下单，商户端在网络超时后会重试，同一个订单号可能被提交多次。订单表给 order_no 建唯一索引后，第二次插入会抛 Duplicate entry，源码会在捕获异常后把已有订单号返回出去。

try { Db::name('pay_order')->insert($orderData); } catch (\Throwable $e) { if (strpos($e->getMessage(), 'Duplicate entry') !== false) { return $existingOrder['order_no']; } throw $e; }

第二个是退款，退款接口启动前必须检查订单状态，只有 status 为1的已支付订单才能进入退款流程。退款发起成功后立即把状态改成2退款中，通道退款成功回调后改为4已退款。这个状态机的好处是，同一笔订单发起两次退款，第二次进来看到状态不是1，直接拒绝。

第三个是通知，商户通知要记录 already_notified 标记，异步或定时任务同步了订单状态后不能无限通知。源码通常维护一个 notify_queue 表，只有触发状态机变更的那一次流程会往里写入任务。幂等不是靠某一行代码实现，而是靠状态机、唯一索引、条件更新三者叠加。

退款回调的验签和支付回调同样重要。有些源码在支付回调上做了一堆校验，到退款回调就只判断 result 字符串，这是最容易翻车的地方。伪造一条退款成功通知，就能把平台账本改乱。所以退款通知也要走 verify 入口，并且更新退款状态时加条件where status = 2，这样只有待退款订单能被推进到已退款。

6. 二次开发实战：给四方支付源码接入一个新的支付通道

6.1 定义通道类并实现统一接口

接入新通道时，先在 app/pay/strategy 目录新建一个类文件，比如 PlatformCChannel.php。真正要做的事情是把通道文档里的下单参数、验签规则、退款规则翻译成四个方法。

class PlatformCChannel implements PayChannelInterface { public function pay(array $params): array { // 调用通道下单接口，返回二维码字符串 return ['qr_code' => $this->request($params)]; } public function verify(array $data): bool { // 按通道要求排序、拼接、比较签名 return true; } public function refund(array $params): bool { // 调用通道退款接口 return true; } public function query(string $tradeNo): array { // 查询订单真实状态 return ['status' => 1]; } }

6.2 注册通道并完成配置

在 ChannelFactory 的 $channels 数组加一行，然后往 pay_channel 表插入渠道数据。两步缺一不可，代码注册负责让接口层能调用到，数据库配置负责让管理后台展示和开关。

6.3 回归验证与我的一个小习惯

通道接好后，我会按“下单→二维码→沙箱支付→异步回调→定时查单→退款”的顺序走完整流程。每走一步核对一次订单状态和金额，确认没有丢单、没有重复通知。从那以后我每次改支付相关代码，都强制走一遍这套模拟流程，再核对数据库里的金额与状态，线上才会稳。这套源码的二次开发价值也恰好在这里：看懂它的分层和状态机之后，新增通道从“改业务代码”降级成“加一个策略类”，希望帮到你。

本文还有配套的精品资源，点击获取