General Guidance

This list contains general best practice rules which apply to multiple capabilities and which should be followed across all messages affected.



  • Within Offers (excluding a-la-carte Offers), there should always be at least one OfferItem marked with the MandatoryInd=true. Absence of this element implies the OfferItem is optional (same as using MandatoryInd=false).

  • When defining rules regarding baggage allowance by weight, the TotalMaximumWeightMeasure element should also be populated (e.g. ).

  • Total Price at Offer-level should not be used in shopping responses (e.g. or ).

  • There are two elements where birthdate is mentioned in Datalists:

    The first element is to be used only in case of anonymous shopping, while the latter is to be used once the passenger data is communicated.

    The same rules apply to the elements

    • /IATA_AirShoppingRQ/Request/PaxList/Pax/CitizenshipCountryCode and

    • /IATA_AirShoppingRQ/Request/PaxList/Pax/IdentityDoc/CitizenshipCountryCode

Order Management

  • In servicing scenarios where a price differential is returned (following the replacing or removal of an existing OrderItem), the PriceDifferential structure needs to be persisted in the OrderViewRS until payment is fully allocated to those affected OrderItems.

  • Delivery Status elements should always be present in OrderViewRS ().

    • Unpaid OrderItems: DeliveryStatusCode=”CONFIRMED”.

    • Paid OrderItems: DeliveryStatusCode=”READY TO PROCEED”.

    • Cancelled OrderItems: DeliveryStatusCode=”REMOVED”.

    • Reference the ATSB Codeset Directory (codeset DELIVERYSERVICE) for all available Delivery Status Codes.


  • If the Seller associates a Payment Method preference to any specific OfferItemIDs, the Airline should return precisely calculated payment surcharge amounts for those specific OfferItems.

  • Any OrderItems that have been fully or partially paid, the payment transaction(s) should reference all OrderItemIDs affected by the payment.

  • PaymentStatusCode and PaymentCommitmentDateTime should be included to all payment confirmations.

  • In “even exchange” scenarios, the committment to accept a change (in the absence of an amount to be paid) should be done by setting the PaymentTypeCode and PaymentBrandCode elements to “OT” and setting the amount to zero.

  • PrefLevel element within Payment functions no longer in use.