Tenant isolation
Every record belongs to an organisation and is scoped on the server. We write tests that try to cross the line, on purpose.
Security & reliability
Built to be boring on match day.
The parts you never see — payments, backups, isolation, queues — get the most attention. This page says plainly how they work, including the limits.
PaymentsTickets issue only on verified payment
DataIsolated per organisation
BackupsRestored on a schedule, not just taken
Direct payments
You are the seller. We are the software.
Buyers buy from you. Your name is on the receipt, the ticket money settles into your connected payment account, and Ticead bills its fee separately. We never hold your revenue and never present it as ours.
- Connect once
- “Connect payment account” links an existing account or creates a new one in minutes. We never ask you to paste secret keys or account passwords anywhere.
- Verified before issued
- A ticket is created only when your payment provider confirms the payment to our servers — not because a browser came back from a payment page. Every payment event is stored, signature-checked and processed exactly once, even if it is delivered twice.
- Card data
- Card details go straight to the payment provider and never touch Ticead. Apple Pay, Google Pay and Strong Customer Authentication are handled there too.
- Refunds and disputes
- Refunds run through your account and cancel the ticket at the same moment. Disputes are tracked against the order so nothing scans that shouldn’t.
- Reconciled daily
- Orders are reconciled against your payment account automatically. If anything doesn’t match, we see it before you do.
- Your contract
- The event contract is between you and the buyer. Ticead supplies ticketing software and agency services, and says so in checkout, receipts and terms. The exact structure is set out in our terms, reviewed by our accountants and lawyers.
Security
Secure by default, then tested for the ways it could fail.
Every organisation is isolated at the database level. Every permission is enforced on the server — hiding a button is not a security control. Every sensitive action is written to an audit log you can read.
Strong sign-in
One-time codes for organisers, MFA for finance and platform roles, sessions you can revoke from any device.
Unguessable tickets
QR credentials are random, signed and contain no personal data. A transferred or refunded ticket’s code stops working immediately.
Audit everything
Refunds, overrides, exports, role changes, support access — who, what, when and why, kept immutably.
Threats we design and test against
Data & privacy
Collect less. Keep it for a reason. Delete it on time.
Ticead is built for organisers in Ireland and the UK. We ask buyers only for what a ticket needs, apply written retention rules, and give both you and your buyers the tools the law expects.
- Minimal data
- Email and, where you require it, a name. No buyer account, no password, no profile.
- Retention
- Personal data is kept for defined periods and then deleted or anonymised, with exceptions only where the law requires records to be kept.
- Buyer rights
- Buyers can request an export or deletion of their data. You can export your own organisation’s data at any time.
- Marketing consent
- Recorded with source and timestamp. Service emails and marketing are kept strictly separate, with a suppression list honoured everywhere.
- Exports
- Exports containing personal data need permission, are audited, encrypted at rest, and expire automatically.
- Processing agreement
- A data-processing agreement and current subprocessor list are provided to every organisation. Legal terms are reviewed professionally, not generated.
Reliability
When something fails, the ticket still gets through.
Graceful degradation is designed in, component by component. Here is what happens when each part has a bad night.
If email is slow or down
The purchase still completes. The ticket is on the confirmation page immediately, and the email is retried until it lands.
If wallet passes can’t be generated
The web ticket is always available and always scans. Wallet generation is retried in the background.
If analytics fails
Nobody notices. Analytics never sits in the path of a payment.
If the ticket database is unavailable
We stop taking new payments rather than risk selling a ticket we can’t record, show a calm “back shortly” message, and preserve queue positions where we can. Existing tickets keep scanning offline.
PITR
Point-in-time recovery
Plus scheduled snapshots and an offsite copy, in a second location.
Drills
Restores are rehearsed
A backup is not considered valid until it has been restored and checked.
Replay
Every job can run twice safely
Payments, emails and refunds are idempotent. A retry never creates a duplicate.
Busy onsales
A queue that protects the doors, not a queue that sells the tickets.
For high-demand sales we place a managed waiting room in front of the event. It controls how many people reach checkout at once — but it never controls inventory. The database does, transactionally, so capacity is exact.
- Load tests before any big onsale, including a 16,000-ticket rehearsal
- Rate limits, bot detection and purchase limits enforced server-side
- An emergency “pause sales” switch that leaves paid orders untouched
- Incident mode and read-only mode, with runbooks we practise
Status & support
If something breaks, you’ll hear it from us first.
A public status page is published at launch with live component health and a full incident history that we don’t edit after the fact. Until then, this page and your organiser contact are the source of truth.
- Support
- hello@ticead.com
Organisers with an event on sale get a direct contact for event day.
- Incidents
- Every incident gets a written post-mortem shared with affected organisers: what happened, what we changed.
- Security reports
- Found something? Email security@ticead.com. We acknowledge within one working day and never take action against good-faith reports.
Trust
Questions we haven’t answered? Ask.
We’d rather explain a limitation than surprise you with one.