Privacy – Saalpass

Saalpass is a ticketing platform for events run by clubs and associations. This notice describes which personal data the platform actually processes, for what purpose, on what legal basis, who receives it and how long it is kept. It is written against what the software really does — not against a template.

Two groups are affected, and they are treated differently: guests who buy a ticket, and organizers (associations and their staff) who publish and manage events.

This is a translation of the German original. In the event of any discrepancy, the German version at saalpass.de/datenschutz prevails.

Controller

Peter Schick
Gutenbergstrasse 25
90513 Zirndorf
Germany
Email: PeterSchick@gmx.net
Contact form: saalpass.de/kontakt

This notice covers the domain saalpass.de and its subdomains (app., tickets., scan.).

Data protection officer

No data protection officer has been appointed, and none is required. Saalpass is run by a single individual; there are not at least 20 people permanently engaged in processing personal data, and there is no large-scale processing of special categories of data and no commercial processing for the purpose of transfer (section 38 BDSG). Please direct all data protection matters to the address above.

Saalpass and the organizers: who is responsible for what

You do not buy a ticket from Saalpass, but from the respective organizer. Saalpass provides the technology: seating plan, cart, checkout, ticket delivery, admission control.

This matters most for payments. Payment is processed as a so-called direct charge through the organizer's own Stripe account — the money goes straight to their account, and Saalpass only retains a service fee as a platform fee. The payment therefore appears in the organizer's Stripe dashboard, including the email address you provided (it is passed to Stripe as the receipt address). For this payment data the organizer is a controller in their own right, not merely a processor acting for Saalpass. They are the right contact for access or erasure of the payment data held by them and in their Stripe account; we will name the responsible organizer on request.

For all other processing on this platform — order, ticket, email delivery, logs — Saalpass is the controller. The legal classification of the interface between the two (processing on behalf under Art. 28 GDPR, or joint controllership under Art. 26 GDPR) is currently being reviewed and settled contractually.

Processing activities in detail

Visiting the website

When a page is requested, the web server produces log entries recording the IP address of the requesting device, the time, the address requested and the HTTP status code. These entries live in the server's log stream, not in the application database, and are not combined with order or account data.

Purpose: operation, troubleshooting, detection and defence against attacks.
Legal basis: Art. 6(1)(f) GDPR. The legitimate interest is the secure and functioning operation of the service.
Recipients: the hosting provider as a processor.

Cart and seat selection

So that your cart survives across page loads, the server issues a random token (the "cart token"). It is stored in a cookie named prunk_cart and, together with a timestamp, in a Redis cache. The token contains no information about you; it merely links your selection to your session.

When you select seats, a temporary hold is stored for each one (seat ID, cart token, expiry time). It prevents the same seat from being sold twice.

Purpose: shopping cart, binding seat reservation during purchase.
Legal basis: Art. 6(1)(b) GDPR (steps taken at your request prior to entering into a contract), and section 25(2) no. 2 TDDDG for the cookie — it is strictly necessary to provide the service you expressly requested and therefore requires no consent.
Retention: the cart token expires after 24 hours. Seat holds expire after 10 minutes by default; a background job deletes expired holds from the database every 30 seconds.

Checkout queue

Only one guest checks out at a time per event date. A queue entry is kept for this, holding the event date ID, the cart token, a status and timestamps. Your browser sends a regular heartbeat while you wait, so that your slot is not blocked if you abandon the purchase.

Purpose: an orderly purchase flow and avoidance of double sales at times of high demand.
Legal basis: Art. 6(1)(b) GDPR.
Retention: the entry remains as a completed record after checkout or expiry. No automatic deletion is currently in place.

Ticket purchase and order processing

To buy a ticket we need your email address. No postal address or phone number is collected or stored for a ticket purchase.

Guest names — only for personalised events. Some organizers issue personalised tickets, for example for members' meetings or when names are checked at the door. Where an event is set up that way, the checkout asks for the name of the guest who will use each seat. The name is stored with the order line, printed on that ticket and shown to the organizer's door staff when the ticket is scanned. For all other events no name is requested and none is stored. You can tell that an event is personalised because the checkout shows the name fields.

