Çok Satıcılı Pazar Yeri Geliştirme: Eksiksiz Teknik Rehber

Çok satıcılı bir pazar yeri inşa etmek, yazılım geliştirme alanındaki en teknik açıdan zorlu projelerden biridir. Bunun nedeni herhangi bir tek bileşenin imkânsız olması değil, her bileşenin diğer tüm bileşenlerle kesişmesi ve standart bir e-ticaret geliştirmesinin hiç karşılaşmak zorunda kalmadığı şekillerde hata modlarının birikmesidir.

Geleneksel bir çevrimiçi mağazanın tek bir satıcısı, tek bir ürün kataloğu, tek bir sipariş karşılama operasyonu ve ödeme yapılacak tek bir banka hesabı vardır. Mimari bu basitliği yansıtır. Buna karşın çok satıcılı bir pazar yeri, tek bir ortak altyapı üzerinde onlarca — sonunda binlerce — paralel işletme yürütmektedir; her birinin kendi ürünleri, fiyatları, stok düzeyleri, sipariş karşılama yöntemleri, ödeme hesapları, performans geçmişleri ve uyumluluk yükümlülükleri bulunmaktadır. Platform operatörü, işlemi paraya çevirerek, kuralları uygulayarak ve bir şeyler ters gittiğinde tüm riski üstlenerek satıcılar ile alıcılar arasında yer almaktadır.

Moda ikinci el satışı, özel gıda ve içecek, B2B endüstriyel malzeme temini ve hizmet pazar yerleri dahil olmak üzere çeşitli sektörlerde pazar yeri platformları geliştirdik. Aşağıdakiler, bu platformların gerçekte nasıl inşa edildiğine dair dürüst ve teknik açıdan ayrıntılı bir değerlendirmedir — önemli olan kararlar, kaçınılmaz olan ödünleşimler ve tasarım aşamasında hafife alındığında sizi zor durumda bırakacak konular.

---

Çok Satıcılı Mimarinin Temel Zorlukları

Tek bir satır kod yazmadan önce, çok satıcılı platformların tek satıcılı uygulamalardan kategorik olarak neyin farklılaştırdığını netleştirmek faydalıdır.

Satıcılar Arasında Veri İzolasyonu

Platformunuzdaki her satıcı, çatınız altında faaliyet gösteren ayrı bir işletmedir. Ürünleri, sipariş geçmişleri, ödeme kayıtları, müşteri iletişimleri ve performans verileri birbirinden yalıtılmış olmalıdır. Bir satıcı, ne kullanıcı arayüzü ne de API aracılığıyla başka bir satıcının satış hacmini, müşteri verilerini veya fiyatlandırma stratejisini görememelidir.

Bu kulağa basit gelir, ancak hızla incelikli bir hal alır. Bir alıcı üç farklı satıcının ürünlerini içeren tek bir sipariş verdiğinde, sisteminizde üç ayrı sipariş karşılama kaydına, üç ayrı ödeme hesaplamasına ve üç ayrı iletişim akışına bölünmesi gereken tek bir sipariş oluşur — alıcının bakış açısından ise tek bir tutarlı sipariş olarak kalır. Veritabanı şemanız, API tasarımınız ve etkinlik sisteminizin bu ikiliği en başından itibaren karşılaması gerekir; çünkü bunu sonradan uyarlamak son derece masraflıdır.

İşlem Düzeyinde Ödeme Bölüştürme

Alıcıdan alınan paranın tek bir banka hesabına girip manüel olarak yeniden dağıtılması mümkün değildir. Anlamlı bir hacimde bu süreç operasyonel olarak çöker, düzenleyici risk yaratır (birçok yargı bölgesinin finansal düzenlemeleri kapsamında bir ödeme aracısı haline gelirsiniz) ve satıcılar için kabul edilemez gecikmeler yaratır. Doğru model, pazar yeri ödeme akışlarını yerel olarak destekleyen bir ödeme sağlayıcısı kullanmaktır — fonların toplandığı, ücretlerin alındığı ve satıcı ödemelerinin tek bir otomatik işlemin parçası olarak gönderildiği bir yapı. Aşağıdaki ödemeler bölümünde belirli araçları ve ödünleşimleri ele alıyoruz.

Yabancılar Arasında Güven

Markanın bilindiği tek satıcılı bir mağazanın aksine, bir pazar yeri alıcının daha önce hiç karşılaşmadığı satıcılara ev sahipliği yapar. Platform, belki de yalnızca birkaç gün önce kabul ettiği satıcılar adına güven tesis etmek zorundadır. Bu, güvenilir bir değerlendirme sistemi, görünür satıcı performans verileri, alıcı koruma güvenceleri ve alıcıların adil olduğuna güveneceği bir anlaşmazlık çözüm sürecini gerektirir. Bunların tümünün lansmandan önce tasarlanıp inşa edilmesi gerekir; çünkü güven altyapısı olmadan bir pazar yeri başlatmak, alıcıların hemen terk edeceği bir platform başlatmak demektir.

Ölçekte İçerik Denetimi

Kataloğunuz tek bir satıcının ürünlerini içerdiğinde, her SKU'yu yayına girmeden önce gözden geçirirsiniz. Kataloğunuz beş yüz satıcının ürünlerini içerdiğinde bunu manüel olarak yapamazsınız. Otomatik içerik taraması, politika uygulama araçları, satıcı uyumluluk puanlaması ve eskalasyon iş akışlarının bir kombinasyonuna ihtiyaç duyarsınız. Denetim sorunu yalnızca bir içerik sorunu değildir — aynı zamanda hukuki bir sorundur. Birçok yargı bölgesinde, özellikle ürün güvenliği, sahte mallar ve yasak kalemler konusunda platform operatörleri, kendi platformları aracılığıyla satılan ürünler için kısmi sorumluluk taşımaktadır.

---

Satıcı Kabul Süreci ve Doğrulama

Satıcı kabul sürecinizin kalitesi, pazar yerinizin kalitesini belirler. Hileli, düşük kaliteli veya uyumsuz satıcılar — katalogunuza yerleştikten ve kendilerine bağlı sipariş geçmişleri oluştuktan sonra çıkarılması son derece güçtür. Yanlış satıcıyı kabul etmenin maliyeti neredeyse her zaman daha titiz bir kabul sürecinin maliyetinden yüksektir.

Müşterinizi Tanıyın — İşletme (KYB) Gereksinimleri

KYB, Müşterini Tanı (KYC) sürecinin işletme karşılığıdır. Bir satıcı ürün listeleyebilmeden veya ödeme alabilmeden önce, gerçekte kiminle sözleşme yaptığınızı doğrulamanız gerekir. Asgari geçerli KYB süreci şunları toplar:

• Yasal işletme adı ve kayıt numarası
• Tescilli işletme adresi
• Yönetici veya serbest tüccar kimliği (resmi fotoğraflı kimlik belgesi ve adres kanıtı)
• Geçerliyse KDV kayıt numarası
• Ödemeler için banka hesabı bilgileri

