Live demo

Client success story

Hubabak success story: a flight storefront tuned for faster purchase decisions

A B2C flight retailer in the Middle East reworked the path its customers take from flight search to payment, so choosing a fare and paying for it feels quicker and clearer.

  • Middle East
  • B2C flight retail
  • Flight retail optimization
  • Launched in 2024

The brief

The Hubabak success story in brief

Hubabak sells flights directly to travellers in the Middle East. For a B2C flight retailer the whole business happens on one short path: a traveller searches, compares fares, picks one, enters passenger details and pays. Every extra step on that path is a chance to lose the sale.

The project, launched in 2024, was a flight retail optimization rather than a new build. Its goal was narrow and practical: help customers make a purchase decision with less effort, from the first search to the payment screen, and show the team where that decision was breaking down.

The storefront is built on the PHPTRAVELS Flights module; the Flight booking software guide covers the same engine from a buyer's point of view.

Project passB2C

From

Search

To

Payment

Client
Hubabak
Industry
B2C flight retail
Region
Middle East
Model
B2C
Scope
Flight retail optimization

Launch

2024

Stack

  • PHP
  • MySQL
  • Duffel API

Where the path broke

Three challenges, mapped onto the booking path

Hubabak named three problems. Each one sat at a different point between search and payment. Pick a challenge to see the stages it touched and the result the team reported.

  1. Flight searchAffected stage
  2. Compare resultsAffected stage
  3. Choose a fareAffected stage
  4. Passenger detailsAffected stage
  5. PaymentAffected stage
  6. ConfirmationAffected stage

Challenge

Heavy comparison friction

Users needed too many steps to finalize route and fare choices.

This is where a flight shopper spends most of their attention. The work focused on letting travellers settle route and fare in fewer moves, without losing the details they need to decide.

Reported result

User journey

Faster decision path

Challenge

Checkout confidence gaps

The payment transition lacked clear reassurance for completion.

A traveller who has chosen a fare can still stop at the moment of paying. The aim was a checkout that restates what is being bought and makes the last step feel safe to complete.

Reported result

Purchase confidence

Cleaner checkout feel

Challenge

Limited behaviour insight

Teams needed better visibility into where users exited.

This challenge runs across every stage. Without a clear view of exits, the team could not tell whether customers were leaving at comparison, at checkout or somewhere in between.

Reported result

Optimization signals

Sharper funnel insight

The deciding screens

Two screens that carry a flight purchase

Most B2C flight sales are won or lost on the fare comparison and on the checkout. These annotated sketches show what a tuned version of each screen puts in front of the traveller.

  1. One row per fare, key facts firstTimes, stops and price sit in the same place on every row, so the eye does not have to hunt.
  2. Labels that explain the differenceShort tags say why one fare differs from the next, which cuts the back-and-forth between results.
  3. One clear action per fareA single select button moves the traveller forward instead of opening another layer of choices.
  1. The trip, restated before paymentRoute, travellers and fare are repeated on the payment screen, so nobody pays while unsure what they chose.
  2. One clear totalThe amount to pay is shown once and stands out, right above the action that charges it.
  3. A visible next stepA short line explains what follows the payment, which removes the last reason to hesitate.
ResultsBest match first
  • Best matchBag includedSelect
  • DirectSelect
  • Flexible fareBag includedSelect
Every fare reads the same way, so travellers compare like with like.
Review and payLast step
Trip
Travellers
Fare
Total to pay
Pay and confirm

After payment, the traveller is told what happens next and where the booking confirmation will arrive.

Illustrative sketches of the screen patterns, not captures of the Hubabak website.

Exit signals

Seeing where travellers leave

The third challenge was not on any screen: the team could not see clearly where customers left the path. Following each session stage by stage turns that into questions with answers.

  • Which stage do travellers reach before they leave?
  • Are customers dropping at the comparison, or after they have chosen a fare?
  • After a screen is reworked, does the exit point move?

trace --path search..payment

# session that books

  1. 01search_submittedOK
  2. 02results_viewedOK
  3. 03fare_selectedOK
  4. 04passenger_detailsOK
  5. 05payment_startedOK
  6. 06booking_confirmedOK

# session that leaves at payment

  1. 01search_submittedOK
  2. 02results_viewedOK
  3. 03fare_selectedOK
  4. 04passenger_detailsOK
  5. 05payment_startedEXIT

> exit point: payment_started, the first stage to review

Illustrative session trace; the event names show the idea, not Hubabak's data.

Results

What changed, in the team's own words

Hubabak reported three results, one for each challenge. They are stated as the team stated them, without invented figures.

HB-01User journeyFaster decision pathReported
HB-02Purchase confidenceCleaner checkout feelReported
HB-03Optimization signalsSharper funnel insightReported

Our storefront now feels faster and clearer for customers booking flights.

Hubabak TeamProduct team

Under the storefront

The stack behind the Hubabak storefront

The storefront sits on three layers: the PHPTRAVELS application in PHP, a MySQL database, and flight content through the Duffel API integration. It is the same self-hosted base covered on the Online travel agencies page, with the source code included under a commercial licence.

  1. Storefront and booking logicSearch, fare comparison, passenger details and checkout, served by the PHPTRAVELS application.PHP
  2. DataCustomers, bookings and settings stored in MySQL.MySQL
  3. Flight contentFlight offers and bookings through the Duffel API connection.Duffel API

Improve your flight storefront

Design a cleaner booking path for your B2C channel. See the flight storefront in a live demo, then compare the one-time plans.

Book a demoSee pricing

More on flight retail

FAQ

Questions about the Hubabak project

Short answers about the client, the work and how to run a similar flight storefront.

Talk to sales

Hubabak is a B2C flight retailer in the Middle East that sells flights directly to travellers. Its storefront runs on PHPTRAVELS and the project described here launched in 2024.

Three things: comparison friction, because customers needed too many steps to settle route and fare; checkout confidence, because the move to payment lacked reassurance; and limited insight into where customers left the booking path.

A faster decision path for the user journey, a cleaner checkout feel for purchase confidence, and sharper funnel insight for optimization. The client described the results in these terms and did not publish figures, so this page does not add any.

PHP and MySQL for the PHPTRAVELS application and its data, with the Duffel API providing flight content.

No. The fare comparison, checkout and session trace are illustrative sketches of the patterns behind the work. They are not captures of the live site or of Hubabak's data.

Yes. The PHPTRAVELS flights module powers B2C flight sales on a self-hosted platform, with the source code included under a commercial licence. Book a demo to walk through the booking path, or see the one-time plans on the pricing page.

Keep exploring

More from the platform