Preventing Duplicate Bookings in the Event of a Time Out

A booking attempt can time out if:

  • The affiliate server time out settings are too low
  • The reservation processing system is slow at the supplier level
  • The payment gateway is slow at the payment processing level
  • Servers become overloaded due an unexpected surge in traffic

Where does the time out occur?

  • A time out can occur on the affiliate server if the response takes longer than your server settings. We recommend at least 30 seconds to allow all reservation and payment processing. Although we rarely expect processing to take this long, we are reliant on the efficiency of supplier and payment gateways.
  • A time out can occur on our own servers if the supplier or payment gateways run longer than our 60 second time out setting before we receive a result. Processing may still be successful, however, even if all systems time out before the outcome of the reservation is known. Unfortunately, this means we may not have all confirmation info without checking the system.

How do I check to see if a booking still resulted in the event of a time out, or if the reservation result is returned empty because of timed out systems at any level?

Study the Reservation Request outline for details on using the affliateConfirmationId, which can be used to find a booking in the event of a timed out occurrence where a successful confirmation or itinerary is not known.

  • You can prevent duplicate bookings by including special logic in your booking pages to handle timed out bookings or empty reservation results
  • Mssage the appropriate information to the user and use proper logic to recover the booking.

affiliateConfirmationId (string)

  • This item is intended for
    • your own tracking
    • preventing duplicate bookings/charges submitted by users
    • checking the system for an itinerary if the reservation timed out or returned an empty result due to timed out processes on third party systems
  • Must use a unique value, such as a GUID, for every request - reusing values, even for failed bookings, will cause booking failures.
  • The ID should be created before the user submits the final reservation form. If the same user hits the Submit button again, the same affiliateConfirmationId will be sent and will be detected as a duplicate booking.
  • Exercise extreme caution when sending this element, as there are many cases when a brand new request should be made with a NEW affiliateConfirmationId, such as a failed or unrecoverable booking.

Steps to determine if a booking exists when a time out occurs on a reservation request or the result is returned empty.

  1. Reservation request is sent with a unique affiliateConfirmationId
  2. A time out occurs or no results return after an extended period
  3. Upon time out or empty reservation result sets, place an itinerary request using only the affiliateConfirmationId.

  4. This itinerary request will return any itinerary info for that affiliateConfirmationId, if one was created, including the booking status:

    • CF - confirmed reservation
    • PS - pending: See our pending process.
    • UC - unconfirmed: This booking is no longer available and will not be confirmed.
    • DT - deleted: the request is cancelled and the itinerary is deleted from any stats. This typically occurs on booking requests where unrecoverable errors were obtained.

Possible Results

If a result is returned from the itinerary request with any other status than CF:

  • Alert the user that there was an issue with their booking and provide the status of the booking.
  • If handling = AGENT_ATTENTION is returned, an agent will contact the user within 24 hours or less.

If a result is returned from the itinerary request with CF, show results of the successful booking from the itinerary results to the user the same as if the booking was successfully confirmed without any time outs.

If no results are returned * A booking did not result during the timed out reservation request. * Alert the user that there was an issue with processing the booking and offer a follow up choice of properties for them to attempt again. * Be sure to issue a new affiliateConfirmationId, since this must be a unique value on every booking request.

Preventing Duplicate Submissions

Users will create duplicate bookings every time they hit an unrestricted Submit button or refresh the booking page for the same reservation.

Because of the nature of the web, electronic systems, and other uncontrollable factors, transmitted submission and response times can sometimes be delayed.

  • If this occurs, users can become impatient by clicking your reservation submission method more than once.
  • In these instances, a new booking is created for every submission that is sent.
  • Since actual confirmation responses can be overwritten with newer responses, the user may not see or detect their booking has been submitted more than once and actually duplicated on your site until they either find the confirmation emails in their email box or show up at the property.

How do duplicate bookings affect the user?

  • On prepaid reservations, this means their credit card is charged each time the duplicate submission is received and a new reservation record is created.

How do duplicate bookings affect me as an affiliate?

  • Every affiliate is responsible for creating their own applications, therefore the affiliate is also responsible for their customers.
  • If proper handling is not exercised, customer disputes can create unnecessary charges that will be charged directly to the affiliate.

To prevent duplicate bookings, include special logic in your booking pages to handle multiple submissions and message the appropriate information to the user.

  • In many cases, simply stating that their card will be charged twice if they click more than once will prevent the majority of cases.
  • You can also add simple code to disable your booking page's Submit button after the first click event, preventing repeat clicks during load time.
  • In other web failure cases, you'll need special handling to insure the booking isn't sent twice when only one reservation was intended.

Special handling should also take note that some booking errors can be resolved by resubmitting the request.

  • Depending on the nature of the failure and the handling code of an exception that is returned at booking time, you can determine that a booking should be resubmitted.
  • In these cases, the booking is not duplicated but tried again for successful processing.

Study the Reservation Request outline for details in using the <affliateConfirmationId>, which can help our system detect a duplicate booking attempt.

Lastly make use of the Itinerary Request to check for an existing itinerary or the status of an existing itinerary.