Dijital Ürün ve Mühendislik
E-Ticaret
Ödeme, stok, fatura ve kargonun birbiriyle uyumlu çalıştığı bir mağaza kuruyoruz ki sipariş arttıkça elle yapılan iş artmasın.
Problem
Sipariş arttıkça sorunlar da artıyor: stok tutmuyor, ödemeler askıda kalıyor, faturalar hâlâ elle kesiliyor.
E-ticaret projeleri genellikle tema seçimiyle başlar. Vitrin ise işin görünen yüzüdür; asıl emek, tek bir siparişin ödeme, stok, fatura ve kargo arasında tutarlı ilerlemesine gider.
Dönüşüm düşükse ürün sayfası yeniden tasarlanır. Kayıp çoğu zaman daha ileridedir: bankadan dönmeyen 3D Secure yanıtları, son adımda çıkan kargo ücreti, stok hatasıyla iptal edilen ödenmiş sipariş. Bunlar ancak ödeme hataları nedenine göre kaydedilirse görünür.
Pazaryerleri riski büyütür. Her kanal kendi stoğunu tutuyorsa aynı ürün iki kez satılır, iptal mağaza puanınızı da götürür.
Bunu yaşıyorsanız
- Kart çekimi yapılıyor ama sipariş panelde görünmüyor.
- Son ürün iki kanalda aynı anda satılıyor.
- Fatura ve kargo etiketleri elle hazırlanıyor.
- Kampanya günlerinde ödeme adımı yavaşlıyor.
Nasıl çalışıyoruz
Platform kararı
Ürün sayısı, kanallar, B2B fiyat kuralları ve ekip kapasitesi; hazır altyapı, headless veya özel geliştirme seçimini belirler.
Ürün veri modeli
Varyant, öznitelik ve fiyat listesi yapısını tanımlıyoruz. Filtreler, site içi arama, pazaryeri beslemeleri ve Product şeması aynı kaynaktan beslenir.
Sipariş durum makinesi
Durumları ve izinli geçişleri yazıyoruz. Ödeme webhook'ları imzayla doğrulanır ve idempotent işlenir; sağlayıcı bildirimi tekrarlasa da ikinci sipariş veya çift iade oluşmaz.
Operasyon ve mevzuat
Stok rezervasyonu, e-Fatura ve e-Arşiv, kargo etiketi ve pazaryeri eşitlemesi arka plan işleriyle çalışır, hatalar görünür kuyruğa düşer. Ön bilgilendirme, mesafeli satış sözleşmesi, KVKK ve İYS adımları ödeme akışına işlenir.
Ne teslim ederiz
- Platform karar dokümanı
- Ürün veri modeli ve aktarım şablonları
- Sipariş durum diyagramı
- Ödeme, fatura ve kargo entegrasyonları
- Hata kuyruğu ve operasyon paneli
- Kampanya öncesi yük testi raporu
Nasıl ölçeriz
- Nedenine göre ayrılmış ödeme tamamlama: tasarım kaybını banka kaybından ayırır.
- Stok kaynaklı iptaller: kanal eşitlemesinin durumunu en açık bu gösterir.
- Siparişten faturaya geçen süre: işin ne kadarının elle yürüdüğünü ortaya koyar.
Birden fazla kanalda satan bir kozmetik markası
Örnek senaryo: Kendi sitesi ve birkaç pazaryerinde satış yapan bir kozmetik markası stoğu her kanalda ayrı izliyor. Tek stok kaynağı belirlenir, her sipariş ürünü anında rezerve eder, kanallar arka plan işleriyle güncellenir. İptaller nedenine göre kodlandığı için kampanyalar gerçek stokla planlanır.
Sık sorulanlar
Hazır altyapı mı, özel geliştirme mi?
Standart katalog ve perakende satışta hazır altyapıyla başlamak daha mantıklıdır. Bayi fiyatları, siparişe özel üretim veya alışılmadık entegrasyonlar sürekli geçici çözüm üretmeye zorluyorsa headless ya da özel geliştirme gündeme gelir.
Ödeme kuruluşunu seçerken neye bakmalıyız?
Komisyonun yanında taksit desteği, 3D Secure başarısı, kart saklama, webhook güvenilirliği ve mutabakat raporlarına bakın. İnce bir soyutlama katmanının arkasındaki ikinci sağlayıcı, kesinti anında yedek olur.
Mevcut mağazamızdan taşınırken ne risk altında?
Eski URL'ler 301 ile eşlenmezse arama trafiği zarar görür. Kayıtlı kart token'ları ödeme sağlayıcısında durduğu için ayrı planlanır. Parola özetleri taşınamıyorsa müşterilerden parola yenilemesi istenir.
Birlikte çalışmadan önce, birlikte düşünelim.
Görüşme talepleri kurucu tarafından yanıtlanır.