E-Ticaret Mobil Uygulama Yaptırma: Ödeme, Stok ve ERP Rehberi
E-ticaret mobil uygulama yaptırırken ödeme, stok, fiyat, sipariş ve ERP entegrasyonunu doğru mimariyle planlayın; teklif ve teslim risklerini kıyaslayın.
Kısa cevap: E-ticaret uygulaması bir katalog değil, dağıtık sipariş sistemidir
E-ticaret mobil uygulama yaptırma projesinin değeri ürün kartlarını telefonda göstermekten gelmez. Kullanıcının gördüğü fiyatın, satışa uygun stokla; ödemenin, tek ve doğru siparişle; siparişin, ERP ve depo operasyonuyla tutarlı çalışmasından gelir. Güzel bir arayüz bu zincirin yalnızca görünen yüzüdür. Kaynak sistemler ve durum geçişleri tasarlanmadan başlanan uygulama, kampanya gününde yanlış stok satar, ödemesi alınan siparişi ERP’ye düşürmez veya aynı işlemi iki kez oluşturur.
Bu nedenle ilk teklif sorusu “Flutter mı native mi?” olmamalıdır. Önce ürün, fiyat, stok, müşteri ve sipariş verisinin otorite kaynakları belirlenmelidir. Mevcut e-ticaret platformu, ERP, pazaryeri yönetimi, depo sistemi ve ödeme sağlayıcısı aynı bilginin farklı kopyalarını tutuyorsa hangi sistemin hangi kararı verdiği yazılır. Mobil istemci bu karmaşıklığı kendi içinde çözmez; güvenli bir ticaret API’si veya entegrasyon katmanı üzerinden çalışır.
Uygulama yatırımına hazır işletme profili
Mobil web trafiği güçlü, tekrar müşterisi belirgin, sık satın alınan ürünleri bulunan, sadakat veya mağaza içi deneyim kuran markalar uygulamadan fayda görebilir. Kullanıcı her siparişte adres ve tercihlerini yeniden giriyorsa; hızlı tekrar sipariş, kayıtlı güvenli ödeme tokenı, favori, stok bildirimi ve sipariş takibi sürtünmeyi azaltabilir. Çok şubeli perakendede mağazadan teslim, barkod okuma ve üyelik kartı ayrıca mobil bağlam yaratır.
Uygulama, zayıf ürün bulunabilirliğini veya düzensiz operasyonu tek başına düzeltmez. Web sitesinde yanlış stok, geciken kargo durumu ve tutarsız kampanya varsa mobil kanal aynı sorunu hızlandırır. Ürün veri kalitesi, ERP entegrasyonu, iade süreci ve müşteri hizmetleri hazır olmadan indirme kampanyasına bütçe ayırmak olumsuz yorum üretebilir. Hazırlık değerlendirmesinde yalnızca teknik API değil operasyonun istisna yönetimi de incelenmelidir.
Üç mimari seçenek için karar tablosu
| Yaklaşım | Uygun olduğu durum | Avantaj | Ana risk |
|---|---|---|---|
| Mevcut platformun mobil API’si | Katalog, müşteri ve sipariş yetenekleri yeterliyse | Daha hızlı başlangıç, tek ticaret çekirdeği | API sınırı ve sağlayıcı bağımlılığı |
| Headless kanal katmanı | Web, mobil ve diğer kanallar ortak servis kullanacaksa | Kanal bağımsız deneyim ve merkezi kural | Entegrasyon/operasyon olgunluğu gerektirir |
| Özel ticaret backend’i | İş modeli paket platforma uymayan karmaşık operasyon ise | İş kurallarında yüksek kontrol | Kapsam, bakım ve güvenlik sorumluluğu büyür |
Hazır platform kullanmak düşük kalite anlamına gelmez; özel backend de otomatik rekabet avantajı değildir. Standarda yakın katalog ve sipariş akışında mevcut platformun güvenilir yeteneklerini kullanmak daha akılcı olabilir. Çoklu depo, bayi fiyatı, abonelik kutusu, kiralama veya özel tedarik akışı varsa ayrıştırılmış servis gerekebilir. Karar, lisans maliyetinin yanı sıra değişim hızı, API limitleri, veri taşınabilirliği ve operasyon ekibinin becerisiyle verilir.
İlk sürüm için müşteri yolculuğu
İlk sürümde her özellik yerine gelir yolunu kapatan akışlar uçtan uca ele alınmalıdır: ürün keşfi, arama/filtre, ürün detayı, varyant seçimi, satışa uygun stok, sepet, adres, teslimat yöntemi, ödeme, sipariş sonucu ve takip. Üyelik zorunluluğu dönüşümü düşürüyorsa misafir ödeme ve sonradan hesap ilişkilendirme değerlendirilebilir. Favori, değerlendirme, sadakat ve bildirim ancak temel sipariş zinciri güvenilir olduğunda değerini gösterir.
Her akışın başarısız hali de tasarlanır. Son ürün ödeme sırasında tükendiğinde ne olur? Ödeme bankada onaylandı fakat uygulama bağlantıyı kaybettiğinde kullanıcıya hangi durum gösterilir? Kargo seçeneği adres değişince geçersizleşirse sepet yeniden hesaplanır mı? Kullanıcı sipariş butonuna iki kez dokunursa ikinci sipariş engellenir mi? E-ticaret kalitesi mutlu yol kadar bu istisnalarda belirlenir.
Katalog, fiyat ve kampanya için tek gerçek
Ürün kimliği kanallar arasında kalıcı olmalıdır. ERP malzeme kodu, e-ticaret varyant ID’si ve pazaryeri SKU’su eşleme tablosuyla yönetilir. Renk/beden varyantı, barkod, birim, paket içeriği, vergi sınıfı ve satış durumu aynı anlamı taşımalıdır. Mobil uygulama ürün bilgisini kopya bir veritabanında tutabilir; fakat otorite kaynak ve güncelleme sırası nettir.
Fiyat yalnızca bir sayı değildir. Liste fiyatı, indirim, müşteri segmenti, kupon, kampanya birleşimi, vergi, para birimi, başlangıç/bitiş zamanı ve kanal koşulu vardır. Uygulama ürün ekranındaki fiyatı cihazda hesaplayıp ödeme sistemine güvenmemelidir. Backend, sepeti güncel kurallarla yeniden fiyatlar ve kullanıcıya değişikliği açıkça gösterir. Böylece manipüle edilmiş istemci veya eski önbellek yanlış tahsilata dönüşmez.
Promosyon motoru ilk sürümde aşırı karmaşık kurulursa proje uzar. Gerçek satış takvimi incelenip en çok kullanılan kural türleri seçilebilir: kategori yüzdesi, belirli tutar üzeri indirim, kargo avantajı veya tek kullanımlık kupon gibi. “Tüm kampanyalar” yerine örneklerle kabul kriteri yazılır. Birleşemeyen kuponlar ve iade durumunda indirimin nasıl dağıtıldığı baştan kararlaştırılır.
Stok: Ekrandaki adet ile satılabilir adet aynı değildir
ERP’de görünen fiziksel stoktan ayrılmış siparişler, hasarlı ürünler, güvenlik stoğu ve mağazaya tahsis edilen miktar düşüldüğünde satışa uygun stok elde edilir. Çoklu depo varsa kullanıcının adresi, teslimat sözü ve bölünmüş kargo kararı devreye girer. Mobil uygulama “stokta” bilgisini gösterirken sipariş anında backend tekrar doğrulama yapmalıdır.
Rezervasyon süresi ticari karardır. Ürünü sepete eklemek rezervasyon yaratıyorsa sahte veya terk edilmiş sepet stok kilitleyebilir; yalnızca ödeme başında rezervasyon yapmak yoğun talepte son adımda tükenme yaşatabilir. Sistem, rezervasyonun ne zaman başladığını, ne zaman sona erdiğini ve başarısız ödeme sonrası nasıl serbest bırakıldığını tanımlar. Kampanya veya sınırlı ürün satışında eşzamanlılık ve kuyruk tasarımı ayrıca test edilir.
ERP’yi her ürün sayfasında doğrudan sorgulamak genellikle kırılganlık yaratır. ERP yavaşladığında uygulama da kullanılmaz hale gelir ve istek hacmi lisans/kapasite sınırına çarpabilir. Bunun yerine entegrasyon katmanı, önbellek veya olay akışıyla uygun güncellik hedefi kurulur. Bazı ürünlerde saniyelik, bazılarında dakikalık senkronizasyon kabul edilebilir. “Anlık” kelimesi ölçülebilir gecikme hedefiyle değiştirilmelidir.
Ödeme mimarisi ve mağaza kuralları
Fiziksel ürün satışı, uygulama içindeki dijital içerik veya özellik satışından farklıdır. Apple’ın App Review Guidelines ve Google Play’in Payments policy sayfaları fiziksel ve dijital mal/hizmet ayrımını açıklar. Ürün modeli, faaliyet ülkesi ve güncel mağaza programları için ödeme sağlayıcısı ve hukuk danışmanıyla doğrulama yapılmalıdır; politika metni eski bir blog özetinden kopyalanmamalıdır.
Kart verisi kapsamını küçültmek için PCI DSS uyumlu ödeme sağlayıcısının barındırdığı veya tokenlaştırdığı akışlar tercih edilebilir. PCI Security Standards Council’ın e-ticaret ödeme sayfası ve SAQ uygunluğu açıklaması ödeme sayfasındaki bileşenlerin kaynağının kapsamı etkileyebildiğini gösterir. Hangi SAQ veya kontrol setinin geçerli olduğu uzman değerlendirmesi gerektirir.
Mobil uygulama ham kart bilgisini loglamamalı, analitik aracına göndermemeli veya kendi basit veritabanında saklamamalıdır. Kayıtlı kart deneyiminde sağlayıcının tokenı kullanılır; tokenın hangi müşteri ve işyeri hesabına bağlı olduğu belgelenir. 3D Secure dönüşü, uygulama derin bağlantısı, iptal, zaman aşımı ve kullanıcının uygulamayı kapatması test edilir.
Ödeme sonucu yalnızca kullanıcının telefonundan gelen “başarılı” ekranına güvenmez. Backend sağlayıcının imzalı bildirimi veya doğrulama API’siyle durumu teyit eder. Sipariş yaratma isteğine benzersiz idempotency anahtarı verilerek tekrar dokunma ve ağ yeniden denemesi çift tahsilat/sipariş üretmez. “Ödeme alındı fakat sipariş yok” ve “sipariş var fakat tahsilat belirsiz” durumları için uzlaştırma kuyruğu ile operasyon ekranı gerekir.
ERP ve diğer sistem entegrasyonu
ERP entegrasyonu tek yönlü ürün aktarımı değildir. Ürün, fiyat ve stok ERP’den veya ticaret platformundan uygulamaya; onaylanan sipariş ve müşteri bilgisi karşı yöne gider. ERP sipariş numarası, fatura, sevk, kargo ve iptal durumu tekrar mobil kanala döner. İade ve kısmi iade, ödeme sağlayıcısı ve ERP’de aynı kimliklerle izlenmelidir.
Üç bağlantı deseni kullanılabilir. Senkron API, kullanıcının hemen cevap beklediği fiyat veya sipariş doğrulamasında uygundur; fakat zaman aşımı ve devre kesici ister. Olay/kuyruk, siparişi dayanıklı biçimde diğer sisteme taşır ve yoğunluğu emer; tekrar mesaj için idempotent tüketici gerekir. Zamanlanmış batch, hacmi düşük ve dakikalar/saatler gecikmesi kabul edilen katalog işlemlerinde basit olabilir. Aynı projede bu desenler birlikte kullanılabilir.
Entegrasyon sözleşmesi alan eşlemesi kadar durum makinesini içermelidir. Mobilde “hazırlanıyor”, ERP’de üç farklı depo statüsüne karşılık gelebilir. İptal hangi aşamaya kadar otomatik, hangi aşamadan sonra operasyon onaylıdır? ERP planlı bakımdayken sipariş güvenli kuyrukta bekler mi? Hatalı kayıt nasıl yeniden işlenir ve operatör hangi veriyi düzeltebilir? Bu sorular cevaplanmadan “ERP entegrasyonu dahil” ifadesi fiyat karşılaştırmasına yetmez.
Yönetim ve operasyon ekranları
Müşteri uygulaması tek başına işletilemez. Destek ekibi sipariş zaman çizelgesini, ödeme doğrulamasını, stok rezervasyonunu, ERP/kargo mesajlarını ve hata nedenini tek korelasyon kimliğiyle görmelidir. Yetkili kullanıcı, kişisel veriyi gereksiz göstermeden siparişi arayabilmeli; yeniden deneme gibi riskli işlemler rol ve kayıtla sınırlandırılmalıdır.
Kampanya, banner veya ana sayfa sıralaması sık değişiyorsa uygulama sürümü beklemeden yönetilebilen içerik alanları tasarlanır. Ancak uzaktan yapılandırma iş kurallarını kontrolsüz biçimde değiştiren gizli programlama paneline dönüşmemelidir. Değişiklik önizleme, zamanlama, onay ve geri alma ile yürütülür. Operasyon paneli teklifin dışında bırakılmışsa müşterinin günlük işi nasıl yapacağı ayrıca açıklanmalıdır.
Güvenlik, KVKK ve tüketici akışları
E-ticaret uygulaması kimlik, adres, sipariş ve davranış verisi işler. Veri minimizasyonu, erişim rolü, saklama, silme, log maskeleme ve veri işleyen envanteri tasarıma dahil edilir. KVKK’nın veri güvenliği yükümlülükleri, uygun teknik ve idari tedbir sorumluluğunu hatırlatır. SDK ve analitik envanteri gizlilik beyanlarıyla tutarlı olmalıdır.
Satış akışında ön bilgilendirme, toplam tutar, teslimat, ödeme yükümlülüğü, sipariş teyidi, cayma ve iade süreçleri hukuk ekibince güncel mevzuata göre hazırlanmalıdır. Ticaret Bakanlığının Mesafeli Sözleşmeler hakkında bilgilendirmesi resmi başlangıç kaynağıdır. Mobil tasarım, gerekli bilgiyi küçük ve erişilemez metne gizlememeli; kullanıcının kayıtlarına sonradan ulaşmasını sağlamalıdır.
Maliyet ve süreyi belirleyen etkenler
E-ticaret mobil uygulama fiyatını en çok etkileyen konu ekran sayısı değil entegrasyon derinliğidir. Hazır ve iyi belgeli platform API’si, temiz ürün verisi ve tek depo başlangıcı eforu azaltabilir. Özel ERP, çoklu depo, bayi/segment fiyatı, kampanya birleşimi, farklı ödeme sağlayıcıları, mağazadan teslim, kısmi sevk ve iade kapsamı takvimi büyütür.
İkinci etken kalite ve hacimdir. Normal günde az, kampanya saatinde çok yüksek trafik varsa yük testi ve kuyruk gerekir. Hedef ülkeler; vergi, para birimi, ödeme, dil ve tüketici akışlarını değiştirir. Tasarım sistemi, erişilebilirlik, tablet desteği, analitik, otomatik test ve güvenlik doğrulaması da açıkça fiyatlandırılır.
Üçüncü taraf maliyetleri ayrı görünmelidir: e-ticaret platformu, ERP bağlantısı, ödeme komisyonu, kargo, SMS/e-posta, arama, izleme, bulut ve mağaza üyelikleri. Geliştirme teklifi yalnızca ilk yayın bedeli sunuyorsa toplam sahip olma maliyeti hesaplanamaz. Bakımda hedef SDK güncellemesi, sertifika, entegrasyon değişikliği ve kampanya nöbeti gibi sorumluluklar ayrıca planlanır.
Teslim edilmesi gerekenler
- iOS/Android kaynak kodu, build ve mağaza yayın dokümanı
- Ticaret API’si, şema, kimlik doğrulama ve sürümleme belgesi
- Ürün/SKU, fiyat, stok, müşteri, sipariş ve iade veri eşleme sözlüğü
- ERP, ödeme, kargo ve bildirim entegrasyon durum/yeniden deneme matrisi
- Tasarım kaynakları ve erişilebilir kritik kullanıcı akışları
- Test senaryoları: stok yarışı, çift istek, başarısız ödeme, kısmi iade ve kesinti
- Operasyon paneli, rol/yetki ve denetim kaydı tanımı
- İzleme panelleri, iş metrikleri, alarm/runbook ve uzlaştırma raporları
- Güvenlik, KVKK/SDK envanteri, yedekleme ve geri dönüş prosedürü
- Bilinen kısıt, teknik borç, hesap sahipliği ve bakım geçiş tutanağı
Büyük riskler ve tekliflerde kırmızı bayraklar
ERP dokümanı görülmeden “entegrasyon hazır” denmesi, stok rezervasyon kuralının işletmeye sorulmaması ve ödeme başarısının yalnızca mobil ekrana bağlanması ciddi risklerdir. Diğer uyarılar; kart verisini kendi sunucusunda tutmayı normalleştirmek, kampanya kurallarını cihazda hesaplamak, canlı veride prova yapmak ve mağaza/ödeme hesaplarını geliştiricinin kişisel hesabında açmaktır.
Yalnızca olumlu senaryoyu gösteren demo da yanıltıcıdır. Ağ kesintisi, ERP zaman aşımı, aynı webhook’un tekrar gelmesi, kargo kodunun değişmesi, kupon sonrası iade ve son stok için eşzamanlı sipariş denenmelidir. “Anlık stok” deniyorsa ölçülen gecikme ve tutarsızlıkta kullanıcı davranışı yazılmalıdır.
Teklif ve sözleşme kontrol listesi
- İlk sürümün gelir üreten uçtan uca akışları kabul senaryolarıyla yazılı mı?
- Ürün, fiyat, stok, müşteri ve sipariş için otorite sistem belli mi?
- ERP/API erişimi teklif öncesi teknik ispatla doğrulandı mı?
- Stok rezervasyonu, satışa uygun miktar ve çoklu depo kuralı tanımlı mı?
- Ödeme sağlayıcısı, 3D Secure, webhook, idempotency ve uzlaştırma kapsamda mı?
- Fiziksel/dijital ürün mağaza ödeme kuralları güncel kaynaktan kontrol edildi mi?
- İptal, iade, kısmi sevk ve başarısız entegrasyon operasyonu tasarlandı mı?
- Yönetim paneli ve müşteri hizmetleri araçları teklife dahil mi?
- Performans/yük, güvenlik, gerçek cihaz ve entegrasyon testleri ölçülebilir mi?
- Mağaza, bulut, ödeme ve diğer hesaplar işletmenin kontrolünde mi?
- Üçüncü taraf ücretleri ve yayın sonrası bakım ayrı gösteriliyor mu?
- Kaynak kod, veri eşleme, dokümantasyon ve çıkış desteği sözleşmede mi?
Aşamalı geliştirme süreci
Keşif aşamasında satış hedefi, müşteri segmenti, tekrar satın alma davranışı ve operasyon kısıtları incelenir. Ürün, stok, fiyat, sipariş ve müşteri veri akışı çizilir. ERP, e-ticaret platformu, ödeme ve kargo API’lerinin erişimi doğrulanır. En riskli entegrasyon için küçük teknik ispat yapılır; pazarlama ekranlarından önce sipariş omurgasının mümkün olduğu gösterilir.
Tasarım aşamasında kritik yol prototiplenir ve istisna durumları eklenir. Teknik ekip durum makinelerini, entegrasyon sözleşmelerini, idempotency ve izleme yaklaşımını belirler. MVP, gerçek operasyon ekibinin yürütebileceği teslimlerle fazlanır. Geliştirme boyunca test ortamında sağlayıcı sandbox’ları, sentetik stok ve kontrollü veri kullanılır.
Yayın öncesi sınırlı kullanıcı veya bölge pilotu yapılabilir. Stok tutarlılığı, ödeme-sipariş uzlaştırması, ERP gecikmesi, çökmesiz oturum, arama sonucu ve müşteri hizmetleri hacmi izlenir. Lansman yalnızca indirme hedefiyle değil başarılı sipariş, ödeme yetkilendirme, iptal/iade ve tekrar satın alma sağlığıyla yönetilir. İlk kampanya için kapasite ve olay planı önceden hazırlanır.
Sonuç: Mobil satış başarısı arayüz ile operasyonun aynı siparişte buluşmasıdır
E-ticaret uygulaması yaptırırken en pahalı hata, çalışan ürün ekranlarını çalışan ticaret sistemi sanmaktır. Değer; doğru ürün ve fiyatı göstermenin, satılabilir stoğu korumanın, ödemeyi tek siparişle eşleştirmenin ve sonucu ERP, depo, kargo ve müşteri hizmetlerine taşımanın birlikte çalışmasıdır. MobiCraft’a teklif için mevcut mağaza ve ERP altyapınızı, ödeme sağlayıcınızı, depo modelinizi, kampanya kurallarınızı ve en sık yaşadığınız operasyon istisnalarını paylaşın. İlk sürümü ekran sayısından değil güvenilir sipariş yolundan başlayarak planlayalım.