Privacy notice
Version 2026-08-25, in effect from 2026-08-25
This is a working draft. The commercial clauses are being prepared with counsel and are listed as outstanding at the end. Everything stated below is a commitment the software already keeps.
Who this is about
Two groups of people. The staff of an organisation using this service, whose names, work email addresses, roles and actions are recorded. And customers of that organisation, about whom this service holds almost nothing — a table number, a guest count, and the last six digits of a payment reference where one is captured.
Who is responsible for what
For your staff records and your trading records, your organisation is the controller and this service is the processor. You decide who you employ, what you sell, which records you keep and for how long; this service holds them and acts on your instructions.
There are two places that changes, and they are set out on this page rather than left for an incident to discover. This service is the controller of its own account and billing records — who signed up, which plan, what was invoiced — because it decides to keep those and no venue instructs it to. And for security records such as sign-in attempts, device registrations and rate-limit counters, the two are joint controllers: your organisation has an interest in who signed in to its tablets, and this service has an independent one in defending every tenant at once against credential stuffing. That second purpose is this service’s own, which is why you cannot instruct it to stop keeping them.
| Records | Controller | Processor | Why |
|---|---|---|---|
| A tenant organisation's staff records and trading records | The tenant organisation | This service | The venue decides who it employs, what it sells, which records it keeps and for how long. This service holds those records and acts on the venue’s instructions — it does not decide why any of it exists. |
| Account and billing records for the tenant organisation itself | This service | — | Who signed up, which plan they are on, what they were invoiced and whether they paid. This service decides to keep those and for how long; no venue instructs it to. It is a controller here, and the duty that follows is its own rather than the tenant’s. |
| Security and abuse records: sign-in attempts, device registrations, rate-limit counters | This service, jointly with the tenant organisation | — | A venue has an interest in who signed in to its tablets, and this service has an independent one in defending the platform against credential stuffing across every tenant at once. Because the second purpose is this product’s own and not the venue’s instruction, the role is joint rather than processor — which matters, because a tenant cannot instruct this service to stop keeping them. |
What this service undertakes where it is the processor
- A tenant’s trading records are not read, aggregated or used to build anything except the service that tenant is being given.
- One tenant’s data is never mixed with another’s. Every row carries its organisation, the database enforces it, and a second check in the application enforces it again — a single mistake is not enough to cross the line.
- Nothing is sold, shared with an advertiser, or used to train a model.
- Sub-processors are listed, and a change to the list is a new version of the privacy notice rather than a silent edit.
- When a tenant leaves, their records are returned or deleted on their instruction — except where a law requires this service to keep something, which is stated rather than done quietly.
What this service undertakes as a processor
Your trading records are not read, aggregated or used to build anything except the service you are being given. One tenant’s data is never mixed with another’s — every row carries its organisation, the database enforces it, and a second check in the application enforces it again, so a single mistake is not enough to cross the line. Nothing is sold, shared with an advertiser, or used to train a model.
When you leave, your records are returned or deleted on your instruction, except where a law requires this service to keep something — and where that happens you are told which records and which law, rather than it being done quietly.
Who else touches your data
The table below is the complete list, with what each one processes, where it sits, and the basis on which your data reaches it. It is held as data in this service’s source code rather than as a page somebody edits, so every change to it has a date and a difference that can be read.
A change to that list is a new version of this notice for you to accept. It is not an edit made underneath an agreement you already gave.
| Role | What it processes | Where | Basis, and why |
|---|---|---|---|
| Cloud host | Everything the service stores: staff records, trading records, the audit trail and the ledger. It is the database and the application servers. | The tenant's own residency region, chosen when the organisation is created. | Stays in your regionNothing to assess, because nothing leaves. An organisation with a residency region set is refused a host region outside it — the check runs before any connection is made rather than after, so a misconfiguration fails to start rather than replicating first and failing later.The vendor for a given deployment is recorded in infra/cloud, per deployment, with the region on the organisation record. |
| Object storage | Evidence photographs — a broken bottle, a POS slip — and generated report exports. Content-hashed, and reachable only by people with permission at that venue. | The tenant's own residency region, replicated only within it. | Stays in your regionA photograph of a POS slip can carry a payment reference and a face, so it is treated as the most sensitive thing the service holds and never crosses a residency boundary. Replication targets are constrained to the same region for the same reason. |
If there is a breach
The clock starts at the first credible report, not at confirmation. Waiting for certainty is how a 72-hour window becomes a 40-hour one, so this service works to 72 hours everywhere — which is never longer than the statute in any country it serves, and shorter than some allow.
The table below sets out, for each country, the statute, the regulator who is notified, what that statute says about timing, and when the people affected are told as well.
| Country | Statute and regulator | What the statute says | We work to | People affected |
|---|---|---|---|---|
| Nigeria | Nigeria Data Protection Act 2023Nigeria Data Protection Commission (NDPC) | 72 hours from becoming aware. | 72 hours | Where the breach is likely to result in high risk to their rights and freedoms. |
| Ghana | Ghana Data Protection Act 2012 (Act 843)Data Protection Commission, Ghana | Without undue delay — the statute names no figure. | 72 hours | The Act requires the Commission and affected persons to be informed of the breach. |
| Kenya | Kenya Data Protection Act 2019Office of the Data Protection Commissioner (ODPC) |
Credentials are never stored in a readable form
Passwords and staff PINs are hashed with Argon2id and cannot be recovered, only replaced. Two-factor secrets are encrypted with a key held outside the database, so a database copy alone produces no working codes. Password reset links, email verification links and invitations are stored only as hashes — a stolen database yields no usable links.
Secrets never travel in a web address
A query string reaches every access log, proxy log and browser history between a tablet and the database, none of which this service controls. Nothing sensitive is ever placed in one. This is also why the error-monitoring entry in the table below can honestly say it receives no personal data.
We do not help anybody discover who works where
The sign-in and password-recovery screens answer identically whether or not an address has an account, and the same is true of a suspended account. The set of people who work at a particular bar is not public information, and this service is built so that it cannot be used to find out.
Photographs
Evidence photographs — a broken bottle, a POS slip — are stored in private object storage, content-hashed so they cannot be swapped, and reachable only by people with permission at that venue. They never cross your residency region, because a photograph of a POS slip can carry a payment reference and a face.
Still to be published
Retention periods for each category of record. The lawful basis relied on in each country served. How to exercise access, correction and erasure rights, and the limits the append-only ledger places on erasure.
Version history
- 2026-08-25 — Publishes the sub-processor register, the controller/processor boundary and the breach-notification window for each country served. Those three were listed as outstanding in the previous version.
- 2026-08-14 — First published version.