PassengerDetailsRQ

The PassengerDetailsRQ service allows client applications to create shell PNRs containing names, phone numbers, email addresses, customer numbers, passenger types, address information, remarks, and retention segments.

The client application can end the transaction once processing is complete, or leave the transaction open in the AAA for subsequent processing. If this option is chosen, the client application can add additional information into the PNR via existing TPF Connector-based Sabre Web Service calls, or other orchestrated service calls, before ending the transaction.

PassengerDetailsRQ orchestrates the following operations:

1. SabreCommandLLSRQ (N*(Profile Name)(end-item)NM)
2. TravelItineraryAddInfoLLSRQ (-, 9, PE, DK, PD, W-, 7)
3. MiscSegmentSellLLSRQ (0OTH, 0MCO, 0INS, 0PTA)
4. SpecialServiceLLSRQ (3, 4)
5. AddRemarkLLSRQ (5)
6. UpdateReservationRQ (New FOP remarks)
7. AirSeatLLSRQ (4G)
8. ARUNK_LLSRQ (0AA)
9. SabreCommandLLSRQ (PQL(record number)(* or –)(name number)
10. EnhancedEndTransactionRQ
11. QueuePlaceLLSRQ (QP)
12. User defined wait interval before reservation redisplay
13. TravelItineraryReadRQv3.10.0
14. IgnoreTransactionLLSRQ (I)

Client applications can pass on any of the services contained within the workflow outlined previously, and in terms of responses they can opt to only receive the record locator generated as a result of the process, or to receive the entire PNR generated as a result of the process via the TravelItineraryReadRQ response message.

In the event you use PassengerDetailsRQ to add frequent flyer number to the PNR and PostProcessing/@RedisplayReservation is set to true, the orchestration engine will ensure that frequent flyer information is added to the PNR before the response is returned to your customer. If PassengerDetailsRQ doesn’t find frequent flyer information in the PNR, it will perform two (2) more attempts, each after 1 second delay. If frequent flyer data is not present in the PNR after 3 attempts, the response is returned and a warning is added to ApplicationResults: Missing expected CustLoyalty information.

Example

Completing a reservation with PassengerDetailsRQ after a call to EnhancedAirBookRQ

When the client application needs the PNR to store Price Quote records, the PNR can be completed by performing a call to EnhancedAirBookRQ plus a single subsequent call to PassengerDetailsRQ. Whenever the price Retain flag is set to true (to retain the Price Quote records in the PNR) within the EnhancedAirBookRQ service call,

and the client application wants to create a PNR as the result of the subsequent PassengerDetailsRQ service call, then the same PassengerDetailsRQ request needs to explicitly specify the relationship/link between the passengers and the Price Quote record(s) that will be generated and retained in the PNR being built.

Note: The PNR is completed by filling in mandatory information like contact phone number, ticket time limit, received from, passenger name(s), and using PostProcessing/EndTransactionRQ/EndTransaction Ind="true".

The relationship stated above needs to be established using the passenger name number of each passenger and the associated Price Quote record number, considering the passenger type.

For example, if the call to EnhancedAirBookRQ includes the OTA_AirPriceRQ section as shown above, the following Price Quote records will be generated:

• Price Quote Record #1 for Adult (ADT) passengers
• Price Quote Record #2 for Infant (INF) passengers

Note: When generating and retaining Price Quote records, the EnhancedAirBookRQ service respects the order in which the PassengerType elements are specified, so the order of the associated Price Quote record numbers is the same.

This way, the call to PassengerDetailsRQ needs to include:

Considering the NameNumber and PassengerType fields are also specified for each passenger in the same PassengerDetailsRQ:

Important! If the price Retain flag is set to true in the EnhancedAirBookRQ service call, but no relationship/link to the generated and retained Price Quote record/s is specified in the PassengerDetailsRQ service call, then the PassengerDetailsRQ response will return this error:

Automated handling of hosted vs. non-hosted indicators for SSRs/OSIs

Due to Sabre specifics, it's necessary for an agency to append information based on whether SSR/OSI information should be passed to American Airlines (AA) or other, so-called, non-hosted carriers. This is controlled within PassengerDetailsRQ by the below attributes:

/PassengerDetailsRQ/SpecialReqDetails/SpecialService/SpecialServiceInfo/AdvancePassenger/ VendorPrefs/Airline/@Hosted

/PassengerDetailsRQ/SpecialReqDetails/SpecialService/SpecialServiceInfo/SecureFlight/VendorPrefs/Airline/@Hosted

/PassengerDetailsRQ/SpecialReqDetails/SpecialService/SpecialServiceInfo/Service/VendorPrefs/Airline/@Hosted

Please note that from version 3.3.0, the API will handle the above flags automatically. Therefore, it is not necessary to include the below elements/attributes within the payload:

/PassengerDetailsRQ/SpecialReqDetails/SpecialServiceRQ/SpecialServiceInfo/AdvancePassenger/VendorPrefs

/PassengerDetailsRQ/SpecialReqDetails/SpecialServiceRQ/SpecialServiceInfo/SecureFlight/VendorPrefs

/PassengerDetailsRQ/SpecialReqDetails/SpecialServiceRQ/SpecialServiceInfo/Service/VendorPrefs/Airline/@Hosted

The API processing will analyze the reservation and check the marketing airline code for each flight segment. Then it will check which flight segments the SSR request is directed to.

• If the SSR request is directed to a flight segment where the marketing airline is AA, then the applicable hosted indicator will be automatically applied.
• If the SSR request is directed to a flight segment where the marketing airline is not AA, then the applicable non-hosted indicator will be automatically applied.
• If the SSR request is directed to all flight segments in the reservation:

/PassengerDetailsRQ/SpecialReqDetails/SpecialServiceRQ/SpecialServiceInfo/.../@SegmentNumber="A"

then the system will send two requests, one with a non-hosted indicator and another with a hosted indicator.

Migration to the new form of payment field (*FOP)

As per Sabre Advance Notification (SAN) 16643, in 1Q 2025 Sabre is retiring the ‘5-‘ form of payment remarks field. This has been the traditional method of adding form of payment information in PassengerDetailsRQv3.4.0 (and older). To prepare API customers for the migration, a new version of the API is released (3.5.0) which introduces support of the updated method of adding form of payment information.

Note: You can self-activate the new form of payment field by enabling PNAPNR TJR setting on your PCC level.

Summary of changes

• The new API version
  • takes advantage of downline call to UpdateReservationRQ instead of legacy AddRemarkLLSRQ to add form of payment information.
  • allows you to add up to ten forms of payment. (Previously only one form of payment could be added.)
• There is no other request schema change; you may continue adding form of payment information in the same way they did in the previous versions.

• Once the form of payment information is added, you will see a different identifier at /PassengerDetailsRS/TravelItineraryReadRS/TravelItinerary/OpenReservationElements/OpenReservationElement[n]/@elementId.

  Forms of payment added in the new way will show an extra interfix: “-or-“ .

New method snippet

<OpenReservationElement elementId="pnr-or-3" id="3" type="FP" displayIndex="1">

Old method snippet

<OpenReservationElement elementId="pnr-3" id="3" type="FP" displayIndex="1">

Supported functions

Payment type

The list below presents supported form of payment types and corresponding schema paths:

• Payment card: .../SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark/CC_Info/PaymentCard
• Payment card with cardholder information: .../SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark/CC_Info/PaymentCard + .../CardHolderName
• Cash: /SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark/@Type="CASH" or "CA"
• Check: /SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark/@Type="CHECK" or "CHEQUE"
• Non-refundable type: /SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark/@Type="CASH NON REF" or "CASH NONREF" (also applies to "CA", "CHECK", "CHEQUE", or you may simply use "NON REF")
• Agency/Agent invoice: /SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark/@Type="AGT INV" or "AGT INVOICE"

Other values are currently not accepted and will be ignored by the service. The list may be expanded in the future.

Association of the form of payment to its use type and/or trip type

You may associate a form of payment to its corresponding use type or trip type. It is possible to either:

• add a new form of payment and create an association - this requires passing a matching @temporaryId that maps a new form of payment to its use/trip type, or
• add association to an existing form of payment - this requires passing a form of payment identifier (@displayIndex) already stored within the PNR (obtained from GetReservationRQ or PassengerDetailsRQ responses)

Each form of payment can be associated to its specific use type or trip type. You can also send multiple repetitions of .../SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark_Association/Child to indicate different types.

Note: One .../FOP_Remark_Association/Child element can contain a single use type or trip type. If you wish to associate use/trip type (Child) to an existing form of payment (Parent), you must pass both .../SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark_Association/Parent (identifies an existing payment index) and .../SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark_Association/Child (identifies use or trip type association).

When associating existing forms of payment using /PassengerDetailsRQ/SpecialReqDetails/AddRemarkRQ/RemarkInfo/FOP_Remark_Association/Parent/@displayIndex, the API can return a downstream error stating "INVALID LINE NUMBER". In this case, please review the content of the session and make sure that the form of payment present in the *FOP wallet entry matches the @displayIndex attribute.

When neither Parent/@displayIndex nor ../Child/@temporaryId is passed within a single FOP_Remark_Association node, the API can return a downstream error stating "NO ASSOCIATION PARENT PROVIDED". In this case, please review the request and amend either @displayIndex when referencing a form of payment that already exists within the customer session or @temporaryId when referencing a new form of payment added in the same PassengerDetails request.

Supported use types:

• "AZ" - All
• "AN" - Ancillary
• "AL" - Airline
• "BU" - Bus/Ground Transportation
• "CR" - Car
• "CS" - Cruise
• "HL" - Hotel
• "IN" - Insurance
• "LC" - Low-Cost Carrier
• "OT" - Other
• "RL" - Rail
• "SS" - Specialty Service
• "TR" - Tour
• "IR" - Interface Record

Supported trip types:

• "AZ" - All
• "CP" - Corporate/Business
• "LS" - Leisure
• "EM" - Emergency
• "FM" - Family
• "GP" - Group

The PassengerDetailsRQ API Resources tab contains sample payloads for form of payment remark association to trip and use type.

Notes:

• If you have already enabled TJR PNA PNR setting, we recommend migrating to the new functionality in version 3.5.0.
• If you have not yet enabled TJR PNA PNR setting
  • you can migrate to the new functionality in version 3.5.0; but note that addition of payment card manual approval code (equivalent of 'Z' qualifier) is not supported.
  • you can stay on the old version of the API (3.4.0) until you are ready to migrate or before the sunset of the legacy functionality.