Security and your data
A plain-English account of what happens to the information you and your customers hand over when you sell tickets through Seaty. No marketing fluff, no buzzwords. What we do, what someone else does for us, and where the responsibility actually sits.
Where the responsibility actually sits.
Three parties hold pieces of the picture. Stripe handles every card payment under PCI DSS Level 1 — card numbers never reach a Seaty server. Seaty holds order, member, and event data and applies the controls described below. You, the organiser, decide who in your team gets access to which parts of that data, and you control your own sign-in credentials.
Card payment data
Card numbers never touch a Seaty server
Every card payment on Seaty is processed by Stripe using the Payment Intents API. Card numbers, expiry dates, and security codes are entered into Stripe-hosted fields embedded in the page. They are sent directly to Stripe and never reach Seaty's servers.
- Stripe is certified to PCI DSS Level 1, the highest tier defined by the Payment Card Industry Security Standards Council
- Seaty stores only a Stripe payment reference for each transaction, which is meaningless without Stripe
- Strong Customer Authentication (SCA) is handled by Stripe under PSD2
- Refunds, partial refunds, and dispute handling are all driven through Stripe
Sign-in and account credentials
Passwords are salted and hashed before storage. Plaintext passwords are never written to disk and never appear in logs. If you forget yours, we can reset it but we cannot tell you what it was — by design.
Every email-and-password sign-in is followed by a one-time code sent to the email address on the account. The code is six characters, valid for twenty minutes, and single-use — once you enter it the code is deleted. This is two-factor authentication: knowing the password is not enough on its own; an attacker would also need access to the email inbox. The code step is mandatory on every login, not just on new devices.
Sign-in is also available through Apple, Google, and Microsoft for organisers who prefer single sign-on; in those flows the identity provider handles the second factor. Door-staff devices use a separate organisation passcode that does not require an email round-trip, so scanning at the door keeps working without admin intervention.
Every email-and-password sign-in is followed by a one-time code sent to the email address on the account. The code is six characters, valid for twenty minutes, and single-use — once you enter it the code is deleted. This is two-factor authentication: knowing the password is not enough on its own; an attacker would also need access to the email inbox. The code step is mandatory on every login, not just on new devices.
Sign-in is also available through Apple, Google, and Microsoft for organisers who prefer single sign-on; in those flows the identity provider handles the second factor. Door-staff devices use a separate organisation passcode that does not require an email round-trip, so scanning at the door keeps working without admin intervention.
Granular permissions for your team
Over thirty distinct permissions, not one big admin switch
Permissions in Seaty are granular. There are over thirty distinct permissions across event, organisation, tour, and order management. You can build custom roles — Finance Manager, Box Office Staff, Marketing Assistant — with exactly the access they need, and nothing more.
Roles you design
Build your own roles with the permissions that match how your group actually works. Not a fixed list of tiers
Device accounts for scanning
Door staff sign in with an organisation passcode tied to a device account, not a full admin login. Devices carry an "is-a-device" marker the platform uses to restrict sensitive admin actions
Visibility of who did what
Order history shows which admin made which change, with timestamps, for accountability
How we handle email addresses
Email addresses are stored in the Seaty database, which lives on Microsoft Azure SQL with platform encryption at rest enabled (Transparent Data Encryption). Email values inside unsubscribe and preference URLs are additionally encrypted at the application layer so that those URLs cannot be reverse-engineered from server logs or browser history.
For mailshots, consent is captured at checkout across three independent categories — Marketing, Survey, and Event Updates. Bounces and spam complaints are auto-blocked. Every unsubscribe is logged with date, admin, and reason. For the wider lawful-basis picture see our UK GDPR guide for event organisers.
For mailshots, consent is captured at checkout across three independent categories — Marketing, Survey, and Event Updates. Bounces and spam complaints are auto-blocked. Every unsubscribe is logged with date, admin, and reason. For the wider lawful-basis picture see our UK GDPR guide for event organisers.
Visitor analytics without storing raw IPs
When a recipient opens or clicks a Seaty mailshot, we record the event for campaign reporting. For recipients who are not signed in, the visitor IP is hashed with SHA-256 and a per-environment salt before storage. We use the hash to deduplicate opens and clicks without storing the raw IP address. Signed-in recipients are tracked by user identifier instead, so their IP is not hashed at all.
Known bot user-agents are filtered out before analytics are recorded — search-engine crawlers, headless browsers, link-preview crawlers, and a long list of email-security scanners that pre-click links inside corporate inboxes — so the click-through and revenue numbers you see reflect real human visits.
Known bot user-agents are filtered out before analytics are recorded — search-engine crawlers, headless browsers, link-preview crawlers, and a long list of email-security scanners that pre-click links inside corporate inboxes — so the click-through and revenue numbers you see reflect real human visits.
Public pages live separately from your data
Public event listings and organisation pages are served from a read-only static cache held in Azure Blob Storage. A visitor browsing your event poster QR code, picking a date, or sharing your event on social media never touches the live database that holds order, member, or financial data.
The live database sits behind authentication. Admin actions — taking payments, editing orders, sending mailshots, running reports — require a signed-in session with the right permissions. The split means a spike in public traffic on event-launch day cannot reach the database that runs your box office.
The live database sits behind authentication. Admin actions — taking payments, editing orders, sending mailshots, running reports — require a signed-in session with the right permissions. The split means a spike in public traffic on event-launch day cannot reach the database that runs your box office.
Where your data lives
Seaty runs on Microsoft Azure in the UK South region. Application servers, the SQL database, and the blob storage containers that hold cached public pages and uploaded images all sit in UK South. Personal data does not leave the United Kingdom for routine processing. Where a sub-processor operates internationally — Stripe for card payments, Postmark for email, Apple, Google, or Microsoft for single sign-on, Dropbox for optional file integration — any cross-border transfer takes place under that provider's own documented UK GDPR transfer mechanism. The full list of sub-processors is in our Privacy Policy.
Errors and incident response
When the platform encounters an unexpected error, a fingerprint of the error type, a normalised version of the error message, and the request path is recorded so we can identify and fix issues. Identifying customer data is not part of the fingerprint. Repeated errors are deduplicated against the fingerprint so a single bug does not flood the report stream.
In the unlikely event of a personal data breach that poses a risk to your rights and freedoms, we notify the Information Commissioner's Office within 72 hours of becoming aware, as required by UK GDPR Article 33. Where the risk is high, we notify affected users directly. The full position is set out in our Privacy Policy.
In the unlikely event of a personal data breach that poses a risk to your rights and freedoms, we notify the Information Commissioner's Office within 72 hours of becoming aware, as required by UK GDPR Article 33. Where the risk is high, we notify affected users directly. The full position is set out in our Privacy Policy.
What this page doesn't claim.
Seaty is a small UK platform, not an enterprise security vendor. We are not SOC 2 audited, we are not ISO 27001 certified, and we do not hold a PCI DSS attestation in our own name — that is Stripe's job. If your procurement process requires a vendor with those certifications, Seaty is not the right fit and we will tell you that honestly.
We rely on Stripe for PCI scope on payments and on Microsoft Azure for the underlying platform compliance. Within that we apply the controls described above. The most important thing you can do as an organiser is keep your sign-in credentials safe, give team members only the permissions they need, and reach out at Support@Seaty.co.uk if anything looks off.
We rely on Stripe for PCI scope on payments and on Microsoft Azure for the underlying platform compliance. Within that we apply the controls described above. The most important thing you can do as an organiser is keep your sign-in credentials safe, give team members only the permissions they need, and reach out at Support@Seaty.co.uk if anything looks off.
Related reading
For the wider regulatory picture, see our guides on UK GDPR for event organisers and charity event ticketing. For the legal text of how we process your data, see our Privacy Policy.
