简介ARYA云支付1.1 Java版是一套面向个人开发者、中小商户与支付系统学习者的聚合支付源码解决了支付宝个人二维码转银行卡、免签支付以及多支付渠道统一接入的核心需求适合作为自建支付网关或二次开发的参考基线。压缩包共含2000个文件解压后约182.28MB其中1350个JS负责前端支付交互与异步逻辑275个HTML与145个CSS搭建用户页面142个Java承载核心业务与渠道对接另有XML、Properties、Shell等用于配置与服务部署各层级文件划分清晰便于按模块阅读与修改。包内提供完整搭建教程、部署文档与使用说明配合全套源码可帮助开发者快速跑通扫码转账、免签回调、多渠道聚合等关键流程也能根据自身业务调整鉴权、路由与安全策略实现个性化支付方案。目前已有141人学习下载适合具备Java Web基础并想深入支付交易链路的开发者入手研究。1. 免费源码只是入场券ARYA云支付Java版真正难在把个码收款跑到稳做独立开发的这些年我接过不少小微商户的收银需求。最尴尬的一关是支付企业资质没下来官方商户接口签不了个人收款码倒是能收钱但收完没有回调、订单还挂在“待支付”顾客催、商户骂只能手动对账。ARYA云支付1.1这类Java版免签聚合支付源码解决的正是这段断掉的链路——用个人收款码收钱由监听端把到账消息实时上报给Java服务端服务端负责匹配订单、驱动回调再把资金通过转卡归集到银行卡。它适合两类人想快速把支付流程跑起来的Java开发者以及正在用个人码收款、被重复劳动折磨的小团队。不过源码只是入场券真正决定能用多久的是订单匹配、回调重试和转卡调度这几段代码。这篇文章从原理、代码讲到部署避坑照着搭一套不是难事。2. 拆开ARYA云支付1.1个码收款、到账匹配与转卡转账的运作原理在写代码之前得先把这套方案“凭什么能跑”讲清楚。很多新手把zip解压、启动工程之后就以为完事了结果扫码付款后订单纹丝不动绕了一圈发现是原理没吃透。2.1 免签支付的三个关键机制个码、到账识别与转卡链路先拆名词。个码是支付宝个人收款码不是商户码。两者的本质差别在于商户码挂在签约商户号下有官方异步通知能回调到你的服务器个人码只有一个收款动作支付宝不会主动告诉你“谁付了多少钱”所以到账感知必须自己解决。免签就是绕开官方签约通道直接收款代价是官方接口的能力——回调、退款、对账——全部要自己补。转卡转账是资金归集的最后一步个人码收到的钱沉淀在支付宝余额里需要通过转账动作归集到银行卡这一步做不好前面收得再顺也是空的。典型的完整时序是这样的用户在业务系统创建订单Java服务端生成一张收款二维码。用户用支付宝扫码在手机上输入金额完成付款。挂在收款手机上的监听端App捕捉到账语音或系统通知把“到账xx元”的消息POST到Java服务端。Java服务端验签后按“金额时间窗口”匹配到具体订单把订单状态从待支付推进到已支付。服务端异步回调业务系统通知发货或放行。定时任务把支付宝余额转入银行卡完成资金归集。整个链路里最不可控的不是服务端代码而是第3步的监听端。手机系统会杀后台进程、通知会被折叠、网络会抖动这一层不解决服务端写得再漂亮也会掉单。我习惯把监听端叫作黑匣子——你永远不知道它下一秒还活不活着所以服务端必须有心跳超时、掉线告警、订单转人工核对这套兜底。2.2 Java版的技术选型为什么是Spring Boot Redis 轮询任务这类源码多数基于Spring Boot原因不外乎三点单体可运维一个jar包扔到服务器上就能跑生态成熟接支付宝、微信这类渠道都有现成轮子招人容易Java工程师对这套组合最熟。配套的组件我也拆一下。MySQL负责订单、回调记录、账户流水这类强事务数据必须要能回滚这个场景单库单表就够不要一上来就上分布式事务。Redis做三件事回调幂等setIfAbsent防止重复通知、订单尾数占用标记防止金额匹配错配、热订单缓存减少数据库压力。任务调度用Quartz或XXL-Job主要跑两类任务扫描超时未支付订单、扫描回调失败待重试记录。ORM层面MyBatis Plus用得多它可以根据实体类生成建表SQL等于把表结构定义放在Java代码里工程迁移时少背一份文档——这个特性对快速接手支付源码的人特别友好。有些方案会顺手把消息队列RocketMQ/Kafka引入进来我一般不建议小团队这么做。单体阶段回调记录表完全可以当消息表用定时任务扫表投递等订单量真到了每天几千单再上MQ也不迟。工程模块划分上常见的做法是四层adapter放外部对接监听端协议、转卡通道service放订单和回调核心逻辑job放定时任务common放常量与工具。这种分层没什么新意但便宜好用——问题出现时按层排查比按业务排查快得多。再补充一句转卡链路的实现边界。常见做法分两种半自动系统算好应转金额、生成转账清单由财务在手机端确认执行全自动通过用户授权的自动代付通道完成。对个人码方案来说半自动更常见因为全自动涉及更高等级的风控要求。转卡要有独立的流水记录和失败池不能和订单主链路混在同一张表里否则对账时你会疯掉。3. 从订单到回调二维码创建、金额匹配与通知重试的落地代码原理立住了接下来进入能抄作业的部分。这一章覆盖从用户下单到业务方收到回调通知的最小闭环每一段代码都标注了关键参数和为什么要这样写。3.1 创建订单与生成收款二维码金额尾数策略是关键个人码二维码本身不能像商户码那样直接带金额用户扫码后要手动输入金额所以“金额尾数唯一法”几乎是这类方案的唯一可行解。每笔订单在应付金额基础上加一个分位尾数比如商品100元订单实际应付100.37用户输入这个金额付出去监听端上报100.37服务端就能按金额精确定位到订单。public PayOrder createOrder(CreateOrderRequest request) { // 1. 基础参数校验业务金额必须大于0单笔不超过5万 Preconditions.checkArgument(request.getAmount() 0, amount must be positive); // 2. 尾数策略在 0.01~0.98 分位生成一个未被占用的尾数 int suffix generateUniqueSuffix(request.getAmount()); BigDecimal payAmount request.getAmount() .add(new BigDecimal(suffix).movePointLeft(2)); // 3. 订单号时间戳 6位随机数单体部署够用不依赖雪花算法 String orderNo A System.currentTimeMillis() RandomUtil.randomNumbers(6); // 4. 落库状态置为待支付默认15分钟支付窗口 PayOrder order new PayOrder(); order.setOrderNo(orderNo); order.setBizOrderNo(request.getBizOrderNo()); order.setAmount(payAmount); order.setStatus(OrderStatus.WAIT_PAY.getCode()); order.setExpireTime(LocalDateTime.now().plusMinutes(15)); order.setCallbackUrl(request.getCallbackUrl()); orderMapper.insert(order); // 5. 生成二维码内容带订单参数的跳转地址而不是直接放个人码图片 String qrContent buildQrContent(orderNo, payAmount); order.setQrBase64(QrCodeUtil.generateBase64(qrContent, 300, 300)); return order; }逻辑说明payAmount是“订单应付金额分位尾数”这0.37就是用户扫码后手动输入金额时的识别码。generateUniqueSuffix负责在Redis里标记占用如果当前时间窗口内已经有100.37这个金额在等待支付就换一个尾数这是防止错配的第一道门槛。订单号不用雪花算法是因为单机部署时时钟回拨风险不值得赌时间戳加随机数在小规模下足够唯一。二维码内容不要直接解析用户的个人收款码图片而是生成一个带订单参数的页面或跳转链接用户扫码后看到具体金额再付这样金额尾数才能真正落到支付动作里。关键参数可以参照这张表参数建议值说明单笔金额上限50000个人码大额支付更容易触发渠道风控尾数范围0.01~0.98避开整数金额尾数冲突概率更低支付窗口15分钟超时自动关闭订单窗口越大错配概率越高二维码尺寸300x300打印小票场景建议至少5123.2 到账上报的处理验签、幂等与订单状态推进监听端上报的报文一般是JSON格式字段大致长这样{ type: ALIPAY_RECEIPT, amount: 100.37, channel: ALIPAY_PERSONAL, time: 1712034567890, flowNo: 20240402AABBCC, sign: md5签名串 }服务端接收这段报文的处理逻辑是所有支付源码里最容易被改坏的一段。PostMapping(/api/v1/notify/receipt) public ResultVoid onReceipt(RequestBody ReceiptNotify notify) { // 1. 验签共享密钥防止伪造到账通知 if (!signService.verify(notify, appKey)) { return Result.fail(sign error); } // 2. 幂等同一流水号只能处理一次监听端重推直接返回成功 boolean first redis.setIfAbsent(rc: notify.getFlowNo(), 1, 10, TimeUnit.MINUTES); if (!first) { return Result.ok(duplicated); } // 3. 金额时间窗口匹配订单 PayOrder order orderService.matchOrder(notify.getAmount(), notify.getTime()); if (order null) { // 匹配不到落异常流水表交给对账任务兜底 abnormalFlowService.record(notify); return Result.ok(pending); } // 4. 状态机推进只有待支付能改已支付重复通知不会覆盖 boolean updated orderService.confirmPaid(order.getOrderNo(), notify.getFlowNo()); if (updated) { callbackService.dispatch(order.getOrderNo()); } return Result.ok(); }逻辑说明验签解决“假的到账通知”——上报地址暴露在公网不法分子扫到接口后可以伪造任意金额的到账消息把100元的订单改成已支付来渗漏资金所以签名校验是资金安全底线。幂等解决“监听端重复上报”和“服务端重启后消息重投”两个问题用Redis的setIfAbsent就够了不需要引入分布式锁。matchOrder的匹配条件是金额精确相等、支付时间在订单创建之后的15分钟内、订单状态为待支付按时间最近的一条优先。参数说明幂等key的TTL设为10分钟要大于监听端最大重推间隔matchOrder查不到订单时不要直接丢弃落一张异常流水表否则用户付了款、监听端也上报了服务端却一直匹配不到钱就悬空了。提示监听端上报接口必须走HTTPS否则验签报文在公网传输会被窃听重放这是支付类接口的底线不是可选项。3.3 回调业务系统落库投递与指数退避重试回调是业务系统的命脉。很多新手直接在到账接口里同步调业务方回调这是典型的翻车设计——业务方接口慢支付线程被占住业务方宕机回调直接丢失。正确做法是回调记录落库由任务异步投递。public void dispatch(String orderNo) { PayOrder order orderMapper.selectByOrderNo(orderNo); if (order null || !OrderStatus.PAID.getCode().equals(order.getStatus())) { return; } if (StringUtils.isBlank(order.getCallbackUrl())) { return; } CallbackRecord record new CallbackRecord(); record.setOrderNo(orderNo); record.setUrl(order.getCallbackUrl()); record.setRetryCount(0); record.setMaxRetry(10); record.setNextTime(LocalDateTime.now()); callbackRecordMapper.insert(record); }投递任务逻辑扫描next_time now的记录逐条HTTP POST请求体里带上签名订单号、金额、状态、随机数业务方验签后更新自己的订单。失败时更新last_status并设置next_time now 重试间隔。重试间隔建议按1分钟、5分钟、15分钟、30分钟指数退避最多10次。10次都失败的记录进“人工处理队列”靠钉钉或企业微信机器人告警不能默默躺在那。为什么回调不能同步放在到账接口里还有一个业务方的视角业务方可能同时收到服务端重试和监听端补发的通知两边都带同一订单号时业务方必须按幂等规范处理。所以回调通知体里订单号、金额、状态三个字段必须齐全签名必须可验证否则业务方不敢更新订单。4. 支付状态机与数据库设计把钱和账用表结构钉住支付系统最怕的不是功能少而是账对不上。状态机在Java八股文里常被当成理论考点但在支付场景里它其实就是一张张带前置校验的更新SQL。这一章把表结构和状态流转讲透。4.1 订单表、回调记录表与异常流水表三张表各司其职订单表是核心字段不用贪多够用就行。我的习惯是订单表只存支付相关字段业务字段商品名、用户ID全部由业务方自己维护两边通过biz_order_no关联。CREATE TABLE pay_order ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 支付订单号唯一, biz_order_no VARCHAR(64) NOT NULL COMMENT 业务方订单号, amount DECIMAL(10,2) NOT NULL COMMENT 含尾数的实付金额, pay_channel TINYINT NOT NULL DEFAULT 1 COMMENT 支付渠道1支付宝个人码, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已回调 3已结算 4已关闭 5异常, callback_url VARCHAR(255) NOT NULL DEFAULT COMMENT 业务回调地址, expire_time DATETIME NOT NULL COMMENT 支付过期时间, pay_time DATETIME DEFAULT NULL COMMENT 实际支付时间, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_status_time (status, expire_time) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4 COMMENT 支付订单表;参数说明amount用DECIMAL(10,2)不要用float或double——浮点累计误差在支付账目上是不可接受的读者要是有怀疑自己跑一轮100笔小数相加就知道差别在哪。金额字段存的是“含尾数的实付金额”和监听端上报值做等值比较。状态用TINYINT不用字符串省空间、索引小但代码里必须建常量类避免到处写魔法数字。唯一索引加在order_no而不是id上因为所有查询入口都走order_no这个索引能覆盖绝大多数SQL。回调记录表是掉单问题最重要的证据。每次回调失败的原因都要写进detail字段没有这张表线上掉单只能靠猜。CREATE TABLE pay_callback_record ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 支付订单号, url VARCHAR(255) NOT NULL COMMENT 回调地址, retry_count TINYINT NOT NULL DEFAULT 0 COMMENT 已重试次数, max_retry TINYINT NOT NULL DEFAULT 10 COMMENT 最大重试次数, last_status TINYINT NOT NULL DEFAULT 0 COMMENT 0未发 1成功 2失败, fail_reason VARCHAR(500) NOT NULL DEFAULT COMMENT 最后一次失败原因, next_time DATETIME NOT NULL COMMENT 下次重试时间, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_next_time (next_time, retry_count) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4 COMMENT 回调投递记录表;还有一张异常流水表也叫疑似流水表。当到账上报匹配不到订单时数据落到这里CREATE TABLE pay_abnormal_flow ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, flow_no VARCHAR(64) NOT NULL COMMENT 监听端上报流水号, amount DECIMAL(10,2) NOT NULL COMMENT 上报金额, channel VARCHAR(16) NOT NULL DEFAULT ALIPAY_PERSONAL, notify_time BIGINT NOT NULL COMMENT 上报时间戳, raw_data TEXT COMMENT 原始报文留证据, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待核对 1已匹配 2已退款, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_flow_no (flow_no) ) ENGINE InnoDB DEFAULT CHARSET utf8mb4 COMMENT 异常到账流水;这张表存在的意义是“后悔药”——当金额匹配失败时钱已经到了你的支付宝订单却还挂着没有这张表就没有追溯线索。flow_no加唯一索引既防重也方便后续人工核对。4.2 状态机的流转规则从待支付到已结算的分支状态流转用大白话讲就四条分支WAIT_PAY(0) → PAID(1)到账上报匹配成功唯一入口PAID(1) → CALLBACK_SUCCESS(2)业务方收到回调并返回成功WAIT_PAY(0) → CLOSED(4)超时或用户取消不经过PAIDPAID(1) → ABNORMAL(5)回调重试超过上限或转卡失败超过N次进人工处理状态推进的代码写法核心是带前置条件的更新int rows orderMapper.confirmPaid(orderNo, payTime, flowNo);对应的SQL是UPDATE pay_order SET status 1, pay_time #{payTime} WHERE order_no #{orderNo} AND status 0。注意这个AND status 0——两个线程同时confirmPaid只有先执行的那条SQL能更新1行后执行的返回0行直接丢弃。这就是状态机防并发最朴素也最可靠的手段比锁、比分布式锁都简单。为什么要卡得这么死因为一旦两个线程都把状态改成了已支付后续结算和退款会全部错乱而且这种错乱在账面上极难追踪。支付系统的并发场景里多一次状态校验就是少一个线上事故这个钱不能省。5. 部署上线与避坑掉单、错配、限额的三类真实现场部署本身不难难的是上线之后各种意想不到的掉链子。这一章先给最小部署清单再写三类我实际踩过的坑每条按现象、原因、解决来写。5.1 最小可运行部署与启动检查一套能跑起来的最小环境大概是这样组件版本建议用途JDK8或11Java服务端运行环境MySQL5.7订单与流水存储Redis3.2幂等与尾数占用监听端Android 8到账上报服务器2核4G单体部署启动顺序先Redis再MySQL最后Java应用。应用启动后不要急着收款先看日志里有没有监听端上线的心跳记录然后用监听端手动发送一笔1分钱测试消息确认验签和金额匹配都通最后再走一笔真实支付。这个检查顺序能帮你把“环境问题”和“代码问题”分开别等到用户付款后才发现回调地址填错了。这里最常见的坑是java环境配置JDK版本和pom里的编译级别不一致启动直接报UnsupportedClassVersionError。先把JAVA_HOME和PATH统一再排查别的不要一上来就怀疑代码。5.2 避坑凌晨四点的掉单现象白天一切正常凌晨订单大量pending第二天早上又自动恢复。原因监听端Android手机被系统杀进程或者省电策略把通知监听停了。服务端日志里能看到心跳断档从00:30到07:00没有一条上报这个断档就是证据。解决监听端配置为前台服务锁后台运行服务端维护心跳表超过2分钟没有心跳就触发告警订单侧加“待人工确认”开关心跳恢复后自动重新拉取未匹配订单。血泪经验是不要相信手机厂商的“永不清理”选项定期检查心跳曲线才是正路。5.3 避坑金额尾数冲突导致错配现象两笔订单同时创建一个100.37一个101.37用户A付了100.37订单却匹配到了101.37上A的订单还挂着。原因尾数生成只做了随机没做占用检查或者两个订单金额相近、时间窗口重叠。解决生成尾数时用Redis setIfAbsent做占用标记key设计成suffix:{amount}:{suffix}TTL设为15分钟匹配时按“金额精确相等时间最近”排序再限定状态一定是待支付。如果冲突无法避免让异常流水和疑似订单一起进人工池。金额尾数冲突是小概率但一旦发生就是连环错配宁可让订单没匹配上也不要在两个订单之间犹豫。5.4 避坑转卡限额与风控校验现象转卡任务提示“当前交易金额超限”或“操作失败”订单状态卡在已支付资金没法归集。原因支付宝个人账户对单笔或单日转出有限额银行卡侧对单笔入账也有上限频繁小额转卡到同一张卡反而更容易触发风控校验。解决转卡调度设置分批上限比如单笔不超过5万失败单进“待人工处理”池而不是自动重试转卡目标支持多卡轮换每天对账时核对“余额-订单总额-转卡总额”三者是否自洽。最容易踩的坑是把转卡失败静默重试重试100次还是失败钱在余额里账却对不上。6. 进阶把免签支付服务做到可运维、可持续支付服务不是能收钱就完了还要能持续收钱。这一章讲两个足够实用的进阶方向。6.1 多监听端轮询与动态切换两台手机做监听端服务端按心跳和负载分配订单尾数区间。心跳健康的标准是30秒一次超过90秒没心跳就把该设备的通知权重降为0订单自动路由到另一台。这样做既能避免单点故障也能降低同一设备连续小额收款被风控的概率。实现上只需要给监听上报加上deviceIdmatchOrder时按deviceId分组做金额尾数隔离两边的尾数生成互不干扰。6.2 我每天必做的三项验证每天早上九点前跑一遍对账任务把昨日已支付订单总额、监听端到账上报总金额、支付宝余额变动三者做一次核对差额超过1元就要查异常流水表。第二件事是抽查一笔昨天的订单从订单表、回调记录、账户流水三个视角走一遍确认状态和时间都对得上。第三件事是看回调重试队列有没有积压超过10条的当天处理掉。这三个动作加起来十分钟能挡住绝大多数“用户付了钱订单没动静”的客诉。做支付这个方向我最大的教训是把“玄学”挂在嘴边的时间太多了。掉单查不出来99%不是玄学而是心跳表没看、回调重试队列没查、状态机更新没校验前置状态。把这三个习惯坚持下来稳定性是能睡出来的。希望帮到你。本文还有配套的精品资源点击获取