Adding travel is easy. Owning it is the decision.

Almost every company asking whether it should add travel already knows the answer. Of course you could. Inventory is rentable, the APIs are documented, and a competent team ships search, offers and a confirmation screen inside a quarter. That is not the hard part, and it is not the decision.

The decision is month four. An airline moves a departure by three hours, and the customer opens your app, because your logo is on the confirmation, to ask about the hotel night they can no longer use. Whoever answers owns your travel product. If you cannot name them today, you are not launching a product. You are opening a tab nobody owns and putting your brand on it.

So the question is not “could our customers book travel here?” It is: what becomes meaningfully better because travel lives inside our product? If the answer is only convenience, ship a link and keep the quarter. If it touches identity, rewards, money, policy or a workflow you already run, travel may deserve to become a product.

The five reasons that can justify travel

Most credible strategies begin with one primary reason. One, not three.

1. Make an existing value store more useful. Points stay abstract until someone spends them on a real hotel on a real Tuesday. Travel is the most legible exchange rate a rewards program has.
2. Complete an existing journey. A property marketplace or HR platform already holds the identity, policy and approval chain that travel would otherwise ask the customer to retype.
3. Deepen a financial relationship. Travel is where FX, instalments, insurance and card benefits stop being features and start being the reason the customer reached for your card.
4. Create a commercial surface. Margin works when the model funds servicing, not only booking. A take rate that ignores the refund desk is a forecast, not a business.
5. Serve a distinct segment. Frequent business travellers, students moving abroad, premium members: a first release with a point of view beats one with a catalogue.

If none of these reasons is specific to your business, wait. “Customers travel” is a fact, not a strategy.

The readiness test

Score each dimension red, amber or green. Be unkind: the table is only useful if it can say no.

One red is survivable. Red ownership is not. Without a named person accountable for the whole experience, every other dimension degrades quietly: economics get re-forecast, support absorbs the overflow, and the partner boundary becomes the answer to every hard question.

Read the decision as a sequence of gates, each with an honourable exit. Failing at gate one costs a meeting; discovering the same failure after launch costs the brand.

Choose the smallest honest product

The first release should match the job, not the breadth of a supplier catalogue.

For a rewards program, hotels are usually the most legible redemption surface. For a regional super-app, buses fit the frequency that already exists. For a premium card, flexible flights and protection fit the proposition. For an HR system, policy-aware business travel is the point.

OnArrival exposes individual product primitives for Flights, Hotels, Buses, Experiences, Insurance and Payments, as well as Bundles. Breadth is an option. It should never be the launch requirement.

Referral, embedded or headless?

Your experience ambition decides the model. Every step to the right is also a compliance commitment that outlives whoever chose it.

A referral ships in days and keeps card data, PCI scope and servicing entirely outside your walls. White-label is configuration on the partner's flow, inside the partner's scope. Composable embedding is weeks of work, and because payment stays inside provider surfaces, a card number never touches your servers. Headless means your checkout owns the card fields, which moves you from the lightest PCI self-assessment into real scope with real audits, and it means your team builds the manage-booking surface and then staffs the desk behind it. Price that desk before you choose: one around-the-clock support seat is roughly five people once shifts and leave are counted.

The Embedded travel solution supports the latter paths with composable surfaces and APIs. Choose the lightest model that can deliver the experience you promised: control is only worth its price if the team intends to use it every week. Fintech teams can continue with the more specific guide to embedded travel for fintechs.

Build the business case around completed outcomes

A model built on traffic and conversion is a model of the good week. The lines that decide the answer sit further down:

• Trip frequency and product mix inside the chosen segment
• Margin, rewards subsidy and payment economics
• Cancellation, refund and chargeback exposure
• Support contacts and manual servicing cost
• Supplier or infrastructure terms, and who owns delivery
• Value to the core product, with a way to measure it

The spreadsheet needs at least these lines, and the servicing lines are the ones that quietly get omitted:

gross_margin  = bookings x take_rate + supplier_incentives
payment_cost  = MDR + FX spread + chargebacks + refund processing
servicing     = schedule_changes x cost_per_touch
              + cancellations x refund_handling
              + support_contacts x cost_per_contact
subsidy       = rewards funding + promotional pricing
net           = gross_margin - payment_cost - servicing - subsidy

Run base, low-demand and exception-heavy cases. The exception-heavy case is not paranoia: flights reschedule, weather cancels connections, hotels overbook. Every one of those events lands in the servicing line, and none of them appear in a model that ends at booking commission. Name the strategic effect in advance too. “Engagement” is what a business case says when it has not chosen a driver; retention, premium adoption, card preference, reward redemption and workflow completion are things you can be measurably wrong about.

The post-booking gate

Do not launch until the team can answer one scenario out loud, in a room, with no partner on the call.

A customer booked two trip components. One supplier changed the timing, the customer wants to cancel the other, and a partial refund is due. Ask:

• Where does the customer see the current truth?
• Which actions are self-service?
• How are financial consequences calculated and displayed?
• What context reaches the support team?
• Who contacts the supplier if automation cannot finish?
• How does finance trace the refund?
• What status does the customer see while waiting?

If those answers live in separate partner decks, the product is not ready. The OnArrival platform lifecycle and Payments layer show why the order and money model need to stay connected after checkout, and the post-booking essay makes the longer argument that the period after payment is where a travel product wins or loses trust.

So, should you add travel?

Yes, when travel makes an existing relationship more useful, your company brings a real advantage to the journey, and a named person is ready to own the experience after payment. Then launch to a bounded cohort, instrument the trust moments rather than the clicks, and add the next product because it completes the trip, not because it exists in the API.

Not yet, when the strategy is a category label, the economics stop at commission, or the customer has to cross an unexplained seam the moment something changes.

The travel products that work do not feel bolted on. They feel like a capability the host product was always in a position to provide, and the giveaway is never the search page. It is what the app can say at 3 a.m. when the plan changes. Once the product case is green, use the build-versus-buy framework to decide which responsibilities should stay inside the company.