Security
Security, in the open
The parts of DineGlobe a guest never sees are the parts a restaurant depends on. Each control below is enforced by the system's own test battery — including the ones that stay switched off — and the limits of this deployment are stated as limits.
Tenant isolation, decided server-side
Every request's authority comes from a verified membership context resolved on the server — request parameters never grant access. A venue's data is invisible to other venues: a cross-tenant request simply looks like not-found, and role denials are refused explicitly. The isolation is proven by tests, not asserted by configuration.
Data protection
Sensitive guest notes (dietary, accessibility, allergy) are encrypted at rest with AES-256-GCM under dedicated keys, and purpose-limited: staff read them only through an audited path. Every token the system issues — guest links, check-in passes, identity tokens — is stored only as a peppered hash and shown in full exactly once. Delivery evidence masks recipients; the full address never crosses into staff views. Audit trails record field names only — never passwords, card details, note bodies or unnecessary guest PII.
Identity and access
Passwords are hashed with Argon2id. Sessions are server-side and revocable — revocation takes effect on the next request, and a disabled account is rejected before any private read. Multi-factor authentication is TOTP with single-use recovery codes, and sensitive operations (refunds, platform decisions) require a fresh MFA-verified session. Login and recovery paths are rate-limited per identity.
Money integrity
Amounts are exact integer minor units in the venue's currency — never floating point, never converted, never rounded. Provider network calls stay outside allocation transactions, webhooks verify raw-body signatures through an idempotent inbox before anything is trusted, and refunds require a second approver above a configurable threshold. A late payment after inventory was released compensates through a refund workflow instead of resurrecting a booking.
Correctness discipline
Business date, the venue's IANA timezone and UTC instants are kept distinct on purpose — day boundaries, DST transitions and overnight services resolve deliberately. Physical tables are exclusive by database constraint: two parties cannot hold the same table at the same time, at any level of concurrency. Side effects flow through a durable PostgreSQL outbox — a confirmation is either durably recorded or honestly absent.
Reliability, stated honestly
Backups are documented and restore-drilled on a schedule — the restore is the proof, not the backup file. DineGlobe currently runs on a single server, not a multi-AZ high-availability deployment, so we publish no availability, capacity or recovery figures: none have been measured, and we will not advertise what we have not measured. Performance figures that exist describe the host they were measured on.
Capability gates and countries
Paid bookings and SMS sit behind capability gates: each country and provider combination stays disabled until it passes a signed readiness review with recorded evidence. Enabling in production additionally requires an approved, non-sandbox provider configuration — a flag alone is never enough. During the pilot the gates are closed: no live payment or SMS provider is connected and no charge is ever made. Every write to the capability registry requires an evidence reference, even a disable.
What we do not claim
No third-party security audit or certification has been obtained — see compliance for what is verified and what is not. There is no impersonation or wildcard tenant bypass anywhere in the product, and no feature is advertised beyond what runs today.
Single-market pilot evidence only: one approved country and its listed capabilities do not constitute global support; unlisted countries and capabilities stay disabled.