Creating Air Bookings

UniversalRecordReqRsp.xsd

Air Pricing > Create Air Booking OR
Low Fare Shop > Air Pricing (recommended) > Create Air Booking

Air booking creates a reservation and stores an air itinerary. Air booking can include pricing information in the reservation; however, pricing data is usually not required for booking. Some carriers do require payment and ticketing at the time of booking.

Note: Booking creates a reservation only. You must subsequently ticket the itinerary or the airline will release the itinerary. The length of the hold varies by airline.

To add an air booking to an existing PNR or Universal Record, see Modifying Air Bookings.

Air bookings are created using the results from an Air Pricing response after searching for air segments and fares. Air bookings can also be created using the results from a Low Fare Shopping response; however, a subsequent Air Pricing call is recommended to confirm fares.

Note: For Airline Content Hub, an Air Pricing call is required before booking.

Schema

Located in Universal.xsd:

How To

  1. Following an Air Pricing or Low Fare Shopping response, send an AirCreateReservationReq with at least the minimum required data.

    • Within AirCreateReservationReq/BookingTraveler, at least one /BookingTravelerName and one /PhoneNumber are required. Refer to Booking Traveler Name for limitations.

    • Send AirCreateReservationReq/ActionStatus to indicate the queue or ticketing status of the booked air segment (optional in Galileo).

    • To add the air segment as a new PNR in an existing Universal Record, specify the existing Universal Record using AirCreateReservationReq @UniversalRecordLocatorCode.

  2. If an Air Pricing request was made prior to the reservation request, the following information is required and is found in the Air Pricing response.

    • For each air segment in the trip, include a /AirPricingSolution/AirSegment element with @Group, @Carrier, @FlightNumber, @Origin, @Destination, and @DepartureTime.

      If an air segment contains a connection, use /Connection to ensure the flights are sold correctly and a sell failure does not occur. See Air Segment Connection Logic for more details.

    • If ticketing is performed at the time of booking, FormOfPayment and Payment are also required.

      Note: Most ACH carriers require payment at the time of booking.

  3. If booking branded fares, enter AirPricingSolution/HostToken and AirPricingSolution/AirpricingInfo/BookingInfo @HostTokenRef.

    In Release 16.2.1 a Host Token was implemented to aid with the pricing and booking of branded fares. Some fare components identifying certain brands were complex for the current pricing and booking transactions. The new implementation contains all the required fare components to properly retain a specific fare (and associated brand) when performing a pricing and/or booking transaction. The Host Token solution applies to Galileo and Worldspan. Apollo users should see the Brand Tier solution.

    In 18.1, the Brand Tier modifier was implemented to also aid with the pricing and booking of these complex branded fares. The Host Token solution is unique to Universal API while the Brand Tier modifier is used by all points of sale at Travelport (Smartpoint, Galileo Desktop, WorldspanGO). The Brand Tier modifier is the preferred way to price and book branded fares. The Fare Host Token may still be used but might be retired in the future. Release 18.1

    Differences between the two solutions:

    • Host Token: Retains the exact fare during the book transaction that was returned in the AirPrice response.
    • Brand Tier: Reprices the fare during the book transaction to get the best fare within the desired brand.

    Important:

    • When both brand tier and a fare host token are sent in a pricing request, the brand tier is used and the fare host token is ignored. A warning is returned: The fare HostToken has been ignored. The BrandTier has been applied.
    • In a price response, a brand tier and fare host token may be returned. If you copy and paste the entire pricing solution into the Air Booking or Universal Record Modify transaction without removing either the brand tier or the fare host token, then the fare host token is ignored.
    • To use the host token instead of the brand tier, remove the brand tier from the Air Booking or Universal Record Modify request in Universal.xsd v43.0 and later. Release 18.1

    Notes:

    • The Host Token should be used in the Air Price and Air Booking requests for both branded and non-branded fares.

    The HostToken can be included in the AirPriceReq to price a specific brand or fare. Regardless of whether they are included in the Air Price request, both the HostToken and HostTokenRef are returned in the Air Price response and should be used in the Air Create Reservation request to successfully book the desired brand or fare, or in the Universal Record Modify AirAdd to successfully add the desired brand or fare to the UR. If they are not sent in the Air Create Reservation request or the Universal Record Modify Air Add request, the lowest brand or fare is typically booked by default.

    • AirPricingSolution/AirPricingInfo/BookingInfo @HostTokenRef
    • AirPricingSolution/HostToken

    Note: The HostToken and HostTokenRef are supported for 1G, 1V, and 1P and are different from ACH Host Tokens.

    Please see the Universal API Demo site for sample XML of the implementation of these Host Tokens.

  4. Additional optional data can be sent in AirCreateReservationReq.

    Optional information Description

    Return Amenities - Routehappy

    Routehappy amenity content, including Seat, Wi-Fi, Power, Entertainment, Food, Beverage, Aircraft, and Layout, is returned in version 53 of the Shop, Price, Book, and Retrieve responses when the ReturnAmenities="true" attribute is included in the request. N

    Sample

    Seat assignments

    AirCreateReservationReq/AutoSeatAssignment and /SpecificSeatAssignment are used to include seat assignments with the booking.

    /AirPricingSolution/OptionalServices/OptionalService @Type="PreReservedSeatAssignment" is used to request paid seats for ACH carriers. Specify the seat number using /OptionalService/ServiceData @Data. For ATPCO carriers, use the Stand-Alone Merchandising Flow.

    Forms of payment

    Payment can be specified at the provider reservation (PNR) level or the stored fare level across a single or multiple stored fares. Refer to Air Booking with Form of Payment for detailed information.

    Passenger type, geography, and residency

    Passenger type, personal geography, and residency type are defined in AirPricingSolution/AirPricingInfo/PassengerType. If no passenger type is sent, adult is assumed.

    Personal geography can be used for locale-specific requirements.

    Passenger type codes

    If Passenger type codes (PTC) are included (PassengerType @Code):

    • Age is never sent for an adult (ADT), even if an age is included.
    • Age is sent for all other PTCs only when a user specifies age.
    • Galileo and Apollo limit each PNR to six PTC types. Use of an age with a PTC makes that PTC unique. For example, C08 and C12 are processed as two distinct child PTCs.

    Personal geography

    The PassengerType/PersonalGeography element supports submitting Country, State or Province, or City Code. One of these fields must be submitted per booking traveler.

    Personal geography can be used for locale-specific requirements. For example, Argentina has separate fares for residents and non-residents. To be eligible for a resident discount, passengers must provide:

    • A Certificate of Residence or Parliamentary/Senatorial credentials.
    • A valid passport or national identity card.

    Residency type

    Residency (PassengerType @ResidencyType) is required to validate the rules of some air fares such as Seaman, Government, and Military.

    Personal Geography data supports location-specific fares. This data is used to validate fares for some passenger types (PTCs), as well as residency data.

    Applied residency type returns in booking and ticketing retrieve responses, so that the nationality from the applied residency type by passenger line or data can be applied in a future exchange. This is useful because of taxes based on nationality. For example, Mexico has a tax for foreigners and Argentina has two taxes for residents. Release 23.1

    Note: Personal geography is supported by Galileo (1G) and Apollo (1V) for Spanish Resident fares only.

    Optional services

    Send /AirPricingSolution/OptionalServices/OptionalService elements for selected services.

    Send OptionalService elements for the selected services.

    Each Optional Service that is submitted should be a different type. For example, users should not send two OptionalService elements for "checked 1st bag". Optional Services that are not a paid seat can be sent with a @Quantity greater than 1. If the @Type is a bag type (pre-paid or chargeable) and if @Quantity is not specified, the provider assumes a value of "1".

    If the request includes an Optional Service that references a Booking Traveler Passenger Type Code (PTC) that includes an age, Universal API converts the PTC with age to an applicable three-alpha-character PTC and saves the Optional Service in the Universal Record (UR). For example, if the PTC is C08, Universal API converts to PTC CNN. CNN is saved in the UR.

    Note: The attributes WeightInExcess, TotalWeight, and BaggageUnitPrice are not currently returned in the response.

    /ServiceData

    For OptionalService/ServiceData, only one @BookingTravelerRef and one @AirSegmentRef can be referenced. If two Booking Travelers request the same optional service, two OptionalService elements must be created, each with an OptionalService/ServiceData element referencing one Booking Traveler with one Air Segment. When the Optional Service applies to multiple Air Segments, multiple ServiceData can be sent, each referencing the Booking Traveler and one Air Segment.

    @ViewableOnly

    The following apply to @ViewableOnly:

    • When @ViewableOnly="true" for ALL Optional Services, Universal API ignores the OptionalService elements and creates a booking and Universal Record that contains the air segments and other pertinent details. The booking does not fail, but:

      • ASVC SSR(s) are not created.

      • The Optional Services are not sold or saved in the Universal Record.

      • A warning is returned: ViewableOnly Services cannot be sold.

    • When @ViewableOnly="true" for at least one Optional Service:

      • Optional Services that have ViewableOnly="false" are fulfilled as normal. Universal API creates a booking and a Universal Record that contains the air segments and other pertinent details.

      • Optional Services that have ViewableOnly="true" are ignored.

        • ASVC SSR(s) are not created.

        • The Optional Services that are viewable only are not sold or saved in the Universal Record.

      • A warning is returned: ViewableOnly Service <service type> <description> for AirSegment <air seg ref> and BookingTraveler <traveler ref> cannot be sold. This warning message is returned for each OptionalService that has ViewableOnly="true".

      • In the message:

      • <service type> = OptionalService @Type
      • <air seg ref> = OptionalService/ServiceData @AirSegmentRef
      • <traveler ref> = OptionalService/ServiceData @BookingTravelerRef
      • <description> = OptionalService/Description (if present in the request)

      For example: ViewableOnly service Baggage BAGGAGE BETWEEN 51 AND 70 LBS for AirSegment (VbVzfleySiKayTIj2/y4Ew==) and BookingTraveler (vA+WEeORQS2pUsrTiZo9tQ==) cannot be sold.

    • If a warning is returned for an Optional Service with multiple AirSegmentRef attributes in OptionalService, the warning lists each AirSegmentRef separated by a comma.

      • For example: ViewableOnly service Baggage BAGGAGE BETWEEN 51 AND 70 LBS for AirSegment (VbVzfleySiKayTIj2/y4Ew==), AirSegment (Ngov0tT9SfGcQ5J/XQ7h5Q==) and BookingTraveler (vA+WEeORQS2pUsrTiZo9tQ==) cannot be sold.

    @IsRepriceRequired / C Type Baggage

    Prior to Universal API release 21.2.2, customers were limited to viewing prices and purchasing F type filed bags only. Release 21.2

    Release 21.2.2 and later allows customers to receive baggage data and purchase bags for itineraries where C type data has been filed by the carrier.

    C type baggage data is shopped and sold via the following:

    • C type baggage including max quantity and price information is viewable in the AirPrice and AirMerchandisingOfferAvailability responses.

    • C type baggage is sellable in the AirCreateReservation and AirMerchandisingFulfillment requests.

    While workflows should not change, it is important to ensure the @IsRepriceRequired element is not omitted from @OptionalServices in the AirCreateReservation and AirMerchandisingFulfillment requests because that information is used to ensure accurate pricing returns for the selected option.

    xPath:

    OptionalServices/OptionalService/@IsRepriceRequired

    • AirPriceRsp/AirPriceResult/AirPricingSolution/

    • AirMerchandisingOfferAvailabilityRsp/

    • AirCreateReservationReq/AirPricingSolution/

    • AirCreateReservationRsp/UniversalRecord/AirReservation/

    • AirMerchandisingFulfillmentReq/

    • AirMerchandisingFulfillmentRsp/UniversalRecord/AirReservation/

    Notes:

    • See DA 901 for further details and examples.

    See Errors and Warnings in the Response section for errors and warnings that can be returned for Optional Services.

    Branded Fares

    Branded and Upsell Fares can be added as part of a booking. See Rich Content and Branding in Air Bookings for details.

    Manual fares

    Manual fares can be added by during the creation of the booking for active segments by setting the PricingMethod attribute of AirPricingInfo to 'ManualFare'.

    AirPricingSolution/AirPricingInfo/AirPricingModifiers/ManualFareAdjustment can be used to provide increments or discounts to a fare using a percentage or amount.

    The Galileo (1G) and Apollo (1V) providers have functionality that allows increases or decreases to be applied to a fare quote when the appropriate parameters are set in Air Shop/Price/Book requests. The fare can be increased or decreased either by percentage or flat amount. The user can increase or decrease either the base amount or total.

    Note: Worldspan (1P) refer to manual fare adjustment as custom discount pricing.

    See Manual Fare Adjustments for details.

    Override fares

    If none of the system-generated fares from Universal API are acceptable, Fare Basis Codes can be used to create a specific fare to price, which overrides Universal API's fare responses.

    The total price can also be adjusted by a flat amount or a percent. The adjustment can be applied at both the PTC level and the per passenger level. See Air Booking with Price Adjustments for details.

    Fare types

    Both Public and Private (negotiated) Fares are available. Use AirPricingSolution/AirPricingInfo/AirPricingModifiers @FaresIndicator to either restrict the type of fare to book or allow flexibility in choosing other fare types.

    You can also specify contract or account codes to return private fares and redistribute private fares if needed. Refer to Air Booking with? Fare Type for more information.

    Loyalty cards

    Use /BookingTraveler/LoyaltyCard to accrue points/miles. For more information, refer to Air Booking with Loyalty Program.

    A single Loyalty Card can be used to accrue points/miles on different carriers (cross-accrual). Up to 10 carriers can be sent in a single LoyaltyCard element in requests to the Galileo (1G) provider.

    Notes:

    • Universal API does not validate the carrier codes against the provider membership mileage table.
    • Universal API does not currently support cross-accrual for multiple airlines on Apollo (1V), or Worldspan (1P) because those providers validate cross-accrual carriers and do not support user entry of cross-accrual carriers.
    • A PNR is not created if the cross-accrual carrier provided does not have a mileage membership agreement with the Loyalty Card carrier. An error is returned: NO CROSS ACCRUAL AGREEMENT EXISTS.
    Multiple AirPricingInfo elements

    If more than one AirPricingInfo element is sent in a book request, then all AirPricingInfo children associated to an AirPricingInfoGroup must be provided in AirTicketingReq/AirTicketingModifiers.

    • If there are more than one AirPricingInfo element in an AirPricingInfoGroup element, and only partial data is added to the AirPricingInfo of that AirPricingInfoGroup, the error message, "All AirPricingInfos associated to an AirPricingInfoGroup should be provided in the request" returns in the response.
    • For example, in an Air Create Reservation request, there are two AirPricingInfoGroup elements. Each AirPricingInfoGroup is associated with two AirPricingInfo elements:
      • There must be two AirTicketingModifiers elements. Each AirTicketingModifiers element has two AirPricingInfoRef elements
      • A common mistake in the AirTicketing request is to have four AirTicketingModifiers for each AirPricingInfo element. This is incorrect.

    The following sample shows a correct request:

    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

    <soap:Body>

    <ns2:AirTicketingReq ReturnInfoOnFail="true" BulkTicket="true" TargetBranch="P#######" xmlns:ns9="http://www.travelport.com/schema/universal_v41_0" xmlns:ns8="http://www.travelport.com/schema/cruise_v41_0" xmlns:ns7="http://www.travelport.com/schema/rail_v41_0" xmlns:ns6="http://www.travelport.com/schema/gdsQueue_v41_0" xmlns:ns5="http://www.travelport.com/schema/hotel_v41_0" xmlns:ns4="http://www.travelport.com/schema/passive_v41_0" xmlns:ns3="http://www.travelport.com/schema/vehicle_v41_0" xmlns:ns2="http://www.travelport.com/schema/air_v41_0" xmlns="http://www.travelport.com/schema/common_v41_0">

    <BillingPointOfSaleInfo OriginApplication="UAPI"/>

    <ns2:AirReservationLocatorCode>UAXL4S</ns2:AirReservationLocatorCode>

    <ns2:AirPricingInfoRef Key="W/O1TA7Q2BKAup/jAAAAAA=="/>

    <ns2:AirPricingInfoRef Key="W/O1TA7Q2BKAxp/jAAAAAA=="/>

    <ns2:AirPricingInfoRef Key="xfUMn/4R2BKAL7aKDAAAAA=="/>

    <ns2:AirPricingInfoRef Key="xfUMn/4R2BKA27aKDAAAAA=="/>

    <ns2:AirTicketingModifiers>

    <ns2:DocumentModifiers GenerateItineraryInvoice="true" GenerateAccountingInterface="true"/>

    <ns2:AirPricingInfoRef Key="W/O1TA7Q2BKAup/jAAAAAA=="/>

    <ns2:AirPricingInfoRef Key="W/O1TA7Q2BKAxp/jAAAAAA=="/>

    <ns2:TourCode Value="."/>

    <Commission Level="Fare" Type="PercentBase" Percentage="0.0"/>

    </ns2:AirTicketingModifiers>

    <ns2:AirTicketingModifiers>

    <ns2:DocumentModifiers GenerateItineraryInvoice="true" GenerateAccountingInterface="true"/>

    <ns2:AirPricingInfoRef Key="xfUMn/4R2BKAL7aKDAAAAA=="/>

    <ns2:AirPricingInfoRef Key="xfUMn/4R2BKA27aKDAAAAA=="/>

    <ns2:TourCode Value="."/>

    <Commission Level="Fare" Type="PercentBase" Percentage="0.0"/>

    </ns2:AirTicketingModifiers>

    </ns2:AirTicketingReq>

    </soap:Body>

    </soap:Envelope>

    Restrict wait-listed segments

    Client applications have the option to restrict the creation or update of PNRs for air bookings that contain wait-listed segments in the booking or modify request.

    Passive segments

    To add a passive segment, set AirPricingSolution/AirSegment @Passive="true". Add the supplier's code and record locator in AirCreateReservationReq/SupplierLocator.

    Passive segments are booked outside of Universal API.

    Manual fares can be added to a passive segment after it is booked.

    Passive segments (particularly Air, Car, Hotel and Surface) are included for Continuity Check within the Universal Record. A Continuity Error is returned if the Passive Segments that are sold have discontinuity with each other or existing segments and the ContinuityCheckOverrideRemark attribute is not sent in the Universal API request. Air Passive Segments are considered at par with active air segments, Hotel Passives with active hotel, and so on for the continuity validation. ARNK segments are added for Air Passives and are similar to active air segments. If the override remark is added, any continuity breaks are returned as warnings.

    @TravelOrder in PassiveReservation/PassiveSegment is returned to indicate the position of each Passive Segment within the UniversalRecord.

    All passive Segment types are ordered within the itinerary by Start Date and then End Date, when applicable. Primarily, End Date is considered for Air and Rail segments. For others, currently, only the Start Date is considered. If the dates match, a priority is used at the UR level for sorting the segments.

    • PRIORITY_AIR = 0; // highest
    • PRIORITY_RAIL = 1;
    • PRIORITY_ARNK = 2;
    • PRIORITY_VEHICLE = 3;
    • PRIORITY_HOTEL = 4;
    • PRIORITY_PASSIVE = 5;

    The priority of passives segments is the same as the active counterparts. Within the same date, the passive segments of other segment types, such as Tour or Limousine, do not have a specific priority order hierarchy and can be placed in no particular order after considering the Date criteria.

    Passive Remarks cannot be added with an air segment request, therefore, any Passive Remarks are converted to General Remarks.

    Override minimum connection time

    Universal API stops processing the reservation when the minimum connection time is not met and an error is returned. You can resend the request with AirCreateReservationReq @OverrideMCT="true" for Galileo or Apollo.

    When an Air itinerary does not meet the minimum connection time (MCT) for air segments, Universal API stops after the first End Transaction that does not meet the minimum connection time and returns an error in the Air Booking response. Keys are returned for the segments that contain an MCT error. If a user receives this error, the booking request can be resent with an OverrideMCT attribute so that the booking can be successful.

    If the error is overridden with the OverrideMCT attribute, Universal API ignores the air booking response from the first End Transaction and proceeds with the Air Booking request.

    Universal API maps AirSegment @Key with the segments that are returned in the MCT error CHECK MINIMUM CONNECT TIME SEGMENTS xx/yy when OverrideMCT=false or the attribute is not included in the request:

    • If all segments in the MCT error have corresponding AirSegment @Key values, either from the Universal API database or included in the request, Universal API maps the keys and updates the MCT error to include the AirSegment @Key values.

    • If any new segment in the MCT error does not have a corresponding AirSegment @Key in the request, Universal API returns the MCT error received from the provider.

    • If the format of the message changes from CHECK MINIMUM CONNECT TIME SEGMENTS xx/yy, Universal API returns the error message received from the provider.

    Some reservation-level tagging must be processed by Universal Desktop. For example, in the case of multiple reservation requests, Universal API may not be able to determine the reservation for which the MCT applies. For client applications other than Travelport Universal Desktop, set OverrideMCT="true" to ensure MCT errors are not returned. Note that MCT warnings may still be returned as they are currently.

    Special Service Requests for Merchandising Optional Services

    If applicable, a Special Service Request (SSR) is created for each Optional Service that is sent in the Air Merchandising Fulfillment request or Air Booking request. This SSR is created in addition to the ASVC SSR.

    • The enhancement to Air Booking applies to Galileo (1G) and Apollo (1V). SSRs for optional services are currently not created in Worldspan (1P).

    • The enhancement to Air Merchandising Fulfillment applies to Galileo, Apollo, and Worldspan.

    SSR and ASVC SSR details

    An airline can file an Optional Service with ATPCO as an ASVC-only SSR service or as a dual-SSR service.

    When the airline files the Optional Service with the SSR code ASVC, it is considered an ASVC-only SSR service. The ASVC SSR is created for each optional service sent in the Air Merchandising Fulfillment request (AirMerchandisingFulfillmentReq) and Air Booking request (AirCreateReservationReq).

    Note: The ASVC SSR is not created for Air Bookings on Worldspan.

    When the airline files the optional service with an SSR code that is not ASVC, it is considered a dual-SSR service. The SSR code can be:

    • A standard, industry-defined SSR code, for example XBAG.
    • A non-standard, airline-defined SSR code, for example BAGA.

    Two SSRs are created for each optional service sent in the Air Merchandising Fulfillment request and the Air Booking request: one for the SSR code filed by the airline and one for the ASVC SSR. For example, carrier XX files a bag Optional Service with SSR Code “XBAG”. Dual SSRs are created: XBAG SSR and ASVC SSR.

    Note: Dual SSRs are not created for Air Bookings on Worldspan.

    Some SSRs require free text that must be sent in the request in OptionalService @SSRFreeText. If the free text is not sent, an error is returned:

    Free text is required for this type of SSR [SSR code].

    Some SSRs do not allow free text. If the free text is sent for an SSR that does not allow free text, an error is returned:

    Free text is not required for this type of SSR [SSR code].

    The SSR and the ASVC SSR are saved in the Universal Record (UR).

    Note: If the provider does not support the SSR sent in the request, the error sent by the provider system is returned in the Universal API response and the user must remove the Optional Service and delete the SSR before resending.

    Book on Book

    Book on Book for an Air Create Reservation request is allowed with host Provider Locator Code and Universal Record Locator Code if the Provider Locator Code does not have any active/passive air content.

    Air, hotel, vehicle, and passive Book on Book is allowed to append itinerary content in the same provider PNR if the PNR's owning PCC has a host bridge branch relationship with the Override PCC or PCC of the Target Branch in the request. The emulating PCC and owning PCC must have host bridge branch relationship so that the PNR can be retrieved and can be modified in the host.

    Language code

    @LanguageCode is available for ACH only. It defines the language that the carrier uses in the confirmation email.

    Define the language using a string in ISO-639 format. For example, "en" or "en-GB". See ISO-639 Standards for details.

    Note: Only ACH supports this parameter.

    ACH ignores @LanguageCode in the request if:

    • It contains an invalid value.
    • It is sent to a carrier that does not support language specification.

    ACH returns the following warning if the language is valid and sent to a carrier that supports the attribute but does not support the specified language:

    <Warning Type="722">Invalid Documentation Language code. Defaulting to English.</Warning>

    Retain reservation

    Use AirCreateReservationReq @RetainReservation to define whether a PNR is created if the values sent in the request differ from the values in the stored schedule and price.

    Changes in price and schedule can occur for many reasons (e.g., a Fare Class may not be available at the time of booking, or a private fare may be returned that is not referenced in the request). If there are differences between the request and the stored values, the AirSolutionChangedInfo element in the response is returned and provides a value to explain what has changed. A warning is also returned: Segment sync error. Flight times returned from the carrier do not match the flight times requested.

    The logic for RetainReservation, customers can choose to have pricing or segment sell failures result in the booking being discarded, no matter the value of RetainReservation sent in the request. To discard bookings with pricing or segment sell failures, please contact your Travelport representative for more information.

    Optional provisioning discards bookings if a pricing or segment sell failure occurs

     

    If you are not provisioned with the logic described above, then the following table shows the RetainReservation value, which value has changed (schedule, price, or both), whether a UR/PNR is created if the value has changed, and whether the original or new value is returned in AirSolutionChangedInfo.

    RetainReservation equals Changed Value UR/PNR Created? AirSolutionChangedInfo returns...
      None Schedule No New time.
    Price No New price.
    Both No New time and price.
      Price Schedule No New time.
    Price Yes Original price.
    Both No New time and price.
      Schedule Schedule Yes Original time.
    Price No New price.
    Both No New time and price.
      Both Schedule Yes Original time.
    Price Yes Original price.
    Both Yes Original time and price.

    If RetainReservation is set to Price, Schedule, or Both, and there IS NO price or schedule change:

    • The AirSolutionChangedInfo element is not returned.
    • A PNR is generated with the segments that are successfully sold.

    Pricing type

    Identify the pricing type using AirPricingSolution/AirPricingInfo @PricingType.

    Galileo (1G) and Apollo (1V)

    Galileo and Apollo support pricing types of TicketRecord and StoredFareQuote in Universal v29.0 and greater.

    Worldspan (1P)

    Worldspan fares can be stored in a PNR using Auto-Pricing (4P*), Ticket Record (4P*|TR), Stored Fare Quote (4PQ), and Pricing Instructions (4-PI).

    Note: Pricing types of TicketRecord and PricingInstruction are not allowed in the same PNR.

    Universal API is not currently able to ticket PNRs that contain only Auto-Pricing fares. As a result, Universal API identifies the type of pricing in the PNR as either Ticket Record or Stored Fare.In Universal v32.0 and earlier, if a fare was stored as Auto-Pricing, all responses returned the fare type as Ticket Record (PricingType="TicketRecord").

    In Universal v33.0 and greater, the response returns the fare type as either "TicketRecord" or "StoredFare", based on the fare type.

    Auto-Pricing fares are returned as PricingType="StoredFare" if there is only one Auto-Pricing fare present in the PNR. Because Worldspan override the existing Stored Fare if another Stored Fare is added to the PNR, multiple fares must be returned as Ticket Records if they are in different pricing groups.

    For requests with multiple fares:

    • PricingType="TicketRecord" is returned if the AirPricingInfoGroup value is different for each instance of PricingInfo.
    • PricingType="Stored Fare" is returned if the AirPricingInfoGroup value is the same for each instance of PricingInfo. Universal API adds one fare to the PNR, which combines all the AirPricingInfo values.

    Price open segments

    Open segments are air segments that do not specify a flight number. To book open segments, send /AirPicingSolution/AirSegment @OpenSegment="true".

    Open segments are air segments that do not specify the flight number. Open segments may or may not include the travel date, and are typically used to secure a fare even though the traveler is not certain of one or more travel dates. Open segments can be booked, modified, and ticketed the same way as regular air segments. Prior to travel, they are exchanged for a ticket with complete flight details.

    The following attributes and values are supported for Open Segments in AirSegment:

    • @OpenSegment="true" (required)

    • @DepartureTime (optional)

      If @DepartureTime is included, it should only include the date and not the time. The time value in @DepartureTime is returned as "T00:00:00.000" in the response.

    • @ArrivalTime (optional)

      If @ArrivalTime is included, it should only include the date and not the time. The time value in @ArrivalTime is returned as “0:00:00” in the response.

    • @FlightTime (optional)

    • @TravelTime (optional)

    • @ClassOfService (optional)

    Regardless of the status that is included in the request to Universal API, open segments are passed to providers as follows:

    • Galileo and Apollo providers are sent Status="NO".
    • Worldspan provider is sent Status="PS".

    Error and Warning Responses

    An error response is returned if:

    • A request with OpenSegment set to "true" includes a FlightNumber value. @FlightNumber is not supported in the request and is not returned in the response.
    • A request is sent without a FlightNumber value and OpenSegment is not set to "true".

    Attributes

    For Air Booking responses (AirCreateReservationRsp), a warning response is returned to indicate that DepartureTime and ArrivalTime data is not included in the response: Time is ignored for open segments.

    Price variance

    With Universal.xsd v46, price is checked during the reservation request. You can specify a price tolerance at time of book, which reduces booking failures.

    AirCreateReservationReq @CheckPriceVarianceType and @CheckPriceVarianceValue supports price checking logic at the confirmation step of Air Create Reservation request. This feature allows for a reduction in book failures by allowing customers to identify a price tolerance at time of book.

    • Price Check is required in the Air Create Reservation request with the Check Price Variance attributes.
    • Specify the type of variance using @CheckPriceVarianceType set to Amount or Percentage.
    • Specify the variance value using @CheckPriceVarianceValue.
    • For example, the parameter could be set so that if the cost of the ticket is within 5%, it allows the booking to take place (example code: <AirCreateReservationReq CheckPriceVarianceType="Percentage" CheckPriceVarianceValue="5"...>.
    • @CheckPriceVarianceType and @CheckPriceVarianceValue were added in Universal v46.

    Review bookings

    Review Bookings (Q-Minders) are a provider functionality that issues reminders to agents for any pending tasks that must be done by a specific date and time. The PNR and the reminders are put into the agency queue on the date and time specified in Review Booking.

    Agent ID override

    AirCreateReservationReq/AgencyIDOverride is used to specify another agent ID for the reservation.

    AgentIDOverride in the request overrides any default agent sine placed in the PNR. This is a two-character alphanumeric code of the agent sine that should replace the default. The AgentOverride attribute is returned in the response, noted below in ProviderReservationInfo. The agent sine cannot be updated after the PNR has been finalized.

    Emulate

    To emulate another PCC or SID, use AirCreateReservationReq/OverridePCC.

    Note: Refer to Emulation for more information.

    The OverridePCC is used to specify the emulated PCC in Common.xsd. When the Override PCC is sent in a booking request:

    • The OwningPCC attribute in ProviderReservationInfo is set to the emulated PCC (the OverridePCC).
    • For Worldspan , the Override PCC is used to set the PCC in the first phone field of the provider PNR, therefore making the OverridePCC the Owning PCC of the PNR.
    • For Galileo and Apollo, Service Bureau set up is required for emulation with Override PCC.

    If OverridePCC is NOT sent in the booking request, the OwningPCC attribute in ProviderReservationInfo is set to the Target Branch.

    Search Control Console

    @ChannelID and @NSCC are only used by Search Control Console users.

    For customers using the Search Control Console (SCC) or Content Optimizer - Air (COA), attributes were added to AirCreateReservationReq in release 17.1 for Galileo (1G) and Apollo (1V) as follows:

    SCC and COA is used by agency administrators to create business rules for filtering certain air shopping results. Two optional attributes allow SCC / COA users to either activate or override these filters:

    • ChannelID, which activates an SCC / COA filter for a portion of travelers served by the agency PCC, such as a specific corporation or group.
    • NSCC, which is used to bypass or override a specific SCC / COA rule.

    These attributes were added to AirFareDisplayReq and to the AirPricingModifiers element in LowFareSearchReq, LowFareSearchAsynchReq, and AirPriceReq for Galileo (1G), Apollo (1V), and Worldspan (1P). They were also added to AirCreateReservationReq and AvailabilitySearchReq in release 17.1 for 1G and 1V.

    Only one attribute can be used in a single request, either ChannelID or NSCC. If both are used together, or if an SCC / COA rule is violated, Universal API does not send the transaction response and returns an error.

    Note the following:

    • ChannelID: Four-character alphanumeric string. Values should be uppercase for 1G and 1V; lowercase values for 1P (if supported for that transaction) may or may not be processed so uppercase is recommended. If an invalid user ID and a valid attribute value are sent, the message AGENT NOT AUTHORISED is returned. In the case of an invalid ID format, the following messages are returned:
      • 1G: INVALID MODIFIER
      • 1V: INVALID INPUT
      • 1P: The attribute is ignored and a successful response is returned.
    • NSCC: Valid values for the rule type identifer number to be sent are 000 to 999. If an invalid user ID and a valid attribute value are sent, the message AGENT NOT AUTHORISED is returned. In the case of an invalid ID format, the following messages are returned:
      • 1G: INVALID MODIFIER
      • 1V: INVALID INPUT
      • 1P: ERR10 INVALID

      Note: If your client application does not use SCC or COA, do not use these attributes. Please contact your Travelport representative if you would like additional information.

      SCC and COA is not applicable to Airline Content Hub (ACH).

  5. If the booking was successful, AirCreateReservationRsp returns Universal Record and the new air PNR data. If the air segment is the first segment booked for the trip, a new Universal Record is created. If the air segment was added to an existing Universal Record, a new air PNR within that record is created.

    ARNK (Arrival Unknown) segments are added to the host PNR automatically wherever required, particularly for continuity breaks with the provider PNR. ARNK (Arrival Unknown) segments that are present in Galileo and Apollo provider PNRs are included in the response in the UniversalRecord/ProviderARNKSegment, to allow agents to view the exact provider PNR composition.

    /ProviderReservationDetails @CustomCheck

    @CustomCheck is set to "true" if a PNR has a Custom Check attached in the Galileo or Apollo provider reservation that was imported via Universal API.

    The Custom Check rule name is returned in the detailed display of the Provider Reservation, or if it is not found, a message is returned: Custom Check not found.

    If creation of the background passive fails on the provider (for example, a RuleName is not attached to a PNR or there is non-compliance with an attached RuleName), a Universal Record is created successfully, with a provider locator of ACH or SDK, as appropriate.

    If a Pseudo City Code (PCC) has a mandatory Custom Check rule that was attached during reservation creation, and the attached rule is compliant, a background passive is successfully created on the Galileo or Apollo provider, and the reservation is also successfully created in Universal API.

    @AgentOverride

    If the request included the optional AgentIDOverride attribute, the AgentOverride attribute returns the agent sine used to override the default agent sine.

    If a Traveler name is more than 55 characters, the secure flight SSR is displayed at the Universal Record level and not at the Booking Traveler level. This means that when SSR @ProfileID and @ProfileSecureFlightDocKey are sent in the request, they are returned in the response at either:

    • The Booking Traveler level: 
    • AirCreateReservationRsp/UniversalRecord/BookingTraveler/SSR @ProfileSecureFlightDocKey
    • AirCreateReservationRsp/UniversalRecord/BookingTraveler/SSR @ProfileID
    • The Universal Record level:
    • AirCreateReservationRsp/UniversalRecord/SSR @ProfileSecureFlightDocKey
    • AirCreateReservationRsp/UniversalRecord/SSR @ProfileID

    After SSRs are added successfully with the Traveler ProfileID and ProfileSecureFlightDocKey and the UR is finalized, the UR displays the ProfileID and ProfileSecureFlightDocKey that is associated to SSR DOCS/DOCO/DOCA.

    • If ProfileID and ProfileSecureFlightDocKey are present in SSRs other than DOCO/DOCA/DOCS, Universal API returns an error: "Profile ID and ProfileSecureFlightDocKey only valid for SSR DOCA/DOCO/DOCS".
    • Universal API validates the Traveler Profile ID (BookingTraveler/AppliedProfile/@TravelerID) against the Universal Record and the Air Booking request that is being sent. If there is no match, an error is returned: "Profile ID specified in SSR is not present in Booking traveler(s) in request or Universal Record".
    • Both ProfileID and ProfileSecureFlightDocKey must be sent in the request or an error is returned: "Profile ID or ProfileSecureFlightDocKey must be accompanied with each other for Secure Flight SSRs".

  6. Within the Universal Record, AirReservation contains the booking data. Booking Data is encapsulated in multiple elements.

    Air reservation information Description
    Air segments

    UniversalRecord/AirReservation/AirSegment contains the itinerary data for each corresponding segment in the itinerary.

    Sell Messages from suppliers are also included in AirSegment (e.g., a supplier may return free text, important information for the traveler, such as a number to call if they need to make changes to their reservation).

    Note: Sell Messages are tied to segment/reservation and if the segment/reservation is deleted then corresponding messages will also be deleted.

    For each Carrier-Specific Display (CSD) response, the AirSegment element returns a Reference Sell Token; therefore if multiple legs are requested, multiple tokens are returned. There can be two connecting segments on the same carrier from the same host CSD. The token remains active on the provider's system for three minutes, but the actual time can be less than three minutes, due to API processing time.

    Air pricing

    UniversalRecord/AirReservation/AirPricingInfo contains the total fare for all segments. Fares for each segment are returned in one or more AirPricingInfo/FareInfo elements.

    AirPricingInfo may also contain Fare Guarantee information to help identify the source of the quoted fare. See Fare Guarantees for details.

    @ApproximateTaxes

    The Approximate Taxes attribute returns approximate values in a booking retrieve response so that customer system calculations. which are dependent on the approximate values, don't fail when a booking is retrieved. Release 23.4

    This is limited release functionality. Please contact your Travelport representative to activate this enhancement.

    /FareInfo

    Fares for each segment are returned in one or more FareInfo children. The number of FareInfo elements returned may vary depending on the number of distinct fares returned in the response. For example, sending multiple passenger types in the request returns corresponding FareInfo elements for each passenger type.

    • AirPricingInfo/FareInfo @PrivateFare displays private fares as “Airline private fare” or “Agency private fare” for the Galileo and Apollo providers. Worldspan and Airline Content Hub display all private fares as "Private Fare".

    • AirPricingInfo/FareInfo/FareRuleKey is contained within each FareInfo element and holds a reference for requesting fare rules in a subsequent transaction.

    • AirPricingInfo @LatestTicketingTime stores the ticketing deadline for Air reservations that are created with a fare. LatestTicketingTime is based on the rules of the fare. Release 19.1

      Previously, Universal API defaulted the last time as 23:59. Even when a ticketing restriction is expressed in hours ("ticket must be within 24 hours of booking"), agents had until midnight of the 'last day to ticket' to issue the ticket. With Universal API 19.1.2, , Universal API complies with advance purchase ("Category 5") rules that are expressed in hours or minutes. For example, a booking made and priced at 9:25 on November 1st must be ticketed by 9:25 on November 2nd. After that time, it will not be possible to issue a ticket for that fare on that booking. For example:

      Previous Behavior:

      • Previously Universal API returned the hours/minutes/Timezone in the session booking response with default value 23:59.
      • Previous Display format : LatestTicketingTime="2018-05-17T23:59:00.000+01:00"

      New Behavior:

      • Correct Hours and Minutes in the response.
      • New Display format: LatestTicketingTime="2018-07-13T10:30:00.000+01:00"

      LatestTicketingTime is updated when any pricing modification is performed, such as adding a pricing information to a reservation created without price or changing pricing information.

    • AirPricingInfo @TrueLastDateToTicket is the last date a fare can be ticketed.

      True Last Date to Ticket is the last available date that a fare can be ticketed, as indicated in the fare rules for a specific fare. This date is merely the last date to purchase a ticket based on the carrier’s fare rules at the time the itinerary was quoted and stored. The TrueLastDateToTicket attribute is returned in AirPricingInfo in the applicable service responses when available.

      Note: Only Galileo supports TrueLastDateToTicket. No other providers support the attribute.

      TrueLastDateToTicket is returned from Galileo with a date. Universal API attaches a time:

      Previous Behavior:

      • Previously Universal API returned the hours/minutes/Timezone in the session booking response with default value 23:59.
      • Previous Display format : AirPricingInfo TrueLastDateToTicket=”2018-05-17T23:59:00.000+01:00"

      New Behavior:

      • Correct Hours and Minutes in the response.
      • New Display format: AirPricingInfo TrueLastDateToTicket=”2018-07-13T10:30:00.000+01:00"

      True Last Date to Ticket is not associated to Latest Ticketing Time, which is the last date that the fare can be ticketed at the quoted price. After the Latest Ticketing Time, a quoted fare must be re-priced for ticketing if there is no agreement between the travel provider and airline to extend the quoted fare to the Last True Date to Ticket. It should also be noted that TAU/TAW dates put in the ticketing arrangement for a PNR do not relate directly to the last date to purchase because a PNR can be created without a stored fare.

      In some cases, the True Last Date to Ticket will have the same date as the Latest Ticketing Time. However, for some ticketing locations, these two dates may differ. When the dates differ, Latest Ticketing Time is typically earlier than True Last Date to Ticket for a stored fare. However, for both of these dates, there is no guarantee that the fare will still be available on that date or that the fare amount will not change.

      Note: Both AirPricingInfo @TrueLastDateToTicket and AirPricingInfo @LatestTicketingTime values can co-exist, most often for European ticketing locations.

      AirPricingInfo @TrueLastDateToTicket data is recorded in the Universal Record History (UniversalRecordHistorySearchRsp).

    • For some suppliers that require payment at the time of booking, the supplier may return an initial 'Payment Pending' response if the credit card FOP has been declined or not yet confirmed. Universal API continues to poll the API multiple times until the supplier returns the messages 'Payment Confirmed' or 'Payment Declined', or polling stops due to a time out.

    • The Agency Private Fare modifiers for account code and contract rule ID are returned in UniversalRecord/AirReservation/AirPricingInfo/FareInfo in Air v29.0 and greater.

    • Air.xsd v53 and greater expands on the existing Routehappy flight amenity content returned in the AirCreateReservation and UniversalRecordRetrieve transactions by extending the data to each leg of a direct flight. U

      • Note: This is limited release functionality. Contact your Travelport representative for further information.

      • xPath: AirPricingInfo/BookingInfo/

        • AmenitiesRef

        • @IncidentalStops

    Optional services

    Information (including costs) about optional services is returned in UniversalRecord/AirReservation/OptionalServices (added in Air v29.0 and later).

    Suppliers can file Optional Services with base price, tax, and total price. The taxes are saved with the Universal Record and displayed in the response. The response displays:

    • The total taxes for the optional service in OptionalService @Taxes.
    • The individual tax amount for the optional service in OptionalService/TaxInfo @Amount.
    • The category code for the optional service in OptionalService/TaxInfo @Category.

      • Note: UniversalRecordHistory does not currently capture taxes. This functionality will be added in the future.

    Certain rules and restrictions are associated with Optional Services filed through ATPCO. OptionalService returns additional details that can be sent in Air Booking and Air Merchandising Fulfillment requests; these details are also saved to the Universal Record and Universal Record History.

    Note: These details are not provided for ACH responses, as ACH carriers do not file their Optional Services through ATPCO.

    ATPCO-filed OptionalServices are saved with an "Offered" status. The ServiceStatus is updated when the airline confirms the sale of the Optional Service and the Universal Record is retrieved or synchronized.

    AirCreateReservationRsp contains the following additional details:

    • OptionalService attributes: InclusiveOfTax, InterlineSettlementAllowed, GeographySpecification, ExcessWeightRate
    • TourCode element
    • OptionalService/EMD attributes added: FulfillmentTypeDescription and Reusable

    In Universal v29.0 and later, if both ATPCO-filed and ACH LCC Optional Services are returned in the response, Universal API returns OptionalServices/OptionalServicesTotal.

    For Low Cost Carriers on ACH:

    • Universal API returns one OptionalService element for one booking traveler that may contain a Quantity greater than "1".
    • When an AirCreateReservationReq that includes OptionalService/ @Quantity greater than “1” is sent to the ACH provider for a Low Cost Carrier (LCC), the Quantity returned is the total number of Optional Services requested, which may reference multiple air segments but always one booking traveler.

      • The TotalPrice of the OptionalService is returned in TotalPrice in AirCreateReservationRsp/UniversalRecord/AirReservation/OptionalService.

    • The Service Status is saved as “Fulfilled” when the LCC issues the EMD for the Optional Service.

    Note: These enhancements are only supported by Airline Content Hub for Low Cost Carriers. For all other providers only @Quantity="1" is supported.  

    In Universal v29.0 and later:

    • Universal API returns the total for the Optional Services, including taxes.
    • For ATPCO-filed Optional Services, the total of all Optional Services is added by Universal API and returned in OptionalServicesTotal.
    • When ACH LCC and API carrier Optional Services are returned from multiple carriers and the currency codes are the same, Universal API returns BasePrice, Taxes, Fees, and TotalPrice in OptionalServices/OptionalServicesTotal.
    • When ACH LCC and API carrier Optional Services are returned from multiple carriers and the currency codes are the different, Universal API does not return BasePrice, Taxes, or TotalPrice in OptionalServices/OptionalServicesTotal. Instead, the ApproximateTotalPrice and ApproximateBasePrice are returned in OptionalServicesTotal based on the default currency code of the TargetBranch (WAB).
    • If Optional Services are returned from multiple providers in the response, Universal API returns OptionalServices/OptionalServicesTotal with the combined price.
    • If Optional Services are returned from multiple providers in the response and the currency codes are different, the ApproximateTotalPrice and ApproximateBasePrice are returned in OptionalServicesTotal based on the default currency code of the TargetBranch (WAB).

    Provider reservation reference keys

    UniversalRecord/AirReservation/ProviderReservationInfoRef provides a cross-reference for the air segment between the Universal Record (UR) and the provider PNR when all segments are canceled, which lets you delete segments and remove the Universal Record. Fully canceled/deleted air segments can then be retrieved within the UR, and the provider age-out guidelines for archiving the PNR data are supported.
    Connection indicators and group numbering

    The AirSegment @Group and Connection @SegmentIndex attributes return connection indicators and group numbering in the book response so that the data is present in post-book workflows. E.g.,

    <air:Connection/> </air:AirSegment><air:AirSegment Key="9Y1ynsxrGD...==" Group="2" Carrier="LH" FlightNumber="630" ...>

    This is limited release functionality. Please contact your Travelport representative to activate this enhancement.

  7. The response also contains information about schedule changes or failures.

    Response information Description

    Schedule change

    If a schedule change occurred, the AirSolutionChangedInfo element is returned.

    The AirSolutionChangedInfo element is returned if there is a change in schedule between the booking request and the stored fare and schedule. It contains a reason code that shows what is different (e.g., <AirSolutionChangedInfo ReasonCode="Price">) and may contain a value that displays the difference.

    AirSolutionChangedInfo/AirPricingSolution previously also displayed the Total/Base Price and Taxes as part of the Air Pricing Solution when a price change occurred during an Air booking or modification of the Universal Record. Now, no price attributes are shown in the Air Pricing Solution when the price changes.

    Changes to either the departure time or the arrival time return AirSolutionChangedInfo data.

    For Galileo (1G), Apollo (1V), and Worldspan (1P), the presence of data in AirSolutionChangedInfo can be affected by the value of @RetainReservation in the booking request. ACH does not support @RetainReservation; after a successful booking request, the reservation is always retained, regardless of price or schedule changes.
    Failed air segments

    If any air segments failed to book, the AirSegmentSellFailureInfo element is returned.

    AirSegmentSellFailureInfo indicates the presence of failed Air segments in a partially failed PNR that also contains a least one successfully booked Air segment. If all requested Air segments fail, then only an error is returned because no PNR is created.

    ZP (Segment) and XF (Passenger Facility Charge) taxes are returned in US dollars, in addition to the point-of-sale currency, regardless of the point of sale location for the ticket. ZP and XF taxes apply to itineraries that include travel within the United States.

    If failed Air segment information is returned in AirSegmentSellFailureInfo, advisory text for the failed segment is also returned in /AirSegmentError/AirSegment/ErrorMessage. For example: <ErrorMessage>0 AVBL/WL CLOSED $$UA$$</ErrorMessage> indicates no availability and a closed waitlist for the flight.

    The existing generic warning message continues to be returned in the ResponseMessage element in AirCreateReservationRsp: UNABLE TO BOOK ALTERNATE - SEGMENTS NOT AVAILABLE. A host error message is also returned, which is mapped in AirSegmentSellFailureInfo/AirSegmentError/ErrorMessage for each segment that fails.

    Detailed warnings for partial failures were previously implemented for Galileo (1G) and Apollo (1V) and were implemented for Worldspan (1P).

  8. The response may also contain Brand details for the fares. See Rich Content and Branding in Air Bookings for details.

Errors and Warnings

Exceptions

  • Universal API sends booking request data to Galileo to price an itinerary per passenger. Galileo "stores" the fare quote in the PNR. Universal API then compares the fare quote from the Galileo response with the pricing information from the client. In the Universal API response, the Galileo price/fare quote is sent and the client is notified if price is different from their initial price (AirSolutionChangedInfo).

  • Polling is not required for Galileo.

  • Free-form Remarks allow maximum of 86 characters:

    AccountingRemark/RemarkData Category="FT" TypeInGds="Other" ProviderCode="1G"

    AccountingRemark/RemarkData Category="X*" TypeInGds="Other" ProviderCode="1G"

  • When the first 15 characters of a last name/first name combination match another last name/first name combination in the same PNR, the names are sent to the Galileo host in the booking request as a cluster of names, with an allowed cumulative total of 55 characters for first name, prefix, last name, and suffix.

    For example: A PNR with these two passengers:

  • Salomonowicz/Barbara
  • Salomonowicz/Bartholomew

    • Is clustered because the first 15 characters are the same: Salomonowicz/Ba

  • Galileo does not support MICR number for check form of payment.

  • Universal API does not have a discrete equivalent to an end transact (PNRBFEnd). When a created, modified or canceled booking is submitted, Universal API internally processes the end transact as part of the request. There is also no equivalent functionality to PNRBFIgnore.

Apollo does not support:

  • A pricing method with a value of GuaranteedUsingAirlinePrivateFare to indicate that a guaranteed Agency Private Fare was used with no rules override.
  • VendorRemarks.  
  • Ignore Stopover Indicator for Fare Quote (Connection/@IncludeStopOverToFareQuote).

Apollo supports the following for SSRs entered during booking:

  • Input of DOCO fields during AirCreateReservationReq. However, all DOCO request(s) must be accompanied by an associated DOCS request, or the HOST returns an error.
  • Generation of DOCS fields during the AirCreateReservationRsp.
  • Generation of DOCA fields during the AirCreateReservationRsp.

See Air Booking with SSRs for more details.

Worldspan does not support the following request data:

  • PointOfSale. Any value provided is ignored, and a warning is sent in the response: "Separate PointOfSale not supported by provider".
  • Eticketability
  • Review booking
  • Specifying different forms of payment at the PNR and stored fares levels during an air booking.
  • OverrideMCT
  • RuleName (World File Edits in Worldspan (1P)).
  • Air Fare Rules.
  • Credit card form of payment without the credit card type.
  • MICR number for check form of payment.
  • Vendor Remarks.

Worldspan does not support the following response data:

  • Link Availability
  • Polled Availability Option/Inside Availability
  • Sell Messages for air segments

  • The creation of SSRs for optional services

Worldspan does not support specific tax exemptions. If CountryCode and TaxCategory are sent in the request, a warning is returned in the response that the modifier is not supported.

Worldspan technically allows exempting all taxes. However, if ExemptTaxes/AllTaxes is "True", in reality, only a few type of taxes will be exempted, and tax information is NOT returned for the exempted taxes. Two response messages may be returned:

  • Warning message: Tax Information for Exempted Taxes not available for the provider.
  • Info Message: All Taxes may not be exempted for the provider.

@ReturnFailedSegments in AirCreateReservationReq/AirPricingSolution/AirPricingInfo/AirPricingModifiers ensures that failed segment(s) information returns in the error response, so that suitable replacement(s) can be found for the failed segment(s) (Worldspan [1P] only). Release 18.4

If the FareRuleKey is sent in the request, it is not returned in the response.

For a more complete list of functionality available from various ACH carriers, see ACH Carriers Functionality. Because functionality for carriers may be subject to change, always confirm functionality directly with the ACH carrier before implementation.

Most ACH carriers require Guaranteed Payment at the time of booking. In ACH, booking request data must include a price. When ACH receives the booking request from Universal with the credit card number and payment amount, the request is sent to the supplier. The supplier then books the flight itinerary and debits the credit card. The supplier returns a response to ACH with a booking reference number.

Note: Most ACH carriers send email notifications to the email address used to book the itinerary.

For requests:

  • A HostToken, which is initially returned in the Low Fare Shopping or Air Availability response, is required in the booking request. This token is used as a reference throughout the shopping and booking process.

  • ACH-specific Host tokens are returned in AirAvailInfo/HostTokenRef, not AirSegment/HostTokenRef. Tokens in AirSegment/HostTokenRef are for Carrier-Specific Display.

    Important: ACH has a session timeout limit of 1 hour. However, ACH carriers often have a lower session timeout limit. While API-connected carriers do not publish timeout values, a good rule of thumb is to expect a session timeout limit of 15-20 minutes for an ACH carrier.

  • Currency is included in the host token.

  • Users can Book Air Canada reservations using Cash as a Form of Payment. Only Air Canada supports this enhancement on ACH and agencies must work with Air Canada to be allowed to use a cash FOP. Other carriers may return an error. Also note that optional services cannot be priced or added if a cash FOP is used.

  • Multi-city and open jaw fares are allowed.

  • The following booking modifiers are not supported:

    • Accounting Remarks

    • General Remarks

    • PTC Only

    • Fare Restriction modifiers

    • Eticket modifier

    • Plating carrier

  • Some ACH suppliers (DY) do not support pricing in the booking request, and may complete the booking for an amount other than the amount that was sent in the request.

  • Most Low Cost Carriers via ACH support only adult (ADT), child (CHD or CNN), and infant (INF) passenger types.

    • Some ACH suppliers support only the ADT passenger type and map CHD, CNN, and INF to ADT.

  • Optional Services may be included in the Booking request. If an Optional Service is not available, the transaction may fail or succeed depending on the carrier logic.

    If an Optional Service that references an infant (INF PTC) is sent in a request, it is ignored and a warning is returned: OptionalServices may not be Supported/Required for passenger type INF.

    Note: For Air Pricing for Baggage Optional Services on ACH, and associated sample, see the Air Pricing for Optional Services topic.

  • A country code is required in the request.

  • For the BookingTraveler information, some ACH suppliers may:

    • Require an email address.

    • Require a cell phone number.

    • Require a name prefix.

    • Support a limited number of prefixes.

    • Note: Prior to Universal v33.0, Universal API validated the name prefix in the Air Booking Request before being sent to ACH for ACH carriers. Universal API validated the prefix that the client input, and if it was not on the standard name prefix list, “MR” was sent to ACH. For example, "DR" or "PROF" was changed to "MR" in the response. With Universal v33.0, removes name prefix processing for ACH carriers and allows ACH to process the carrier name prefixes and requirements.

  • RetainReservation is not supported by ACH. After a successful booking request, the reservation is always be retained, regardless of price or schedule changes.

  • Every FormOfPayment is associated with an AirPricingInfo element. For aggregated scenarios in ACH, Galileo (1G), and Apollo (1V), the first AirPricingInfo element that has ProviderReservationLevel=true in FormOfPayment\ProviderReservationInfoRef is applied to the PNR.

  • For an aggregated booking request, any GDS provider segments are attempted before the ACH segments.

  • Review Booking is not supported.

  • The creation of SSRs for optional services is not supported.

  • RuleName is not supported.

  • Credit card form of payment without the credit card type is not supported.

  • eNett Virtual Account Number (VAN) is supported as a form of payment.

eNett International provides integrated payment solutions to meet the needs of the travel industry. eNett eliminates the risk of misuse by issuing a single- or multi-use Virtual Account Number (VAN) for a specific transaction or set of transactions. Enett VAN functionality applies only to ACH and is not supported for other providers.

The @Type="Enett" FormOfPayment is available for Air Booking only and is not available for Air Exchange or Air Refund.

When FormOfPayment @Type="Enett", Universal API requests a multi-use VAN from eNett International and submits the VAN in the Air Booking request as a MasterCard credit card. If a value is submitted in @MaxPercentage when the FormOfPayment @Type="Enett", a VAN is requested with the Amount equal to MaxAuthAmount.

The Enett element is returned in the Air Booking Response to indicate the Enett form of payment. Because FormOfPayment/EnettVan @Maxpercentage is not used for multi-use VANs, a warning message is returned if @MaxPercentage is submitted: “MaxPercentage has not been considered while issuing a multiuse VAN”

Note: ACH carriers support only specific test cards in their respective test systems. eNett International generates random VANs that may not pass through the complete booking cycle.

eNett VANs support was added for multiple Stored Fares, which can include Stored Fares from more than one carrier.

eNett VANs can be issued:

  • As a single VAN for multiple Stored Fares, which uses one instance of the Enett Form of Payment. (AirPricinggSolution/TotalPrice)
  • As a single VAN to support multiple Stored Fares with multiple corresponding Enett Forms of Payment. (AirPricinggSolution/TotalPrice)
  • In combination with a Credit Card for multiple Forms of Payment. (AirPricinginfo/TotalPrice)

If the booking includes multiple fares for a single carrier or different carriers, the corresponding ProviderReservationInfoRef value is saved for the respective Form of Payment.

If a fare does not have a payment reference, then the fare is associated to the first Form of Payment. The Payment reference is mandatory in the request to identify which FormOfPayment values are associated with each Stored Fare, so that the VAN can be issued for a specific amount.

If a segment fails to book, the corresponding Enett VAN is canceled. If SolutionChangedInfo is returned in Air Booking response, the VAN is adjusted and a warning message is returned. If a booking with two or more carriers fails in the first segment, then all subsequent segments are canceled and a Universal Record is not created.

For responses:

  • For sessioned ACH carriers, a Booking failure may require the user to begin the Shopping and Pricing sequence again.

  • The Travelport Universal Record is synchronized with the carrier's updated booking record. Any additional or modified phone numbers retained by the carrier are updated in the Universal Record and are returned in /UniversalRecord/BookingTraveler/PhoneNumber element. In some cases, there may be a time lag in the response from the air carrier. If the updated phone information is not returned immediately in the Air Booking response, a subsequent Travelport Universal Record Retrieve transaction is required to retrieve the updated Universal Record data.

  • Form of Payment

    • If a Form of Payment (FOP) is included in the request, the payment is made at the time of booking.

    • If a Form of Payment (FOP) is included, Charge and Payment details are created.

    • If a Form of Payment (FOP) is not included, passive segments are not created until the FOP is passed.

    • If eNett is used and if eNett returns a credit card billing address, that address is returned in AirCreateReservationRsp/UniversalRecord/FormOfPayment/BillingAddress.

  • A TCR (Ticketless Carrier Record) is created (rather than an ETR which, is created for host bookings at the time of ticketing).

  • Some ACH suppliers may return a Pending status, which requires polling.

  • Some ACH suppliers do not return full booking/pricing details in the response. Pricing or status may change on the subsequent retrieval.

  • Passive segments are created in the host.

  • ACH suppliers may return both passenger-level (FareInfo) and itinerary-level (AirPricingInfo) fees.

    Data is also returned in AirPricingSolution @TotalPrice, @Taxes, and @Fees.

    • Note: If the sum of the passenger level fees is different than the itinerary level fees returned by ACH, but the fee type is the same, a warning is returned: Passenger type level fees are informational only, and may not match with those returned at the itinerary level.

  • If the AirPricingInfo/FareInfo @FareBasis code is more than eight (8) characters, and a passive segment is created, the fare basis is truncated to the first eight characters and a General Remark is returned: "The fare basis was truncated to meet host requirements. The full fare basis is AAAAAAAA" where AAAAAAAA represents the actual fare basis code.

  • ACH suppliers may return non-IATA standard tax codes.

  • ACH suppliers do not file Optional Services through ATPCO. Therefore, the additional information provided in the AirCreateReservationRsp are not returned for ACH suppliers.

  • Some ACH carriers support a wide variety of currencies, while others only support a few. When FiledCurrency is sent in the request, if the carrier:

    • Supports the requested currency, then the Base/Total Fare is returned in the requested currency.

    • Does not support the requested currency, the Base/Total Fare is returned in the currency of the point of origin.

    • If the requested currency is not supported by the carrier, a warning is returned: Currency specified for the request does not match the currency associated with the host token.

    The CurrencyType attribute should be used to obtain Approximate Base and Approximate Total fares in the requested currency; it displays an indicative price without changing the underlying transaction.

  • Taxes and Fees Breakdown

    • For ACH carriers that include the taxes and fees within the base fare at the itinerary level, Universal API provides a breakdown of the taxes and fees included in the base fare when this information is provided by the carrier. In UniversalRecordRetrieveRsp/UniversalRecord/AirReservation and /AirReservation/AirPricingInfo, each TaxInfo or FeeInfo element contains the attribute @Text, which returns any freeform text information provided by the supplier, and the element IncludedInBase, which provides the breakdown of the taxes and fees. IncludedInBase has the attribute @Amount, which shows the amount included in the base fare for the specific fee or tax. This information is provided by default anytime it is available from the ACH carrier.

Air Canada

The following data is required for bookings on Air Canada:

  • Prefix
  • Email
  • Phone
  • Secure flight information
  • Exact match for frequent flier name (LoyaltyCard), if present.
  • ShippingAddress

ShippingAddress is optional in the schema; however, if it is not present, Air Canada bookings fail. Air Canada requires all of the following attributes for ShippingAddress in the Air Booking request:

  • AirCreateReservationReq/BookingTraveler/DeliveryInfo/ShippingAddress @Street @City @State @PostalCode @Country

Tour codes are used for tracking only in the Air Booking transaction. The tour code that is sent in the Air Booking request in /FareInfo @TourCode is saved to be displayed in the book and retrieve response.

Note: Currently, Air Canada is the only ACH supplier to support Tour Codes.

Only one Tour Code per supplier can be sent in the Air Booking request. A Tour Code can be sent per traveler; however, each Tour Code numbers must match because Universal API processes only the first Tour Code found in the request. If the Tour Codes do not match, the Tour Code is not used in the booking, and an error is returned: "Only one tour code can be sent in the request."

The Tour Code that was sent in the Air Booking request is returned as an attribute in /AirPricingInfo/FareInfo. If multiple instances of AirPricingInfo can be returned in a response, the Tour Code is returned in each instance.

Virgin Australia

(Formerly Virgin Blue)

Virgin Australia (DJ) requires AssociatedRemark/RemarkData to pass the booking reference to DJ. The remark data is returned in the Air Booking response.

  • AssociatedRemark is used specifically by DJ for ACH carriers. If the AssociatedRemark ProviderCode="ACH" but the SegmentRef does not point to a DJ segment, an error is returned: "AssociatedRemark is not supported for this carrier."

  • Only one Customer Booking Reference is permitted per PNR. If more than one AssociatedRemark is sent, an error is returned: "Only one AssociatedRemark supported for this carrier."