简介V免签支付系统安卓监控端全套源码及视频搭建教程面向具备PHP基础、希望快速实现支付宝/微信免签约收款回调处理的开发者。整套方案围绕Thinkphp框架构建后端服务覆盖支付回调、收款监控、数据统计等核心功能同时提供安卓监控端APK与接口对接方案帮助跳过签约流程直接完成收款通知与业务联动。压缩包共297个文件以class、jar、js、html、css、gif等为主分别对应后端逻辑、第三方依赖库、前端页面和演示图解并额外附带APK安装包、视频教程及环境配置脚本整体大小约34MB。目前已有187人学习浏览。资料中的视频与部署文档从PHP环境搭建、数据库配置、Thinkphp接入到支付平台回调、安全加固逐步拆解既适合独立开发者快速上手也能为已有业务系统集成移动支付提供参考是一份贴近实战、便于对照落地的源码教程。1. V免签在支付链路里补的是哪一段空位做过支付对接的人都清楚微信支付和支付宝的官方API要求必须有商户号、应用AppID和密钥而商户号审批需要营业执照或对公账户。临时环境、个人开发者、企业内部测试平台往往拿不到这套资质但业务又确实需要“用户付了钱服务端立刻知道”的闭环。V免签这套方案就是为这段空位设计的在手机上装一个安卓监控端App通过无障碍服务和通知栏监听捕获支付到账的通知再把结果推给ThinkPHP服务端服务端生成回调给业务系统。它把“支付成功”这件事从安卓端“搬运”到了服务器本质上是在补“收单通知”的缺失。这套链路适合三类人一是刚起步的小团队想先把支付闭环跑通再做商户备案二是给客户做演示、内测、体验版等正式上线再切官方接口三是想研究回调机制、幂等设计和轮询上报的技术人员。需要先说清楚的是生产环境优先走官方支付接口V免签这类方案适合测试和中转合规性要自己把握。接下来我会按服务端部署、安卓监控端、回调对接、链路验证的顺序讲一遍我平时搭这套系统的完整做法。2. 服务端部署ThinkPHP内核下的基础配置与参数选型服务端是整个系统的中枢所有订单状态、设备注册、回调记录都落在这一层。V免签这类系统大多基于老版本ThinkPHP开发最常见的版本是ThinkPHP 3.2.x它在PHP 5.3时代成型拿到新服务器上第一步就是解决运行环境兼容问题。2.1 环境兼容ThinkPHP 3.2在PHP 7.4和PHP 8之间的取舍ThinkPHP 3.2 官方原版只承诺支持PHP 5.3以上版本到PHP 7.0时代就已经出现不少报错。实际部署中我看到最多的问题是mysql_*函数被移除、each()函数在PHP 8.0被删除、create_function()在高版本不可用。社区里有一个专门给ThinkPHP 3.2打PHP 7补丁的分支处理了大部分兼容问题但即使打了补丁PHP 8.1以上的动态属性Deprecation警告仍然会刷屏。我一般建议用PHP 7.4来跑老版本ThinkPHP服务端理由有两点对比项PHP 7.4PHP 8.0each() 等老函数保留但标记废弃已移除动态属性创建正常触发 Deprecation框架自带缓存驱动可直接用部分驱动报错老扩展兼容良好mhash、mcrypt等缺失PHP 7.4 同时兼容了框架老代码和现代语法是运行成本最低的选择。如果你非要用PHP 8记得在入口文件强制关闭所有Deprecation提示并且提前检查代码里是否用了each、eregi、mysql_connect这类函数。2.2 Nginx环境下的站点配置与伪静态规则Web服务器建议选Nginx性能比Apache好配置也直观。站点配置里最核心的是把请求重写到index.php入口文件这一步做不对访问任何路由都会404。server { listen 80; server_name pay.example.com; root /var/www/vpay; index index.php index.html; location / { if (!-e $request_filename) { rewrite ^/(.*)$ /index.php?s$1 last; } } location ~ \.php$ { include fastcgi_params; fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } location ~* \.(sql|log|bak|ini)$ { deny all; } }rewrite ^/(.*)$ /index.php?s$1是ThinkPHP在Nginx下的标准伪静态写法其中$1是原始请求路径框架会通过s参数解析到对应的控制器和方法。后面的location把所有敏感后缀文件直接拒掉避免安装包里的SQL备份或日志文件被公网直接下载。2.3 数据库导入与核心表结构V免签系统依赖几张核心表订单表、设备表、回调记录表。建好数据库后重点检查订单表里的索引设计因为设备端轮询订单状态是高频操作没有索引的话数据量上来之后查询会明显变慢。CREATE TABLE vpay_order ( id int(11) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 平台订单号, mch_order_no varchar(32) NOT NULL COMMENT 业务方订单号, amount decimal(10,2) NOT NULL COMMENT 订单金额, pay_type tinyint(1) NOT NULL DEFAULT 1 COMMENT 1支付宝 2微信, device_no varchar(32) DEFAULT NULL COMMENT 收款设备编号, status tinyint(1) NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已回调, create_time int(11) NOT NULL, pay_time int(11) DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_mch_order (mch_order_no), KEY idx_status_time (status, create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;UNIQUE KEY uk_order_no保证平台单号唯一后续幂等判断依赖这个字段。idx_mch_order方便按业务单号反查排障时最常用到的就是它。idx_status_time是复合索引服务端定时扫描待支付到期订单时用得上。2.4 渠道参数配置应用标识、支付类型与回调地址安装完成后后台管理界面里需要配置的常见参数包括应用AppID、应用密钥、通讯密钥、收款二维码有效期。其中最重要的是“通讯密钥”它是安卓监控端和服务端之间的共享密钥监控端上报支付结果时用它做签名。这个参数不要用默认值建议生成一个32位以上的随机字符串。回调地址则关系到支付成功后服务端把结果通知到哪。这套系统和官方支付回调有一个明显差异支付宝回调、微信支付投诉回调都是平台主动POST给服务器的而V免签是服务器收到安卓端上报后再转发。所以业务系统那边配置的“网页授权回调域名”或“支付回调URL”指向的是V免签服务端的入口地址而不是直接指向你自己的后端。3. 安卓监控端无障碍服务识别支付到账的关键路径安卓监控端是这套系统里技术含量最高的部分。它的职责是盯着支付宝和微信的收银台一旦有收款到账立刻把结果上报服务端。实现方式主要有两种监听通知栏消息以及截屏分析界面。多数方案是两种结合用通知栏做第一触发用截图做二次确认。3.1 监听通知栏AccessibilityService的最小实现通知栏监听是触发最快、准确率较高的方式。支付宝和微信在收款到账时都会弹出通知监控端注册一个无障碍服务在onAccessibilityEvent里拦截TYPE_NOTIFICATION_STATE_CHANGED类型的事件就能拿到通知里的文本内容。class PayMonitorService : AccessibilityService() { override fun onAccessibilityEvent(event: AccessibilityEvent?) { if (event null) return if (event.eventType AccessibilityEvent.TYPE_NOTIFICATION_STATE_CHANGED) { val parcelable event.parcelableData if (parcelable is Notification) { val extras parcelable.extras val title extras?.getCharSequence(Notification.EXTRA_TITLE).toString() val text extras?.getCharSequence(Notification.EXTRA_TEXT).toString() if (isPaymentNotification(title, text)) { reportPayment(title, text) } } } } override fun onInterrupt() {} }EXTRA_TITLE通常对应通知的标题EXTRA_TEXT对应详情内容。这里isPaymentNotification要做的是关键词过滤比如支付宝通知标题含“支付宝”或“收款”微信通知含“微信支付”或“收款到账”过滤通过再触发上报避免普通聊天通知误报。3.2 截图识别确认金额准确性的第二道校验仅靠通知栏文本有个隐患通知内容不完整或者被系统折叠拿不到“收款金额”和“付款人”。到账金额是核心数据一旦解析错造成的后果比丢单严重。因此我习惯在通知命中后再触发一次截屏把当前屏幕截图发给服务端由服务端用OCR识别图片中的金额和商品描述和通知里的金额做交叉校验。高版本安卓上AccessibilityService.takeScreenshot()是系统API不需要额外授权但需要API 30以上。低版本设备有两种常见替代方案用MediaProjection申请屏幕录制权限或者干脆走Root方案直接读帧缓冲。实际选型时看用户设备分布如果你的目标用户都是新手机无障碍截图就够了。if (Build.VERSION.SDK_INT Build.VERSION_CODES.R) { takeScreenshot( Display.DEFAULT_DISPLAY, context.mainExecutor, object : TakeScreenshotCallback { override fun onSuccess(screenshot: ScreenshotResult) { val bitmap screenshot.hardwareBuffer.toBitmap() uploadScreenshot(bitmap) } override fun onFailure(errorCode: Int) { saveFailureEvent(screenshot_failed_$errorCode) } } ) }OCR识别放在服务端做而不是端上原因是安卓端的算力参差不齐Tesseract在低端机上跑一次要好几秒容易把监控线程拖死。服务端收到图片后抠出金额区域再识别速度更快准确率也更稳定。3.3 上报协议与失败补偿断网、被杀进程怎么处理监控端上报接口的调用时机需要注意通知刚到的那一瞬间就上报经常遇到服务端还没准备好订单数据的情况处理不好就是上一秒报了“已支付”下一秒查询订单返回“不存在”。我习惯把上报设计成异步队列先落本地数据库再逐条同步失败的重试交给一个带退避策略的循环。val requestBody JSONObject().apply { put(device_no, deviceNo) put(order_no, currentOrderNo) put(amount, amountText) put(pay_type, if (isAlipay) 1 else 2) put(screenshot_id, screenshotId) put(occur_time, System.currentTimeMillis()) } val signStr $deviceNo$currentOrderNo$amountText$secretKey put(sign, md5(signStr))签名串是把设备号、订单号、金额和密钥拼接后做MD5服务端用同样算法验签。这里有个容易忽略的点拼接的字段顺序一旦定下来就不能改否则升级客户端后所有上报都会验签失败。上报后服务端应返回1表示成功、0表示失败客户端收到非成功响应就进入重试队列最多重试5次间隔分别是1秒、5秒、30秒、5分钟、15分钟。4. 回调业务系统时的验签、幂等与补偿方案监控端上报了支付结果服务端更新订单状态接下来就是最关键的环节把支付结果安全可靠地通知到业务系统。这一层做不好用户付款后迟迟不发货比支付失败更伤体验。4.1 回调数据结构与签名验证流程业务系统收到的回调参数一般包含订单号、金额、支付类型、平台单号和签名。服务端在处理回调之前必须先验签防止伪造通知。这里给出ThinkPHP控制器里的一段验签逻辑public function notify() { $mchKey $this-getMchKey(I(post.mch_id)); $sign I(post.sign); unset($_POST[sign]); ksort($_POST); $signStr urldecode(http_build_query($_POST)) . $mchKey; if (md5($signStr) ! $sign) { exit(sign error); } $orderNo I(post.mch_order_no); $amount I(post.amount); $order M(order)-where([mch_order_no $orderNo])-find(); if (!$order || $order[status] 1) { exit(success); } if (bccomp($order[amount], $amount, 2) ! 0) { exit(amount mismatch); } M(order)-where([id $order[id]])-save([status 1, pay_time time()]); exit(success); }参数说明第3行$mchKey是对应商户的密钥每个接入方应该分配独立密钥。第6行http_build_query把除签名外的所有参数排序拼接再拼上密钥做MD5这是最常见的签名算法。第15行bccomp必须用字符串比较函数直接比较浮点数会被精度问题坑比如数据库存的是 0.10回调传过来是 0.1两者用浮点比较可能通过但遇到 19.99 这类金额则可能出现偏差。4.2 幂等表设计重复通知不会二次发货支付回调天生是“至少要收到一次”的语义网络抖动、业务方重启、消息队列重试都会导致同一个订单被通知多次。如果你只是在回调里判断订单状态会出现一种竞态第一次回调处理中第二次回调又进来了两条并发请求都读到“未处理”然后都执行发货逻辑。正确做法是把“回调通知”本身建成一张独立的流水表用订单号做唯一键CREATE TABLE vpay_callback_log ( id int(11) NOT NULL AUTO_INCREMENT, mch_order_no varchar(32) NOT NULL COMMENT 业务订单号, callback_url varchar(255) NOT NULL, request_body text NOT NULL, response_body text, status tinyint(1) NOT NULL DEFAULT 0 COMMENT 0待通知 1成功 2失败, retry_count tinyint(1) NOT NULL DEFAULT 0, next_retry_time int(11) NOT NULL, create_time int(11) NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_mch_order (mch_order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;uk_mch_order唯一索引保证同一订单只会插入一条回调记录后续所有重复通知都转换成“查询已有记录”而不是重新触发业务逻辑。next_retry_time字段支撑了后面的定时补偿任务扫描条件就是status 2 AND next_retry_time 当前时间。4.3 两种对接方式HTTP推送和中间表拉取业务系统接入方式有两种流派。一种是服务端主动HTTP POST到业务方的回调地址业务方返回success字符串表示收到。优点是实时性好缺点是业务方需要暴露公网接口并且要处理网络波动。另一种是共享数据库中间表V免签写入支付结果业务系统定时扫描这张表。优点是实现简单内网环境下很稳缺点是有秒级延迟且两套系统共享数据库有耦合风险。实际项目里我建议优先用HTTP推送因为后续如果想对接微服务、消息队列推送方式更贴合体系数据库中间表只适合两个系统都在同一网段并且都归你管的小项目。public function retryCallback() { $list M(callback_log) -where([status 2, next_retry_time [lt, time()]]) -order(id asc) -limit(50) -select(); foreach ($list as $row) { $res $this-httpPost($row[callback_url], $row[request_body]); if ($res success) { M(callback_log)-where([id $row[id]])-save([status 1]); } else { M(callback_log)-where([id $row[id]]) -setInc(retry_count) -save([next_retry_time time() min(3600 * pow(2, $row[retry_count]), 86400)]); } } }注意setInc和save在ThinkPHP中不能放在同一条链式调用里连续操作这是我实际踩过的坑。正确写法是先setInc(retry_count)再单独save()或者直接用原生SQL更新两个字段。退避时间用min(3600 * 2^重试次数, 86400)意思是每次重试间隔翻倍最多不超过一天避免对失效业务方做无休止轰炸。4.4 常见坑重复金额校验、回调时序与日志留痕金额校验必须用字符串比较不能转float这一点在4.1节的bccomp已经提到。再补充几个实战经验回调时序上的坑主要是“先通知后落单”。监控端上报和业务方请求下单这两个动作是并行的服务端收到回调的时候业务方可能还没来得及把订单写进数据库。遇到这种情况服务端不应直接丢弃回调而要把回调内容暂存到一张等待表隔5秒再重试一次。日志留痕是定位所有线上问题的前提。每次回调的完整请求体、业务方返回的原文、验签失败的具体原因都要记录到日志文件。在ThinkPHP里可以这样写\Think\Log::write( json_encode([url $url, body file_get_contents(php://input)]), \Think\Log::INFO );注意微信支付投诉回调、支付宝回调这些官方通知有“验证网关”机制返回非success会触发官方多次重试但自建回调系统没有这个兜底所有可靠性都得自己扛。所以“收到即记录落库再处理”是底线。5. 验证回调链路与兜底技巧从模拟通知到余额复核整个系统搭建完成后不能直接拿真钱测试先用模拟数据把链路走通再逐步切换到小额真实支付。5.1 用HTTP工具模拟回调验证业务系统业务系统接入完成后先用Postman或curl向业务方的回调地址手动发送一份模拟请求验签、幂等、业务处理都能在这个环节暴露问题。curl -X POST http://your-server.com/index.php/Api/Notify/index \ -d mch_id10001mch_order_noTEST2024001amount0.01pay_type1sign计算后的签名签名要按约定算法先算好填进去不要拿真实回调抓包的数据直接改。这一步重点验证三件事业务方返回体是否为字符串success、该订单第二次通知时是否被幂等拦截、金额不一致时是否返回amount mismatch。5.2 真机端到端验证流程拿一台备用安卓手机装好监控端开启无障碍权限再把支付宝收款码保存到相册或直接显示在屏幕上。下单后扫码支付0.01元观察整个链路监控端收到通知的耗时正常应在1秒内通知文本和截图是否成功上传服务端服务端日志出现支付成功且金额识别无误业务系统收到回调订单状态变为已支付重复通知场景手动把同一条回调再发一次观察不影响业务结果这五步里最容易出问题的是第二步截图上传失败率在部分ROM上会特别高。检查点主要在服务端的日志里看screenshot_upload对应的返回码如果超时占比高就调大监控端上传超时时间。5.3 每日余额对账最后的兜底手段再完善的通知机制也可能漏单任何回调系统最后都要靠对账兜底。轻量做法是每天定时拉取支付宝和微信账单或者在监控端截一张当日收款汇总图人工核对一遍服务端订单表里的金额总和与到账总金额是否一致。我习惯写一段SQL直接比对SELECT DATE_FORMAT(FROM_UNIXTIME(create_time), %Y-%m-%d) AS day, pay_type, COUNT(*) AS order_count, SUM(amount) AS total_amount FROM vpay_order WHERE status 1 GROUP BY day, pay_type;查询结果里total_amount如果与支付宝/微信账单差值超过0.01元就说明当天存在漏回调或重复回调。定位方法也很直接找出对应时间段内status 0的订单再结合监控端的本地日志确认是上报失败还是通知解析失败。还有一个实践技巧值得保留处理这类支付回调系统时调试线上问题要养成随手保存完整通知报文的习惯因为支付平台返回的报文字段顺序、编码格式在不同环境的呈现不一致没有原始报文做对比调签名问题时往往要多花几个小时。本文还有配套的精品资源点击获取
V免签支付回调系统搭建：ThinkPHP服务端与安卓监控端实战
简介V免签支付系统安卓监控端全套源码及视频搭建教程面向具备PHP基础、希望快速实现支付宝/微信免签约收款回调处理的开发者。整套方案围绕Thinkphp框架构建后端服务覆盖支付回调、收款监控、数据统计等核心功能同时提供安卓监控端APK与接口对接方案帮助跳过签约流程直接完成收款通知与业务联动。压缩包共297个文件以class、jar、js、html、css、gif等为主分别对应后端逻辑、第三方依赖库、前端页面和演示图解并额外附带APK安装包、视频教程及环境配置脚本整体大小约34MB。目前已有187人学习浏览。资料中的视频与部署文档从PHP环境搭建、数据库配置、Thinkphp接入到支付平台回调、安全加固逐步拆解既适合独立开发者快速上手也能为已有业务系统集成移动支付提供参考是一份贴近实战、便于对照落地的源码教程。1. V免签在支付链路里补的是哪一段空位做过支付对接的人都清楚微信支付和支付宝的官方API要求必须有商户号、应用AppID和密钥而商户号审批需要营业执照或对公账户。临时环境、个人开发者、企业内部测试平台往往拿不到这套资质但业务又确实需要“用户付了钱服务端立刻知道”的闭环。V免签这套方案就是为这段空位设计的在手机上装一个安卓监控端App通过无障碍服务和通知栏监听捕获支付到账的通知再把结果推给ThinkPHP服务端服务端生成回调给业务系统。它把“支付成功”这件事从安卓端“搬运”到了服务器本质上是在补“收单通知”的缺失。这套链路适合三类人一是刚起步的小团队想先把支付闭环跑通再做商户备案二是给客户做演示、内测、体验版等正式上线再切官方接口三是想研究回调机制、幂等设计和轮询上报的技术人员。需要先说清楚的是生产环境优先走官方支付接口V免签这类方案适合测试和中转合规性要自己把握。接下来我会按服务端部署、安卓监控端、回调对接、链路验证的顺序讲一遍我平时搭这套系统的完整做法。2. 服务端部署ThinkPHP内核下的基础配置与参数选型服务端是整个系统的中枢所有订单状态、设备注册、回调记录都落在这一层。V免签这类系统大多基于老版本ThinkPHP开发最常见的版本是ThinkPHP 3.2.x它在PHP 5.3时代成型拿到新服务器上第一步就是解决运行环境兼容问题。2.1 环境兼容ThinkPHP 3.2在PHP 7.4和PHP 8之间的取舍ThinkPHP 3.2 官方原版只承诺支持PHP 5.3以上版本到PHP 7.0时代就已经出现不少报错。实际部署中我看到最多的问题是mysql_*函数被移除、each()函数在PHP 8.0被删除、create_function()在高版本不可用。社区里有一个专门给ThinkPHP 3.2打PHP 7补丁的分支处理了大部分兼容问题但即使打了补丁PHP 8.1以上的动态属性Deprecation警告仍然会刷屏。我一般建议用PHP 7.4来跑老版本ThinkPHP服务端理由有两点对比项PHP 7.4PHP 8.0each() 等老函数保留但标记废弃已移除动态属性创建正常触发 Deprecation框架自带缓存驱动可直接用部分驱动报错老扩展兼容良好mhash、mcrypt等缺失PHP 7.4 同时兼容了框架老代码和现代语法是运行成本最低的选择。如果你非要用PHP 8记得在入口文件强制关闭所有Deprecation提示并且提前检查代码里是否用了each、eregi、mysql_connect这类函数。2.2 Nginx环境下的站点配置与伪静态规则Web服务器建议选Nginx性能比Apache好配置也直观。站点配置里最核心的是把请求重写到index.php入口文件这一步做不对访问任何路由都会404。server { listen 80; server_name pay.example.com; root /var/www/vpay; index index.php index.html; location / { if (!-e $request_filename) { rewrite ^/(.*)$ /index.php?s$1 last; } } location ~ \.php$ { include fastcgi_params; fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } location ~* \.(sql|log|bak|ini)$ { deny all; } }rewrite ^/(.*)$ /index.php?s$1是ThinkPHP在Nginx下的标准伪静态写法其中$1是原始请求路径框架会通过s参数解析到对应的控制器和方法。后面的location把所有敏感后缀文件直接拒掉避免安装包里的SQL备份或日志文件被公网直接下载。2.3 数据库导入与核心表结构V免签系统依赖几张核心表订单表、设备表、回调记录表。建好数据库后重点检查订单表里的索引设计因为设备端轮询订单状态是高频操作没有索引的话数据量上来之后查询会明显变慢。CREATE TABLE vpay_order ( id int(11) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 平台订单号, mch_order_no varchar(32) NOT NULL COMMENT 业务方订单号, amount decimal(10,2) NOT NULL COMMENT 订单金额, pay_type tinyint(1) NOT NULL DEFAULT 1 COMMENT 1支付宝 2微信, device_no varchar(32) DEFAULT NULL COMMENT 收款设备编号, status tinyint(1) NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已回调, create_time int(11) NOT NULL, pay_time int(11) DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_mch_order (mch_order_no), KEY idx_status_time (status, create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;UNIQUE KEY uk_order_no保证平台单号唯一后续幂等判断依赖这个字段。idx_mch_order方便按业务单号反查排障时最常用到的就是它。idx_status_time是复合索引服务端定时扫描待支付到期订单时用得上。2.4 渠道参数配置应用标识、支付类型与回调地址安装完成后后台管理界面里需要配置的常见参数包括应用AppID、应用密钥、通讯密钥、收款二维码有效期。其中最重要的是“通讯密钥”它是安卓监控端和服务端之间的共享密钥监控端上报支付结果时用它做签名。这个参数不要用默认值建议生成一个32位以上的随机字符串。回调地址则关系到支付成功后服务端把结果通知到哪。这套系统和官方支付回调有一个明显差异支付宝回调、微信支付投诉回调都是平台主动POST给服务器的而V免签是服务器收到安卓端上报后再转发。所以业务系统那边配置的“网页授权回调域名”或“支付回调URL”指向的是V免签服务端的入口地址而不是直接指向你自己的后端。3. 安卓监控端无障碍服务识别支付到账的关键路径安卓监控端是这套系统里技术含量最高的部分。它的职责是盯着支付宝和微信的收银台一旦有收款到账立刻把结果上报服务端。实现方式主要有两种监听通知栏消息以及截屏分析界面。多数方案是两种结合用通知栏做第一触发用截图做二次确认。3.1 监听通知栏AccessibilityService的最小实现通知栏监听是触发最快、准确率较高的方式。支付宝和微信在收款到账时都会弹出通知监控端注册一个无障碍服务在onAccessibilityEvent里拦截TYPE_NOTIFICATION_STATE_CHANGED类型的事件就能拿到通知里的文本内容。class PayMonitorService : AccessibilityService() { override fun onAccessibilityEvent(event: AccessibilityEvent?) { if (event null) return if (event.eventType AccessibilityEvent.TYPE_NOTIFICATION_STATE_CHANGED) { val parcelable event.parcelableData if (parcelable is Notification) { val extras parcelable.extras val title extras?.getCharSequence(Notification.EXTRA_TITLE).toString() val text extras?.getCharSequence(Notification.EXTRA_TEXT).toString() if (isPaymentNotification(title, text)) { reportPayment(title, text) } } } } override fun onInterrupt() {} }EXTRA_TITLE通常对应通知的标题EXTRA_TEXT对应详情内容。这里isPaymentNotification要做的是关键词过滤比如支付宝通知标题含“支付宝”或“收款”微信通知含“微信支付”或“收款到账”过滤通过再触发上报避免普通聊天通知误报。3.2 截图识别确认金额准确性的第二道校验仅靠通知栏文本有个隐患通知内容不完整或者被系统折叠拿不到“收款金额”和“付款人”。到账金额是核心数据一旦解析错造成的后果比丢单严重。因此我习惯在通知命中后再触发一次截屏把当前屏幕截图发给服务端由服务端用OCR识别图片中的金额和商品描述和通知里的金额做交叉校验。高版本安卓上AccessibilityService.takeScreenshot()是系统API不需要额外授权但需要API 30以上。低版本设备有两种常见替代方案用MediaProjection申请屏幕录制权限或者干脆走Root方案直接读帧缓冲。实际选型时看用户设备分布如果你的目标用户都是新手机无障碍截图就够了。if (Build.VERSION.SDK_INT Build.VERSION_CODES.R) { takeScreenshot( Display.DEFAULT_DISPLAY, context.mainExecutor, object : TakeScreenshotCallback { override fun onSuccess(screenshot: ScreenshotResult) { val bitmap screenshot.hardwareBuffer.toBitmap() uploadScreenshot(bitmap) } override fun onFailure(errorCode: Int) { saveFailureEvent(screenshot_failed_$errorCode) } } ) }OCR识别放在服务端做而不是端上原因是安卓端的算力参差不齐Tesseract在低端机上跑一次要好几秒容易把监控线程拖死。服务端收到图片后抠出金额区域再识别速度更快准确率也更稳定。3.3 上报协议与失败补偿断网、被杀进程怎么处理监控端上报接口的调用时机需要注意通知刚到的那一瞬间就上报经常遇到服务端还没准备好订单数据的情况处理不好就是上一秒报了“已支付”下一秒查询订单返回“不存在”。我习惯把上报设计成异步队列先落本地数据库再逐条同步失败的重试交给一个带退避策略的循环。val requestBody JSONObject().apply { put(device_no, deviceNo) put(order_no, currentOrderNo) put(amount, amountText) put(pay_type, if (isAlipay) 1 else 2) put(screenshot_id, screenshotId) put(occur_time, System.currentTimeMillis()) } val signStr $deviceNo$currentOrderNo$amountText$secretKey put(sign, md5(signStr))签名串是把设备号、订单号、金额和密钥拼接后做MD5服务端用同样算法验签。这里有个容易忽略的点拼接的字段顺序一旦定下来就不能改否则升级客户端后所有上报都会验签失败。上报后服务端应返回1表示成功、0表示失败客户端收到非成功响应就进入重试队列最多重试5次间隔分别是1秒、5秒、30秒、5分钟、15分钟。4. 回调业务系统时的验签、幂等与补偿方案监控端上报了支付结果服务端更新订单状态接下来就是最关键的环节把支付结果安全可靠地通知到业务系统。这一层做不好用户付款后迟迟不发货比支付失败更伤体验。4.1 回调数据结构与签名验证流程业务系统收到的回调参数一般包含订单号、金额、支付类型、平台单号和签名。服务端在处理回调之前必须先验签防止伪造通知。这里给出ThinkPHP控制器里的一段验签逻辑public function notify() { $mchKey $this-getMchKey(I(post.mch_id)); $sign I(post.sign); unset($_POST[sign]); ksort($_POST); $signStr urldecode(http_build_query($_POST)) . $mchKey; if (md5($signStr) ! $sign) { exit(sign error); } $orderNo I(post.mch_order_no); $amount I(post.amount); $order M(order)-where([mch_order_no $orderNo])-find(); if (!$order || $order[status] 1) { exit(success); } if (bccomp($order[amount], $amount, 2) ! 0) { exit(amount mismatch); } M(order)-where([id $order[id]])-save([status 1, pay_time time()]); exit(success); }参数说明第3行$mchKey是对应商户的密钥每个接入方应该分配独立密钥。第6行http_build_query把除签名外的所有参数排序拼接再拼上密钥做MD5这是最常见的签名算法。第15行bccomp必须用字符串比较函数直接比较浮点数会被精度问题坑比如数据库存的是 0.10回调传过来是 0.1两者用浮点比较可能通过但遇到 19.99 这类金额则可能出现偏差。4.2 幂等表设计重复通知不会二次发货支付回调天生是“至少要收到一次”的语义网络抖动、业务方重启、消息队列重试都会导致同一个订单被通知多次。如果你只是在回调里判断订单状态会出现一种竞态第一次回调处理中第二次回调又进来了两条并发请求都读到“未处理”然后都执行发货逻辑。正确做法是把“回调通知”本身建成一张独立的流水表用订单号做唯一键CREATE TABLE vpay_callback_log ( id int(11) NOT NULL AUTO_INCREMENT, mch_order_no varchar(32) NOT NULL COMMENT 业务订单号, callback_url varchar(255) NOT NULL, request_body text NOT NULL, response_body text, status tinyint(1) NOT NULL DEFAULT 0 COMMENT 0待通知 1成功 2失败, retry_count tinyint(1) NOT NULL DEFAULT 0, next_retry_time int(11) NOT NULL, create_time int(11) NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_mch_order (mch_order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;uk_mch_order唯一索引保证同一订单只会插入一条回调记录后续所有重复通知都转换成“查询已有记录”而不是重新触发业务逻辑。next_retry_time字段支撑了后面的定时补偿任务扫描条件就是status 2 AND next_retry_time 当前时间。4.3 两种对接方式HTTP推送和中间表拉取业务系统接入方式有两种流派。一种是服务端主动HTTP POST到业务方的回调地址业务方返回success字符串表示收到。优点是实时性好缺点是业务方需要暴露公网接口并且要处理网络波动。另一种是共享数据库中间表V免签写入支付结果业务系统定时扫描这张表。优点是实现简单内网环境下很稳缺点是有秒级延迟且两套系统共享数据库有耦合风险。实际项目里我建议优先用HTTP推送因为后续如果想对接微服务、消息队列推送方式更贴合体系数据库中间表只适合两个系统都在同一网段并且都归你管的小项目。public function retryCallback() { $list M(callback_log) -where([status 2, next_retry_time [lt, time()]]) -order(id asc) -limit(50) -select(); foreach ($list as $row) { $res $this-httpPost($row[callback_url], $row[request_body]); if ($res success) { M(callback_log)-where([id $row[id]])-save([status 1]); } else { M(callback_log)-where([id $row[id]]) -setInc(retry_count) -save([next_retry_time time() min(3600 * pow(2, $row[retry_count]), 86400)]); } } }注意setInc和save在ThinkPHP中不能放在同一条链式调用里连续操作这是我实际踩过的坑。正确写法是先setInc(retry_count)再单独save()或者直接用原生SQL更新两个字段。退避时间用min(3600 * 2^重试次数, 86400)意思是每次重试间隔翻倍最多不超过一天避免对失效业务方做无休止轰炸。4.4 常见坑重复金额校验、回调时序与日志留痕金额校验必须用字符串比较不能转float这一点在4.1节的bccomp已经提到。再补充几个实战经验回调时序上的坑主要是“先通知后落单”。监控端上报和业务方请求下单这两个动作是并行的服务端收到回调的时候业务方可能还没来得及把订单写进数据库。遇到这种情况服务端不应直接丢弃回调而要把回调内容暂存到一张等待表隔5秒再重试一次。日志留痕是定位所有线上问题的前提。每次回调的完整请求体、业务方返回的原文、验签失败的具体原因都要记录到日志文件。在ThinkPHP里可以这样写\Think\Log::write( json_encode([url $url, body file_get_contents(php://input)]), \Think\Log::INFO );注意微信支付投诉回调、支付宝回调这些官方通知有“验证网关”机制返回非success会触发官方多次重试但自建回调系统没有这个兜底所有可靠性都得自己扛。所以“收到即记录落库再处理”是底线。5. 验证回调链路与兜底技巧从模拟通知到余额复核整个系统搭建完成后不能直接拿真钱测试先用模拟数据把链路走通再逐步切换到小额真实支付。5.1 用HTTP工具模拟回调验证业务系统业务系统接入完成后先用Postman或curl向业务方的回调地址手动发送一份模拟请求验签、幂等、业务处理都能在这个环节暴露问题。curl -X POST http://your-server.com/index.php/Api/Notify/index \ -d mch_id10001mch_order_noTEST2024001amount0.01pay_type1sign计算后的签名签名要按约定算法先算好填进去不要拿真实回调抓包的数据直接改。这一步重点验证三件事业务方返回体是否为字符串success、该订单第二次通知时是否被幂等拦截、金额不一致时是否返回amount mismatch。5.2 真机端到端验证流程拿一台备用安卓手机装好监控端开启无障碍权限再把支付宝收款码保存到相册或直接显示在屏幕上。下单后扫码支付0.01元观察整个链路监控端收到通知的耗时正常应在1秒内通知文本和截图是否成功上传服务端服务端日志出现支付成功且金额识别无误业务系统收到回调订单状态变为已支付重复通知场景手动把同一条回调再发一次观察不影响业务结果这五步里最容易出问题的是第二步截图上传失败率在部分ROM上会特别高。检查点主要在服务端的日志里看screenshot_upload对应的返回码如果超时占比高就调大监控端上传超时时间。5.3 每日余额对账最后的兜底手段再完善的通知机制也可能漏单任何回调系统最后都要靠对账兜底。轻量做法是每天定时拉取支付宝和微信账单或者在监控端截一张当日收款汇总图人工核对一遍服务端订单表里的金额总和与到账总金额是否一致。我习惯写一段SQL直接比对SELECT DATE_FORMAT(FROM_UNIXTIME(create_time), %Y-%m-%d) AS day, pay_type, COUNT(*) AS order_count, SUM(amount) AS total_amount FROM vpay_order WHERE status 1 GROUP BY day, pay_type;查询结果里total_amount如果与支付宝/微信账单差值超过0.01元就说明当天存在漏回调或重复回调。定位方法也很直接找出对应时间段内status 0的订单再结合监控端的本地日志确认是上报失败还是通知解析失败。还有一个实践技巧值得保留处理这类支付回调系统时调试线上问题要养成随手保存完整通知报文的习惯因为支付平台返回的报文字段顺序、编码格式在不同环境的呈现不一致没有原始报文做对比调签名问题时往往要多花几个小时。本文还有配套的精品资源点击获取
