Een vliegticketvergelijker werkt door tarieven, beschikbaarheid en voorwaarden van verschillende luchtvaartmaatschappijen en boekingskanalen gelijktijdig op te vragen via GDS-systemen, directe API-koppelingen en cachingstructuren. De vergelijker berekent vervolgens welke vluchtcombinaties technisch uitvoerbaar zijn, welke tarieven toepasbaar zijn op basis van boekingsklasse, en welke bijkomende servicekosten of flexibiliteitsregels gelden. De structuur lijkt op de manier waarop luchtvaarttarieven worden opgebouwd, zoals beschreven op tarief, maar een vergelijker verwerkt deze gegevens geautomatiseerd binnen milliseconden. Het resultaat is een realtime overzicht van mogelijke vluchtopties met filters op prijs, reistijd, overstappen, bagage en airline.
Hoe tarieven uit GDS-systemen worden opgehaald
Vliegticketvergelijkers maken gebruik van wereldwijde distributiesystemen (GDS) zoals Amadeus, Sabre en Travelport. Deze systemen bevatten miljoenen tarieven die zijn ingediend door luchtvaartmaatschappijen volgens ATPCO-structuren. Een vergelijker voert een tariefzoekopdracht uit op basis van datum, vertrek- en aankomstluchthaven, passagierstypen en serviceclass. De GDS retourneert vervolgens alle geldige fares, inclusief restricties, inventarisstatus en fare basis codes. Deze fare basis bepaalt welke regels gelden voor wijzigingen en annuleringen, zoals uitgelegd op wijzigingskosten.
Het ophalen van tarieven is slechts één deel van het proces; de vergelijker moet ook seats beschikbaar vinden binnen de juiste boekingsklasse. Een vlucht kan stoelen beschikbaar hebben, maar als de bijbehorende RBD (bijv. V, L of T) gesloten is, is het tarief niet boekbaar. De vergelijker controleert daarom inventory buckets, seat availability en married segment logic, vooral bij complexe routes met overstappen.
Hoe vluchtverbindingen worden opgebouwd
Een vergelijker moet bepalen welke combinaties van segmenten toegestaan zijn. Niet elke airline staat willekeurige aansluitingen toe. De tool verifieert per vlucht of de Minimum Connecting Time (MCT) wordt gehaald en of internationale, Schengen- of veiligheidscontroles de overstap mogelijk maken. De techniek achter geldige overstappen werkt identiek aan de logica zoals uitgelegd in aansluiting.
Wanneer een vergelijker combinaties bouwt, controleert hij routing rules, permitted carriers en fare combinability. Een tarief kan vereisen dat een passagier via een specifieke hub reist, waardoor een route zoals AMS–FRA–HND wel toegestaan is, maar AMS–MUC–HND niet. Ook kunnen overstappen binnen non-Schengen zones nodig zijn zonder paspoortcontrole, wat impact heeft op welke verbindingen de vergelijker mag tonen.
Directe API-koppelingen met airlines
Steeds meer airlines leveren data via directe API’s die tarief-, beschikbaarheids- en seatmap-informatie bevatten. Deze API’s kunnen dynamisch geprijsde tickets teruggeven, vooral wanneer airlines revenue-based pricing gebruiken. Hierdoor kunnen bepaalde routes of data goedkoper worden weergegeven dan via GDS. Vergelijkers gebruiken vaak een hybride model: GDS voor basisdata en airline-API’s voor aanvullingen zoals bagage-info, stoelindeling en reissupplementen. De herkomst van vluchtinformatie lijkt op de datastroom die ook wordt gebruikt door vluchtvolgsystemen zoals beschreven op vluchtstatus.
Hoe prijzen worden berekend inclusief toeslagen en servicekosten
De ticketprijs bestaat uit het basistarief, belastingen, luchthavenheffingen en carrier-imposed surcharges (YQ/YR). Deze componenten worden door de vergelijker naar de eindgebruiker gecombineerd tot één transparante prijs. Sommige boekingssites tonen aanvullende servicekosten pas in de checkoutfase. Een vergelijker moet rekening houden met bagageregels, omdat deze afhankelijk zijn van fare families. De regels rondom bagage worden uiteengezet op bagage. Door afwijkende bagageregels op dezelfde route kunnen prijzen sterk variëren tussen aanbieders.
Bij airlines die dynamic pricing toepassen, kan de prijs binnen minuten variëren op basis van vraag, device fingerprinting of routebeperkingen. Een vergelijker toont steeds de prijs zoals deze op dat moment wordt teruggegeven door de GDS of de airline-API. Wanneer een passagier meerdere keren zoekt, kunnen airlines hun revenue-algoritmen aanpassen op basis van zoekvolume — een verschijnsel dat vaak wordt verward met prijsopdrijving, maar feitelijk voortkomt uit inventory- en yieldmanagement.
Waarom dezelfde vlucht bij verschillende aanbieders andere prijzen toont
Hoewel het tariefbestand in de GDS identiek is, verschillen prijzen per aanbieder door:
1) servicekosten,
2) onderhandelde nettowijzen,
3) consolidatiedeals,
4) valuta-afronding en
5) de manier waarop bagage wordt verwerkt in de prijs.
Online reisbureaus kunnen toegang hebben tot speciaal onderhandelde fares, vooral op long-haul routes uitgevoerd door maatschappijen zoals Emirates. Ook kunnen consolidatoren bucket-discounts aanbieden bij afname van grote ticketvolumes. Hierdoor worden prijzen soms lager weergegeven dan bij de airline zelf. De vergelijker toont alle bronnen naast elkaar zodat de gebruiker kan kiezen welke aanbieder de beste combinatie van prijs, flexibiliteit en servicevoorwaarden biedt.
Hoe een vergelijker omgaat met multi-city, open-jaw en complexe routes
Bij complexe reizen moet het systeem nagaan of fare combinability-regels worden gevolgd. Een open-jaw ticket (bijv. AMS–HND en terug KIX–AMS) vereist specifieke tariefstructuren die niet met alle boekingsklassen gecombineerd mogen worden. De vergelijker interpreteert deze regels automatisch en toont alleen geldige combinaties. Deze structuur sluit nauw aan op de fare construction logica die wordt beschreven op e-ticket.
Bovendien moeten vluchttijden, overstaptijden en terminalrouting worden gecontroleerd. Multi-city routes kunnen meerdere airlines omvatten, waardoor interline-bagagebehandeling noodzakelijk is. Een vergelijker voorkomt combinaties van airlines die geen interline-overeenkomst hebben, omdat bagage dan niet automatisch doorgelabeld kan worden, zoals uitgelegd op overstap.
Waarom vergelijkers soms niet alle airlines tonen
Bepaalde luchtvaartmaatschappijen, zoals low-cost carriers (Ryanair, Wizz Air, Transavia), beperken toegang tot hun tarieven via GDS. Deze airlines bieden tarieven voornamelijk via directe API’s of hun eigen website. Vergelijkers tonen dan alleen de maatschappijen waarvoor zij legale en technische toegang hebben. Sommige full-service airlines beperken specifieke tarieftypes (zoals discount business of corporate fares) tot eigen verkoopkanalen.
Daarnaast kunnen airlines die dynamic ancillaries verkopen — zoals stoelkeuze, ruimbagage en veranderingen — ervoor kiezen om deze gegevens alleen via eigen systemen aan te bieden. Hierdoor lijkt de vergelijker soms minder complete informatie te geven, terwijl dit technisch gezien afhankelijk is van distributierechten.
Wat er gebeurt wanneer je doorklikt naar een aanbieder
Zodra een gebruiker kiest voor een vluchtoptie, stuurt de vergelijker een live availability check. Deze controleert opnieuw of de boekingsklasse beschikbaar is. Wanneer de beschikbaarheid is gewijzigd, moet de gebruiker de nieuwe prijs accepteren. Dit komt doordat availability dynamisch is: een vlucht met RBD “V2” kan in enkele minuten naar “V0” gaan door externe boekingen. De techniek hierachter werkt identiek aan de seat availability principes binnen prijsstructuren zoals uitgelegd op vliegticket.
Na verificatie wordt de gebruiker doorgestuurd naar het online reisbureau of de airline waar de daadwerkelijke boeking plaatsvindt. De PNR (Passenger Name Record) wordt daar aangemaakt en het e-ticket uitgegeven op basis van het tarief dat op dat moment beschikbaar is. De vergelijker zelf maakt geen PNR aan; deze fungeert uitsluitend als zoekmachine.
Hoe vergelijkers omgaan met filters op reistijd, bagage en overstappen
Filters worden toegepast op basis van gedetailleerde metadata die afkomstig is uit GDS- en API-responses. Reistijd wordt berekend door segmentduur en connectietijd te combineren. Bagage-informatie wordt opgehaald uit ATPCO-bronnen en airline-API’s. Overstappen worden weergegeven inclusief locatie, MCT en terminalinformatie. Hierdoor kan de gebruiker reizen selecteren op basis van comfort, snelheid of tariefstructuur. Deze metadata volgt dezelfde logica als de manier waarop reisplannen worden opgebouwd zoals beschreven op reisschema.
