Choosing checkout software for a wellness center starts with a conclusion you may not want to hear: checkout is hard — but not at the moment of taking payment.
A single payment QR code can take money, and the operation is trivial. What actually blocks you are the three things that happen after the money arrives — which card this payment belongs to, how many sessions that card has left, and whether today’s books reconcile. Get those three wrong and within three months the store drifts back to Excel, because at least Excel lets you add a column.
So when choosing wellness center checkout software, do not look at “how many payment methods are supported.” Look at whether these three things run as one chain.
Gate 1: does payment deduct the session in the same step?
A wellness center mostly sells session cards and treatment packages. When a client finishes a service and pays at the front desk, two things must happen at once: the money comes in, and the count is deducted.
If these are two separate steps in the system, the front desk records twice; in a busy moment one recording gets missed, and the client’s card ends up with an extra session that the month-end books will not match. This is not carelessness — it is process design.
Verifiable on the spot: count-based vouchers can be configured with a total number of uses and a per-day use limit; the redemption log page records order number, member, order type, redeemed content, store, redemption time, and notes; the finance module includes checkout and payment collection, including an aggregate payment QR code.
Test it live like this: create a 10-session card, deduct one session through checkout, and watch whether the remaining count immediately becomes 9 while a new line appears in the redemption log.
The part you configure to your store’s process: deducting the session at the same time as payment, how over-deduction is handled, whether rescheduling reverses the deduction, how voided orders are recorded — these rules vary store by store and must be configured to your card packages and payment scenarios, not forced into a generic taxonomy.
| # | Check | How to verify | What fails looks like |
|---|---|---|---|
| 1 | Payment and deduction are one step, not two | With the same test member, run one payment with deduction, then open the card balance and the redemption log | Two separate menus, and a manual card selection is needed to deduct — mark failed |
| 2 | Remaining count is visible on the spot, without opening a report | Right after the operation, ask “how many sessions does this card have left” and watch whether the rep opens another page | If a separate report is needed, card packages and redemption are not connected |
| 3 | Rules for over-deduction, rescheduling, and voiding are clearly stated | Ask each one: can over-deduction be blocked, does rescheduling reverse, how is voiding recorded | Whatever cannot be answered becomes a verification item in the contract appendix |
Ask on the spot: “Please use the same test member and run one payment with session deduction. When it is done, open the card balance and the redemption log at the same time and show me this transaction.”
Red flag: payment and deduction are demonstrated in two different menus, with a manual card selection in between.
Gate 2: are prepaid principal and bonus tracked separately?
Top up 1,000 CNY, get 300 bonus, the member balance shows 1,300. At sale time everything is clear; at refund time the argument begins: is 1,300 refundable, or 1,000, or 1,000 minus the consumed portion?
This is not just an accounting question. Under current rules, the burden of proof in such disputes does not rest entirely on the consumer: consumption records, consumption counts, and balances controlled and managed by the operator must be evidenced by the operator. A system that cannot remember becomes the store’s loss.
Two more provisions to know: an operator providing services through prepayment should conclude a written contract with the consumer covering service content, price, refund method, and liability for breach; within seven days of payment the consumer may request return of the prepaid principal. And clauses like “no refunds after payment” or “lost cards will not be reissued” are invalid by law.
Verifiable on the spot: the marketing module supports multi-tier “top up X CNY, get Y bonus and Z points” configurations.
Test it live like this: create one tier of “top up 1,000 CNY, get 300 bonus,” run one top-up, and look at whether the balance page shows a single total of 1,300 — or two numbers: 1,000 principal and 300 bonus.
Questions to settle face to face: can principal and bonus be recorded in two separate fields, and can the consumption order be configured by you (principal first, or bonus first). Both must be asked in person during selection.
If the system cannot track them separately, patch it with manual fields in your charter and ledger — this step cannot be skipped, because it directly decides which number the refund follows.
Two more things to ask in the same conversation:
- Whether your store falls under the applicable-entity scope of China’s Measures for the Administration of Single-Purpose Commercial Prepaid Cards. Those measures cover corporate entities in retail, accommodation and catering, and resident services; many wellness stores are sole proprietorships and may be exempt. Applicability and any filing requirement follow the local commerce authority.
- Whether the store can meet the 30-days’ advance public notice required for closure or relocation.
Gate 3: does the daily close reconcile?
Taking payment is easy; the hard part is knowing after collection how much came in today and what kind of money it was. Card opening, top-up, one-off consumption, price-difference make-up, and refunds — if all of these are mixed into one “revenue” bucket, the daily close shows only a total with no structure.
Verifiable on the spot: the finance module provides transaction detail, balance detail, top-up records, redemption records, and commission records as ledger views; the redemption log page carries an order-type field.
Test it live like this: pick any transaction and trace it from the ledger back to the redemption record — see whether the trail runs end to end.
The part you configure to your store’s process: which concrete scenarios your store’s card opening, top-up, one-off, make-up, and refund types correspond to, and what each is called, varies by store — order types must be configured to the real payment scenarios; whether the daily close splits by store or by person, and which fields the reconciliation statement carries, follows your store’s own reconciliation process.
Questions to settle face to face: are multiple payment methods recorded separately, can the daily-close statement be exported, and how do refunds and voids reverse and show up in reconciliation. Run one real transaction for these three — do not stop at demo data.
Two more belong to the “ask, though they probably cannot answer” category — raise them together at the end:
- Does money go to the corporate account first, or pass through a third-party account first — this decides who has authority when a refund happens;
- How long does a refund take to reach the client’s account, what happens if it fails to arrive, and who holds refund authority.
There is no standard answer to either, but they must be asked, because they directly determine how fast you can handle complaints.
When a payment QR code alone is enough
Not every store needs a system right now. In these three situations, a payment QR code plus one Excel file is actually the better fit:
- One-off visits only, no cards sold: with no session cards or prepaid balance, there is no deduction or balance to track;
- One store, one cashier: the account structure is simple enough to hold in one person’s head;
- Card packages not yet figured out: installing a system now freezes half-formed rules into configuration that is more painful to change later.
Conversely, the moment you start selling session cards or prepaid balance, the three gates above become unavoidable — and the earlier the system is in place, the easier, because backfilling historical card balances is always harder than starting inside the system.
The four-step on-site acceptance method
Compress the three gates into one action and have the vendor perform it live:
| Step | What you should see | What failing looks like |
|---|---|---|
| Payment with deduction | After payment, the count drops by one and a redemption line appears | Payment and deduction in two menus |
| Separate top-up tracking | Principal and bonus are two numbers, not one total | Only one balance shown |
| Export the daily close | Today’s books export and can be traced line by line | Only a grand total viewable |
| Process one refund | The refund leaves a record in the system and the books still match | Manual spreadsheet edits required |
If any of the four steps falls back to Excel, the system does not pass.
In Yujian Cloud, the count-based voucher parameters, redemption log fields, top-up bonus tier configuration, and finance ledger views are all verifiable on the spot; the linkage rules between deduction and payment, order-type naming, and daily-close splitting are the parts configured to each store’s process. The actual scope of each can be checked item by item against the full-scenario digital operations plan for wellness centers.
Frequently asked questions
How is wellness center checkout software different from generic checkout software?
Not in the payment features — in three things: money must be bound to card-package session deduction, prepaid value must track principal and bonus separately, and treatment packages must deduct by session. Software that only solves “money received” drifts back to manual work within three months in a wellness center.
Is a payment QR code not enough?
For a store doing one-off visits and selling no cards, a QR code plus Excel genuinely suffices. The moment you sell session cards or prepaid balance, session deduction, balances, and refunds become unavoidable — and backfilling history later is far more painful.
When a prepaid balance card is refunded, which number is refunded?
It depends on whether principal and bonus are tracked separately in the system. If only one total is shown, nobody can say what should come back. So confirm at selection time whether separate fields and configurable consumption order are supported; where they are not, patch them with manual fields in the charter and ledger.
What must be verified for the daily close?
Three must-check items: are multiple payment methods recorded separately, can the daily-close statement be exported, and how refunds and voids reverse and show up in reconciliation. Run one real transaction for these three — do not let demo data pass for verification.
Scope note
This article addresses the selection of wellness center checkout software, providing a verification structure and self-audit criteria only: no prices or payment-channel terms, no operating data cited, and no conclusions about any vendor’s capabilities. Legal content paraphrases provisions only and is not legal advice; specific applicability and filing requirements follow the competent local authority. Provisions on referral-level structures follow the relevant anti-pyramid-selling regulations.
To run the four-step acceptance method against a live system with your own card types:
Contact us to verify the three gates with a real transaction on your own workflows.