Merchant of Record
Müşteri ödemesini kendi merchant hesabı üzerinden kabul eden, işlem kayıtları ve chargeback/refund sorumluluğunda temel taraf olan entity'dir.
Neden önemli?
Transaction kavramları metasearch click'inin downstream booking experience'e nasıl dönüştüğünü açıklar. Context-preserving deeplink, stable click ID, booking lifecycle ve reconciliation birlikte tasarlanmazsa search performansı ile gerçek ticari sonuç arasında kopukluk oluşur.
Pratikte nasıl görünür?
Metasearch'te click_id deep link ile provider'a taşınır, booking event ile geri gelir ve cancellation/stay state'leriyle reconcile edilir. Bu zincir koparsa commercial attribution eksik kalır.
Uygulamada sorulması gerekenler
- Search context landing'e eksiksiz taşınıyor mu?
- Click/booking arasında durable ID var mı?
- Booking lifecycle event'leri idempotent mi?
- Provider sonucu ile internal state reconcile ediliyor mu?
Yaygın hatalar
- Generic landing page'i başarılı handoff saymak
- Unknown booking state'i failed kabul etmek
- Duplicate conversion event'i iki kez revenue yazmak
Travel stack içinde nerede kullanılır?
Merchant of Record, çoğunlukla transaction katmanlarıyla ilişkilidir. İlgili sistemlerde source-of-truth, identity, freshness ve transaction ownership sınırlarını açık tanımlamak gerekir.
İlgili terimler
İlgili teknik içerikler
Travel Payment Ownership: Merchant of Record, Seller of Record ve Collect Modelleri
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.
İncele →Travel PII ve Passenger Data Boundaries
Passenger PII, identity, contact, payment ve travel document verisini search, booking, logging ve provider entegrasyonlarında güvenli sınırlarla modelleyin.
İncele →Travelport Historical Context: Galileo, Apollo ve Worldspan
Galileo (1G), Apollo (1V) ve Worldspan (1P) kimliklerinin Travelport entegrasyonlarında provider identity ve historical GDS context olarak neden hâlâ önemli olduğunu anlayın.
İncele →Canonical Hotel Entity Model
Birden fazla supplier'dan gelen property kayıtlarını tek canonical hotel entity altında birleştiren identity, alias, lineage ve merge modelini tasarlayın.
İncele →Cloudbeds API Entegrasyon Rehberi
Scoped credential, property identity, reservation sync, rate-limit kontrolü ve reconciliation kullanan production Cloudbeds PMS entegrasyonu.
İncele →Duplicate Property Detection Playbook
Aynı hotelin birden fazla canonical kayıt altında yaşamasını name, geo, address ve provider mapping sinyalleriyle tespit edin.
İncele →