ProcessTerms Request

The ProcessTerms request is the last request to be submitted before the final request to book the flight. In order to maintain session continuity on the supplier web site, the final booking request must be made soon after the ProcessTerms request. Multiple ProcessTerms requests should not be submitted for a particular session (i.e. search) unless a data validation error is returned (necessitating a correction to the data and resubmission of the ProcessTerms request). The ProcessTerms request relates to the flight selected in the most recent ProcessDetails request.

 
 XML Field  Description
 CommandList  The surrounding tag
 -ProcessTerms  The command name
 --XmlLoginId  The xml customer login id. See the Login guide
 --LoginId  The end user login id. See the Login guide
 --RoutingId
 The routing id corresponding to that returned previously.
 --OutwardId  The id of the outward leg. Whilst the ProcessTerms request always relates to the flights specified in the most recent ProcessDetails request, the 'OutwardId' corresponding to the last ProcessDetails must be submitted. Failure to do so may result in an error.
 --ReturnId  The id of the return leg. As per the above a 'ReturnId' must always be submitted for return journeys, and must relate to the last ProcessDetails.  Please see OutwardId above for details. Failure to do so may result in an error.
 --BookingProfile
    [Optional]
 This element must be supplied if there is any profile data that has not yet been supplied. Note that any of the elements or sub-elements below are optional if they have been supplied previously (at the search stage). Otherwise they are mandatory unless stated otherwise.
 ---CustomSupplierParameterList
    [Optional]
 Contains any special parameters that are needed for this search/ booking. Contains 0 or more CustomSupplierParameter elements
 ----CustomSupplierParameter
    [Optional]
 Contains a parameter to be used for this search / booking
 -----Supplier
    [Optional]
 The supplier to which this parameter applies. If this element is omitted, then it will be assumed relevant to all suppliers. If multiple CustomSupplierParameter elements have the same Name value, then the first match will be used. For example if AgentLogin is specified first for easyjet and then for all suppliers, then the first definition will be used if the supplier is easyjet. However if it is specified first for all carriers and then for easyjet, the second definition will never be used.
 -----Name  The name of the parameter. There are 2 types of custom parameter. The first type corresponds to those in the RequiredParameterList in the related Router (see CheckRouting Response) - these must be submitted here if they were in the required parameter list, and may be submitted even if they were not in the required parameter list. The second type may be supplied in any search / booking process to activate special functions. See the sub-section below for details of the additional parameters for the Name element that activate special functions. These additional parameters will never appear in the required parameter list.
 -----Value  The value of the parameter.
 ---TravellerList  The list of travellers and their details. Contains 1 or more Traveller elements. The first will be assumed to be the lead passenger
 ----Traveller  A Traveller
 -----Age  The age of the Traveller. This should match the age of the corresponding Traveller in the previous Search request (i.e. the traveller in the same position in the list - e.g. the third traveller in this list corresponds to the third traveller in the list submitted in the previous Search request)
 -----Name  The name of the Traveller. See the sub-section below for details of the General Name Format. The title field must be supplied for all travellers.
 -----CustomSupplierParameterList
    [Optional]
 Contains any special parameters that are needed Per Passenger for this search / booking. Format will be the same as CustomSupplierParameterList above
 ---ContactDetails  The correspondence details
 ----Name  The name of the person to be contacted. See the sub-section below for details of the General Name Format.
 ----Address  The correspondence address (Not necessarily the passenger's address). See the sub-section below for details of the General Address Format
 ----HomePhone
    [Optional 1 of 3]
 The correspondence home phone number (Not necessarily the passenger's number). See the sub-section below for details of the General Phone Format. At least one of HomePhone, WorkPhone or MobilePhone must contain data
 ----WorkPhone
    [Optional 1 of 3]
 The correspondence work phone number (Not necessarily the passenger's phone). See the sub-section below for details of the General Phone Format. At least one of HomePhoneWorkPhone or MobilePhone must contain data
 ----MobilePhone
    [Optional 1 of 3]
 The correspondence mobile phone number (Not necessarily the passenger's phone). See the sub-section below for details of the General Phone Format. At least one of HomePhoneWorkPhone or MobilePhone must contain data
 ----Fax
    [Optional]
 The correspondence fax number (Not necessarily the passenger's number). See the sub-section below for details of the General Phone Format.
 ----Email  The correspondence email address (Not necessarily the passenger's email address). Must be a valid email address. Must contain no whitespace (leading / trailing or otherwise)
 ---BillingDetails  Contains billing details
 ----Name  This is the name of the person to be billed. It may be different or formatted differently to the NameOnCard. See the sub-section below for details of the General Name Format.
 ----Address  The billing address. See the sub-section below for details of the General Address Format.
 ----CreditCard  Contains details of the credit card to be used for payment
 -----Company  Free text. The company of the card holder
 -----NameOnCard  See the sub-section below for details of the General Name Format. Note that if FullCardNameBreakdown is required (see RequiredParameterList in search and results responses), then the name should be broken down as much as possible using the Title and NamePart fields. Otherwise it should be specified as a single NamePart and the Title should be omitted.
 -----Number  An integer. The card number.
 -----SecurityCode  An integer. This field should always be submitted unless it is unknown. In this case, it may not be possible to complete the booking. This will depend upon the supplier and the card type
 -----ExpiryDate  Format is mm/yy. The expiry date of the card
 -----StartDate  Format is mm/yy. The start date of the card. This field should always be submitted unless it is unknown. In this case, it may not be possible to complete the booking. This will depend upon the supplier and the card type
 -----CardType  The type of credit card to be used. The list of possible values for this field can be found by submitting the 'GetSupportedCardTypeList' XML request. This list may change at any time. Customers are requested to build their system in such a way that such changes are handled correctly. For example if a new type of card is introduced, it will be added to the system without notice.
 -----IssueNumber  An integer. This field should always be submitted unless it is unknown or it is not relevant to the particular card type. If it is omitted, but required by the supplier, it will not be possible to complete the booking

Additional parameters for the Name element that activate special functions

These parameters will never appear in the required parameter list.
Value Description Format Default
MaxCacheDataAgeSeconds The maximum allowed age of flight data. For example, if this has value 86400, data will not be returned that is older than 1 day (If necessary, a new search will be performed with the supplier). You must not submit this parameter without explicit permission in writing from Travelfusion. Integer. 0 or negative indicates latest data must be fetched from supplier. If this CustomParameter is not supplied, the caching rules will be taken from the user account profile.
Language Specifies the point of sale of the search/ booking, or activates any other language or locale specific functionality that is supported by Travelfusion. For example, drop-in URLs can be customised so that the the user is dropped in to the appropriate language version of the supplier website.

The parameter name itself could be a bit misleading so please pay attention to its real reference.
Standard locale code in the format of country code-language code, E.g. GB-EN If this CustomParameter is not supplied, or the code supplied is not recognised or supported in the specific case, an appropriate default will be used - for example the user will be dropped in to the English version of the supplier's site. If you do not have a list of the standard country codes, please contact Travelfusion.
AirPlusAccountingUnit Special descriptive billing fields for payments through Air Plus (AIDA) cards. Corresponds to the AE DBI field in Air Plus system. Free text - (1-17, alphanumeric)
 AirPlusOrderIdentifierSpecial descriptive billing fields for payments through Air Plus (AIDA) cards. Corresponds to the AU DBI field in Air Plus system.Free text - (1-17, alphanumeric)
 AirPlusDepartmentIdentifierSpecial descriptive billing fields for payments through Air Plus (AIDA) cards. Corresponds to the DS DBI field in Air Plus system.Free text - (1-17, alphanumeric)
 AirPlusAccountIdentifierSpecial descriptive billing fields for payments through Air Plus (AIDA) cards. Corresponds to the IK DBI field in Air Plus system.Free text - (1-17, alphanumeric)
 AirPlusCostCentreSpecial descriptive billing fields for payments through Air Plus (AIDA) cards. Corresponds to the KS DBI field in Air Plus system.Free text - (1-17, alphanumeric)
 AirPlusEmployeeIdentifierSpecial descriptive billing fields for payments through Air Plus (AIDA) cards. Corresponds to the PK DBI field in Air Plus system.Free text - (1-17, alphanumeric)
 AirPlusProjectIdentifierSpecial descriptive billing fields for payments through Air Plus (AIDA) cards. Corresponds to the PR DBI field in Air Plus system.Free text - (1-17, alphanumeric)

General Address Format

When submitting an address to a supplier, the various address fields below will be used appropriately. If the supplier offers a free text field for inputting the address, the data elements below will be concatenated together in the order that they appear. This means that an element can be left blank and its data could be included in the next element, which will not cause a problem unless that separation of data is required by the supplier. For example if BuildingNumber is left blank and Street contains '3 Duck Street', then if the supplier asks for a free text address, then '3 Duck Street' will be submitted to the supplier. However if the supplier requests the building number separately to the street name, an error will occur. It is recommended that all addresses be broken into the items listed below to ensure compatibility with all suppliers.
 XML Field  Description
 -Company  Free text representing the company to which the contactee belongs
 -Flat  Free text. Defines the flat number within the building
 -BuildingName  Free text. Defines the building name.
 -BuildingNumber  Free text. Defines the building number within the street.
 -Street  Free text. The street name
 -Locality  Free text. The locality / area within the city
 -City  Free text. The city name.
 -Province  Free text. The county or province. If value is unknown, submit OT
 -Postcode  Free text. The postcode. If the postcode is required (See PostCode parameter here), but is not known or available for some reason, a dummy value should be submitted as the Travelfusion system requires a value for this field. It is recommended that a value is used that could not be interpreted as a real postcode, such as 'NONE'.
 -CountryCode
    [Optional]
 The standard ISO 3166 two letter country code (e.g. GB). If you do not have a list of the standard country codes, please contact Travelfusion. The country code should be supplied whenever possible. Failure to do so may mean that the booking can not be made with the supplier.

General Phone Format

Similarly to addresses, the fields below will be concatenated to form a single number when this is required by the supplier. However if the supplier requires the number to be split up as below, then it must be split up correctly when supplied to Travelfusion.
Whilst these fields can contain characters other than numeric digits, it is recommended to only send numeric digits to Travelfusion as some suppliers may require this. Travelfusion does not take responsibility for the re-formatting of phone number data although measures will be taken to re-format wherever possible / necessary.
 XML Field  Description
 -InternationalCode  Free text. The international dialing code.
 -AreaCode  Free text. The local area code
 -Number  Free text. The phone number
 -Extension  Free text. The internal extension number

General Name Format

A general name contains one or more NamePart elements. For example a person with full name 'Mr Jason Robert Smith' will be represented as 3 NamePart elements with values 'Jason', 'Robert' and 'Smith' and Title value 'Mr'. In cases where only an initial is available, then this should be submitted as the value of the NamePart. e.g. 'Jason', 'R', 'Smith'. Note that in principle the entire name (including title) can be sent as a single NamePart (for example this should be done for the name on card, except in special cases where the supplier requires a broken down name). However, this may or may not be accepted depending on what the name is to be used for. For example it may depend upon the supplier behaviour. In general the name should be broken down as much as possible and the title should be entered into the Title field if possible, and not included in a name part.

In cases where a first and lastname/surname are requested by the supplier, they will be assumed to be the first and last NamePart in the list. Therefore please take particular care with cases like Spanish names where the first or last name may consist of multiple separate parts. For example, if the traveller's passport states the last name as 'Andres Hurtado' and the first name as 'Maria Jose' ('Pepita' being a middle name), then the NamePartList XML should be structured as follows:
<NamePartList>
   <NamePart>Maria Jose</NamePart>
   <NamePart>Pepita</NamePart>
   <NamePart>Andres Hurtado</NamePart>
</NamePartList>
If a supplier requires the merging of some or all of the title/ name parts, they will be merged in the order they appear below separated by a single 'space' character. i.e. title first, then all the name parts in the order they occur in the XML.
 XML Field  Description
 -Title
    [Optional in some cases]
    [Required in some cases]
 Value must be one of: Mr, Mrs, Miss. No other values are supported as values like 'Ms' often cannot be mapped to a supplier value (e.g. if the supplier only offers 'Mrs' and 'Miss'). If more options are required, please contact Travelfusion.
 -NamePartList  Represents the list of individual names that make up the full name.
 --NamePart  Free text. Represents one part of the full name. e.g. 'Robert' as in 'Jason Robert Smith'. Trailing and leading white space will be trimmed. Must not be empty after trimming.