Websites

Travel website: bookings, prices and cancellations

Dynamic prices, availability, booking system integrations, time zones and currencies, cancellation rules — what determines how a travel website works.

A travel website differs from an ordinary catalogue in that it sells time, not goods. A room for specific dates can't be sold twice and can't be put back on the shelf. All the complexity grows from this: the price changes, availability changes, and a mistake in cancellation rules turns into a dispute with the customer and lost money.

Price and availability are values, not attributes

In an online store, price is an attribute of the product. In travel, price is a function of several variables: check-in and check-out dates, length of stay, number of guests, rate plan, sales channel, how far in advance the booking is made.

Practical consequences to account for in the project:

  • The price can't be shown as a single number. The catalogue shows a guide — "from" — with the exact price for the chosen dates required. A gap between the guide and the total at checkout is the main reason people abandon.
  • Minimum stays and arrival rules. Minimum nights, no arrivals on certain days, mandatory periods over holidays. These must be checked when dates are chosen, not announced at payment.
  • Surcharges and fees. Tourist tax, cleaning, extra bed, meals. Anything added to the price must appear in the calculation before the person enters card details.
  • Availability depends on the range. Occupancy is checked across every night of the period: one booked day in the middle makes the whole stretch unavailable. The calendar should make this obvious.

A separate question is rate plans. The same room is usually sold under several rates: non-refundable is cheaper, refundable costs more, with breakfast is its own rate. The customer chooses not a room but a combination of room and rate. If the system is built with one rate per property, adding the others later rewrites the storefront, checkout and cancellation rules.

Integrations with booking systems

Almost everyone who sells accommodation or tours already has a management system: a PMS for a hotel, a channel manager, a tour operator system, a GDS for an agency. In this setup, the website is usually one of the sales channels.

You need to choose a model:

  1. The site as a storefront. Prices and availability come from outside, bookings go back there. Most hotels work this way. The risk is sync delays.
  2. The site as the source of truth. Its own booking system, with other channels receiving data from it. More control, more responsibility and more development.
  3. A mixed scheme. Part of the inventory is managed on the site, part comes from partners. The hardest to maintain.

Whatever the model, some things have to be designed explicitly:

  • What happens when the external system is unavailable. A booking mustn't silently vanish. Either it's blocked with an honest message, or accepted as a request with confirmation to follow.
  • The race for the last room. Two people book the last available room at the same time. You need a temporary hold for the duration of checkout and clear behaviour if the hold fails.
  • Confirmation. Instant or on request. If a person confirms the booking, the customer should understand that before paying, not after.
  • Changing a booking. Who can change dates and guests, up to what point, and what happens to the price.

Overbooking deserves a separate mention: it arises from delays between channels. Technically it's reduced by frequent syncing and inventory holds, but it can't be eliminated completely — you need an operational scenario for when it does happen.

Time zones and currencies

Two areas where mistakes look especially bad, because they hit money and schedules.

Time

The rule is simple: check-in and check-out dates live in the property's time zone, not the user's or the server's. A customer in another zone booking late in the evening mustn't end up a day off.

What's also usually missed:

  • Check-in and check-out times are stated explicitly, in the property's local time.
  • The free cancellation deadline is a point in time in the property's zone. "One day before arrival" without a time zone breeds disputes.
  • For tours and transfers, the start time is critical: show it in local time with an explicit label rather than silently converting it in the browser.
  • The booking date in confirmations and reports is a separate value; it's convenient to store it in universal time and display it by context.

Money

  • Settlement currency and display currency are different things. You can show the price in the customer's currency, but the charge is in the seller's currency, and that must be stated plainly.
  • The exchange rate is fixed at a moment. You need to decide which one: display, booking or payment. And where the fixed rate is stored so refunds are calculated correctly.
  • Rounding follows one rule. Otherwise the amount in the calculation and the amount charged differ by cents, and that's enough for a support ticket.
  • Refunds go in the payment currency and for the original amount, not at the current rate.

Any value that can change between display and payment — price, exchange rate, availability — must be fixed when the booking is created and stored with it.

Cancellation rules

This is where ambiguity turns into conflict. Cancellation rules need to be not only implemented but shown in an understandable form.

What a rule describes:

  • Until what moment cancellation is free — with the time zone stated explicitly.
  • What is retained for a later cancellation: a fixed amount, the first night, the full payment.
  • What happens on a no-show — usually a separate, stricter case.
  • Whether partial cancellation is possible if the booking covers several rooms or services.
  • How the refund is calculated for a change rather than a cancellation.

The technical side isn't trivial either. If a booking is partially paid — a deposit plus the balance at check-in — the rule has to handle that. If payment went through a payment provider, the refund depends on its timelines and limits, and the customer should be told this honestly.

A useful interface rule: refundable and non-refundable rates must look visibly different at the selection stage. The non-refundable rate is cheaper, and some people pick it without reading. If the condition wasn't noticeable, a dispute follows in which the seller is formally right and the customer is lost in practice.

What to show before payment

Before the pay button, the customer should have the full picture. The confirmation screen isn't a formality; it removes most support requests.

It should contain:

  1. The property, accommodation type and chosen rate.
  2. Check-in and check-out dates and times, stated in local time.
  3. The number and make-up of guests, if it affects the price.
  4. A full calculation: base price, surcharges, fees, taxes, and the total on one line.
  5. The charge currency and the amount in it, if it differs from the display currency.
  6. Cancellation terms as text with a specific deadline date and time, not a link to general rules.
  7. What's paid now and what's paid on site.
  8. The confirmation method — immediate or after review — and the response time.
  9. What to bring or present at check-in, if there are requirements.

After payment, the customer receives an email with the same details and the booking number. That email often becomes the only document they'll show at the front desk — so it should include the address, the property's contacts and the cancellation terms, not just a thank-you.

Pre-launch checklist

Before starting a travel project, it's worth settling the following in writing:

  1. What makes up the price and which surcharges exist.
  2. The full list of rates and arrival rules, including minimum stays.
  3. Which system manages availability and which exchange model is used.
  4. How the site behaves when the external system fails and in a race for the last place.
  5. The mechanism for holding inventory during checkout.
  6. Where the exchange rate and price are fixed and how this is used for refunds.
  7. The time zone in which check-in, check-out and the cancellation deadline are calculated.
  8. Cancellation, no-show and change rules — as text fit to show the customer.
  9. The contents of the confirmation screen and the booking email.

Points three to five define the architecture and are very hard to change later. The rest are terms to agree with the business before development, or they'll surface during testing. If some questions don't have answers yet, it makes sense to work through them at the start — let's discuss together with the task definition.