How payments work
When someone buys an event ticket through Flok, they are redirected away from Flok entirely to a checkout page hosted by the club's own Stripe or Payrexx account. Flok's page never renders a card number field, a CVV field, or any other cardholder-data input — there is no iframe carrying a payment form either. The buyer types their card details directly into Stripe's or Payrexx's own page, on their own infrastructure.
Once payment completes, the buyer is sent back to Flok — but Flok doesn't just trust that redirect. A server-side step independently re-confirms the payment with the provider's own API before a ticket is issued. For Payrexx specifically, whose webhooks carry no signature, this re-verification is not optional: Flok never acts on a webhook payload alone.
Because no cardholder data ever reaches Flok's browser code or server code, every club selling tickets through Flok qualifies for SAQ A — the shortest PCI DSS self-assessment available, reserved for merchants using a fully outsourced, redirect-only payment page. See the responsibility matrix below for the detail, and our tenant PCI guide for what that means for you as an organiser.
Subprocessors
Everyone who touches Flok data or infrastructure on our behalf, and why.
| Provider | Purpose | Location | Certifications |
|---|---|---|---|
| Vercel | Static site hosting, object storage (encrypted backups) | Frankfurt, DE (eu-central-1) | Publishes its own SAQ-D AoC and a customer responsibility matrix via its Trust Center — security.vercel.com |
| Supabase | Database, authentication | Zürich, CH | Per Supabase's own published certifications — supabase.com/security |
| Stripe | Payment processing (each club's own connected account) | Per club's Stripe account | PCI DSS Level 1 Service Provider — stripe.com/docs/security |
| Payrexx | Payment processing (each club's own connected account) | St. Gallen, CH | PCI DSS Level 1 Service Provider — see payrexx.com |
| Resend | Transactional email, newsletter delivery | Ireland, EU (eu-west-1) | See Resend's own documentation |
| Sentry | Error tracking (no cardholder data; scrubbed of common PII patterns) | Germany, EU | Per Sentry's own published certifications |
| Google (Gemini API) | Pilot AI features — drafting, matching, summarising, always with a human approving before anything sends or charges | Google Cloud (region managed by Google) | Per Google Cloud's own published certifications |
Data residency
Member and club data lives in Flok's Supabase database in Zürich, Switzerland. Static assets and encrypted backup files are stored in Frankfurt, Germany. Both locations are within the scope of the Swiss Federal Act on Data Protection (nDSG) and the EU GDPR. Cardholder data never reaches either location — see How payments work.
Backups
The database is backed up twice daily, encrypted with GPG before it ever leaves the backup job, and stored in a private object store independent of the primary database provider — so a problem with one doesn't take out the other. Backups are kept for 60 days and pruned automatically after that. The restore process is a documented, tested procedure — including specific issues found and fixed during a real restore run, not just a description of how it's supposed to work.
Authentication
Members authenticate with a passwordless one-time code sent to their email — no password to reuse or leak. Codes are valid for 10 minutes and lock out after 5 incorrect attempts. Club staff and admin accounts can additionally use WebAuthn passkeys — hardware-backed, phishing-resistant login.
Shared responsibility matrix
| Requirement | Provider | Flok | You (tenant) | Notes |
|---|---|---|---|---|
| Loading… | ||||
Certifications held by our providers
Flok does not hold these certifications itself — they belong to the providers listed above, who each publish and maintain their own attestations:
- Stripe — Security at Stripe
- Payrexx — payrexx.com
- Vercel Trust Center
- Supabase — Security & compliance
Security contact
Found a security issue, or think you have? Email security@getflok.app. We commit to acknowledging a genuine report within 2 business days and will keep you updated as we investigate and fix it. Please report privately rather than opening a public issue, and give us a reasonable window to fix something before disclosing it — we won't take legal action against good-faith security research conducted this way.