简介ARYA云支付1.1Java版是一套基于Java开发的聚合支付源码核心解决支付宝个人码转银行卡、免签支付与多渠道聚合等实际业务需求适合个人开发者、中小团队以及需要快速搭建支付系统的技术人员参考。系统自带完整的搭建教程、部署文档和使用说明目录划分清晰前后端代码齐备。压缩包共包含2000个文件解压后约182.28MB其中以1350个JavaScript脚本、275个HTML页面、145个CSS样式为主配合142个Java核心类、XML配置文件及少量说明文档整体覆盖前端页面、后端逻辑与系统配置。目前已有141人学习下载。开发者可直接阅读完整源码掌握聚合支付接口调用、免签回调处理、安全验证机制以及多支付通道切换等关键实现同时可基于现有工程按业务场景二次开发调整功能模块并重新打包部署是理解支付系统底层设计、提升工程能力的高价值参考。1. 支付源码里的另一条路个码收单加码转卡ARYA云支付 1.1 Java 版拆解支付宝收单接口不是想签就能签的商户资质、费率、结算周期会卡住不少起步团队。做支付系统的圈子里绕过官方签约的免签方案一直在流传“码转卡”就是其中一种用户扫你的个人收款码资金先进你的支付宝系统再把对应款项转给订单归属方。这套 zip 里就是一份 Java 版聚合支付源码——ARYA云支付 1.1后端是 Java管理后台是 Bootstrap 风格界面包里附带搭建教程、部署文档和使用说明。这篇把源码拆开讲码转卡链路怎么落地、异步通知怎么验签、用户扫码后掉单查哪里、二开从哪里下手。适合做聚合收单、代收结算、私域卖货系统的 Java 开发者也适合想研究免签支付原理的人。2. 先看懂通道逻辑码转卡、免签支付与聚合收单的源码结构2.1 三种收单形态为什么有人选“个码免签”做支付对接的人第一步就是选通道形态。我按实际项目里常见的三种路子做一个对比别看都是“扫码付款”接入成本和后续维护完全是三码事。收单形态接入门槛费率与结算典型场景回调成熟度官方扫码支付当面付需要企业资质、完成签约官方费率T1 自动结算正规电商、线下门店官方异步通知文档齐全聚合服务商动态码服务商进件商户逐个审核阶梯费率分润结算多商户 SaaS 平台有官方 API流程偏重个人码免签几乎零门槛走码主账户结算自己处理私域收单、快收通道、码转卡需要自己维护回调与对账状态ARYA 云支付走的是第三行。它的产品逻辑一句话能说清平台方准备一个或多个支付宝个人收款码用户下单后展示码用户扫码付款后资金进入码主账户平台通过某种方式感知到账再把这笔钱在系统里标记为已支付最后统一结算到商户绑定的银行卡。这就是标题里“个码转卡转账”四个字的来源。这套设计的价值在于绕开了签约门槛代价是把本该由官方通道负责的事情全部拉回来自建到账感知、订单状态维护、资金结算、差错处理一个都不能少。源码里最值钱的不是某个炫技算法而是这套“免签收单 转卡结算”的完整闭环。看懂闭环之后不管你是拿它做二开还是只当学习样板都不会迷路。2.2 源码的模块拆解收银台、商户后台、订单引擎、回调服务根据摘要和包里能看到的文件布局这套系统大致由六块组成。我按调用顺序理一遍收银台模块用户端下单页负责创建订单、生成支付宝收款码、轮询订单状态并跳转结果页。这块是用户唯一能看到的部分。商户后台模块管理商户、收款码、结算银行卡、订单查询和账单下载也就是 Bootstrap 那套界面的核心功能区。项目正文里那几个 CSS 文件antui-all.css、style.css、bootstrap.min.css基本能确认后台前端是 Bootstrap 全家桶。支付通道层封装与支付宝的交互包括生成二维码链接、发起转账、处理异步通知。1.1 版本主要对接支付宝聚合能力说的是以后可以横向接微信、银联这些。订单引擎订单创建、状态流转、超时关闭、回调状态更新。这块是支付系统的命根子后面讲状态机时专门展开。结算服务这个是“码转卡”的核心落点把已支付订单汇总按商户维度做转账记录触发银行卡转账并回写结算状态。系统管理管理员登录、操作员权限、字典配置、系统参数、日志查看。2.3 技术栈推演与包目录观感这类 Java 支付项目我拆过好几个ARYA 的技术栈属于典型的中型单体支付系统没有花架子。根据源码文件名和 Java 版本特征推断大概率是这套组合JDK 1.8Spring Boot 或 Spring MVC MyBatisMySQL 5.7 以上存储订单、商户、结算流水Redis 做二维码缓存和短时效数据部分版本也可能没接支付宝官方 SDKalipay-sdk-java负责签名、验签、转账接口调用前端 Bootstrap 3/4后台页面静态资源直接放在包里解压之后你大概率会看到这样的目录骨架具体类名以你手里的 zip 为准但结构大差不差arya-pay/ ├── src/main/java │ ├── controller/ # 收银台、后台、回调三个入口 │ ├── service/ # 订单服务、结算服务、通道服务 │ ├── mapper/ # MyBatis 数据层 │ ├── entity/ # 订单、商户、码、结算流水实体 │ └── config/ # 数据源、拦截器、支付参数配置 ├── src/main/resources │ ├── application.yml # 核心配置数据库、Redis、支付参数 │ ├── mapper/*.xml # SQL 映射 │ └── static/ # 后台静态资源antui、bootstrap 都在这里 ├── docs/ # 搭建教程与部署文档 ├── sql/ │ └── arya_pay.sql # 初始化脚本 └── pom.xml注意一个容易忽略的点项目正文里列出来一堆 bootstrap.min.css 和 style.css 重复项说明打包时前端资源被多次打包进不同目录不代表系统有多个前端。看后台页面的时候认准 static 目录下实际被 admin 模板引用的那套就行。我一般拿到源码先不看业务代码先把静态资源目录和数据库 SQL 过一眼能快速判断这个项目的完整度和作者习惯。这套技术栈选的没什么问题都是支付系统里的常见方案。MyBatis 做订单状态更新时方便写原子 SQLRedis 缓存二维码短链接能抗住用户快速扫码的场景Spring Boot 把配置集中在 application.yml 里也好排查。接下来直接把它跑起来。3. 部署到能跑数据库、配置文件和启动验证3.1 环境准备清单不要一上来就改代码先把运行环境对齐。1.1 版本是偏 Java 8 时代的项目高版本 JDK 经常会遇到反射或字节码层面的兼容问题。环境建议按下面这张表准备组件推荐版本说明JDK1.8.0_2xx以 pom.xml 里 java.version 为准别直接用 JDK 17MySQL5.7 或 8.0注意 8.0 的驱动名和时区参数不一样Redis5.x 以上如果配置里没启用可以暂时不开Maven3.6 以上打 jar/war 包用Nginx1.18 以上用于域名转发回调接口必须要公网可访问这里有个容易翻车的细节如果你用的是 MySQL 8.0驱动类要改成com.mysql.cj.jdbc.Driver而 5.7 时代的老项目里写的是com.mysql.jdbc.Driver。不改的话启动直接报ClassNotFoundException。我一般先把这两个环境的差异确认好再动手省得启动失败后回头猜配置。3.2 导入数据库与初始化配置解压 zip 后在 sql 目录下找到初始化脚本正常情况下一个文件就能建完所有表。导入命令用重定向最省事mysql -u root -p -h 127.0.0.1 --default-character-setutf8mb4 arya_pay.sql导入成功后用 Navicat 或命令行连上去检查至少能看到orders、merchant、pay_code、settlement这几类表。如果缺表或者某个表是空的多半是 SQL 脚本没完整执行重新导一遍。接着改配置文件。老版本项目可能是jdbc.properties新一点的是application.yml两个文件的作用一样把下面这段按实际情况替换spring: datasource: url: jdbc:mysql://127.0.0.1:3306/arya_pay?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.jdbc.Driver redis: host: 127.0.0.1 port: 6379 password: pay: alipay: appId: 你的支付宝应用APPID privateKey: 你的应用私钥 alipayPublicKey: 支付宝公钥注意不是应用公钥 notifyUrl: http://你的域名/notify/alipay returnUrl: http://你的域名/result这里把三个最关键的参数讲透privateKey是你自己生成并保存在本地的应用私钥用来给请求签名alipayPublicKey是支付宝公钥用来验签支付宝推送的通知。这两个搞反是最常见的低级错误我见过不下五次。notifyUrl是支付宝异步通知的接收地址必须填公网能直接访问到的地址而且要是 http/https 可以正常请求到的域名不能填 IP 加端口支付宝校验时对这种地址大概率直接拒绝。本地联调阶段往往会在这里卡住后文避坑章节单独说。3.3 启动后端服务配置改完先 Maven 打包再启动。如果是 Spring Boot 项目标准流程这样走# 在项目根目录执行跳过测试减少意外失败 mvn clean package -DskipTests # 进入target目录启动 cd target nohup java -jar arya-pay-1.1.0.jar --spring.profiles.activeprod /logs/pay.log 21 # 确认服务起来了 tail -f /logs/pay.log如果是传统的 war 包项目就把打出来的 war 文件扔进 Tomcat 的 webapps 目录启动 Tomcat 后看日志。判断启动成功的标志不是“端口起来了”而是日志里出现数据源初始化完成、MyBatis mapper 加载这些关键行。登录后台时要注意这类系统后台路径一般是/admin或/manager初始账号密码在部署文档里有登录后第一件事改密码。不要跳过这一步支付系统的后台如果保持默认口令相当于把资金流水公示给全网。后台登录进去后先建一个测试商户配置一个收款码生成一笔测试订单能跑到这一步说明部署链路基本通了。3.4 验证“下单→展示码→回调”的最小闭环跑通的最短验证路径是商户后台创建收款码关联一个支付宝个人码。复制收银台地址模拟用户看到下单页。用自己的支付宝扫生成的码真实付一笔 0.1 元。回到商户后台看订单状态是否从“待支付”变成“已支付”。如果第 4 步状态没变先别急着怀疑业务代码按日志优先排查。打开支付日志搜索订单号看有没有收到支付宝的异步通知记录。多数情况是通知根本没到你服务这个坑下面有专门一节。走到这一步你已经把整套源码从静态代码变成了运行中的系统接下来的核心是业务链路里的细节。4. 核心业务流订单状态机、支付宝异步通知与码转卡结算4.1 从下单到支付的状态流转支付系统的代码可以写得乱但订单状态不能模糊。ARYA 这类免签方案的订单状态机比官方支付多一个“待结算”状态因为资金进的是码主账户需要系统主动触发转账。我按通用设计还原一下这张订单表的状态设计CREATE TABLE orders ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 平台订单号, merchant_id bigint(20) NOT NULL COMMENT 归属商户, amount decimal(10,2) NOT NULL COMMENT 订单金额, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已结算 3已关闭 4结算失败, channel varchar(16) DEFAULT alipay COMMENT 支付渠道, callback_time datetime DEFAULT NULL COMMENT 回调时间, pay_time datetime DEFAULT NULL COMMENT 实际支付时间, create_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;整个生命周期链路是这样的用户下单后状态是 0等待支付宝异步通知收到通知并验签通过后状态变成 1结算服务扫描已支付订单发起转账成功后状态变成 2如果转账失败状态进入 4需要人工介入或自动重试。这里有一个容易踩坑的设计点状态变更必须用条件更新不能先查出来在 Java 内存里改完再 update。原因很简单支付回调引擎是不定线程数的同一笔订单可能同时被通知回调、管理员手动标记、定时补偿任务读取。用无条件 update 一定会出现状态覆盖。正确写法应该是UPDATE orders SET status 1 WHERE order_no ? AND status 0这种带前置条件的原子操作扫到的行数为 0 就说明订单已经被处理过直接返回成功。4.2 支付宝异步通知的验签与幂等处理支付宝异步通知是整个系统中风险最集中的入口。100% 的支付系统安全问题都出在“无条件信任通知内容”这个环节。通知参数可以伪造签名是不能伪造的所以第一步永远是对参数验签PostMapping(/notify/alipay) public String handleAlipayNotify(HttpServletRequest request) throws AlipaySignatureException { // 把支付宝异步通知的参数取出来转成 Map MapString, String params new HashMap(); MapString, String[] requestParams request.getParameterMap(); for (String name : requestParams.keySet()) { String[] values requestParams.get(name); params.put(name, String.join(,, values)); } // 验签RSA2 算法必须保持一致公钥必须用支付宝公钥 boolean signVerified AlipaySignature.rsaCheckV1(params, alipayPublicKey, UTF-8, RSA2); if (!signVerified) { log.error(异步通知验签失败直接拒绝{}, params); return failure; } // 只处理成功状态的交易其他状态直接 ACK避免重复计算 String tradeStatus params.get(trade_status); if (!TRADE_SUCCESS.equals(tradeStatus)) { return success; } // 幂等更新只有待支付状态才能变更为已支付 String orderNo params.get(out_trade_no); int updated orderMapper.updatePaidIfPaying(orderNo); if (updated 0) { orderMapper.updateCallbackInfo(orderNo, params.get(trade_no), new Date()); } return success; }参数说明rsaCheckV1的第一个参数是支付宝推送的原始参数集合签名校验算法必须用RSA2这是目前支付宝强制要求的。out_trade_no是平台生成的订单号trade_no是支付宝交易号回调信息里两个都要存后续对账靠支付宝交易号去找支付宝侧记录。这段代码里最关键的战略性习惯是“先验签、再审状态、再条件更新”这个顺序任何一步不满足都直接返回。支付宝的通知机制很直白你返回success它认为你处理完了返回其他任何字符串都会在接下来的 24 小时内按递增间隔重试最长 7 次。如果业务处理成功但因为代码异常返回了failure支付宝会重推几次而你的幂等逻辑挡住了重复处理这反而是补偿机制在兜底不是坏事。4.3 码转卡结算的记账逻辑订单标记为已支付之后资金还躺在收款码的支付宝账户里要把这笔钱结算给商户绑定的银行卡。这就是“码转卡”的最后一跳。结算服务一般按商户维度做批次汇总避免每单都发起一笔转账。常见的聚合策略是每分钟扫描一次已支付但未结算的订单按商户分组每个商户累加金额生成一条结算流水然后调用支付宝转账接口或者人工打款。转账涉及敏感接口实现上必须保留完整的操作日志public void settleMerchant(Long merchantId) { // 先把可结算订单汇总出来避免转账过程中订单状态变化 ListOrder orders orderMapper.listSettling(merchantId); BigDecimal totalAmount orders.stream() .map(Order::getAmount) .reduce(BigDecimal.ZERO, BigDecimal::add); // 生成结算流水状态为处理中 Settlement settlement new Settlement(); settlement.setMerchantId(merchantId); settlement.setAmount(totalAmount); settlement.setStatus(0); settlementMapper.insert(settlement); // 调用转账渠道逐笔处理失败时单独标记 boolean transferResult transferService.transfer(merchantId, totalAmount); if (transferResult) { settlementMapper.markSuccess(settlement.getId()); orderMapper.markSettled(merchantId); } else { settlementMapper.markFailed(settlement.getId()); // 失败流水保留等重试或人工核对 } }这里强调一个“先记账、再转账”的顺序。很多二开者上来就调转账转账成功后才想起来写流水一旦渠道返回超时但实际到账流水缺失导致对账永远对不平。正确的做法是转账前先生成一条待确认流水转账结果再回写流水状态这样不管渠道返回什么账面上都有迹可循。5. 上线排查避坑回调丢失、掉单、重复通知与数据错乱5.1 支付宝异步通知就是进不来现象用户扫码付款成功了订单状态一直是待支付后台日志里根本搜不到notify相关的访问记录。原因最常见的有三个。第一notifyUrl填的是内网地址或 IP 地址支付宝的服务器根本路由不到第二服务器防火墙或云安全组没放行对应端口第三填了域名但该域名还没备案或没解析到当前服务器支付宝请求直接超时放弃。解决先把notifyUrl改成一个浏览器能直接访问的线上地址再用 curl 模拟一个 POST 请求测通接口确认接口能返回success。测试时注意支付宝要求接口的响应时间不能太长业务处理逻辑超过 3 秒会被判定超时真正的回调进来时只会更慢所以回调入口只做状态更新不做重活。5.2 钱扣了但系统没单掉单怎么查现象用户反馈“我明明付款了订单还是待支付”而且日志里确实没有收到支付宝通知。原因这类掉单大多出在异步通知丢失。支付宝异步通知依赖公网链路偶尔会有网络抖动导致通知没送达这不常见也不是小概率跑量之后总会遇到。另外一个隐蔽原因是用户在扫码之后支付环境异常比如支付宝内部拦截了收银台的跳转导致回调延迟了很久。解决不要只依赖被动通知。我给一个基本兜底方案定期轮询支付宝订单查询接口超过 30 秒还处于待支付的订单主动向支付宝发起查询查到已支付就直接更新本地状态。代码留在最后一章。掉单问题的根因是“被动等待”而生产环境必须把主动性握在自己手里。5.3 重复通知导致金额重复上账现象订单只付了一笔后台却出现了两条支付流水或者商户余额增加了两倍。原因支付宝异步通知有重推机制如果业务代码先查订单状态再在 Java 层判断“已支付就返回”两个线程同时进来就能绕过判断。另外人工手动补单和自动补偿任务同时跑也会重复处理。解决全部改成条件更新。任何状态流转都用UPDATE ... WHERE status 期望的旧状态这种原子操作更新行数为 0 说明已被处理直接忽略。这条规则写进代码评审标准里比任何分布式锁都便宜可靠。5.4 数据库中文乱码和订单时间差八小时现象后台商户名称显示乱码订单创建时间比实际时间早或晚 8 个小时。原因数据库表和连接串的字符集不一致。老项目初始化脚本里常用utf8而 MySQL 8.0 默认是utf8mb4两者在 emoji 和生僻字场景下表现完全不同。时间错乱则是因为 JDBC 连接串没有指定时区服务器时区与实际时区偏差。解决连接串里显式加上characterEncodingutf8mb4和serverTimezoneAsia/Shanghai同时把表和库的字符集统一改为utf8mb4。改完还要重启服务因为连接池在启动时就已经按旧参数建立了连接。别用 Navicat 里的可视化删改直接执行一条 ALTER 语句全库转换最干净。5.5 验签一直提示失败现象日志里明确打印出验签失败回调参数看起来正常但rsaCheckV1就是不通过。原因九成是公钥配置错误。很多人把“应用公钥”填到了alipayPublicKey的位置但验签必须用“支付宝公钥”这两个完全不一样。支付宝开放平台后台的应用信息页面里能看到两个公钥一个是你上传的应用公钥一个是支付宝生成的支付宝公钥复制机会不小。解决找回正确的支付宝公钥后先把配置里填错的公钥删掉重启服务后重新用真实回调测试一次。同时确认算法字符串是RSA2而不是RSA这两个算法对应不同的签名方式验签时写错会 100% 失败。如果回调参数里有中文且服务端用ISO-8859-1解析了也会造成签名原文不一致控制台启动后第一件事就是把请求编码确认成UTF-8。6. 二开进阶上线前先加一个主动查单补偿任务接支付通道的人有个共识回调是补丁主动查询才是主路径。ARYA 源码里即使已经有掉单补偿我也建议按自己的业务节奏重写一版。下面这个定时任务用 Spring 的Scheduled实现60 秒扫一次超过 30 秒仍然待支付的订单逐个向支付宝发起交易查询Component public class OrderCompensateTask { private static final int PAYING_TIMEOUT_SECONDS 30; private static final int QUERY_BATCH_SIZE 50; Scheduled(fixedDelay 60000) public void compensatePayingOrders() { // 只捞状态为待支付、且创建时间超过30秒的单子避免刚下单就被查询 ListOrder payingOrders orderMapper.listTimeoutPaying(PAYING_TIMEOUT_SECONDS, QUERY_BATCH_SIZE); if (payingOrders.isEmpty()) { return; } for (Order order : payingOrders) { try { // 调用支付宝查询接口查真实交易状态 AlipayTradeQueryResponse response alipayService.query(order.getOrderNo()); if (response null || !response.isSuccess()) { continue; } // 查到已支付就做幂等更新不理会重复处理 if (TRADE_SUCCESS.equals(response.getTradeStatus())) { int updated orderMapper.updatePaidIfPaying(order.getOrderNo()); if (updated 0) { log.info(补偿任务将订单置为已支付{}, order.getOrderNo()); } } } catch (Exception e) { // 单笔查询失败不影响整批吞掉异常留着下次扫描再试 log.error(补偿查询异常订单号{}, order.getOrderNo(), e); } } } }参数说明PAYING_TIMEOUT_SECONDS设 30 秒是留出用户实际扫码支付的时间太短会导致用户还没付完就被查一次产生无意义的渠道调用QUERY_BATCH_SIZE限制每批扫描数量防止积压大量异常订单时把线程全部占满。频率上 60 秒一次已经足够支付系统的补偿任务不是越频繁越好支付宝接口有流量限制频繁轮询还可能触发风控。日志是这类的灵魂。你会依赖日志来判断是“查询失败”还是“查询成功但更新失败”所以每笔都要打订单号。生产环境里把日志级别调到 INFO单独输出到独立文件方便出问题时按订单号 grep。补上这段之后整条链路才算闭合主动查询兜底被动回调回调正常时秒级完成状态更新回调丢失时最多晚 60 秒被补偿任务捞回来。两套机制同时工作互相掩护这就是支付系统没有玄学、只有兜底的真实写照。那年我上线第一个支付通道凌晨一点接到商户电话说钱扣了订单还没到账翻日志查了一整夜最后发现是回调网络抖动丢了一个通知数据库里那笔单子就那么干躺着。从那以后我接任何支付通道第一件事就是先把主动查单任务写好再谈上线。ARYA 这套源码跑起来之后你也先把这条兜底加上。希望帮到你。本文还有配套的精品资源点击获取