Travel Booking Platform

Checkout runs over two rails that converge on one confirmation function. The FPX rail computes the amount server-authoritatively (tiered adult/child/infant pricing, per-pax deposit), creates a bill with the toyyibPay gateway, and redirects. A webhook callback then confirms the booking — but only after verifying the gateway's hash, so a forged or misconfigured callback gets a 403 and a log entry, not a silent success. The manual rail lets a customer upload a bank-transfer receipt that staff verify in the dashboard.

The subtle bug was in how idempotency was keyed. The first version guarded the callback on booking status, and it silently dropped balance confirmations: once a booking was deposit_paid, a later callback for the balance bill was treated as a duplicate and ignored. The fix was to key idempotency to the payment row — the unique bill code and the verified state of that specific payment — not the booking.

// A retried callback for an already-verified bill is a no-op.
// A still-pending balance bill confirms even while the
// booking already sits in 'deposit_paid'.
const payment = await findPaymentByBillCode(billCode)
if (!payment) return res.status(404)
if (payment.status === 'verified') return res.status(200) // idempotent

if (!verifyToyyibpayHash(payload, secret)) {
await logSuspiciousCallback(payload)
return res.status(403)
}
await confirmPayment(payment) // shared by FPX + manual rails

There is also an ordering rule worth naming: on first payment the booking flips to deposit_paid first, which fires the slot-deduction trigger (and can raise "departure full"), and the payment is marked verified only after the slot is secured. So a departure that fills up at the last moment never strands a verified payment on a pending booking, and a cancelled or completed booking is never resurrected by a late callback.

Most of the agency's customers come through sales agents, so the attribution had to be right or someone gets paid for a sale they did not make. First click is captured in cookies via a public beacon. A deep link prefills the agent-code field with its own agent's code, which is not an override. Only a genuinely different code, typed in manually, displaces the prior first-click — and when it does, the displaced reference is preserved in an audit log. Staff bookings made on behalf of a customer deliberately ignore the staff member's ambient cookie so they do not mis-attribute.

The displacement rule is a pure function with its own unit tests, because it is exactly the kind of edge case that ships broken. Commission accrual is a database trigger: it fires at an admin-configured status (deposit_paid or fully_paid), reads admin-tunable rates from a settings row, applies per-package overrides, skips house and inactive agents, and reverses itself if the booking is cancelled. It is idempotent on a unique booking id, so the same booking can never accrue commission twice.

Row-level security was not a one-shot. It was a deliberate hardening arc across several migrations: pinning search_path on functions, moving role checks into SECURITY DEFINER helpers, and then an explicit lock-down that revokes EXECUTE on those definer functions from the anon and authenticated roles and re-grants only to the service role. Each step was driven by Supabase's own security advisor lints, and each function kept callable by the public (the RLS predicates, the attribution beacon) versus locked to service-role-only got a written justification in the migration.

Passport scans — which the manifest requires — are stored as private-bucket keys rather than URLs and served through short-lived signed URLs, and the anonymous pre-login upload action is throttled per IP. The principle throughout: forgetting a policy should fail closed, not leak.