Travel Payment Ownership: Merchant of Record, Seller of Record and Collect Models

In travel booking, “who is the provider?” does not by itself answer payment ownership. Seller of Record, Merchant of Record, fulfillment owner and underlying supplier can be different entities, so the payment model belongs in canonical booking state.

Merchant and seller distinction

Seller of Record is the contractual seller to the traveler. Merchant of Record accepts the payment through its merchant account and carries core payment-record, chargeback and refund responsibility. They may be the same entity but do not have to be.

Collect models

In agency/platform collect, payment may be collected by the intermediary; in hotel collect or pay-at-property, collection occurs at the property. Virtual-card settlement can introduce another payment leg.

Booking lifecycle

Persist amount, currency, payment timing and cancellation terms at booking creation. Modification and refund payment state can evolve independently from reservation state.

Reconciliation

Gross booking value, collected amount, refunded amount, commission and net settlement should be separate ledger fields. Duplicate webhooks and unknown payment outcomes require idempotent reconciliation.

Design rule

Never infer MoR/SoR from the platform brand alone; verify the active contract and booking-response semantics.

Payment-provider context in travel

Payment providers should be modeled by payment lifecycle capability, not as travel inventory sources.

None of these providers determines who is the contractual Seller of Record or Merchant of Record by brand name alone. The active commercial/legal contract still controls that answer.

Marketplace and travel-seller modeling

A travel marketplace can have:

Traveler
 -> Travel seller / OTA
 -> Payment provider
 -> Submerchant / hotel / supplier
 -> Settlement

Keep these identifiers separate:

• booking ID,
• payment intent/transaction ID,
• traveler charge,
• seller/submerchant ID,
• supplier settlement ID,
• refund/chargeback ID.

Do not use a payment-provider transaction ID as the canonical booking identity.

Turkey-specific marketplace flows

iyzico and PayTR both document marketplace/submerchant-style flows. These are useful when a Turkish travel platform collects payment and later distributes money to sellers/suppliers, but they do not automatically define the travel platform's legal MoR/SoR role.

Travel failure modes

• booking confirmed but payment uncertain,
• payment captured but supplier booking rejected,
• partial refund without booking-state update,
• seller/submerchant payout mismatch,
• FX difference between displayed and settled currency,
• cancellation after payout,
• duplicate callback/webhook processing.

Production checklist

• verify Seller of Record and Merchant of Record from active contracts,
• keep booking/payment/settlement identifiers separate,
• persist collect model in the booking snapshot,
• separate refund/chargeback/settlement ledger fields,
• preserve seller identity in marketplace/submerchant flows,
• monitor payment-booking reconciliation and FX drift.

Observability

Track authorization rate, capture rate, refund latency, chargeback rate, payment-vs-booking reconciliation drift, settlement age and currency/FX mismatches.