DaxPay: an open source payment platform built around isolated channel apps

A payment platform for service providers and merchants

DaxPay is a free, open source payment management system. The README describes the open source build as the core of the platform, released under GNU LGPL v3.0 or later, providing the core capabilities of payment, refund and transfer, aimed at payment service providers, multi-merchant platforms and cross-border business teams.

That audience statement is the most important line in the README, because it says what the project is not. It is not a checkout page for a single shop. It is infrastructure for organisations that route money on behalf of many merchants, and the whole design follows from that.

The commercial loop is listed in one line: payment, refund, transfer, query, callback, synchronisation, close, merchant notification, with support for full and partial refunds. A complete transaction lifecycle is a different requirement from a single pay button, and it is where the operational weight of a payment platform sits.

There is also a documented management surface. The project provides a visual interface for management, with an operator side and a merchant side, and the README's source table lists separate repositories for the Web management front end, the Java and Go channel sub-applications, and an H5 gateway for PC and mobile.

The stated principle is decoupling: business systems integrate against a single unified HTTP standard protocol to reach Alipay, WeChat, UnionPay and similar payment methods, and all third party SDKs are isolated into independently deployed channel sub-applications so that integration, upgrades and scaling do not interfere with each other.

The main application orchestrates, the sub-applications integrate

The architecture is described as a layered design with main application orchestration and sub-application integration, and the README calls it the core design of the system.

The orchestration layer is the main application, dax-pay-open. Its responsibilities are channel declaration, channel routing, payment policy orchestration, CRUD over configuration data, and callback assembly. Critically, the table says it contains no third party SDKs.

The integration layer is the channel sub-applications, channel-one and channel-two. Their job is calling the third party SDKs directly, signing and verifying signatures, and adapting the channel specific protocols. They are deployed independently.

The link between the two layers is a declarative HTTP client based on @HttpExchange, and the README states that the whole link is encrypted in transit with AES-GCM. That combination is the substance of the design: the main application never loads a vendor SDK, so a vendor SDK upgrade cannot break the core, a channel can be run as multiple instances behind a load balancer when its traffic is high, and a channel outage is contained in one sub-application.

The module layout in the repository shows the same separation at the source level. daxpay-platform/ holds the base layer with core contracts, common technical infrastructure, platform capabilities and business services. daxpay-payment/ holds the payment core, split into a domain kernel covering order, refund, synchronisation, callback, notification and routing, plus separate API modules for the unified open API, the operator API, the merchant API and the two mini program APIs. daxpay-channel/ is the routing and orchestration code, daxpay-plugin/ holds the plugin mechanism, daxpay-demo/ is a feature demo module, and daxpay-start/ is the entry point.

Four channels are open, the aggregated ones are not

The payment channel table lists what the open build actually contains. The modules are daxpay-channel-alipay for Alipay with direct connection plus ISV service provider mode, daxpay-channel-wechat for WeChat Pay with direct or service provider mode, daxpay-channel-ums for UnionPay Business with direct connection, and daxpay-channel-douyin for Douyin Pay with direct connection.

The aggregated channels are a separate matter. The README states that aggregated channels, listing Lakala, Haike Rongtong, Dougong, Leshua, Suixingfu, Hema Pay, Adapay, Fuiou and YeePay among them, belong to a commercial extension package carried by the dax-pay-channel-two sub-application, with details in the version and pricing list on the documentation site. The repository description in Chinese similarly lists Alipay, WeChat, Haike and Leshua as supported channels, which describes the full product rather than the open build.

That distinction is the single most important thing for an evaluator. If your business needs an acquiring aggregator rather than a direct merchant relationship, the channel you need may be the one that is not in this repository.

The three client applications are similarly split. The operator and merchant Web management front ends are open source repositories, as are the Java and Go channel sub-applications and the H5 gateway for PC and mobile. The operator, merchant and cashier mini programs are listed as commercial extension packages.

There is also a demo environment with operator and merchant sites and demonstration accounts, with the warning that the data is reset regularly and that no real business data or sensitive information should be entered, and that the seeded local account and initial password are in the startup log and should be changed after the first login.

RSA signing, AES-GCM transport and dual nonce replay protection

The security section describes several layers, and one of them is unusual enough to be worth singling out.

Interface signature protection: the open payment API uses RSA with SHA256withRSA for mutual verification along the whole chain, and the core entry point aspect intercepts uniformly. Field level encryption: sensitive fields such as channel keys and API credentials are transparently encrypted with AES-256-GCM, with key rotation supported, so a database dump cannot be decrypted. Transport encryption between the main application and the channel sub-applications is AES-GCM throughout, and in production the keys are required to come from environment variables.

Then there is the dual nonce anti-replay mechanism, which combines a one-time nonce issued by the management side with a merchant nonceStr on the open API, validated with Redis SETNX and a time window. Two nonces on two sides of the system is not redundant, because the management side and the open API are different trust domains.

Permission handling uses Sa-Token with menu and data isolation, and supports TOTP two-step verification and social login.

