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

Seller recognition

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.

You can find a detailed guide for this part here.

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:

  • Travel management company
  • Student (with PTC "STU")
  • Seat only 
  • Marine (with PTC "SEA" and OSI "MARINE FARE Name of the ship Country of registration" - see example here)
  • Tour operator

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, indicate the Corporate Identifier (CLID) as an OSI in OrderCreateRQ. Refer to the example of OrderCreateRQ in the InstructionList. The creation of an SSR CLID as described in the OrderCreate implementation guide must not be used for now.

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

In case of flight disruptions, our flight scheduling team re-accommodates passengers to suitable alternatives. This means that we take care of the ticket’s revalidation and no action is needed from the sellers.

All orders are updated with text SSR OTHS “INVOL rebooked due to AY irre, rebook on AY or oneworld” . This is an indication that there was a flight change in booking. This is for AY internal PNR handling and NDC sellers can ignore this SSR.

Below SSR OTHS are meant for communicating actions needed from sellers:

Scenario

SSR OTHS

Action required from NDC seller

Schedule change of 5 min or more

No action required from NDC sellers  

No action needed from seller.

The flight (and any affected connecting flights) is automatically rebooked by AY.

Flight cancellation and rebooking by AY

No action required from NDC sellers 

No action is required from seller.

If the new flights are not acceptable for the passengers, the seller can visit Manage Booking or contact AY Customer Care for rebooking.

Flight cancellation (AY no longer operating that route/day)

NDC sellers to contact AY customer care 

Seller needs to contact AY Customer care for possible rebooking options. BSP sellers can request refund through BSP application and direct agents can fill online form here.