E-Ticaret Sitesinde Satıcı Paneli ve Marketplace Yapısı Nasıl Planlanır?

E-ticaret sitesinde marketplace yapısı kurmak, standart bir mağazaya satıcı girişi eklemekten ibaret değildir. Klasik e-ticarette ürün, stok, sipariş, ödeme ve iade tek işletmenin kontrolündedir. Marketplace modelinde ise birden fazla satıcı aynı platformda ürün yayınlar, sipariş alır, kargo süreçlerini yürütür ve gelir paylaşımı kurallarına bağlanır. Bu nedenle satıcı paneli, ürün onayı, komisyon, ödeme, kargo, iade ve denetim mekanizmaları baştan planlanmalıdır.

Marketplace doğru kurgulandığında ürün çeşitliliğini büyütür, satıcı ekosistemi oluşturur ve platformun ölçeklenmesini sağlar. Yanlış kurgulandığında ise ürün kalitesi düşer, stoklar tutarsızlaşır, müşteri hangi satıcıdan ne aldığını anlamaz, iade süreçleri karışır ve platform operasyonu manuel denetim yüküne dönüşür.

Marketplace yapısı nedir?

Marketplace, birden fazla satıcının aynı platform üzerinde ürün veya hizmet sunduğu e-ticaret modelidir. Platform sahibi altyapıyı, trafik kaynağını, müşteri deneyimini, ödeme akışını, kategori düzenini ve genel kuralları yönetir. Satıcılar ise ürünlerini yükler, stok ve fiyatlarını günceller, siparişlerini hazırlar ve platform kurallarına göre çalışır.

E-ticaret altyapısı tek satıcılı modelde daha düz bir sipariş yapısına sahiptir. Marketplace modelinde bir sepet içinde birden fazla satıcının ürünü bulunabilir. Bu durumda sipariş tek ödeme ile alınsa bile operasyon tarafında satıcı bazlı alt siparişlere ayrılmalıdır. Kargo, komisyon, iade ve ödeme akışı bu ayrımı dikkate almalıdır.

Stripe Connect, marketplace veya platformların müşterilerden ödeme toplayıp gelirin bir kısmını satıcılara ya da hizmet sağlayıcılara aktarabildiği yapılar için kullanıldığını açıklar Stripe Docs. Bu yaklaşım marketplace ödeme mimarisinde platform, müşteri ve satıcı ilişkilerinin ayrı düşünülmesi gerektiğini gösterir.

Satıcı paneli hangi temel modüllerden oluşur?

Satıcı paneli, satıcının platformla çalıştığı ana ekrandır. Bu panel yalnızca ürün yükleme alanı değildir. Satıcı burada mağaza bilgilerini yönetir, ürün ekler, fiyat ve stok günceller, siparişleri görür, kargo işlemlerini takip eder, iade taleplerine cevap verir ve kazançlarını izler. Panel eksik tasarlanırsa satıcı her işlem için platform ekibine destek talebi açar.

Yönetim paneli geliştirme tarafında satıcı paneli ile platform admin paneli birlikte düşünülmelidir. Satıcı kendi mağazasını yönetir; platform ekibi ise satıcı performansını, ürün kalitesini, komisyonları, uyuşmazlıkları ve sistem hatalarını merkezi ekrandan izler.

Satıcı başvurusu ve doğrulama nasıl kurgulanmalı?

Marketplace kalitesi satıcı kabul süreciyle başlar. Her başvurunun otomatik onaylanması kısa vadede satıcı sayısını artırır, fakat uzun vadede ürün kalitesi, müşteri güveni ve operasyon yükü üzerinde risk oluşturur. Başvuru formu satıcının kim olduğunu, hangi ürünleri satacağını, vergi ve fatura bilgilerini, kargo kapasitesini ve destek sorumluluğunu anlamaya yetecek şekilde tasarlanmalıdır.

Örnek satıcı başvuru alanları:

• Firma adı, yetkili kişi, iletişim bilgileri.
• Vergi numarası, vergi dairesi ve fatura tipi.
• Satılacak ana kategoriler ve marka yetkisi bilgisi.
• Depo veya gönderim adresi.
• Günlük/haftalık sipariş karşılama kapasitesi.
• İade kabul adresi ve iade kontrol süreci.
• Banka veya payout için gerekli hesap bilgileri.
• Satıcı sözleşmesi ve platform kurallarının onayı.

