Booking Lifecycle & the Booking Engine¶

Part of the Aashray Business Logic. Related: Stay — Rooms & Flats, Food, Travel, Adhyayan & Utsav, Payments, Credits & Reconciliation. For implementation detail — exact routes, database structure, and known code-level defects — see the companion Technical Reference — Booking Lifecycle & Engine.

This is the connective file that ties every booking type together. Stays, meals, study sessions (adhyayan), festivals (utsav), and travel are all different kinds of bookings, but they all follow the same shape and the same journey: one main booking with optional extras riding along, submitted together, checked for availability and cost, created, paid for (or covered by credit), confirmed, and — sometimes — later cancelled. Per-type details (room assignment, meal cutoffs, bus grouping, study-session seats) live in the linked files; this one explains the shared frame they all sit inside.

1. One main booking, plus optional extras¶

Whatever a member is booking — a stay, a meal, a study session, a festival, or travel — one of those is the main booking. On the same screen, before finishing, the member can attach one or more extras: for example, a stay with a meal plan and a travel leg attached, or a study-session registration with a meal add-on. Everything attached is submitted together, in one request, and billed as a single order.

A flat booking is the one exception. A flat can't be attached as an extra to anything else, and a room or festival registration can't be attached to a flat booking. A flat must always stand on its own.

Known limitation today. This "flat stands alone" rule is only actually enforced when a member books a flat for a guest. When booking a flat for themselves or for a fellow seeker (mumukshu), the check that would block a flat-as-extra (or a flat mixed with a room or festival) is not applied, so such a combination can currently slip through on those paths. The rule is intended to hold for everyone.

2. Booking for yourself, a fellow seeker, or a guest¶

A member can make a booking in one of three ways:

For themselves.
For a Mumukshu — an existing, recognized fellow seeker who already has a record in the system. A member looks the person up by phone number; the system won't let someone create a "Mumukshu" from scratch through this path, only find one who's already known to it.
For a Guest — someone who may not have a record yet. If the phone number isn't already known as a guest, a new guest record is created on the spot as part of the booking.

Whichever way a booking is made, it always belongs to one specific person — whoever is actually staying, eating, attending, or travelling. If someone else made the booking for them, that's also recorded, so the app can show "Booked For: {name}" and so both people — the attendee and whoever booked it for them — get notified about what's happening with it.

3. Checking availability and cost before committing¶

Before a booking is actually created, the member sees a preview: is what they're asking for available, and what will it cost? This preview also shows what happens if the member has store credit — the credit is shown as already applied to the cost, but nothing is actually spent yet. If something isn't available (the dates are blocked, a slot is already taken, there's no room left), the member sees a clear message and can change their request rather than being charged for something that can't be given to them.

4. Creating the booking¶

Once the member confirms, everything in the main booking and its extras is created together as one unit. What happens next depends on where the member is paying from:

Members in India get a payment order generated immediately, so they can pay online right away (or shortly after, since payment can be deferred — see below).
Members outside India aren't offered online payment for this; instead their charge is recorded as a cash amount payable on-site.

Right after a booking is created, the attendee and (if different) whoever booked it for them are notified by WhatsApp, email, and an in-app notification that their booking has been created and is awaiting payment or confirmation. If, for some reason, these notifications fail to send, the booking itself still stands — a booking is never undone just because a notification didn't go out.

5. From "just booked" to "confirmed" — the life-cycle in plain words¶

A booking generally moves through a small number of plain-English states:

Waiting — for stays, this can mean waiting for a room number to be assigned; for other types, it can mean waiting for a spot to open up if everything is full (see §6).
Awaiting payment — created, but payment hasn't gone through yet (or, for a stay, hasn't been fully applied).
Confirmed — payment has gone through (or been fully covered by credit) and, where relevant, staff have signed off. For stays, "confirmed" continues on into an actual check-in and, eventually, a check-out.
Cancelled — either the member cancelled it themselves, or it was cancelled automatically (see the 24-hour rule, below), or a staff member cancelled it.

If a member pays for the whole thing using existing store credit, the booking skips straight to confirmed — there's no separate online payment step needed in that case.

The 24-hour rule. If a booking is left unpaid, it is automatically cancelled after roughly a day, and — for booking types that support a waitlist — the next person waiting gets automatically offered the freed-up spot. This is separate from a different, unrelated 24-hour target staff use for finalizing travel arrangements (see Travel).

6. Waitlists and automatically opening a freed-up seat¶

When a booking type is completely full, a new request doesn't have to be rejected outright — it can be placed on a waitlist instead, for these booking types:

Stays, specifically for a single night that falls right at the edge of a festival.
Study sessions (adhyayan)
Festivals (utsav)
Travel

Food and flat bookings don't use a waitlist — a food order or flat either goes through or it doesn't.

The idea is that when a confirmed booking is cancelled — including an automatic cancellation for non-payment — the next person on the waitlist should be automatically moved up and notified that a spot has opened for them.

In practice, this doesn't currently happen for every type it's meant to. Travel bookings, in particular, never actually enter a waiting state in the first place, so there is currently no one for a freed-up travel seat to be automatically offered to (see Travel — Known limitations). Stay waitlists at a festival boundary also aren't moved up automatically — a staff member does that by hand.

7. Cancelling a booking¶

A member can cancel their own booking while it's still waiting, awaiting payment, or confirmed. When they do, any money already paid comes back as store credit they can use on a future booking — though the exact refund rules differ a little by booking type (for instance, some types don't return credit for a member-initiated cancellation the way a stay does); see Payments, Credits & Reconciliation for the full picture. The attendee and (if different) whoever made the booking are both notified of the cancellation.

Staff can cancel — or otherwise adjust — any booking at any time, independently of what the member does in the app, and can choose whether or not to issue credit when they do. This gives staff a way to fix mistakes, free up a slot, or handle situations (like a trip that never fills up) that don't have a clean self-service equivalent for the member.

How this connects to other domains¶

This file is the spine; the per-type files hang off it. Stay — Rooms & Flats covers room assignment and check-in/out. Food, Travel, and Adhyayan & Utsav cover meal cutoffs, travel/bus arrangements, and study-session/festival seats — all created through the same booking flow described here. Money mechanics (payment, credit, cancellation refunds, the 24-hour unpaid-booking rule) are expanded in Payments, Credits & Reconciliation, and the full status vocabulary in Status & Cron. Who can be booked for — members, Mumukshus, and Guests — is covered in Accounts, Identity & Auth.

Full engineering detail — every route, the underlying data model, and every known code-level defect in this pipeline — is tracked in the technical reference.