Stored with the order are: email address, cart token, the chosen event date, the chosen seats and ticket types, prices, currency, the service fee at the rate applicable at the time of purchase, the order status, the identifier of the Stripe payment and timestamps. For each seat purchased, a ticket record is created with a random ticket identifier, a QR checksum, the time it was sent and — after admission — the time it was scanned.

IP address of the order. We additionally store the IP address the purchase was made from. It serves one purpose only: defending against unjustified chargebacks. Where a card payment is later disputed ("I did not authorise this"), the IP address of the purchase is among the items the payment provider expects in the response. It is not used to analyse your behaviour, to determine your location or for advertising.

Purpose: performance of the ticket purchase contract, ticket issuance, admission, handling of refunds. For the IP address separately: establishing and defending legal claims, in particular presenting evidence in chargeback cases.
Legal basis: Art. 6(1)(b) GDPR; additionally Art. 6(1)(c) GDPR for the parts subject to statutory retention. For the IP address, Art. 6(1)(f) GDPR — the legitimate interest being defence against unjustified chargebacks, the loss from which otherwise stays with the merchant.
Retention: order data is not currently deleted automatically. Where it forms part of tax-relevant records, the statutory retention periods under section 147 AO and section 257 HGB apply (eight or ten years depending on the type of record). A deletion policy with fixed periods for the remaining data has not yet been established; until then we delete on your request, unless a retention obligation prevents it. The IP address follows the same period as the admission scan records: 180 days after the event date, after which it is no longer needed. It is not a tax-relevant record, so the longer commercial and tax retention periods do not apply to it. A daily clean-up job deletes it automatically once that period has passed.

Payment processing via Stripe

Payment is handled by Stripe. Your card details never reach our servers: you enter them into a payment form provided by Stripe that runs directly in your browser. To do this the checkout page loads a script from js.stripe.com — your browser therefore connects to Stripe directly, transmitting technical data such as your IP address and browser information. Stripe also uses this for fraud detection.

We transmit to Stripe the amount, the currency, your email address as the receipt address and our internal identifiers for the order and the event date. In return we store the payment identifier, the payment status, the amount and a technical key for the payment form. Callbacks from Stripe (webhooks) are logged including their content in order to prevent duplicate processing; these may contain further details of the payment.

Because payment is charged as a direct charge to the organizer's Stripe account, Stripe acts as the organizer's payment service provider in that respect, and the organizer is a controller in their own right (see above).

Purpose: payment processing, refunds, fraud prevention, settlement of the service fee.
Legal basis: Art. 6(1)(b) GDPR for the processing itself, Art. 6(1)(f) GDPR for fraud prevention.
Recipients: Stripe Payments Europe, Ltd. (Ireland) and affiliated companies including Stripe, Inc. in the USA; the respective organizer.
Third country: see "Transfers to third countries".

Ticket delivery by email

After successful payment you receive your tickets by email. The PDF contains the event name, the date and time, the venue and organizer, the seat, the ticket category, the price, the order number, the ticket identifier and the QR code for admission. If the organizer collects guest names, the ticket also carries the name of the guest it was issued to. Your email address is deliberately not printed on the ticket, because tickets are usually passed on to the guests.

Purpose: delivery of the service purchased.
Legal basis: Art. 6(1)(b) GDPR.
Recipients: the provider of the outgoing SMTP mail server, as a processor.

Guest list for the organizer

Organizers can view and print the list of expected guests for each of their event dates. Per paid ticket it shows the seat and table, the ticket category, the order number, the email address of the order, the admission timestamp (once scanned) and — for events that collect names — the guest's name. Unpaid orders and refunded seats are not listed.

Access is limited to signed-in accounts of that organizer, and technically restricted to their own event dates. The list serves the running of the event: seating, admission and catering.

Purpose: running the booked event, admission control, seating.
Legal basis: Art. 6(1)(b) GDPR towards the guest, Art. 6(1)(f) GDPR for the organizer's legitimate interest in running the event in an orderly way.
Recipients: the respective organizer and the admission and service staff they employ.
Note: because personal data of guests is handed to the organizer here, this processing belongs to the interface described above, whose legal classification (Art. 28 or Art. 26 GDPR) is currently being assessed and settled contractually.