Doğrulama süreci sektör ve risk seviyesine göre değişebilir. El yapımı ürün satan küçük satıcı ile elektronik ürün satan yüksek hacimli satıcının belge ihtiyacı aynı olmayabilir. Ancak her durumda satıcının kimin adına satış yaptığı ve müşteriyle hangi sorumluluğu üstlendiği açık olmalıdır.

Ürün ekleme ve onay akışı nasıl tasarlanmalı?

Marketplace yapısında ürün kalitesi platform markasını doğrudan etkiler. Satıcı hatalı kategori seçerse, düşük kaliteli görsel yüklerse, ürün başlığına kampanya metni yazarsa veya eksik açıklama girerse müşteri bunu yalnızca satıcının değil platformun problemi olarak görür. Bu nedenle ürün ekleme akışı kurallı olmalıdır.

Ürün onay akışı örnek olarak şöyle kurulabilir:

1. Satıcı ürün taslağı oluşturur.
2. Kategori seçimine göre zorunlu alanlar açılır.
3. Sistem görsel boyutu, başlık uzunluğu, fiyat, stok ve varyant uyumunu kontrol eder.
4. Riskli kategori veya yeni satıcı ürünleri manuel onaya düşer.
5. Onaylanan ürün yayına alınır ve ilgili satıcı mağazasında görünür.
6. Fiyat veya stok güncellemesi hızlı geçebilir; başlık, kategori veya marka değişikliği yeniden onay isteyebilir.

Google Search Central, ürün yapılandırılmış verisinin fiyat, stok durumu, yorum, kargo ve iade gibi bilgileri arama deneyimlerinde daha zengin şekilde gösterebileceğini belirtir Google Search Central. Marketplace ürün sayfalarında bu verilerin satıcıdan gelen bilgilerle tutarlı olması gerekir. Bir ürün stokta görünürken satıcı panelinde stok yoksa hem müşteri deneyimi hem arama görünürlüğü zarar görür.

Komisyon modeli nasıl belirlenmeli?

Marketplace gelir modeli genellikle komisyon, listeleme ücreti, abonelik, hizmet bedeli veya karma modelle kurulabilir. En yaygın yapı, satıcının yaptığı satıştan belirli oranda komisyon alınmasıdır. Ancak her kategori için aynı komisyon doğru olmayabilir. Elektronik, gıda dışı tüketim, moda, el yapımı ürün ve B2B sarf malzemesi farklı kâr marjlarına sahiptir.

Örnek komisyon kuralı:

Kategori: Ev dekorasyon | Komisyon: %12 | Kargo: Satıcı öder | İade kargo: Kusurlu ürünse satıcı, cayma hakkıysa platform politikası | Payout: Teslimattan 7 gün sonra | Stopaj/vergisel kesinti: Muhasebe politikasına göre ayrıca gösterilir

Bu örnek kural, satıcıya net bilgi verir. Satıcı hangi satıştan ne kadar gelir elde edeceğini, ne zaman ödeme alacağını ve hangi durumlarda kesinti olacağını önceden görmelidir. Belirsiz komisyon yapısı satıcı güvenini düşürür ve mutabakat yükünü artırır.

Ödeme ve payout akışı nasıl planlanmalı?

Marketplace ödeme yapısı klasik e-ticaret ödemesinden daha karmaşıktır. Müşteri tek ödeme yapabilir, ancak sepet içinde farklı satıcılar varsa ödeme tutarı satıcı bazlı ayrıştırılmalıdır. Platform komisyonu, kargo bedeli, iade, chargeback, kampanya katkısı ve ödeme sağlayıcı kesintisi ayrı hesaplanmalıdır.

Stripe, marketplace ödemelerinde destination charges ve separate charges and transfers gibi farklı charge türleri olduğunu; seçilen charge türünün paranın taraflar arasında nasıl bölüneceğini, banka ekstresinde işlemin nasıl görüneceğini, iade ve chargeback sorumluluğunu etkilediğini açıklar Stripe Docs. Bu nedenle ödeme mimarisi sadece teknik entegrasyon değil, iş modeli kararıdır.

Sanal POS entegrasyonu veya ödeme altyapısı seçilirken şu sorular yanıtlanmalıdır:

• Müşteri sepetinde birden fazla satıcı ürünü varsa ödeme nasıl bölünecek?
• Platform komisyonu ödeme anında mı, hakediş döneminde mi düşülecek?
• Satıcıya ödeme teslimattan sonra mı, iade süresi sonrası mı yapılacak?
• İade durumunda para hangi hesaptan geri dönecek?
• Chargeback veya ödeme itirazında sorumluluk kime ait olacak?
• Satıcı bazlı hakediş raporu nasıl üretilecek?

