How your shop
is protected.

Bloom is multi-tenant: many coffee shops share one system. The failure that would matter most is therefore not an outsider breaking in — it is one shop seeing another shop's numbers. That is the risk we design around first.

• Every query is scoped by shop, and the shop identity comes from the signed session token — never from anything the browser can set, like a URL parameter or a request body.
• Every update and delete on shop-owned data re-checks ownership inside the same function that performs the write, so a guessed record ID from another shop fails rather than succeeds.
• That rule is enforced mechanically, not by reviewer memory: an automated check scans the codebase for unguarded writes and blocks the merge if it finds one.
• Cross-tenant access attempts are covered by tests that deliberately try to reach another shop by forging a header and a query parameter, and assert that both come back with only the caller’s own data.

In transit

HTTPS everywhere, with HSTS so a browser will not fall back to plain HTTP. Certificates are managed by Cloudflare.

At rest

Sensitive fields — two-factor secrets and face encodings — are encrypted with AES-256-GCM before they are written. GCM is authenticated, so tampering with the stored value is detected rather than silently decrypted.

Key handling

The encryption key is derived with PBKDF2-SHA256 at 100,000 iterations and lives only in the server's environment. It is never committed, never logged, and never sent to a browser.

Passwords and PINs

Hashed with bcrypt, per-record salt. We cannot read your password. If you lose it, we can only reset it — which is the correct answer, and the reason no support person can ever tell you what it was.

• Role-based access: an account can only reach what its role needs. A waiter cannot open payroll.
• Optional two-factor authentication on staff accounts.
• Sessions expire, and changing a password revokes every existing session on every device immediately.
• Password reset links are single-use and expire after 60 minutes.
• Repeated failed sign-ins are rate limited, and the reset endpoint answers identically whether or not an address exists — so it cannot be used to discover who has an account.
• CSRF tokens on every state-changing request.

Bloom does not process card payments. Settlement happens at the table — cash, or the waiter's own bank terminal. No card number, expiry or CVV ever enters the system.

This is worth being blunt about: it is not a feature we built, it is a category of breach we chose not to be exposed to.

Schedule

Full database backup nightly at 02:00.

Retention

Kept 30 days, then destroyed automatically.

Restores

Restores are tested rather than assumed — a backup nobody has restored is a hope, not a backup.

• Type-checked end to end; the build fails on a type error rather than shipping it.
• Automated tests run on every change — unit, integration against a real database, and end-to-end tests that drive a real browser through the critical paths.
• Dependencies are pinned and updated deliberately.
• Secrets live in the server environment, never in the repository.
• Database changes go through reviewed migrations, never ad-hoc edits against production.

Every vendor page you read claims a certification. Here is ours, stated accurately, because you will find out anyway and it is better that you hear it from us.

If you have found a vulnerability, tell us on WhatsApp at +216 20 114 798. Please give us enough detail to reproduce it, and time to fix it before it goes public.

We will not pursue you legally for research done in good faith: no accessing or altering other people's data beyond what is needed to demonstrate the issue, no degrading the service for real shops, and no extortion. We do not run a paid bounty programme yet, and we will not pretend otherwise — but we will credit you if you want the credit.

Related: what we collect and where we stand on regulation.