Security, in plain language

Entraqo is designed to OWASP ASVS Level 2 throughout and Level 3 on payment and ticket issuance. What that means in practice:

Who you are

  • Buyers sign in with a single-use link that expires in fifteen minutes and is bound to the network and browser that asked for it. No passwords to leak.
  • Staff, admins and agents use a password hashed with argon2id; venue and platform administrators also need a one-time code from an authenticator app.
  • Sessions are server-side and can be revoked. Cookies are HttpOnly, Secure and SameSite.
  • Role checks live in the business logic, never only in the screen.

Your data stays yours

  • Every query is scoped to the venue. Postgres row-level security is a second wall behind the application code, and cross-venue access is tested in CI.
  • Hosting in the EU. Encrypted in transit (TLS 1.2 and above) and at rest; phone numbers and addresses are encrypted at field level with a key held outside the database.
  • Data minimisation: no date of birth unless a concession requires it. Orders are kept seven years for VAT, scan logs ninety days, sign-in tokens purged. Buyers can export and erase their data.
  • Every administrator action is written to an audit log: who, what, before and after.

Payments

  • Card details go to Stripe, never to our servers (SAQ-A). 3-D Secure is enforced for European cards.
  • Amounts are recomputed on the server from the price list at order time. Nothing is trusted from the browser.
  • Webhooks are signature-verified and idempotent, so a replayed message cannot issue a second ticket.

Tickets that cannot be copied

  • Each QR is a signed token (ES256, one key per venue) that changes every thirty seconds. The gate refuses a reused one because every scan is logged by ticket and time bucket.
  • The printed fallback code is high-entropy and single-use until rotated.
  • Transfers need the holder's wallet session and the recipient's verified email. Ticket secrets never appear in a logged URL.

Bots and scalpers

  • Cloudflare Turnstile on checkout and sign-in, invisibly. Per-network and per-account rate limits.
  • Ten-minute holds with a cap per buyer per performance, by account and by card fingerprint. Disposable email domains are blocked.
  • Named tickets by default on events; ID check optional per performance. Resale only inside the system, at face value plus a capped fee.

Every boundary checked

  • Schema validation on every form, API call, webhook and seed. Parameterised queries only.
  • A content security policy with per-request nonces and no inline scripts. Framing denied except for an agent's allow-listed widget origins. HSTS, Referrer-Policy and Permissions-Policy set.
  • Secrets live in the environment, never in the repository. Dependencies are audited and pinned; a software bill of materials is produced at build.

Operations

  • Structured logs without personal data, request ids, error tracking with scrubbing, uptime checks.
  • Daily encrypted backups with tested restores and point-in-time recovery. Multiple application replicas.
  • Destructive admin actions ask for re-authentication. Any module or any venue can be switched off instantly.
  • An external penetration test before launch is a line in the proposal, not an afterthought.

When everything is off

The gate must admit valid ticket holders with no electricity, no internet and no Entraqo servers, and reconcile afterwards without double entry.

  • Offline verification is the default

    Any gate phone holding the venue's public key verifies a ticket with no network. After an hour offline the time check widens and the scan is recorded as offline-verified.

  • Phones are the batteries

    The gate runs as an installed PWA on ordinary Android phones, with the key and the day's used-ticket list cached. Ten hours on a charge; two phones and a 20,000 mAh power bank in the gate drawer.

  • Doors talk to each other

    Devices at one venue sync scan logs over local Wi-Fi or Bluetooth. A ticket used at one door is refused at the next within seconds.

  • Paper is the last line

    A printed manifest with holder initials, code, slot and zones, generated before opening. Door sales during an outage use pre-printed signed codes that count against capacity on reconciliation.

  • Sales keep running

    The buyer side runs in the EU cloud with Stripe. A power cut at the venue does not stop online sales, and an already-loaded wallet still shows its QR.

  • Drills

    Blackout mode in the gate app proves the device admits and refuses correctly with the network off. We demonstrate it with a phone in flight mode.