# Travel Order Lifecycle Platform | OnArrival > Normalize travel supply into offers, turn confirmed offers into orders, service every change and reconcile money on one trip lifecycle. See the whole model. Source: https://www.onarrival.com/platform --- # 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. [Follow the lifecycle](https://www.onarrival.com/platform#lifecycle) [Request sandbox access](https://www.onarrival.com/signup) 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. 1. 01 · Intent**Search** A traveller asks for a trip. Every connected supplier is asked at once. 2. 02 · Offer**Compare** Options from different suppliers are put in one format, so they compare fairly. 3. 03 · Order**Book** One payment and one confirmation create one order. 4. 04 · Service**Change** Delays, cancellations and refunds are handled on that same order. 5. 05 · Settlement**Settle** Every payment and refund is matched back to the trip. 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. LIVING ORDER OA-74K2 Confirmed BOM → DXB Two travellers · one composed trip Outbound flightconfirmed Three-night stayconfirmed Trip protectionattached **Representative trace** Payment approved · booking confirmed OA-74K2 maps to each supplier confirmation. 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. [Flights](https://www.onarrival.com/flights) [Hotels](https://www.onarrival.com/hotels) [Buses](https://www.onarrival.com/buses) [Experiences](https://www.onarrival.com/experiences) [Travel Fintech](https://www.onarrival.com/insurance) Shared infrastructure ## Services used across every order. Bundles, payments and MCP share the same order and event history as every bookable product. [Bundles](https://www.onarrival.com/bundles) [Payments & ledger](https://www.onarrival.com/payments) [MCP for travel](https://www.onarrival.com/solutions/ai) 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. [Request sandbox access](https://www.onarrival.com/signup) [Discuss your integration](https://www.onarrival.com/company#contact) ## Related reading [All field notes →](https://www.onarrival.com/blog) [Technical architecture · 11 min Travel API architecture needs orders, state and recovery Supplier adapters handle API calls. A travel platform also needs a shared booking record, permission checks and recovery when a supplier response is late or unclear. **Pawan Shetty**](https://www.onarrival.com/blog/travel-api-architecture-control-plane) [Product engineering · 11 min The travel order lifecycle: from search to refund settlement A travel order records the offer, confirmation, booking changes and related payments. Keeping that history together makes partial cancellations and delayed refunds easier to handle. **Manan Vaghasiya**](https://www.onarrival.com/blog/travel-order-lifecycle) [Technical architecture · 11 min Why a travel cart needs more than one checkout call Flights, hotels and activities can expire or fail independently during checkout. A travel cart needs price checks, booking recovery and a payment plan for partial success. **Manan Vaghasiya**](https://www.onarrival.com/blog/the-travel-cart-problem) Travel APIs, and the people who run them around the clock. Platform - [Platform overview](https://www.onarrival.com/platform) - [Agentic travel agent](https://www.onarrival.com/agents) - [Flights](https://www.onarrival.com/flights) - [Hotels](https://www.onarrival.com/hotels) - [Buses](https://www.onarrival.com/buses) - [Experiences](https://www.onarrival.com/experiences) - [Travel Fintech](https://www.onarrival.com/insurance) - [Bundles](https://www.onarrival.com/bundles) - [Payments & ledger](https://www.onarrival.com/payments) - [Hotel & Room Mapping](https://www.onarrival.com/mapping) - [Hotel Places Search](https://www.onarrival.com/places) - [Flight Status API](https://www.onarrival.com/flight-status) Solutions - [Travel sellers](https://www.onarrival.com/solutions/travel-sellers) - [Fintech](https://www.onarrival.com/solutions/fintech) - [Enterprises](https://www.onarrival.com/solutions/enterprises) - [Suppliers](https://www.onarrival.com/solutions/suppliers) - [Embedded travel](https://www.onarrival.com/solutions/embedded) - [Corporate travel](https://www.onarrival.com/solutions/corporate) - [Loyalty redemption](https://www.onarrival.com/solutions/loyalty) Company - [About](https://www.onarrival.com/company) - [Blog](https://www.onarrival.com/blog) - [Trust center](https://www.onarrival.com/trust) - [Careers](https://www.onarrival.com/company#careers) - [Press](https://www.onarrival.com/company#press) - [Pricing](https://www.onarrival.com/pricing) - [Contact](https://www.onarrival.com/company#contact) Developers - [Quickstart](https://www.onarrival.com/docs) - [Documentation](https://docs.onarrival.com/) - [MCP server](https://www.onarrival.com/solutions/ai) - [API evaluation checklist](https://www.onarrival.com/resources/travel-api-evaluation-checklist) - [Duffel alternative](https://www.onarrival.com/alternatives/duffel) - [Nuitée / LiteAPI alternative](https://www.onarrival.com/alternatives/nuitee) - [Status preview](https://www.onarrival.com/status) © 2026 OnArrival Travel Technology Private Limited · SOC 2 Type II · PCI · GDPR WeWork Salarpuria Symbiosis, Bannerghatta Road, Arekere, Bengaluru 560076, India [Privacy](https://www.onarrival.com/privacy) [Terms](https://www.onarrival.com/terms) [Security](https://www.onarrival.com/security) [DPA](https://www.onarrival.com/dpa)