Sanal POS, taksit, kapıda ödeme ve kargo süreçlerinin sitenize doğru şekilde bağlanması. Ödeme bildirimleri imza doğrulamasıyla işlenir, kargo etiketi ile takip bilgisi otomatik üretilir, iade akışı panele bağlanır.
Hangi ödeme çözümünü seçmeliyim?
İki temel seçenek var ve ikisi de doğru olabilir. Banka sanal POS, bankanızla doğrudan anlaşma yaparsınız; komisyon oranı genellikle daha düşüktür ancak her banka için ayrı entegrasyon ve ayrı mutabakat süreci gerekir. Ödeme kuruluşları ise tek entegrasyonla çok sayıda bankanın kartını ve taksit imkânını sunar, mutabakatı sadeleştirir; buna karşılık komisyon oranı biraz daha yüksektir.
Karar verirken baktığımız ölçüler: aylık işlem hacminiz, taksit ihtiyacınız, hangi bankalarla çalıştığınız, para çekim vadeniz ve operasyon ekibinizin mutabakat kapasitesi. Düşük hacimde başlayan mağazalarda ödeme kuruluşu genellikle daha mantıklı; hacim büyüdükçe doğrudan POS anlaşması komisyon farkını anlamlı hâle getiriyor. İki modeli birlikte kullanmak da mümkün; sistemi buna hazır kuruyoruz.
3D Secure zorunlu mu, dönüşümü düşürür mü?
3D Secure, kart sahibinin banka tarafından doğrulanmasıdır ve ödeme itirazı riskini kart sahibine kaydırdığı için satıcıyı korur. Doğrulama adımı akışa ek bir ekran koyduğu için dönüşümde bir miktar kayıp olabilir; ancak doğrulamasız işlemde yaşanan itiraz ve sahtecilik kayıpları çoğu mağaza için çok daha maliyetlidir.
Bizim önerimiz 3D Secure akışını varsayılan olarak açık tutmaktır. Dönüşüm kaybını azaltmak için akışı hızlandıran ayrıntılara odaklanıyoruz: doğrulama ekranından dönüşte kullanıcının sepetini ve form bilgilerini kaybetmemesi, hata mesajlarının banka jargonu yerine anlaşılır dilde gösterilmesi ve başarısız işlemden sonra tek tıkla yeniden deneme imkânı.
Ödeme bildirimi neden tek başına yeterli değil?
Ödemenin başarılı olduğunu kullanıcının yönlendirildiği sayfadan öğrenmek güvenli değildir; kullanıcı o sayfayı hiç görmeden tarayıcıyı kapatabilir ya da adres satırındaki parametreler değiştirilebilir. Bu yüzden siparişi yalnızca sunucudan sunucuya gelen bildirim üzerinden onaylıyoruz.
Bu bildirimi işlerken üç kural uyguluyoruz: imza doğrulaması yapılır ve doğrulanmayan istek işlenmez; tutar ve para birimi sipariş kaydıyla karşılaştırılır, uyuşmazlık varsa sipariş onaylanmaz; her bildirim benzersiz işlem anahtarıyla kaydedilir, aynı bildirim tekrar gelirse yok sayılır. Sağlayıcılar ağ sorunlarında bildirimi birden fazla kez gönderdiği için bu son kural olmadan çift sipariş oluşması kaçınılmazdır.
Ayrıca bildirimin hiç gelmediği durumlar için düzenli aralıklarla çalışan bir uzlaşma görevi kuruyoruz: bekleyen durumdaki siparişlerin ödeme durumu sağlayıcıya sorularak doğrulanıyor ve kayıp işlemler yakalanıyor.
Kargo entegrasyonunda neler yapılıyor?
Kargo entegrasyonu üç işi otomatikleştirir: gönderi kaydı oluşturma, etiket üretimi ve takip durumu güncelleme. Sipariş hazır duruma geldiğinde kargo firmasında gönderi kaydı açılır, barkodlu etiket üretilir ve takip numarası hem sisteme hem müşteriye iletilir. Sonrasında teslimat durumları düzenli olarak sorgulanır; teslim edildi bilgisi geldiğinde sipariş kapanır.
Fiyat tarafında kurallar tanımlanıyor: ağırlık ve desi hesabı, bölgeye göre ücret farkı, ücretsiz kargo eşiği, kampanya dönemi istisnaları ve büyük hacimli ürünler için özel tarife. Desi hesabı özellikle önemli; ürün ölçüleri sisteme girilmediğinde kargo maliyeti tahminle belirleniyor ve hacimli ürünlerde ciddi zarar oluşabiliyor. Bu yüzden ürün kaydına en, boy, yükseklik ve ağırlık alanlarını zorunlu hâle getirmenizi öneriyoruz.
Kapıda ödeme ve iade süreçleri nasıl kurgulanıyor?
Ödeme adımında sunulan seçenek sayısını da ölçülü tutmayı öneriyoruz. Çok sayıda ödeme yöntemi, kullanıcıyı karar vermek zorunda bıraktığı için akışı yavaşlatıyor. Verinizde kullanılmayan yöntemleri belirli aralıklarla gözden geçirip kaldırmak, hem arayüzü sadeleştiriyor hem entegrasyon bakımını azaltıyor.
Kapıda ödeme, tahsilatın kargo firması üzerinden yapılması demektir ve ek bir hizmet bedeli doğurur. Sistemde bu seçenek açıldığında kapıda ödeme bedeli sepete otomatik ekleniyor, ayrıca hangi bölgelerde ve hangi tutar aralığında geçerli olduğu kural olarak tanımlanıyor. Yüksek tutarlı siparişlerde kapıda ödemenin kapatılması, teslim alınmayan gönderi riskini azaltıyor.
İade tarafında hem tam hem kısmi iade akışı kuruluyor. Panelden iade başlatıldığında ödeme sağlayıcısına iade isteği gidiyor, sipariş durumu güncelleniyor ve stok geri ekleniyor. Kısmi iade özellikle çok ürünlü siparişlerde gerekli oluyor. İade süresi ve kart sahibine yansıma süresi sağlayıcıya göre değiştiği için müşteriye gösterilen bilgilendirme metnini gerçekçi tutuyoruz; en sık gelen müşteri şikâyeti iadenin gecikmesi değil, ne zaman geleceğinin bilinmemesi.
Güvenlik ve mevzuat tarafında nelere dikkat ediliyor?
Kart verisi hiçbir aşamada bizim sunucumuza düşmüyor; ödeme sağlayıcısının barındırdığı alan veya güvenli çerçeve kullanılıyor. Bu yaklaşım kart verisi güvenlik standartlarının getirdiği yükümlülüklerin büyük bölümünü sağlayıcı tarafında bırakıyor. Anahtar ve gizli bilgiler kod içinde değil ortam değişkenlerinde tutuluyor, günlük kayıtlarında maskeleniyor.
Mevzuat tarafında sipariş akışına şunlar yerleştiriliyor: ödeme öncesi ön bilgilendirme ve mesafeli satış sözleşmesi onayı, onayın zaman damgasıyla kaydı, fiyatların vergi dahil gösterimi, cayma hakkı bilgilendirmesi ve iade koşullarının açık yazımı. Sipariş sonrası bilgilendirme e-postaları, ticari elektronik ileti kapsamındaki pazarlama mesajlarından ayrı tutuluyor.
Ne kadar sürüyor?
Teknik entegrasyon 2-4 haftada tamamlanıyor. Süreyi belirleyen asıl etken genellikle bizim tarafımız değil, sanal POS başvurusunun ve kargo anlaşmasının sonuçlanmasıdır; bu süreçler kurumdan kuruma değişiyor. Bu yüzden başvuruları projenin başında başlatmanızı öneriyoruz, geliştirme test ortamında paralel ilerliyor.
Teslimden önce gerçek işlemlerle uçtan uca test yapıyoruz: başarılı ödeme, başarısız ödeme, doğrulamadan vazgeçme, çift bildirim, kısmi iade, tam iade ve kargo durum güncellemesi. Test kayıtları raporla birlikte paylaşılıyor; böylece canlıya geçerken hangi senaryonun denendiği belgeli oluyor.
Mutabakat ve muhasebe tarafı nasıl kurgulanıyor?
Ödeme entegrasyonu yalnızca tahsilatı çalıştırmakla bitmiyor. Paranın hesabınıza ne zaman ve ne kadar geçtiğinin, sipariş kayıtlarınızla örtüşüp örtüşmediğinin izlenebilir olması gerekiyor. Bu iş elle yapıldığında ay sonunda saatler alıyor ve küçük farklar genellikle hiç bulunamıyor.
Kurduğumuz yapıda her sipariş için şu bilgiler kaydediliyor: brüt tutar, komisyon ve hizmet bedeli, taksit vade farkı, net hakediş tutarı, valör tarihi ve varsa iade mahsuplaşması. Sağlayıcının gün sonu raporu düzenli olarak çekilip sistemdeki kayıtlarla eşleştiriliyor; eşleşmeyen işlemler ayrı bir listeye düşüyor ve incelenmek üzere işaretleniyor.
Fatura tarafında ise e-fatura ve e-arşiv süreçlerine bağlanma ihtiyacı doğuyor. Sipariş onaylandığında fatura kaydının otomatik oluşturulması, iptal ve iade durumlarında iade faturasının üretilmesi ve fatura numaralarının sipariş kaydına yazılması sağlanıyor. Böylece müşteri destek ekibi tek ekrandan hem ödeme hem fatura durumunu görebiliyor.
Kargo tarafında da benzer bir mutabakat gerekiyor. Kargo firmasının fatura ettiği tutar ile sistemin hesapladığı desi ve bölge bazlı tutar karşılaştırılıyor. Deneyimimize göre ölçüleri eksik girilmiş ürünlerde bu fark kayda değer boyutlara ulaşabiliyor; düzenli karşılaştırma, ürün ölçü verisindeki hataları da ortaya çıkarıyor.
Bu raporlar panelde günlük ve aylık dökümler hâlinde sunuluyor. Amaç muhasebe yazılımının yerini almak değil; iki tarafın rakamları arasındaki farkı erken ve otomatik olarak görünür kılmak.
