Group airline ticketing platform for a travel consolidator

The brief

A travel consolidator in India asked us to build a group airline ticketing platform. Ticketing vendors hold blocks of seats under a group PNR, each with a fixed fare and a deadline for passenger names. Travel agents buy those seats and supply the names.

The client wanted that whole workflow on one B2B portal. It is not a consumer booking site. Every account is a vendor, an agent or the operator’s own staff, and nobody trades until an admin approves them.

What we built for the group airline ticketing platform

So far we have designed the platform end to end and built its data layer. These are the parts that carry the most risk.

Seat inventory that can’t be sold twice

Vendors upload blocked seats with airline, sector, date, flight, fare, group PNR and name deadline. Each seat is its own database row, locked at the moment of sale, so two agents can never buy the same seat. Abandoned checkouts hand their seats back automatically.

A wallet built like a ledger

Agents pay from a wallet balance or an approved credit line. The ledger is double-entry and append-only, held in whole paise. Money is reserved when a booking starts and debited only when it is confirmed.

Manual credits need two people. The proposer can never approve their own credit, and a payment reference and proof are mandatory.

Passenger names to the airline

Agents enter passenger details, checked against the airline’s name rules. A pluggable driver then sends the names in one of three ways. It can call an API, produce the airline’s name-list file, or let ops upload the confirmation by hand. Each passenger is tracked from pending to confirmed or failed, and every attempt is stored.

Audit and data protection

Each change writes its audit row in the same transaction, and the rows are hash-chained so tampering shows. Database triggers block edits to the audit log. Passport, date-of-birth and contact fields are encrypted at field level, with India’s DPDP Act in mind.

How we worked

We researched before we wrote code. Our survey of public flight APIs found none that accept names against an existing group PNR on a self-service basis. They are built for retail bookings of one to nine passengers. That is why the name push has file and manual fallbacks, so the client can go live without waiting on an API.

When the client supplied a supplier API, we mapped it call by call. It needs names at booking time and offers no hold or cancellation, while the proposal assumed buy now, name later. We raised that early, with two options. Its booking call is also not safe to repeat, so timeouts go to a reconciliation queue instead of an automatic retry.

This is the software consulting side of a custom software build: find the expensive surprises before they are in the code.

Where it stands

In development. Scope, API research, architecture, security design, the database schema and the wallet service are done. The vendor, agent and admin portals, payments and the background worker for name pushes come next.