Loyalty Platform | Release Notes v1.0

1. About This Release

Version 1.0 is the first formal release of the Loyalty Platform: a white-label loyalty programme that runs under your brand, on your customers' phones, connected to whatever till system you use.

One principle shapes the whole product: configuration, not code. Your brand, your earn rules, your promotions, your preference categories and your catalogue are all settings you control from a console, changeable in seconds and live immediately. Onboarding a new business onto the platform is a ten minute form, not a development project.

Why this matters. Loyalty offered by till vendors locks your programme, and your customer relationships, inside their product. This platform keeps both with you: if you ever change tills, your members and their points come with you.

2. Features in This Release

2.1 The member app

Join in under 60 seconds from a link or QR code, with an instant welcome reward. No app store download; one tap adds it to the phone's home screen.
Passwordless login with a single-use 6-digit code, valid for 10 minutes.
A membership barcode that refreshes every 30 seconds (a real, scanner-readable Code 128), so screenshots and shared codes are worthless. A printed card number is shown as well for tills without a scanner.
Points, tiers and rewards: live balance, progress to the next tier, one-tap conversion of points into vouchers.
Offers hub: activate-to-earn promotions and automatic ones, ranked with the customer's favourites first.
Preferences: customers pick what they love; the app also suggests categories from what they actually buy.
Itemised e-receipts for every identified purchase, with the points working shown in full.
Date-grouped activity history explaining every movement in plain language, including returns and refunds.
Lost phone recovery: old codes die instantly, points and vouchers stay intact.

2.2 The admin console

Each business gets its own console, its own admin key, and complete data isolation from every other business on the platform.

Area	What you can do
Earn rules	Points per £1, redemption threshold and welcome reward, changed live with no release.
Offers and promotions	Create, edit and retire promotions in seconds. Choose activate-to-earn (the customer opts in) or automatic (applies to everyone). Customers see changes within moments.
Preference chips	Manage the interests customers can pick, in your own vocabulary: dietary tags for a restaurant, departments for a retailer.
Members and liability	Member list with balances, plus points and voucher liability derived live from the ledger, so finance always sees the true exposure.
Demo tools	One-click seed and reset for demonstration environments.

2.3 The platform console

Self-service onboarding: create a new business (a tenant) from a form: identity, brand colours, earn rules, preference chips and an optional catalogue and offers. Credentials are generated automatically and shown once.
Suspend and reactivate: the billing enforcement hook. A suspended tenant's app, tills and admin console all refuse politely; nothing is deleted, and reactivation restores everything exactly as it was.
Access control: an unknown or unpaid business simply does not exist on the platform. There is no way to use the programme without being provisioned.

2.4 Connecting tills

Route	What it is
Day-one companion screen	Any spare tablet or phone at the counter scans customer codes and records sales. No changes to the existing till, so a pilot can start the same day.
Enactor estates	A ready-made connector implementing Enactor's external loyalty pattern (ICD TS26-003): enquiry, capture, tender redemption and void, delivered as a single container for the back office or the cloud.
Toast restaurants	A cloud-to-cloud connector implementing all six of Toast's loyalty transaction types (search, signup, inquire, redeem, accrue, reverse). Nothing installs in the restaurant; many locations map to one programme.
Square	The shop connects its own Square account from its own console, in about ten minutes, with nothing to install on the till. Every completed sale earns points on its own, refunds take them back, and staff carry on using the Add customer button they already use. Sales with no customer attached are counted, so an owner can see whether the habit is sticking.
Any other POS	One open, documented API (`openapi.yaml`) with five operations, security-signed, with a certification checklist for the till supplier.

Common to every route: exactly-once earning (a till retry can never double points), earning on the amount actually paid after vouchers and points, line-level returns that take back exactly the right points, and offline queues that replay safely when connectivity returns.

2.5 Wallet passes and notifications

Apple Wallet and Google Wallet passes, generated with the customer's card and your branding. See Known Limitations for the signing status in this release.
Push notifications: customers who enable alerts get a notification when a new promotion matches their preferences, even with the app closed. Standards-based Web Push; on iPhone the app must first be added to the home screen.
In-app awareness: a badge and a tap-to-view banner the moment a new offer is published.

2.6 Privacy and data ownership

Data export: any member can download everything held about them as a single file, from inside the app.
Right to erasure: any member can delete their account themselves. Their profile is anonymised immediately, remaining value is forfeited, and their devices stop receiving notifications. Pseudonymous financial records are retained for audit, as permitted.
The business owns its customer data. Each tenant's members, rules and history are isolated at the data layer, and portable.

Peace of mind, without becoming a security expert. The heavy lifting of data privacy and fraud protection is engineered into the platform: codes that cannot be copied, points that cannot be faked, and privacy rights your customers exercise themselves. You get full ownership of your customer data; the technical proof lives in the appendix at the end of this document, ready to hand to an IT or compliance reviewer whenever one asks.

