Project context
In flight sales, any gap between the price shown and the payment flow is direct financial and legal risk: a different fare issued than selected, a ticket issued after a declined payment, or a service shown in the basket but never charged.
The goal was an OTA on live GDS data where what is shown equals what is charged at every step and no ticket is issued without an approved payment.
Architecture and data flow
- Search: a provider factory selects the live GDS provider by configuration; AirSearch results map to a common flight model.
- Fares: each flight's branded fares are listed with baggage, refund and change rules.
- Booking: Allocate, UpdatePassengers and MakePrebooking reserve seats, store passengers and return real installment options.
- Payment: 3D Secure starts and the customer approves on the bank page.
- Ticket: if the return is approved, FinalizeShopping issues the ticket, the booking is stored locally and notifications are sent.
Engineering challenges and solutions
3D Secure approval gate
Ticketing could run regardless of the 3D result. A fail-safe gate now sits before ticketing: unless the return parameters are explicitly approved, no ticket is issued, the pending payment is marked failed and the GDS reservation is released with RemoveProduct.
Issuing the right fare
The selected branded fare is matched to the issued fare by its fare ID. A fallback that dropped to the cheapest fare when the ID was empty was found and removed; matching is now exact on the brand ID, and baggage, refund and change rules are read from the real XML policies.
Shown equals charged
Agency margin and ancillaries are declared to the GDS as a service fee, so the prebooking total and the 3D charge equal the basket total. Margin is calculated with prioritized markup rules by domestic, international and cabin class.
Look-to-book tracking
The GDS counts every search call. The admin search-to-ticket ratio now counts round-trip searches as two calls, and homepage deal cards are fed from past searches instead of live API calls to protect the ratio.
The resulting system
The site searches a live GDS, shows branded fares with real rules, charges via 3D Secure with real bank installments and issues tickets automatically. In the admin panel, refunds are wired to the GDS two-step refund service, and pending 3D payments, price alerts, notifications, commission and profitability reports have their own screens.
Technology stack
Related product and service
Go to the product page: ucakbiletcisi.com
Frequently asked questions
Which GDS does it use?
The BiletBank Trevoo WS SOAP service for search, booking, payment, ticketing and refunds.
What happens if a payment is declined?
Unless the 3D return is explicitly approved, no ticket is issued, the payment is marked failed and the GDS reservation is released automatically.
Can you build a similar OTA site?
Yes. The flight booking website development page describes scope and process.