Air Booking with Form of Payment (FOP)

Air bookings are created using the results from an Air Pricing response. Multiple stored fares can be imported, and one, or multiple, Forms of Payment can be added to an Air booking, depending upon the number of stored fares in the booking. Each can have a different Payment associated with it.

Schema

Located in Universal.xsd:

• AirCreateReservationReq
• AirCreateReservationRsp

How To

1. Include the minimum required information for creating an air booking.

2. Forms of payment can be added at the PNR level, provider reservation level, and stored fare level.

   • For payment at the PNR level (provider reservation level), send AirCreateReservationReq/FormOfPayment/ProviderReservationInfoRef @ProviderReservationLevel="true" (default value). Include payment one or more details in AirCreateReservationReq/FormOfPayment.

   • For payment at the stored fare level, send payment details in AirCreateReservationReq/Payment.

     Note: When testing in a development environment, credit card numbers for FOP testing purposes can and should be requested from the credit card issuer directly. Travelport does not provide test credit card numbers.

   Form of payment scenarios

   The following table shows how FormOfPayment is applied across PNRs and Stored Fares.

   Note: Stored Fare (SF) is the same as Filed Fare (Galileo), ATFQ (Apollo), or AirPricingInfo.

   Stored Fare	Request	Response
   Single Stored Fare	Request an allowed FormOfPayment at Stored Fare level, but NOT allowed at PNR level (e.g., Government Credit Requisition)	Warning: Form of Payment is not allowed at PNR level. Request is processed with FormOfPayment only at the Stored Fare level in the response.
   Single Stored Fare	Request an allowed FormOfPayment at PNR, but NOT allowed at Stored Fare level (e.g., not in existence now)	Warning: Form of Payment is not allowed at Stored Fare level. Request is processed with FormOfPayment only at the PNR level in the response.
   Single Stored Fare	Request an allowed FormOfPayment (e.g., Cash) at the PNR level and a different allowed FormOfPayment (e.g., Check) at Stored Fare level	Both FormOfPayment elements are processed.
   Single Stored Fare	Request NO FormOfPayment at the PNR level and an allowed FormOfPayment (e.g., Check) at the Stored Fare level	The Stored Fare’s FormOfPayment is applied to the PNR if ProviderReservationLevel=true.
   Single Stored Fare	Request an allowed FormOfPayment (e.g., Cash) at the PNR level and NO FormOfPayment at the Stored Fare level	A successful response is returned with the requested FormOfPayment at the PNR level.
   Multiple Stored Fares	Request NO FormOfPayment at the PNR level and multiple Stored Fares with different FormOfPayment elements for each Stored Fare	There are four potential responses: If ProviderReservationLevel=true for one of the Stored Fares, apply that FormOfPayment to the PNR. If ProviderReservationLevel=true for all Stored Fares, apply the FormOfPayment for the first Stored Fare to the PNR. If ProviderReservationLevel=false for all Stored Fares, NO FormOfPayment is applied to the PNR. If there are multiple Stored Fares with multiple FormOfPayment elements and if ProviderReservationLevel=false for all Stored Fares, but an additional FormOfPayment is included and ProviderReservationLevel=true, the additional FormOfPayment is applied to the PNR.
   Multiple Stored Fares	Request an allowed FormOfPayment (e.g., MiscFormOfPayment) at the PNR level and multiple Stored Fares with different FormOfPayment elements for each Stored Fare	The first FormOfPayment with ProviderReservationLevel=true is applied to the PNR. If a value for ProviderReservationLevel is not given for any of the FormOfPayment elements, no FormOfPayment is applied to the PNR.
   Single and Multiple Stored Fare	Request a FormOfPayment, but do not specify if it is for the PNR or Stored Fare level	If the FormOfPayment is valid, it is applied to the PNR level.

3. Credit card form of payment without an associated credit card type (FormOfPayment @Type) is allowed at the PNR level and the stored fare level in Common.xsd.

   Values allowed for @Type include:

   • Certificate
   • Cash
   • Credit
   • Check - When the form of payment is check, the MICR number can be added at the PNR or stored fare level using the Check @MICRNumber attribute. MICR number is only supported by Apollo.
     
   • Ticket
   • Debit
   • Invoice
   • Requisition (e.g., Government credit or cash)
   • MiscFormOfPayment (e.g., FreeFormCreditCard)
   • AgencyPayment
   • DirectBill
   • UnitedNations
   • DirectPayment
   • AgentVoucher
   • AccountReceivable
   • AgentNonRefundable
   • ARC (Airlines Reporting Corporation) Release 18.3
   • BSP (Billing and Settlement Plan) Release 18.3

   Note: When testing in a development environment, credit card numbers for FOP testing purposes can and should be requested from the credit card issuer directly. Travelport does not provide test credit card numbers.

4. Some Credit Card companies, like American Express (AX), allows some card holders to request extended payments, as opposed to paying a balance in full, which is the traditional AmEx model. Other credit cards, e.g., Visa (VI) and Master card (CA), allow Extended Payment as well, subject to the BSP market rule.

   A payment can be tagged for extended payment in Universal API when a valid credit card is used for an Air Booking. TheExtendedPayment attribute in FormOfPayment/CreditCard is required.

   Provider support

   Galileo supports extended payment.

   For ACH, if CreditCard/Type is sent in the request:

   • With the value 'AX' (American Express) AND the ExtendedPayment attribute is also included, an error is sent in the response: "American Express Extended Payment is not supported."
   • With a value other than than 'AX,' ‘VI,’ or ‘CA,’ AND the ExtendedPayment attribute is also included, the ExtendedPayment attribute is ignored.
   • With the value 'AX,' ‘VI,’ or ‘CA,’ but without the ExtendedPayment attribute, Type is accepted.

5. When a booking is created with multiple Forms of Payment (FOP), each from a separate Profile ID, payments are applied and saved as such. Additionally, in the response, all of the Forms of Payments are shown, applied, and saved to each corresponding Profile ID.

6. The response returns an Air Booking with form of payment information in AirReservation/FormOfPayment/ProviderReservationInfoRef. Each ProviderReservationInfoRef indicates that a Form of Payment exists for a provider at the PNR level.

Exceptions