Security for both sides of every booking.
A booking is two people trusting one system: the operator's business and the guest's plans. Theybook is built so the riskiest things — card numbers, held funds, cross-tenant data — simply don't exist on our side of the wire.
- Pricing
- $99 / month, flat
- Commission
- 0% — always
- Payouts
- Your own Stripe
- Setup
- Self-serve, same day
The biggest security feature is architectural: we never hold the money
Most booking platforms route guest payments through their own merchant account before paying operators out. That makes them a honeypot: card flows, held balances, payout ledgers — all attack surface, all trust the operator has to extend.
Theybook refuses that role. Guests pay through the operator's own Stripe account — Stripe is PCI DSS Level 1 certified, the highest level — and funds settle directly to the operator's bank. Card numbers never pass through Theybook servers, and there is no pooled balance of operator money for anyone to steal, freeze or mismanage. The most valuable thing in the system is something we deliberately never possess.
01 — For operators
Your business, defended
Account security, data isolation, and the guarantee that your revenue and your records stay yours.
- Card data handled entirely by Stripe — never on our servers
- Payouts settle to your own Stripe account; we can't touch funds
- scrypt-hashed, salted & peppered passwords
- Server-side sessions — revocable instantly, httpOnly + Secure cookies
- Rate-limited logins with automatic cooldowns
- Owner vs staff roles — billing, team and design stay owner-only
- Per-organization data isolation on every query
- Nightly database backups with rolling retention
- CSV export of everything, any time — no hostage data
02 — For guests
Their plans, protected
A guest should never have to wonder where their card number went or whether the seat is real.
- Payment goes to the operator's PCI-certified Stripe checkout
- TLS encryption on every page and request
- Unguessable booking codes protect confirmation & manage links
- Only booking-essential data is collected — nothing resold
- Zero third-party ad trackers on booking pages
- Instant confirmations and change emails — no state surprises
- Waivers and intake answers visible only to your operator
- Overbooking locks mean a confirmed seat is a real seat
03 — Fraud & scams
Built to make the common scams not work
Payment fraud, fake storefronts, ghost bookings, refund tricks — each one runs into a structural wall, not a policy PDF.
Stripe-verified operators
No operator can take a cent until Stripe's onboarding verifies their identity and bank account. A scam storefront with nowhere legitimate to send money is a storefront that can't get paid.
Verified-guest reviews
Reviews are collected only through post-trip links tied to a real confirmation code. There is no public review box for competitors to bomb or owners to stuff.
Bot & velocity shields
A hidden honeypot field catches script bots, and sliding-window caps per IP and per email stop ghost-booking floods and card-testing runs at the checkout door.
Chargeback evidence packs
Every booking can print a dispute dossier — signed waiver with timestamp, full email log, intake answers, check-in record — the exact bundle card networks ask for.
Radar on every payment
Charges run through the operator's Stripe with Stripe Radar's machine-learning fraud scoring, and 3-D Secure can step in on risky cards — shifting dispute liability to the bank.
Refund discipline
Refunds flow back only to the original payment method through Stripe. The classic 'refund me to this other card' social-engineering play has no button to press.
04 — Under the hood
How the platform is hardened
The unglamorous engineering that makes the promises above true.
Isolation by construction
Multi-tenancy is enforced in the data layer: every read and write carries the operator's organization ID. There is no 'all customers' query to accidentally expose — cross-tenant access isn't a permission, it's a missing code path.
Sessions that can be killed
Sign-ins create 256-bit random tokens stored in the database, not stateless tokens that live until expiry. Compromised or stale sessions are revocable server-side the moment they're deleted.
Booking integrity locks
Seat counts update inside database transactions, and shared resources (a boat, a room, a guide) carry overlap locks. Overselling isn't prevented by hope — it's prevented by the transaction failing.
Upload hygiene
Operator image uploads are type-whitelisted (SVG is rejected outright to block script-in-image attacks), size-capped, renamed to random UUIDs, path-traversal-proofed, and served with nosniff headers from isolated per-operator folders.
Hardened HTTP surface
Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and frame-denial headers ship on every response — with framing allowed only where it should be: the booking widget operators embed on their own sites.
Least-privilege infrastructure
The application runs as a non-root user in an isolated container; the database is unreachable from the public internet; secrets live in environment configuration, never in the codebase or image; automation endpoints require their own secret.
Privacy as a business model, not a policy page
Commission platforms and marketplaces monetize guest relationships — which is exactly why their privacy stories get complicated. Theybook's only customer is the operator, so the incentives stay clean: guest data exists to run the booking, full stop. No marketplace remarketing, no selling lists, no advertising competing trips to your customers.
The same goes for tracking: the Theybook marketing site ships zero third-party ad trackers, and operator booking pages aren't seeded with surveillance scripts. Guests get a fast page and a fair deal; operators get customer data that is genuinely, exportably theirs.
What we're building next
Security is a program, not a page. Shipping next on the roadmap: two-factor authentication (TOTP) for operator accounts, self-serve password reset with signed expiring links, an active-sessions view with one-click revocation, and an audit log recording who changed prices, cancelled bookings or exported data — accountability for growing teams.
We publish this openly for a simple reason: operators are trusting us with their storefront and guests are trusting operators with their plans. If you spot something we should do better, tell us — security reports go to the front of the queue.
Questions, answered
Security FAQ
01Does theybook store guest card numbers?
No — never. Card entry and processing happen entirely on Stripe (a PCI DSS Level 1 certified processor), inside the operator's own Stripe account. Card numbers do not pass through or rest on theybook servers, which removes the single biggest breach target from our side of the system.
02How are operator passwords protected?
Passwords are hashed with scrypt — a deliberately slow, memory-hard algorithm — using a unique random salt per account plus a server-side secret, and verified with constant-time comparison. Plaintext passwords are never stored or logged.
03What stops someone from brute-forcing a login?
Login attempts are rate-limited per IP address with a rolling window and an enforced cooldown after repeated failures. Sessions are 256-bit random tokens stored server-side, so they can be revoked instantly.
04Can one operator see another operator's data?
No. Every query in the system is scoped to the authenticated organization — bookings, customers, experiences, uploads and reports are isolated per operator at the database-query level, not just hidden in the interface.
05What guest data do you collect, and do you sell it?
Only what a booking needs: name, email, optional phone, party details and any intake answers the operator requires. It is never sold, never shared with a marketplace, and never used to advertise competing trips. The marketing site runs zero third-party trackers.
06What happens to data in a disaster?
The production database is backed up automatically every night with a rolling retention window, and uploads live on persistent storage that survives deploys and restarts. Operators can additionally export their own bookings and customers to CSV at any time.
07How does theybook stop fake operators from scamming guests?
Structurally: an operator cannot collect a payment until they've connected a Stripe account, and Stripe's onboarding verifies identity and bank details (KYC) before money can move. Reviews on booking pages come only from post-trip links tied to real bookings, so social proof can't be astroturfed. And report links reach us directly — pages that misrepresent a business get taken down.
08What happens if a guest files a false chargeback?
The operator opens the booking's dispute evidence pack: a print-ready dossier with the confirmation code, the signed waiver name and timestamp, every email sent (confirmation, reminders) with timestamps, intake answers, and the on-site check-in record. That bundle is exactly what card networks ask for in a dispute — and it wins the winnable ones.
09How does theybook prevent bots from ghost-booking my capacity?
The public checkout carries a hidden honeypot field that scripted bots reveal themselves by filling, plus per-IP and per-email velocity caps that stop rapid-fire booking floods and card-testing runs before they touch your manifest.
10How do guests know a booking is really confirmed?
Every confirmed booking gets a unique, unguessable confirmation code, an instant branded email with a calendar invite, and a self-serve management page. Changes trigger automatic emails, so the guest and the operator always see the same state.
Trust is the product.
Start free — your Stripe, your data, your bookings. We just run the rails.
Flat fee · 0% commission · Payouts to your own Stripe · Cancel anytime