Docs / Public Website / Guest & Public Booking

Guest & Public Booking

A traveller can book in two ways: as a logged-in account holder, or as a guest with no account. Both flows end with a paid, confirmed booking. The guest path lets them claim the booking under an account later.

The two doors

Registered user

  • Sign-in with email + password (or social)
  • Skips guest details — autofilled from profile
  • Booking appears in "My bookings" automatically
  • Eligible for member discounts & saved cards

Guest checkout

  • No account creation
  • Email + phone with OTP
  • One-tap "save my details for next time" option
  • Magic-link in confirmation email to claim booking under account

Checkout flow

  1. Property page → "Reserve"

    Server creates a 10-min hold on the room type for the dates. Returns a booking_id in held state.

  2. Checkout step 1 — Guest details

    Logged in: pre-filled. Guest: enter name, email, phone. Phone OTP fires; user enters 6-digit code.

  3. Step 2 — Review & policies

    Show stay summary, total, cancellation policy in plain English, GST breakdown, special requests box.

  4. Step 3 — Payment

    Razorpay modal (full payment) or partial-payment toggle. Mode chosen by the rate plan.

  5. Success page

    Booking reference (ABC-24817), itinerary, "add to Google Calendar" button, "claim this booking under an account" if guest.

  6. Confirmation email + SMS

    Sent within 5 seconds. Includes magic claim-link with 30-day expiry.

Guest-detail form

abc.com/checkout/bk_abc24817
Who's checking in?
Step 1 of 3 · No account needed
Park View Hotel
Old Manali · Deluxe King
Check-in27 Dec 2026 · 14:00
Check-out30 Dec 2026 · 11:00
Guests2 + 1
3 nights × ₹6,500₹19,500
GST₹2,340
City tax₹390
Total₹22,230
Free cancellation till 26 Dec
Hold expires in 9:42

Guest record handling

Internally, every booking — registered or guest — is linked to a row in guests. That row may or may not be linked to a users row.

guests
  • iduuid
  • user_id→ users · nullable
  • nametext
  • emailtext
  • phonetext
  • phone_verifiedbool
  • created_viaenum (registered / guest / manual)
claim_tokens
  • iduuid
  • guest_id→ guests
  • token_hashtext
  • expires_attimestamp
  • claimed_attimestamp · nullable

Claim-link flow

  1. Confirmation email includes claim-link

    Format: abc.com/claim?t=<token>. Valid 30 days.

  2. Guest opens link

    Lands on "Save your bookings to an account" page.

  3. Sets password

    Email is already verified (proof: they clicked the link); phone already verified (OTP at booking). User created instantly.

  4. Existing bookings linked

    All bookings with the same verified email/phone are linked to the new user account, including past ones. Owner of those bookings now sees them under "My bookings".

De-duplication

A returning guest who books five times without ever signing up should not become five separate "guest" rows in the database — they're one person.

  • On booking, we match on verified phone first, then verified email.
  • If matched, we reuse the existing guest_id and update name/email if changed.
  • The repeat-stay badge surfaces on the owner's booking detail screen.
  • This also unlocks "member-only" rate plans for repeat guests, even without an account.

Anti-abuse on guest checkout

  • OTP rate-limited: 3 sends / phone / hour, 6 / phone / day.
  • Captcha on the phone-entry step after 2 OTP failures.
  • Disposable email blocking on guest checkout.
  • Risk-score gates Razorpay payment options (high-risk: only UPI to start).
  • Hard cap of 5 active bookings per unverified guest (anti-credit-card-cycling).
Guest checkout is not "lower quality".

Many big OTAs nudge guest users into accounts after checkout, when conversion is already secured. ABc follows the same playbook — never force an account up front, always offer one after.