Data processing addendum
This addendum forms part of the terms of service and governs the personal data a merchant's shop holds on the platform.
[PLACEHOLDER — counsel to supply: the incorporation clause, the parties, the order of precedence between this addendum and the terms, and which data protection law governs it.]
Roles
The merchant is the controller of the data in their shop. The platform is the processor, acting only on the merchant's documented instructions — which, in the ordinary case, are the merchant's own use of the product.
The platform is the controller of one narrow set: the merchant's own account details and the operational records of running the service for them.
What is processed
| Subject matter | Running a point-of-sale service for the merchant's shop |
| Duration | For as long as the shop exists, plus the retention window below |
| Nature and purpose | Storage, retrieval, synchronisation to the merchant's terminals, reporting, receipt and invoice generation, and backup |
| Types of personal data | Shop customers: name, phone number, purchase history, outstanding balance. Staff: name, role, hashed PIN. Terminals: a server-generated identifier and a human-readable device label. Owner: login email |
| Categories of data subject | The merchant's customers, the merchant's staff, and the merchant themselves |
| Special categories | None. The product has no field for any, and none should be entered |
Sub-processors
| Sub-processor | Purpose | Data reached |
|---|---|---|
| Supabase | Managed Postgres database, authentication, and private object storage | All of the above |
| Vercel | Hosting and delivery of the web application and its API | Data in transit, and whatever a request carries |
| Mailgun or Resend — whichever is configured on the platform | Delivery of transactional email (verification, backup notices, contact replies) | Recipient email address, shop name, and the message body |
| Sentry — only when a reporting key is configured | Diagnosing crashes and server errors | No personal data. A report carries the shop's subdomain, the route that failed, the ROLE of whoever was acting (owner / cashier / accountant — never their name or PIN), and an error message that is redacted before it is sent |
There are no others. In particular there is no advertising network and no third-party tracking anywhere in the product — web or mobile — and no analytics of any kind touches shop data: nothing measures a signed-in shop, its staff, or its customers. The public marketing pages (landing, demo, pricing, contact) carry Vercel Web Analytics — cookieless, aggregated visit counts, run by the sub-processor already listed above; those pages process no shop data, so it is noted here for completeness only.
On the crash reporter specifically, because it is the one entry above that touches a live request. The error payload is assembled field by field in the platform's own code, not by a vendor SDK: the request body, headers, cookies and query string are never attached, and the message and stack are passed through a redaction step first — email addresses, telephone-shaped numbers, the database's own "duplicate value" detail line, anything under a key named for a secret, and any Arabic text (which in a server error is data, not a message). The report is redacted before it leaves the platform's servers, not after it arrives. Reporting is inert entirely unless a key is configured.
[PLACEHOLDER — counsel to supply: the sub-processor change procedure, the notice period, the objection right, and the transfer mechanism for each entity above.]
Security measures
- Each shop's rows are scoped to that shop at the database level; a request bound to one shop cannot read another's.
- Staff PINs are stored hashed. The plain-text column was removed.
- Terminal credentials are opaque, stored only as a hash, single-use on exchange, and revocable from the owner's Devices screen. A refresh token presented twice revokes the whole device rather than being honoured.
- File storage buckets are private; nothing uploaded is world-readable.
- Privileged database routines are not executable by anonymous or ordinary authenticated roles, and a continuous-integration gate fails a change that would re-open them.
[PLACEHOLDER — counsel to supply: the formal Article 32-style measures annex, breach notification timing, and confidentiality undertakings for personnel.]
Assisting the merchant with data-subject requests
A merchant asked by one of their customers to produce or erase that customer's data can, today:
- Export the whole shop — catalogue, customers, sales history and settings — as a single file, at any time, from the store settings (
/api/files/store-export). - Delete a customer record from the customers screen.
Two things are honestly not built yet, and this addendum will not promise them before they are: a per-customer export (that one shopper's orders and payments as a file) and an erasure that reaches everywhere the name went — free-text activity-log entries, receipts already saved into file storage, and backup bundles already taken. Both are tracked as outstanding work.
[PLACEHOLDER — counsel to supply: the assistance obligation and its timescales, drafted against what is actually implemented above.]
Retention
This is the statement the mechanism has always implemented and no document ever made:
- A live shop's data is retained for as long as the shop is live. Nothing is deleted on a schedule while the subscription runs, and being blocked for non-payment deletes nothing.
- Saved exports, reports and receipts in file storage are removed 90 days after they are produced.
- Backup bundles are kept to the most recent few per shop — eight by default, adjustable per shop — and older bundles are pruned as new ones are taken.
- Sync tombstones expire after 30 days. They carry no personal data: only the fact that a row with a given id no longer exists.
- The activity log is archived, never deleted, once past its window; the archive keeps every row with its original identity.
- Sign-in attempt records and expired session tokens are removed on platform-wide windows, no shorter than 7 days.
- A closed shop is marked deleted, retained for a window, and then purged permanently — the purge cascades to everything that belongs to the shop. [PLACEHOLDER — counsel and the business to fix the window; the mechanism is implemented and the window is a stored setting.]
Return and deletion on termination
The store export is the return-of-data mechanism. It produces the shop's catalogue, customers, sales history and settings as one file, and it is offered before a shop is deleted rather than only on request.
After the retention window above, the shop's rows are permanently deleted. Backup bundles taken before deletion age out on the backup retention above rather than being individually reached into — which is why the window matters and is stated here.
Audit
[PLACEHOLDER — counsel to supply: audit and inspection rights, and what evidence the platform will provide in place of an on-site audit.]
Contact
Requests under this addendum go through the contact form.