企业官网建设流程全解析

简介：一套基于PHP的淘宝天猫代付系统完整资源包，面向具备一定后端基础、希望实现电商平台代付功能的开发者。内容围绕系统原理、OAuth2.0授权、订单获取、代付请求与支付回调等核心环节展开，并涵盖技术栈选型、安全加密、防SQL注入与XSS、API签名验证等关键要点。包内共2000个文件，以JS、HTML、CSS等前端资源为主，另有Markdown说明文档与JSON配置文件，整体约75.19MB，便于按功能模块查阅。已有256人学习下载，适合用于学习代付业务流程设计、接口开发思路及电商系统安全加固实践。通过源码与配套说明，可掌握从需求分析、数据库设计到接口编写、上线维护的完整开发流程，并参考其中的异常处理与性能优化方案。

1. PHP 代付系统是做什么的：订单与支付之间那段空档

标题里的 PHP 代付系统，解决的是一个很具体的业务空档：订单在电商平台已生成，但下单人账户受限、支付工具不在手边，或者本来是替别人下的单，需要另一个人完成付款。系统要做的，是在这段空档上搭一座桥——读取订单、生成代付记录、让代付人支付、回调确认后同步订单状态。

常见落地场景有三类：给家人代付、客服替电话下单客户付款、企业采购由财务统一支付。适合正在做电商周边系统的 PHP 开发者，或者接到“做个代付”需求、纠结直接用平台功能还是自建的同学。现成功能快，但接不进自己的订单体系、做不了审批流时，自建反而省事。下面按实际做过的方案，把流程、数据模型、回调处理和踩过的坑串一遍。

2. 代付系统的核心流程与状态设计：先定链路和数据模型，再写代码

很多第一次做代付的同学，上来就写“生成支付链接”的接口，结果做到回调那一步发现状态根本没法收敛。代付系统和普通支付系统最大的差别在于：它同时要维护“电商平台订单”和“支付渠道订单”两个视角的状态，两个视角之间靠回调和对账同步。所以我的习惯是先定链路和数据模型，把状态流转画清楚，再动代码。

2.1 两种发起链路怎么选：平台侧代付与自建支付渠道

接到需求先回答一个问题：代付人付款时，页面是在电商平台内，还是在我们自己的系统里？这个问题直接决定接入方式，也决定后续要承担多少风控压力。

如果代付场景发生在电商平台内部，比如买家发起“请人代付”，优先用平台官方能力，我们的系统只做两件事：监听订单待支付事件、把平台订单号和代付人关系记下来，等平台自己回调结果。只有当付款动作必须发生在自己系统里，比如客服代付、财务批量付款，才需要自建支付渠道，这也是本章和下一章主要讲的路径。

自建路径的完整流程是：下单人在平台下单 → 我们的系统监听到待支付订单 → 创建代付记录 → 组装支付参数生成付款链接或二维码 → 代付人完成支付 → 支付渠道异步回调 → 更新代付记录 → 调用平台接口确认订单已支付。这里面最容易做错的是最后两步的顺序：必须先更新本地代付记录，再通知平台，通知失败要有重试，不能向平台报成功但本地没落账。

2.2 数据模型：一张 pay_order 表与一张回调日志表

代付记录至少要能回答三个问题：谁下的单、谁付的款、现在到哪一步了。我常用的表结构如下，按 MySQL 语法写的，换其他数据库把反引号去掉即可。

-- 代付订单表：一条记录对应一笔平台订单的一次代付 CREATE TABLE pay_order ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, platform_order_no VARCHAR(64) NOT NULL COMMENT '电商平台订单号', channel_order_no VARCHAR(64) NOT NULL COMMENT '支付渠道订单号，创建支付时生成', buyer_user_id BIGINT NOT NULL COMMENT '下单人ID', payer_user_id BIGINT NOT NULL COMMENT '代付人ID', amount_cents INT NOT NULL COMMENT '金额，单位分', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待支付 2已支付 3已确认 4已退款 5已关闭', paid_at DATETIME DEFAULT NULL COMMENT '渠道回调确认的支付时间', callback_cnt INT NOT NULL DEFAULT 0 COMMENT '累计回调次数', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_platform (platform_order_no), UNIQUE KEY uk_channel (channel_order_no), KEY idx_status_time (status, created_at) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

