Inside Regy Pro: The Iceberg Under a Thirty-Second Checkout

I've written before about why Regy Pro exists: Land Cruise Vacations needed registration and checkout, and I decided to own that layer instead of renting it. This post is about what it took — because "a checkout" sounds like a form and a pay button, and what it actually is, is an operations platform where the checkout is just the front door.

Inventory without holds

Selling a trip means selling finite things: rooms of specific types, add-ons with limited quantity. The classic approach reserves inventory the moment someone starts checking out, then needs timers, cleanup jobs, and abandoned-cart logic to un-reserve it. Regy Pro doesn't hold anything. Inventory is claimed only at the instant an order completes, inside one atomic database transaction: check the pool, decrement, create the order — all or nothing. Two buyers racing for the last room both get an honest answer, and there's no zombie-hold machinery to babysit.

Every movement in an inventory pool — initial stock, adjustment, claim, release — is written to an audit log with who, when, and why. When a number looks off, I don't wonder; I scroll.

Money is a workflow, not an event

The purchase is the easy part: card payments through Stripe payment intents, with a fake-payment mode for development that stores only a token, a brand, and a last-four — no real card data anywhere near local code. The real work is everything after:

• Refunds — full or partial, with retry logic for the attempts that fail, and automatic recalculation of what's owed.
• Order edits — when an admin changes a booking and the price goes up, the system generates a payment link for the balance due and emails it, rather than leaving a sticky note somewhere.
• Offline money — checks, cash, comps, and invoices get recorded with the same rigor as cards, because a surprising amount of group travel still pays by check.
• Daily payout reports — a scheduled job summarizes the money that moved, every day, without being asked.

Email that can't get lost

Confirmation, cancellation, refund, and balance-due emails all pass through a durable outbox: every message is written to the database first, then handed to the delivery provider. If sending fails, the record persists and retries; nothing silently evaporates. On top of the outbox sit scheduled sequences — the pre-trip reminder drips — processed by an hourly job. The from-address, template, and branding are configurable per brand profile, so the platform can send as any trip brand it hosts.

Trust, verified

This system touches other people's vacations and other people's money, so the paranoia is structural:

• Role-based access — admin, staff, and viewer, enforced at the API, not hidden in the UI.
• An audit log on every state change: order edits, refunds, inventory adjustments, logins.
• Deny-by-default database policies — customer data is only reachable server-side.
• End-to-end browser tests covering checkout, refunds, receipts, and exports, run against a fresh server so stale code can't fake a pass; unit tests underneath; error tracking with privacy-masked session replay in production.
• Encrypted offsite backups, plus destructive scripts that refuse to run without an explicit flag — the database cannot be reset by a fat-fingered command.

The stack

Next.js 16 and React 19 on Vercel; Prisma over Supabase Postgres in production with SQLite for throwaway local runs; Stripe, Resend, and Sharp for server-side image processing; Vitest and Playwright for the test suites. The app database role can't even run schema changes — migrations go through reviewed SQL, never through an ORM with production credentials. A hundred and fifty-five commits over two months, built the way I build everything now: AI coding agents doing the long middle, me holding the spec and reading every diff that touches money.

Guests see thirty seconds of checkout. This is the iceberg underneath.