Çok Satıcılı Pazaryeri Uygulaması Yaptırma: Kapsam, Maliyet ve Yol Haritası

Kısa cevap: Pazaryeri uygulaması aslında bir finans ve operasyon ürünüdür

Çok satıcılı pazaryeri uygulaması yaptırma kararı, yalnızca ürünlerin listelendiği ve müşterinin sepete eklediği bir mobil uygulama siparişi değildir. Asıl ürün; satıcıların sisteme kabul edildiği, her ürünün doğru satıcı ve stokla eşleştiği, tek müşteri siparişinin gerektiğinde parçalara ayrıldığı, komisyonların hesaplandığı, iadelerin sorumlu tarafa yönlendirildiği ve finans ekibinin hakedişleri açıklayabildiği işletim modelidir. Mobil arayüz bu modelin müşteriye görünen yüzüdür.

Sağlam bir ilk sürümde her ihtimali çözmek gerekmez. Ancak para ve sipariş hareketlerinin temel kuralları daha ilk günden tanımlanmalıdır. Bir müşterinin iki satıcıdan aldığı ürünler tek ödeme ile mi tahsil edilecek? Satıcı bakiyesi sipariş verildiğinde mi, teslim gerçekleştiğinde mi oluşacak? Kupon maliyetini platform mu, satıcı mı paylaşacak? Kısmi iade yapıldığında komisyon nasıl geri alınacak? Bu sorular cevapsızsa güzel görünen uygulama gerçek sipariş başladığında manuel tablolara bağımlı kalır.

Bu rehber, teklif aşamasına yaklaşmış girişim ve işletmeler için kapsamı somutlaştırır. Buradaki bilgiler hukuki veya mali müşavirlik görüşü yerine geçmez; ticari modeliniz ödeme kuruluşu, hukuk ve muhasebe paydaşlarıyla ayrıca doğrulanmalıdır.

Önce pazaryeri tipini adlandırın

Aynı teknoloji etiketi altında farklı ekonomiler bulunur. B2C ürün pazaryerinde katalog, kargo ve iade baskındır. Hizmet pazaryerinde uygunluk, teklif, randevu ve hizmet tamamlama kanıtı öne çıkar. B2B modelde bayi koşulları, minimum sipariş, vadeli çalışma ve kurumsal onay gerekebilir. İkinci el modelde ilan moderasyonu, kullanıcılar arası mesajlaşma ve güven mekanizmaları kritik olur. Talep toplayıp satıcıdan fiyat alan bir sistem ise klasik sepete göre bambaşka bir akış ister.

Bu ayrım teklifin temelidir; çünkü veri modeli ve yönetim paneli aynı kalmaz. “Amazon benzeri” ifadesi kapsam değildir. Teklif brief'inde hangi tarafın ne sattığı, platformun işlemdeki rolü, teslimatın kime ait olduğu ve gelirin nasıl oluştuğu açıkça yazılmalıdır.

Kullanıcı rolleri ve uçtan uca akışlar

Müşteri

Müşteri; kayıt veya misafir devam etme, adres seçme, katalogda arama, filtreleme, satıcı ve ürün koşullarını görme, sepete ekleme, ödeme, sipariş takibi, iptal/iade talebi, değerlendirme ve destek akışlarını kullanır. Güven için tahmini teslimat, satıcı bilgisi, iade şartı ve toplam maliyet karar anından önce görünmelidir. Aynı sepette farklı satıcılar varsa kargo ve teslimat beklentisi satır bazında açıklanmalıdır.

Satıcı ve satıcı çalışanı

Satıcı başvurur, şirket veya kimlik belgelerini iletir, sözleşme/onay adımlarını tamamlar, mağazasını açar, ürün ve varyant oluşturur, fiyat-stok günceller, siparişi kabul eder, hazırlık ve kargo durumunu işler, iadeye yanıt verir ve finansal hareketlerini izler. Bir satıcının birden fazla çalışanı olacaksa mağaza sahibi, katalog editörü, sipariş operatörü ve finans görüntüleyicisi gibi alt yetkiler gerekir. Her çalışana aynı yetkiyi vermek hem hata hem veri sızıntısı riskidir.

Platform operasyonu