Sipariş modeli satıcı bazlı ayrıştırılmalı

Marketplace sepetinde müşteri tek sipariş veriyor gibi görünse de operasyon tarafında satıcı bazlı alt siparişler oluşmalıdır. Örneğin müşteri aynı sepette üç satıcıdan ürün aldıysa sistem ana siparişi müşteri için tek kayıt olarak gösterebilir; ancak satıcı panelinde her satıcı yalnızca kendi ürünlerini görmelidir.

Somut örnek:

Ana sipariş: ORD-2026-004812 | Müşteri: Ahmet K. | Toplam: 3.450 TL | Alt sipariş 1: Seller-A, 2 ürün, 1.200 TL | Alt sipariş 2: Seller-B, 1 ürün, 750 TL | Alt sipariş 3: Seller-C, 3 ürün, 1.500 TL

Bu ayrım kargo ve iade için zorunludur. Seller-A siparişi aynı gün kargoya verebilir, Seller-B stok sorunu yaşayabilir, Seller-C ürünlerinden biri iade edilebilir. Ana sipariş tek statüye sıkıştırılırsa müşteri ve destek ekibi hangi parçanın hangi durumda olduğunu göremez.

Kargo ve iade kuralları nasıl yönetilmeli?

Marketplace yapısında kargo ve iade, müşteri deneyiminin en hassas alanlarından biridir. Müşteri platformdan alışveriş yaptığını düşünür; ürünün farklı satıcıdan geldiğini ödeme sonrası fark ederse deneyim kopabilir. Bu yüzden satıcı, kargo süresi, kargo ücreti, iade adresi ve iade sorumluluğu açık görünmelidir.

Kargo entegrasyonu için üç model düşünülebilir:

• Platform anlaşmalı kargo: Satıcı barkodu platform panelinden alır, kurallar merkezi yönetilir.
• Satıcı anlaşmalı kargo: Satıcı kendi kargo anlaşmasını kullanır, takip numarasını sisteme girer.
• Karma model: Belirli kategoriler veya satıcı seviyelerine göre farklı kargo modeli uygulanır.

İade tarafında da net kurallar gerekir. Ürün kusurluysa sorumluluk satıcıda olabilir. Cayma hakkı, ambalaj durumu, hijyen kategorileri veya kişiye özel ürünler ayrı değerlendirme gerektirebilir. Platform bu kuralları satıcı sözleşmesinde, müşteri bilgilendirmesinde ve panel akışında tutarlı göstermelidir.

Stok, fiyat ve entegrasyon yapısı nasıl çalışmalı?

Marketplace satıcıları ürün ve stoklarını elle yönetebilir, Excel ile yükleyebilir veya API/XML entegrasyonu kullanabilir. Başlangıçta manuel ürün girişi yeterli olabilir; ancak satıcı sayısı ve ürün hacmi arttıkça entegrasyon ihtiyacı doğar. Stok güncellemesi gecikirse platform stokta olmayan ürünü satabilir.

Stok takip yazılımı ve satıcı paneli birlikte çalışmalıdır. Satıcı stok güncellediğinde ürün kartı, arama indeksi, kampanya kuralları ve pazaryeri feedleri aynı veriyi kullanmalıdır. Çok satıcılı modelde aynı ürün birden fazla satıcıda varsa sistem en iyi satıcıyı nasıl göstereceğini de belirlemelidir: fiyat, stok, teslimat süresi, satıcı puanı veya kampanya önceliği.

API entegrasyon hizmeti kapsamındaki örnek satıcı stok güncelleme kaydı şöyle olabilir:

seller_id: SLR-204 | sku: FILTRE-HEPA-13 | stock: 48 | price: 890.00 | dispatch_time: 1 business day | updated_at: 2026-06-26T14:00:00+03:00 | source: seller_api

Bu örnek gerçek satıcı verisi değildir; satıcıdan gelen güncellemenin platformda nasıl normalize edilebileceğini göstermek için hazırlanmıştır. Böyle bir kayıt olmadan platform hangi fiyatın, hangi stokun ve hangi teslimat süresinin geçerli olduğunu denetleyemez.

Güvenlik ve yetki modeli nasıl kurulmalı?

Marketplace satıcı paneli dış kullanıcılara açık olduğu için güvenlik standart e-ticaret panelinden daha hassas hale gelir. Satıcı yalnızca kendi ürünlerini, siparişlerini, kazançlarını ve mağaza bilgilerini görebilmelidir. Başka satıcının müşteri verisine, siparişine veya finansal bilgisine erişim kritik güvenlik hatasıdır.

