Security & privacy architecture
This page describes, as plainly and accurately as we can, how your data actually moves through this product — not marketing language about how secure it is. If something below is unclear, email privacy@visitorlevycalculator.co.uk.
HTTPS everywhere
Every request between your browser and both this site and the API runs over HTTPS. Session cookies are marked secure and HTTP-only in production, so they're never readable by page scripts.
Booking files are parsed in your browser
When you import a CSV or XLSX export from Airbnb or Booking.com, the file is read and parsed entirely client-side — it is never uploaded as a raw file to our servers for the browser-based import flow. Column mapping and source detection happen locally too, before anything is sent anywhere.
Guest details are structurally excluded, not filtered out
There is no guest name, email, phone number, or address field anywhere in the backend's data model — not on a reservation, not accepted by the calculation or import endpoints. Only column headers you explicitly map to a fixed set of levy-relevant fields (check-in date, check-out date, accommodation amount, nights, and similar) are ever read from your file; anything else in the spreadsheet, including any guest-identifying columns, is never sent — because there's no field for it to be sent to.
Tenant-isolated, sanitised ledger
Once sanitised, levy-relevant booking data is stored under your organisation. Every authenticated request is scoped to a specific organisation via a required organisation header, so one organisation's bookings, properties and calculations are never visible to another.
Stripe handles payment details
Card details never reach this application. Billing is handled by Stripe via Laravel Cashier — checkout happens on Stripe-hosted pages, and we only ever see the subscription status Stripe reports back, never card numbers.
Your data, exportable and deletable
Reports you generate can be exported as CSV, PDF or XLSX at any time. If you close your account, contact us and we'll walk you through deletion of your organisation's data.
The import workspace and local storage
While you're mapping columns and reviewing a spreadsheet import before it syncs, the working data lives in your browser's own local storage (IndexedDB) — not on our servers. This lets you review, correct or abandon an import without any data leaving your device until you explicitly confirm the sync. Only the rows you confirm, and only the fields listed above, are then sent to your account.
What we don't claim
We deliberately avoid vague or unverifiable security claims. We are not "SOC 2 compliant", we do not use the term "bank-grade" or "military-grade" security, and we do not describe ourselves as "GDPR certified" — GDPR compliance isn't a certification any product can claim to hold. What we describe above is the actual architecture, and we'd rather you judge it on those specifics.
Methodology & sources
Every Visitor Levy figure this product shows is calculated from configured council scheme data — a specific, versioned set of rules (rate, night cap, effective dates, retention percentage) for a named local authority — run through a single calculation engine shared by the free calculator, manual entry, and bulk imports. We only mark a council's scheme "live" once it has been independently verified against official guidance; see how a calculation works for the full step-by-step methodology.
This product does not submit Visitor Levy returns to any local authority, and it never will as currently built. It prepares the figures and the supporting workings for your quarter — filing the actual return with your council, and paying what's owed, remains entirely your responsibility as the accommodation provider.