几个刻意的设计说明：金额字段直接叫 amount_cents，单位是分，从命名上杜绝“这里传元那里传分”的混用；platform_order_no 加了唯一约束，防止平台事件重复推送时建出多张代付单；channel_order_no 也有唯一约束，它是支付渠道侧的唯一键，回调幂等要靠它。callback_cnt 平时不显眼，出问题时看它就能判断“回调是不是重复来了很多次”，比翻渠道后台日志快得多。

状态流转需要单独说明，我把它收敛成一条不允许跳步的路径：

从 0 到 2 的跳转只允许发生在回调处理里，不允许用人工改库的方式“插队”。从 2 到 3 是异步任务推进的，失败会重试。这张表不加 status=1“支付中”，因为“用户正在扫码”这个状态在服务端不可见，加了反而让状态难以收敛。

提示：排障时把状态直接从 0 改成 3 看起来很省事，但会绕过金额核对和平台同步，强烈不建议。状态收敛靠代码不靠手。

回调原文单独建一张日志表，这是排查问题的后悔药：

CREATE TABLE pay_callback_log ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, channel_order_no VARCHAR(64) NOT NULL COMMENT '支付渠道订单号', raw_body MEDIUMTEXT NOT NULL COMMENT '回调原文，原样保存', sign_ok TINYINT NOT NULL DEFAULT 0 COMMENT '验签是否通过', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_channel (channel_order_no, created_at) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

回调处理里先写这张表再验签，保证任何一条回调都有案可查。线上排查时，我看到 raw_body 里 out_trade_no 对得上、但本地 pay_order 没更新，就知道问题出在自己的业务逻辑，而不是渠道侧没通知。

2.3 创建代付单的 PHP 实现：幂等检查与支付参数组装

代付单的创建入口，在自建路径下通常是平台订单事件回调或后台管理员的“代付”按钮。接口只接收平台订单号和代付人身份，金额必须从平台订单数据里读，不能相信前端传的金额。

