These WooCommerce credit system use cases show how one ledger powers very different organizations — explore the full feature set behind each.
Every kind of business that counts in credits.
A credit is a padel hour at a Dutch tennis club, a drink token at a summer festival, a behaviour point in a primary school, a coaching session at a therapist’s practice, a meeting-room booking at a co-working space, or a euro of store credit at a vinyl shop. CreditKit Pro is the WooCommerce plugin that turns any of those into the same ledger.
// the catalogue
One WordPress plugin, eight working scenarios.
Not personas. Not “imagine if.” Eight live patterns that CreditKit Pro stores already run on stock WooCommerce — same database tables, same pcs/v1 REST namespace, same signed webhooks.
Shops
Store credit, loyalty, gift cards.
Sports clubs
Yearly bundle, per-session spend.
Schools
Behaviour points, library passes.
Events
Drink tokens, food vouchers, merch.
Coaching
Session bundles, deduct per appointment.
Subscriptions
Monthly auto-refill across catalogue.
Memberships
Tier perks: bronze 100, gold 500, etc.
Co-working
Room 4 cr, podcast booth 8 cr.
// use case 01
The store-credit and gift-card use case, done as a real ledger.
The original credit use case: a WooCommerce shop wants store credit that survives refunds, a loyalty programme that doesn’t drift, and a gift-card alternative that doesn’t require yet another plugin. CreditKit Pro handles all three from the same wp_pcs_user_credits table. No sidecar wallet, no third-party SaaS, no coupon hack.
Loop Records sells vinyl on WooCommerce. They give 5 credits with every newsletter sign-up, 1 credit per $10 spent on orders, and accept up to 100 credits per order toward future purchases. When a customer returns a sleeve, you can issue goodwill store credit back to the buyer at a rate you set — the store no longer eats the cost of every return. Six months in, the loyalty programme is one report in the WordPress admin, not a spreadsheet.
GET /credits/me (account widget), POST /credits/spend (apply at checkout), POST /bundles/{id}/purchase (top-up bundles).1.0 so a $50 partial refund on a 20-cr order returns 10 cr.- Cap credit-per-order so the balance doesn’t pay for everything forever — decide up front which products are credits-only and which stay money-only.
- Decide once whether expired credits log out via
credit.expiredor roll over — both valid, neither reversible.
// use case 02
Members pay yearly. They spend in sessions.
The yearly-bundle, per-session-spend pattern is the most common non-shop use case for a WooCommerce credit system. A padel club sells a 50-session pack at the start of the year. Members book courts via the WordPress site, and one booking deducts six credits. The treasurer stops being a human spreadsheet.
TC Zandvoort has 240 members, two padel courts, an indoor swim lane, and a Saturday morning gym class. Previously the club used a wall planner and a clipboard. Now every member buys a 50-credit bundle in February, books on the WooCommerce site, and watches their balance drop in real time. A padel hour is 6 credits, a swim entry 2, a gym class 4. The treasurer’s spreadsheet is finally retired.
POST /bundles/{id}/purchase (the yearly pack), POST /credits/spend with context=padel|swim|gym (one call per booking), GET /credits/me (member dashboard balance).- Use ONE
credit.spentevent with acontextfield per booking type — don’t shard into custom event names, the webhook subscribers will thank you. - No-show forgiveness is a policy, not a feature: decide whether
refund.restoredfires automatically on 24 h cancellations or only on admin approval.
// use case 03
Behaviour points, cafeteria credits, library passes — one balance.
Primary and secondary schools running a WordPress site for parent communication can use CreditKit Pro as the points-and-passes back end. Teachers award credits via the WordPress admin. Students see their balance on the parent portal. Cafeteria, library, after-school club each deduct their own context. No new app, no new login.
OBS De Vlinder runs a Kadence-based parent portal on WordPress. Teachers award behaviour points each Friday from the admin. Parents top up a cafeteria balance via WooCommerce. The library lends iPads against a 5-credit deposit, restored on return. One student’s account dashboard shows behaviour points, cafeteria credits, and library pass holds in one view — because under the hood they are all the same ledger row, just with different context fields.
POST /credits/add (teacher awards from the gradebook), POST /credits/spend with context=cafe|ipad|library, GET /credits/me (parent portal widget).pcs_security_log.- The audit log is non-negotiable in a school context — every
credit.addedis signed with the teacher’s user ID, so parent disputes resolve in one query. - Don’t conflate behaviour points with payable credit unless that’s the actual policy; use two separate
contextvalues and keep them ring-fenced.
// use case 04
Drink tokens, food vouchers, merch passes — one wristband.
A festival doesn’t want cash at the bar. It also doesn’t want a bespoke POS contract. CreditKit Pro on a WooCommerce site sells the bundle online before gates open, and the bar tablet hits POST /credits/spend over the festival Wi-Fi. Leftover tokens refund automatically the Monday after.
Lowlands-style weekender sells a 10-token bundle for $25 in pre-sale. The bar tablet runs a single-page WooCommerce client that scans the wristband barcode, calls POST /credits/spend with context=bar, and prints the receipt locally. The food court does the same with context=food. On Monday at noon, a cron refunds unused tokens to the original card via refund.restored — no support inbox, no goodwill bleed.
POST /bundles/{id}/purchase (pre-sale), POST /credits/spend with context=bar|food|merch (every tablet tap), POST /credits/add via Monday cron (the post-event sweep).- Run the bar tablet against a local Wi-Fi WooCommerce mirror and keep the spend call on the local network — festival latency is the real failure mode.
- Test the velocity factor at full bar pace before doors open. The default
fraud.flaggedthreshold is tuned for e-commerce, not festival rush hour.
// use case 05
Session bundles that survive a rescheduled Thursday.
Coaches, therapists, and consultants sell session bundles. The hard part isn’t selling them — it’s tracking which client has how many sessions left, surviving a last-minute reschedule, and not losing track of a refund. CreditKit Pro makes the session ledger the single source of truth, and the client sees the same number you do.
Studio Werkdag offers a 10-session coaching bundle for $600. Clients book via the WooCommerce site. Each appointment is one credit. A 24 h no-show forfeits the credit; a 48 h cancellation refunds it via refund.restored. When a client buys a top-up mid-bundle, the new credits queue behind the originals so expiry behaves correctly. The “did I prepay or not?” email thread dies.
POST /credits/spend with context=session (per booking), GET /credits/me (client dashboard balance + expiry warning), POST /bundles/{id}/purchase (top-up purchases that respect bundle expiry order).pcs_check_expiring_credits cron 30 days before TTL.- Set
_pcs_expiry_dayson the bundle product, not as a global; clients buy different programmes with different commit horizons. - The expiring-credits cron is what makes this use case retainable — keep it on its hourly schedule, never disable it during “quiet months.”
// use case 06
Monthly credits, spent across your catalogue.
The “subscription credits monthly” pattern beats the classic subscription box on retention. Instead of locking the customer to one product, you sell them a monthly allowance and let them spend across the WooCommerce catalogue. No skip-a-week emails. No “this month’s box is not for me” churn. The credits roll, the customer stays.
Crate & Cellar sells a $40/month wine credit subscription. Each month, the WooCommerce Subscriptions renewal triggers credit.added · +40 CR. The customer browses 120 SKUs and spends whatever fits their week — sometimes one $40 bottle, sometimes four $10 minis. Unused credits roll for 90 days. Churn drops because the customer never receives a box they didn’t want; they curated it themselves on the WordPress site.
POST /credits/add (called from woocommerce_subscription_payment_complete), POST /credits/spend (the gateway, every order), GET /credits/me (the dashboard widget showing balance + next renewal).- Wire
credit.added · subscriptionto the subscription renewal hook, not the order-complete hook, or you will double-credit on the first cycle. - 90-day expiry is a compromise between “use it or lose it” and “feels punitive.” Test both ends with a real cohort before deciding.
// use case 07
Tier perks that mean something specific.
Most WordPress membership plugins gate content. CreditKit Pro lets the tier mean a number. Bronze gets 100 credits a month, gold 500, platinum unlimited via a flag on the gateway. Members spend on real products: workshop seats, members-only merch, priority bookings. The perk is a budget, not a badge.
The Maker Cooperative runs a WordPress membership site with three tiers. Bronze ($19/mo) gets 100 credits, gold ($49) gets 500, platinum ($99) gets the unlimited_credits gateway flag. Credits buy workshop seats (40 cr), studio time (8 cr/hr), members-only print runs (variable). When a member upgrades mid-month, credit.added tops up the delta. When they downgrade, the next renewal simply credits less. The audit log records actor and reason for every change.
POST /credits/add (tier renewal), per-user gateway flag unlimited_credits (platinum), GET /credits/me (member dashboard with tier + balance), POST /credits/spend for every member-only purchase.- The
unlimited_creditsgateway flag is a per-user override, not per-product — confirm the right user gets it, not the right product. - Tier changes mid-cycle are an accounting decision. Either pro-rate via
upgrade-delta, or wait until renewal. Don’t do both.
// use case 08
Bookings priced in credits, not Calendly hours.
A co-working space, a podcast studio, a recording room, a community kitchen — every venue with bookable rooms can price them in credits instead of euros. The member buys a monthly credit pack. Each room booking deducts the right number. The accounting layer underneath is still WooCommerce, with full euro reporting for the tax office.
Werkspot Zuid runs three meeting rooms, a podcast booth, and a one-camera video room out of a converted warehouse. Members buy a 40-credit monthly pack for $120. A 2 h meeting room is 4 credits, a podcast booth hour is 8, the video room is 12. A cancellation 6 h ahead refunds the credits; under 6 h forfeits them. Office managers love it because there’s one number to look at, not a price list.
POST /credits/spend with context=room|booth|video (one call per confirmed booking from your room-booking plugin), POST /credits/add for refunds (the 6 h cancellation window), POST /bundles/{id}/purchase (monthly pack as WooCommerce subscription), GET /credits/me (lobby tablet dashboard).- The room-booking plugin (Amelia, Bookly, etc.) must call
POST /credits/spendon confirmation, not on form submit, or you’ll debit half-completed bookings. - Debit credits on booking confirmation, not on a tentative hold in your booking plugin — otherwise a cancelled tentative booking can leave the balance short.
// the alternative
Why “just use a gift-card plugin” is the wrong shape.
One code, one balance, one spend
- One code = one balance, single use
- Refunds re-issue a fresh code
- No webhook on redeem
- No
contextper spend - Drift fixed by support ticket
- Use case capped at “shop”
One user, one rolling balance, many spends
- One user = one rolling balance, many spends
- Refunds restore the original ledger row
credit.spentfires every timecontext=session|bar|room|ordertags every debitpcs_integrity_checkcron catches drift hourly- Same plugin covers 8 economies on the same DB
// faq
Questions a shop owner, a club treasurer, and a head teacher all actually ask.
Can one WordPress install run more than one of these use cases at the same time?
Yes. The context field on credit.spent and credit.added lets a single WooCommerce site run a shop, a coaching practice, and a co-working booking layer side by side. The ledger is one table; the contexts keep the reporting clean.
Do members in different use cases need different account dashboards?
No. The CreditKit Pro account widget shows balance and full history the same way whether the user is buying vinyl, booking a padel court, or paying for studio time. The context shows in the history row, not as a separate tab.
Will the gateway work for use cases where there is no fiat at all — like school behaviour points?
Yes. Set the gateway mode to credits-only and the WooCommerce checkout treats the credit balance as the only tender. There is no requirement to charge a euro alongside.
What about VAT, tax, and bookkeeping when a session is “6 credits” not “$36”?
The WooCommerce order still records the fiat value of the underlying bundle when it was sold. Reports, tax exports, and the accountant’s view all read in euros. Credits are the unit of consumption, not the unit of accounting.
Can I move from a gift-card plugin to CreditKit Pro without losing balances?
Yes. POST /credits/add accepts a backdated reason field, so a migration script can replay every outstanding gift-card balance into the ledger in one pass. The WordPress admin shows the imported rows under audit.signed for posterity.
Which use case is most common today?
Shops and sports clubs lead. Co-working and coaching grow fastest. Festivals are the most fun deployment because the velocity factor of the fraud scorer earns its keep in the first hour.
Eight kinds of business. One WooCommerce plugin.
Same pcs/v1 REST namespace, same signed webhooks, same wp_pcs_user_credits ledger — running a shop, a club, a school, a festival, a coaching practice, a subscription, a membership, and a co-working space. Install it on the WordPress site you already have.