Çok Satıcılı Checkout ve Ödeme Sistemi Nasıl Kurulur?

Pazaryeri Checkout'u Tek Sepet Görünümünün Arkasında Çoklu Operasyon Yönetir

Müşteri tek sepet ve tek ödeme deneyimi beklerken arka planda ürünler farklı satıcılara, kargo koşullarına ve sipariş alt akışlarına ayrılabilir. Kurulumun görevi bu karmaşıklığı müşteriye taşımadan doğru sipariş ve ödeme kayıtlarına dönüştürmektir.

1. Sepet Veri Modeli

• Sepet.
• Satıcı grubu.
• Ürün/varyant.
• Adet.
• Birim fiyat.
• İndirim.
• Kargo koşulu.
• Vergi/fiyat bileşenleri iş modeline göre.

Sepette satıcı kimliği her kalemle ilişkilendirilmelidir. Böylece checkout, sipariş ve finans tarafında ayrıştırma mümkün olur.

2. Sepete Ekleme Anındaki Kontroller

• Ürün yayında mı?
• Satıcı satışa açık mı?
• Varyant geçerli mi?
• Stok yeterli mi?
• Fiyat güncel mi?
• Teslimat bölgesine uygun mu?
• Adet limiti var mı?

Sepete eklenen veri checkout'a kadar değişebilir. Bu nedenle kritik bilgiler ödeme öncesinde tekrar doğrulanmalıdır.

3. Çok Satıcılı Sepetin Sunumu

Müşteri ürünleri tek sepet içinde görürken satıcı bazlı teslimat veya kargo farklılıklarını anlayabilmelidir.

• Satıcı adı.
• Ürünler.
• Tahmini teslimat.
• Kargo ücreti/koşulu.
• Satıcıya özgü kampanya varsa.
• Toplam sipariş özeti.

4. Checkout Adımlarını Sadeleştirin

1. Müşteri/iletişim.
2. Teslimat adresi.
3. Kargo/teslimat seçenekleri.
4. Ödeme.
5. Sipariş özeti ve gerekli onaylar.
6. Ödeme ve sipariş sonucu.

Gereksiz alanları kaldırın; ancak siparişin yerine getirilmesi ve geçerli süreç için gerekli bilgileri eksiltmeyin.

5. Üyelik Zorunluluğunu İş Modeline Göre Değerlendirin

Misafir checkout kullanılacaksa sipariş takibi, iletişim doğrulaması, iade ve destek süreçlerinin üyelik olmadan nasıl çalışacağı tasarlanmalıdır.

6. Adres ve Teslimat Doğrulaması

• Teslimat bölgesi.
• Posta/il/ilçe alanları.
• Telefon/iletişim.
• Satıcı veya ürün bazlı teslimat kısıtı.
• Kargo servis uygunluğu.

Adres hatası ödeme sonrasında fark edilirse sipariş operasyonunu ve müşteri deneyimini bozabilir.

7. Kargo Ücretini Satıcı Bazında Hesaplayın

Tek sepet içinde farklı satıcılar farklı paketler oluşturabilir. Kargo ücretinin sepet toplamına nasıl yansıyacağını açık bir kuralla belirleyin.

8. Kampanya ve İndirim Dağıtımı

Sepet indirimi finansal kayıtlara dağıtılabiliyor olmalıdır. İndirimin platform mu satıcı mı tarafından karşılandığı hakediş hesabını etkiler.

• Platform kuponu.
• Satıcı indirimi.
• Kategori kampanyası.
• Ücretsiz kargo desteği.
• Ortak finansmanlı kampanya.

9. Ödeme Öncesi Son Doğrulama

1. Stok yeniden kontrol edilir.
2. Fiyat yeniden doğrulanır.
3. Satıcı durumu kontrol edilir.
4. Kargo/teslimat yeniden hesaplanır.
5. İndirim geçerliliği kontrol edilir.
6. Nihai tahsilat tutarı oluşturulur.

Müşteriye gösterilen nihai tutar ile ödeme sağlayıcısına gönderilen tutar aynı güvenilir sunucu hesabından üretilmelidir.

10. Ödeme Kaydı ile Siparişi Ayırın

Ödeme girişimi ve sipariş aynı kavram değildir. Bir sipariş için başarısız ve başarılı birden fazla ödeme girişimi oluşabilir.

• payment_attempt_id.
• Sipariş/checkout referansı.
• Tutar.
• Para birimi.
• Sağlayıcı işlem ID.
• Durum.
• Başlangıç/bitiş zamanı.
• Hata kodu.

11. Ödeme Durumları

• Başlatıldı.
• Doğrulama bekliyor.
• Başarılı.
• Başarısız.
• İptal.
• İade edildi/kısmi iade.
• İnceleme/istisna.

Sağlayıcı terminolojisini doğrudan kullanıcıya yansıtmak yerine platformun ortak durum modeline eşleyin.

12. 3D Secure / Ek Doğrulama Akışı

Kullanılan ödeme yönteminde ek doğrulama gerekiyorsa yönlendirme, geri dönüş ve sunucu tarafı doğrulama adımları kesintiye dayanıklı olmalıdır.

13. Callback/Webhook İşleme

1. Bildirimi al.
2. Kaynağı/imzayı doğrula.
3. İşlem referansını bul.
4. Tutar ve para birimini kontrol et.
5. Mevcut durumu kontrol et.
6. Idempotent biçimde güncelle.
7. Sipariş/finans olayını tetikle.
8. Sonucu logla.

