Functional & technical specificities of AY NDC compared to the Altea NDC solution

Seller recognition

For 21.3 seller recognition specificities, please check the 21.3 implementation guide for shared features and the DistributionChain example on page 5. In 21.3 SystemID is replaced by OrgID.

Assuming you have already implemented another Altea carrier, you are quite likely aware of “Agency Handling” / “Seller Recognition” / “NDC Configuration”. These are various names for the same feature: a way to identify the seller in our API. See a detailed guide for this part.

Seller recognition is mandatory in our API, and we do require the sending of either IATA numbers or TIDS.

Fare rules and benefits

The fare rules and benefits enable communication of the label and the value mapping, which can be used to receive content in given languages for different fare families. Here is described the process and added a complete Fare Rules and Benefits list.

Files for fare rules and benefits labels: Labels.xlsx and Labels.json

Finnair private fares

We configure our fare access based on the IATA number. Thus, only specific agents may access specific fares.

If you are a partner implementing with us and need to target private fares for testing, our team will configure the access for a dedicated test IATA number.

Travel agent negotiated fares

Our negotiated fares can be targeted with account codes. The account code must be provided in AirShoppingRQ. See the example of AirShoppingRQ in the AccountID field.

List of AY negotiated fare types:

• TMC
• Student (with PTC "STU")
• Seat Only 
• Marine (with PTC "SEA" and OSI "MARINE FARE Name of the ship Country of registration" - see example)
• Tour operator
• Visit Home

Corporate fares

Our corporate fares can be similarly targeted with corporate codes. Input your corporate code in the AccountID field in AirShoppingRQ (see the example above).

In addition, to enable corporate recognition for reporting and pricing, indicate the Client Identifier (CLID) in the CorporateID field in AirShoppingRQ (as per this example, in the Participant section). The creation of an SSR CLID is described in the release note.

Seat exemption

In prime booking flow, it is mandatory to send an OfferPrice message before the SeatAvailability. Otherwise, the seat prices and possible exemptions may not be applied correctly, and the booking can fail.

Secure flights

Secure flights require passport information and date of birth for boarding.

In our flow, passport information can be added at check-in. Thus, for secure flights, only the date of birth is mandatory in OrderCreate.

Contact info

While the Altea NDC API itself doesn’t enforce them, these contact-related fields are all mandatory for AY bookings:

• Phone number (AP)
• Email address (APE)
• Notification contact (APN/CTCE/CTCM)
• Billing address, for credit card payments (AB)

Involuntary exchange

We support many different OCN (OrderChangeNotif) codes to notify the seller of involuntary or voluntary changes to the order. Please check the list of available codes at the bottom of the Order Capabilities page.

Our flight scheduling team re-accommodates passengers to suitable alternatives in case of flight disruptions. It means that in most cases, we take care of rebooking passengers, and no action is needed from sellers. 

However, in some situations, sellers are required to take action when there are no suitable alternatives available. This is communicated through remarks in SSR OTHS. Therefore, all affected NDC orders are updated with SSR OTHS remarks, which contain instructions for sellers, for example, what action they should take.

Below are examples of SSR OTHS remarks, along with detailed descriptions depending on the type of schedule change.