Security & trust
Built to be attacked
A ticketing platform is a target the moment a show sells out. This page says what we do about it, in plain terms.
Security review
Security review is part of how the platform is built, not a step at the end. The whole system is reviewed adversarially on a regular basis, with particular attention to whatever changed most recently. Every finding is fixed, and each fix is covered by an automated test so it can't quietly come back.
Money
- Card details are entered into Stripe's own form and never pass through the platform. Payments use 3‑D Secure when the issuing bank requires it.
- Prices, fees and totals are computed on the server. The fee rules a buyer sees are frozen for their session, so a change during an on‑sale can't alter an in‑flight purchase.
- Paid orders are fulfilled exactly once, and a background check catches any confirmation that goes missing, so a payment can never leave someone without tickets.
- Refunds are recorded before money moves, so a crash mid‑refund is finished rather than repeated. Chargebacks are mirrored as they happen.
Tickets
- A ticket's secret exists only inside its QR, never in an email's text, a URL or a log.
- A ticket scans once. Two devices scanning the same code at the same moment can't both admit.
- Reprints, refunds, voids and accepted transfers each issue or invalidate codes immediately.
- Scanner apps keep their local data encrypted, and an offline scan is still checked against the server when it uploads.
Accounts
- Sign‑in is handled by a managed identity service; the platform never stores passwords. Google and Apple sign‑in link to an existing account only when the provider has verified the email.
- A changed email is verified before it takes effect, and the previous address is told. A changed password sends a notice. “Sign out everywhere” is one click.
- Access is deny‑by‑default and checked on the server for every request. Something you may not see returns “not found”, so the API never confirms that it exists.
The on‑sale
- Joining the queue requires passing a bot challenge. Queue positions are assigned by a keyed shuffle no client can influence.
- Presale access codes have a minimum length and are rate‑limited per event and address.
- Rate limits, a web application firewall and bot checks run at the edge, in front of the platform.
Infrastructure
- The platform runs on AWS, behind Cloudflare. The database is not reachable from the internet.
- Secrets live in a managed secrets store, never in configuration or code.
- Changes are tested and reviewed before they reach production.
Transactional mail only: receipts, transfer links, reminders people asked for, security notices, invitations. Sent from a verified domain with standard email authentication in place; bounces and complaints handled automatically; one‑click unsubscribe on every reminder. The full policy is published at ticketdemo.xyz/email-policy, with real support@ and abuse@ mailboxes behind it.
Reporting a problem
If you believe you've found a security issue, write to support@ticketdemo.xyz with the details. We'll acknowledge it and keep you informed while it's fixed.