Short answer: a flight metasearch engine takes one search, fans it out to many suppliers (GDS, airline direct or NDC connections, OTA feeds and affiliate networks), normalises and deduplicates the results, ranks them, caches them, and then earns money when the traveller clicks through (cost per click) or completes a booking (cost per acquisition). It is a comparison and referral business, not a ticketing business.
Metasearch vs OTA vs airline direct
Three kinds of website show flight prices, and they are easy to confuse because the search box looks the same on all of them. The difference is who holds the inventory, who takes the payment, and who is responsible when the flight changes.
| Flight metasearch | Online travel agency (OTA) | Airline direct | |
|---|---|---|---|
| Examples | Skyscanner, Google Flights, Kayak, Momondo | Expedia, MakeMyTrip, Booking.com flights, Trip.com | IndiGo, Air India, British Airways, Delta |
| Holds inventory? | No. Displays fares sourced from others. | Yes, via GDS, NDC or consolidator contracts. | Yes, its own seats. |
| Takes payment? | Usually not. Redirects to a booking site. Some offer facilitated booking. | Yes. Issues the ticket and handles changes. | Yes. |
| Revenue | Per click, per booking or hybrid from the sites it refers to; advertising. | Margin, service fees, supplier incentives, ancillaries. | Fare plus ancillaries. |
| Customer relationship | Ends at the click unless the engine holds an account or facilitated booking. | Owns the booking and the support burden. | Owns everything. |
| Licensing and liability | Lightest. No ticketing, so no IATA accreditation needed. | Needs ticketing capability (own or via consolidator), payment compliance, refunds handling. | Regulated carrier. |
A meta flight website sits in the first column. A flight aggregator website is the same idea when the comparison is across your own supplier connections rather than across other retail websites.
Where the fares come from
A metasearch engine is only as good as its sources. Large engines combine all of the following; a new regional engine usually starts with two or three.
Global distribution systems (GDS)
Amadeus, Sabre and Travelport aggregate published fares from most full-service carriers and many low-cost carriers. A GDS shopping call returns priced itineraries with fare rules and availability. It is the broadest single source, but it has two limits for metasearch: the contract normally expects a sensible ratio of searches to bookings, and many low-cost carriers and some airline-specific fares are not in it. See our GDS integration page for how the connection works in practice.
Airline direct and NDC
Airlines expose their own fares, bundles and ancillaries through direct APIs, increasingly built on IATA's New Distribution Capability (NDC) standard. Direct connections often surface fares and seat bundles a GDS does not carry, and they are the only route to most low-cost carriers. The cost is integration effort: each airline is a separate project with its own onboarding, certification and schema quirks.
OTA and consolidator feeds
Online travel agencies and consolidators publish search APIs so that metasearch engines can list their prices. This is the core of the classic metasearch model: the OTA pays for clicks or bookings, and the engine shows the OTA's fare alongside the airline's. Consolidator feeds are also how many engines in India and the Middle East get net fares that are cheaper than published ones.
Affiliate networks
Networks such as Travelpayouts, and programmes run through Impact, CJ or Awin, package OTA and airline offers with tracking links. They are easiest to join and lowest in commercial commitment, which makes them a common starting point, at the cost of less control over data freshness and the click economics. Our flight affiliate website guide covers that path in detail.
Cached fares and price history
Every serious engine stores the results of recent searches. Cached fares power calendar views, "cheapest month" features, route pages that rank in Google, and price alerts. They also answer a large share of repeat searches without a new supplier call, which is the single biggest lever on operating cost.
The search lifecycle, step by step
From the moment a traveller presses search to the moment the results settle, a metasearch engine runs through a fixed sequence.
- Query. The search form is validated (airport codes, dates, passengers, cabin) and the engine decides which sources are relevant. A domestic Indian search does not need a European OTA feed; a multi-city search may skip sources that cannot price it.
- Fan-out. Requests go to every relevant source at the same time, each with a timeout. A slow source should delay one row, not the page.
- Normalisation. Each supplier returns a different structure: different currency, taxes included or not, different airport and carrier codes, baggage rules in free text. Everything is mapped to one internal schema before anything else happens.
- Deduplication. The same physical itinerary (same flights, same dates, same cabin) often arrives from five sellers at five prices. The engine groups them into one result with a list of sellers, or keeps only the cheapest, depending on the product.
- Ranking. "Best" is a score combining price, duration, stops, departure time, self-transfer risk and seller reliability. Most engines also let the user sort by price or duration alone.
- Cache. The normalised result set is stored with a time-to-live so that the next identical search, the price calendar, and the route pages can be served without a new supplier round trip.
How flight metasearch engines make money
The traveller pays nothing to the metasearch engine. The sites it sends traffic to do. Four models exist, and most engines use more than one.
Cost per click (CPC) redirect
The oldest and still the most common model. When a user clicks a fare, they are redirected to the OTA or airline site and the seller pays for the click, whether or not a booking follows. Rates are negotiated per partner and per market, and often vary by route. The engine's interest is in sending qualified clicks; the seller's interest is in conversion, which is why sellers push for "deep links" that land on a pre-filled booking page rather than a home page.
Cost per acquisition (CPA)
The seller pays only when a referred user completes a booking, usually a share of the ticket value or a fixed amount per passenger. This shifts the risk to the engine, so it is common when the engine is small, when it joins through an affiliate network, or when the seller does not trust the traffic quality yet.
Hybrid
Larger engines negotiate a lower per-click fee plus a performance bonus, or move partners between CPC and CPA depending on how their traffic converts. A partner whose fares are frequently unavailable on landing (a "fare mismatch") may be demoted in ranking or moved to CPA until the problem is fixed.
Facilitated booking, or "book on meta"
Some engines now let the traveller complete the purchase without leaving the site. The ticket is still issued by the partner OTA or airline, and the engine collects the details and hands them over. This raises conversion because the user never loses the price they saw, but it also brings the engine closer to the support and compliance obligations of an OTA. It is a different product, closer to what we describe on the flight booking engine page.
Advertising and data
Display advertising, sponsored placements from airlines and OTAs, and anonymised demand data sold to airlines and tourism boards round out the picture.
Why caching and look-to-book ratios matter
The economics of metasearch are dominated by one ratio: searches per booking, known in the industry as the look-to-book ratio. Every search costs money. GDS contracts typically cap how many shopping requests you may send per booking before overage fees apply; airline direct connections impose rate limits; even a free affiliate API will throttle you. A comparison site, by design, generates far more looks than books, because it shows results it does not sell.
Caching is the answer. A well-run engine serves a large share of requests from cache without calling any supplier. The trade-off is freshness: cache too long and you show a fare that is gone when the user lands on the seller's site, which damages trust and gets you demoted by partners; cache too briefly and your supplier bills climb. Most engines use short time-to-live values for specific date searches, longer ones for calendar and route-page data, and re-price a single itinerary live at the moment of click.
This is also why an engine's first supplier choices matter so much. A source that tolerates high search volumes at low or zero cost per search (an OTA feed paying you for clicks, for example) can be queried freely, while a GDS connection has to be used sparingly and backed by cache. We cover this choice in the flight booking API comparison.
What it takes to build your own
Nothing about metasearch is secret, but it rewards focus. A regional engine that covers one country's airports, a handful of suppliers, and the routes people actually search can be built and launched; a global clone of Skyscanner cannot, and should not be the plan.
Scope
Decide the markets (for example India domestic plus India to the Gulf, UK and North America), the supported trip types (one-way, return, multi-city), languages and currencies, and whether you redirect only or also facilitate booking.
Suppliers
A practical first line-up is one broad source (a GDS or a consolidator API) for coverage, one or two OTA or affiliate feeds that pay per click, and direct connections to the low-cost carriers that dominate your market. Each supplier has a commercial onboarding process separate from the technical one, and some will only sign with an entity that has a registered travel business.
Cost drivers
Supplier fees and minimums, search volume (which drives infrastructure and API costs), the number of integrations, the depth of the front end (calendar views, price alerts, maps, multi-currency), admin and reporting tools, and ongoing maintenance as supplier APIs change. We explain these in general terms on the travel portal development cost guide; the honest answer to "how much" is a scoped quote.
Timeline
A white-label or affiliate-based engine can be live in weeks because the supplier side already exists. A custom engine with its own GDS and airline connections takes months, with supplier certification often the slowest step rather than the code.
What you will need beyond the software
A registered business, supplier agreements, a privacy policy and cookie consent that cover affiliate tracking, a content plan (route and airport pages are how metasearch engines get organic traffic), and a clear position on compliance: you are a comparison site, you do not issue tickets, and you are not affiliated with any airline. That position should be visible on the site, not buried in the terms.
Questions to settle before you start
- Which markets and routes will the first version cover, and which will it deliberately ignore?
- Redirect-only, facilitated booking, or both? This decides your compliance and support load.
- Which sources will carry the search volume cheaply, and which will be rate-limited and cached?
- What cache time-to-live will you accept for specific-date searches versus calendar and route pages?
- How will you measure fare accuracy at landing, and what happens to a partner whose fares mismatch?
- Who owns the commercial relationships with suppliers: you, or the platform vendor?
- How will the site earn organic traffic (route pages, airport guides, price tracking) rather than relying on paid clicks?
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.