# Jeepay: a self-hosted payment platform for the Chinese market

> An LGPL-licensed Java payment system covering merchant and provider models, aggregate QR payment and multi-application access, built on Spring Boot with a Vue admin front end that lives in its own repository.

**jeequan/jeepay** — Jeepay是一套适合互联网企业使用的开源支付系统，支持多渠道服务商和普通商户模式。已对接微信支付，支付宝，云闪付官方接口，支持聚合码支付。

- Repository: https://github.com/jeequan/jeepay
- Website: https://www.jeequan.com
- Stars: 6,406 · Forks: 2,022
- Language: Java
- License: LGPL-3.0
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/jeequan-jeepay

## What the project set out to be

Jeepay describes itself as an open source payment system for internet businesses, supporting four shapes of use: a plain merchant model, a multi-channel service provider model, aggregate QR payment, and multi-merchant multi-application access. Channels already integrated include WeChat Pay, Alipay and Cloud QuickPass, the last of which is the cross-bank QR standard that UnionPay promotes.

The stated audience is narrower than the word platform usually implies. The README lists who it suits: teams that want independent control over the payment flow, the merchant system, channel configuration and callback notifications rather than being locked to a hosted service. Teams running a provider model across many merchants and channels. Teams that plan to do substantial secondary development and want a clear architecture and complete documentation as a starting point. And teams that need Docker or shell one-click deployment, distribution and a switchable message queue.

The metadata adds context the README does not spell out in English: Java, LGPL-3.0, 6388 stars, 2018 forks, 46 open issues, last pushed 2026-09-22, with the homepage at jeequan.com. The topic list is only `jeepay` and `xxpay`, which refers to the project's former name. The README states that development continues under the original XxPay team, and the related search phrases for this project include XxPay along with DaxPay, IJPay and Yansongda Pay, which are the other names you will meet when researching Chinese open source payment systems.

## A fixed stack with pinned versions

The README publishes a version table rather than leaving you to infer it, and that is the most useful single artefact in the file. The backend is Spring Boot 3.3.7 on JDK 17 with Spring Security, the front end is Ant Design Vue, and the message queue can be RocketMQ, ActiveMQ or RabbitMQ.

The dependency table goes further and names versions: Redis 3.2.8 or newer, MySQL 5.7.x or 8.0 or newer, Ant Design Vue 4.2.6, MyBatis-Plus 3.4.2, WxJava 4.6.0 as the WeChat Java SDK, and Hutool 5.8.26. A stack this specific is a signal in itself: this is a system whose payment channel integrations have been built and tested against those exact library versions, and the version history shows what happens when they move.

The repository tree mirrors that architecture as a Maven multi-module build. `jeepay-core/` holds the shared kernel, `jeepay-service/` the business services, `jeepay-payment/` the channel-facing payment module, `jeepay-manager/` the admin console backend, `jeepay-merchant/` the merchant-facing backend, `jeepay-components/` the pluggable pieces including the MQ abstraction, and `jeepay-z-codegen/` the code generator. `libs/` and `conf/` hold shared libraries and configuration, and there are `version.md` and `upgrade.md` files at the root for tracking releases and upgrade notes. A `CLAUDE.md` at the root is a recent addition aimed at AI-assisted contribution.

## Three deployment routes and where each fits

The deployment section is organised as a table, and the routing is sensible. A shell script installer targets clean CentOS, Anolis, Ubuntu or Debian servers. Docker Compose is aimed at local and test environments where you want the full cluster including the front end. A one-click install for the BaoTa panel, at version 9.2.0 or newer, comes with its own compose file at `docker-compose.baota.yml`. And teams integrating with internal infrastructure are told to supply their own MySQL, Redis and MQ, adjust `conf/`, then build with Maven.

The compose file itself is worth reading before you run anything, and its opening comments are a usage manual in miniature:

```bash
docker compose up
docker compose up -d
docker compose up --build
docker compose up --force-recreate
docker compose up --build --force-recreate
```

It brings up MySQL on a fixed host port with a healthcheck, then RocketMQ's name server with a reduced development heap and its own healthcheck. Images default to a Huawei Cloud SWR public registry rather than Docker Hub, which the README explains as zero-configuration access from inside China. SQL initialisation is mounted as two files, an init script and a patch script, so a first deployment gets a complete table structure rather than an empty schema.

One detail in the compose file is easy to miss. The front end is a separate repository, and the compose file expects `jeepay-ui` as a sibling directory, with `.env.example` exposing a single `UI_BASE_DIR` setting to override it. The default image references read as:

```yaml
image: ${MYSQL_IMAGE:-swr.cn-south-1.myhuaweicloud.com/jeepay/mysql:8}
```

Deployments also need a domain and HTTPS, per the project's own HTTPS guide, and the README points at a troubleshooting page for when something fails.

## What the last two releases fixed

Only two release tags are published, V3.2.0 in April 2026 and V3.2.9 in May 2026, and their content is more useful than a feature list would be.

V3.2.0 was largely a Docker deployment story. It completed the one-command Compose path so MySQL, Redis, RocketMQ, three backend services and three front ends start as a stack. It upgraded RocketMQ Server to 5.3.1 to fix a broker start-up NPE, and added a full health check chain from MySQL through Redis, the name server, the broker, the Java services and finally the UI. Database initialisation was folded into the init and patch SQL files so the schema is complete on first run. The base image moved to a Java 17 JRE and a healthcheck was added. There was also a named volume permission fix for RocketMQ, which runs as a different uid inside the container.

