Tour booking system case study. Problem: two Costa Rica tour operators sold tours through 200+ field Gravity Forms that were fragile, slow on mobile and had no real dashboard. What we did: built a custom booking widget embedded in their WordPress sites, an owner dashboard and a server-checked PayPal payment back end, then proved it matched the old forms across all 1,995 option combinations. Result: two live booking systems plus a national park ticket store, zero price differences, payments never charged twice, and owners who edit prices themselves. Stack: React, TypeScript, Supabase, PostgreSQL, Cloudflare Workers, PayPal Orders API.
- Clients
- El Rincón Tours & Transportation and La Leona Waterfall
- Industry
- Tourism and transport
- Location
- Guanacaste, Costa Rica
- Live sites
- transportation.rincondelaviejapark.com, transportation.leonawaterfall.com, rincondelaviejapark.com
- Services
- Web app development, WordPress integration
- Stack
- React, TypeScript, Supabase, PostgreSQL, Cloudflare Workers, PayPal Orders API
- Timeline
- September–October 2026; first site live in about a week
- Delivered by
- PlusTechnology
The challenge
Two tour companies near Rincón de la Vieja National Park sold tours with hotel pickup through very large Gravity Forms on WordPress, with 207 and 206 fields. The forms worked, but they had become hard to live with:
- Huge, fragile forms with show/hide rules for every tour, hotel area and pickup time. One change could break a price somewhere else.
- No real dashboard. Bookings, payments and customer emails were spread across WordPress, PayPal and email.
- Slow and dated on mobile, where most tourists book.
- Email problems: one form sent "confirmed" emails before the customer had paid.
- Hard to change prices: the yearly price update meant editing dozens of fields by hand.
The owners had one firm rule: the new system had to behave exactly like the old one. Prices, questions and pickup times had already been approved, and real customers were booking every day.
What we built
A custom booking platform in three parts, with a separate copy, data and dashboard for each company.
1. Booking form embedded on the WordPress sites
- Step-by-step choice of tour, hotel or pickup area, date, time and travellers, with a live price summary.
- A calendar that greys out closed or full dates and shows "Only N seats left".
- PayPal and card payments inside the form, loading PayPal only at the payment step to keep pages fast.
- Quote requests for locations that need a custom price, so no customer is blocked.
- Saved progress, automatic retries on weak mobile connections, and Shadow DOM isolation so WordPress themes and plugins can't break it.
2. Owner dashboard
- Bookings with search, filters, notes, cancellations, CSV export and the emails sent for each booking.
- Reports on sales and how far visitors get through the form.
- Owner-editable tours, prices, pickup areas, hotels, times, availability, seat limits and email templates with live preview.
- Secure two-step login, a safe switch between PayPal test and live modes, and a system log with email alerts.
3. Back end and payments
- Server-side checks on every booking: the server recalculates the price and rejects forged totals, past or closed dates and full tours.
- PayPal Orders flow: the order is created for the stored total, captured and the captured amount verified. Declined cards can retry safely and nobody is charged twice.
- Emails only after payment succeeds, logged and retried if sending fails.
Proving nothing changed
This was the core of the project. Instead of copying the forms by hand, we wrote an importer that read the Gravity Forms export and replayed every combination: 1,305 on one site and 690 on the other, recording which questions appear and which prices apply.
- Automated parity tests compare every choice with the original export: same questions, same price lists, same totals.
- Gravity's own logic was run on the live forms and compared with the new system: 53/53 and 48/48 scenarios matched.
- Known bugs were fixed on purpose and agreed with the client, such as confirmation emails now going out only after payment.
Going live safely
- Full PayPal sandbox test payments on both sites before switching to live.
- A backup before every price or setup change, with version checks so two edits can't overwrite each other.
- The old forms stayed installed until both sites were confirmed working.
- The first real bookings, payments and emails were monitored after launch.
Both tour sites went live in early October 2026.
Phase 2: national park ticket store
After launch, the client asked for self-guided admission tickets to Rincón de la Vieja National Park on their main website. We built it on the same platform: a choice of ranger station (Las Pailas or Santa María) with its own trails, hours, closed days and trail map; adult and child tickets; a visit-date calendar with same-day cut-off times; and a ticket delivery panel with WhatsApp, email and live chat.
Results
- Two live booking systems plus a park-ticket store, taking real PayPal and card payments daily.
- Zero price differences from the forms the client had approved.
- Reliable payments: every payment verified, declines handled correctly, nobody charged twice.
- Owners update prices, pickup times, availability and email wording themselves, without a developer.
- Problems are caught early: customer-side errors are logged and emailed to the team. A phone translator breaking the form was found and fixed within a day.
- Faster, cleaner mobile booking that no longer depends on WordPress form plugins.
Tech stack
| Area | Technology |
|---|---|
| Booking widget | React, TypeScript, Vite, Shadow DOM web embed |
| Dashboard | React, TypeScript |
| Back end | Supabase Edge Functions, PostgreSQL with row-level security |
| Login | Supabase Auth with two-step verification |
| Hosting | Cloudflare Workers and Supabase |
| Payments | PayPal Orders API, PayPal Buttons and Card Fields |
| Transactional email with logging and retries | |
| Quality | 133 automated tests (parity, pricing, bookings, checkout, notifications) and Playwright browser checks |
| Operations | Nightly backups, health checks, error log with email alerts |
"The hardest part wasn't building a booking form. It was proving that 2,000 combinations of tours, hotels and prices behaved exactly like the old system, while real customers kept booking every day."
— Rehan Ullah, founder of PlusTechnology
Tour booking system FAQ
What does a custom tour booking system include?
This tour booking system includes a booking form embedded in WordPress with live pricing and seat availability, an owner dashboard for bookings, prices and pickup times, and a PayPal payment back end that verifies every payment.
How do you replace a large Gravity Forms booking form without changing prices?
We wrote an importer that read the Gravity Forms export and replayed every combination (1,305 and 690 on the two sites), then ran automated parity tests comparing questions, price lists and totals, plus Gravity's own logic on the live forms. Every scenario matched.
Can a custom booking system work inside a WordPress site?
Yes. The booking form is embedded with a short HTML snippet and isolated with Shadow DOM, so WordPress themes and plugins can't break it and it can't break the site.
How do you stop customers being charged twice with PayPal?
The server creates the PayPal order for the stored total, captures it and verifies the captured amount. Retries after a declined card are handled safely, and confirmation emails are only sent after a successful payment.
How long did the booking system take to build?
The first site went live in about one week in late September 2026, with both sites live in early October and improvements continuing after launch.
Related reading
Want something similar for your business? Hire PlusTechnology on Upwork or get in touch.