Travelfusion Direct Connect XML API > Guidelines >

Booking On Hold

Contents

Step 1: Retrieving booking-on-hold details.

ProcessDetails

Step 2: Requesting booking-on-hold.

ProcessTerms

StartBooking and CheckBooking

Step 3: Requesting the commit preview details.

Step 4: Confirming or cancelling booking-on-hold.

CommitBooking

StartBookingCancelPlane and CheckBookingCancelPlane

With airline suppliers it is possible to put the booking on hold and finish the payment later via the Travelfusion XML API.

This functionality is not currently available on all suppliers. However, for suppliers that do support it, the command and syntax of the requests and responses are almost identical to that of the normal booking flow.

In order to indicate the Booking-On-Hold feature is available there is a special CustomSupplierParameter named BookingOnHold found in ProcessDetails response.

Step 1: Retrieving booking-on-hold details.

ProcessDetails

If booking-on-hold is available for the selected result, then the BookingOnHold parameter will be found in the RequiredParameterList:

RequiredParameterList XML example

<Name>BookingOnHold</Name>

<Type>boolean</Type>

<DisplayText>Request booking-on-hold (y/n). Please note the booking will expire in: 3 days, 1 hour, 59 minutes</DisplayText>

// example values: 1 day; 1 day 10 hours; 24 hours; 24 hours 30 minutes

<PerPassenger>false</PerPassenger>

</RequiredParameter>

</RequiredParameterList>

Additionally, in the SupplierInfoList a remark will be found, showing the duration before this booking-on-hold expires:

SupplierInfoList XML example

<DisplayName>Booking-On-Hold expiry period</DisplayName>

<InfoType>remark</InfoType>

// example values: 1d, 1d10h, 24h, 24h30m

</SupplierInfo>

</SupplierInfoList>

Step 2: Requesting booking-on-hold.

ProcessTerms

In order to request booking-on-hold, the BookingOnHold parameter needs to be sent in the ProcessTerms request with the boolean value 'y' or 'true', in the similar way that other CustomSupplierParameter's are submitted:

CustomSupplierParameterList XML example

<Name>BookingOnHold</Name>

</CustomSupplierParameter>

</CustomSupplierParameterList>

Check here to find more details on how to handle the CustomSupplierParameter's.

StartBooking and CheckBooking

The StartBooking, CheckBooking requests remaining the same as for the normal booking flow.

The only difference is related to status. The successful holding booking process sets the booking status as 'BookingOnHold'.

StartBooking and CheckBooking XML example

// request

</StartBooking>

// response

</StartBooking>

// request

</CheckBooking>

// response

<Status>BookingOnHold</Status>

</CheckBooking>

The none successful holding booking process can set the booking status as 'Failed' or 'Unconfirmed' (more details can be found here). In this case of 'Failed', the booking is not created and put on-hold on the supplier side. In the case of 'Unconfirmed', TravelFusion needs to resolve the status and check if the booking can be set as 'BookingOnHold' or 'Failed'.

Step 3: Requesting the commit preview details.

Right before starting the process of committing the on-hold booking (see CommitBooking command), the user should submit the GetBookingDetails command (see GetBookingDetails request and response XML) in order to check if the booking can still be committed. The request must contain the ‘IsBookingForCommit’ CustomSupplierParameter in order to retrieve the commit preview details. Other custom supplier parameters are optional (depending on the supplier), however they may affect the process of committing the on-hold booking.

Where possible, the GetBookingDetails retrieves the latest price information from the supplier’s system and, if there are any price changes, it updates the booking price accordingly.

The BillingDetails element in the request needs to be the same as that included in the ProcessTerms request. Depending on the response (e.g. as in the credit-card-declined example response shown further below) and if the supplier allows for it, then the user may be able to reattempt with different billing details.

In the GetBookingDetails response, the DateOfOnHoldExpiration element contains the time of expiration of the on-hold booking in UTC+00:00 timezone. If optional element SupplierDateOfOnHoldExpiration is present, then a) the user should ignore DateOfOnHoldExpiration and retrieve the time from SupplierDateOfOnHoldExpiration instead, and b) the timezone can not be known; however, the optional attribute timezoneSource will indicate where the timezone information can be found. Possible values of attribute timezoneSource are ‘agent’, ‘supplier’ and ‘unknown’; when this attribute is not present, it is equivalent to having the value of ‘unknown’.