Email delivery log

Every send attempt — ticket email, newsletter confirmation, contact enquiry — writes an entry to our log. Recorded are the outcome (sent, failed, or written to the development outbox), the recipient address, the subject line, the type of mail, the number of attachments and, on failure, the technical error message. The body of the message is not stored. The entries are visible in the backoffice at /admin/mails; only Saalpass administrators have access.

One limitation we state openly: if a send fails, or if no outgoing mail server is configured, the message is additionally written in full, including its body text, to a file on the server so that the event remains traceable.

Purpose: proof of whether a message was delivered, and troubleshooting of delivery problems — for a ticket delivery this is often the only way to investigate a complaint.
Legal basis: Art. 6(1)(f) GDPR.
Retention: currently no automatic deletion.

Admission control and the check-in app

At the door, the QR code on your ticket is scanned. Stored are the ticket identifier, an identifier of the scanning device, the result of the check (valid, already used, refunded, unknown) and the time. The time of admission is also recorded on the ticket.

The check-in app works offline. To do so it stores on the door staff's device a device login token, the chosen language and a scan history containing the scanned ticket identifier, the result and the time. These ticket identifiers are pseudonymous — on their own they contain no name and no address, but they can be linked to an order in our database. They remain on the device until cleared using the "clear history" function; there is no automatic deletion. For personalised events the door staff are additionally shown the guest's name when scanning, so it can be checked against the person at the door; the name is not stored on the device.

Purpose: access control, prevention of repeated admission on the same ticket, operation of the app without a network connection inside the venue.
Legal basis: Art. 6(1)(b) GDPR (admission is performance of the ticket contract) and Art. 6(1)(f) GDPR (protection against ticket misuse).
Retention: the server-side scan data (ticket identifier, device identifier, result, time) is kept for up to 180 days after the event date and may be deleted after that — the reason is that these records are the strongest evidence that a guest actually showed up, should a card payment be disputed months after the event. A cleanup job that deletes it automatically once that period has passed.

Contact form

In the contact form at /kontakt you provide a name, email address, subject and your message, optionally an order number, and confirm by ticking a box that we may contact you about your enquiry.

These details are not stored in our database. They are sent solely as an email to a fixed mailbox configured by the operator — the recipient is never derived from your input. The delivery log described above retains the recipient mailbox and the subject line; the subject line contains the subject you typed.

To prevent abuse we limit submissions to five per hour and IP address. For this, the times of your submissions within the last hour are held together with your IP address in the server's memory. They are never written to disk, drop out of the count as the hour elapses, and are lost on every restart of the server. A hidden extra field (a honeypot) identifies automated submissions; these are discarded without an email being sent.

Purpose: handling your enquiry; defence against spam and bulk submissions.
Legal basis: Art. 6(1)(b) GDPR where your enquiry concerns an order or the conclusion of a contract, otherwise Art. 6(1)(f) GDPR (responding to enquiries); the confirmation checkbox additionally documents your consent under Art. 6(1)(a) GDPR. The rate limit relies on Art. 6(1)(f) GDPR.
Retention: the enquiry stays in our mailbox for as long as is necessary to deal with it and keep it traceable.

Newsletter with double opt-in

The newsletter uses a double opt-in procedure. After you enter your email address you receive a message containing a confirmation link; the subscription takes effect only when you click it. Stored are your email address, the confirmation status, a confirmation token, the time it was sent, the number of resends and the time of confirmation. The confirmation link expires after 24 hours; at most three confirmation emails are sent to the same address within 24 hours.

Purpose: sending the newsletter; the confirmation data serves as proof that the subscription came from you.
Legal basis: Art. 6(1)(a) GDPR (your consent); Art. 6(1)(f) GDPR for keeping the record of that consent.
Withdrawal: you may withdraw your consent at any time with effect for the future. Every newsletter mail carries an unsubscribe link; one click is enough and no reason is required. Many mail programs additionally show their own unsubscribe button, which uses the same route. An informal message to PeterSchick@gmx.net or via the contact form also works.
After unsubscribing your address stays on record as unsubscribed, so that we can evidence the withdrawal and do not accidentally write to you again. Nothing is sent to an unsubscribed address. On request we delete the entry entirely.

