← Help center

How a stranger can verify the certificate

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.

Layer 1 — Content hash

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.

Layer 2 — HMAC-bound verification token

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.

Layer 3 — QR code + public verify page

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:

  • Verified — hash on file AND the HMAC matches. The certificate is genuine.
  • Content hash known — hash on file but no token in the URL. Hash matches, but authenticity isn't proven this round.
  • Token mismatch — hash on file but the token doesn't recompute. The URL was probably tampered with or the QR re-encoded.
  • Hash not recognized — no PreArrive cert has this hash. The QR is from a different system, or the value was fabricated.

Privacy by design

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.