Introduction

Inbound Passenger Information Service is a service offered by an airport to an airline. The service makes it possible for airlines to give airports information about the passengers on an incoming flight. This in turn makes it possible for the airport to offer a better passenger experience, for example by simplifying the transfer process.
The passenger related information that shall be submitted for all incoming flights consists mainly of:

• • Passenger names
  • Travel documentation 
  • Baggage information

Abbriviations used

Overview

The service consist of two different operations:

• • • SetIPI - which is the preferred operation that should be used, as it forms a well defined and structured interface.
    • SetIIPIFromPRL - which is an alternative operation than can be used by the airline. This operation allows the airline to submit the "PRL-string(s)" to the airport. However, this requires that the airline adheres to any implementaion guide for the PRL format used by the airport. Any implementation guide should clarify elements in RP1719b, restrict which options that may be used and define any optional elements in RP1719b as mandatory.

Design guidelines and requirements

PCI DSS must be fulfilled

Description:
It is a requirement that the interface makes it possible to fulfill the PCI DSS. Basically this means that masked credit card numbers must be used.

Considerd
Yes. The interface has support for masked credit card numbers.

Support for all relevant travel documentation

Description:
The interface must have support for validation of all relevant travel documentation. The following is used and must be supported:

• • • • 2D bar code.
      • Credit card (number)
      • Other cards (feequent flier, co-branded, military)
      • NFC

Considerd
Yes. All these types of travel documentation have been considered. Currently NFC can't be validated using this interface.

Interface must be general and support all airlines and all airports

Description:
The interface must be generic in a way so it can be used by any airline and be used to support all Avinor airports, and not only OSL.

Considerd

Yes. The SetIPI service operation is generic and are not relying on any specific ailrine booking- or DCS-system. However, the operation SetIPIFromPRL and the reated Implementation Guide, has only been verified towards the Amadeus Altea DCS-system.

Interface should be simple to understand and use

Description:

The interface should be defined and documented in a way that as much as possible uses current airline nomenclature.

Considered:

Yes. The main elements and naming is taken from the set og IATA recommendation and recommended practices. However, when naming has been found unambigious, calrification have been introduced.

Implementation considerations

Any implementation of this service MUST use the WSDL and XSD files provided here: WSDL and XSDs

It is however up to the service provider to decide which data elements to actually update. As clients vary wildly in their capabilities most elements are optional

Any service provider should make available documentation about the actual implementation, including:

• • • the address of the service.
    • any limitations in the implementation.
    • any limitations on how often a client can use the service.

Purpose of this service description

This service description has the following purpose:

• • • Describe of service in enough detail for a service provider to implement it.
    • Describe the service so that a client (of this service) developer can use it.
    • Make available the WSDL and XSD files necessary to implement and use the service.
    • Make it possible for relevant people at airports, airlines, handlers and other aviation partners to understand the available functionality and then to decide if to implement/use it or not.

Intended readership

• • IT architects
  • Developers
  • Business architects
  • Interested parties in the aviation community

Service overview

The figure below shows the available operations on the Inbound Passenger Information Service. The operations are described in detail in Service operations.

Service operations

Data entities

XML Usage

WSDL and XSDs