Applying as an organizer

Associations wishing to use Saalpass get in touch via /veranstalter — either with a short enquiry or with the full application form. Stored are the name of the organization, the name of the contact person, an email address, optionally a phone number, the preferred means of contact, the type of event, a website, a message, the preferred language and any uploaded logo, together with the type of form, the processing status and timestamps.

Unlike the contact form, these details are stored in our database and are visible in the backoffice. Two messages are also sent: a notification to the operator and an acknowledgement of receipt to the address provided. Both appear in the email delivery log described above. This form, too, is protected against bulk submissions by a per-IP address limit which, as with the contact form, is held only in memory.

Purpose: review and handling of the enquiry, establishing the business relationship; defence against automated submissions.
Legal basis: Art. 6(1)(b) GDPR (pre-contractual steps); Art. 6(1)(f) GDPR for the rate limit.
Retention: currently no automatic deletion. Rejected or unpursued enquiries are deleted on request.

Organizer and backoffice accounts

For organizer accounts and internal backoffice accounts we store the email address, a password hash (the password itself is never stored; it is derived using PBKDF2 with 120,000 iterations), the role, the activation status, the association the account belongs to, and timestamps. Each login creates a session, of which only a hash of the session token and the expiry date are stored; backoffice sessions expire after 12 hours by default.

Failed login attempts are counted per combination of IP address and email address: after five failures within 15 minutes, login is temporarily blocked. These counters, too, exist only in memory and are not stored permanently.

Purpose: access to the management interface, protection against systematic password guessing.
Legal basis: Art. 6(1)(b) GDPR for running the account, Art. 6(1)(f) GDPR for login throttling and session management.

Audit log of significant operations

Significant operations are recorded in an audit log: the creation of an order, the start and refresh of a payment, every admission scan and changes to the seating plan. An entry contains the type of operation, the object affected, the actor (such as the cart token or the scanning device), the source and further details of the operation. When an order is created this includes the guest's email address. Administrators can export this log, filtered, as JSON or CSV.

Purpose: traceability of bookings, payments and admissions, resolution of disputes and errors, security of the system.
Legal basis: Art. 6(1)(f) GDPR; where the operations concern bookings, additionally Art. 6(1)(c) GDPR.
Retention: currently no automatic deletion.

Checkout measurements

To identify where a purchase stalls or breaks off, measurement points are recorded for each checkout: order number, cart token, the stage of the process (start, refresh, completion, failure), the status, the time taken in milliseconds and supplementary technical details. This data serves only the technical evaluation of the purchase flow, not the analysis of your behaviour.

Purpose: monitoring and improving the reliability of checkout.
Legal basis: Art. 6(1)(f) GDPR.
Retention: currently no automatic deletion.

Cookies and storage on your device

Saalpass sets exactly one cookie:

prunk_cart — the cart token. A random value containing no information about you. Readable only by the server (HttpOnly), set to SameSite=Lax, transmitted only over HTTPS in production (Secure), lifetime 24 hours.

The cookie is strictly necessary to provide the service you requested and therefore requires no consent under section 25(2) no. 2 TDDDG. For the same reason there is no cookie banner on this site — there would be nothing to consent to.

In addition, your browser stores data locally on your device in order to run the interface. It does not leave your device except where stated otherwise:

in the shop: a cart identifier generated per event date,
in the backoffice and the organizer interface: the session token, the language selection and seating plan editor settings,
in the check-in app: the device login token, the language selection and the scan history (see "Admission control and the check-in app"). The scan history is transmitted to the server when it is synchronised.

No analytics, no tracking, no advertising

No analytics or tracking tool is embedded in this website — no Google Analytics, no Matomo, nothing comparable. There are no advertising networks, no profiling, no retargeting and no disclosure of data for advertising purposes. Nor is there any automated decision-making, including profiling, within the meaning of Art. 22 GDPR.