Pratikte bu belgeleri büyük ölçekte toplamak, bir doğrulama sağlayıcısıyla entegrasyon gerektirir. Belge doğrulaması için en sık Stripe Identity, Onfido veya Veriff kullanıyoruz; sonuçlar kendi sistemlerinizde depolanmak yerine satıcı onay iş akışınıza beslenmektedir. Bu yaklaşım, hassas belge verilerini altyapınızın dışında tutar ve uyumluluk yükümlülüklerinizi basitleştirir.

Ödeme Hesabı Kurulumu

Ödeme hesabı kurulumu, ödeme sağlayıcınızla sıkı sıkıya bağlantılıdır. Stripe Connect ile satıcılar, Stripe'ın kendi kabul sürecinden geçer — platformunuz onları, bankacılık ve kimlik bilgilerini doğrudan toplayan ve doğrulayan Stripe tarafından barındırılan bir akışa yönlendirir. Platformunuz ham hesap kimlik bilgilerini hiçbir zaman işlemez. Ödünleşim, deneyim üzerinde daha az kontrol sahibi olmanızdır; ancak uyumluluk yükü önemli ölçüde azalır.

Satıcı deneyimi üzerinde daha fazla kontrol gerektiren platformlar için özel Stripe Connect hesapları, Stripe'ın temel uyumluluğu yönetmesini sağlarken kendi kabul kullanıcı arayüzünüzü oluşturmanıza olanak tanır. Bu yaklaşım, platformunuzun Stripe API aracılığıyla gerekli tüm bilgileri toplayıp iletmesini gerektirir; bu da platformunuzun daha fazla hassas veri işlediği ve daha büyük uyumluluk sorumluluğu taşıdığı anlamına gelir.

Onay İş Akışları ve Aşamalı Güven

Tüm satıcı başvuruları aynı şekilde değerlendirilmemelidir. En az üç düzeyden oluşan katmanlı bir güven modeli öneriyoruz:

Güven Düzeyi	Gereksinimler	Platform Erişimi
Beklemede	Başvuru gönderildi	Listeleme yeteneği yok
Geçici	KYB onaylandı, ilk listeleme incelendi	Sınırlı listeleme, manüel ödeme incelemesi
Doğrulanmış	Olumlu sipariş geçmişi, tam KYB	Tam erişim, otomatik ödemeler
Güvenilir	Sürdürülen performans metrikleri	Yükseltilmiş arama sıralaması, tanıtım araçları

Geçiciden doğrulanmış statüye geçiş, belirlenen eşikler karşılandığında otomatik olmalıdır — genellikle açık anlaşmazlık bulunmadan ve tanımlı bir taban üzerinde bir inceleme puanıyla tamamlanan asgari sipariş sayısının ardından. Otomatik geçiş, platform büyüdükçe yönetim yükünüzü azaltır ve satıcılara daha fazla platform ayrıcalığına giden açık ve nesnel bir yol sunar.

---

Komisyon ve Ücret Yapıları

Satıcıları platformunuza erişim için nasıl ücretlendirdiğiniz, önemli teknik çıkarımları olan temel bir iş modeli kararıdır. Komisyon motoru, doğru kurulması en karmaşık bileşenlerden biridir; çünkü mevcut ücret yapınıza uyum sağlarken iş modeliniz olgunlaştıkça gelişecek kadar esnek olması gerekir.

Yaygın Ücret Modelleri

Sabit yüzde komisyon en basit modeldir: platform, kategori, satıcı kademesi veya hacimden bağımsız olarak her işlemden sabit bir yüzde alır. Satıcılara açıklaması kolaydır ve uygulaması basittir; ancak önemli gelir optimizasyon fırsatlarını değerlendirememekte ve satıcıların platformunuzdaki hacmi artırması için herhangi bir teşvik sunmamaktadır.

Kategoriye dayalı komisyon, ürün kategorisine göre farklı yüzdeler belirler — genellikle platformun güçlü talep yaratma gücüne sahip olduğu kategorilerde daha yüksek marjlar, satıcıların alternatiflere sahip olduğu rekabetçi kategorilerde daha düşük marjlar. Bir elektronik pazar yeri, telefonlarda %8, aksesuarlarda %15 ücret alabilir. Bunu uygulamak, komisyon motorunuzun sipariş anında ürün kategorisi hiyerarşisini değerlendirmesini ve doğru oranı uygulamasını gerektirir.

Kademeli hacim komisyonu, satıcının belirli bir dönem içindeki brüt ticaret hacmi (GMV) arttıkça alınan pay oranını düşürür. Bu, yüksek performanslı satıcıları ödüllendirir ve güçlü bir elde tutma teşviki yaratır. Teknik olarak, komisyon motorunuzun satıcı başına kümülatif bir GMV toplamı tutmasını, her işlem noktasında hangi kademenin geçerli olduğunu değerlendirmesini ve bir satıcı kademeler arasında geçiş yaptığında yeniden hesaplamasını gerektirir.

Abonelik artı işlem modeli, platform erişimi için aylık veya yıllık bir ücret alırken indirimli bir işlem başına yüzde uygular. Bu model, platform için gelir öngörülebilirliğini artırır ve ölçekte tam komisyon oranları ödemekten kaçınan yüksek hacimli satıcılar için sürtüşmeyi azaltır. Abonelik bileşeni, pazar yeri ödeme akışınızdan ayrı bir yinelenen faturalandırma entegrasyonu gerektirir.

Tanıtım listeleme ücretleri, satıcıların arama sonuçlarında veya kategori açılış sayfalarında üst sıralarda görünmesi için ücret talep eder. Bu, olgun pazar yerleri için önemli bir ikincil gelir akışıdır ve satıcı panelinize yerleştirilmiş bir teklif verme veya sabit oranlı sistem gerektirir.

Esnek Bir Komisyon Motoru Tasarlamak

Hangi modelle başlarsanız başlayın, komisyon motorunuz sabit kodlanmış bir hesaplama yerine bir kural motoru olarak tasarlanmalıdır. Motor en azından şunları yapabilmelidir:

• Bir işlemi girdi olarak kabul etmek (tutar, kategori, satıcı kimliği, ürün kimlikleri)
• İşleme karşı önceliklendirilmiş bir kural kümesini değerlendirmek
• Bir ücret dökümü döndürmek (platform komisyonu, ödeme işlem ücreti, ücretler üzerindeki KDV, net satıcı ödemesi)
• Denetim amaçlı olarak uygulanan tam kural kümesiyle birlikte her hesabı kaydetmek

