Flight booking, built into a financial institution's own app.
A financial institution can sell flights to its customers without building a travel stack: by joining an open commerce network as a buyer app with the payments fintech as its Technology Service Provider. We designed the full flow, from search to seat to pay, that plugs into the network's open travel supply. To prove it whitelabels to any partner, we themed the entire booking journey into a real client's identity (a private financial institution). Same flow, the client's brand.
A flight store inside a financial institution's app.
The customer opens their financial institution's app and books a flight without ever leaving it. The institution gets a new, high-engagement service. Neither of them touches an airline integration. That's what the open commerce network and the TSP model make possible.
Book in the enterprise's app
Search, pick a seat, and pay for a flight inside the app they already trust (no third-party redirect).
A new service, no travel stack
The enterprise becomes a buyer app on the open commerce network and offers flights as a value-added service, with the payments fintech supplying the tech.
Powered by the network
Open travel supply: many airline sellers reachable through one network, not one-by-one tie-ups.
An open network, and a role in it.
An open commerce network is not an app itself, but a set of open protocols that let any buyer app transact with any seller app, across categories. It defines four roles: Buyer and Seller network participants, a Gateway that matches them, and Technology Service Providers who supply the software. Travel is one of its newer categories.
The customer searches and books here. The payments fintech builds it as the client's TSP.
Broadcasts the search across the network and matches buyer to sellers.
Airlines & travel sellers return fares, seats, and rules.
Confirmed back in the client's app; the payments fintech PG settles the money.
the payments fintech is the client's Technology Service Provider
The TSP model lets enterprises with a big customer base (financial institutions, fintechs, telcos) join the open commerce network as a buyer app without in-house commerce tech. The client owns the customer and the brand; the payments fintech supplies the buyer-app software, the booking UX, and the payment rail. This work was designed and delivered with the network.
Travel is a great service to offer, and a hard one to build.
Flights are high-intent, high-frequency, and keep customers inside the app. But a financial institution can't reasonably build airline integrations, fare engines, seat maps, and cancellation rules. And even with the open commerce network opening the supply, the network gives you a protocol, not a product.
- No travel stack: financial institutions have no airline tie-ups, fare search, or seat/meal inventory.
- Booking is a long, stateful flow: search, fare rules, travellers, seats, add-ons, payment, cancellation, each with edge cases.
- The network is a protocol, not a UI: it returns data; someone still has to design the experience that makes it bookable.
- It has to feel like the client: as a TSP build, the flow must wear the client's identity, not a vendor's.
What the booking flow had to do.
Ride the open network's supply
Pull fares and seats from many sellers through one network instead of building integrations.
Search → seat → pay, end to end
A full, stateful booking flow with fares, travellers, seats, add-ons, and cancellation rules.
Themeable for the client
One flow that re-skins from the client's identity to the payments fintech design system.
Wireframe → visual design, and a whitelabel proof
The flow was shaped first as wireframes themed into a real client's identity (a private financial institution), to prove a point: as a TSP build, the same booking journey can wear any partner's brand. Those wireframes were then elevated into the payments fintech design system. The before/after pairs below carry both threads at once: the surface lifting from wireframe to VD, and the brand shifting from a client's identity to the payments fintech base.
Start with where and when.
The entry point: trip type (one-way / round-trip / multi-city), From and To, dates, and travellers with cabin class. Airport pick offers recent and popular routes; the date picker is built to carry fares; traveller selection covers adults, children, infants, and class in one panel.
Click to zoom
The wireframe sits in the client's chrome. It already introduces persona fare chips (Student, Armed Forces, Senior Citizen, Doctors).
Click to zoom
The visual design lifts it into a single, calm search bar against a world-map hero: the four inputs as one connected control.
Click to zoom
Airport search leads with recent and popular routes. Most trips are picked, not typed.
Click to zoom
Adults, children, infants and cabin class resolve in one stepper panel, not a separate page.
Click to zoom
251 flights, made decidable.
The results screen turns network supply into a choice: filters for stops, baggage, price, and departure time; a fare-aware date strip that surfaces the cheapest day at a glance; and a sticky total that always shows the price you'll pay, with savings called out.
Click to zoom
The wireframe nails the information: filter rail, fare-by-day tabs, and dense flight rows in the client's frame.
Click to zoom
The VD gives the fare strip real weight (cheapest day in green) and pins a savings-aware total to the bottom.
The fare rules, before the form.
Once a flight is chosen, the review step confirms the itinerary, then does something most booking flows bury: it shows the cancellation refund as a timeline (how much you get back, and how that shrinks as departure nears). Then the traveller form, contact, and GST, with a live fare summary alongside.
Click to zoom
The wireframe already carries the cancellation-and-date-change band and a coupons block in the client frame.
Click to zoom
The VD turns the refund policy into a green→red gradient timeline: the fine print becomes a single glance.
Pick the seat, see the price.
Add-ons are their own step: a seat map colour-coded by class and price (Free, Premium, Standard, XL), per-traveller assignment, and a Meals tab, with the fare summary updating live as seats are chosen. Upsells (extra legroom, priority boarding) ride the same map.
Click to zoom
The wireframe maps the seat grid, the class-based pricing, an urgency nudge, and a seller upsell (SpiceMax).
Click to zoom
The VD draws the seat map into the fuselage, colour-codes by price band, and tracks each traveller's seat against a live total.
Click to zoom
Close it on the client's own rail.
The journey ends where the payments fintech is strongest: the payment gateway. Saved options, UPI, card, online transfer, wallets, EMI; card instant discounts surfaced inline; coupons applied against the same fare summary that's followed the customer the whole way.
Click to zoom
The calls that made it bookable.
Fares on the calendar, not behind it
Price drives flight choice more than time does. The results date strip shows a fare under every day and greens the cheapest, so the cheapest-day decision happens before the user even scans the list.
Cancellation as a timeline, not fine print
Refund rules are where booking trust is won or lost. Rendering them as a green→red gradient (how much comes back, and when it drops) turns a buried policy into a glance, before the customer commits.
The fare summary never leaves
A sticky total with strikethrough savings follows every step: results, review, seats, payment. The price you'll pay is always one glance away, so add-ons never feel like a trap.
Persona fares, surfaced early
The open network's supply means many seller offers: Student, Armed Forces, Senior Citizen, Doctors. Putting those fare chips on the search screen makes the network's breadth a benefit the customer sees up front.
One flow, any client's skin
Because this is a TSP build, the flow has to be the client's, not a payments fintech's. Theming the whole journey into a private financial institution's identity was a deliberate proof of whitelabel capability: the same booking logic re-skins from a partner's brand to the payments fintech base with no change to the flow. That's the pitch to the next client.
One buyer app, many clients, and beyond flights.
The TSP-plus-open-network model is the leverage. The booking experience is built once and themed per client; the supply comes from the network, not from integrations. The same pattern extends to any enterprise that wants to become a buyer app. And because the network is multi-category, it reaches beyond travel too.
Re-skin, don't rebuild
Theme the same flow to each partner's identity: the wireframe-to-VD shift proves the seam.
Supply from the network
New sellers on the network appear without new integrations on our side.
Beyond flights
The same buyer-app role applies to other network categories as they mature.
What was delivered.
An end-to-end flight-booking experience for a financial institution's buyer app on the open commerce network, designed from wireframe through visual design, built as the client's Technology Service Provider, with the network.
- A complete booking flow: search, results, review, seats & meals, and payment, designed as one journey.
- Financial institution as buyer app on the open commerce network, the payments fintech as TSP: the enterprise offers flights with no travel stack of its own.
- Whitelabel proven: the journey themed into a private financial institution's identity to show it wears any client's brand, then lifted from wireframe into the payments fintech design system.
- Delivered with the open commerce network: the experience plugs into the open travel network and its seller supply.
Where it goes next.
Round-trip & multi-city
Carry the same fare-aware, sticky-total model into return and multi-leg journeys.
Post-booking
Web check-in, cancellation, and rebooking (using the refund timeline already designed).
More of the network
Hotels and the rest of travel as the network's categories open up.
One honest learning.
An open network solves supply, not experience. The network made the flights reachable, but none of it is bookable until someone designs the fare discovery, the seat map, the cancellation clarity, and the running total. The TSP's real job isn't the protocol: it's turning a protocol into something a person can confidently buy a flight on.