OWASP Top 10, web uygulamalarındaki kritik güvenlik risklerine dikkat çeken temel kaynaklardan biridir OWASP. Marketplace panelinde özellikle broken access control, kimlik doğrulama sorunları, dosya yükleme güvenliği, API anahtarları, loglama ve rate limit konuları dikkatle ele alınmalıdır.

Pratik güvenlik kontrolleri:

• Satıcı kullanıcıları yalnızca kendi mağazasına ait verileri görebilmeli.
• Mağaza içinde rol bazlı yetki olmalı: ürün editörü, sipariş sorumlusu, finans kullanıcısı.
• Ürün görseli ve dosya yükleme güvenli şekilde doğrulanmalı.
• API anahtarları satıcı bazlı üretilmeli ve iptal edilebilir olmalı.
• Fiyat, banka hesabı ve komisyon değişiklikleri işlem loguna yazılmalı.
• Şüpheli giriş ve yoğun API isteği için rate limit uygulanmalı.

SEO ve müşteri deneyimi nasıl korunmalı?

Marketplace yapısında ürün sayısı hızla artar. Bu artış SEO için fırsat olabilir, fakat kontrolsüz ürün sayfaları düşük kaliteli içerik, kopya açıklama, eksik görsel ve stokta olmayan ürün riski de yaratır. Platform, ürün kabul kriterlerini SEO ve müşteri deneyimiyle birlikte belirlemelidir.

Teknik SEO danışmanlığı açısından marketplace yapısında şu kararlar önemlidir:

• Satıcı mağaza sayfaları indexlenecek mi?
• Aynı ürün birden fazla satıcıda varsa tek ürün sayfası mı, satıcı bazlı ayrı sayfa mı kullanılacak?
• Stokta olmayan satıcı teklifleri ürün sayfasında nasıl gösterilecek?
• Kopya ürün açıklamaları kalite kontrolünden geçecek mi?
• Ürün structured data fiyat ve stok bilgisiyle tutarlı mı?
• Satıcı puanı, teslimat süresi ve iade politikası ürün sayfasında görünür mü?

Google'ın ürün yapılandırılmış veri dokümanı, satın alınabilir ürün sayfalarında merchant listing özelliklerinin fiyat, stok, kargo ve iade gibi daha ayrıntılı ürün bilgilerini desteklediğini açıklar Google Search Central. Marketplace ürün sayfalarında bu bilgilerin satıcı teklifleriyle çelişmemesi gerekir.

Başlamadan önce marketplace checklist'i

Marketplace projesine başlamadan önce teknik geliştirmeden önce iş kuralları netleştirilmelidir. Aşağıdaki kontrol listesi ilk planlama için kullanılabilir:

• Marketplace modeli ürün bazlı mı, hizmet bazlı mı, B2B mi olacak?
• Satıcı başvuru, doğrulama ve onay süreci yazıldı mı?
• Satıcı panelinde ürün, sipariş, kargo, iade ve kazanç ekranları planlandı mı?
• Ürün yayınlama onayı kategori ve satıcı riskine göre ayrıldı mı?
• Komisyon, kesinti, kargo ve iade maliyeti satıcıya açık gösteriliyor mu?
• Ödeme ve payout akışında platform, müşteri ve satıcı sorumlulukları net mi?
• Sepet içinde çok satıcılı sipariş alt siparişlere ayrılıyor mu?
• Kargo modeli platform anlaşmalı, satıcı anlaşmalı veya karma mı olacak?
• Satıcı API/XML entegrasyonu ve manuel ürün girişi birlikte desteklenecek mi?
• Satıcı yetkileri, loglar, güvenlik ve veri erişimi test edildi mi?

Sonuç: Marketplace, ürün sayısından önce kural mimarisidir

E-ticaret sitesinde satıcı paneli ve marketplace yapısı kurmak, ürün sayısını artırmanın teknik yolu gibi görülebilir. Asıl mesele ise kuralları doğru tasarlamaktır. Satıcı kabulü, ürün onayı, ödeme, komisyon, sipariş ayrıştırma, kargo, iade, stok, güvenlik ve SEO kontrolü net değilse platform büyüdükçe karmaşa da büyür.

Webioo, marketplace projelerinde satıcı panelini yalnızca ürün giriş ekranı olarak değil; ödeme, hakediş, stok, kargo, iade, API entegrasyonu, SEO ve yönetim paneli denetimiyle birlikte planlar. Böylece platform hem satıcılar için kullanılabilir hem müşteriler için güvenilir hem de işletme için yönetilebilir hale gelir.