Komisyon motorlarını kendi ücret kuralları veritabanı tablosuyla ayrı bir servis olarak uyguluyoruz. Kurallar değiştiğinde — ki değişecektir — mevcut kurallar geçmiş işlemlere bağlı denetim günlüğünde kalır ve yalnızca gelecekteki işlemler yeni kuralları kullanır. Bu, satıcı anlaşmazlıkları için kritiktir: satıcıların herhangi bir işleme tam olarak hangi ücretin uygulandığını bilme hakkı vardır.

---

Bölünmüş Ödemeler ve Satıcı Ödemeleri

Ödemeler altyapısı, çoğu pazar yeri projesinin karmaşıklığını küçümsediği alandır. Para almak görece basittir. Doğru yerlere, doğru zamanlarda, doğru miktarlarda, birden fazla yargı bölgesindeki finansal düzenlemelere uyarken göndermek ise gerçek çalışmanın bulunduğu yerdir.

Stripe Connect: Sektör Standardı

Stripe Connect, Birleşik Krallık ve Avrupa'da pazar yeri ödemeleri için baskın tercih olmaya devam etmektedir — ve bunun iyi bir nedeni vardır. Çok taraflı ödemeler için amaca yönelik bir API sunmakta, PCI uyumluluğunu yönetmekte, farklı platform kontrol düzeyleri için üç hesap türü sunmakta ve kapsamlı dokümantasyon ile olgun bir ekosistemle desteklenmektedir.

Üç hesap türü, kontrol ile uyumluluk yükü arasında temel bir ödünleşimi temsil etmektedir:

Standart hesaplar en basit entegrasyon yoludur. Satıcılar mevcut Stripe hesaplarını OAuth aracılığıyla platformunuza bağlar. Stripe, kimlik doğrulama, banka hesabı yönetimi ve uyumluluğun tamamını üstlenir. Platformunuzun Stripe hesaplarına sınırlı görünürlüğü vardır. Ödemeler, kendi Stripe ödeme programlarına göre doğrudan banka hesaplarına aktarılır. Bu model, satıcıların bağımsız olarak Stripe kullanıyor olabileceği köklü işletmeler olduğu platformlar için uygundur.

Express hesaplar Stripe tarafından barındırılır ancak platform markasını taşır. Satıcılar, platformunuzun adı ve logosuyla Stripe tarafından barındırılan bir kabul akışından geçer. Platformunuz, ödeme zamanlamasını kontrol eder ve API aracılığıyla ayrıntılı hesap bilgilerine erişebilir. Stripe, uyumluluk ve kimlik doğrulamasını üstlenir. Çoğu pazar yeri geliştirmesi için önerdiğimiz model budur — platform kontrolünü kabul edilebilir uyumluluk yüküyle dengeler.

Özel hesaplar, platformunuza satıcı deneyimi, kabul akışı ve hesap yönetimi üzerinde tam kontrol sağlar. Ödemeler platformunuz tarafından tamamen kontrol edilir. Bunun karşılığında platformunuz önemli uyumluluk sorumluluklarını üstlenir — gerekli tüm KYB bilgilerini toplama ve iletme konusunda siz sorumlusunuzdur; Stripe'ın şartları sizi bu veriler için sorumlu taraf olarak belirler. Özel hesaplar, özel uyumluluk ekiplerine ve entegrasyonu sürdürmek için bütçeye sahip çok büyük platformlar için uygundur.

Ödeme Zamanlaması ve Emanet

Satıcılar parasını ne zaman gerçekten alır? Bu karar, satıcı nakit akışı, alıcı koruması ve geri ödeme riski için önemli çıkarımlar taşımaktadır.

Sipariş karşılamada ödeme, satıcı bir siparişi gönderildi olarak işaretlediğinde satıcı fonlarını serbest bırakır. Satıcı nakit akışını en üst düzeye çıkarır ve düşük anlaşmazlık oranlarına sahip kategoriler ile güvenilir satıcılar için uygundur. Risk, bir alıcının geri ödemesi — meşru bir tanesi bile olsa — zaten satıcıya gönderilmiş fonları geri almayı gerektirebilir.

Teslimatta ödeme, fonları yalnızca taşıyıcı takibi veya alıcı onayıyla teyit edilen teslimat kaydedildiğinde serbest bırakır. Geri ödeme riskini önemli ölçüde azaltır; ancak özellikle dar marjlarla çalışan satıcılar için nakit akışı sürtüşmesi yaratır.

Kayan serbest bırakmaya sahip emanet, tüm fonları otomatik serbest bırakmadan önce genellikle teslimatten 7 ila 14 gün sonrasına kadar bekletir. Bu yaklaşım, Airbnb ve Etsy gibi büyük pazar yerleri tarafından kullanılan modeli yansıtır. Fonlar platformdan ayrılmadan önce anlaşmazlıkları ele almak için bir pencere sağlayarak geri ödeme kurtarma karmaşıklığını önemli ölçüde azaltır.

Geri Ödeme İşlemleri

Geri ödemeler — alıcının kartı veren kuruluşla bir ücrete itiraz etmesi — pazar yeri operasyonlarının kaçınılmaz bir gerçeğidir. Platformunuz, alıcının bankası ile satıcının ödeme hesabı arasında yer almaktadır. Banka alıcı lehine karar verirse ve satıcıya zaten ödeme yapılmışsa, bu fonları satıcıdan geri almanız gerekir.

Bu kurtarma süreci, platform mimarinize yerleştirilmiş olmalıdır. Stripe Connect ile Stripe, hesapta yeterli bakiye varsa geri ödeme tutarı artı anlaşmazlık ücretini otomatik olarak satıcının bağlı hesabından borçlandırabilir. Bakiye yetersizse platformunuz geçici olarak zararı üstlenir ve satıcı sözleşmesi şartları aracılığıyla kurtarma işlemini sürdürmek zorunda kalır. İşte bu nedenle iyi hazırlanmış satıcı sözleşmeleri ve bir emanet veya rezerv modeli en başından itibaren önemlidir.

---

Envanter ve Listeleme Yönetimi

Tek satıcılı bir mağazada ürün kataloğu, tutarlı bir süreçle tek bir ekip tarafından yönetilir. Çok satıcılı bir pazar yerinde katalog, katalog yönetimi karmaşıklığı, ürün fotoğrafçılığı kalitesi ve özellik tamamlama oranları açısından birbirinden çok farklı yüzlerce satıcı tarafından oluşturulur.

Satıcıya Ait Ürün Katalogları

Her satıcının platform içinde yalıtılmış bir ürün kataloğu olmalıdır. A Satıcısı, B Satıcısının listelemeleri üzerinde hiçbir şekilde göremez, değiştiremez veya etkileyemez. Veritabanı düzeyinde, her ürün kaydı bir vendor_id yabancı anahtarı taşımalı ve satıcı panosundan gelen tüm sorgular, bir kullanıcı arayüzü filtresi değil, veri erişim katmanında zorunlu bir kısıtlama olarak ilgili satıcının kimliğine göre kapsamlandırılmalıdır.

