企业官网建设流程全解析

Jeepay开源支付系统实战：微信支付、支付宝聚合与支付回调闭环怎么跑通

【免费下载链接】jeepayJeepay是一套适合互联网企业使用的开源支付系统，支持多渠道服务商和普通商户模式。已对接微信支付，支付宝，云闪付官方接口，支持聚合码支付。项目地址: https://gitcode.com/GitHub_Trending/je/jeepay

Jeepay（计全支付）是一套面向互联网企业的开源支付系统。当你的业务要同时接入微信支付、支付宝、云闪付，还要管理商户、应用和回调通知时，它把这些环节整合成一套可自建的支付底座。核心能力是一个统一下单接口：请求进来，直接返回可唤起支付的参数。

一、先建立心智模型：一张图看懂系统

Jeepay 后端拆成三个独立服务，共享同一个 MySQL 库：支付网关（jeepay-payment，9216 端口）负责真实交易；运营平台（jeepay-manager，9217）负责商户、渠道、应用这些配置；商户系统（jeepay-merchant，9218）给商户查订单、看通知。消息队列负责把"订单成功"这个事件从网关异步送到商户系统。

一次请求的完整路径如下：

记住这个方向：钱的状态由渠道回调驱动，订单状态更新在网关内完成，商户通知永远走 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.yml）：

spring: datasource: url: jdbc:mysql://mysql:3306/jeepaydb?useUnicode=true&characterEncoding=utf-8&useSSL=false 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