Enterprise-grade loyalty platform with a revolutionary digital token system for reward exchanges.
Visit live site ↗Loyalty Club PLC needed a robust platform that goes beyond traditional points — featuring a revolutionary digital token for seamless reward exchanges between partners and customers.
Lucid Code Labs engineered the experience end to end — from information architecture and UI through to the token-based reward system and scalable backend.
We also developed a companion mobile app so users can earn, exchange, and redeem rewards wherever they are.
The platform supports growth with a codebase and design system the team can evolve confidently.
Loyalty Club PLC set out to build a loyalty platform that goes beyond traditional points, centred on a digital token that lets rewards be exchanged between partners and customers. That premise changes the engineering problem: reward value has to behave like a transferable balance with a proper audit trail, not like a counter held inside one merchant's scheme. The platform also had to carry the day-to-day operations partners and members depend on, and reach members through a companion mobile app so they can earn, exchange and redeem wherever they are. Underneath all of it, the client needed a codebase and design system their team could keep extending with confidence.
Reward value is held in a double-entry wallet ledger where each TEDS transaction records one of 15 transaction types, from token purchase and stamp exchange to cause donations, booking payments and order refunds, with source and destination wallet references and polymorphic user references across nine user types. Members exchange stamps for TEDS, partners can link a bank account to cash out and administrators approve pending transactions, while nightly Agenda jobs aggregate wallet activity and record daily totals.
A single shared awardStampsForVisit routine serves the QR and till flow, the QR menu-order flow and the booking attendance flow, so a stamp is awarded identically however the customer arrives. Campaigns support Buy X, Get Y Free and Spend X Amount To Earn a Stamp, with goals, start and end dates, QR enrolment and referrer rewards, and side effects such as review asks and referrals are individually caught so a failure there can never cost a customer their stamp.
Menus model day and time schedules, sections, items and reusable modifier groups for build-your-own dishes, with the UK's 14 regulated allergens enforced as a schema enum. Guests order from a QR short code without an account, partner endpoints cover the kitchen board, mark-paid, settle-at-till and write-off, and the order controller enforces an explicit received to accepted to in_progress to completed state machine, alongside cancel and reject paths, returning HTTP 409 on an illegal transition.
Availability is computed on read against a five-minute grid instead of materialising slots, and the only persisted artefact is a SlotLock whose unique compound index on client, resource and cell start makes two overlapping bookings collide at the database rather than in application code, with no multi-document transactions required and a TTL index automatically freeing abandoned holds. Working hours are stored as local times and converted per date with date-fns-tz so daylight-saving days stay correct, and the engine handles both appointment mode and table mode.
A full Square OAuth handshake with signed state connects each partner's own Square account, keeping booking and order payments out of the platform's flow of funds, and access and refresh tokens are encrypted at rest with AES-256-GCM using a random IV and stored auth tag. Scheduled jobs refresh those tokens nightly and release unpaid bookings and menu orders every fifteen minutes, while a currency utility normalises stored symbols to ISO 4217 codes before anything reaches a payment API.
Photographed menus are read into structured sections and dishes using OpenAI vision with strict json_schema Structured Outputs and then re-validated, recording allergens and dietary tags only where the printed menu states them because inferring an allergen is a regulatory exposure; where no API key is configured the feature reports itself as unconfigured rather than failing obscurely. A second service grades open-ended sales training answers against the training content and returns written feedback, falling back to manual review if grading is unavailable. Both default to gpt-4o-mini and are model-configurable by environment.