Ortak Kategori Taksonomisi

Platform genelindeki kategori taksonomisi, bireysel satıcılar tarafından değil, platform operatörü tarafından merkezi olarak yönetilmelidir. Satıcıların kendi kategorilerini oluşturmasına izin vermek, haftalar içinde parçalanmış ve aranamaz bir katalogla sonuçlanır. Taksonomi hiyerarşik olmalıdır (örn. Giyim → Kadın → Üstler → T-Shirtler), anlamlı filtrelemeyi mümkün kılacak kadar ayrıntılı ve satıcıların kategori atamalarının beklenmedik şekilde değişmeyeceğine güvenebileceği kadar istikrarlı olmalıdır.

Kategori ataması, satıcının sabit bir taksonomiden yapacağı seçim olmalıdır; yanlış kategorize edilmiş listeleri bir denetim kuyruğu aracılığıyla işaretleme seçeneği sunulabilir.

Esnek Özellik Şemaları

Farklı ürün türleri, tamamen farklı özellik kümeleri gerektirir. Giyim kategorisindeki bir listelemenin beden, renk, malzeme ve cinsiyet bilgisine ihtiyacı vardır. Elektronik kategorisindeki bir listeleme voltaj, bağlantı, garanti süresi ve uyumluluk bilgisine ihtiyaç duyar. Gıda kategorisindeki bir listeleme ise içerikler, alerjenler, ağırlık ve menşe ülkesi bilgisi gerektirir.

Doğru yaklaşım, kategori hiyerarşisine bağlı bir dinamik özellik şemasıdır. Bir satıcı kategori seçtiğinde, listeleme formu o kategori için gerekli ve isteğe bağlı özellikleri dinamik olarak görüntüler. Veri katmanında bu genellikle şu anlama gelir:

