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.
Independent audits
The platform has had three independent adversarial security audits in 2026, each covering the whole system with particular attention to code added since the previous one. Every finding was fixed, and each fix is covered by an automated test so it can't quietly come back. New model generations of the auditing tools are run against the platform as they become available.
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 request verification run at the edge, in front of the platform, and the platform refuses requests that didn't come through it.
Infrastructure
- Serverless on AWS in a single region, with the database on a private network reachable only from the platform's own functions.
- All secrets live in a managed secrets store; none are in configuration or code.
- Every change reaches production through an automated pipeline that runs the full test suite first. Nothing is deployed by hand.
- Logs that could contain personal data are retained for three months.
Transactional mail only: receipts, transfer links, reminders people asked for, security notices, invitations. Sent from a verified domain with DKIM, SPF and DMARC; 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.