public function createPayOrder(array $platformOrder, int $buyerUserId, int $payerUserId): array { // 金额统一转分，用 round 避免浮点误差 $amountCents = (int) round($platformOrder['total_amount'] * 100); // 幂等检查：同一平台订单只允许建一张代付单 $exists = PayOrder::where('platform_order_no', $platformOrder['order_no'])->first(); if ($exists) { throw new \RuntimeException('该订单已存在代付单，请勿重复创建'); } $channelOrderNo = $this->genChannelOrderNo($buyerUserId, $payerUserId); $payOrder = PayOrder::create([ 'platform_order_no' => $platformOrder['order_no'], 'channel_order_no' => $channelOrderNo, 'buyer_user_id' => $buyerUserId, 'payer_user_id' => $payerUserId, 'amount_cents' => $amountCents, 'status' => 0, ]); // 返回支付渠道参数，由调用方决定拼二维码还是拼跳转链接 return $this->buildPayParams($payOrder); }

这里的幂等检查在并发场景下不是绝对可靠，真正兜底的是上一节 pay_order 表上的 uk_platform 唯一索引。代码先查一次是为了给业务方一个清晰的“请勿重复创建”提示，而不是让他在数据库报错里猜原因。channel_order_no 我会用“渠道前缀 + 日期 + 下单人ID后四位 + 随机串”拼，保证同一渠道侧全局唯一。

从流程上还要接住平台侧的订单事件。常见做法是监听平台的下单通知，判断该订单是否有代付人，有则自动建单：

public function onPlatformOrderCreated(array $platformOrder): void { if ($platformOrder['status'] !== 'AWAIT_PAYMENT') { return; // 只有待支付订单才需要代付 } $payer = $this->getPayerForOrder($platformOrder); if (!$payer) { return; // 该订单没有指定代付人，走普通支付 } $this->createPayOrder($platformOrder, $platformOrder['buyer_id'], $payer); }

getPayerForOrder 里“谁来付”的规则因业务而异：亲友代付看平台下单时填的代付人字段，客服代付看客服与客户的绑定关系，财务代付走审批流。规则可以不同，但一定要收敛到这一个方法里，不要散落在各控制器。

3. 对接支付渠道与回调处理：验签、幂等、状态机一次说清

代付系统在渠道对接这个环节最容易翻车。支付渠道的参数组装规则、签名算法、回调通知策略各不相同，但踩过的坑高度相似：签名串顺序不对、编码不一致、回调重复、金额对不上。这一章按“先组装参数、再接收回调、最后处理业务”的顺序，把每一步的关键点拆开。

3.1 组装支付参数与签名：排序、编码、密钥拼接缺一不可

不管接哪家渠道，支付参数组装都有一个固定套路：拿官方文档的字段名，填上业务数据，按规则签名。下面是组装参数的示例，渠道配置放在 config 里，按环境区分测试与正式参数。

private function buildPayParams(PayOrder $payOrder): array { $config = $this->channelConfig; $params = [ 'app_id' => $config['app_id'], 'out_trade_no' => $payOrder->channel_order_no, // 渠道侧订单号 'total_fee' => $payOrder->amount_cents, // 单位：分 'subject' => '订单代付-' . $payOrder->platform_order_no, 'payer_id' => $payOrder->payer_user_id, // 代付人标识，渠道风控用 'notify_url' => $config['notify_url'], // 异步回调地址 'timestamp' => date('YmdHis'), ]; $params['sign'] = $this->sign($params); return $params; // 调用方按渠道要求拼成二维码内容或表单HTML }

签名函数的正确性直接决定支付能不能走下去，这里给出我常用的 MD5 带密钥实现：

private function sign(array $params): string { unset($params['sign']); // 签名本身不参与签名 // 去掉空值和 null，渠道侧通常要求空值不参与签名 $params = array_filter($params, fn($v) => $v !== '' && $v !== null); ksort($params); // 按键名字典序升序排列 // 手动拼 k=v 并用 & 连接，避免 http_build_query 对空格编码的差异 $str = ''; foreach ($params as $k => $v) { $str .= $k . '=' . $v . '&'; } $str = rtrim($str, '&'); return strtoupper(md5($str . '&key=' . $this->channelConfig['secret'])); }

三点经验：第一，排序必须用 ksort 升序，渠道侧也是这么算的，顺序错了验签必失败。第二，不要用 http_build_query 拼签名串，它对空格和特殊字符的编码规则与渠道侧可能有出入，最稳妥的是手动拼原始字符串。第三，如果渠道用非对称签名，变化点只在最后一步换成私钥签名，前面的参数排序和拼接规则完全一样，排查思路可以复用。

3.2 回调接收与验签：先落库留底，再验签，最后动业务数据

回调接口的设计原则是：任何一次回调，不管真假，先把原文存下来；验签失败的返回失败响应，让渠道按策略重试；验签通过但业务处理失败的同样返回失败。只有全部处理成功才返回渠道约定的成功回执。

public function notify(Request $request): Response { $body = $request->getContent(); $data = json_decode($body, true) ?? $_POST; // 按渠道要求的格式解析 // 第一步：原文留底，验签状态先记为失败 PayCallbackLog::create([ 'channel_order_no' => $data['out_trade_no'] ?? '', 'raw_body' => $body, 'sign_ok' => 0, ]); // 第二步：验签，不通过直接返回失败 if (!$this->verifySign($data)) { return $this->fail('签名验证失败'); } // 第三步：补记验签通过，再进业务处理 PayCallbackLog::where('channel_order_no', $data['out_trade_no'] ?? '') ->latest()->first()->update(['sign_ok' => 1]); try { DB::transaction(function () use ($data) { $this->handlePaid($data); }); } catch (\Throwable $e) { \Log::error('代付回调处理失败', [ 'channelOrderNo' => $data['out_trade_no'] ?? '', 'error' => $e->getMessage(), ]); return $this->fail('业务处理失败'); } return $this->success(); // 按渠道要求返回，常见是纯文本 SUCCESS }

三个细节值得注意。原文留底必须在验签之前，因为验签失败的报文往往是最难找的排查材料。业务处理包在事务里，异常时整个回滚，对渠道返回失败，让它重试——这正是幂等必须存在的原因。成功回执的格式必须按渠道要求，有的渠道认纯文本 SUCCESS，有的认 JSON 格式，格式错了渠道会一直重试。

注意：成功回执的格式以渠道文档为准，不要自己发明；格式不对时渠道会判定通知失败并持续重试，相当于帮自己制造重复回调。

3.3 业务处理与幂等：回调可以重，金额错一分都不行

handlePaid 是代付系统的核心方法，负责把“渠道已支付”翻译成“本地已支付、平台订单已确认”。它的第一要务不是更新状态，而是判断这笔回调是不是已经处理过了。

private function handlePaid(array $data): void { $channelOrderNo = $data['out_trade_no']; $paidAmount = (int) $data['total_fee']; // 渠道返回金额，强转分单位 // 行锁读取，同一订单的并发回调串行化 $payOrder = PayOrder::where('channel_order_no', $channelOrderNo) ->lockForUpdate()->first(); if (!$payOrder) { throw new \RuntimeException('代付单不存在: ' . $channelOrderNo); } if ($payOrder->status >= 2) { return; // 已支付或已确认，直接幂等返回成功 } if ($paidAmount !== $payOrder->amount_cents) { throw new \RuntimeException('金额不一致，拒绝入账: ' . $channelOrderNo); } $payOrder->status = 2; $payOrder->paid_at = date('Y-m-d H:i:s'); $payOrder->save(); // 同步平台订单状态，失败抛异常让回调重试，成功后再发通知 $this->syncPlatformOrderPaid($payOrder); $this->notifyUsersAsync($payOrder); // 队列异步，不进当前事务 }

金额校验这行不能省，它的意义不是防渠道出错，而是防回调报文里的金额被篡改或拿到别单的金额。回调报文本身有签名保护，验签通过后基本可以信任，但“信任签名”和“核对金额”是两件事，后者是对账的底线。同步平台订单状态时要注意：平台侧接口也要支持幂等，否则回调重试时会重复通知平台。我的做法是在平台侧同步记录里加 platform_sync_status 和 last_sync_at，每次同步前判断上一次是否已成功。

4. 代付系统避坑指南：五个踩过的坑与排查路径

流程能跑通只算完成三分之一，线上问题才是这系统的真正考验。下面五条都是我在代付这类场景里实际遇到并修过的，按现象、原因、解决三条线写，方便对照排查。

4.1 重复回调导致重复同步订单

现象：同一笔代付单在几秒内收到两次回调，平台侧订单状态被同步了两次，第二次把第一次已推进的“已发货”状态覆盖回“已支付”。

原因：支付渠道的通知机制本身带重试策略，第一次返回成功回执格式不对、或处理时抛了异常但没扣住，都会触发重发。业务代码里如果只判断“金额对就更新”，就会重复同步。

解决：handlePaid 里用 status >= 2 做幂等拦截，处理过直接返回成功；同步平台订单状态的接口也做幂等，用 platform_sync_status 判断是否已同步；最后靠 pay_order 表的 uk_channel 唯一索引兜底，防止极端并发下插入重复记录。

4.2 金额单位混用：分和元在接口之间打架

现象：月底对账总有几笔差一分钱，反复核对发现渠道侧记录和本地记录对不上。

原因：商品金额在库里有的是元、有的是分，某处写的是 intval($yuan * 100)，浮点计算 0.29 * 100 得到 28.999 直接被截成 28 分。

解决：所有金额字段统一用分并带 _cents 后缀命名；元转分必须用 (int) round($yuan * 100)；渠道回调里的金额同样按分解析并强转。命名上带单位后缀这个习惯，能在一开始就杜绝大部分混用。

4.3 越权代付：换了个参数就能替别人付

现象：有用户发现改一下请求里的关联人标识，就能生成一笔不属于自己的订单的支付链接，还能顺带看到订单明细。

原因：创建代付单接口完全信任前端传来的用户标识，服务端没有校验当前登录用户与订单的关系，也没有校验代付人是否被允许付这单。

解决：下单人身份从登录态取，前端传的只当参考；代付人必须存在于订单关联关系里，比如亲友关系、客服绑定关系、审批通过的财务单，查不到就拒绝；涉及用户标识的接口加频控，防止被遍历批量探测。

4.4 代付被风控拦截：付了钱订单却被冻结

现象：代付人扫码付款显示扣款成功，但平台订单一直停在待支付，过一会儿变成支付异常，钱在渠道侧被冻结。

原因：支付人与下单人的账户、设备、常用地区毫无关联，被渠道风控判定为异常代付；或者同一个代付人短时间为大量陌生订单付款，触发了批量代付的限制。

解决：平台内能走官方代付能力就走官方，让平台自己处理关系校验；自建渠道时，在支付参数的备注或扩展字段里写明代付人与下单人的关系，给风控侧提供判断依据；控制同一代付人单日笔数和金额，超阈值转人工审核。

4.5 回调丢了：用户说付了钱，系统没动静

现象：用户截图付款成功，客服后台看订单还是待支付，等了一天也没更新。

原因：notify_url 被内网防火墙拦了；渠道侧通知失败次数超限停止重试；更隐蔽的原因是业务处理抛异常但代码里 catch 后返回了成功回执，渠道以为已处理，不再重发。

解决：回调处理坚持“成功才回成功”，异常一律返回失败；同时写定时任务主动查单兜底，每 5 分钟把“渠道已支付但本地还是待支付”的订单拉回来：

*/5 * * * * php /data/www/paytool/bin/query_channel_order.php >> /data/www/paytool/logs/query.log 2>&1

查单脚本的逻辑和 handlePaid 共用同一套入账方法，只是数据来源从“回调报文”变成“渠道查单接口的返回”。这样即使回调全丢，也能在下一个周期内自愈，不会让用户干等。

5. 进阶：把代付封装成通用中间件，用模拟回调验证可靠性

流程跑通之后，我建议再做两件事：把渠道差异收敛成接口，把回调验证做成自动化。这两件事做完，这套代付系统才算真正可维护。

5.1 渠道差异收敛：四个方法定义一个支付渠道

代付核心逻辑里，只有“创建支付、验签、查单、退款”四个动作跟渠道强相关，把它们抽象成接口，后续每接一个新渠道就是实现四个方法：

interface PaymentChannelInterface { public function createOrder(PayOrder $payOrder): array; // 生成支付参数 public function verifySign(array $data): bool; // 回调验签 public function queryOrder(string $channelOrderNo): array; // 主动查单 public function refund(PayOrder $payOrder, int $amountCents): bool; // 退款 }

代付单的创建、回调入账、对账脚本都只依赖这个接口，不直接触碰某个渠道的签名细节。我每次接新渠道的做法是：先写实现类，再写模拟回调脚本，最后才联调真实渠道。

5.2 用模拟回调脚本验证整条链路的幂等与金额校验

模拟回调脚本是验证可靠性的关键工具。用你自己代码里的签名函数生成一份合法回调，往本地回调接口打，连续执行两次，验证第二次不会重复入账：

// mock_notify.php 用法：php mock_notify.php <channelOrderNo> <amountCents> $params = [ 'out_trade_no' => $argv[1], 'total_fee' => (int) $argv[2], 'status' => 'SUCCESS', ]; $params['sign'] = (new LocalChannel())->sign($params); $ch = curl_init('http://127.0.0.1:8080/notify'); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($params)); curl_setopt($ch, CURLOPT_HTTPHEADER, ['Content-Type: application/json']); curl_exec($ch); curl_close($ch);

提示：模拟脚本只能覆盖你自己的处理逻辑，渠道侧的签名算法和字段格式要以真实联调结果为准。

跑通过这个脚本，再叠加两个并发进程同时回调同一个订单号，确认只有一次入账，回调这部分就可以放心交给渠道了。这套做法帮我避开过不少线上事故：验签没过、幂等失效、金额搞错单位，都能在本地先暴露，而不是等到用户来投诉。我现在的习惯是，接任何支付渠道第一件事就是写模拟回调和查单脚本，再写业务代码，线上出问题时也优先查回调日志而不是靠猜。这套流程让代付这类系统少了很多玄学，希望帮到你。

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