Operasyon ekibi satıcı başvurusunu inceler; yasaklı veya eksik ürünleri yönetir; kategori, özellik ve komisyon kurallarını tanımlar; sipariş istisnalarını çözer; iade uyuşmazlıklarını ele alır; kampanyaları yayımlar ve destek kayıtlarını ilişkilendirir. Yönetim paneli yalnızca CRUD ekranlarından oluşmamalıdır. Geciken kabul, stoksuz iptal, bekleyen iade, negatif bakiye ve başarısız ödeme gibi “aksiyon kuyrukları” üretmelidir.

Finans ve destek

Finans rolü tahsilat, komisyon, hizmet bedeli, kupon katkısı, iade, kesinti, satıcı bakiyesi ve ödeme kayıtlarını aynı sipariş üzerinde uzlaştırabilmelidir. Destek çalışanı ise gereğinden fazla finansal veya kişisel veri görmeden müşterinin sorusunu çözmelidir. Hassas alanların maskelenmesi ve işlem geçmişinin değiştirilemez denetim kayıtlarıyla izlenmesi önemlidir.

Tipik akış şu zincirdir: satıcı kabulü → katalog onayı → ürün yayını → müşteri sepeti → ödeme yetkilendirmesi → satıcı bazında sipariş parçaları → hazırlık/kargo → teslim → iade penceresi → satıcı bakiyesi → mutabakat. Her ok için hata ve geri dönüş yolu ayrıca yazılmalıdır.

Para hareketi tasarımı: komisyon tablosundan daha fazlası

Pazaryeri yazılımının en pahalı hatası, finansal defteri sonradan düşünmektir. Sipariş toplamı ile satıcıya ödenecek tutar aynı kavram değildir. Sistem; ürün brütü, vergi, kargo, platform indirimi, satıcı indirimi, komisyon, ödeme hizmet bedeli, iade ve düzeltme gibi hareketleri ayrı kayıtlar halinde saklamalıdır. Geçmiş bir sipariş, komisyon oranı daha sonra değişse bile aynı sonucu vermelidir; bu nedenle kuralın sipariş anındaki sürümü korunur.

Ödeme sağlayıcısının pazaryeri çözümü seçilmeden “otomatik bölüştürme” varsayımı yapılmamalıdır. Alt üye işyeri kabulü, tahsilatın ne zaman kesinleştiği, blokaj, kısmi iade ve ters ibraz senaryoları sağlayıcıyla doğrulanır. Kart verisini uygulama veya kendi sunucularınızda tutmak yerine ödeme kuruluşunun güvenli bileşenleri ve token yaklaşımı tercih edilir. Uygulama içindeki fiziksel ürün ve hizmet ödemeleri ile dijital içeriklerin mağaza kuralları aynı değildir; hedef kullanım Apple App Review Guidelines üzerinden ayrıca kontrol edilmelidir.

MVP ve ileri faz karar matrisi

MVP'yi küçültmenin güvenli yolu finansal doğruluğu veya yetkilendirmeyi çıkarmak değildir. Satıcı uygulamasını web paneliyle başlatmak, otomatik ürün eşleştirmeyi manuel onaya bırakmak ya da tek lojistik modeliyle çıkmak kapsamı düşürebilir. Fakat sipariş durumu, iade izi ve para hareketlerinin açıklanabilirliği ertelenmemelidir.

Teknik mimari ve entegrasyon sınırları

Müşteri mobil uygulaması, satıcı paneli ve operasyon paneli aynı backend API üzerinde farklı yetkilerle çalışabilir. Çekirdekte kimlik ve yetki, katalog, fiyat-stok, sepet, sipariş, ödeme hareketleri, iade, bildirim ve raporlama alanları bulunur. Başlangıçta iyi sınırlandırılmış modüler bir servis çoğu ekip için yönetilebilir olabilir; sipariş hacmi ve ekip büyüdüğünde belirli alanlar bağımsız ölçeklenebilir. “Mikroservis” kelimesi tek başına kalite göstergesi değildir.

