SHA-256-Integritäts-Hashing. Strukturelle Minderjährigen-/Erziehungsberechtigten-Verwaltung. Automatischer Widerruf. Kein Marketing-Blabla — hier erfährst du genau, was unter der Haube passiert.
Jeder Teilnehmer in einem Park muss vor der Teilnahme einen Haftungsausschluss (Waiver) unterschreiben. Das System erzwingt dies an jedem Einstiegspunkt — Online-Buchung, Vor-Ort-Registrierung, Kassensystem-Check-in und Ticket-Einlösung. Ein Waiver ist immer an einen bestimmten Park und einen bestimmten Nutzer gebunden. Wenn ein Nutzer mehrere Parks auf der Plattform besucht, unterschreibt er für jeden Park einen separaten Waiver.
Der Unterschriftsprozess hat 6 Schritte und wird nach der Registrierung, Buchung oder Ticket-Einlösung ausgelöst.
Nach der Registrierung, Buchung oder Ticket-Einlösung wird der Nutzer zur Compliance-Seite weitergeleitet.
Das System prüft, ob der Nutzer bereits einen gültigen Waiver für diesen Park hat. Falls ja, wird der Compliance-Schritt komplett übersprungen.
Der Nutzer sieht den vollständigen Haftungsausschlusstext des Parks, eine Zusammenfassung seiner persönlichen Daten und wird aufgefordert, seine Adresse anzugeben, seinen vollständigen rechtlichen Namen einzutippen, seine Unterschrift zu zeichnen und die Annahme zu bestätigen.
Beim Absenden erfasst und speichert das System alle Waiver-Daten einschließlich kryptografischer Hashes.
Ein Hintergrund-Job erzeugt eine PDF-Kopie des unterschriebenen Waivers und speichert sie zusammen mit dem Waiver-Datensatz.
Der Nutzer wird dorthin zurückgeleitet, woher er kam — Buchungsbestätigung, Registrierung oder Einlösungsübersicht.
Jeder unterschriebene Waiver erfasst 15 Datenpunkte für rechtlichen Schutz und forensische Nachverfolgbarkeit.
Ja. Das System berechnet einen SHA-256-Hash über eine kanonisierte JSON-Darstellung aller Waiver-Daten — Name, E-Mail, Telefon, Geburtsdatum, Dokumenttext, Unterschriftsname, IP, User Agent und Adresse. Dieser Hash wird im Waiver-Datensatz gespeichert und auf dem PDF gedruckt.
Wenn ein Feld im Waiver-Datensatz nach der Unterschrift jemals geändert würde, würde der Hash nicht mehr übereinstimmen. Das liefert kryptografischen Beweis, dass die gespeicherten Waiver-Daten seit dem Moment der Unterschrift nicht manipuliert wurden.
Das Unterschriftsbild hat eine eigene separate SHA-256-Prüfsumme, die zum Zeitpunkt des Uploads berechnet wird. Das beweist unabhängig, dass die Unterschriftsdatei nicht verändert wurde.
Das ist stärker als Smartwaivers Dokument-ID-Ansatz (eine undurchsichtige Kennung, kein kryptografischer Beweis) und ROLLERs reiner Verschlüsselungsansatz (kein öffentlich dokumentierter Hash pro Waiver).
Ein Minderjähriger (jeder unter dem gesetzlichen Alter des Parks, typischerweise 18) kann seinen eigenen Waiver nicht unterschreiben und kann nicht der Buchungsinhaber sein. Ein Elternteil oder Erziehungsberechtigter muss ein eigenes Konto erstellen, den Waiver im Namen des Minderjährigen unterschreiben und den Minderjährigen als Teilnehmer hinzufügen.
Ein Zod-Validierungsschema prüft das Geburtsdatum gegen das gesetzliche Alter des Parks. Minderjährige Einreichungen werden mit klarer Anleitung für Minderjährige und verunsicherte Eltern abgelehnt.
Der erste Bildschirm fragt: Erwachsener oder Kind? Bei Auswahl von Kind muss sich zuerst der Erwachsene registrieren.
Beim Einlösen eines Tickets für ein Kind muss zuerst ein Erwachsener identifiziert werden.
Wenn das Personal einen Waiver für einen Minderjährigen anfordert, erscheint ein Overlay, das zuerst die Suche und Auswahl des verantwortlichen Erwachsenen erfordert.
Das signedBy-Feld zeigt immer auf den Erwachsenen, der unterschrieben hat — nie auf das Kind. Das PDF zeigt deutlich 'Unterschrieben für: [Kind]' und 'Unterschrieben von: [Elternteil]'.
signedBy und userId sind separate erstklassige Felder im Datenmodell. Die Beziehung zwischen Unterzeichner und Teilnehmer ist strukturell, abfragbar und durch Code erzwungen — nicht nur eine textliche Unterscheidung auf einem Formular wie bei Smartwaiver oder ROLLER.
Ja. Wenn das Personal ein Nutzerprofil über das Kassensystem bearbeitet, wird der Waiver automatisch ungültig und muss mit aktuellen Daten erneut unterschrieben werden. Das Personal kann auch explizit einen neuen Waiver anfordern, was den aktuellen widerruft und eine Compliance-Anfrage an das Tablet sendet.
Jede Neu-Unterschrift erstellt eine neue WaiverVersion. Alle vorherigen Versionen bleiben erhalten und sind abfragbar. Die vollständige Unterschriftshistorie eines Nutzers in einem Park ist jederzeit verfügbar.
| Feature | wakesys | Smartwaiver | ROLLER |
|---|---|---|---|
| Gezeichnete Unterschriftserfassung | |||
| Vollständiger Dokumenttext pro Unterschrift gespeichert | |||
| SHA-256-Integritäts-Hash pro Waiver | (doc ID) | ||
| SHA-256-Prüfsumme auf Unterschriftsbild | |||
| IP-Adresse erfasst | |||
| Browser User Agent erfasst | |||
| PDF-Erzeugung pro Waiver | |||
| Separates signedBy / signedFor im Datenmodell | Nein (Formular-Ebene) | Nein (Formular-Ebene) | |
| Waiver-Versionshistorie pro Nutzer | |||
| Automatischer Widerruf bei Profiländerung | |||
| Altersverifizierung beim Buchungs-Checkout | Nicht zutreffend (keine Buchung) | Auf Waiver-Ebene | |
| Altersverifizierung bei Vor-Ort-Registrierung | N/A | Auf Waiver-Ebene | |
| Echtzeit-Waiver-Anforderung im Kassensystem | Nicht zutreffend (kein Kassensystem) | ||
| Waiver-Ablauf mit Erinnerungen | |||
| SOC 2 Type II zertifiziert |
Wir glauben an Transparenz darüber, was das System kann und was nicht.
Altersverifizierung ist keine Identitätsverifizierung. Es gibt keinen Ausweis-Upload oder biometrischen Check — das System verlässt sich auf wahrheitsgemäße Angaben, wie es bei allen Online-Buchungssystemen üblich ist.
PDFs werden asynchron erzeugt. Der Datenbank-Datensatz mit seinem Integritäts-Hash ist der maßgebliche Datensatz, nicht das PDF.