• Hangi özelliklerin hangi kategoriye ait olduğunu, veri türlerini ve zorunlu olup olmadıklarını tanımlayan bir category_attributes tablosu
• Esnek anahtar-değer yapısında (veya şema esnekliğini tercih ediyorsanız PostgreSQL'de bir JSONB sütununda) her ürün için özellik değerlerini depolayan bir product_attribute_values tablosu

Bu mimari, platform operatörlerine şema migrasyonu gerektirmeden bir kategoriye yeni özellikler ekleme imkânı tanır ve arama dizininin, şema tasarım aşamasında özellik türlerini bilmeden çok yönlü filtreleme için özellik değerlerini dizinlemesini sağlar.

Görsel Yönetimi

Satıcı tarafından yüklenen ürün görselleri önemli bir altyapı konusudur. Satıcılar, profesyonel marka fotoğrafçılarından mutfak masasında ürün fotoğraflayan bireysel satıcılara kadar geniş bir yelpazede yer almaktadır. Platformunuzun şunları yapması gerekir:

• Birden fazla formatta görsel kabul etmek (mobil cihazlardan JPEG, PNG, WebP, HEIC)
• Minimum çözünürlük gereksinimlerini uygulamak (kısa kenar için minimum 1200 piksel öneriyoruz)
• Farklı görüntüleme bağlamları için birden fazla boyut varyantı oluşturmak (küçük resimler, ızgara görünümleri, ürün detayı, yakınlaştırma)
• Küresel yükleme sürelerini en aza indirmek için görselleri bir CDN üzerinden sunmak
• Görselleri nesne depolamada satıcıya özgü bir yol yapısında depolamak

Depolama için gerçek zamanlı görsel dönüşüm özellikli bir CDN ile birlikte AWS S3 veya Cloudflare R2 kullanıyoruz (Cloudflare Images, Imgix veya Lambda@Edge ile AWS CloudFront). Bu yaklaşım, yüklenen her görsel için her boyut varyantını önceden oluşturmaktan kaçınır; bunun yerine varyantları ilk istekte oluşturur ve bunları kenarda önbelleğe alır.

---

Arama, Keşif ve Sıralama

Arama, çoğu pazar yeri alıcısı için birincil gezinme mekanizmasıdır. Arama ve keşif deneyiminizin kalitesi, doğrudan dönüşüm oranını ve dolayısıyla satıcı memnuniyetini belirler. Kataloğunuzda iyi ürünlere sahip olan ancak bulunamayan bir satıcı platformu terk edecektir.

Çok Satıcılı Arama Zorlukları

Pazar yeri aramasının temel zorluğu, alaka düzeyinin iki boyutunun bulunmasıdır: ürün alaka düzeyi (bu ürün alıcının istediğiyle eşleşiyor mu?) ve satıcı alaka düzeyi (bu alıcının güvenmesi gereken bir satıcı mı?). Doğrulanmamış ve hiç incelemesi olmayan bir satıcıdan mükemmel bir ürün, 500 adet beş yıldızlı incelemeye sahip bir satıcıdan çok benzer bir ürünün üzerinde sıralanmamalıdır.

Sıralama algoritmanızın şunları birleştirmesi gerekir:

• Metin alaka düzeyi: Başlık, açıklama ve özellikler sorguyla ne kadar eşleşiyor?
• Satıcı kalite puanı: İnceleme ortalaması, sipariş karşılama oranı, anlaşmazlık oranı ve platformdaki görev süresinin bileşik değeri
• Listeleme tamamlığı: Tam özelliklere, birden fazla görsele ve ayrıntılı açıklamalara sahip listeler, eksik listelemelerin üzerinde yer almalıdır
• Dönüşüm sinyalleri: Benzer sorgular için iyi dönüşüm sağlayan listeler olumlu bir sıralama sinyali almalıdır
• Güncellik: Güvenilir satıcılardan gelen yeni listeler, gömülmemek için geçici bir destek almalıdır

Çoğu projede pazar yeri aramasını Elasticsearch veya OpenSearch üzerine kuruyoruz; altyapı basitliğinin önceliklendirildiği projelerde Typesense giderek daha fazla değerlendiriliyor. Satıcı kalite puanı, bir arka plan işi tarafından eşzamansız olarak hesaplanır ve ürün belgesinde aranabilir bir alan olarak depolanır; bu sayede sıralama hesaplamaları sorgu zamanında veritabanı birleştirmesi gerektirmez.

Tanıtımlı Listeler

Satıcıların yükseltilmiş yerleşim için ödeme yapacağı bir tanıtımlı listeleme sistemi, alıcı güvenini zedelememek için dikkatli bir tasarım gerektirir. Temel ilkeler:

• Tanıtımlı listeler, organik sonuçlardan görsel olarak ayırt edilmelidir (çoğu yargı bölgesinde reklamcılık standartları kapsamında yasal gereklilik)
• Sonuç sayfası başına maksimum tanıtımlı slot sayısı uygulanmalıdır (genellikle ilk 10 sonuçtan 2-3 tanesi)
• Tanıtımlı slotlar hâlâ minimum alaka düzeyi eşiğini karşılamalıdır — alakasız bir tanıtımlı listeleme, son derece alakalı bir organik sonucun önüne geçmemelidir

Adil Görünürlük Sağlama

Sipariş geçmişi ve incelemesi olmayan yeni satıcılar her zaman köklü satıcıların altında sıralanacaktır. Bu algoritmik açıdan doğrudur, ancak ticari açıdan sorunludur — kataloğunuzu büyütmek için yeni satıcıların başarılı olması gerekir. Bunu, yeni satıcıların yapay bir sıralama desteği aldığı 30-90 günlük yeni satıcı muafiyet süresiyle ele alıyoruz. Muafiyet döneminin ardından satıcılar gerçek performans sinyalleriyle rekabet eder.

---

Değerlendirmeler, Puanlamalar ve Güven

Değerlendirme sistemi, çok satıcılı bir pazar yeri için isteğe bağlı bir özellik değildir. Alıcıların daha önce hiç karşılaşmadıkları satıcılarla işlem yapmasına olanak tanıyan birincil güven mekanizmasıdır. Manipüle edilebilen, şişirilmiş puanlar gösteren veya gerçek olumsuz deneyimleri yansıtamayan güvenilmez bir değerlendirme sistemi, alıcıların platforma duyduğu güveni zedeleyecektir.

Yalnızca Doğrulanmış Satın Almalar

Değerlendirme bütünlüğü açısından en önemli tek tasarım kararı, yalnızca tamamlanmış ve teslim edilmiş siparişe sahip alıcıların satın aldıkları satıcı ve ürünler için değerlendirme bırakabilmesidir. Bu açık görünmektedir; ancak veri katmanında dikkatli bir uygulama gerektirir: değerlendirme gönderimi, kullanıcı arayüzü doğrulamasıyla değil, incelemecinin hesabına bağlı başarılı bir sipariş olayıyla engellenmelidir.

Satıcı Performans Metrikleri

Toplam yıldız puanlamalarının ötesinde, bir satıcı puan kartı alıcılara daha ayrıntılı güven sinyalleri sunar ve platformunuza satıcı yönetim kararları için nesnel bir dayanak sağlar. Puan kartı şunları içermelidir:

• Sipariş karşılama oranı: Belirtilen hazırlık süresi içinde karşılanan siparişlerin yüzdesi
• Zamanında teslimat oranı: Belirtilen teslimat penceresi içinde teslim edilen siparişlerin yüzdesi
• Yanıt süresi: Alıcı mesajlarına yanıt verme için medyan süre
• Anlaşmazlık oranı: Resmi bir anlaşmazlıkla sonuçlanan siparişlerin yüzdesi
• İade oranı: İade talebiyle sonuçlanan siparişlerin yüzdesi

Bu metrikler, tüm zamanlar yerine kayan 90 günlük bir pencerede hesaplanmalıdır; böylece satıcılar zorlu bir dönemden toparlanabilir ve erken dönemdeki güçlükler için kalıcı olarak cezalandırılmazlar.

Değerlendirme Özgünlüğü ve Manipülasyon

Değerlendirme manipülasyonu — satıcıların sahte olumlu değerlendirmeler bırakması, rakip satıcıların sahte olumsuz değerlendirmeler bırakması — ölçekte gerçek bir operasyonel sorundur. Karşı önlemler şunları kapsar:

• Küçük siparişler veren ve hemen değerlendirme bırakan birden fazla hesabı tespit etmek için IP ve cihaz parmak izi analizi
• Belirli bir satıcı için değerlendirme gönderiminde alışılmadık artışları işaretlemek amacıyla değerlendirme hızı izleme
• Şüpheli değerlendirme kalıplarını ortaya çıkarmak için duygu analizi (örn. birden fazla değerlendirmede alışılmadık derecede benzer dil kullanımı)
• Platformda önceki satın alma geçmişi olmayan hesaplardan gelen değerlendirmelerin gecikmeli yayınlanması

---

Yönetim ve Denetim

Platform operatörünün arka ofisi, pazar yeri projelerinde sık sık yetersiz belgelenir ve lansmandan altı hafta sonra en acil ihtiyaç haline gelir. Bir pazar yerini ölçekte yönetmek için gereken yönetim kapasitesi oldukça büyüktür.

Satıcı Performansı İzleme

Yönetim paneliniz en azından şunları sunmalıdır:

• Dönemden döneme karşılaştırmayla satıcıya göre gerçek zamanlı GMV
• Satıcı SLA ihlal uyarıları (sipariş karşılama süresi aşıldı, mesaja yanıt verilmedi)
• Satıcı ve kategoriye göre detay inceleme özelliğiyle anlaşmazlık oranı eğilimleri
• Ödeme kuyruğu durumu ve manüel geçersiz kılma kapasitesi

İçerik Denetimi

Bir satıcı tarafından gönderilen her listeleme, yayına girmeden önce bir denetim sürecinden geçmelidir. Süreç iki aşamaya sahiptir:

Otomatik tarama, yasaklı anahtar kelime eşleştirme, görüntü tanıma (yasaklı içerikleri, sahte marka göstergelerini ve ürün güvenliği tehlikesi imgelerini tespit etmek için) ve kategori politikası kural denetimlerinin bir kombinasyonunu kullanır. Otomatik denetimden geçemeyen listeler denetim kuyruğuna gider; geçenler, platformunuzun risk toleransına bağlı olarak otomatik olarak yayınlanır veya manüel inceleme için bekletilir.

Manüel inceleme, eskalasyon kuyruğunu ele alır. Yönetim kullanıcı arayüzünüzün listelemenin tamamını sunması, eskalasyonu tetikleyen belirli politikayı işaretlemesi ve incelemecilerin onaylama, şablonlu bir gerekçeyle reddetme veya satıcı düzenlemesi talep etme seçeneklerine izin vermesi gerekir.

Anlaşmazlık Çözüm Araçları

Bir alıcı anlaşmazlık bildirdiğinde, yönetim ekibinizin şunları yapabilmesi gerekir:

1. Eksiksiz sipariş geçmişini, iletişim akışını ve zaman çizelgesini görüntülemek
2. Alıcıdan ve satıcıdan kanıt talep etmek (fotoğraflar, takip bilgisi, yazışmalar)
3. Anlaşmazlık politikanızı uygulamak ve sonucu kaydetmek
4. Uygun finansal işlemi başlatmak (alıcı iadesi, satıcı borçlandırması veya bölünmüş çözüm)
5. Satıcının performans kaydına bir anlaşmazlık işareti uygulamak

Tüm bu adımlar, birden fazla bağlantısız sistem üzerinden değil, tek bir yönetim iş akışı görünümü içinde gerçekleştirilebilir olmalıdır. Anlaşmazlık çözüm araçlarının inşa edilmesi göz alıcı değildir; ancak bu araçlara harcanan zaman doğrudan yönetim kapasitesine dönüşür — ve ölçekte yetersiz araçlar, anlaşmazlıkların çözülmesinin haftalar alması anlamına gelir ki bu hem alıcının hem de satıcının güvenini yerle bir eder.

---

Teknik Mimari

Alan sorunları belirlendikten sonra, üretim için hazır çok satıcılı bir pazar yerinde teknik yığına nasıl yaklaştığımıza geliyoruz.

Önerilen Yığın

Katman	Teknoloji	Gerekçe
Ön yüz (alıcı arayüzü)	Next.js (App Router)	SEO için SSR, React ekosistemi, kenara hazır
Ön yüz (satıcı paneli)	Next.js veya React SPA	Kimlik doğrulamalı uygulama, daha az SEO bağımlılığı
Yönetim paneli	React SPA	İç araç, basitlik öncelikli
API katmanı	Node.js (Fastify) veya Python (FastAPI)	Yüksek G/Ç verimi, güçlü ekosistem
Birincil veritabanı	PostgreSQL	Finansal veriler için kritik ACID uyumluluğu
Arama dizini	Elasticsearch / OpenSearch	Ölçekte tam metin ve çok yönlü arama
Önbellek	Redis	Oturum yönetimi, hız sınırlama, sık okunan veriler
Kuyruk / olaylar	AWS SQS + SNS veya RabbitMQ	Eşzamansız sipariş işleme, olay yayılımı
Dosya depolama	AWS S3 / Cloudflare R2	Satıcı medyası, belgeler
Ödemeler	Stripe Connect	Pazar yeri ödeme akışları
E-posta	SendGrid / Postmark	İşlemsel ve bildirim e-postası
Altyapı	Terraform ile AWS / GCP	Tekrarlanabilir, ölçeklenebilir bulut altyapısı

Veritabanı Şema Değerlendirmeleri

Çok satıcılı pazar yerleri için en önemli iki şema tasarım kararı:

Her tabloda satıcı izolasyonu. Satıcıya özgü veriler içeren her tablo (ürünler, siparişler, ödemeler, mesajlar) bir vendor_id sütunu taşımalıdır. Uygulama düzeyinde veri erişimi, isteğe bağlı bir filtre olarak değil, depo veya ORM katmanında zorunlu bir kısıtlama olarak satıcı kapsamını uygulamalıdır. PostgreSQL'de veritabanının ikincil bir güvence olarak izolasyonu uyguladığı satır düzeyinde güvenliği kullanıyoruz.

Sipariş bölüştürme. orders tablosu alıcının işlemini temsil eder. Ayrı bir vendor_orders (veya fulfilments) tablosu, her satıcının bu siparişten aldığı payı kendi durum makinesiyle (beklemede, onaylandı, gönderildi, teslim edildi, tamamlandı), kendi iletişim akışıyla ve kendi ödeme kaydıyla temsil eder. vendor_orders'dan orders'a giden yabancı anahtar iki tablo arasındaki tek bağlantıdır; satıcı sorguları her zaman vendor_orders'a göre kapsamlandırılır, orders'a asla göre değil.

Sipariş Yönetimi için Olay Tabanlı Mimari

Çok satıcılı bir pazar yerinde sipariş karşılama, pek çok servis arasında pek çok adımı kapsar. Olay tabanlı bir mimari bu adımları birbirinden ayırır ve sistemi kısmi hatalara karşı dayanıklı kılar.

Bir alıcı ödemeyi tamamladığında, tek bir OrderPlaced olayı yayınlanır. Bu olayın aboneleri şunlardır:

• Bildirim servisi (alıcıya onay e-postası gönder; her satıcıya yeni sipariş bildirimi gönder)
• Ödeme servisi (ödeme tahsilini başlat ve fonları tut)
• Envanter servisi (sipariş edilen her ürün için stok düzeyini düşür)
• Analitik servisi (raporlama için işlemi kaydet)
• Satıcı sipariş servisi (sepetteki her satıcı için bir vendor_order kaydı oluştur)

Sonraki her durum değişikliği — VendorOrderConfirmed, ItemDispatched, DeliveryConfirmed, DisputeOpened, PayoutReleased — kendi abone kümesiyle birlikte kendi olayıdır. Bu mimari, yeni bir davranış eklemek (örn. belirli bir eşiğin üzerindeki siparişlerde sahtekârlık denetimi) için yalnızca ilgili olaya yeni bir abone eklenmesini gerektirir — sipariş işleme çekirdeğinde değişiklik yapılmaz.

API Tasarımı

Pazar yeri API yüzeyi büyüktür ve üç farklı tüketiciye hizmet eder: alıcı arayüzü, satıcı paneli ve yönetim paneli. Bunları, tek bir uç nokta düzeyinde rol tabanlı erişim kontrolü uygulanmış tek bir API yerine, ayrı kimlik doğrulama ara yazılımı ve ayrı izin modelleriyle ayrı API ad alanları (/api/storefront, /api/vendor, /api/admin) olarak tasarlıyoruz. Bu, bir izin hatası olsa bile satıcı API tüketicilerinin yönetim uç noktalarına ulaşmasını engeller.

---

Mobil: Yerel Uygulama mı PWA mı?

Çoğu pazar yeri operatörü bu soruyu projenin bir noktasında sorar: yerel bir mobil uygulamaya ihtiyacımız var mı, yoksa progresif web uygulaması yeterli mi?

Önce PWA gerekçesi: Uygun manifest yapılandırması ve servis çalışanı önbelleğiyle Next.js kullanılarak iyi inşa edilmiş bir PWA gerçekten iyi bir mobil deneyim sunar — tarayıcıdan kurulabilir, önbelleğe alınmış sayfalar için çevrimdışı çalışır ve modern mobil donanımda hızlıdır. Mühendislik kaynaklarının sınırlı olduğu bir V1 pazar yeri için PWA, web uygulamanızın yanında ayrı iOS ve Android kod tabanlarını sürdürmenin maliyetini ve karmaşıklığını önler.

Yerel uygulamalar gerekçesi: iOS'ta PWA'lar için anlık bildirimler sınırlı kalmaya devam etmektedir (iOS 16.4'ten bu yana iyileşmiş olmakla birlikte yerel uygulamalarla eşdeğer değil). Satıcı listeleme fotoğrafçılığı için kamera erişimi yerel bir uygulamada daha kapsamlıdır. Uygulama mağazası varlığı, PWA'nın kopyalayamayacağı keşfedilebilirlik sağlar. Mobilin birincil kanal olduğu alıcı odaklı pazar yerleri için — özellikle moda, gıda ve tüketim malları alanlarında — yerel uygulamalar, platform yatırımı haklı kılacak kadar yeterli katalog derinliğine ulaştığında daha yüksek etkileşim metrikleri üretme eğilimindedir.

Tipik önerimiz, duyarlı bir web uygulaması veya PWA ile başlamak, ürün-pazar uyumunu sağlamak ve lansmandan 12-18 ay sonra kullanıcı davranışı ve dönüşüm kalıpları üzerine gerçek veriye sahip olduğunuzda yerel uygulamalara yatırım yapmaktır.

---

Ölçekleme Zorlukları

Çok satıcılı bir pazar yerinin ölçekleme zorlukları, standart bir web uygulamasının ölçekleme zorluklarından nitelik bakımından farklıdır. Yönettiğiniz ölçek yalnızca işlem hacmi değil — katalog derinliği, satıcı çeşitliliği ve operasyonel karmaşıklıktır.

Ölçekte Görsel ve Medya Depolama

500 satıcısı bulunan ve her birinin ortalama 200 ürünü olan, ürün başına 8 görsel içeren bir pazar yeri, tek bir satış gerçekleşmeden 800.000 görsel depolamaktadır. Sıkıştırma sonrası 500 KB ortalama dosya boyutuyla bu, boyut varyantları oluşturulmadan önce yalnızca orijinaller için 400 GB depolamaya karşılık gelir. Nesne depolama maliyetleri düşüktür (S3 fiyatlandırması GB başına aylık kuru kuruş mertebesindedir), ancak trafik ölçeklendikçe CDN bant genişliği maliyetleri önemli hale gelebilir.

Verimlilik kaldıracı, talep üzerine görsel dönüşümü ve agresif CDN önbelleğidir. Her görseli açık önbellek başlıklarıyla bir dönüşüm URL'si üzerinden sunun; CDN dönüştürülmüş varyantı kenarda önbelleğe alır ve kaynak depolama alanınız yalnızca önbellek kaçırmada vurulur. CDN katmanında WebP dönüşümüyle (aynı görsel kalite için genellikle JPEG'e kıyasla dosya boyutunu yarıya indiren) bu yaklaşım, orijinalleri sunmaya kıyasla CDN bant genişliği maliyetlerini %60-70 oranında azaltabilir.

Ölçekte Arama Dizini Performansı

Tam özellik verisiyle 500.000 ürün belgesi içeren bir Elasticsearch dizini, bir ölçekleme zorluğu değildir. Onlarca eşzamanlı satıcıdan gerçek zamanlı güncellemeler — stok düzeyi değişiklikleri, fiyat değişiklikleri, yeni listeler, listeleme devre dışı bırakmaları — alınan bu boyuttaki bir dizin bambaşka bir meseledir. Elasticsearch'ün yazma verimi, yenileme aralığı ve kopyaları senkronda tutmanın maliyetiyle sınırlandırılmıştır.

Ölçekte işe yarayan stratejiler:

• Belge başına API çağrıları yerine büyük katalog güncellemeleri için toplu dizinleme
• Tam belge değişikliği yerine sıkça değişen alanlar (fiyat, stok) için kısmi belge güncellemeleri
• Elasticsearch'e göndermeden önce kısa bir pencerede aynı belgeye yapılan değişiklikleri gruplayan özel bir güncelleme kuyruğu
• Yazmaları birincil parça yönetirken arama sorguları için okuma kopyaları

Satıcılar Arasında Gerçek Zamanlı Envanter

Envanter tutarlılığı, sınırlı stoka sahip kategorilerde (vintage veya ikinci el ürünler, siparişe özel mallar, sınırlı sayıda ürünler) özellikle önemlidir. Platformunuzun en son istemediği şey, iki alıcının aynı anda aynı benzersiz ürün için ödemeyi tamamlamasıdır.

Doğru kalıp, sepete ekle anında iyimser rezervasyon, ödeme sırasında onaylı rezervasyondur. Bir alıcı sepetine ürün eklediğinde sistem, belirli bir süre için (genellikle 15-30 dakika) rezervasyon yapar. Bu pencere içinde ödeme tamamlanmazsa rezervasyon sona erer ve stok iade edilir. Rezervasyon, ödeme başarıyla tahsil edildiğinde yalnızca onaylanır ve stok kalıcı olarak düşürülür. Bu kalıp, birincil veritabanınıza ait olmayan rezervasyon durumu için Redis (veya benzer hızlı anahtar-değer depolama) gerektirir.

---

Cyberbeak'te Çok Satıcılı Pazar Yerlerini Nasıl İnşa Ediyoruz

Pazar yeri geliştirme projelerine, ticarı hedefe gözden kaçırmadan doğasında var olan karmaşıklığı yöneten yapılandırılmış bir yaklaşım geliştirdik: satıcı ve alıcı çekmeye başlayabilmesi için çalışan bir platformu pazara sunmak.

Yaklaşımımız

Her pazar yeri projesine iki ila dört haftalık bir keşif aşamasıyla başlıyoruz. Bu, rutin bir kutu işaretleme egzersizi değildir. İş modelini doğrudan müşteriyle hassas teknik terimlerle haritalandırıyoruz — komisyonların tam olarak nasıl hesaplandığı, anlaşmazlıkların tam olarak nasıl çözüldüğü, satıcıların panellerinde tam olarak hangi verileri görmesi gerektiği. Keşfin çıktısı bir sunum destesi değildir; doğru tahmin edilecek ve üzerine inşa edilecek kadar ayrıntılı bir teknik spesifikasyondur.

Ardından tek bir büyük çaplı başlatma yerine aşamalı teslimat modeline geçiyoruz:

Aşama 1 — Temel (1-8. haftalar): Temel veri modeli, satıcı kabul ve KYB akışı, temel listeleme yönetimi, Stripe Connect Express hesaplarıyla ödeme entegrasyonu, alıcı arayüzü katalog ve ürün sayfaları, ödeme ve sipariş verme.

Aşama 2 — Operasyonlar (9-16. haftalar): Satıcı paneli (sipariş yönetimi, ödeme geçmişi, listeleme analitiği), yönetim paneli (satıcı yönetimi, sipariş denetimi, anlaşmazlık araçları), değerlendirme ve puanlama sistemi, e-posta bildirim sistemi.

Aşama 3 — Büyüme (17-24. haftalar): Arama ve çok yönlü filtreleme, tanıtımlı listeler sistemi, gelişmiş satıcı analitiği, mobil optimizasyon veya PWA geliştirme, performans ayarlaması.

Tipik Zaman Çizelgesi

Ticari olarak başlatılabilir, yalnızca kavram kanıtı olmayan, üretime hazır bir V1 pazar yeri, deneyimlerimize göre 16 ila 24 hafta sürmektedir. Bu zaman çizelgesini sıkıştırmaya çalışan projeler genellikle bunu operasyonel araçları (satıcı paneli, yönetim paneli, anlaşmazlık çözümü) atlayarak yaparlar ve ardından büyüyen satıcı ve anlaşmazlık sayısını bir elektronik tablodan yönetmeye çalışırken lansmandan altı hafta sonra krizle yüzleşirler.

Aralığın alt sınırı (16 hafta), dar tanımlanmış bir kategoriye, basit bir komisyon yapısına ve iyi örgütlenmiş ve kararlı bir müşteri ekibine sahip pazar yerleri için geçerlidir. Üst sınır (24 hafta), karmaşık komisyon mantığına, gelişmiş KYB gerektiren yargı bölgelerine veya üçüncü taraf sipariş karşılama sistemleriyle entegrasyonlara sahip çok kategorili platformlar için geçerlidir.

Yatırım

Çok satıcılı pazar yeri geliştirmesi, inşa edilenin gerçek karmaşıklığını yansıtarak önemli bir yatırım gerektirmektedir. Bu alandaki projelerimiz, V1 geliştirmesi için 100.000 £ ile 300.000 £ arasında değişmekte olup fark şunlardan kaynaklanmaktadır:

• Kapsam dahilindeki satıcı odaklı özellik sayısı (satıcı paneli genellikle alıcı odaklı platform kadar büyüktür)
• Ödeme karmaşıklığı (yargı bölgesi sayısı, para birimi desteği, komisyon motoru karmaşıklığı)
• Gereken entegrasyonlar (üçüncü taraf sipariş karşılama sağlayıcıları, ERP sistemleri, kargo API'leri)
• Tasarım karmaşıklığı (özel tasarım sistemi ile bileşen kitaplığı kullanan hızlandırılmış geliştirme)
• Lansman sonrası süregelen altyapı ve destek gereksinimleri

Maliyetler konusunda başlangıçtan itibaren şeffafız ve sözleşmelerimizi kapsam genişlemesi sürprizlerini önleyecek şekilde yapılandırıyoruz — işte bu nedenle keşif aşaması yatırımı vazgeçilmezdir. Platformunu tam olarak tanımlamak için dört hafta harcayan müşteri, 18. haftada komisyon motoru tasarımını değiştirmeyecek müşteridir.

---

Sıkça Sorulan Sorular

Shopify üzerine çok satıcılı bir pazar yeri inşa edebilir miyim?

Etkili bir şekilde hayır. Shopify, tek bir satıcının müşterilere satış yapması için tasarlanmıştır. Çok satıcılı işlevsellik, Webkul tarafından geliştirilen Multi-Vendor Marketplace gibi uygulamalarla kısmen simüle edilebilir; ancak bu uygulamalar yerel bölünmüş ödemeleri, gerçek satıcı veri izolasyonunu veya gerçek bir pazar yerinin ihtiyaç duyduğu operasyonel araçları sunamaz. Shopify çok satıcılı uygulamalar üzerine kurulu platformlar büyüdükçe sürekli olarak sert tavanlarla çarpmaktadır. İş modeliniz bir pazar yeriyse, bir pazar yeri inşa edin — tek satıcılı bir platformu bir pazar yerine benzetmek için uyarlamayın.

Platform inşa edildikten sonra satıcıları platforma almak ne kadar sürer?

Satıcı edinimi, pazar yeri inşaatının en zorlu parçasıdır ve platform geliştirmesinden tamamen ayrıdır. Teknik kabul süreci — bir satıcının başvurusuna başlamasından ilk listelemeyle canlıya geçmesine kadar — iyi tasarlanmış bir platformda 48-72 saati geçmemelidir. Bu sürenin büyük bölümü, kimlik doğrulama sağlayıcınızdan alınan KYB doğrulama sonuçlarını beklemektir. Satıcıları platformunuzun zamanlarını ve katalog yönetimi çabalarını harcamaya değer olduğuna ikna etmenin ticari zorluğu, teknik değil pazarlama ve satış zorluğudur.

Satıcılara aylık abonelik mi, komisyon mu yoksa her ikisi birden mi almalıyız?

Bu bir iş modeli sorusudur; ancak teknik yanıt, komisyon motorunuzun yalnızca bir modelle başlasanız bile her ikisini aynı anda ilk günden itibaren desteklemesi gerektiğidir. Yalnızca komisyon modelleri lansmanda satıcılara satmak daha kolaydır (ön taahhüt yoktur), ancak başarınızla ölçeklenen gelir yaratır. Abonelik artı indirimli komisyon modelleri, yüksek hacimli satıcılar için daha uygundur ve gelir öngörülebilirliğinizi artırır. Pek çok pazar yeri yalnızca komisyonla başlar ve aboneliği zorlayıcı kılacak yeterince platform gücü kazandığında abonelik kademeleri sunar.

Bir satıcı dolandırıcılık yapsa — sipariş alsa, ödeme alsa ve hiç göndermese — ne olur?

İşte bu nedenle ödeme zamanlaması ve emanet tasarımı önemlidir. Platformunuz satıcı ödemelerini yalnızca onaylı teslimatın ardından serbest bırakıyorsa, finansal maruz kalma, ödeme tahsili ile teslimat onayı arasındaki pencereyle sınırlıdır. Teslimat sonrası 7 günlük serbest bırakma penceresiyle, fonlar platformdan ayrılmadan önce sahte bir satıcıyı tespit edip yanıt vermek için zamanınız olur. Satıcı sözleşmeniz ayrıca geri alma hakları ve gelecekteki ödemeler veya satıcının platform depozitosuna karşı tartışmalı tutarları mahsup etme hakkını kapsayan açık hükümler içermelidir. Daha yüksek riskli kategorilerde, performansa karşı tutulan bir satıcı depozitosunun talep edilmesi makul bir koruyucu önlemdir.

Alıcılar ve satıcılar için ayrı mobil uygulamalara ihtiyacımız var mı?

Genellikle lansmanda hayır. Duyarlı alıcı odaklı web uygulaması veya PWA, V1 için alıcı tarafını yeterince karşılar. Satıcılar için, mobil uyumlu bir satıcı paneli erken aşamalarda genellikle yeterlidir — satıcı katalog yönetiminin büyük bölümü (listeleme ekleme, sipariş işleme, stok güncelleme) zaten masaüstünde daha iyi yapılır. Alıcı tarafında yerel mobil uygulamalar, süregelen bakım maliyetini haklı çıkaracak kadar derinliğe ulaştığında değer kazanır; satıcı tarafında ise satıcılar mobil öncelikli operatörse (gıda, moda ikinci el satışı ve zanaatkar mal pazarlarında yaygın) değer kazanır.

---

Çok satıcılı bir pazar yeri planlıyorsanız ve bir geliştirme taahhüdünde bulunmadan önce mimari, iş modeli veya gerçekçi maliyetler hakkında görüşmek istiyorsanız, bu konuşmayı yapmaktan memnuniyet duyarız. Size doğru bir teknik spesifikasyon ve proje planı sunan — bir saatlik görüşmeye dayalı belirsiz bir tahmine değil — yapılandırılmış bir keşif süreci sunuyoruz. Bizimle iletişime geçin ve ne inşa ettiğinizi anlatın.