Booking transactions
Last updated
Last updated
Summary and examples
Transaction flow and session control
UltraDirect supports session control for all booking transactions – i.e., the hotel CRS will temporarily hold all booking, modify and cancel requests until a subsequent request to complete or ignore the action is received and processed.
Each affiliate partner has the option of participating actively or passively in the session control processing.
For active participation, the affiliate will send two messages per transaction – one to initiate the booking, modification, or cancellation and another message to complete (commit) or ignore the transaction. Since a transaction is only complete when it is committed, the confirmation number or cancellation number will only be returned in the response to a commit transaction.
For passive participation, RateGain will automatically send the commit or ignore message to the CRS on behalf of the affiliate. Therefore, the affiliate only sends one request message per transaction and receives the confirmation number or cancellation number in the response.
The following diagram illustrates the flow of a booking transaction when an affiliate is an active participant in session control – i.e. generates a commit (End Transact) or Ignore message. The same flow would apply to both modifies and cancels.
The following diagram illustrates the flow of a booking transaction when an affiliate is a passive participant in the session (RateGain generates End Transact). The same flow would apply to both modifies and cancels.
When the affiliate is actively participating in the session control processing, a 15-minute timer will be activated when the response to the booking, modify or cancel transaction is returned to them. If a subsequent Commit or Ignore message is not received from the affiliate within this time, RateGain will automatically generate an Ignore message to the hotel CRS to clean up the session.
In the event that a Commit response is not received from a CRS within the timeout window, an error will be returned to the affiliate advising them the transaction could not be confirmed. The confirmation/cancellation number received from the CRS will not be sent to the affiliate, but RateGain will record the transaction data for a failed End Transact for future reference by Customer Support if needed.
The session control functionality is only available for hotel chains that support it – most do but there are some that do not. The BrandInformation transaction (see section 0) can be used to determine which chains support it. It is important to note the following for hotel chains that do not support session control:
Booking modifications are not supported - i.e. the ModifyBooking transaction cannot be used for bookings made with hotel chains that do not support session control. Furthermore, there are also a small number of chains that support session control but not modifications. Again, the BrandInformation transaction can be used to identify chains that do not support modifications. If modifications are not supported, the booking must be canceled and rebooked.
If the affiliate sends session control elements in the initial booking or cancel request, the affiliate will be required to interpret the response message received to determine if session control processing is in effect for that hotel chain. A response containing a confirmation or cancellation number but no session identifier must be interpreted as non-session control, and a subsequent Commit or Ignore should not be sent. A response containing a session identifier but no confirmation or cancellation number will require the affiliate to send a Commit or Ignore request to complete the session.
New bookings
The BookReservation transaction is used to make a new booking. The minimum information that is typically sent includes:
Property, room type and rate plan codes
Arrival and departure dates
Number of guests and rooms
Guarantee method (this normally means sending the credit card details)
Primary guest’s name and contact details
Special requests or comments (optional)
The following is an example booking request using session control (Session=”New”)
The response message is shown below. Note that it includes the SessionID but no confirmation number:
After reviewing the details in the response, the booking can be completed by sending the following message:
The response then includes the confirmation number:
Booking cancellations
To cancel a booking, the CancelReservation message should be sent with the following information:
Latest confirmation number (i.e. some hotel CRSs may generate a new confirmation whenever a booking is modified)
Property code
Arrival and departure dates
Name of the primary guest
As with all the other booking transactions, the CancelReservation transaction can be used with or without session control. The following is an example without session control:
The response will include a cancellation number, as shown below:
Booking modifications
The ModifyBooking transaction is used to request changes to an existing booking, although this is not supported by all hotel CRSs. If a booking modification transaction is sent for a hotel chain that does not support modifies, an error will be returned advising them the transaction is not supported. As noted above, modify requests will never be processed for a non-session control CRS since these transactions require session control participation.
All booking modifications must be sent with a full recap of the complete reservation data. This will include the original, unchanged reservation information and the new, changed information. The latest confirmation number on the reservation must always be included.
It is important to note that a new room rate amount may apply when some booking information is changed, such as arrival date, departure date, number of guests or room type, etc. The new room rate information must be shown to the end user. The method for doing this will depend on whether the affiliate is using active or passive session control, as described below:
If using passive session control, the affiliate may choose to generate an availability request and display the new rates to an end-user prior to submitting a modify transaction. The additional availability request is recommended because passive participation does not allow the end-user to accept the changes prior to the modify request being confirmed within the CRS.
With affiliates that are active participants in the session control functionality, there is an option for the affiliate to display the new reservation data to the end-user prior to confirming a modify request. Because an active participating affiliate is required to submit the SessionControl “Commit” transaction to confirm the modification and close the session, the affiliate can take that opportunity to allow the end-user to approve of the changes prior to the “Commit” being sent to the CRS.
When a reservation is modified, the affiliate must store the new reservation information within their system’s local database. Additionally, a history of the date and time of each modification made to a reservation is recommended as well. The booking data prior to a modification should be maintained in the affiliate's database for customer support purposes. This will give an affiliate the ability to research customer search issues that may arise due to the modification of a reservation
An example of the ModifyReservation message is shown below using active session control. Note that the UpdateReservation element includes a full recap of all the reservation information, not just the information that has changed. Also note that the Reservation element contains information that is required to uniquely identify the reservation – such as confirmation number and dates of stay etc.
The response message is shown below. Note that it includes the SessionID but no confirmation number:
The affiliate then sends a SessionControl request message to commit the transaction using the SessionID in the previous response:
A successful response is shown below. Now that the modification is committed, the ConfirmationNumber is returned. This may be the same or different from the original confirmation number, depending on the hotel CRS.
