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 recentProcessDetails request.
Additional parameters for the Name element that activate special functions
These parameters will never appear in the required parameter list.
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.
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.
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:
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.