Ödeme ve kargo çağrıları ağ hatası yüzünden tekrarlanabilir. Bu yüzden aynı isteğin ikinci kez sipariş veya iade oluşturmamasını sağlayan idempotency anahtarları, olay kuyruğu ve yeniden deneme politikaları tasarlanır. Webhook imzaları doğrulanır; sağlayıcıdan geç gelen durumlar sipariş geçmişine işlenir. Arama motoru, görsel depolama/CDN, e-posta/SMS, push bildirim, analitik, muhasebe/e-fatura ve kargo servislerinin her biri için kota, hata, test ortamı, veri sahipliği ve sağlayıcı değişimi planlanmalıdır.

Katalog aramasında ürün adı kadar kategori özellikleri, yazım hatası toleransı, filtre ve stok durumu önemlidir. Ancak öneri motoru için yeterli veri oluşmadan karmaşık yapay zekâ bütçesi ayırmak yerine arama sorgusu, sonuç tıklaması, sepete ekleme ve satın alma olaylarını doğru toplamak daha değerlidir.

Güvenlik, KVKK ve ticari uyum

Pazaryeri; müşteri adresi, satıcı belgeleri, çalışan kayıtları ve finansal hareketler gibi farklı veri sınıflarını işler. Proje başlangıcında veri sorumlusunun ve varsa veri işleyenlerin rolleri hukuk danışmanıyla belirlenmeli; işleme amacı, hukuki sebep, saklama süresi, aktarım ve silme süreci veri envanterine bağlanmalıdır. Her kullanıcı yalnızca görevi için gereken veriye erişmelidir. Satıcı A'nın Satıcı B siparişini görmesi gibi yatay yetki açıkları API testlerinde özellikle aranır.

Parolalar güçlü tek yönlü algoritmalarla saklanır; yönetici ve finans rollerinde çok faktörlü doğrulama düşünülür. Dosya yüklemelerinde tip/boyut kontrolü ve zararlı içerik taraması, oturumlarda süre ve cihaz yönetimi, API'lerde hız sınırı, gizli bilgilerde güvenli kasa, yedeklerde şifreleme ve düzenli geri yükleme testi beklenir. Mobil güvenlik kabul ölçütleri için OWASP Mobile Application Security kaynakları kullanılabilir. Veri envanteri ve diğer yükümlülükler için KVKK uyum süreci duyurusu resmi başlangıç kaynaklarından biridir.

Elektronik ticaret veya aracılık modelinde kayıt ve bildirim yükümlülükleri değişebilir. Ticaret Bakanlığı ETBİS bilgilendirmesi incelenmeli; güncel yükümlülükler faaliyet modelinize göre uzmanlarla doğrulanmalıdır.

Maliyet ve süreyi gerçekten değiştiren etkenler

Sabit fiyat uydurmak yerine iş kırılımı üzerinden tahmin yapılmalıdır. En belirgin etkenler müşteri, satıcı ve yönetim arayüzlerinin sayısı; ürün/varyant modeli; çoklu satıcılı sepet; ödeme ve hakediş mantığı; kargo ve e-belge entegrasyonları; iade/uyuşmazlık derinliği; çoklu dil/para birimi; raporlama; veri aktarımı; performans hedefi ve güvenlik kapsamıdır. Hazır tasarım sistemiyle ilerlemek ile özgün araştırma ve UI tasarlamak da aynı efor değildir.

Takvim; keşif, deneyim tasarımı, teknik hazırlık, geliştirme, entegrasyon testi, kullanıcı kabulü ve mağaza değerlendirmesi olarak ayrılmalıdır. Ödeme kuruluşunun ticari kabulü veya dış API erişimi yazılımdan bağımsız takvim riski yaratabilir. Teklifte bu bağımlılıklar ile müşteri tarafından sağlanacak sözleşme, metin, kategori, komisyon ve test hesaplarının teslim tarihleri görünmelidir.

Teslimatlar ve kabul ölçütleri

İyi bir teklif yalnızca “iOS ve Android uygulaması” yazmaz. En azından onaylanmış kapsam ve kullanıcı hikâyeleri, akışlar/prototip, tasarım dosyaları, kaynak kod depoları, API ve veri modeli dokümantasyonu, ortam ve dağıtım tanımları, müşteri-satıcı-yönetim arayüzleri, entegrasyon listesi, test senaryoları, güvenlik kontrol sonuçları, analitik olay sözlüğü, mağaza yayın paketleri, yedekleme/izleme planı ve yönetici eğitimi teslimat olarak adlandırılır.

