V免签支付系统实战：安卓监听实现免签约收款回调-开发者社区

简介：这是一款基于Thinkphp内核的V免签支付系统安卓监控端，面向需要为应用接入支付宝、微信免签约收款的开发者，省去与支付机构正式签约的流程，帮助商家实时掌握收款动态。压缩包约34.03MB，共297个文件，其中class与jar为后端编译类库，js/css/html构成前端管理界面，gif为操作演示动画，apk为可直接安装的监控端应用。已有187人学习下载。资源包含从环境配置、Thinkphp框架安装、数据库部署到支付平台接入、安卓接口对接的完整内容，并配有视频讲解，让搭建步骤更直观。教程还专门讲解HTTPS加密、数据校验和防范常见攻击等安全措施。整体结构兼顾代码与文档，适合有一定PHP基础、希望快速搭建免签约收款监控体系的开发者系统参考。

1. V免签支付系统到底在解决什么问题：不签约也能回调收款

做过个人项目收款的朋友应该都有同感：支付宝、微信的官方支付接口看着功能全，但商户签约这道门槛直接卡死一大批人——要么需要营业执照，要么需要有企业资质，要么审核周期长到项目凉一半。V免签支付系统的核心思路就是绕过签约环节：用一个安卓手机安装监控端，监听支付宝或微信的账变通知，再把结果回调给网站后台，让个人开发者也能用上完整的“下单—付款—回跳”闭环。

这套方案的字面意思是“免签约收款”，但落到工程上，它实际干了两件事：一是把实体手机的支付结果变成可编程的 HTTP 回调，二是用 ThinkPHP 框架把订单、回调、通知地址管理串成一套后台。适合的场景很明确：个人开发者、小工作室承接外包项目时，客户没有商户号，又急需一个能线上收款的演示环境；或者正在测试电商原型，不想在没验证商业模式之前就去办一堆资质。

常见误解是把它当“黑科技”或者“外部操作工具”用。其实它的支付动作本身100%发生在支付宝和微信官方客户端里，资金也直接进你自己的账户，系统只是在手机端读取通知栏里的“收款到账”消息，再转发给 ThinkPHP 后端去改订单状态。理解了这个边界，你就知道这套东西技术上不犯法、不触碰支付通道，风险点只在于平台规则对个人收款的容忍度，用在小额、熟人、测试场景最稳妥。

下面按我自己的落地顺序展开：先讲回调链路是怎么设计和实现的，再讲服务端怎么搭、安卓端怎么配，最后把最容易翻车的几个地方单独列出来。

2. 回调链路设计：安卓监听端怎么把“到账通知”变成订单状态

2.1 免签回调解决的核心问题：没有服务器端通知

用官方支付接口时，支付平台会在用户付完款后，从服务器直接给你配置好的回调地址发一条带签名的通知。这条通知叫“异步通知”，订单状态以它为准。V免签没有签约，拿不到这个官方异步通道，所以必须自己造一条通路。

造通路的办法是这样：安卓手机上安装监控端，开启“通知栏监听”权限后，当支付宝或微信弹出“收款到账 XX 元”这类系统通知时，监控端App捕获这条消息，提取金额和付款人，再通过 HTTP 请求把数据 POST 给你自己的 ThinkPHP 后端。后端收到后拿着金额去匹配未支付订单，匹配上了就改状态，再触发业务逻辑（比如发放积分、开通会员）。

整条链路的关键点有三个：手机通知栏监听要稳、通知消息解析要准、HTTP 回调要能和订单对得上。第一点和手机厂商的省电策略有关，第二点看监控端的正则配置，第三点看你的订单金额唯一性或备注匹配逻辑。刚开始玩这套方案的人，往往把精力花在部署上，结果用几天发现漏单——大概率是这三处某一段断了。

2.2 回调协议设计：token 验证 + 时间戳 + 订单匹配

服务端设计回调接口时有现成规范可以参考。V免签的自有协议大致是向notify.phpPOST 一组字段，包括pay_type（1 支付宝 / 2 微信）、total_fee（实际到账金额）、trade_no（平台交易号）、out_trade_no（你自己的订单号）、param（自定义参数）、sign（签名）、type（通知类型），后端拿配置好的 token 对参数做一次签名校验，再把out_trade_no对应的订单置为已支付。

实际动手时我通常是这么处理的，一个 PHP 接口接收回调的核心逻辑如下：

