Short answer: a PSS (passenger service system) is the core software an airline runs its commercial operation on. It has three main parts: the reservation system that creates and stores bookings, the inventory system that decides how many seats are for sale at which fare classes, and the departure control system that checks passengers in and boards the flight. GDSs, NDC APIs and airline websites are all just sales channels feeding into the PSS.
What a PSS is
Passenger service system is the industry's umbrella term for the software suite at the heart of an airline's commercial business: selling seats, keeping the master record of every booking, and getting passengers onto aircraft. Airlines either license a PSS from a specialist vendor (the common case) or, for a handful of the largest carriers, run heavily customised or in-house systems with the same three functions. When you press "book" anywhere, in an agency terminal, on the airline's app, through an API, the transaction ends up in a PSS.
The three core components
| Component | What it does | What agencies see of it |
|---|---|---|
| Central reservation system (CRS) | Creates, stores and modifies bookings; holds the airline's master PNR; manages fares and ticketing links | The airline-side PNR your GDS booking synchronises with |
| Inventory system | Controls how many seats are open in each booking class on each flight, applying revenue management decisions | Availability displays, waitlists, class closures and last-seat availability |
| Departure control system (DCS) | Check-in, seat assignment at the airport, baggage, boarding, load control | Online check-in behaviour, boarding passes, why airport staff "cannot see" some changes |
Around this core, modern PSS platforms bolt on internet booking engines, loyalty modules, merchandising and APIs, but reservations, inventory and DCS remain the defining trio described consistently across the industry, for example in AltexSoft's overview of airline reservation and passenger service systems.
Who builds PSSs
A small vendor market serves most of the world's airlines. The most-cited platforms are Amadeus Altea, used by many full-service network carriers; SabreSonic from Sabre; and Navitaire (owned by Amadeus but run separately), whose ticketless, e-commerce-style model made it the default choice for many low-cost carriers. Industry analyses such as AltexSoft's credit these three families with the majority of the market, with challengers and regional systems serving the rest. Which PSS an airline runs shapes what its channels can do: ticketless low-cost platforms historically skipped parts of the interline and GDS machinery that full-service systems were built around.
How a PSS relates to the GDS
The GDS is a distribution layer, not the source of truth. When your agency books through Amadeus, Sabre or Travelport, the GDS creates its own PNR and messages the airline's PSS, which creates or updates the airline-side booking and decrements inventory. Fares are filed by airlines (via ATPCO) and computed by the GDS, but the seats themselves are always the PSS inventory system's decision. This is why a "confirmed" GDS segment can still fail if synchronisation breaks, and why schedule changes flow from the PSS outward to every channel that holds a copy of the booking. The mechanics of PNRs across these systems are covered in our companion guide, what is a PNR, and the agency-side connection work under GDS integration.
How a PSS relates to NDC
NDC does not replace the PSS; it gives the airline a more direct doorway into it. In an NDC flow the airline's offer engine, sitting on top of PSS inventory, constructs the priced offer itself instead of letting the GDS compute one from filed fares, and the resulting order is managed airline-side. IATA's long-term "offers and orders" vision goes further, gradually retiring PNRs, e-tickets and EMDs as record formats, which over time reshapes what PSS vendors sell. For the channel-level view of that shift, see our guide to what NDC changes for agencies.
Why agencies should care
- Servicing logic makes sense: knowing the airline PNR (in the PSS) is the master copy explains why some changes must be done "with the airline" rather than in your GDS
- Sync failures stop being mysteries: divergence between the GDS record and the airline record is the root of many "booking exists but airline cannot see it" calls
- Low-cost carriers behave differently by design: ticketless PSS platforms explain missing interline, different change flows and API-only distribution
- Channel strategy is really PSS strategy: which fares appear on GDS versus NDC versus direct reflects how the airline configured its systems and offers
- Better supplier conversations: asking a consolidator or aggregator how they handle airline-side changes shows you where their pipes actually reach
For a booking site or portal, none of this requires touching a PSS directly; it means designing your flight API integration so that airline-side truth (schedule changes, cancellations, involuntary reroutes) reaches your customer service before your customers notice. That is a data-flow decision we make deliberately in every travel API project.
Sources: AltexSoft, "Airline Reservation Systems and Passenger Service Systems"; vendor documentation from Amadeus (Altea), Sabre (SabreSonic) and Navitaire; IATA's Distribution with Offers and Orders programme material. Vendor client lists and market shares change, so verify current specifics with the vendors.
This article is general information about travel technology and online marketing. It is not legal, tax or financial advice, and advertising platform policies change often. Check the current policy documents and take professional advice for your own situation.