Rate and availability transactions
Overview and typical process flows
The following five transaction types relating to retrieving rates and availability information are supported by UltraDirect:
Standard MultiAvailability – this returns the status (i.e. open/closed) and minimum/maximum available rates for up to 200 properties (identified by their property codes) in one transaction.
Enhanced Shopping transaction (EST) – this returns detailed information for available rooms and rate types for up to 200 properties (identified by their property codes) in one transaction.
Single Property Availability – this returns detailed information for available rooms and rate types for one property.
Rate Rules – this returns full information (normally including detailed rate information, policies, restrictions and taxes) for one room rate at one property.
All these transactions are described in detail in the following sections. Normally a distributor will only use two or three of these transactions - the choice of transactions will depend on the distributor’s requirements (particularly the design of their website).
Three of the most common usage scenarios are outlined below, although other variations are also allowed.
Scenario 1: Show lowest rate in city search results
This scenario is typically used when the distributor’s website shows the lowest available rate for each property matching the user’s hotel search criteria. Many hotel chains prefer distributors to use this scenario because it minimizes the number of transactions sent to their CRS. The basic steps are summarized below:
1. The user enters the arrival date, number of nights, number of guests, destination and any other criteria on the website
a. The website application finds all the hotels that match the criteria in its local database and builds a list of property codes
b. The website application sends a standard MultiAvailability transaction containing the list of property codes and the rate selection criteria (dates of stay, guest counts etc)
c. The MultiAvailability response contains the availability status of each requested property (i.e. open/closed), along with the minimum and maximum rates. The available hotels are displayed on the website with the lowest available rate (or rate range) together with hotel details from the local database
2. The user selects a hotel on the website to view more details
a. The website application sends a PropertyInformation (Single Property Availability) transaction to UltraDirect for the selected property. This contains the same criteria as the previous MultiAvailability transaction (dates of stay, guest counts etc)
b. The response includes details of all available room types and rates, which are then displayed on the website. This may also include some policy information etc.
3. The user selects a particular room and rate on the website.
a. The website application sends a PropertyInformation (Rate Rules) transaction to UltraDirect for the selected property, room type and rate code (and all the previous criteria such as dates of stay etc).
b. The rate rules response includes more detailed rate and policy information, including any restrictions and taxes/surcharges. This information is displayed to the user
4. The user chooses to proceed with the booking & enters their name, address & credit card details etc (see Section 3 booking transactions for much more detail on this)
a. The web application processes the booking and sends a BookReservation transaction to UltraDirect
b. The booking response includes the confirmation number and other information, which is displayed to us. The booking details and information from the rate rules response (such as cancellation policies) should be stored in the local database.
Scenario 2: Show room rate details in city search results
This scenario is typically used when the distributor’s website needs to show more than just the lowest available rate for each property – e.g. display rates for a selection of room types for each matching property.
The downside of this approach for hotel chains is the increased load on their CRSs, as they must return detailed room and rate information for all properties in the searched city. This is in contrast to the previous scenario, where such details were only provided when a user selected a specific hotel.
The steps in this scenario are outlined below:
1. The user enters the arrival date, number of nights, number of guests, destination and any other criteria on the website
a. The website application finds all the hotels that match the criteria in its local database and builds a list of property codes
b. The website application sends a MultiAvailability (Enhanced Shopping – EST) transaction containing the list of property codes and the rate selection criteria (dates of stay, guest counts etc)
c. The MultiAvailability (EST) response includes details of all available room types and rates, and may also include some policy information et The available hotels are displayed on the website, together with some room rate information. For example, this could be details of the lowest rate for each distinct room type (if there are too many room rates to show for each hotel)
2. The user selects a hotel on the website to view more details
a. Since the MultiAvailability (EST) response already included all the room rates details for all properties, the full information can be displayed for the selected hotel without sending another UltraDirect transaction.
3. The user selects a particular room and rate on the website.
a. The website application sends a PropertyInformation (Rate Rules) transaction to UltraDirect for the selected property, room type, and rate code (and all the previous criteria such as dates of stay etc).
b. The rate rules response includes more detailed rate and policy information, including any restrictions and taxes/surcharges. This information is displayed to the user
4. The user chooses to proceed with the booking & enters their name, address & credit card details etc.
a. The web application processes the booking and sends a BookReservation transaction to UltraDirect
b. The booking response includes the confirmation number and other information that is displayed to us. The booking details and information from the rate rules response (such as cancellation policies) should be stored in the local database.
Scenario 3: Price comparison websites
This scenario is typically used for meta-search engine websites that compare prices across multiple websites or channels. The user is redirected to the source website to actually make the booking.
1. The user enters the arrival date, number of nights, number of guests, destination and any other criteria on the website
a. The website application finds all the hotels that match the criteria in its local database and builds a list of property codes
b. The website application sends a standard MultiAvailability transaction containing the list of property codes and the rate selection criteria (dates of stay, guest counts etc)
c. The MultiAvailability response contains the availability status of each requested property, along with the minimum and maximum rate (typically, these will be the rates available on the hotel’s own website). The available hotels are displayed on the website with the lowest available rate that can be found on the hotel’s website (together with the lowest rates available on other websites found by other means).
2. The user selects the hotel and the rate that is available from the hotel’s website
a. The user is redirected to the hotel’s own booking website
b. The hotel website shows all available room types and rates for the hotel and criteria (dates of stay etc)
3. The user selects a particular room and rate.
a. The hotel website shows the full details for the room and rate.
4. The user chooses to proceed with the booking & enters their name, address & credit card details.
a. The hotel website processes the booking
b. Booking confirmation details are displayed to the user
Last updated