Kabul senaryoları para ve istisna üzerinden yazılmalıdır: iki satıcılı sipariş doğru bölünüyor mu; bir kalem iade edildiğinde bakiye ve komisyon düzeliyor mu; aynı webhook iki kez geldiğinde çift kayıt oluşuyor mu; yetkisiz satıcı başka mağazayı okuyabiliyor mu; başarısız ödeme stok ayırıyor mu; satıcı ekstresi sipariş hareketleriyle uzlaşıyor mu? “Ekran açılıyor” testi ticari kabul için yeterli değildir.

Başarıyı hangi KPI'larla ölçeceksiniz?

Pazaryerinin kuzey yıldızı yalnızca indirme değildir. Arz tarafında onaylanan satıcının ilk ürünü yayımlama süresi, aktif satıcı oranı, stok doğruluğu ve sipariş kabul süresi; talep tarafında aramadan ürün görüntülemeye geçiş, sepete ekleme, ödeme dönüşümü, tekrar satın alma ve destek oranı izlenir. Operasyonda stoksuz iptal, geç sevk, iade çözüm süresi ve ilk temasta çözüm önemlidir. Finans tarafında brüt işlem hacmi tek başına yetmez; net gelir, komisyon tahsilatı, promosyon katkısı, iade ve mutabakat farkı birlikte görülmelidir.

Olay isimleri yayın öncesi tanımlanır. Aynı “purchase” olayı hem ödeme alındığında hem teslimde gönderilirse raporlar karar veremez hale gelir. KPI panosu karar sahiplerine bağlanmalı; her metriğin tanımı, kaynağı, zaman penceresi ve sorumlusu bulunmalıdır.

En sık görülen riskler ve önleyici kararlar

• Likiditeyi yazılımla çözmeye çalışmak: Satıcı ve müşteri edinme planı yoksa özellik fazlalığı pazar oluşturmaz. Dar bir kategori veya bölgeyle doğrulama yapılır.
• Operasyonu görünmez bırakmak: İstisna kuyrukları yoksa ekip veritabanı veya tablo üzerinden yangın söndürür. Yönetim paneli gerçek günlük işlere göre prototiplenir.
• Belirsiz finans kuralları: Komisyon ve iade sözle tarif edilirse kodda farklı yorumlar çıkar. Örnek siparişler üzerinden beklenen defter hareketleri yazılır.
• Satıcı verisinin zayıflığı: Kategori ve özellik standardı olmadan arama kalitesi bozulur. Katalog yönetişimi ve toplu yükleme doğrulamaları kurulur.
• Tek sağlayıcıya kör bağımlılık: Ödeme, SMS veya kargo cevabı doğrudan çekirdek modele yayılırsa değişim zorlaşır. Adaptör sınırları ve hata senaryoları belirlenir.
• Her şeyi ilk sürüme alma: Sadakat, sohbet, reklam ve gelişmiş öneri çekirdeği geciktirebilir. Özellikler gelir, risk azaltma veya öğrenme değerine göre sıralanır.

Teklif istemeden önce doldurulacak brief

1. Pazaryeri tipi, hedef kategori, hizmet bölgesi ve ilk 12 aylık ticari hedef.
2. Müşteri, satıcı, satıcı çalışanı, operasyon, destek ve finans rollerinin yetkileri.
3. Ürün/hizmet veri yapısı; varyant, stok, fiyat, minimum sipariş ve onay kuralları.
4. Komisyon, üyelik, ilan bedeli veya ek hizmetlerden oluşan gelir modeli.
5. Ödeme alma, satıcıya ödeme, iptal, kısmi/tam iade ve uyuşmazlık senaryoları.
6. Teslimatı kimin yönettiği; kargo firması, kurye ağı veya dijital teslim seçenekleri.
7. ERP, muhasebe, e-belge, CRM, PIM, harita, SMS/e-posta gibi mevcut sistemler.
8. Beklenen satıcı, SKU, sipariş ve eşzamanlı kullanım ölçeği; kampanya pikleri.
9. KVKK rolleri, saklama politikası, hedef ülke ve sektörel mevzuat gereksinimleri.
10. İçerik, sözleşme, mağaza hesapları, ürün verisi ve operasyon kararlarının sahipleri.

Önerilen proje süreci