On the framework side, the RocketMQ Spring Boot starter moved from 2.2.0 to 2.3.5, Spring Boot 3 auto-configuration registration was completed, and a new environment post-processor supplies default RocketMQ configuration as a fallback. The cashier front end was moved from Vue 2 and vue-cli to Vue 3 and Vite so it matches the manager and merchant apps, and the Docker build moved to Node 20 LTS.

V3.2.9 in May 2026 is the one to read if you handle callbacks. It hardened authorization callback state parsing against malformed values that could trigger a null pointer or an array out of bounds, and it added cross-checks on business fields in asynchronous notifications, specifically out_trade_no, app_id and total_amount, to eliminate mis-payment risk from signature collisions in multi-merchant or cross-order scenarios. The release recommends redeploying the payment image on affected installations. That is the kind of fix that tells you where a payment system actually lives or dies.

## The hosted service the project points you toward

Part of the README is not documentation but a sales page. There is a section for an official hosted service, aimed at merchants and platforms without a payment licence or without channel resources, offering aggregated access to WeChat, Alipay and UnionPay channels, account management, settlement and reconciliation, and after-sales support. The feature it leads with is full revenue splitting for platform businesses that need profit sharing or collection on behalf of others.

This is worth naming plainly when you are evaluating the repository. The hosted offering and the open source system are related but separate things, and the README says the hosted route exists for people who explicitly do not want to self-host. If you are reading this to decide whether to build on Jeepay, that section tells you what the commercial incentive is, and by extension where the paid feature development is likely to land.

The same section is also a small quality signal in the project's favour, because it means the maintainers have a business attached to the code rather than treating an abandoned repository as an outcome. The repository is not archived and the last push was 2026-09-22.

Two smaller things sit alongside it. An AI integration assistant repository is linked from the README, gathering the signing traps, field casing rules and channel selection details that assistants otherwise get wrong, and usable as plain documentation if you are not using an assistant at all. SDKs exist for Java and Python, with a PHP integration demo, and the Java SDK lives in its own repository.

## Licence and what to check before you commit

The licence is LGPL-3.0, and for a payment system that most teams intend to modify and self-host, this is the single most consequential fact after the channel coverage.

LGPL is copyleft scoped to the library boundary. Self-hosting it as a service and modifying it is possible, and the project clearly expects that, given the whole point is running your own payment stack. What LGPL does oblige you to do depends on how you distribute: if you ship the software itself, the modified library source has obligations attached, and linking patterns matter. That is a question for whoever handles your licence obligations, not for a README, and it is worth settling before you build a commercial product on this rather than after.

The second thing to check is documentation depth, which the README addresses extensively. It links a quick start, a development guide, a channel integration guide, an online deployment guide, an interface reference and a FAQ, plus in-repository deployment guides for shell, Compose, BaoTa, HTTPS and troubleshooting, a features and interface market page, and a project structure page.

The third is editorial rather than technical, but it is a real quality signal: the GitHub repository description misspells Alipay's name, and the README body names the same three channels correctly. A payment system whose documentation is machine-translated in places will still need someone on your team who reads the channel's own specification. The third-party channel APIs, not this repository, are where the hard integration problems live.

## Conclusion

Jeepay is aimed at teams who want to run the payment layer themselves rather than rent a channel, and the parts of it that matter are concrete: a fixed stack, three deployment routes, a working Docker Compose stack, and a release history that fixes real integration bugs rather than announcing features. The decision you are actually making is about licensing and market fit. LGPL-3.0 lets you modify and self-host it, which is what most integrators want, but it is a copyleft licence and your obligations depend on how you link. The channel coverage is built around WeChat Pay, Alipay and Cloud QuickPass, which makes it a poor fit outside that market. Read the deploy docs under `docs/deploy/`, start with Docker Compose locally, and confirm your licence position before you build a product on top of it.

## FAQ

### What licence does Jeepay use and can I modify it for a commercial product?

The repository is licensed LGPL-3.0 and the project is built for teams that self-host and do secondary development. Your obligations depend on whether and how you distribute the software, since LGPL is copyleft at the library boundary. Settle that with whoever owns licensing compliance at your organisation before building on it.

### Which payment channels does Jeepay already support?

The README names WeChat Pay, Alipay and Cloud QuickPass as the integrated mainstream channels. On the stack side it pins WxJava 4.6.0 as the WeChat Java SDK, and the hosted service section also lists UnionPay among the channels aggregated there.

### What is the difference between the merchant model and the provider model?

Both are listed among the four supported scenarios. The provider model is aimed at platforms managing many merchants across many channels, with split payment capability, while the plain merchant model serves a business accepting payments for itself. Aggregate QR payment and multi-merchant multi-application access are the other two supported shapes.

### Where does the Jeepay front end live?

In a separate repository, jeepay-ui. The Docker Compose file expects that project as a sibling directory, and `.env.example` exposes `UI_BASE_DIR` so you can point it somewhere else. The UI is Ant Design Vue, and V3.2.0 moved the cashier from Vue 2 and vue-cli to Vue 3 and Vite to match the other front ends.

## Sources

- [jeequan/jeepay on GitHub](https://github.com/jeequan/jeepay)
- [License: LGPL-3.0](https://github.com/jeequan/jeepay/blob/master/LICENSE)
- [Project website](https://www.jeequan.com)
- [README](https://github.com/jeequan/jeepay/blob/master/README.md)
- [Releases](https://github.com/jeequan/jeepay/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jeequan-jeepay