简介这套第三方API代付系统源码主要面向需要快速接入微信、支付宝、QQ三大主流代付通道的个人开发者与企业运营者解决API接口易失效、资金划拨成本高、汇款管理繁琐等问题。系统后台地址为/admin默认账号admin密码123456部署后即可登录使用。包内共2005个文件以PHP业务逻辑代码、JS交互脚本、CSS样式与SVG图标为主同时包含PNG图片、HTML页面、TTF字体、SQL数据库备份及PEM证书等压缩包大小47.33MB目录结构完整适合二次开发与本地调试。目前已有186人学习下载。功能上支持余额充值接口集成易支付、微付、码支付及官方通道可自定义手续费承担方开启汇款邮件通知设置最低最高汇款金额并内置密码错误次数限制、同账户频繁汇款限制、充值延迟到账等安全机制。代付成功率99%以上每笔出款均有详细列表与统计帮助用户清晰掌握资金流向。1. 代付不等于转账先把三方API代付系统的边界划清楚业务跑到一定量你会发现“给用户打钱”比“收用户的钱”麻烦得多。退款、佣金结算、报销打款、活动奖励每一笔都走人工网银操作财务一天几百笔点下来不是抄错卡号就是漏单月底对账恨不得把Excel摔了。第三方API代付系统解决的就是这个场景通过QQ、微信、支付宝三个渠道的开放接口把“付款”这个动作从人工操作变成程序自动调用。标题里的“余额充值接口”和“易支付”值得先拆开。余额充值接口指的是系统内部的资金账户体系——用户或商户先在平台充值获得可用余额代付时从余额扣减而不是每次实时走网银易支付则是一类聚合支付平台常见做法是用它来做充值的收单入口用户在易支付下单、完成付款平台收到回调后给账户加余额。整个链路串起来就是易支付收钱进余额三方API把钱付出去。这套系统的核心难点不在“调通一个接口”而在“三个渠道的行为差异怎么抹平”“余额账怎么记才平”“失败和重试怎么不重复扣钱”。本文按我自己的实现思路从架构抽象、渠道接入、余额账务、易支付对接一直讲到幂等和状态机每段都有能直接落地的代码和参数。2. 渠道差异与统一抽象层设计先分清QQ、微信、支付宝代付的根本区别2.1 三个渠道的代付产品形态差别做聚合代付第一件事是忘掉“都是给用户打钱”这个直觉。QQ钱包付款、微信商家转账、支付宝批量代付三个产品在接口形态、到账速度、限额、手续费上完全是三套逻辑。对比项支付宝批量付款微信商家转账到零钱QQ钱包付款到QQ接口名称alipay.fund.trans.uni.transfer商家转账v2/v3qqpay.cashier_pay入参核心字段out_biz_no、payee_info、amountout_bill_no、openid、transfer_amount付款单号、收款QQ号、金额收款人标识支付宝账号email/手机或openid用户openid需AppID绑定QQ号本身到账时效实时到账一般几分钟实时部分触发风控实时手续费按笔或按比例可谈按笔有行业费率按笔沙箱环境有完整沙箱无线上沙箱仅测试商户号有测试商户号从这张表能看出一个关键问题微信代付必须拿到用户的openid而openid是和公众号/小程序AppID绑定的QQ代付只需要QQ号支付宝既可以用账号也可以用openid。这意味着你的系统在业务层面就得提前规划——“用什么标识唯一确定一个收款人”这个字段在三个渠道里不是同一个东西。2.2 统一接口抽象用一套内部API包住三种渠道我一般会在系统里定义一个PaymentChannel接口所有渠道都实现这套内部方法。对外暴露的只有四个动作pay()发起代付、query()查单、callback()处理异步通知、refund()退回如果有这个能力。?php interface PaymentChannelInterface { // 发起代付$order为内部代付单$config为渠道配置 public function pay(array $order, array $config): array; // 主动查单返回统一状态结构 public function query(string $channelTransNo, array $config): array; // 处理渠道异步回调解析并验签返回内部订单号 public function callback(array $request): array; }以支付宝实现为例pay()内部就是组装并调用alipay.fund.trans.uni.transfer这个API。public function pay(array $order, array $config): array { $bizContent [ out_biz_no $order[order_no], trans_amount $this-fenToYuan($order[amount]), product_code TRANS_ACCOUNT_NO_PWD, biz_scene $order[scene] ?? DIRECT_TRANSFER, payee_info [ identity $order[payee_id], identity_type $order[payee_type], // USER_ID / ALIPAY_LOGON_ID name $order[payee_name] ?? , ], ]; // 调用支付宝SDK下单 $response AlipayClient::execute( alipay.fund.trans.uni.transfer, $bizContent, $config ); if ($response[code] 10000) { return [ status PENDING, channel_txn_no $response[order_id], raw $response, ]; } // 业务失败区分可重试与不可重试 return [ status FAILED, code $response[sub_code] ?? , message $response[sub_msg] ?? , ]; }这段代码有几个参数需要说明。out_biz_no是调用方生成的唯一单号支付宝用它做幂等——同一个单号重复请求不会重复打款trans_amount是字符串类型的元为单位金额很多财务系统习惯用分存储这里必须转换否则传成整数会收到金额无效的报错identity_type字段的值ALIPAY_LOGON_ID表示收款方是支付宝登录账号邮箱或手机号USER_ID表示支付宝用户IDopenid选错类型会直接抛PAYEE_NOT_EXIST。PENDING返回并不代表钱一定出去了。支付宝这类代付接口很多时候是异步结果代付单最终状态要等异步通知或主动查询来刷新。所以实现层里我在收到code 10000时先记成PENDING再由后续的查单或回调推进状态。2.3 状态机设计代付单不是“成功/失败”两个状态这是系统能不能扛住线上压力的分水岭。代付单的常见做法是用五个状态跑一个有限状态机状态含义可转移至INIT已创建未提交渠道PROCESSING / FAILEDPROCESSING已提交渠道结果未知SUCCESS / FAILED / CLOSEDSUCCESS渠道确认成功终态FAILED渠道明确失败INIT重试时新建单CLOSED超时或人工关闭终态注意一个细节重试不是把FAILED的单改回INIT而是用新的order_no重新发起一笔代付原单保持FAILED存档。这样对账时每一笔资金流向都有一条独立且不可变的状态路径而不是在同一个单号上反复横跳出了纠纷讲不清楚。提示微信、支付宝对同一笔“业务单号”的幂等控制只保证该单号本身不被重复执行。如果你在原单上重置状态再次提交部分渠道的幂等键已经失效可能出现两笔真实打款。3. 余额账户与入账出账设计钱从哪里来、到哪里去、怎么对平3.1 账户模型一分钱都不能多出来的账务设计余额充值接口解决的是“平台内资金池”的问题。每个用户/商户在系统里有一个余额账户代付从余额扣钱易支付回调后往余额加钱。账户表的核心字段必须有user_id、balance可用余额、frozen冻结余额、version乐观锁版本号。只靠balance字段做加减并发一上来必出脏账。-- 账户核心表只保留当前余额 CREATE TABLE user_account ( user_id BIGINT UNSIGNED NOT NULL COMMENT 用户ID, balance BIGINT NOT NULL DEFAULT 0 COMMENT 可用余额单位分, frozen BIGINT NOT NULL DEFAULT 0 COMMENT 冻结余额单位分, version INT UNSIGNED NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, PRIMARY KEY (user_id) ) ENGINEInnoDB COMMENT用户资金账户; -- 资金流水表每一笔变动都留痕 CREATE TABLE account_flow ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, user_id BIGINT UNSIGNED NOT NULL, change_type TINYINT NOT NULL COMMENT 1充值 2代付 3退款 4冻结 5解冻, change_amount BIGINT NOT NULL COMMENT 变动金额正负表示, balance_after BIGINT NOT NULL COMMENT 变动后余额, order_no VARCHAR(64) NOT NULL COMMENT 关联单号, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_order_type (order_no, change_type) ) ENGINEInnoDB COMMENT资金流水;这里最容易被忽略的是account_flow表上的唯一索引uk_order_type。它的作用是保证同一笔业务单号只能产生一种类型的流水同一笔订单不可能既记一次充值又记一次充值这就把重复入账挡在了数据库层。代码里哪怕回调逻辑有bug并发多次插入同单号也会撞唯一键直接抛异常而不是悄悄加两次钱。3.2 代付扣款与防超扣乐观锁事务发起代付时扣减余额和写流水必须在一个数据库事务里完成并且用乐观锁防止超扣。经典的实现是条件更新的写法// 尝试扣减余额返回受影响行数 $sql UPDATE user_account SET balance balance - :amount, frozen frozen :amount, version version 1 WHERE user_id :user_id AND balance :amount AND version :version; $affect $db-execute($sql, [ :amount $order[amount], // 单位分 :user_id $order[user_id], :version $account[version], ]); if ($affect 0) { throw new \Exception(余额不足或账户version冲突); }注意这里我先把要付的金额从balance挪到frozen而不是一次性扣光。原因是代付提交渠道之后状态是PENDING最终可能成功也可能失败。钱先进冻结区等渠道回调确认成功后再从frozen真正扣减如果渠道返回失败再从frozen解冻回balance。这样做账户余额永远只代表“真实可用”的钱不会出现账面有余额但钱全在途付不出去的情况。version :version的乐观锁是关键。并发请求同时读到同一版本号时只有一个UPDATE能匹配到version另一个受影响行数为0抛异常走重试或提示用户。在高并发下这比SELECT ... FOR UPDATE行锁更轻量而且不会因为事务持有锁时间过长拖垮数据库。3.3 易支付充值进余额回调验签与入账时序易支付这类平台的对接模式大同小异用户在易支付下单支付易支付跳转同步页不信任同时服务器端发送异步通知要验签业务侧只认异步通知才入账。易支付的异步通知参数里通常包含pid商户ID、trade_no易支付单号、out_trade_no你自己的单号、type支付方式、money金额、trade_statusTRADE_SUCCESS、sign签名。签名一般是MD5把除sign外的参数按key排序拼接后加上商户密钥做MD5再比较。$params $_GET; // 或$_POST以实际通知方式为准 $sign $params[sign]; unset($params[sign], $params[sign_type]); ksort($params); $signStr urldecode(http_build_query($params)) . $merchantKey; if (md5($signStr) ! $sign) { http_response_code(400); exit(sign error); } // 验签通过检查订单状态与金额 if ($params[trade_status] TRADE_SUCCESS) { // 幂等入账以out_trade_no为唯一键重复通知不重复加钱 $affect $db-execute( INSERT INTO account_flow (user_id, change_type, change_amount, order_no) VALUES (:uid, 1, :amount, :order_no) ON DUPLICATE KEY UPDATE id id, [...] ); }这段代码里的ON DUPLICATE KEY UPDATE id id是妙用配合uk_order_type唯一索引实现“重复通知不重复入账”的幂等效果。第一次插入成功第二次撞唯一键后只做一个无操作更新不影响余额。验签用的$merchantKey是易支付商户后台的那串密钥跟MD5配合时要注意urlencode的坑参数拼接前不要提前decode否则明文和签名时的原文不一致会导致验签失败。这是新手最容易踩的地方。4. 余额充值接口与易支付集成从下单到回调入账的全链路代码4.1 充值下单接口生成订单号并跳转易支付充值接口的入参一般是user_id和amount最基础的做法是后台生成一笔充值单然后构造易支付的支付链接让前端跳转。// 生成充值单 $rechargeNo R . date(YmdHis) . mt_rand(1000, 9999); $db-execute( INSERT INTO recharge_order (recharge_no, user_id, amount, status) VALUES (:no, :uid, :amount, PENDING), [...] ); // 构造易支付请求参数 $params [ pid $merchantId, type alipay, // 或wxpay、qqpay out_trade_no $rechargeNo, notify_url https://pay.example.com/notify/easy, return_url https://example.com/ucenter/recharge/return, name 余额充值, money number_format($amountYuan, 2, ., ), sign , ]; ksort($params); $params[sign] md5(urldecode(http_build_query($params)) . $merchantKey); $payUrl https://pay.easy.com/submit.php? . http_build_query($params); header(Location: . $payUrl);type参数决定用户看到哪个渠道的支付二维码常用值有alipay、wxpay、qqpay对应支付宝、微信、QQ钱包。money必须保留两位小数0.00这种格式是易支付的硬校验传整数会报金额格式错误。notify_url是异步通知地址return_url是同步跳转地址后者只是给用户看的页面真正的入账动作只认notify_url的回调。4.2 异步通知处理状态推进和入账顺序易支付的异步通知走notify_url业务侧处理顺序是验签 → 检查out_trade_no对应的充值单是否存在且为PENDING→ 校验money和下单金额一致 → 更新充值单状态 → 插入资金流水并增加余额 → 返回success给易支付。这里有一个顺序必须守死先更新订单状态再入账。如果先入账再更新订单入账成功后进程崩溃充值单还是PENDING状态易支付重发通知时你又入了一次账。// 在事务里执行 $db-beginTransaction(); try { // 1. 更新充值单状态只有PENDING才能变为SUCCESS $affect $db-execute( UPDATE recharge_order SET status SUCCESS, paid_at NOW() WHERE recharge_no :no AND status PENDING ); if ($affect 0) { // 已经处理过直接返回success不重复入账 $db-commit(); echo success; return; } // 2. 给用户加余额 $db-execute( UPDATE user_account SET balance balance :amount, version version 1 WHERE user_id :uid ); // 3. 写流水 $db-execute( INSERT INTO account_flow (user_id, change_type, change_amount, balance_after, order_no) VALUES (:uid, 1, :amount, (SELECT balance FROM user_account WHERE user_id :uid2), :no) ); $db-commit(); echo success; } catch (\Exception $e) { $db-rollBack(); http_response_code(500); echo error; }代码里的UPDATE recharge_order ... WHERE status PENDING是另一种幂等防护。即使前面验签通过如果充值单已经被处理过状态不再是PENDING这个更新影响行数为0直接返回success不会二次加钱。这就是状态机“只允许PENDING到SUCCESS”的约束在SQL层面的落地。4.3 三方代付对账每天拉渠道账单比对流水无论代码写得再小心线上跑几个月也难免出现渠道侧扣款成功但平台没收到回调的单子。解决这个问题的常见做法是每日对账从支付宝、微信、QQ钱包下载前一天的交易账单跟平台的代付订单表做匹配重点找出“平台标记失败但渠道扣款成功”和“渠道成功但平台无此单”两类数据。对账单状态平台状态处理动作成功成功正常不处理成功失败/不存在人工介入补单或退款记录异常单失败成功向渠道发起原路退回若有此能力不存在成功查平台原始请求日志确认是否漏发渠道-- 以支付宝为例找出渠道成功但平台状态不是SUCCESS的代付单 SELECT od.order_no, od.amount, od.status FROM pay_order od LEFT JOIN alipay_statement st ON st.out_biz_no od.order_no WHERE st.status SUCCESS AND od.status ! SUCCESS AND st.trans_date 2025-01-15;提示对账任务建议放到凌晨低峰执行用脚本扫描后生成差异报表发到企业微信或钉钉群。差异单当天处理不要累积到月底否则人工核对的成本会失控。5. 代付系统的4个常见坑与一个验证技巧5.1 金额精度陷阱分与元的单位混用代付接口和易支付的金额单位完全不同支付宝代付用“元”且是字符串易支付用“元”且保留两位小数微信转账用“分”且是整数。如果内部统一用分存储调支付宝时忘了除以100用户会收到一笔比实际金额大100倍的打款这种事故非常致命。我的做法是在封装层强制写单元测试把“转元转分”做成独立函数单测覆盖边界值0.01、0.10、1.00、999999.99。5.2 密钥管理别把商户私钥写进代码仓库PHP项目最常见的是把支付宝应用私钥、易支付商户密钥直接写在config.php里然后提交到Git。仓库一旦泄露别人拿着你的私钥可以发起代付打光余额。至少要做的措施有密钥放环境变量或独立的.env文件并加入.gitignore线上环境用配置中心或密钥管理服务读取每次代付请求前检查IP白名单和商户状态。5.3 重试风暴回调处理必须幂等且快速返回易支付的异步通知在没收到success响应时会重发多次间隔从几分钟到几小时不等。如果业务侧因为慢查询导致响应超时易支付会一直重发反而把数据库拖垮。处理原则是验签失败立即返回error让平台继续重试业务重复单直接返回success告诉平台不用再发整个回调处理逻辑控制在200ms内完成超过就报警。5.4 验证技巧用沙箱环境做一次“异常的闭环演练”上线前别只测“正常回流”要测三件事第一模拟渠道成功回调后重复推送两次确认不为同一单加两次钱第二模拟代付提交后渠道返回UNKNOWN异常确认代付单停在PROCESSING状态而不是直接变成失败第三人为把账户余额改成刚好等于代付金额并发发起两笔代付确认只有一笔能扣款成功另一笔报余额不足。把这三条写成自动化测试脚本每次改代码后跑一遍。代付系统容不得“上线后再观察”资金安全靠的就是这些脏路径上的防守。本文还有配套的精品资源点击获取
