Cached Data and Price Change Guide

Caching

Travelfusion maintains an internal data cache of supplier data. This is for 2 main reasons:

• • To reduce the number of searches submitted to the suppliers' systems

  • To improve Travelfusion's server response times

This means that in the CheckRouting response, some prices will be out of date. The 'age' of each price is supplied in the CacheDataAgeSeconds element (see the detailed spec of the CheckRouting response).

The algorithm used to cache data has been carefully designed by Travelfusion to optimise the balance between data accuracy and cache efficiency. For more information please contact Travelfusion.

To make best use of the cached data, prices are sometimes returned in a different currency to that which would be returned by the supplier if the same search were performed directly on their system. For example if a search is submitted to a supplier for a return flight from London to Dublin, the supplier may quote the price of both legs in GBP. However, if a search is then executed for a single from Dublin to London on the same date as the return leg in the previous search, the data already stored for that leg can be reused. This means that the currency returned would be GBP even though the supplier would quote the flight in EUR if the same search were submitted directly to their system. This behaviour can affect both single and return journeys and it can even cause the two legs of a return flight to be returned in different currencies. No assumptions should be made about what currency the legs will be returned in, and all prices should always be converted in the required currency.

Under special circumstances it may be possible to allow caching to be deactivated or to adjust the algorithm to cache data for more or less time. Please contact Travelfusion if you require such changes.

Once the end user has selected a flight, a ProcessDetails request must be submitted to Travelfusion. This will cause a live request to be made to the supplier and so an up-to-date price will be returned. The ProcessDetails request must only be submitted once the user has manually selected a flight.

Price Changes

As well as out-of-date cached prices, there are other reasons that the price may change after the CheckRouting stage. For example:

• • If the user chooses to pay with a card type that incurs an extra charge from the supplier, this will be included in the price in the ProcessTerms response. Where possible, the list of available cards and their related charges is returned in the ProcessDetails response so that these can be displayed to the user before they decide which card to use (see the SupportedCardList in the ProcessDetails response spec.)

  • The price returned by the supplier is sometimes out-of-date, or can be updated by them for other reasons during the booking process. Such changes would lead to changes in price in the ProcessDetails or ProcessTerms stages.

  • Some supplier bookings fail after the StartBooking request due to price changes and this must be handled carefully. If the relevant error (8010) is returned in the CheckBooking response, the user must be informed that the price of the flight has changed. There are a number of ways to handle this situation:

    • The user can be instructed to repeat the search and booking process from the beginning. This is the simplest solution but the worst user experience. Or...

    • The search, details and terms requests can be automatically submitted again in the background to get the latest price from the supplier. This new price can then be displayed to the user and they can choose whether to continue or cancel the booking. If they choose to continue and the same error is then returned again, the booking should be abandoned in order to avoid a loop situation.