pay-java-parent: A Java SDK for WeChat, Alipay and Cross-Border Payment Integration

What pay-java-parent actually is, and who it is written for

The README opens by calling the project a third-party payment integration toolkit, and then narrows the claim: it is currently only a development toolkit, meaning an SDK, with a simple web implementation provided as a demo. That sentence is the most important one on the page. pay-java-parent is not a payment gateway you deploy. It is a set of Java classes you add to a build.

The audience is narrow and specific. You are a Java developer building an application that must accept money through WeChat Pay, Alipay, UnionPay, Fuiou, Youdian, PayPal, Payoneer or Yiji, and you do not want to reimplement each channel's request signing, certificate handling and callback parsing from scratch. The README's own framing is that payment is fully separated from business logic, and that a few lines of code are enough to complete a payment.

That separation is the design thesis. The SDK knows how to construct a channel request and how to verify a channel callback. It does not know what you are selling, who the customer is, or what happens after the money moves. If your requirement is a system that stores orders, reconciles settlements and exposes an operations dashboard, this project covers none of that.

Module layout: one common core, one module per payment channel

The repository is a Maven multi-module build. The README lists four parts: pay-java-common, which holds the payment core and the interface definitions; pay-java-web-support, which the README says currently implements callback handling; pay-java-demo, which contains concrete payment examples; and the pay-java-* modules, which are the per-channel implementations.

The top-level directory listing matches that description and adds the channels: pay-java-ali, pay-java-wx, pay-java-union, pay-java-fuiou, pay-java-wx-youdian, pay-java-paypal, pay-java-payoneer, pay-java-yiji and pay-java-baidu. There is a root pom.xml tying them together.

The practical consequence is that you pull only the channels you need. A project that takes WeChat and Alipay does not carry PayPal's dependencies, and a project that adds UnionPay later adds one artifact rather than rewriting its payment layer. The common module is where the abstraction lives, so the cost of a new channel is a new module rather than a change to your business code.

The README states the dependency set explicitly: httpclient, fastjson, log4j and com.google.zxing, with no MVC framework and no servlet dependency. That is a deliberately small footprint, and it is the reason the README claims the library can be embedded into any system. It also means the project does not inherit Spring's transaction or configuration machinery, so wiring is yours to do.

Adding the SDK to a Maven build and calling one channel

The README gives the Maven coordinates directly. The artifactId is the channel module name, and the README names pay-java-ali and pay-java-wx as examples. The version shown in the README is 2.14.13, which is ahead of the most recent tagged release listed for the repository, v2.14.6 from 2023-09-13. Check the version that actually resolves before you pin it.

<dependency>
    <groupId>com.egzosn</groupId>
    <artifactId>pay-java-ali</artifactId>
    <version>2.14.13</version>
</dependency>

After the dependency resolves, the working entry point is not in the README. The README points at the demo module and at the wiki for the Alipay and WeChat walkthrough, and it names specific controllers for the newer WeChat work: WxV3PayController for WeChat V3, WxV3CombinePayController for combined payment, and WxV3ProfitSharingController for profit sharing. Those files are the documentation. Read the controller for your channel before writing anything, because it shows the request object you construct and the callback object you receive.

git clone https://github.com/egzosn/pay-java-parent.git
cd pay-java-parent
mvn -pl pay-java-demo -am package

Running the demo module is the fastest way to see the intended flow end to end. The README notes that the demo uses Spring MVC's @PathVariable and recommends a similar framework, so expect the demo to be a web application rather than a library test. The project is also mirrored on Gitee, which the README lists alongside GitHub; if you are building in a network where GitHub is slow, the Gitee remote is the same repository.

Where the SDK stops and your application has to start

The README is explicit that the project provides only a simple web implementation and recommends pulling it in via Maven or Gradle rather than forking it. That is honest, and it draws a boundary that matters more than any feature list.

Callback handling is the sharpest edge. pay-java-web-support is described as implementing callback-related support, but a callback endpoint is where security lives: you must verify that the notification genuinely came from the payment channel before you mark an order paid. The README does not document a rollback path, a retry policy for failed callbacks, or how the support module handles duplicate notifications. Those are the failure modes that cost money, and they are left to the application.

Idempotency is the second gap. Payment channels retry notifications. If your handler is not idempotent, a retry becomes a double credit. Nothing in the README suggests the SDK enforces idempotency for you, and it would be the wrong place for it to try, since only your application knows what an order is.

There is also a versioning wrinkle worth flagging. The README advertises 2.14.13 while the newest release listed is v2.14.6, and the two intermediate entries are a v2.14.3-b2 beta from 2021-11-23 and a v2.14.3 release from 2021-10-07. The tag history is thin relative to the README's version string, so treat the README as describing the develop branch rather than a published artifact.

pay-java-parent compared with a self-hosted gateway like DaxPay

The obvious alternative for a Java team is a self-hosted payment gateway. DaxPay is the name that appears in searches around this project, and the difference in approach is structural rather than a matter of features.

pay-java-parent is a library. It runs inside your process, shares your classpath, and returns objects your code then acts on. There is no separate deployment, no database of its own, and no operational surface. You upgrade it by changing a version in pom.xml and rebuilding.

A self-hosted gateway is a service. It runs as its own application, owns its own configuration and persistence, and exposes an API your business system calls. That buys you centralized channel credentials, a place to hang reconciliation and an operations view, and it costs you a second system to deploy, monitor and keep patched. If several internal applications need to accept payments, a gateway avoids duplicating channel configuration in each one.

The trade-off is direct. Choose the SDK when one application owns the payment flow and you want the smallest possible dependency. Choose a gateway when payment is a shared capability across teams or when you need settlement and reconciliation data that outlives any single service. The README's own recommendation, to depend on the SDK rather than embed it, points at the first case.

Maintenance, releases and what the Apache-2.0 licence lets you do

The repository is not archived. The last push was on 2026-05-19, which is within six months of today. The release history, however, is sparse: v2.14.6 on 2023-09-13, v2.14.3-b2 on 2021-11-23 and v2.14.3 on 2021-10-07. Commits and tags are not moving at the same rate, which is common for a project whose README tracks a develop branch.

The upgrade cost is the real maintenance question. Because each payment channel is its own module, a channel change touches one artifact, and a channel you do not use cannot break your build. The flip side is that payment channels change their APIs on their own schedule, and the project's ability to keep up is bounded by its maintainers. The README lists four named developers and two QQ groups, one of which it marks as full. That is a small team for eight payment channels.

The licence is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notices. It also includes an explicit patent grant. This is a permissive licence, so the practical obligation is attribution rather than source disclosure. That is a general description of Apache-2.0, not legal advice for your situation.

One process detail matters if you intend to contribute: the README asks that pull requests target the develop branch, because the project follows a git flow workflow. Sending a patch to the default branch will not match that process.

Editorial conclusion

Adopt pay-java-parent if you are writing a JVM backend that must talk to several Chinese payment channels and you want the channel-specific signing, certificate and callback handling out of your own code. Do not adopt it if you need a running payment gateway with an admin console, reconciliation reports and a database schema, because the README describes an SDK and a demo, not a deployable service. Before committing, verify that the channel module you need exists on Maven Central at the version in the README, read the module source for the exact endpoints it calls, and confirm the callback signature verification path in pay-java-web-support matches your framework.

Frequently asked questions

Official sources

1. egzosn/pay-java-parent on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases