—Help
The PDF certificate is more than a printed acknowledgment. It carries three independent integrity checks that a stranger can verify cold — without an account, without access to your dashboard, without seeing any guest information.
At sign time, we serialize the exact packet the guest agreed to (rules + fees + welcome + property identity) and take SHA-256 over the JSON. That hash is stored on the immutable snapshot row and printed on the certificate.
If you edit the live packet later, the hash on this certificate doesn't change — the snapshot is frozen at sign time. A claims reviewer can re-derive the hash from the printed packet text and confirm it matches.
The content hash alone proves "this hash exists somewhere." It doesn't prove "PreArrive issued this certificate." An attacker who lifts a content hash from a leaked PDF could in principle paste it into a forged cert.
The HMAC closes that gap. At sign time we compute:
verify_token = HMAC-SHA256( server_secret, reservation_id | signed_at | content_hash ) — truncated to 32 hex characters (128 bits of strength).The first 32 hex of that HMAC ride in the QR URL as the t=… parameter. The server secret never leaves us — an attacker can't recompute the HMAC without it.
The bottom of every certificate carries a QR code that encodes:
https://prearrive.com/verify/<content_hash>?t=<hmac_token>Scanning takes any reviewer to the public verify page. The page reads the hash, looks it up in our DB, recomputes the HMAC server-side, and renders one of:
The verify page is public — anyone can hit it — so it reveals only what a claims reviewer needs: property name, stay dates, signed-at timestamp, content hash. Guest names, emails, IPs, and the signature image stay in the host's account.
That keeps the cert safe to attach to a public AirCover ticket or insurance filing without exposing PII along with it.
Still stuck? Message us — we read every message and reply within a few hours on weekdays.