3. Setting Up Your Programme

The platform records what happens at your tills. What it cannot know is what your programme should reward, because that is your business decision. These are the values you supply, each changeable at any time from your console:

Setting	What it means
Points per £1	Your earn rate. Different businesses on the platform run anything from 2 to 10.
Welcome reward	The voucher a customer receives the moment they join.
Redemption threshold	How many points convert into a reward voucher, and therefore what a point is worth.
Preference chips	The interests customers can pick, in your own words. These drive offer ranking and notification targeting.
Catalogue or menu	Optional: your items with categories and member prices, enabling member pricing and category-based promotions.
Promotions	Your live offers: title, category, points multiplier, and whether customers must activate them.

4. Known Limitations

Stated plainly, so nothing surprises you later.

Login codes are shown on screen in demonstration mode. The platform does not yet send email; in production configuration this is a small integration with a transactional email provider.
Wallet passes are generated unsigned in this release. The full Apple and Google pass structure ships and validates, but installing a pass into Apple Wallet requires Apple merchant certificates, and one-tap Google save links require a Google Wallet issuer account. Both are drop-in credentials, not code changes.
iPhone push notifications require home-screen installation first. This is an Apple platform rule for web apps, and the app explains it to the customer at the point of enabling alerts.
Till integrations are certification-ready, not vendor-certified. The Enactor, Toast and Square integrations implement the vendors' documented patterns and pass full simulated end-to-end suites. Field-level certification happens with each vendor's programme, and any adjustment lands in one translation file per till.
Square earning depends on the customer being attached to the sale. Square gives no way for us to prompt staff at the moment of payment, so a sale rung up without Add customer earns nothing. Those sales are counted and shown in the console, which is the honest answer: it is a staff habit, and the number tells you whether the habit has formed.
Redeeming at a Square till is a staff action, not an automatic one. Square does not let an outside application put a discount into a sale that is already in progress, so a voucher or points payment is applied by the member or by staff and the discount is keyed in Square as normal. Earning, refunds and balances are fully automatic; only applying a reward is manual.
Billing is by agreement rather than in-product. The enforcement mechanism (suspension) is built and tested; card payment collection is a planned integration.

5. Getting Help and Trying It

The User Manual covers day to day use for customers, store staff, programme managers and platform operators, including what to check when something looks wrong. For anything not answered there, use the contact route agreed at onboarding.

Not on the platform yet? You can try everything in this document risk free: the pilot runs free until your first 100 members join, using the day-one companion screen from section 2.4, so nothing touches your existing till. We set up your branding and your first campaign for you, and your customer sign-up list is yours to keep whatever you decide.

Everything your IT, compliance or security reviewers will ask for. Nothing in it changes how you use the product.

Technical & Security Appendix

This appendix exists so a technical reviewer can verify the platform without a meeting. Business readers can stop at section 5 with a clear conscience.

A1. Technology and Versions

Published so that your technical or security reviewers can see what the platform runs on. Checked on 21 August 2026.

Component	In v1.0	Notes
Node.js	24	Current release line, used in production and in every test run.
Application runtime	Zero-dependency core	The platform core uses no third-party packages at runtime, which keeps the supply-chain surface close to nil. The single exception is below.
node-postgres (pg)	8.x	The only runtime dependency, used solely for database persistence.
PostgreSQL	16	System of record in cloud deployments; the same engine is used in every CI run.
Hosting	Vercel + managed PostgreSQL	Serverless deployment with cross-instance state convergence built in.
Delivery pipeline	GitHub Actions	Every deployment is gated: code reaches production only after the full test suite passes.

A2. Testing and Verification

This release ships with over 840 automated checks, all passing. The full set runs on every change, against a fresh database each time, and a change that fails any check cannot reach production.

Suite	Checks	What the tests verify
Platform	375	Enrolment, earning, redemption, returns and refunds, promotions, tenant isolation, provisioning, suspension, preferences, GDPR export and erasure, wallet pass structure, push targeting, login, rate limiting and every security layer. Roughly a third of the checks assert what must not happen: no double earning, no cross-tenant access, no unsigned till call accepted.
Enactor connector	13	End to end from a simulated Enactor till through the connector to an auth-enforced platform, including the proof that unsigned direct calls are rejected.
Toast connector	20	All six Toast transaction types with Toast's own message shapes, retry deduplication, two locations sharing one programme, and rejection of unknown restaurants and bad tokens.
Square till	82	Webhook signatures verified the way Square specifies, including refusal of a signature made for a different address; a Square order translated into a basket and earned once however many times Square retries; discounts counted once rather than twice; sales by weight; another currency refused; partial refunds corrected to the amount the customer kept; and a forged or replayed call from an unconnected Square account refused in words that give nothing away.
Security and abuse	130	A hundred and thirty deliberate attacks: forged and replayed till signatures, requests tampered with after signing, one customer trying to read another, one business trying to reach another, injection attempts, prototype pollution, path traversal, header injection, mass assignment, negative and absurd baskets, double redemption, double refunds, rate limit evasion and information leakage. Each one asserts the attack fails.
Races and timing	46	What happens when two things arrive at the same instant: two tills redeeming one voucher, a customer tapping Redeem four times, a till retrying a sale eight times, two refunds of one sale, forty simultaneous sales, a rush on a free pilot boundary, and a deletion request arriving while a sale is still in flight.
Database persistence	13	Cold-start survival, convergence between simultaneous instances, session handover between instances, and tenant provisioning visibility across instances, run against a real PostgreSQL.
Member app in a browser	162	Every screen driven in a real browser environment, running the page's own code against a live server: joining, earning, redeeming, receipts, preferences, the admin console including a locked-down instance, and the platform consoles.

