A booking engine for a tour operator, and the one thing the browser must never decide.

Wander Yak was built for tour operators, and its live site belongs to one based in Tabo, Spiti Valley. In a small tour business the selling usually happens in chat: a traveler asks about a trip, the operator sends a price and an itinerary, they settle a date, and a payment follows. Every step is typed by a person, over and over, and often from a place with poor signal.

The brief that follows is plain. Put the price, the stay, the plan and the open dates on the page. Let a traveler pay to hold a seat without a person in the loop. Hand the operator one panel to run trips, bookings and customers from. And do it once as a product that can be licensed to other operators, not rebuilt for each.

When a traveler books, the page sends the choices, not the amounts. The server looks up the price per person for the chosen stay category, multiplies by the number of people, then works out the token: 20% of the total, rounded to the nearest rupee, plus 5% GST on that rounded token, rounded again. For two travellers on a Rs 20,499 trip that comes to a total of Rs 40,998, a token of Rs 8,200 and Rs 8,610 payable now.

A Razorpay order is created for that amount and saved with the booking as "initiated". After the traveler pays in Razorpay's own window, the server checks Razorpay's signature before the booking is confirmed, then sends the confirmation email and, if the traveler is new, creates an account and sends a welcome email. Because of that signature check, a user can't mark their own booking as paid by editing the page.

Travelers come from other countries, so a currency switch lets them see prices in their own. When one is chosen, the server asks a free exchange-rate service for the day's rate and keeps it in the visitor's session, and every price on the page, and in the PDF brochure, is converted from rupees.

The booking itself is always charged in rupees. I kept it that way on purpose: converting at checkout would mean the amount a traveler is shown and the amount Razorpay charges could differ by the minute, and the whole point of working the token out on the server is that they never do.

The code lives in a Git repository, and its history shows the real order of work: a README and licence in July 2025, a final push in January 2026, Mailgun email in February, a trending order and date sorting, a rewritten payment module in May, then a pull request titled as a code review the same week, which hardened how the package type and slug travel from the page to the server, and the campaign module in July.

The review pass is worth mentioning because it's the kind of thing a client product needs. A booking page passes a package type and slug through JavaScript, and a value that reaches the server from the browser must be treated as untrusted whatever it looks like. That was tightened after the review.

It doesn't count seats. A group departure lists its dates, but nothing stops a date selling past the vehicle's capacity, so the operator must close a date by hand. It has no payment webhook, so a booking is confirmed when the browser comes back from Razorpay, and a traveler who pays and closes the tab at that exact moment needs the operator to reconcile. Prices in the stay-category table are stored as text that can contain commas, which the booking code has to strip before it can calculate. It works, and it's a data-model wart I'd fix first in a rebuild.

Wander Yak is live at thewanderyak.com and does the thing it was built for: a traveler can choose a trip, a stay and a date, pay a token to hold the seat and get a confirmation, and the operator runs everything from one panel. It's a licensed product, so the next operator gets the same engine with their own trips and brand.

What it isn't yet: fast on mobile, seat-aware, or webhook-safe. Those are known, written down and fixable. The image pipeline from Diksha, a seat count per departure and a Razorpay webhook are the next three jobs, in that order.