The website also loads no content from third-party servers: fonts, images and scripts are served from our own server. The only exception is the Stripe payment form on the checkout page described above.

Recipients and processors

Beyond the parties named with the individual processing activities above, we disclose no data. The following are used:

Stripe — payment processing. Stripe Payments Europe, Ltd. (Dublin, Ireland) and affiliated companies including Stripe, Inc. (USA). For a payment charged to the organizer's account, Stripe is the organizer's payment service provider; alongside that we have our own contractual relationship with Stripe for the platform fee.
Outgoing mail server (SMTP) — delivery of ticket, confirmation and contact emails, as a processor. Enquiries from the contact form go to a mailbox at 1&1 Mail & Media GmbH (GMX).
Hosting — operation of the application, database and cache, as a processor.
The respective organizer — as a controller in their own right for the payment, see above.

We disclose data to public authorities and courts only where we are legally obliged to do so.

Transfers to third countries

A transfer to a country outside the EU and the EEA takes place in connection with Stripe: although the contracting party is the Irish Stripe Payments Europe, Ltd., the US company Stripe, Inc. is involved in the processing. This applies both to the payment itself and to loading the payment form in your browser.

The transfer relies on the European Commission's adequacy decision for the EU-US Data Privacy Framework (Art. 45 GDPR), to the extent the receiving entity is certified under it, and additionally on the European Commission's standard contractual clauses (Art. 46(2)(c) GDPR). A residual risk remains: US authorities may under certain conditions access data processed there, and the legal remedies against this do not in every respect match the European standard.

All other processing takes place on servers within the EU.

Your rights

You have the following rights in relation to the controller:

Access (Art. 15 GDPR) — you may find out whether and which data we process about you, and obtain a copy of it.
Rectification (Art. 16 GDPR) — we must correct inaccurate data and complete incomplete data.
Erasure (Art. 17 GDPR) — unless a statutory retention obligation prevents it.
Restriction of processing (Art. 18 GDPR) — for example while we verify the accuracy of data you contest.
Data portability (Art. 20 GDPR) — you receive the data you provided to us on the basis of a contract or of consent, in a common, machine-readable format.
Objection (Art. 21 GDPR) — you may object, on grounds relating to your particular situation, to any processing we base on a legitimate interest (marked throughout this notice as Art. 6(1)(f) GDPR). We will then stop the processing unless we can demonstrate compelling legitimate grounds.
Withdrawal of consent (Art. 7(3) GDPR) — at any time with effect for the future. Processing carried out before the withdrawal remains lawful. This concerns the newsletter in particular.

An informal message to PeterSchick@gmx.net or via the contact form is sufficient. We usually reply within two working days, and at the latest within the statutory period of one month. Since the only thing we know about a guest is their email address, we identify a request by that address; where we have doubts about your identity we may ask for additional details, such as an order number.

Please note that we can give only limited information about payment data held in the organizer's Stripe account — the organizer is responsible for that. We will name them on request.

Lodging a complaint with a supervisory authority

Without prejudice to any other remedy, you have the right to lodge a complaint with a data protection supervisory authority (Art. 77 GDPR). Because our seat is in Zirndorf, the competent authority is:

Bayerisches Landesamt für Datenschutzaufsicht (BayLDA)
Promenade 18, 91522 Ansbach, Germany
www.lda.bayern.de

You may also contact the supervisory authority of your habitual residence or place of work.

Data security

The connection to the website is encrypted with TLS. Passwords are never stored in plain text, only as a PBKDF2 hash with 120,000 iterations; of session tokens we likewise store only a hash. The cart token in the cookie cannot be read by JavaScript. Access to the backoffice and organizer interface is separated by role, login attempts are throttled, and payment data never reaches our systems in the first place.

No one can guarantee complete security of data transmission over the internet; absolute protection is not possible.

Changes to this privacy notice

If the processing changes — because a feature is added or a service provider is replaced — we will update this text. The version published here is the one that applies.

The German original is available at /datenschutz and prevails in the event of any discrepancy.

Last updated: 16 August 2026