Skip to content
OnArrival

Manage the full travel order lifecycle.

Find travel from many suppliers, book it, handle changes and refunds, and match every payment. Each trip lives in one order, from the first search to the final refund.

A traveller steps off a train onto a harbour platform with a rolling suitcase as a crew member points the way to a waiting ferry, one unbroken route from rail to water.
Product types you can sell
5
Order history per trip
1
Ways to connect
3
In short

One trip, one record, from search to refund.

Every booking becomes an order: a single record that follows the trip through five steps.

Pick a step to see it in detail below

Order lifecycle

Follow one trip, step by step.

Pick a step. See what changes, what the traveller sees and what your team can do.

Order

One confirmation becomes one lasting order.

The payment, each supplier's confirmation and the traveller details join one order. Each supplier's own reference is kept underneath.

What changed
The accepted offer and its terms are saved in the order history.
Behind the scenes
Payment and booking steps run together, with safe retries that never book twice.
Traveller sees
Receives one clear confirmation and reference.
Your team can
Can manage supported actions and escalate cases that need supplier help.
Platform model

Four platform layers
behind each order.

Whichever way you connect, the same four layers do the work. They share the same offer, order, traveller, event, servicing and payment records.

Highlighted: the layers used at the Book step

01 · Experience surfacesWhere people book
Embedded journeyAPIs & SDKsAgent tools
02 · Shared objectsWhat every trip is made of
IntentOfferOrderTravellerEvent
03 · OrchestrationThe steps we coordinate
PricingPolicyConfirmationServicing
04 · Operations & moneyWhere money moves
Supplier railsPaymentsLedgerSettlement
Choose an integration

Three ways to connect.

Use ready-made booking screens, build your own on our APIs, or let an AI agent book through MCP.

MCP (Model Context Protocol) is an open standard that lets AI agents use outside tools. Here, the tools are travel search and booking.

01

Embedded journeys

Drop a complete travel booking flow into your product, styled as yours.

You own
Your brand, where travel appears, your rules and your customer relationship.
OnArrival handles
Search, showing offers, checkout and the travel operations behind them.
Best fit
Teams that want the fastest path to a native-feeling launch.
02

APIs & SDKs

Build your own screens. The same booking records and operations run underneath.

You own
Your screens, your app logic and the parts of the flow that set you apart.
OnArrival handles
Putting supplier data in one format, tracking each booking, handling changes and sending you updates.
Best fit
Teams building their own travel interface.
03

Agent tools · MCP

Let an AI agent search and book through travel tools with clear limits.

You own
The agent experience, its instructions, when a person approves, and user trust.
OnArrival handles
The tool definitions, limited-access keys, a record of every action, and the booking itself.
Best fit
AI products that need travel tools with clear permissions and approvals.
Responsibility boundary

Keep your customer experience.
We run supplier operations.

You decide the look, the rules, the order of results and who approves what. OnArrival handles the suppliers, changes, refunds and payment updates.

Your team controls

The relationship

  • Brand and customer experience
  • Commercial rules and how results are ranked
  • Your customer relationship and your own customer data
  • Private supply contracts you choose to bring
  • When approvals happen and when to escalate
Platform coordinates

The travel state

  • Supplier responses in one shared format
  • Price checks and confirmation status
  • Changes, cancellations and refunds
  • Booking updates and handoffs to your support team
  • Payment movements linked to the trip
Bookable supply

Add product types without changing your order model.

Start with one product, like flights. Add hotels later without rebuilding your rules or your booking updates.

Shared infrastructure

Services used across every order.

Bundles, payments and MCP share the same order and event history as every bookable product.

Evaluation

Test with a real itinerary.

Before you plan a launch, try price changes, supplier failures, cancellations and refunds on a real trip.

01

Map

Pick a real trip and agree who owns each part.

02

Build

Connect one way in (screens, APIs or MCP) to the shared offers and orders.

03

Break

Try price changes, supplier failures and changes to the booking.

04

Plan

Write down what launch needs, who owns it and the rollout steps.

Your itinerary, end to end
Run one itinerary from search through servicing.

Related reading

All field notes →