14. Idempotency

Ödeme sağlayıcısı aynı bildirimi tekrar gönderebilir. Aynı işlem ikinci kez işlendiğinde yeni sipariş, komisyon veya hakediş oluşturmamalıdır.

15. Sipariş Ne Zaman Oluşmalı?

İş modeline göre geçici sipariş rezervasyonu ödeme öncesi oluşturulabilir; ancak 'ödenmiş sipariş' statüsü yalnız doğrulanmış ödeme sonucuyla verilmelidir.

Stok rezervasyon süresi ve başarısız ödeme sonrası rezervasyonun nasıl serbest bırakılacağı ayrıca tanımlanmalıdır.

16. Ana Sipariş ve Satıcı Alt Siparişleri

Başarılı checkout sonrasında müşteri için bir ana sipariş; operasyon için satıcı bazlı alt siparişler oluşturulabilir.

17. Sipariş Kalemi Finansal Snapshot'ı

Sipariş anındaki fiyat, indirim, komisyon kuralı ve satıcı bilgisi daha sonra değişse bile geçmiş işlem yeniden hesaplanmamalıdır.

• Birim fiyat.
• Adet.
• İndirim payı.
• Komisyon oranı/kuralı.
• Komisyon tutarı.
• Satıcı payı.
• Kargo/diğer paylar uygun olduğunda.

18. Başarılı Ödeme Sonrası İşlemler

1. Ödemeyi başarılı işaretle.
2. Siparişi kesinleştir.
3. Alt siparişleri oluştur/kesinleştir.
4. Stok hareketini tamamla.
5. Finansal kayıtları oluştur.
6. Satıcılara bildirim gönder.
7. Müşteriye onay göster/gönder.
8. Analitik olayı kaydet.

Bu zincirde bir adım başarısız olursa görünür retry/istisna mekanizması olmalıdır.

19. Başarısız Ödeme Deneyimi

Müşteriye teknik hata yerine anlaşılır sonuç ve yeniden deneme yolu sunun.

• Sipariş iki kez oluşmamalı.
• Stok sonsuza kadar rezerve kalmamalı.
• Başarısız girişim kaydedilmeli.
• Yeni ödeme girişimi eski kayda bağlanabilmeli.

20. Ödeme Başarılı, Sipariş Oluşmadı Senaryosu

Bu kritik finansal istisna otomatik olarak tespit edilebilmelidir.

1. Başarılı sağlayıcı işlemini tespit et.
2. Yerel sipariş kaydını ara.
3. Eksikse istisna kuyruğuna al.
4. Güvenli yeniden işleme uygunsa çalıştır.
5. Değilse finans/operasyon incelemesine yönlendir.
6. Müşteri etkisini çöz.

21. İade ve Kısmi İade

İade sipariş kalemi seviyesinde yönetilebilmelidir. Bir satıcının ürünü iade edildiğinde diğer satıcıların kalemleri etkilenmemelidir.

• İade edilebilir tutar.
• Daha önce iade edilen tutar.
• Sağlayıcı refund ID.
• İade nedeni.
• Finansal ters kayıt.
• Durum.

22. Ödeme Mutabakatı

Platform ödeme kayıtları ile ödeme sağlayıcısının işlem kayıtları düzenli karşılaştırılmalıdır.

• Platformda başarılı / sağlayıcıda yok.
• Sağlayıcıda başarılı / platformda yok.
• Tutar farkı.
• Çift işlem.
• Refund farkı.
• Durum farkı.

Farklar otomatik kapanmamalı; açıklanabilir sonuca bağlanmalıdır.

23. Checkout KPI'ları

• Sepet → checkout.
• Checkout → ödeme başlatma.
• Ödeme başarı oranı.
• 3D doğrulama başarı oranı uygun olduğunda.
• Teknik ödeme hata oranı.
• Sepet terk.
• Orphan payment sayısı.
• Çift işlem engelleme.
• Refund başarı süresi.

24. Uçtan Uca Test Senaryoları

1. Tek satıcı / tek ürün başarılı ödeme.
2. İki satıcı / tek ödeme.
3. Stok ödeme öncesi tükendi.
4. Fiyat checkout sırasında değişti.
5. Ödeme başarısız → yeniden deneme.
6. Callback iki kez geldi.
7. Başarılı ödeme → callback gecikti.
8. Başarılı ödeme → sipariş kayıt hatası.
9. Tek kalem kısmi iade.
10. Tam iade.

Uygulama: Checkout ve Ödeme Akış Haritası

1. Sepet veri modelini yazın.
2. Checkout adımlarını belirleyin.
3. Satıcı bazlı kargo hesabını tanımlayın.
4. Kampanya maliyet sahibini kaydedin.
5. Ödeme girişimi durumlarını belirleyin.
6. Callback doğrulama adımlarını yazın.
7. Idempotency anahtarını belirleyin.
8. Ana sipariş/alt sipariş modelini çizin.
9. Finansal snapshot alanlarını seçin.
10. Başarısız ve orphan payment akışını yazın.
11. 10 test senaryosunu uygulama planına ekleyin.

Siparişin tahsilat tarafını kurduk. Sonraki derste bu tahsilatı satıcı bazında komisyon, hakediş, mahsup ve mutabakat kayıtlarına dönüştüreceğiz.