<?php // application/api/controller/Notify.php namespace app\api\controller; use think\Controller; use think\Db; class Notify extends Controller { // 你的 token，和安卓端监控App里填的保持一致 private $token = '在此填写你的通信密钥'; public function index() { $post = input('post.'); // 1. 基础字段检查 if (empty($post['trade_no']) || empty($post['total_fee']) || empty($post['sign'])) { return json(['code' => 400, 'msg' => '参数缺失']); } // 2. 签名校验 $sign = $post['sign']; unset($post['sign'], $post['type']); $checkText = $this->token . ksort($post); // 按协议排序后拼 token 取 md5 $checkText = $this->token; ksort($post); foreach ($post as $k => $v) { $checkText .= $k . $v; } if (md5($checkText) !== $sign) { return json(['code' => 400, 'msg' => '签名错误']); } // 3. 订单匹配：先查订单号，再核对金额 $order = Db::name('order')->where('order_sn', $post['out_trade_no'])->find(); if (!$order) { return json(['code' => 400, 'msg' => '订单不存在']); } if ($order['status'] == 1) { return json(['code' => 200, 'msg' => '重复通知已忽略']); } // 金额比对：转成整数分比较，避免浮点误差 if (intval($order['amount'] * 100) !== intval($post['total_fee'] * 100)) { return json(['code' => 400, 'msg' => '金额不一致']); } // 4. 更新订单 Db::name('order')->where('id', $order['id'])->update([ 'status' => 1, 'pay_time' => time(), 'platform_trade' => $post['trade_no'], ]); return json(['code' => 200, 'msg' => 'success']); } }

这里每个步骤都有它的必要性。签名校验是为了保证回调确实来自你自己的安卓手机，防止别人往你的接口里伪造“支付成功”的请求——可别小看这一点，接口一旦裸奔，等于把充值入口放在了公网上；金额比对必须用“分”为单位做整型判断，PHP 的浮点数做==比较会出奇怪的结果，这就是金额对不上问题的根源之一。

2.3 服务端要同时准备的配套能力：轮询、回跳、超时关单

回调接口只是链路里的一环。用户付款后，网页端怎么知道支付成功了？两个常见方案：一是前端轮询，每秒或每两秒请求一次订单状态抓接口；二是 WebSocket 推送。小项目用轮询最简单也最稳，ThinkPHP 里写一个orderStatus接口就行。

轮询接口的响应里要包含几个关键信息：订单状态（未支付/已支付/已关闭）、支付类型（支付宝/微信）、支付金额。前端拿到已支付状态后跳转感谢页。这里的细节在于：轮询接口不要每次都查数据库，可以用 ThinkPHP 的缓存把高频订单状态缓存 5 秒，HTTP 压力一下就降下来了。

超时关单则要配合一个定时任务。我自己习惯写一条 Shell 脚本每分钟调一次 ThinkPHP 命令行方法，把超过 15 分钟未支付的订单标记为“已关闭”。这个动作很重要，因为监控端App可能因为手机休眠而延迟上报，如果把所有订单无限期挂着，订单表里全是不明不白的死单，后面查账非常痛苦。

## 3. ThinkPHP 部署细节：伪静态、入口文件与数据库初始化 ### 3.1 本地快速跑通 ThinkPHP 5.x 的最小步骤 V免签的后端基于 ThinkPHP 内核，很多下载包里直接带了全部代码。第一次拿到压缩包，不要急着传到服务器上，先在本地 Windows 或 Mac 上用集成环境跑一遍。以我常用的 Ubuntu + Nginx 环境为例，完整落地流程是： ```bash # 1. 解压源码到 web 目录 cd /var/www/html unzip V免签支付系统.zip -d vpay cd vpay # 2. .env 文件（新版本 ThinkPHP 用独立配置） vi .env

.env里至少要配数据库连接、应用地址、调试开关这三组信息：

[APP] ; 部署阶段务必关掉调试模式 DEBUG = false [DATABASE] TYPE = mysql HOSTNAME = 127.0.0.1 DATABASE = vpay USERNAME = root PASSWORD = 你的数据库密码 HOSTPORT = 3306 CHARSET = utf8mb4 [API] ; 和安卓端 App 里填写的 token 必须一致 TOKEN = 你的通信密钥

接下来是导入数据库并配置站点：

