—Trust & security
PreArrive’s value is the evidentiary chain we put around your signed packet. Here’s exactly what we capture, what we don’t, and how a third party can verify it.
Last reviewed May 22, 2026.
Open the sample certificate PDF
01How a stranger can check it
Every packet’s text (rules, fees, welcome, exact wording) is hashed at send time. The hash is printed on the certificate. Any later edit to the packet produces a different hash, so the version the guest signed is provable.
We capture timestamp + IP at the email click and again at the signed action. Both endpoints are in the certificate. This is the two-event structure claims reviewers generally look for when they need to verify when a disclosure was delivered and acknowledged.
The guest draws a signature with their finger or mouse. We keep the raw PNG and embed it in the certificate. Not a typed-name proxy and not an "I agree" checkbox.
PreArrive does not collect government ID scans, biometric templates, or face-matching results. Paid hosts can optionally request a plain photo at signing, governed by the public photo policy.
Signed certificates are kept for roughly 7 years. Optional photo at signing uses a shorter default: deleted one year after checkout unless configured or held. The full schedule is published below.
The application runs on Cloudflare Workers, Pages, D1, KV, and R2. Core durable records use US-region storage where supported. Globally distributed edge, email, payment, support, OAuth, and analytics vendors are disclosed below.
02The artifact, opened up
Re-hash the packet text yourself. Same SHA-256 means the version on the certificate matches what the guest saw, byte for byte.
03Cryptographic backstop
A claim reviewer, insurance adjuster, or small-claims clerk shouldn't have to take our word that the certificate is real. The bottom of every PDF carries a QR code that encodes a self-contained verification URL — scan it from any phone.
(reservation id | signed_at | content hash), keyed by our server secret. The first 32 hex chars travel in the QR URL as ?t=…prearrive.com/verify/<hash>?t=… recomputes the HMAC and renders one of three verdicts: verified, content-hash known (token missing), or token mismatch (URL tampered).Scan to open the public verify page — no PII.
Recomputing the HMAC requires our server secret. An attacker who lifts a content hash from a leaked certificate can't fabricate the matching token — the verify page rejects with token mismatch.
04Data map
PreArrive is an acknowledgment layer, not an identity-verification or payment-collection system. The map below is intentionally concrete so a host, guest, broker, or privacy reviewer can see the boundary.
Name, email, team membership, properties, packet text, rules, itemized fees, release settings, sync sources, and API/webhook configuration.
Guest name and email, stay dates, packet snapshot, line-by-line acknowledgments, drawn signature, open/sign timestamps, IP addresses, content hash, and verification token.
A plain camera photo only when the host enables the feature and the guest consents. No ID scan. No biometric matching. Deleted one year after checkout by default unless configured/held. Guest deletion path from confirmation email. Photo policy.
Claim Kit stores no incident evidence files. Hosts can hash local files and export an evidence manifest; original photos, videos, receipts, estimates, statements, and screenshots remain with the host.
Request logs, security/rate-limit events, first-party product events, and consent-gated Google Analytics events on marketing pages.
No driver licenses, passports, document uploads, or ID-document verification workflow.
No face geometry extraction, face recognition, identity database matching, liveness score, or biometric enrollment.
Cards are entered into Stripe-hosted payment surfaces. PreArrive stores billing status and Stripe identifiers, not full card numbers.
Guests sign from a single-use link. They do not create a PreArrive login or install an app.
PreArrive does not charge guests, collect deposits, or pull money from booking platforms. The certificate is evidence for the proper claim or resolution path.
05Storage and subprocessors
Core product records live in Cloudflare storage. Email delivery, payment, support, optional OAuth, and consent-gated analytics use named processors. The list below is the public subprocessor register.
| System | Stores | Examples | Residency |
|---|---|---|---|
| Cloudflare Workers and Pages | Application execution, static pages, request routing | Signing flow, dashboard API, public verify endpoint, scheduled jobs | Runs on Cloudflare edge infrastructure; core durable data is in the US-region storage listed below. |
| Cloudflare D1 | Relational application records | Users, teams, properties, packets, reservations, signatures, packet snapshots, audit metadata, API keys, webhook delivery rows, first-party events | US-region database for the production project. |
| Cloudflare KV | Short-lived tokens, revocation mirrors, counters, and caches | Magic links, session revocation keys, guest signing tokens, OAuth state, API rate-limit buckets, idempotency snapshots, webhook plaintext secret cache | Cloudflare KV is globally replicated; values use short TTLs where possible. |
| Cloudflare R2 | Object storage | Property logos in a public asset bucket; optional photo-at-signing images in a private bucket as AES-256-GCM ciphertext | R2 bucket data is configured for Cloudflare storage; private photo bytes are additionally encrypted before upload. |
| Transactional email provider | Email delivery data | Sign-in links, guest packet emails, signature confirmations, reminder emails, support notices | Processed according to the email provider account region and policy. |
| Stripe | Billing and checkout records | Customer id, subscription status, checkout session id, invoices, payment method metadata | Processed by Stripe under Stripe policies. Full card numbers do not touch PreArrive servers. |
| Analytics | Product and marketing usage events | First-party /api/events rows in D1; consent-gated GA4 page/event data for marketing pages only | First-party events stay in D1. GA4 events are processed by Google Analytics after cookie consent. |
| Subprocessor | Purpose | Region / processing note | Data category | Policy |
|---|---|---|---|---|
| Cloudflare | Hosting, Workers, Pages, D1, KV, R2, DNS, TLS, edge security, and Cloudflare Access for operator/admin access. | Core PreArrive durable data is configured for US-region storage where the Cloudflare service supports it; KV and edge services are globally distributed. | Host account data, guest acknowledgment records, packet data, signatures, optional encrypted photo objects, property assets, logs, security events. | Policy |
| Cloudflare Turnstile | Bot and abuse prevention on help-widget escalation forms. | Processed by Cloudflare under the Turnstile Privacy Addendum. | Visitor IP address, browser/device challenge signals, pass/fail token. PreArrive receives the token, not the underlying signal set. | Policy |
| Stripe | Checkout, subscriptions, billing portal, invoices, tax/payment compliance, and webhook reconciliation. | Processed by Stripe according to Stripe account and policy. | Host billing email/name, Stripe customer/subscription ids, checkout metadata, invoice and payment status. Full card numbers stay with Stripe. | Policy |
| Mailgun | Transactional email delivery and delivery-status handling. | PreArrive uses the configured Mailgun region for the sending domain. | Sender/recipient email addresses, message subject/body, delivery metadata, suppression or bounce metadata. | Policy |
| Teamwork Desk | Support ticket handling for help-widget escalations and support requests. | Processed by Teamwork according to Teamwork policies. | Support requester email/name if supplied, ticket body, attachments if the requester provides them, support metadata. | Policy |
| Google Analytics 4 | Consent-gated marketing analytics and conversion measurement on public marketing pages. | Processed by Google Analytics after the visitor chooses Accept all in the cookie banner. | Page/event data, approximate device/browser data, anonymized IP handling, campaign/referrer fields. Not loaded when visitors choose Essential only. | Policy |
| Google OAuth | Optional host sign-in provider when Google SSO is enabled. | Processed by Google according to Google policies. | OAuth state/PKCE, Google account identifier, email address, and basic profile fields returned by the OAuth flow. | Policy |
Core application records are stored in the Cloudflare production project with US-region durable storage where supported. Edge execution, KV, email, payment, support, OAuth, and analytics providers may process data under their own regional infrastructure and policies. PreArrive does not claim SOC 2, ISO 27001, HIPAA, or PCI certification for the product today.
06Retention and deletion
A certificate has to remain verifiable after export, redaction, or a support review. We remove recoverable personal data when allowed while keeping the minimum hash and audit metadata needed to prove what changed.
| Data class | Default retention | Deletion path | Legal hold |
|---|---|---|---|
| Host account, team, and property configuration | While the account is active. Closed accounts become read-only; export remains available for 90 days, then records needed for certificates are archived for the certificate window. | Email privacy support to close, export, redact, or delete account data where deletion does not break a retained certificate or legal obligation. | May be retained longer when required for billing, security investigation, dispute, or legal hold. |
| Reservations and guest contact details | Kept with the related certificate/audit record for roughly seven years from signing when a reservation is signed. | Guests may request access or deletion through the host or PreArrive. Redaction can remove recoverable PII while preserving hash/audit metadata. | Disputes, active claims, fraud/security reviews, and legal holds pause destructive redaction. |
| Signed certificates, packet snapshots, signatures, hashes, and audit trail | Roughly seven years from sign date. | Hosts can export at any time. Deletion/redaction requests are reviewed so the certificate can remain verifiable without unnecessary PII. | May be retained through the dispute, claim, insurance, or court window for the signed stay. |
| Optional photo at signing | Deleted one year after checkout by default unless configured/held. Hosts may shorten retention per property; some plans can configure within documented limits. | Guest deletion path from confirmation email, or email [email protected] from the signing address. If no hold applies, the encrypted R2 object is deleted within five business days while hash/redaction metadata remains. | Active disputes, support investigations, and legal holds pause photo deletion until the hold lifts. |
| Claim Kit metadata and evidence manifest | Current Claim Kit metadata is local to the host browser unless it is sent transiently to export a claim packet PDF. Metadata may include incident notes, checklist state, claimed amount, platform case id, filenames, file sizes, MIME types, descriptions, and SHA-256 hashes. It does not include evidence file bytes. | Remove inventory rows in the browser, clear site storage, or delete exported claim packet PDFs. PreArrive does not currently store original incident evidence files. | Not applicable to local-only evidence files unless the host submits them separately to a platform, insurer, or court. |
| Operational, security, API, webhook, and analytics logs | Short-lived counters use minutes-to-days TTLs. Product/security/event rows are pruned or aggregated as operationally needed. | Privacy requests can remove or aggregate personal fields where they are not needed for security, abuse prevention, or accounting. | Security investigations, abuse prevention, fraud review, and legal obligations may require longer retention. |
| Billing and support records | Retained as required for accounting, tax, chargeback, and support history. | Billing identifiers can be disconnected from the account where allowed; Stripe remains the system of record for payment records. | Tax, accounting, chargeback, fraud, and legal obligations may require retention. |
07Security and contacts
These are implementation controls in the current product. PreArrive does not claim SOC 2, ISO 27001, HIPAA, or PCI certification today; payment card handling stays with Stripe.
All production traffic uses HTTPS/TLS. Cloudflare storage services encrypt at rest; optional photo objects are encrypted again with AES-256-GCM before R2 upload.
Host sessions use the __Host-session cookie with Secure, HttpOnly, SameSite=Lax, a 30-day max age, signed JWTs, and a KV revocation mirror.
Operator/admin surfaces are guarded by Cloudflare Access. Sensitive support preview paths are logged and avoid exposing raw bucket bytes to public clients.
Public REST API keys are shown once, stored as SHA-256 hashes with prefix/last4 display fields, scoped for restricted keys, rate-limited, and rotation-aware.
Outbound webhooks include PreArrive-Signature with HMAC-SHA256 over timestamp and body, a 300-second replay window, and 24-hour rotation grace.
Packet snapshots are immutable, content is hashed with SHA-256, and certificate verification uses an HMAC-bound token so tampering produces a visible mismatch.
Magic links, API calls, verification, help escalation, and bot-sensitive forms use KV counters, Turnstile where applicable, and small request bodies.
Photo bytes are resized, EXIF-stripped, encrypted before R2 storage, linked to explicit consent text, and redacted by retention sweep, guest request, host request, or operator action.
| Need | Contact | Use for |
|---|---|---|
| Privacy requests | [email protected] | Access, export, redaction, deletion, and questions about host or guest data. |
| Security reports | [email protected] | Vulnerability reports, suspicious account activity, and responsible disclosure. |
| Product support | [email protected] | Signing issues, accessibility fallback, dashboard help, and claim-kit questions. |
| DPA requests | [email protected] | Processor terms, customer privacy review, subprocessor questions, and regulated-market review. |
| Incident reporting | [email protected] | Security incidents, suspected data exposure, and urgent evidence-access concerns. |
ESIGN + UETA compliant electronic record. The certificate is evidence of an acknowledgment — not a contract, and not legal counsel.
—See the artifact
The sample certificate, the public verification page, and the API surface — three things you can click into without an account.
The certificate is the artifact. The chain behind it is what makes it stand up — see one before you sign up.