Jeepay开源支付系统实战微信支付、支付宝聚合与支付回调闭环怎么跑通【免费下载链接】jeepayJeepay是一套适合互联网企业使用的开源支付系统支持多渠道服务商和普通商户模式。已对接微信支付支付宝云闪付官方接口支持聚合码支付。项目地址: https://gitcode.com/GitHub_Trending/je/jeepayJeepay计全支付是一套面向互联网企业的开源支付系统。当你的业务要同时接入微信支付、支付宝、云闪付还要管理商户、应用和回调通知时它把这些环节整合成一套可自建的支付底座。核心能力是一个统一下单接口请求进来直接返回可唤起支付的参数。一、先建立心智模型一张图看懂系统Jeepay 后端拆成三个独立服务共享同一个 MySQL 库支付网关jeepay-payment9216 端口负责真实交易运营平台jeepay-manager9217负责商户、渠道、应用这些配置商户系统jeepay-merchant9218给商户查订单、看通知。消息队列负责把订单成功这个事件从网关异步送到商户系统。一次请求的完整路径如下记住这个方向钱的状态由渠道回调驱动订单状态更新在网关内完成商户通知永远走 MQ 异步链路。后面排查问题先判断你卡在这条链路的哪一段。二、用最短路径把它跑起来环境要求一段说清JDK 17 Spring Boot 3.3.7 后端MySQL 5.7/8.0 存数据Redis 做缓存消息中间件默认 RocketMQ也支持 ActiveMQ、RabbitMQ 和阿里云 RocketMQ。用 Docker Compose 时这些依赖全部随编排文件一起拉起你只需要一台装好 Docker 的服务器。最短路径就是四步git clone https://gitcode.com/GitHub_Trending/je/jeepay cd jeepay mvn clean package -DskipTests docker compose up -d --build起好后验证两件事运营平台入口默认 9227 端口能用 jeepay / jeepay123 登录docker compose ps里 payment、manager、merchant 三个服务都是 Up 状态。端口映射、默认账号和常用命令都写在 docs/deploy/compose.md如果你更习惯裸机部署可以看 Shell 脚本部署。三、跟练一次完整走通一个核心业务选支付订单全流程做跟练按四步走每步都有明确验证点。第一步发起统一下单。向网关的/api/pay/unifiedOrder发签名请求带上 appId、mchOrderNo、wayCode比如 ali_bar和 notifyUrl。入口在 UnifiedOrderController。你应该看到返回码成功且 payData 里有二维码或唤起参数库里订单记录状态为支付中。如果返回不支持的支付方式说明 wayCode 对应的通道没在运营平台开启。第二步路由选择。网关先校验 wayCode 存在再交给对应渠道的支付服务自动分类条码auto_bar会根据 authCode 前缀反推是微信还是支付宝。这一步验证的是通道配置——去运营平台的支付通道管理里确认接口证书商户号、密钥、证书已填且通道已启用否则请求会停在渠道交互前。第三步第三方交互。渠道服务调起微信/支付宝用户真实付款。验证点支付渠道后台能看到这笔交易且返回的渠道订单号后续会落到本地订单的 channelOrderId 字段。第四步异步通知闭环。渠道回调打到网关的/api/pay/notify/{ifCode}见 ChannelNoticeController网关验签后把订单从支付中更新为成功随后 PayMchNotifyService 落一条通知记录并投递 MQ商户系统消费后带签名 POST 你的 notifyUrl。你应该依次看到网关日志出现订单通知完成、通知记录表里该订单状态推进到成功、你的回调接口收到带 sign 参数的请求。验签逻辑可直接参考 JeepayKit 里的签名工具方法。四、真正影响功能的几处配置只列四处改错任何一处系统都起不来或跑不通。数据源三个服务各自独立一份如 conf/merchant/application.ymlspring: datasource: url: jdbc:mysql://mysql:3306/jeepaydb?useUnicodetruecharacterEncodingutf-8useSSLfalse username: root容器内主机名是 mysql裸机部署要换成你实际的地址和库名 jeepaydb。Redis 按服务分库库号写死在配置里不要乱改导致三个服务串号spring: data: redis: database: 2 # 1库运营平台 2库商户系统 3库支付网关消息队列厂商开关在根配置里指定必须和实际部署的 MQ 一致isys: mq: vender: rocketMQ rocketmq: name-server: 127.0.0.1:9876注意 rocketmq 配置段必须放在 yml 根目录而不是 spring 下这是 devCommons 通用配置 里明确注释过的坑。内存缓存开关网关默认开启配置内存缓存网关地址、商户应用、服务商配置开启后要求 MQ 广播模式正常单机求稳可以直接关掉改为每次查库isys: cache-config: true五、从能用到好管2~3 个进阶场景多应用接入。一个商户下可以挂多个应用每个应用有独立 appId 和 appSecret签名互相隔离。运营平台上给同一商户创建第二个应用用它单独下单验证互不影响即可。适合同一商户、多套系统各自接入的场景。支付成功自动分账。下单时指定自动分账模式后订单确认成功会先把分账状态置为等待再投递一条延迟 80 秒的分账 MQ 消息见 PayOrderProcessService。你在商户系统里维护分账接收方和比例之后每笔订单按配置自动拆分分账结果可在分账记录页追溯。通知与订单的兜底监控。网关内置了一组定时任务超时未支付订单自动关单、支付结果掉单重查、通知失败重发见 jeepay-payment/task 目录。上线后你不需要自建重试系统只需定期看通知记录表里是否堆积通知中状态堆积了说明渠道或你的回调地址有问题。六、踩坑点与自查清单现象下单报不支持的支付方式或渠道直接返回签名错误。原因wayCode 对应通道未在运营平台启用或接口证书商户号/密钥/证书填错。处理去支付通道管理核对证书与开关改完后再发一笔测试单不要怀疑代码。现象用户已付款订单一直停留在支付中。原因渠道异步回调地址不可达——没配 HTTPS 或 notify 域名解析不到网关。处理检查域名 HTTPS 配置参考 docs/deploy/https.md在网关日志里搜支付回调确认请求是否到达到达再往下查验签。现象订单成功了但商户回调接口收不到通知。原因RocketMQ 没起来或通知消息发出后你的 notifyUrl 不可访问导致重发耗尽。处理先确认 MQ 进程和 topic 消费正常再查通知记录表的 notifyCount 与状态最后用 curl 直接测你的回调地址。现象改了 conf 下的 yml 不生效。原因配置在容器启动时加载改文件不会热生效。处理执行docker compose restart service重启对应服务若切换了 MQ 厂商还要同步改 docker-compose.yml 和对应服务 pom 里的依赖。更细的排查思路见 docs/deploy/troubleshooting.md。写在最后Jeepay 的价值在于把多商户、多应用、多渠道、回调重试这些支付系统里最琐碎的部分做成了可运行的开源实现你拿到手的不是一组 demo而是一套能直接承接真实交易的底座。想继续深入建议从 docs/project-structure.md 读起了解模块边界再看 docs/features.md 的功能清单最后落到 jeepay-payment 的 channel 目录——每个渠道的下单、查单、退款、回调实现都按统一接口拆开读懂一个渠道其余的也就通了。【免费下载链接】jeepayJeepay是一套适合互联网企业使用的开源支付系统支持多渠道服务商和普通商户模式。已对接微信支付支付宝云闪付官方接口支持聚合码支付。项目地址: https://gitcode.com/GitHub_Trending/je/jeepay创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