# 3. 建库并导入 sql（源码包里一般带 install.sql） mysql -uroot -p -e "CREATE DATABASE vpay DEFAULT CHARSET utf8mb4;" mysql -uroot -p vpay < install.sql # 4. 给 runtime 写权限，否则 ThinkPHP 会报目录不可写 chmod -R 777 runtime chmod -R 777 public/uploads # 5. Nginx 站点配置指向 public 目录，重点看下一步伪静态

配置完启动 PHP 内置服务器最快验证页面能不能开：

cd /var/www/html/vpay php -S 0.0.0.0:8080 -t public

浏览器打开http://127.0.0.1:8080/index.php/index/index，能看到页面说明框架已经跑起来了。本地这一步跑不通的话，不要往后走，先排查是数据库连接问题还是 runtime 权限问题，最常见的坑就是.env里漏了[DATABASE]的某项配置，导致连接数据库直接抛异常。

3.2 Nginx 伪静态与 ThinkPHP 路由：报错 404 的元凶

在 Apache 下跑 ThinkPHP，程序一般自带.htaccess，不用额外配置。但大多数服务器用的是 Nginx，如果不写伪静态规则，访问任何非首页地址都会 404。这个原因在于：ThinkPHP 是单入口框架，所有请求都要经过public/index.php，由框架路由分发给控制器。

Nginx 的伪静态规则是一个坑点，我最常用的是下面这套：

server { listen 80; server_name yourdomain.com; root /var/www/html/vpay/public; index index.php index.html; location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s=$1 last; break; } } location ~ \.php$ { fastcgi_pass unix:/run/php/php7.4-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }

这里rewrite ^(.*)$ /index.php?s=$1 last;是关键。ThinkPHP 5.x 默认用 PATHINFO 模式解析 URL，Nginx 不重写的话，/index.php/index/notify这种地址会直接落磁盘找文件，找不到就 404。改完配置记得重载 Nginx：nginx -s reload。

另外很多人在服务器上配好后访问后台出现 404，十有八九是忘了把站点根目录指到public，而指到了项目根目录。ThinkPHP 出于安全考虑，application目录绝对不能暴露在 Web 可访问路径下，这也是为什么官方推荐root指向public。

3.3 安装向导跑完，后台登录不上的排查链路

源码包里的安装向导会帮你生成配置和导入数据，但跑完向导后经常出现“后台登录跳回首页”或者“登录报错”的情况。按我的排查顺序来：先开 ThinkPHP 的调试模式，把.env里DEBUG = true，再访问页面看具体报错。

常见的几类问题和对应处理：

数据表前缀对不上：安装向导生成的库表可能带vpay_前缀，但代码里模型默认查vp_order，两者对不上就查不到数据。去数据库看一眼表名前缀，.env里没有专门配置前缀的地方就把它写在database.php的prefix字段里。
验证码不刷新：这通常不是代码问题，而是服务器时间不准确。ThinkPHP 验证码会基于会话和图形库生成，时间跳跃会导致 session 失效。执行date -R看服务器时间，偏差大就先同步时间。
密码一直提示错误：源码包内可能有官方默认密码（常见的是admin/123456），但如果是别人二次打包的，密码可能被改过。最直接的处理是打开数据库，看user表里password字段的加密方式，ThinkPHP 里改密码最简单的方式是调用自带方法重新生成哈希，直接 SQL 改容易踩加密方式不匹配的坑。

后台登录是整套系统对外的第一道门，登录这块不稳，后面所有订单业务都白搭。本地调试时把所有错误显示打开，线上再关掉，这种“先裸奔再穿衣”的思路能帮你少走很多弯路。