GetBookingDetails request XML example

<Name>IsBookingForCommit</Name>

</CustomSupplierParameter>

</CustomSupplierParameterList>

<Name>

<NamePart>Peterson</NamePart>

</NamePartList>

</Name>

<Company>TravelFusion</Company>

<BuildingName>Dean's Court</BuildingName>

<Street>St. Georges Road</Street>

<Locality>Clifton</Locality>

<City>Bristol</City>

</Address>

<Company>Travelfusion</Company>

<NamePart>Peterson</NamePart>

</NamePartList>

</NameOnCard>

<CardType>MasterCard</CardType>

</CreditCard>

</BillingDetails>

</BookingProfile>

</GetBookingDetails>

</CommandList>

GetBookingDetails response XML example

<Status>BookingOnHold</Status>

<SupplierReference>NFJNDS</SupplierReference>

...

...

...

<Group>

...

<Price>

<!--

the price updated based on the supplier latest price look-up,
in most cases it doesn't change

-->

</Price>

</Group>

</GroupList>

</BookingRouter>

</RouterHistory>

...

</GetBookingDetails>

</CommandList>

GetBookingDetails request XML example (credit card declined)

In this case, the user may reattempt GetBookingDetails using a different credit card.

</CommandExecutionFailure>

</CommandList>

GetBookingDetails request XML example (supplier rejects commit)

This is the case where the supplier does not allow the commit. The on-hold booking process should stop here, and reattempts are not recommended or necessary.

</CommandExecutionFailure>

</CommandList>

Step 4: Confirming or cancelling booking-on-hold.

CommitBooking

In order to commit the booking and proceed with the payment, the CommitBooking needs to be sent.

The successful commit of the booking-on-hold process sets the booking status as 'Succeeded'.

The BillingDetails needs to be the same as in the ProcessTerms request.

CommitBooking request XML example

<Name>

<NamePart>Peterson</NamePart>

</NamePartList>

</Name>

<Company>TravelFusion</Company>

<BuildingName>Dean's Court</BuildingName>

<Street>St. Georges Road</Street>

<Locality>Clifton</Locality>

<City>Bristol</City>

</Address>

<Company>Travelfusion</Company>

<NamePart>Peterson</NamePart>

</NamePartList>

</NameOnCard>

<CardType>MasterCard</CardType>

</CreditCard>

</BillingDetails>

</BookingProfile>

</CommitBooking>

CommitBooking response XML example

<Status>Succeeded</Status>

</CommitBooking>

The none successful commit process can set the booking status as 'Failed' or 'Unconfirmed' (more details can be found here). In this case of 'Failed', the booking remains on-hold or is not possible to be committed on the supplier side. In the case of 'Unconfirmed', TravelFusion needs to resolve the status and check if the booking can be set as 'Succeeded' or 'Failed'.

The booking-on-hold with the status 'Failed' can still be committed or cancelled again if it is possible to do so.

StartBookingCancelPlane and CheckBookingCancelPlane

This request will cancel bookings with status 'BookingOnHold' for which users do not wish to proceed with a commit or the booking-on-hold expired.

The successful cancellation of the booking-on-hold process sets the booking status as 'CancelSucceeded'.

StartBookingCancelPlane and CheckBookingCancelPlane XML example

// request

</StartBookingCancelPlane>

// response

</StartBookingCancelPlane>

// request

</CheckBookingCancelPlane>

// response

<Status>CancelSucceeded</Status>

</CheckBookingCancelPlane>

The none successful cancellation process can set the booking status as 'CancelFailed' or 'CancelUnconfirmed'. In this case of 'CancelFailed', the booking remains on-hold or is not possible to be cancelled on the supplier side. In the case of 'CancelUnconfirmed', TravelFusion needs to resolve the status and check if the booking is 'CancelSucceeded' is or 'CancelFailed'.

The booking-on-hold with the status 'CancelFailed' can still be committed or cancelled again if it is possible to do so.

It is the responsibility of the user of the API to cancel these bookings because TravelFusion cannot guarantee that they will be automatically cancelled by the airline and also in order to release the seat.