简介ARYA云支付1.1 Java版是一套面向开发者的聚合支付源码聚焦支付宝个人码转卡、免签支付及多渠道统一收款等典型场景适合有Java基础的技术人员研究或二次开发。压缩包共2000个文件大小约182.28MB其中1350个JS、275个HTML、145个CSS构成前端界面和交互逻辑142个Java类与68个XML文件支撑后端服务、支付路由与配置管理另有properties、shell脚本、JSON等辅助文件以及PDF、DOCX格式的搭建部署文档前端包含多个样式库和页面模板后端涉及支付网关、订单管理、异步通知等模块。整体目录清晰按前端、后端、配置和文档分区便于快速定位支付流程、安全校验和回调处理等核心代码。目前已有141人学习下载可直接在本地环境运行测试也可参考源码理解免签支付的实现原理并根据业务需求调整支付渠道或对接方式随包附带的搭建文档可帮助快速完成本地部署与联调。1. 支付源码拆解ARYA云支付1.1Java版个人码转卡与聚合支付的真实玩法支付源码我拆过不少但ARYA云支付1.1Java版算是一套把“支付宝个人码”和“银行卡转账”串起来的聚合支付系统。它内置了后台管理、订单轮询、异步回调等模块适合有两台服务器、想自己搭一套收银台的开发者。核心解决三件事把多平台支付聚合到一个入口用个人码接收订单并转成卡转账以及通过回调通知完成后续业务。接下来我会按拆包顺序讲清楚它怎么跑起来以及哪些地方容易翻车。2. 系统架构与支付链路从扫码到收款的状态流转2.1 模块划分Java后端、Bootstrap管理端与通知服务ARYA云支付1.1的源码整体是典型的前后端分离单体应用。后端用Java编写负责支付路由、订单管理、回调接收和对账前端管理界面从文件名来看是antui-all.css、bootstrap.min.css和style.css的组合说明后台是基于Bootstrap 3的风格。如果你拆开zip会看到几个逻辑模块支付核心包、渠道适配包、管理后台包以及一套doc格式的文档目录。模块之间大致是业务层调用ChannelAdapter接口发起支付ChannelAdapter负责把订单二维码返回给前端用户扫完码后支付宝异步通知到达回调接口回调接口验签后触发订单状态流转。这套结构的好处是新增渠道时你不需要改Controller层只要实现ChannelAdapter统一接口然后在适配器里写自己渠道的逻辑即可。实际项目里最常见的是循环依赖和事务边界问题。比如订单服务和回调服务在同一个事务里查了两次OrderMapper第一次是未支付第二次刚被别人更新就会出现状态碾压。所以我在看这个源码时会重点看支付回调入口是否用了乐观锁或状态判断以及有没有独立的回调处理服务。2.2 订单状态机与支付宝回调幂等处理ARYA云支付的订单状态做了一个标准的状态机从CREATE已创建、PAYING支付中、PAID已支付到CLOSED已关闭。这是聚合支付系统的命门。状态机的核心是用数据库行锁或version字段防重而不是业务代码里简单if判断。下面这段是常见写法如果源码里少了这部分二次开发时就要自己补上// OrderStateEnum public enum OrderStateEnum { CREATE(0, 已创建), PAYING(1, 支付中), PAID(2, 已支付), CLOSED(3, 已关闭); private final int state; private final String desc; } // 回调处理核心逻辑 public boolean handlePayNotify(String orderNo, String channelTxnId, BigDecimal amount) { // 1. 先根据渠道订单号查本地订单 Order order orderMapper.selectByOrderNo(orderNo); if (order null) { log.error(回调未命中订单: {}, orderNo); return false; } // 2. 校验金额 if (order.getAmount().compareTo(amount) ! 0) { log.error(订单金额不一致: {} vs {}, order.getAmount(), amount); return false; } // 3. 幂等只有CREATE和PAYING状态才允许更新 int rows orderMapper.updateStateIfAllowed(orderNo, Arrays.asList(OrderStateEnum.CREATE.state, OrderStateEnum.PAYING.state), OrderStateEnum.PAID.state, channelTxnId); if (rows 1) { // 发MQ或业务回调给上游系统 notifyUpstream(order); return true; } // 4. 如果更新失败说明已处理过返回成功给渠道避免重复通知 log.info(重复回调忽略: {}, orderNo); return true; }逻辑说明第一步查单是为了拿到订单状态、金额和渠道。第二步金额校验是硬校验支付宝回调里的金额是不可信字段必须和本地订单比对防止改包。第三步是把状态从“未支付”改成“已支付”的唯一出口用SQL的update ... where state in (...)受影响行数是1才继续天然幂等。第四步对重复通知要返回“成功”让渠道停止重发否则支付宝会按频率重试。参数说明上方updateStateIfAllowed对应的SQL大概是这样UPDATE pay_order SET state #{targetState}, channel_txn_id #{channelTxnId}, pay_time now() WHERE order_no #{orderNo} AND state IN (#{allowedStates})这里allowedStates是CREATE和PAYING。为什么不直接stateCREATE因为用户可能从渠道A发起后切到渠道B订单变成PAYING这时候回调不能再拒绝。允许PAYING是为了兼容多通道同时唤起的情况。2.3 定时任务驱动的关单与自动退款支付系统最怕“挂单”用户扫了码没付或者付了没回调回来。ARYA云支付1.1里关单逻辑通常是启动一个ScheduledThreadPool每隔30秒扫一遍PAYING状态且超过15分钟的订单把它们改成CLOSED。这里有三个坑坑一是扫单时间不能太短。个人码支付场景下用户从举起手机到支付完成通常需要30秒到2分钟如果5分钟就关单容易出现误杀。如果你跑的是自己的场景我一般建议把15分钟改成30分钟至少给足扫码时间。坑二是扫单范围必须带渠道标识。如果系统接入了多个渠道不能只按状态和创建时间扫还要按渠道去判断因为不同渠道的付款等待期不一样。支付宝一般5分钟没支付就关闭微信可以到10分钟所以渠道适配包里会配置一个expireMinutes。坑三是退款补偿。订单超时关单但用户其实已经付了回调还没到就会出现关单后回调补进来的情况。ARYA云支付的做法大致是回调里查到订单已经是CLOSED状态且金额一致会先“复活”订单为PAID再发一条差异告警。这种设计虽然会造成对账差异但总比把钱吞了强。如果你二次开发我会建议在此基础上加一个manualReview字段人工确认后再入账。支付系统第二容易出问题的是回调验签。ARYA云支付1.1里验签用的是支付宝官方SDKAlipaySignature.rsaCheckV1这一步不能省。在很多二次开发里验签被注释掉为了本地调试方便但这是生产隐患。哪怕只是内网测试也要把验签逻辑保留否则别人只要拿到你的回调URL就能伪造一笔支付成功通知。另外异步通知的参数里trade_status为TRADE_SUCCESS或TRADE_FINISHED要在代码里区分。很多新手只判断TRADE_SUCCESSTRADE_FINISHED不收导致全额退款订单一直处于“支付中”后台对账不知不觉多了一堆差异单。3. 本地部署实战JDK、数据库与配置文件的一次性通过3.1 环境准备与初始化SQL如果你要跑这套ARYA云支付1.1Java版我建议用这套环境JDK 1.8或OpenJDK 8、Maven 3.6、MySQL 5.7、Redis 5.x。为什么不用JDK 11因为很多老支付SDK的依赖在JDK 11下会有模块化报错省得踩坑直接用JDK 8最稳。数据库导入很简单把源码目录下的sql文件夹里的init_db.sql导入即可。下面是表结构里最关键的一张pay_orderCREATE TABLE pay_order ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 业务订单号, channel varchar(16) NOT NULL COMMENT 渠道编码如ALI, state tinyint(4) NOT NULL DEFAULT 0 COMMENT 0创建 1支付中 2已支付 3已关闭, amount decimal(10,2) NOT NULL COMMENT 订单金额, channel_txn_id varchar(64) DEFAULT NULL COMMENT 渠道流水号, create_time datetime NOT NULL, pay_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT支付订单表;注意这里的uk_order_no唯一索引很重要它保证业务订单号不重复。支付宝回调可能乱序到达如果两个线程同时插入同单号数据库会让一个成功一个失败然后业务层用失败回滚来保证数据一致。3.2 配置项逐项说明数据库、Redis、回调地址源码里的application.yml是资源配置集中地我贴一个精简模板server: port: 8088 spring: datasource: url: jdbc:mysql://localhost:3306/arya_pay?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password redis: host: localhost port: 6379 database: 0 pay: ali: app-id: 202100xxxxxxxx private-key: MIIE........ alipay-public-key: MIIB.... notify-url: http://your-domain.com/api/pay/ali/notify max-wait-minutes: 30参数说明pay.ali.app-id支付宝开放平台创建的应用APPID。如果渠道模式走的是开放平台这个值要填真实ID如果走纯个码模式这里可以留空由渠道适配器决定。private-key和alipay-public-key一对RSA2密钥线上环境从支付宝后台生成本地调试可以用支付宝官方工具生成。notify-url回调地址必须能被公网访问到而且必须是HTTP/HTTPS可访问不能带query string。支付宝会往这个地址发POST通知。max-wait-minutes订单可等待的分钟数上面第2章说的关单时间就是这里控制。3.3 打包启动与自检验证打包命令mvn clean package -DskipTests如果源码里带了打包插件会在target/目录下生成arya-pay.jar。然后启动nohup java -jar target/arya-pay.jar --spring.profiles.activeprod logs/console.out 21 这里指定prod环境会加载application-prod.yml里面通常配置了线上的数据库和回调地址。我一般不直接改application.yml而是新建一个application-local.yml再通过spring.profiles.active切换。这样能避免误改线上配置。自检验证分三步浏览器访问http://localhost:8088/如果看到Bootstrap风格的登录页说明前端资源和静态CSS加载正常。调用下单接口POST /api/pay/create参数带上orderNo、amount、channelALI返回里应该包含一个二维码图片地址。用支付宝扫码后等几秒到后台“订单管理”里看订单状态是否从“支付中”变成“已支付”。如果第2步返回5xx优先看控制台日志重点看Caused by后面的异常链。我见过最多的是数据库时区问题serverTimezoneAsia/Shanghai少配了导致日期字段全少了8小时。3.4 Nginx反向代理与HTTPS配置由于支付宝回调要求公网HTTPS生产环境一般会在前面加Nginx。我在部署ARYA云支付时习惯把Tomcat端口隐藏只暴露Nginx的443server { listen 443 ssl; server_name pay.example.com; ssl_certificate /etc/nginx/ssl/pay.crt; ssl_certificate_key /etc/nginx/ssl/pay.key; location / { proxy_pass http://127.0.0.1:8088; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }说明proxy_set_header Host必须带否则Spring MVC生成的绝对路径会变成内网IP。X-Real-IP是给后端记录用户来源IP用的聚合支付的风控逻辑依赖它。4. 二次开发指南新支付渠道接入与订单扩展4.1 渠道接入抽象层设计ARYA云支付1.1的扩展点在PayChannelAdapter接口。我拆包后会先找这个接口所有的第三方支付都是实现它。接口大概长这样public interface PayChannelAdapter { String getChannelCode(); // 创建支付单返回二维码内容 PayOrderDto createPay(PayCreateRequest req); // 处理渠道回调返回验签结果 boolean handleNotify(String rawParams, HttpServletRequest request); }你新加一个“微信支付”渠道要做的就是新建一个WechatPayAdapter然后把它注入到ChannelAdapterRouter里路由里通过getChannelCode()匹配。不需要动Controller和Service这是它设计上比较干净的地方。有个容易被忽略的点创建支付单返回的是二维码内容不是二维码图片。ARYA云支付会把内容写进响应体由前端用qrcode.js生成图片。如果你二次开发在接口返回里要区分qrContent和qrImg不要混。4.2 订单超时关单与自动对账这块在源码里是一个任务包叫ScheduledTask。默认是每隔30秒扫一次超时单。如果你要改间隔建议通过配置项注入而不是硬编码。比如Scheduled(cron ${pay.task.close-cron:0/30 * * * * ?}) public void closeExpiredOrders() { ListOrder pendingOrders orderMapper.selectExpired(PAYING.state); for (Order order : pendingOrders) { orderMapper.changeState(order.getOrderNo(), PAYING.state, CLOSED.state); } }参数说明close-cron允许你在application.yml里覆盖默认每30秒扫描一次。注意定时任务本身要加分布式锁如果有多台实例同时跑会出现订单状态错乱。我在本地试验时只跑单实例但生产环境一定要加Redis锁否则一个订单会被两个实例同时关闭。对账任务同理一般是每天早上2点跑一次拉取支付宝或微信的日账单和本地订单做比对。ARYA云支付的对账结果会在后台“差异单列表”里标红你要人工点击“确认”或“忽略”。这个交互虽然原始但很实用。4.3 把ARYA云支付嵌入自己的Spring Boot项目如果你不想单独跑一套支付系统而是想在现有商城项目里集成常见做法是独立部署用HTTP接口对接。ARYA云支付对外提供3个核心接口POST /api/pay/create下单返回二维码POST /api/pay/query查单POST /api/pay/close关单商家系统只需要在你自己的支付页里调用这三个接口即可。举例RestTemplate restTemplate new RestTemplate(); JSONObject req new JSONObject(); req.put(orderNo, M202607100001); req.put(amount, 19900); req.put(channel, ALI); ResponseEntityJSONObject resp restTemplate.postForEntity( http://localhost:8088/api/pay/create, req, JSONObject.class );这里amount我建议用“分”作为单位避免浮点计算误差。ARYA云支付如果用的“元”你在对接层除以100再传。另外反向对接接口要做签名校验。ARYA云支付1.1有没有内置签名我不确定但我会在网关层统一加签名过滤器防止别人拿你的下单接口刷单。加一个OncePerRequestFilter从Header取appId和sign校验通过才放行验签逻辑用简单的MD5或HMAC都行。5. 踩坑与排查回调丢失、重复入账、日志黑洞5.1 回调丢失公网地址和异步通知的“打架”现象扫码支付成功后数据库订单一直停在“支付中”十分钟后变成“已关闭”。原因支付宝异步通知没送到或者送到了但被拦截。最常见的是回调地址写在局域网里或者服务器安全组没放开443/8088端口。还有一种玄学支付宝回调需要返回“success”如果业务代码里返回了其他字符支付宝会认为通知失败反复重试直到放弃。解决先把notify-url里的域名在服务器上先curl一遍确认能通再在回调入口第一行写日志打印全部参数。我一般会在日志里打notifyParams事后拿支付宝文档对照。支付这种强依赖回调的系统日志比什么工具都管用。5.2 重复入账幂等没做好后台账目乱了现象用户支付一次后台出现了两笔订单甚至金额翻倍。原因回调被重试或Webhook被消息中间件重放而你的回调方法没有唯一约束。虽然数据库有uk_order_no但如果回调代码先查询再更新两次回调并发时都查到未支付然后都执行更新就出问题。解决方案就是第2章里的updateStateIfAllowed用update where state in (...)来原子更新而不是select后再update。解决检查回调方法必须把“状态变更”和“业务通知”放在不同事务里。ARYA云支付如果用了Transactional要特别注意事务边界发送MQ或HTTP通知不能放在事务内否则事务回滚会把通知也撤销。我比较倾向的做法是用TransactionSynchronizationManager.registerSynchronization在事务提交后发通知这样即使事务回滚通知不会发。5.3 个码转卡被风控小额高频被限制现象某个账号收了十几笔几块钱的订单突然支付宝提示交易受限二维码不能用了。原因个人收款码本身是给日常小额收款用的不是给高频支付通道用的。你如果拿它做代理收单一天几十笔触发风控模型的概率极高。解决合规的方式是引导用户配置支付宝商户号走正式的聚合支付接口。ARYA云支付1.1的源码里有渠道配置可以通过后台把ALI渠道的代理改成商户号模式。如果只是技术演示可以限制单渠道每日成功率比如在ChannelAdapter里加一个今日订单数阈值超过就直接拒绝下单。5.4 启动失败依赖冲突和版本不对齐现象mvn spring-boot:run启动时报NoSuchMethodError或ClassNotFoundException多见于支付宝SDK和Spring Boot版本不匹配。原因支付宝老版本SDK依赖了commons-lang3的旧版Spring Boot 2.x默认引入的是新版方法签名变了。解决用mvn dependency:tree查看依赖冲突在pom.xml里对冲突的依赖用exclusions排除掉。我在ARYA云支付1.1里就遇到过一次它的alipay-sdk-java依赖的是commons-logging1.2而我工程里是jcl-over-slf4j启动时日志打不出来加一行exclusions就解决了。5.5 回调验签失败公钥配置反了现象支付宝回调进来后日志提示java.security.SignatureException: Signature verification failed。原因把支付宝公钥填成了应用私钥。在支付宝开放平台后台你需要复制的是“支付宝公钥”不是应用公钥。很多新手在这块翻车因为两个名字太像。解决在支付宝后台“开放密钥”页面分别取出应用公钥、应用私钥、支付宝公钥。在源码配置里private-key填应用私钥alipay-public-key填支付宝公钥。填反了就会验签失败。另注意密钥是PKCS8格式的私钥有的SDK要PKCS1如果不兼容用工具转换一下。6. 调试验证用内网穿透和模拟回调把支付流程跑通最后我要说的不是部署而是日常调试里最有用的一个组合内网穿透 模拟回调。本地开发时支付宝回调没法打到你localhost所以最顺的方案是用cpolar或natapp之类的工具把本地8088端口暴露成一个临时域名然后把这个域名填到notify-url里。natapp -authtoken你的token -localport8088然后你会得到一个类似http://xxx.natapp.cc的公网地址把这个地址拼上/api/pay/ali/notify填到后台配置。这样每次提交代码后支付宝的异步通知就会直接打到本地调试断点能跟上省去“改代码-打包-传服务器-看日志”的循环。但也别高兴太早。内网穿透的域名经常会变一变支付宝那边的回调就404了。所以更稳的做法是使用Postman模拟回调。先用下单接口创建一个订单拿到订单号然后直接把支付宝的回调参数手工组装成POST请求打到你本地的/api/pay/ali/notify。curl -X POST http://localhost:8088/api/pay/ali/notify \ -H Content-Type: application/x-www-form-urlencoded \ -d order_noM202607100001trade_statusTRADE_SUCCESStotal_amount199.00signxxxxxxxx因为验签逻辑开着你手工造的sign肯定验不过。我一般会准备两套配置本地开发环境把验签开关临时关掉测试环境保持开启。关掉验签只适合本地联调一旦上了测试服务器必须开回来。这个教训是我有一次忘了开结果线上回调全部验签失败后台全是未支付单只能靠手动重新同步支付宝流水补救。从那以后我每次改完ARYA云支付回调逻辑都会先跑一遍Postman模拟回调再开内网穿透做一次真实扫码最后才提交代码。流程虽多但能省下半夜查日志的力气。希望帮到你。本文还有配套的精品资源点击获取