1. Security overview

Outside is built as a multi-tenant hospitality platform for conversational menus, ordering, kitchen delivery, and payments. This page describes the security controls we design into the product and operations. It is not a formal certification, penetration-test report, or guarantee against all risk.

2. Multi-tenant data isolation

Customer data is scoped by business tenancy. Application queries default to the current business context so one brand’s menus, orders, staff, and configuration are not exposed to another brand’s operators under normal operation.

Guest carts, chat sessions, and orders are tied to the shop or business where they were created, using shop-scoped APIs and guest session tokens in addition to authenticated staff or diner accounts where applicable.

3. Authentication and sessions

Guest diners and restaurant staff authenticate with email and password through our auth stack. Sessions use signed JWTs with scoped claims (for example user vs staff), expiry, and server-side revocation support for invalidated tokens.

Guest cart and chat continuity use opaque tokens (`outside_cart_token` and `outside_chat_token` in the browser, forwarded to the API as cart and chat headers) so a table session can resume without exposing another guest’s cart. Staff and diner APIs expect Bearer authentication where the action requires an account, including checkout.

Passwords are stored encrypted/hashed by our backend auth framework. Sensitive parameters such as passwords, tokens, and payment secrets are filtered from application logs.

4. Payments

Card and digital wallet payments are processed by Stripe using PaymentIntents and Stripe Connect for marketplace-style payouts to restaurants. Outside stores payment metadata such as amount, currency, status, and Stripe payment identifiers. We do not store full card numbers (PAN) or CVV on Outside application servers.

Checkout on the guest app uses Stripe’s client-side Payment Element with a server-created client secret. Wallet methods such as Apple Pay or Google Pay appear only when enabled for the Stripe account and supported by the guest’s device and browser.

Businesses may provide bank details for payout configuration where that feature is used. Those records are separate from guest card capture and should be treated as sensitive financial data by operators.

5. Application and API protections

Sensitive endpoints such as authentication, AI chat, and checkout are rate limited to reduce abuse. Cross-origin access to the API is restricted to configured application origins.

Role-based authorisation controls what staff can do within a business. Real-time kitchen channels authenticate connected clients before streaming order events for that business.

Optional production monitoring (such as Sentry) and tracing may be enabled per environment to detect errors without intentionally logging payment card data.

6. Allergen and guest safety filters

Conversational recommendations can honour guest-selected allergen filters and budget constraints so unsafe or out-of-budget items are excluded from suggestions where product allergen data is configured correctly by the restaurant.

Restaurants remain responsible for the accuracy of menu, allergen, and pricing data they publish. Guests with medical allergies should still confirm ingredients with venue staff when needed.

7. Infrastructure and third parties

Application services, databases, and media storage run on cloud infrastructure (including DigitalOcean in our standard deployments). Images and other uploads are stored in object storage. Outbound email uses configured SMTP. Address features may use mapping/geocoding providers.

AI chat features may send message content and menu context to OpenAI to generate recommendations. Payment card data is handled by Stripe. Each provider maintains its own security and compliance programs.

8. Your responsibilities

Operators should use strong unique passwords, limit staff access to people who need it, keep menu and allergen data accurate, and secure devices used to manage the business dashboard. Guests should avoid sharing unnecessary sensitive information in free-text chat or special instructions.

9. Reporting a vulnerability

If you believe you have found a security issue in Outside, email [email protected] with enough detail for us to reproduce and assess the issue. Please do not publicly disclose vulnerabilities until we have had a reasonable opportunity to investigate and remediate.

For privacy requests, use [email protected] or our Contact page. Effective date: 4 August 2026.