How our waiver system actually works
SHA-256 integrity hashing. Structural minor/guardian handling. Automatic revocation. Not marketing fluff. Here's exactly what happens under the hood.
What is a waiver in wakesys?
Every participant at a park must sign a Release of Liability (waiver) before they can participate. The system enforces this at every entry point: online booking, onsite registration, POS check-in, and ticket claiming. A waiver is always tied to a specific park and a specific user. If a user visits multiple parks on the platform, they sign a separate waiver for each park.
How does the waiver signing flow work?
The signing process has 6 steps, triggered after registration, booking, or ticket claiming.
Trigger
After registration, booking, or ticket claiming, the user is redirected to the compliance page.
Validation
The system checks whether the user already has a valid waiver for that park. If they do, the compliance step is skipped entirely.
Presentation
The user sees the park's full Release of Liability text, a summary of their personal details, and is asked to provide their address, type their full legal name, draw their signature, and confirm acceptance.
Submission
On submit, the system captures and stores all waiver data including cryptographic hashes.
PDF generation
A background job generates a PDF copy of the signed waiver and stores it alongside the waiver record.
Redirect
The user is sent back to wherever they came from: booking confirmation, registration, or claim overview.
What data does each waiver capture?
Every signed waiver records 16 data points for legal protection and forensic traceability.
Are wakesys waivers tamper-proof?
Yes. The system computes a SHA-256 hash over a canonicalized JSON representation of all waiver data: name, email, phone, date of birth, document text, signature name, IP, user agent, and address. This hash is stored on the waiver record and printed on the PDF.
If any field in the waiver record were ever altered after signing, the hash would no longer match. This provides cryptographic proof that the stored waiver data has not been tampered with since the moment of signing.
The signature image has its own separate SHA-256 checksum, computed at upload time. This independently proves the signature file has not been modified.
This is stronger than Smartwaiver's document ID approach (an opaque identifier, not cryptographic proof) and ROLLER's encryption-only approach (no publicly documented per-waiver hash).
How does electronic signature consent work?
A drawn signature on a phone is only half of it. The other half is proving the guest agreed to sign electronically at all, and knew what they gave up by not signing on paper. wakesys asks for that consent explicitly, in the same step as the signature, and stores the answer with the record.
What the guest agrees to
- They have read the release of liability and consent to signing this document electronically.
- They could sign a paper copy instead, and by consenting they waive that right.
- They may request a paper copy of any record at any time, at no charge, with no special hardware or software required to view it.
- Consent continues until they withdraw it in writing, and there is no penalty for withdrawing.
A line recording who consented and on what date is written onto the generated PDF, next to the signature, the full document text and the integrity hashes. The consent travels with the document instead of living only in a database row.
This wording follows standard US electronic signature practice. It does not make a release enforceable on its own. What your release says, and whether a court in your state will enforce it, is a question for your own attorney.
How does wakesys handle waivers for minors?
A minor (anyone under the park's legal age, typically 18) cannot sign their own waiver and cannot be the booking owner. A parent or legal guardian must create their own account, sign the waiver on behalf of the minor, and add the minor as a participant.
5 independent age verification checkpoints
Online booking checkout
A Zod validation schema checks the date of birth against the park's legal age. Underage submissions are rejected with clear guidance for both minors and confused parents.
Onsite registration
The first screen asks: Adult or Child? Selecting Child forces the adult to register first.
Ticket claiming
When claiming a ticket for a child, the system requires an adult to be identified first.
POS sales
When staff requests a waiver for a minor, an overlay requires them to search for and select the responsible adult first.
Waiver signing
The signedBy field always points to the adult who signed, never the child. The PDF clearly shows 'Signed for: [child]' and 'Signed by: [parent]'.
Signing for a child who is not yours
Age checks stop a minor from signing for themselves. They do nothing about an adult signing for a child they have no legal authority over, which at a family entertainment center happens every weekend. So before a guest can assign a ticket to someone else's child, a full screen dialog states who counts as a legal guardian (parent, legal guardian, foster parent, court-appointed guardian), warns that signing without that authority may constitute misrepresentation, invalidate the waiver and expose the signer to civil liability, and points them at the invite link so the real parent can sign from their own phone.
The confirmation fires at three entry points: claiming a ticket from an online booking, registering at the on-site kiosk, and adding a child to an existing account. In the booking flow, cancelling returns the guest to the screen where the invite link can be shared. Parks that do not collect a waiver get the same dialog worded for registration rather than signing.
The signedBy and userId are separate first-class fields in the data model. The signer-to-participant relationship is structural, queryable, and enforced by code, not just a text-level distinction on a form like Smartwaiver or ROLLER.
Does wakesys automatically revoke waivers?
Yes. When staff edits a user's profile via POS, the waiver is automatically invalidated and must be re-signed with current data. Staff can also explicitly request a new waiver, which revokes the current one and sends a compliance request to the tablet.
What triggers re-signing
- Profile edit via POS: any change to a user's profile revokes their waiver automatically
- Staff-initiated re-request via POS
What does NOT trigger re-signing
- Booking a new session at the same park
- Claiming additional tickets at the same park
- Logging in from a different device
Every re-signing creates a new WaiverVersion. All previous versions are preserved and queryable. The complete signature history for a user at a park is always available.
How does this compare to other waiver systems?
| Feature | wakesys | Smartwaiver | ROLLER |
|---|---|---|---|
| Drawn signature capture | |||
| Full document text preserved per signing | |||
| SHA-256 integrity hash per waiver | (doc ID) | ||
| SHA-256 checksum on signature image | |||
| IP address captured | |||
| Browser user agent captured | |||
| PDF generation per waiver | |||
| Separate signedBy / signedFor in data model | No (form-level) | No (form-level) | |
| Per-user waiver version history | |||
| Automatic revocation on profile change | |||
| Age verification at booking checkout | N/A (no booking) | At waiver level | |
| Age verification at onsite registration | N/A | At waiver level | |
| Real-time POS waiver request | N/A (no POS) | ||
| Guardian vs non-guardian tracking | (template only) | ||
| Underage self-booking prevention | (3-layer interstitial) | (blocks submission) | |
| Guardianship confirmation before signing for another's child | (3 entry points) | ||
| Electronic signature consent recorded on the PDF | |||
| Pre-filled on-site re-signing | |||
| Global child deduplication | |||
| Waiver expiration with reminders | |||
| SOC 2 Type II certified |
Known limitations
We believe in being transparent about what the system does and doesn't do.
Age verification is not identity verification. There is no ID upload or biometric check. The system relies on truthful input, consistent with how all online booking systems operate.
The guardianship confirmation is an attestation, not a verification. No system can check a custody order at booking time. What it does is turn a checkbox nobody reads into an explicit, deliberate and timestamped claim, and route the guest to the person who can actually sign.
PDFs are generated asynchronously. The database record with its integrity hash is the authoritative record, not the PDF.