## 4. 安卓监控端配置全流程：通知监听、关键词匹配和权限白名单 ### 4.1 权限设置：安卓 8.0 以上，软件要过的三关 安卓端监控是这个系统的“传感器”，它的稳定程度直接决定漏单率。从安卓 8.0 开始，后台应用被系统加了层层限制，不把权限配齐，App 在锁屏几分钟后就会被杀死，收不到通知自然无从回调。 监控端 App 一般会明确列出自己需要的权限，常见是这几类：通知使用权（NotificationListenerService）、电池优化白名单、自启动权限、浮窗或后台弹窗权限。每类权限在不同手机上的入口不一样，比如小米在“安全中心—应用管理—权限管理”，华为在“设置—应用—应用启动管理”，部分系统还有“纯净模式”额外拦截。 一句话原则：凡是系统提示“允许后台运行”“允许自启动”“忽略电池优化”的地方，全开。国产 ROM 对后台应用格外苛刻，有些手机会把目标 App 的推送服务直接掐断，这就需要你去开发商的后台把“神隐模式”或者“智能限制后台”给关掉。这一步不做，后面调接口写得再稳也是白费。 ### 4.2 通知监听与关键词提取：凭什么确定这是收款成功 监控端App读取通知栏文本，靠的是 `NotificationListenerService` 的 `onNotificationPosted` 回调。代码层面拿到的是系统通知的 `title` 和 `text` 字符串，接下来就是匹配逻辑。 支付宝收款的系统通知一般是“支付宝到账 XX 元”这种格式；微信收款的通知则和收款方式有关，个人收款码到账会显示“微信支付收款 XX 元”，也有商户版显示“收款到账 XX 元”。监控端App里通常有一个“关键词”设置页，让你填触发词，比如“到账”“收款”。 实践中要小心的是“匹配过宽”和“匹配过窄”两头的问题。比如只匹配“到账”两个字，别人给你发一条“货款明天到账”的聊天消息，也会被误判为收款；匹配“支付宝到账”又会漏掉微信的场景。我的做法是设置至少两个条件同时满足：主关键词（到账 + 收款）和金额模式（正则匹配到“元”之前的数字）。App 如果支持自定义正则最好，不支持就把关键词列表配全，宁多勿漏，日志里能看到每次捕获的消息原文，用来调整匹配规则。 ### 4.3 连接服务端：通信 token、回调地址和重试机制 安卓端配好权限和关键词后，最后一步是填服务端地址和通信密钥。这一步的关键配置项我列在下面： | 配置项 | 建议值 | 说明 | | --- | --- | --- | | 服务端地址 | `http://你的域名/index.php/api/notify` | 指向 ThinkPHP 的回调接口 | | 通信 token | 与原 .env 中 `[API] TOKEN` 一致 | 不一致会报签名错误 | | 轮询间隔 | 10秒 | 影响手机和服务端的通信频率 | | 超时重试 | 3次 | 请求失败后重试次数 | | 设备标识 | 手机型号加编号 | 多台手机同时监控时区分日志 | 填好后点一下“测试通知”或者在支付宝里给自己转一分钱来验证链路。注意，监控端发的是 **HTTP 请求**，走的是你服务器的公网地址，如果服务器在国内没备案的域名访问不到，直接填服务器 IP 也可以，但后续 APP 端如果做了域名校验就得注意。 ## 5. 避坑与排查：漏单、重复回调、手机被杀，三大高频故障怎么定位 ### 5.1 漏单：后台一直收不到回调，钱却收了 现象：用户付款成功，支付宝/微信账单里已经扣款，后台订单仍是“未支付”。 原因拆解，九成是下面三类： - 手机 App 在前台/后台被杀，根本没捕获到通知。验证方法：在手机通知栏手动下拉，看 App 是否还活着；去 App 内置日志页看有没有捕获记录。 - App 捕获到了，但 HTTP 请求发不出去。服务端地址填错、域名解析失败、服务器防火墙挡了 80/443，都会让请求在网络上绕圈。验证方法：在服务端 Nginx 日志里 grep 当天的 `/api/notify` 访问记录，有记录就是到达了，没记录就是网络问题。 - 请求到了，但金额或备注匹配不上。比如用户实际支付了 12.10 元，但因为优惠导致订单金额和到账金额不一致。验证方法：打开数据库订单表，看 `total_fee` 的值和实际到账差多少。 解决优先级：先确认监控端 App 在前台保持运行并开启“测试通知”功能，再查服务端日志，最后核对订单数据。绝大多数漏单是第一步没做干净。 ### 5.2 重复回调：同一笔订单被通知了两次以上 现象：用户付一次款，PHP 日志里出现两次 `/api/notify` 请求，订单状态被重复更新。 原因：手机通知栏出现两次通知（比如支付宝先弹一条“收款到账”，紧接着又弹一条“付款详情”）就会触发两次解析；另外，监控端 App 的 HTTP 超时重试机制也会导致同一通知被发送两次。 解决：接口里的幂等判断必须做。我的做法是：每次回调进来先查订单有没有已经在“已支付”状态，是的话直接返回成功而不修改数据。上面 `Notify` 控制器里已经有这段逻辑，不要因为它短就忽略。另外在订单表里加 `callback_log` 字段或者单独建一张表记录所有回调的原始报文，方便定位重复来源。 ### 5.3 后台能支付但收不到通知，安卓端的状态栏一直被系统清理 现象：安装在旧安卓手机上的监控端，当天能用，第二天就失效了。要点开 App 才恢复，锁屏一段时间又失效。 原因：国产 ROM 的内存清理机制在作祟。“自启动”权限和“电池优化白名单”在重启后丢失是常见现象，部分机型还会在夜间自动清理后台。 解决：把 App 加入系统“不清理列表”（在最近任务界面下拉锁定）；建议用专门的一台安卓手机跑监控端，不要又当测试机又当监控机；有条件的话给手机插上电源，关闭自动锁屏和休眠，再把屏幕亮度降到最低放一边，这是目前最稳的“硬核方案”。手机管家类 App 要卸载或允许名单全过，这类工具本身就是后台杀手的源头。 ### 5.4 支付宝和微信官方接口的回调时效对比 很多人不注意一个差异：官方接口回调是秒级的，服务器到服务器，毫秒到几十毫秒就完成；V免签的手机监听方案是秒到十几秒，取决于手机通知栏捕获速度和 HTTP 请求建立连接的速度。这意味着你的前端轮询逻辑不能按官方回调的节奏来设计。 轮询间隔建议设 3 到 5 秒，超时阈值 60 秒。不要设 1 秒轮询一次，又占服务器资源，又制造大量无效请求。同时页面要做好“等待支付结果”的友好提示，至少要有一句“支付成功后自动跳转，如果长时间未跳转点此刷新”。 ## 6. 回归自测：把回调链路变成一条可重复跑通的命令 ### 6.1 写一个模拟回调的脚本，不依赖真钱 这套方案刚搭完后，直接用真钱去测试，又要盯着手机看，又要在后台刷新页面确认状态，来回跑非常低效。更聪明的做法是先写一个模拟回调脚本，把端到端的流程验证完，再拿真钱做一次最终确认。 我保存了一份脚本，它可以直接调用你想对应的 `` 接口，本质是手工模拟安卓端发出的数据： ```python import time import hashlib import requests # 改成你实际的配置 BASE_URL = "http://127.0.0.1:8080/index.php/api/notify" TOKEN = "你的通信密钥" OUT_TRADE_NO = "202501010001" # 手动造一个未支付订单 TOTAL_FEE = "0.01" def make_sign(params: dict, token: str) -> str: # 签名规则：token + 参数排序后 key + value 拼接，再 md5 payload = token for key in sorted(params.keys()): payload += key + str(params[key]) return hashlib.md5(payload.encode("utf-8")).hexdigest() params = { "pay_type": "1", "total_fee": TOTAL_FEE, "trade_no": "TEST" + str(int(time.time())), "out_trade_no": OUT_TRADE_NO, "param": "", "type": "alipay", } params["sign"] = make_sign(params, TOKEN) resp = requests.post(BASE_URL, data=params, timeout=10) print("接口返回:", resp.text)

