fuint is a membership and cashier system for Chinese retail shops

The design idea: scan to pay, and payment makes you a member

fuint is described as an open source membership and marketing system for physical shops, built on a front end and back end separated architecture. The intended businesses are listed explicitly: fresh produce, retail supermarkets, bars, hotels, car 4S dealers, flower shops, milk tea and dessert shops, restaurants and farm stays.

The core workflow is a single sentence in the README: a customer scans and pays, becomes private domain traffic, and payment is membership. Everything else hangs off that. Once payment has created a member, points and card coupons build a tiered membership system, and message push and SMS campaigns are how the shop reaches those members again.

The stated goal is lowering customer acquisition cost by removing the barrier between the offline checkout and the online store. That is why a cashier is inside this system rather than beside it, and why 代客下单, ordering on behalf of a customer who is standing in front of the counter, is a first-class feature.

The backend supports multi-store mode.

Cards and coupons come in five flavours, and redemption needs two devices

The card and coupon layer is the deepest part of the system. The types named are electronic coupons, stored value cards, physical cards, multi-use cards such as the 集次卡 counting card, and the 储值卡 prepaid card, plus balance payment and member top-up.

Structurally, the backend treats electronic coupons as two levels: a coupon group and the coupons inside it. That is the difference between defining a marketing campaign once and issuing many coupons against it, and it is why the admin list has both 电子券组管理 and 电子券管理.

Redemption is designed around the shop floor. A member presents a QR code at the front end and an administrator verifies it with a WeChat scan. The administrator side has its own management area with three functions listed: the redemption staff list, approval of redemption staff, and editing their information. Approval is the notable part, since it means redemption permissions are not just given to everyone with a login.

Transferring a coupon is also handled: a member enters the recipient's phone number, the recipient gets an SMS, and the transfer record appears in the transfer management section.

Messages are the reason the shop keeps the member record

Three channels are listed: SMS, in-app popup messages and WeChat subscription messages. The listed message scenarios are delivery notices, card expiry reminders, activity reminders, membership expiry reminders, and points balance change notifications.

That list is the operational core of the system. A membership programme without expiry reminders is a membership database, and the expiry and points-balance triggers are what turn it into retention.

Templates are configurable per scenario and per business line through the SMS template management area, and the SMS management area holds the sent list, so campaign history is auditable rather than fire and forget. Coupon issuance, both single and batch, records what was actually sent and can void a record after the fact, which is what you need when a batch goes out to the wrong segment.

An operation log covers key backend actions for the coupon system specifically, recorded so you can investigate who did what. That is a compliance feature, and it is scoped to the coupon side rather than to the whole admin surface.

The backend is a four module Maven project with a broad component list

The repository layout is a Maven project with several backend modules. fuint-application/ is the deployable jar, fuint-framework/ holds framework code, fuint-repository/ is the data access layer, and fuint-utils/ is shared utilities. pom.xml sits at the root, db/ holds the SQL, and configure/ holds configuration files. sbin/ and screenshots/ are auxiliary directories.

The backend stack is Spring Boot 3.2 with MyBatis Plus on MySQL 5.7 or 8, plus Redis. The named components cover a lot of ground: Spring Security for authentication, Druid for the connection pool, Slf4j for logging, Fastjson for JSON, JWT for tokens, Quartz for scheduled jobs, and Swagger UI for the API documentation.

Quartz is worth singling out because the scheduled work is not decoration here. Sleeping member wake-up campaigns and card expiry reminders are time-driven, and the README describes member operations automation through campaign settings such as card opening gifts and dormant member reactivation.

The frontend is Vue 3 with Vite, Uniapp and Element UI Plus on Node, with Electron listed in the front end stack, which suggests a desktop cashier build is possible rather than only a browser or mini program one.

Install steps are an import, an edit and a Maven build

The documented environment lists JDK 1.8, 11 and 17 as accepted, MySQL 5.7 or 5.8, and any Redis version.

The install sequence is four steps: import the fuint-db.sql file from the db directory, edit the configuration files in the configure directory, import the project into IntelliJ IDEA with the Lombok plugin installed, then run install with Maven and run the jar:

nohup java -Dfile.encoding=UTF-8 -Xmx2048m -Xms2048m -Xss256k -Xmn1024m -jar fuint-application-1.0.0.jar

The JVM flags are set equal for heap maximum and minimum at 2 GB, which means the process reserves that memory as soon as it starts. On a small server that is a deliberate choice rather than a default, and it is worth knowing before you deploy to something with 1 GB.

The UTF-8 encoding flag matters here specifically, because the system sends SMS in Chinese and stores Chinese text in MySQL. Getting the encoding wrong shows up as garbled content in messages rather than as an error.

For people without Linux or backend experience, the README points at the 宝塔 panel for deployment, and a live demo with the account fuint and password 123456 is published along with a Swagger UI.

Licence, development plans and what the README restricts

The repository carries AGPL-3.0, which particularly affects a hosted deployment: if you run a modified fuint as a network service for other people, the AGPL requires the corresponding source to be offered to them.

The README adds a usage policy on top of that. Personal study is allowed, as is use as a reference for a graduation project or paper. Then two constraints appear: do not remove the copyright labels, and for commercial use, purchase a source authorisation, which the README describes as very cheap. The project asks for stars and watching in exchange for updates, and says feature questions go to a group chat.

So there are two overlapping signals here. AGPL-3.0 in the LICENSE file is the legal grant, and the README's commercial authorisation request is an additional condition layered on top. If you intend to run this in a business, that contradiction is the first thing to resolve with the author rather than decide yourself.

The development plan lists four items: better reporting and statistics, share-to-help and share-to-get-coupon mechanics, staff commission and distribution, and more marketing tools such as daily check-in. None of these are in the current feature list, so plan around what exists.

Editorial conclusion

Adopt fuint if you run a physical shop in China that needs a membership database, coupon redemption and a cashier that shares one member record with the online mini program. Do not adopt it expecting a full point of sale replacement or a turnkey e-commerce platform, and settle the licensing question first because the README asks you to buy a commercial source authorisation. Before deploying, import db/fuint-db.sql, edit configure/, build fuint-application with Maven, and replace the demo account before anyone reaches the production instance.

Frequently asked questions

Official sources

1. fushengqian/fuint on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README