简介：这套USDT跑分支付系统源码集成了API监听、自动回调与三级分销逻辑，面向数字货币支付开发者、区块链技术研究者及有搭建支付平台需求的创业者，重点解决USDT交易状态实时同步与多级推广佣金分配问题。压缩包大小40.69MB，共2000个文件，包含609个js、148个php、174个html、165个css等前后端代码，以及sql数据库脚本、json配置文件、png/gif界面素材和md说明文档，目录划分较清晰，便于按模块学习。已有958人学习下载。源码覆盖数据库连接、API接口定义、安全防护、前端展示及分销层级计算等完整链路，可帮助读者理解异步回调机制、HTTP交互流程、分布式环境下的并发与事务处理；内容预览中的twig模板、layui/mui样式、transfer.ltr.css等也侧面反映出该项目的技术栈与典型Web支付架构。对希望深入区块链支付系统、掌握API回调设计或快速原型开发的开发者来说，这套源码提供了可参考的工程实例和二次开发基础。
1. 5000元的USDT跑分源码：值钱的是回调链路，不是那堆PHP文件
某站上挂5000元的那套“USDT跑分源码”，标题里其实塞了三样东西：一块负责监听入账的API监听模块，一套收到链上交易后自动回调商户的PHP接口，外加一个三级分销的佣金体系。第一眼觉得贵很正常，但做过支付中间件的人知道，真正值钱的不是那些能改颜色的后台页面，而是回调进来那一瞬间，系统怎么验签、怎么防重、怎么把分账算对。跑分支付系统的本质，是给商户和收款方之间加了一层自动撮合与记账的中间层，订单状态一旦错位，钱就会卡在链上或账上。这篇更适合已经在部署PHP项目、想评估这套源码技术含量的人读；读完你会清楚自己买回去该先看哪个文件、上线前要补哪几个坑。
2. 跑分系统的模型拆解：三方角色与订单状态机才是地基
标题里没有写角色模型，但拿到源码后第一件事应该是先梳理角色和订单状态，而不是急着配后台。很多人在这一步跳过去，后面所有排查都变成黑匣子乱猜。把资金路径和状态流转理清了，再看代码，哪里缺东西、哪里埋着雷基本一目了然。
2.1 商户、跑分人员、平台：三条资金路径谁在承担风险
一笔等待入账的订单从生成到回调完成，至少经过商户、跑分人员、平台三方。商户发起订单，提供商品或服务；跑分人员拿出自己的收款地址，等用户往里面打U；平台只做订单撮合和记账，不直接碰用户的转账动作。这样设计的好处是平台不需要持有大额资金池，缺点是把信任风险压到了跑分人员身上，他先垫资收款，后面再靠平台给他做余额结算。大多数跑分系统源码里，跑分人员并不是先充值后接单，而是先接单后收款，所以系统必须记录每一笔入账对谁生效。
资金路径可以拆成四步：用户下单后系统匹配一个可用的收款地址，用户往该地址转账，监听模块在链上看到这笔txid并确认金额，平台更新订单状态后调用商户的回调URL通知业务方发货。第4步做完，跑分人员余额增加，商户业务闭环，平台抽佣。任何一步断掉，都会出现“用户转了钱但商户说没收到”这类客诉。看源码的时候，重点不是看页面和接口多不多，而是看这四个环节分别落在哪些文件、异常分支是否齐全。
风险承担上，最容易翻车的是平台：如果监听模块把未确认到账的交易当作已到账去回调，商户发完货链上交易又被撤销，损失就要平台自己兜。所以后面所有确认数和幂等设计，本质都是在保护平台这层。这也是为什么值钱的源码会把确认数、状态机写在配置而不是写死在代码里。
2.2 订单状态机：从待支付到已结算的六个状态
拿到这类源码，第一件事先建数据库，然后打开订单表看status字段有多少种取值。正常的USDT支付订单，状态至少应该有下面这几种，我一般在设计时直接把它做成状态机：
| 状态值 | 含义 | 进入条件 | 后续动作 |
|---|---|---|---|
| 0 | 待支付 | 商户下单成功，等待链上入账 | 轮询/监听关注该地址 |
| 1 | 检测到入账，待确认 | 监听模块看到txid，金额匹配 | 等待区块确认数 |
| 2 | 已确认可回调 | 确认数达到阈值 | 自动回调商户URL |
| 3 | 回调成功 | 商户返回SUCCESS | 触发分销结算 |
| 4 | 已结算 | 佣金已入账，流水已落库 | 结束，可对账 |
| 5 | 超时关闭 | 超过订单有效期未收到足额U | 释放收款地址 |
这六个状态里，0到1的跃迁是监听模块干的，1到2是确认模块干的，2到3是回调服务干的，3到4是结算服务干的。每一跳都要有幂等保护。看源码时如果发现status字段只有“待支付”和“已支付”两种，那说明这份跑分源码把确认和结算全部挤到一段代码里了，商户回调一旦失败，整条订单就死在那，后续没有任何补救入口。
还要注意一个细节：订单要有expire_time。USDT跑分场景里，用户可能几十分钟才转账，也可能转错地址，如果订单永久有效，收款地址会被大量占用。成熟源码会在订单生成时设置15到30分钟的有效期，超时后状态置为5，等下一次有用户下单再复用这个地址。这个设计直接决定跑分人员的接单效率。
2.3 为什么状态流转必须落在数据库事务里，而不能靠内存标记
我见过有人图省事，用Redis的incr计数和命令行标记来记订单状态，并发一上来数据全乱。支付系统的状态流转必须落在MySQL事务里，核心原因是状态变更伴随着余额变更，而余额变更必须和状态变更在同一原子操作内完成。如果用先更新状态、再写流水这种两步操作，进程中途退出时，订单状态和账户余额就永远对不上了。
一个稳定的状态流转事务至少要做四件事：用select for update锁定订单行、比对当前状态是否等于预期状态、更新状态值和相关金额、插入一条流水记录。这里放一个最简单的订单确认逻辑：
// OrderController::confirm() public function confirm($orderNo, $amount, $txid) { $db = Db::name('orders'); // 开启事务 $db->startTrans(); try { // 1. 行锁锁定订单，防止并发重复处理 $order = $db->where('order_no', $orderNo)->lock(true)->find(); if (!$order || $order['status'] != ORDER_PENDING) { throw new \Exception('order status error'); } // 2. 更新订单为“已确认” $db->where('order_no', $orderNo)->update([ 'status' => ORDER_CONFIRMED, 'txid' => $txid, 'confirm_time' => time() ]); // 3. 写一条变更流水，后面对账全靠它 Db::name('order_log')->insert([ 'order_no' => $orderNo, 'action' => 'confirm', 'amount' => $amount, 'txid' => $txid, 'created_at' => date('Y-m-d H:i:s') ]); $db->commit(); } catch (\Throwable $e) { $db->rollback(); throw $e; } }这段代码的逻辑是：先锁行再读状态，状态不对直接抛异常回滚，状态对就更新并写流水，两个操作在同一个事务里完成，要么都成功要么都不成功。参数上要注意lock(true)在ThinkPHP里会生成for update语句，前提是订单表必须走主键或唯一索引查询，否则MySQL可能选择间隙锁甚至全表锁，大并发下直接锁死整个订单表。
另一个实际参数是事务隔离级别。这套系统的默认隔离级别通常是REPEATABLE READ，行锁配合唯一索引已经足够。不要为了省事改成READ COMMITTED之后又用Redis预减余额，两套并发控制叠加，反而制造更多不一致。状态机的每一次跃迁都应该能从流水表回溯，这也是后面做对账和数据修复的唯一依据。
3. API监听与自动回调：把钱包入账变成业务通知的关键100毫秒
标题里的“API监听”和“自动回调”是这套源码的核心卖点，也是5000元里最值钱的部分。它有两条链路：一条向外，定时或长连接去链上查询收款地址是否收到U；一条向内，收到入账后组织签名、把结果POST到商户的回调地址。两条链路都要处理“数据没到齐、到了两次、到了错的数据”这些脏场景。
3.1 监听USDT入账的三种方案：轮询区块浏览器、节点RPC、第三方监听API
常见做法是这三种，优缺点我直接列出来：
| 监听方案 | 延迟 | 部署成本 | 误报风险 | 适合场景 |
|---|---|---|---|---|
| 区块浏览器API轮询 | 5到30秒 | 极低，只需一个HTTP客户端 | 偶尔漏块或被限流 | 小额快速跑单 |
| 自建节点RPC | 1到3秒 | 高，需要同步区块数据 | 低，本地数据可控 | 大额、订单量集中的场景 |
| 第三方监听API | 1到10秒 | 中，要申请API Key并按次计费 | 依赖第三方可靠性 | 不想维护节点，愿意付接口费 |
区块浏览器API轮询是最常见的做法。定时任务每5秒拉取一批收款地址的最近交易，比对金额、收款地址和txid是否已在订单表中出现过。这个方案实现最快，但有两个明显短板：一是公共API会限流，跑分人员多的时候上百个地址同时轮询，很容易触发429，一旦被限流，后面的入账全部迟到；二是公共API可能因为节点同步延迟而漏掉刚被打包的交易，漏掉那几分钟的窗口，订单就可能走到超时关闭。
自建节点RPC从可靠性上讲最稳，但要部署完整节点服务并保持区块数据同步，几万个区块的数据量对服务器磁盘有要求。第三方监听API是折中，它帮你把“监控地址”这件事做成一个订阅接口，你提交地址，它异步通知你入账。用这种方案时记住一个原则：第三方只能帮你发现交易，不能替你做确认和回调，确认逻辑仍然要放在自己的服务里。
3.2 自动回调的签名验签与幂等处理：一段PHP实现
自动回调的入口通常是一个notify.php，收到POST后先验签再处理业务。签名机制是这类源码最基础的防伪造手段，常见做法是取所有非空参数，按参数名ASCII升序排列，拼接成key=value&的形式后追加密钥，再做一次MD5得到sign。商户端持有同样的密钥，就可以判断这个回调是不是平台发出的。
// notify.php 自动回调统一入口 class NotifyController { private $appSecret = '在后台为每个商户配置独立的密钥'; public function receive() { $params = $_POST; // 1. 验签：除sign外所有参数参与签名，按key排序 ksort($params); $signStr = ''; foreach ($params as $key => $value) { if ($key === 'sign' || $value === '') { continue; } $signStr .= $key . '=' . $value . '&'; } $signStr .= 'key=' . $this->appSecret; if (md5($signStr) !== ($params['sign'] ?? '')) { // 验签失败，返回失败标识，让平台重试 exit('sign_error'); } $orderNo = $params['order_no']; $amount = (string)$params['amount']; $txid = $params['txid']; // 2. 幂等处理：按订单号查当前状态，已回调成功则直接返回SUCCESS $order = Db::name('orders') ->where('order_no', $orderNo) ->lock(true) ->find(); if (!$order || $order['status'] != ORDER_PENDING) { exit('SUCCESS'); // 重复回调也认为是成功 } // 3. 金额比对：允许小数点后4位以内的精度误差，防止浮点比较翻车 if (abs((float)$amount - (float)$order['amount']) > 0.0001) { exit('amount_error'); } // 4. 更新订单为已确认，随后触发分销结算 $this->confirmOrder($orderNo, $amount, $txid); exit('SUCCESS'); } }逻辑说明：第一步的ksort非常重要，签名串的拼接顺序必须和商户端完全一致，少一个参数或排序方式不同都会导致验签失败；第二步用行锁查询订单，已回调成功的订单直接返回SUCCESS，这是幂等的第一道防线；第三步的金额比对用字符串转float再比较，不要直接用浮点等值判断，否则0.1加0.2这种问题会在线上定时炸给你看。第四步才真正变更业务数据。
参数说明里最需要关注的是appSecret的配置方式。成熟的源码不会全局只有一个密钥，而是每个商户独立生成，商户后台能看到自己的密钥。这样某个商户泄漏了密钥，不会波及其他商户的回调安全。回调处理完必须输出SUCCESS这个固定字符串，商户端只有收到SUCCESS才会停止重推；输出任何别的结果，商户系统都会按失败处理并再次推送，直到推了几次失败后进入人工处理队列。
3.3 防止重复入账的最后一公里：唯一约束加Redis锁
验签和状态判断能挡住大部分重复，但挡不住并发：同一笔交易，监听脚本刚确认完，回调服务又把状态改了，两边同时读到订单还是待支付，就可能出现两次入账。解决方法是数据库唯一约束加上Redis锁，双保险。数据库侧给订单流水表的order_no和txid联合字段建唯一索引，第一次插入成功，第二次插入直接报Duplicate entry。Redis侧在确认前用SET NX抢锁，抢不到锁说明另一个进程正在处理同一张订单。
// ConfirmService::execute() public function execute($orderNo, $txid, $amount) { // 1. Redis锁：key为订单号，TTL给8秒，足够完成后续事务 $lockKey = 'usdt:confirm:' . $orderNo; if (!Redis::set($lockKey, 1, ['nx', 'ex' => 8])) { // 拿不到锁说明已有进程在处理，直接幂等返回 return; } try { // 2. 这里执行上一节的状态机事务 $this->confirmInTransaction($orderNo, $txid, $amount); } finally { Redis::del($lockKey); } }这个锁的过期时间是个关键参数。8秒看起来随意，实际要按业务耗时计算：订单确认事务里包含更新订单、插入流水、可能还有异步分发事件，正常情况下50毫秒就跑完了。但订单量大时，数据库连接池排队可能让事务超过1秒，8秒的TTL给足了缓冲。TTL不能设太大也不能太小，太大会在其他进程崩溃时把锁占死，需要等TTL自然过期；太小的话，事务还没提交锁就消失了，另一个进程又进来处理，幂等就只剩数据库唯一索引在兜底。
要特别提醒的一点：Redis锁只是降低并发概率，不是数据正确性的兜底。真正的兜底永远是数据库的唯一索引。我见过不少源码把Redis锁当成唯一防线，Redis一旦持久化配置不当或主从切换丢锁，重复入账就发生了。排查的时候先看数据库有没有唯一约束，没有就补上，这比调任何参数都管用。
4. 三级分销分成：比例、事务与防刷这三个点怎么算清楚
标题里最后四个字“三级分销”，经常被当作一个列表页就实现了。但实际上三级分销才是最容易让商家亏钱的模块——比例设错、事务没包好、被跑分人员自刷，哪一条都会让佣金支出高于平台收入。这章讲清楚比例怎么定、结算怎么落库、刷单怎么挡。
4.1 三级分成的级距与比例：怎么设才不会被薅穿
三级分销的含义是：一个用户通过推广链接注册后，他带来的每一笔订单，他本人拿一级佣金，他的上级拿二级，上级的上级拿三级。大多数源码的默认值是固定的几个数字，比如一级3%、二级1.5%、三级0.5%合计不超过5%。但直接抄默认值是有风险的，因为跑分场景的订单金额通常不大，几十U到几百U，比例设得太高，平台抽佣还不够发佣金。
设计比例时要考虑两个参数：平台实际收的手续费率，以及平均订单金额。我通常这样定：一级佣金不超过平台手续费的50%，二级不超过一级的一半，三级不超过二级的一半。比如平台对商户收1%手续费，一级最多设0.5%，二级0.25%，三级0.12%，整体佣金支出被控制在手续费以内。反过来，如果平台不收手续费、靠汇率差赚钱，那佣金比例就要结合汇率差的真实毛利来算，不能凭感觉填。
还要考虑一个细节：三级分销的级距是递归往上翻的。一张订单100U，一级拿3U，二级拿1.5U，三级拿0.5U，如果1000个用户形成深度链条，每一层的真实结算金额是可观的。所以源码里比例必须存配置表，并允许后台动态调整，不能写死在代码里；调整后要生效于新订单，不能追溯历史订单，否则对账永远对不平。
4.2 分成结算的事务写法：一个订单只结算一次
分销结算最怕的就是“一笔订单被结算了两次”。跑分系统的订单状态有并发改动的可能，如果结算逻辑不是包在事务里的，订单状态和佣金流水就会分裂。我见过一份源码的结算逻辑写在回调成功后的一个普通函数里，订单状态更新成功但佣金写入失败时，整张订单状态变成已支付，佣金却丢了；跑分人员来问，还得靠人工补。
正确的写法是把“更新订单为已回调”和“写佣金流水”放进同一个事务，订单状态没变成功，佣金就不允许落库。推荐的做法：
// CommissionService::settle() public function settle($orderNo) { Db::startTrans(); try { // 1. 锁住订单行，并检查是否已经结算过 $order = Db::name('orders') ->where('order_no', $orderNo) ->lock(true) ->find(); if ($order['settle_status'] == 1) { Db::commit(); // 已结算，幂等返回 return; } // 2. 查出这个用户的推广链：pids 字段存三级上级uid $user = Db::name('users')->where('uid', $order['uid'])->find(); $pids = json_decode($user['pids'], true); // [一级uid, 二级uid, 三级uid] // 3. 按比例给三个上级加佣金，并写流水 $levels = [ ['uid' => $pids[0] ?? 0, 'rate' => 0.03], ['uid' => $pids[1] ?? 0, 'rate' => 0.015], ['uid' => $pids[2] ?? 0, 'rate' => 0.005], ]; foreach ($levels as $lv) { if ($lv['uid'] <= 0) continue; $amount = round($order['amount'] * $lv['rate'], 4); if ($amount <= 0) continue; Db::name('users')->where('uid', $lv['uid']) ->inc('balance', $amount) ->update(); Db::name('balance_log')->insert([ 'uid' => $lv['uid'], 'order_no'=> $orderNo, 'amount' => $amount, 'type' => 'commission_level_' . array_search($lv, $levels), 'created_at' => date('Y-m-d H:i:s') ]); } // 4. 标记订单已结算 Db::name('orders')->where('order_no', $orderNo) ->update(['settle_status' => 1]); Db::commit(); } catch (\Throwable $e) { Db::rollback(); throw $e; } }这段代码的重点有三个：订单行锁放在最前面，保证同一订单的结算不会并发执行；settle_status是最终幂等标志，不管这个函数被触发多少次，每次进去都会先查这个字段；每一步余额变更都写balance_log流水，后面跑分人员对账、平台审计都靠这条流水找证据。
参数上需要注意round($order['amount'] * $rate, 4)的精度处理。USDT按链上精度可以到小数点后6位，但业务一般只保留4位小数，多余部分宁可舍掉也不进位，原因是一笔订单的佣金如果四舍五入进位，一万笔订单多出来的金额会被“薅”走。很多源码在这里直接使用PHP的round默认模式，实际上应该显式传参指定舍入模式，比如PHP_ROUND_HALF_DOWN，保证每一笔都不超过理论值。
4.3 防自刷与防篡改：注册IP、绑定快照和提现审核
三级分销的天然漏洞就是自刷：跑分人员注册一个主号，再注册几个小号挂在主号下面，用小额订单把佣金刷出来。这个问题靠事务和唯一约束根本挡不住，因为是合法用户在使用合法流程。我见过的有效防线是三道：
第一道是注册环节的IP和设备限制。同一个IP在5分钟内最多注册2个账号，同一个设备指纹在一天内最多绑定1个下级。跑分人员要刷就得换IP换设备，成本抬高后自刷的动机会明显下降。
第二道是绑定快照。用户的推荐链在注册完成时就把pids字段写入并锁定，后续不允许修改。现在不少源码把上级绑定做成一个可修改的字段，注册后还能被下级自己改，这等于给刷单开了大门。正确的做法是pids只允许服务端在注册流程写入，用户端永远没有这个修改入口。
第三道是提现审核。佣金入账后不能直接提走，至少设置一个T+1或手动审核的缓冲期。即使有人刷了佣金，平台在审核时还能看到订单是否来自同一设备、同一IP段，直接驳回。当然这道防线需要后台有人工审核界面，单纯靠自动提现的系统是挡不住的，这点在看源码时要留意后台有没有提现审核模块。
5. 部署与调参避坑：这套源码跑通前的5个翻车现场
不管源码从哪个渠道拿回来，部署上遇到的问题大致都躲不开这五个坑。每个坑我都按“现象、原因、解决”三条写清楚，对应到代码可能出现在哪里，方便你拿回去直接对照排查。这些坑在支付类源码里几乎是共通的，不只是这一套，其他带回调的PHP支付系统也能用同一套思路查。
5.1 坑一：回调URL明明正确，订单却一直停在“待支付”
现象：监听脚本正常跑着，后台能看到钱包收到U了，但商户始终没收到回调，订单一直是待支付状态。
原因：最常见的是Nginx伪静态规则把notify.php这个路径劫持了。跑分源码大多用ThinkPHP或其他框架，路由规则会把所有请求重写到入口文件index.php，而商户的回调地址通常是http[s]://域名/notify.php这类独立入口，如果location规则没有单独放行，请求会被送到框架路由里，返回404，回调自然失败。
解决：先把回调地址改成带index.php的路径，比如/notify.php改成/index.php?s=/notify/receive，确认能通后再处理伪静态。如果要用伪静态，Nginx配置里加一条location = /notify.php的精确匹配，把这条请求直接指向PHP-FPM，绕过框架路由。测通后用curl模拟一次商户回调，确认返回SUCCESS，再让监听脚本触发真实回调。
5.2 坑二：监听模块收到交易，但入账金额对不上
现象：用户转了100U，后台订单只记了99.9U，金额比对一直失败，订单停在待确认。
原因：TRC20转账时有“扣网络手续费”的模式差异，转账方可以选择从转账金额里扣，也可以选择从自己的余额里另扣。监听脚本如果只读取交易的amount字段，没考虑实际到账金额的差异，就会出现小数点后的差额。另外，不同浏览器访问API对金额字段的精度定义不同，有的返回字符串，有的返回科学计数法，直接转float可能丢失精度。
解决：监听模块解析交易时，把“转账金额”和“到账金额”拆成两个字段记录，确认入账时以到账金额为准。金额比对允许容差，一般在0.0001 USDT以内。实现上不要用float直接等值比较，统一转成整数最小单位并转为字符串比较。排查时打开监听模块的调试日志，看它解析出来的原始JSON里amount和到账字段分别是多少，对比一下就能定位是取错了字段还是精度丢了。
5.3 坑三：回调并发进来，同一个订单被入账两次
现象：后台订单余额显示正常，但跑分人员账户里佣金被叠加了，一张订单产生了两笔流水。
原因：回调接口被重复调用，或者监听脚本和手动补单工具同时处理了同一笔txid。如果订单表没有唯一索引，或者状态判断没放在事务里的行锁中，两条请求同时读到待支付状态，就会各记一次账。
解决：先给订单表加(order_no)唯一索引，给入账流水表加(order_no, txid)联合唯一索引，这是硬兜底。再检查状态判断代码，必须在事务里用select for update锁住订单行再更新，不能用先查后改、两步分开的写法。最后确认是否已经有Redis锁，锁的TTL按第3章说的8秒设置。排查时打开MySQL慢查询日志，找到同时出现的两条update语句，执行时间几乎一致就可以判定是并发重复入库。
5.4 坑四：验签一直失败，最后发现是服务器时区问题
现象：本地测试回调验签全部通过，一上服务器就返回sign_error，商户端也报签名错误，但签名串看起来完全一样。
原因：签名串里如果包含时间戳，而服务器时间比真实时间慢了或者快了超过允许窗口，就会导致商户端在用同一时间戳验签时对不上。另外，PHP在Windows和Linux环境下ksort函数的字符排序顺序在个别字符上存在差异，服务器的默认语言区域如果被改成非ASCII排序，也会产生不同结果。
解决：先把服务器时间同步到标准时间，在业务代码里对所有时间戳校验做一个正负5分钟的误差窗口，不要做精确等于。然后用日志把服务器端拼接的签名串原样打印出来，和商户端记录的待验签串做逐字符对比，差异在哪里一眼就看得出来。同时，拼接签名串时统一用PHP的ksort($params, SORT_STRING)显式指定排序方式，不要依赖环境默认行为。
5.5 坑五：跑分人员自己下了一笔单，把推广佣金刷走了
现象：某跑分人员的下级数量短期内快速增长，每个下级都是小额订单，佣金支出明显高于正常水平，但订单本身都是真实链上入账。
原因：分级佣金被自刷，用户自己注册小号挂在自己下面，用极低金额的订单反复刷佣金。系统没有做设备指纹、IP段和订单金额的关联风控，也没设置提现审核，佣金入账后直接提到外部地址。
解决：在注册环节做同IP注册次数限制，建议5分钟2次；订单确认时把用户下单的IP、user_agent、设备指纹都记录到订单扩展表，佣金结算后做一次批量风控扫描，同一个IP或同一设备指纹关联的订单，提现时人工审核。如果源码没有提现审核模块，这个功能上线前一定要补，它是最后一层后悔药。
6. 验收清单：用一次回调压测判断5000花得值不值
源码拿到手先别急着配后台，花半天时间把回调压测和分销核对做掉，这5000值不值就清楚了。第一步是写一个简单脚本并发请求notify接口，同一笔订单号发20个请求，然后查订单余额和佣金流水，正常结果应该只入账一次。第二步是构造一笔100U的测试订单，手动触发结算，分别查三级上线的余额流水，核对比例和舍入是否符合要求。
#!/bin/bash for i in $(seq 1 20); do curl -s -X POST https://你的域名/notify.php \ -d "order_no=TEST202501010001&amount=100&txid=faketx$i&status=1&sign=按规则算出的签名" & done wait跑完查看数据库，订单状态已确认、佣金流水中TEST202501010001只出现一条，说明幂等生效；如果出现了两条，直接按第5章第三个坑去查唯一索引。入库金额、回调响应码、日志完整度这三项都过了，再谈上线。我现在拿到这类支付源码，第一步一定是先跑回调压测再动部署，因为回调链路上隐藏的问题，大多数都要在并发下才暴露；等真上客时再发现，补的不是代码而是信任。希望帮到你。
本文还有配套的精品资源，点击获取
