---
title: "Travel Payment Ownership: Merchant of Record, Seller of Record ve Collect Modelleri"
description: "Merchant of Record, Seller of Record, agency collect, hotel collect ve pay-at-property modellerini booking lifecycle ve reconciliation açısından ayırın."
slug: "travel-payment-ownership-models"
translationKey: "guide-travel-payment-ownership-models"
locale: "tr"
type: "guide"
category: "architecture"
tags: ["travel-distribution","architecture","canonical-model"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-27"
reviewedAt: "2026-09-27"
technicalVerifiedAt: "2026-09-27"
codeExampleStatus: "illustrative"
sources:
  - title: "Expedia Rapid — Booking API"
    url: "https://developers.expediagroup.com/rapid/lodging/booking/about-booking-api"
  - title: "Booking.com Connectivity APIs"
    url: "https://developers.booking.com/connectivity/docs"
  - title: "Stripe for travel and hospitality"
    url: "https://stripe.com/industries/travel"
  - title: "Adyen for travel"
    url: "https://www.adyen.com/industries/travel-mobility"
  - title: "iyzico Marketplace — Submerchant"
    url: "https://docs.iyzico.com/en/products/marketplace/marketplace-implementation/submerchant"
  - title: "PayTR Marketplace Solution"
    url: "https://dev.paytr.com/en/platform-transfer-talebi"
---
Travel booking'de “provider kim?” sorusu payment ownership'ı tek başına cevaplamaz. Seller of Record, Merchant of Record, fulfillment/service owner ve underlying supplier farklı entity'ler olabilir. Bu nedenle ödeme modeli canonical booking state'in parçası olmalıdır.

## Merchant ve seller ayrımı

Seller of Record müşterinin satış sözleşmesindeki satıcı kimliğidir. Merchant of Record payment transaction'ını merchant hesabı üzerinden kabul eden ve chargeback/refund operasyonunda temel payment tarafıdır. Aynı entity olabilirler ama zorunlu değildir.

## Collect modelleri

Agency/platform collect modelinde ödeme platform veya aracı tarafından alınabilir; hotel collect/pay-at-property modelinde tahsilat property tarafından yapılır. Virtual card senaryosunda settlement başka bir payment leg üzerinden ilerleyebilir.

## Booking lifecycle

Booking create sırasında amount, currency, payment timing ve cancellation terms saklanmalıdır. Confirmation sonrası modification/refund payment state'i booking state'ten bağımsız ilerleyebilir.

## Reconciliation

Gross booking value, collected amount, refunded amount, commission ve net settlement ayrı ledger alanları olmalıdır. Duplicate webhook veya unknown payment outcome idempotent reconciliation gerektirir.

## Tasarım kuralı

Platform brand'inden MoR/SoR sonucu çıkarmayın; aktif contract ve booking response semantics'i doğrulayın.


## Travel payment provider context

Payment provider'lar travel inventory source değildir; **payment lifecycle capability** olarak modellenmelidir.

| Provider | Travel/platform bağlamı | Architecture boundary |
|---|---|---|
| Stripe | travel/hospitality checkout, multicurrency, Connect marketplace money movement | payment + payout orchestration |
| Adyen | airline, hotel, OTA, global acquiring, reconciliation | payment/acquiring layer |
| iyzico | Türkiye marketplace submerchant onboarding ve seller settlement | marketplace payment/split context |
| PayTR | Türkiye marketplace payment + transfer akışı | payment + seller/platform transfer context |

Bu provider'lardan hiçbiri marka adıyla otomatik olarak Seller of Record veya Merchant of Record belirlemez. Aktif commercial/legal contract source of truth'tur.

## Marketplace ve travel-seller modeli

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

Ayrı tutulması gereken identity'ler:

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

Payment-provider transaction ID canonical booking identity yapılmamalıdır.

## Türkiye marketplace akışları

iyzico ve PayTR marketplace/submerchant benzeri flow'lar dokümante eder. Türkiye'deki travel platform supplier/seller'lara ödeme dağıtıyorsa yararlıdır; fakat travel platformun legal MoR/SoR rolünü tek başına belirlemez.

## Travel failure modes

- booking confirmed ama payment uncertain,
- payment captured ama supplier booking rejected,
- partial refund ile booking state ayrışması,
- seller/submerchant payout mismatch,
- displayed vs settlement currency FX farkı,
- payout sonrası cancellation,
- duplicate callback/webhook.

## Production checklist

- Seller of Record ve Merchant of Record rollerini contract'tan doğrulayın,
- booking/payment/settlement ID'lerini ayrı tutun,
- collect modelini booking snapshot'ında persist edin,
- refund/chargeback/settlement ledger alanlarını ayırın,
- marketplace/submerchant akışında seller identity'yi koruyun,
- payment-booking reconciliation ve FX drift'i izleyin.

## Observability

Authorization rate, capture rate, refund latency, chargeback rate, payment-vs-booking reconciliation drift, settlement age ve FX mismatch izlenmelidir.