Independent verification is used where it matters most: Apple Wallet pass archives are validated with a separate tool rather than the code that produced them, and push notification signatures are cryptographically verified against the served public key.

A3. Security and Data Handling

Till and connector traffic is signed. Every till-side call carries a per-tenant HMAC signature with a timestamp and single-use nonce; stale or replayed requests are rejected.
Member identity resists copying. Barcodes rotate every 30 seconds and a used code cannot be replayed.
Sessions, keys and scopes. Members hold session tokens that only reach their own data; each business has its own admin key; platform operations require a separate platform key.
An append-only ledger. Points are never edited, only appended: corrections are compensating entries, so history is complete and auditable.
Abuse guards. Public endpoints are rate limited per address, with tighter limits on signup and login.
Tenant isolation. A member number, voucher code or transaction reference from one business is meaningless in another.
Signatures cover the whole request. A till signature is computed over the method, the address and the contents, so a captured signature cannot be moved onto a different call or kept while the basket is swapped.
Browser protections. A content security policy, framing refused, content type sniffing refused, strict transport security, referrer limits and unused device permissions denied. Member and business data is marked never to be cached.
Limits on the money path. Quantities, prices and basket totals are bounded, so a faulty or compromised till cannot credit an implausible number of points. Returns must be whole positive quantities.
You can take a key back. A business can replace its own admin key whenever someone who had it leaves. The old key stops working immediately, and the replacement is shown once.
An audit trail that cannot be edited. Every change to a programme is recorded with what changed, from what to what, when, and which console did it, including changes made by us as the platform provider. Member deletion requests are recorded as evidence they were honoured, without keeping what was deleted.
Sessions expire. Staying signed in lasts 30 days and is extended by use, so a regular customer is never asked to log in again while a token from a lost or shared phone dies.
Correct under pressure. Simultaneous requests cannot double spend a balance, redeem one voucher twice, pay a reward twice for the same visit, create two accounts for one email address, or credit points to a deleted account.
Text is displayed, never executed. Anything typed by a business, a member or a till is escaped before it reaches a screen, so a name or an offer title cannot carry a script into someone else's browser.

Written honestly: this is internal security testing, not an independent penetration test. It means an outside tester starts from a higher floor rather than finding the obvious things first. An independent test is planned before the first customer that requires one.

A4. Measured Performance and Scale

These are measured figures, not estimates. A programme is loaded to size, then the real endpoints are driven through the real code and timed. The harness is part of the codebase, so any figure here can be reproduced or challenged.

Operation	1,000 members 10,000 transactions	10,000 members 200,000 transactions	25,000 members 500,000 transactions
Identify a customer at the till	2.0 ms	2.2 ms	2.1 ms
Earn points on a sale	2.8 ms	2.7 ms	2.7 ms
Customer opens the app	2.1 ms	2.3 ms	2.0 ms
Customer reads their receipts	2.0 ms	2.1 ms	1.9 ms
Console liability summary	2.3 ms	4.9 ms	11 ms
Console programme figures	19 ms	243 ms	548 ms
Tills identifying at once	635 per second	965 per second	947 per second

The figures worth drawing out:

Response times do not grow with the programme. A till lookup takes about the same two milliseconds whether the business has a thousand members or twenty five thousand, and whether there are ten thousand transactions on record or half a million.
A sale costs the same at any size, because a sale adds one record rather than rewriting history.
Aggregate reporting is the exception and grows with the data, reaching about half a second at half a million transactions. That is a page a manager opens occasionally rather than something a customer waits on.
Roughly 950 till identifications a second on a single instance, and the hosting adds instances under load rather than queueing.

Where this stops being enough, stated plainly rather than left to be discovered: a single business with more than about 25,000 members and half a million transactions approaches the memory a single instance holds comfortably, and a first request after an idle period takes around three seconds to load a programme that size. Both are addressed by reading from the database on demand rather than loading a whole programme, which is planned work rather than a redesign. No business of that size is on the platform today.

This exercise found two real faults, which were fixed rather than documented around: reading a balance was scanning a business's entire transaction history, and every sale was rewriting every receipt ever issued. The test suite now fails if either pattern returns.