运行参数解析之前，先给测试用先在订单表里手动插入一条order_sn = 202501010001、status=0的未支付订单。

返回success后再查表，订单状态应从 0 变成 1，pay_time和platform_trade也同步写入了。这一步过了，说明签名校验、订单匹配、金额比对、状态更新这条主链路全通。

6.2 进阶优化：订单回调幂等、并发控制和日志入库

主链路通了之后，不要急着马上投产，挑三个可以在 30 分钟内完成的优化点做掉。

第一是回调接口的并发控制。用户可能同时付款多笔订单，回调请求在同一秒涌进来。PHP 单线程模型下不会出太大问题，但要注意 MySQL 的并发写入。我习惯在更新订单的 SQL 里加条件WHERE status = 0，确保同一笔订单只有第一次能更新成功。

第二是记录完整回调日志。把$_POST的全部字段 JSON 编码后写入一张callback_log表，表结构就四个字段：id、order_sn、request_body、create_time。排查问题的时候，能在日志里看出手机上传的原始报文长什么样，是判断到底哪一段出错的最好依据。

第三是支付页面增加“已支付订单不允许重复提交”的逻辑。后端创建订单前先查库里有没有同款未支付订单，有就直接返回原订单号，避免用户在刷新页面的瞬间生成两笔一模一样的订单，导致回调时后端输了对不上号的状况。

支付成功后的跳转逻辑也顺手加一下，ThinkPHP 控制器里在订单状态刷新为已支付后 redirect 到成功页，页面里再把废弃的轮询请求停掉。这看起来是细节，实际是防止用户看到页面在转圈，回头又去付一笔，白花冤枉钱。