Merchant Model
A commercial model where the intermediary charges the traveler and settles a contracted or net amount with the supplier.
Why it matters
This concept affects how travel supply moves between systems and which state can be trusted during search. Distribution data needs more than a valid payload: it needs context, freshness and clear ownership. The same term may exist at supplier, channel-manager, OTA and metasearch layers with different semantics, so careless abstraction creates hard-to-debug mismatches.
What does it look like in practice?
A hotel rate update moving from supplier through connectivity into an OTA or metasearch should preserve entity identity, source timestamp, restrictions and version state. HTTP success alone does not prove downstream distribution state is current.
Implementation questions
- Which system is the source of truth?
- Which identifiers and versions must be preserved?
- Does state arrive by push, pull or event?
- How is stale or incomplete state detected?
Common mistakes
- Treating provider IDs as canonical IDs
- Equating HTTP success with business-state success
- Mixing full and delta update semantics
Where does it appear in the travel stack?
Merchant Model commonly appears across distribution layers. Its implementation should make source-of-truth, identity, freshness and transaction-ownership boundaries explicit.
Related terms
Related technical guides
Travel Payment Ownership: Merchant of Record, Seller of Record and Collect Models
Separate Merchant of Record, Seller of Record, agency collect, hotel collect and pay-at-property models across booking and reconciliation.
Explore →NDC Offer/Order Lifecycle: Search to Servicing
Model NDC Offer/Order lifecycle across search, offer, revalidation, order creation, payment, ticketing, servicing and reconciliation states.
Explore →Payment + Booking Distributed Transaction
Model payment and supplier booking as a distributed transaction using authorization, capture, compensation, UNKNOWN outcomes and reconciliation.
Explore →Canonical Offer, Order and Booking State Model
Design canonical Offer, Order and Booking lifecycle boundaries with an explicit booking state machine for travel integrations.
Explore →Travel Observability, Trace and Correlation Model
Trace travel transactions from search through booking and servicing using correlation IDs, distributed traces, metrics and structured domain events.
Explore →Travel Servicing Architecture
Model post-booking change, cancellation, refund, exchange, ancillary and schedule-change workflows with a canonical servicing architecture.
Explore →