The most distinctive item is the production fail-fast check. Before starting, the platform forcibly validates development-mode switches, such as sandbox mode, super administrator access and Swagger, and refuses to start if they are not turned off. That is a specific guard against the classic mistake of shipping a development configuration into production, and the README points at the deployment guide for the details.

The risk controls are also present as a plugin rather than being hard-coded: IP blacklists, overseas IP interception, province and city region lists, pre-payment checks, and records of risk hits. The plugin mechanism itself is SPI based, with the core layer's PayPluginAssistService as the extension point, and a second plugin implements the Easypay protocol so it can interoperate with systems that speak it.

Multi-merchant isolation, UTC timestamps and ten languages

The multi-merchant and service provider model shows up in three places. There is a dual entry point with an operator side and a merchant side, menus and data are isolated by client_code, and merchant data is isolated at row level.

Row level isolation is the detail worth noting. Filtering on a tenant column in the query layer is a common approach, and it fails quietly when one query forgets the filter. An operator-side feature that reads across merchants is exactly where a forgotten predicate becomes a data leak, so a design that isolates at the row level and separates the operator API from the merchant API has fewer single points of failure.

Internationalisation and time zones are handled with support for Chinese, Japanese and Korean plus ten ASEAN languages, and with time fields stored uniformly in UTC. Storing everything in UTC and converting at the edge is the boring, correct choice, and it is worth checking what the project does about the per-merchant timezone setting, since the README mentions the isolation and the UTC storage but not the display layer in the excerpt available here.

Two smaller operational features round out the picture. Deployment isolation between sandbox and production is a global switch, and the startup phase forces it to be aligned, so a sandbox configuration cannot silently carry into a production deployment. And the time zone handling in the container image is set to Asia/Shanghai with the system timezone configured accordingly.

The Docker image runs Java 21 while the docs ask for JDK 25

The runtime requirements table lists JDK 25 or later, Spring Boot 4.1.x, PostgreSQL 14 and above, Redis 7.x and above, Apache Artemis 2.55 or above, OpenTelemetry built in, and Go 1.22 or later for the Go channel implementation.

The Dockerfile in the repository does not match that list. The base image is a Java 21 image:

FROM m.daocloud.io/docker.io/eclipse-temurin:21.0.4_7-jdk-alpine

and the container exposes port 9999, adds the built jar from the daxpay-start target directory, and starts it with java $JAVA_OPTS -jar daxpay-server.jar. The image also sets the timezone to Asia/Shanghai, and sets a JAVA_COMM environment variable that configures the entropy source and the file encoding.

So there is a genuine inconsistency between the stated requirement of JDK 25 and the shipped image built on Java 21. A class file compiled for a newer release will not run on an older JVM, so if the code is compiled with Java 25 as the table says, the shipped image would fail at startup. Either the table overstates the requirement, or the image is stale. Both are things to check on your own deployment rather than assume, and the one-click installer and deployment guide linked from the README are where the current instructions live.

The base image is also pulled through a Chinese registry mirror rather than from Docker Hub directly, which is a deliberate choice for build speed in that region and is worth knowing if your own build environment cannot reach that mirror.

Beta status, the licence file and the commercial packs

The release record shows a 4.0 line in beta: 4.0.0-beta7 on 2026-09-19, 4.0.0-beta8 on 2026-10-04 and 4.0.0-beta9 on 2026-10-13, with the README badge already reading 4.0.0-beta10. The default branch is named 4.0, and the last push was on 2026-10-20. So the platform is under active development, and the version you deploy from the main branch will move.

On licensing, the README is precise: the open source build of the payment platform core is released under GNU LGPL v3.0 or later, and the badge reads LGPL-3.0-or-later. The repository root contains a LICENSE file, a _license/ directory and a file named 用户授权使用协议.txt, which is the user authorisation agreement. That last file is a separate document from the licence, and for an open source project with commercial extension packs it is exactly the file to read before deciding how you will use the code.

The commercial side is not hidden. The aggregated channel pack, the mini programs and the related items are listed as extension packages with a version and pricing list on the documentation site, and the README links them directly. The open core plus the paid extensions is a deliberate model: the core, the management front ends, the direct channels and the SDK isolation architecture are free, and the parts that require commercial acquiring relationships are not.

That model has an implication for evaluation. The architectural benefit, that a channel SDK upgrade or outage stays inside one sub-application, is available in the open build. The breadth of channels you can actually route to is not.

Editorial conclusion

DaxPay suits a team that needs to accept several Chinese payment methods behind one HTTP interface and wants the vendor SDKs isolated so they can be upgraded and scaled per channel, and that is willing to run the platform itself. It does not suit a team that needs the aggregated acquiring channels or the mini programs without buying the extension packs, and it does not suit a team that wants the aggregation handled by a hosted provider instead. Before adopting, run the open build against the sandbox and confirm the four open channels cover the methods you need, read the deployment guide for the fail-fast startup checks, and check the price list for the extension pack before assuming the aggregated channels are available to you.

Frequently asked questions

Official sources

1. dromara/dax-pay on GitHub
2. License: LGPL-3.0
3. Project website
4. README
5. Releases