Privacy Policy
Last updated: 2026-05-15 Effective date: 2026-05-15
Template — review with counsel before launch. This text reflects taamga’s current data flows; it does not constitute legal advice. Adjust the controller-of-record details, member-state references, and supervisory-authority pointer before publication.
1. Who we are
taamga is a software platform that helps restaurants run QR-menu ordering, pay-at-table, reservations, and loyalty under one customer identity.
When you (a restaurant operator) sign up for the platform, taamga is the data controller for your account and billing data (sections 3.1 and 3.2 below).
When a guest orders food, pays, or books a table at a restaurant that uses taamga, the restaurant is the data controller of the guest’s personal data. taamga acts as the data processor on the restaurant’s behalf. The processor relationship is governed by our Data Processing Agreement, which forms part of every operator’s contract.
Contact: privacy@taamga.com. We are happy to receive requests in English, German, French, Spanish, or Dutch.
2. Scope
This policy covers personal data we process when you:
- visit our marketing website (taamga.com) or per-venue websites hosted on
*.taamga.com - sign up for or use the taamga operator dashboard
- order food, pay, or book a table at a restaurant powered by taamga
- contact our support team
3. What we collect, why, and for how long
3.1 Operator data
We collect this when you sign up for a taamga subscription.
| Data | Why | Retention | Legal basis |
|---|---|---|---|
| Email, name | Authenticate you, send transactional emails (receipts, payment failures, churn confirmations) | While your account exists + 30 days | Contract (Art 6(1)(b) GDPR) |
| Tenant + venue metadata (name, timezone, address) | Run the platform — render your menu, send guests to the right place | While your account exists + 30 days | Contract |
user_venue_role assignments | Authorise which operator can do what | While your account exists | Contract |
3.2 Billing data
| Data | Why | Retention | Legal basis |
|---|---|---|---|
| Stripe customer ID, subscription state, plan, period bounds | Charge you monthly / annually, gate features by plan | While your account exists + 10 years (statutory bookkeeping) | Contract + legal obligation |
| Invoice records | Statutory bookkeeping | 10 years | Legal obligation (Art 6(1)(c)) |
We do not store card numbers. Card details are entered directly into Stripe’s iframe (the Stripe Elements PCI SAQ-A flow) and never reach our servers.
3.3 Guest data — processed for the restaurant
When a guest interacts with a taamga-powered restaurant we process the following data on behalf of that restaurant.
| Data | Why | Retention | Legal basis (controller’s basis) |
|---|---|---|---|
| Phone, name, email (when entered for receipt or booking) | Send receipts / booking confirmations; build a returning-guest record | Up to 3 years after last interaction, or as the restaurant configures | Contract (with guest) + legitimate interest |
| Session, order, payment metadata | Run the order and payment, send the funds to the restaurant | 7 years (tax-record obligation in most EU jurisdictions) | Contract + legal obligation |
| Booking, party details | Manage the table reservation | 3 years after the booking date | Contract + legitimate interest |
| Loyalty points + ledger | Track points balance for returning guests | One year after the member’s last activity at that restaurant. Then the points expire, the membership’s link to past orders is removed, and once no membership is active the member profile is anonymised (see “Membership retention” below) | Contract |
| Allergen notes (where provided) | Inform kitchen staff to handle the order safely | Until the guest deletes them | Vital interest (Art 6(1)(d)) |
| Device tokens (staff app push) | Notify staff of new orders | Until the device is unregistered or stale (>180 days) | Contract (with the operator) |
Membership retention
A guest who verifies their email at a restaurant becomes a member of it. Each membership has its own activity clock, which moves forward when the member signs in, links a table session, earns points, or opens their points or order history.
When a membership has seen no activity for one year:
- its points balance expires (an expiry entry is written to the points ledger);
- its past orders and sessions at that restaurant are no longer linked to the member.
The orders themselves are kept, because they are tax records.
When a member has no active membership left, and no recent or upcoming order or booking, their profile is anonymised, exactly as in a self-service erasure (see §6).
3.5 What an erasure keeps
An erasure, whether the guest asks for it or the retention rule above triggers it, never deletes a tax record:
- Kept, without the link to the person: orders, order lines and payment amounts. Orders also lose the guest’s name and receipt email.
- Deleted: memberships, points, notes, favourites and marketing consents.
- Kept, under a random identifier with no email, name or phone attached: coupon redemptions, so that a coupon limited to one use per guest stays used.
- Kept, without the link to the account: bookings, under the restaurant’s booking retention.
3.4 Analytics
We use PostHog (EU-hosted) for product analytics to understand which features are used. Analytics is off by default — guest browsers only emit events after the user opts in via the cookie banner.
We never sell, rent, or trade your data.
4. Cookies and local storage
taamga stores the following in your browser:
| Item | Type | Purpose | Lifetime |
|---|---|---|---|
taamga.theme | localStorage + cookie | Remember light/dark theme preference | Indefinite (clear via browser tools) |
| Supabase auth session token | localStorage | Keep operator logged in | Until logout or 60 days |
taamga.consent | localStorage | Remember your cookie consent decision | Indefinite (clear via banner) |
| PostHog distinct_id | cookie | Tie product-analytics events together (only after consent) | 365 days |
You can revoke consent at any time using the “Manage cookies” link in the footer.
5. Who else sees your data
We use the following processors. Each is bound by a written agreement equivalent to Article 28 GDPR.
| Processor | Purpose | Hosting region |
|---|---|---|
| Supabase | Postgres database + authentication | EU (Frankfurt) |
| Stripe | Payments (guest checkout) + Billing (operator subscription) | US (with SCCs) — strictly necessary for payment processing |
| Resend | Transactional email | EU |
| Twilio | SMS reminders (operator opt-in) | US (with SCCs) |
| PostHog | Product analytics (consent-gated) | EU |
| Sentry | Error monitoring | EU |
| Contabo | VPS hosting (Go API + Angular SSR + static SPAs) | EU (Germany) |
| FCM / APNs | Push notifications to operator devices | US (with SCCs) |
Where a processor is outside the EU/EEA we rely on the Commission’s Standard Contractual Clauses (2021/914).
6. Your rights
Under GDPR you have the right to:
- Access your data (Art 15) — request a copy via privacy@taamga.com.
- Rectify inaccurate data (Art 16).
- Erase your data, subject to retention obligations (Art 17). Statutory invoice records cannot be deleted before the 10-year window expires.
- Object to processing based on legitimate interest (Art 21).
- Restrict processing while a complaint is investigated (Art 18).
- Port your data (Art 20) — we will deliver a JSON export within 30 days.
- Withdraw consent at any time without affecting prior processing.
- Lodge a complaint with your supervisory authority. In Germany, that is the Berliner Beauftragte für Datenschutz und Informationsfreiheit; the EDPB list covers other member states.
Signed-in members can download their data and delete their account themselves, from the account page of the restaurant’s menu app. The download is a JSON file. A deletion takes effect immediately, follows §3.5, and removes the sign-in.
For guest data held on behalf of a restaurant, address access / erasure requests to that restaurant. They can fulfil the request using the GDPR export endpoint built into the operator dashboard, or by contacting us at privacy@taamga.com to request it on their behalf.
7. Security
- All traffic uses HTTPS (TLS 1.3).
- Database access is gated by Postgres row-level security so a logged-in operator can only see their tenant’s rows. A separate dockertest-backed CI suite verifies this on every commit.
- Passwords are hashed with bcrypt by Supabase Auth.
- We log every operator-side admin action to a tamper-evident audit table.
- Payment card data never reaches our servers (Stripe Elements / SAQ-A scope).
- We run external penetration testing annually.
8. Children
taamga is not directed at children under 16. If you believe a child has provided personal data, contact privacy@taamga.com and we will delete it.
9. Changes
We notify operators of material changes by email at least 14 days in advance. The latest version is always at taamga.com/legal/privacy.
10. Contact
- Privacy questions: privacy@taamga.com
- General contact: support@taamga.com
- Postal: (to be added once the controller-of-record is finalised)