İlk adım iş modeli ve risk atölyesidir. Ekip, örnek bir siparişi başvurudan mutabakata kadar yürütür ve bilinmeyenleri çıkarır. Ardından müşteri ile satıcı deneyimi ve operasyon paneli birlikte prototiplenir; çünkü bir taraftaki kolaylık diğer tarafta manuel yük yaratabilir. Teknik keşifte ödeme/kargo sağlayıcılarıyla test hesapları açılır, veri modeli ve entegrasyon sözleşmeleri netleşir.

Geliştirme, uçtan uca çalışan dikey dilimler halinde ilerler: örneğin satıcı kabulü ve ilk ürün; ardından sepetten başarılı siparişe; sonra kargo ve iade. Otomatik testler kritik hesaplama ve yetkilendirmeyi korur. Pilot, sınırlı satıcı ve gerçek operasyon ekibiyle yürütülür; bulunan sorunlar ölçeklemeden önce düzeltilir. Yayın sonrasında hata bütçesi, izleme, destek sorumluluğu ve ürün backlog'u düzenli olarak yönetilir.

Sık sorulan sorular

Hazır pazaryeri yazılımı mı, özel geliştirme mi seçilmeli?

Standart katalog, komisyon ve lojistikle hızlı doğrulama hedefleniyorsa hazır ürün değerlendirilebilir. İş modelinin avantajı özel fiyatlama, teklif, sektör verisi, karma teslimat veya mevcut sistemlerle derin entegrasyonsa özel geliştirme daha anlamlı olabilir. Karar, lisans ücretinden önce kritik farklılaşmanın hazır çözümde ne ölçüde karşılandığına göre verilmelidir.

Satıcılar ürünleri nasıl yükler?

MVP'de form ve doğrulamalı CSV yükleme yeterli olabilir. SKU hacmi büyüdükçe API, XML/feed, ERP veya PIM bağlantısı gerekir. Her yöntemde kategori eşleştirme, zorunlu özellik, görsel kalitesi, mükerrer ürün ve hata raporu tasarlanmalıdır.

Tek sepet içinde birden fazla satıcı olabilir mi?

Olabilir; ancak sipariş bölme, ayrı kargo, teslimat tahmini, kampanya dağıtımı, iade ve muhasebe daha karmaşık hale gelir. Ticari faydası ilk sürümde bu karmaşıklığı karşılamıyorsa geçici olarak tek satıcılı sepet kuralı seçilebilir.

Kaynak kod ve mağaza hesapları kimin olmalı?

Sözleşmede fikri haklar, üçüncü taraf lisansları, kaynak depo erişimi ve teslim koşulları açık olmalıdır. Apple/Google, bulut, alan adı, ödeme ve analitik gibi üretim hesaplarının mümkün olduğunca müşteri kuruluşu adına açılması iş sürekliliğini güçlendirir.

Yayından sonra hangi bakım gerekir?

İşletim sistemi ve SDK güncellemeleri, güvenlik yamaları, entegrasyon değişiklikleri, izleme uyarıları, yedekleme testleri, mağaza gereksinimleri ve operasyon kaynaklı iyileştirmeler sürer. Bakım; müdahale süreleri, dahil saatler, acil durum kanalı ve yeni özellik ayrımıyla sözleşmeye bağlanmalıdır.

Sonuç: önce işlem gerçeğini, sonra ekranları tasarlayın

Başarılı bir çok satıcılı pazaryeri, en fazla özelliği yayımlayan değil; siparişi, sorumluluğu ve parayı her taraf için anlaşılır yöneten üründür. Yatırım kararından önce birkaç gerçekçi sipariş ve iade senaryosunu satıcı, operasyon ve finans ekipleriyle masada yürütün. Bu çalışma MVP sınırını, entegrasyon riskini ve teklif karşılaştırmasını belirgin biçimde iyileştirir.

MobiCraft ile görüşürken mevcut iş modelinizi, örnek ürün verinizi ve çözmek istediğiniz ilk işlem akışını paylaşabilirsiniz. Birlikte müşteri uygulamasını, satıcı çalışma alanını ve yönetim operasyonunu aynı kapsam haritasında ele alıp teklif verilebilir fazlara ayırabiliriz. Projeniz için görüşme başlatın veya önce mobil uygulama geliştirme hizmetlerini inceleyin.