Sanal POS Başvurusu ve Entegrasyonu: Kurumsal Rehber

E-ticaret projelerinde geliştirme tarafı planlandığı gibi ilerlerken takvimi bozan kalem çoğu zaman ödeme altyapısı olur. Sebep teknik değildir: sanal POS, bir bankanın ya da ödeme kuruluşunun onayına bağlıdır ve bu onay süreci firmanın kendi evrak hazırlığıyla doğru orantılı ilerler.

Bu yazı, süreci baştan sona planlayabilmeniz için hazırlandı.

Önce karar: banka POS mu, ödeme kuruluşu mu?

İki seçenek arasındaki fark, komisyon oranından ibaret değildir.

Banka sanal POS'u, çalıştığınız bankayla doğrudan ilişki kurar. Para, bankanın belirlediği valörle doğrudan firma hesabına geçer. Komisyon oranı genellikle daha düşüktür. Buna karşılık her banka için ayrı entegrasyon ve ayrı test süreci gerekir; birden fazla bankanın taksit kampanyasından yararlanmak isteyen firmalar birden fazla POS yönetmek zorunda kalır.

Ödeme kuruluşu, birden fazla bankayı tek bir arayüz arkasında toplar. Tek entegrasyonla tüm kartlara ve taksit seçeneklerine erişilir, ödeme formu ve 3D akışı hazır gelir. Komisyon oranı bir miktar daha yüksektir ve para önce kuruluşta bekler, sonra firmaya aktarılır.

Karar ölçütü şudur: taksit kampanyası ve çoklu banka desteği satış için belirleyiciyse ödeme kuruluşu; işlem hacmi yüksek ve tek bankayla çalışılıyorsa banka POS'u daha uygundur.

Başvuru için hazırlanacaklar

Başvuru dosyası kurumdan kuruma değişse de temel liste ortaktır:

• Vergi levhası
• Ticaret sicil gazetesi
• İmza sirküleri
• Faaliyet belgesi
• Kimlik fotokopileri (yetkili ve ortaklar)
• Banka hesap bilgileri
• Yayında olan web sitesi adresi

Son madde çoğu zaman şaşırtır: sanal POS başvurusu için sitenin yayında olması istenir. Değerlendirme, siteye girilerek yapılır. Bu nedenle proje planında sanal POS başvurusu, ödeme adımı henüz çalışmıyorken bile site yayına alındıktan hemen sonra başlatılır.

Sitede aranan zorunlu içerikler

İnceleme sırasında aşağıdaki sayfaların eksiksiz ve erişilebilir olması beklenir:

• Mesafeli satış sözleşmesi
• Ön bilgilendirme formu
• Teslimat ve iade koşulları
• Gizlilik politikası ve KVKK aydınlatma metni
• İletişim bilgileri: açık unvan, adres, telefon, e-posta
• Ürün fiyatlarının KDV dâhil gösterimi
• Kabul edilen kart markalarının ve varsa taksit koşullarının görünür olması

Bu sayfaların bulunmaması, başvurunun en sık reddedilme nedenidir. Hazırlanmaları hukuki bir iştir; metinlerin firmanın gerçek satış ve teslimat koşullarını yansıtması gerekir.

Komisyon ve taksit yapısını anlamak

Teklif alırken tek bir oran sormak yanıltıcıdır. Sorulacak başlıklar:

• Tek çekim komisyon oranı
• Taksitli işlem oranları. Taksit sayısı arttıkça oran artar ve bu fark ya firmaya ya müşteriye yansır.
• Valör süresi. Paranın hesaba geçme süresi; nakit akışını doğrudan etkiler.
• İptal ve iade işlem ücreti
• Aylık sabit ücret veya alt limit var mı?
• Yabancı kart oranı. İhracat yapan firmalar için ayrı bir kalemdir.

Taksit yükünün müşteriye yansıtılıp yansıtılmayacağı bir fiyat politikası kararıdır ve altyapıda buna göre kurgulanır; sonradan değiştirilmesi fiyat gösteriminin baştan ele alınmasını gerektirir.

3D Secure kurgusu

Kart hamilinin bankası tarafından doğrulandığı akış olan 3D Secure, kurumsal projelerde standart kabul edilir. İki yaygın kurgu vardır:

• 3D Pay: Doğrulama ve tahsilat tek adımda tamamlanır. Kurgusu basittir.
• 3D Secure (ön otorizasyon ayrı): Önce doğrulama yapılır, tahsilat ayrı bir çağrıyla gerçekleşir. Stok kontrolünü ödeme ile tahsilat arasına yerleştirmek isteyen operasyonlar için uygundur.

Ayrıca kart saklama ihtiyacı varsa kart verisinin sizin sunucunuzda hiçbir aşamada tutulmaması gerekir; saklama işlemi ödeme kuruluşunun jeton altyapısıyla yapılır.

Entegrasyonun teknik tarafı

Geliştirme tarafında planlanacak başlıklar:

• Test ortamı. Kurum tarafından verilen test kartlarıyla başarılı ödeme, başarısız ödeme, yetersiz bakiye ve 3D iptal senaryolarının tamamı denenir.
• Sipariş durumu yönetimi. Ödeme başlatıldığında sipariş "beklemede" yazılır; sonuç geldiğinde güncellenir. Kullanıcı ödeme sayfasında tarayıcıyı kapatırsa siparişin ne olacağı önceden tanımlanır.
• Geri bildirim adresi. Bankadan gelen sonuç bildiriminin işlendiği adres, dışarıdan tetiklenebilir olduğu için imza doğrulaması yapar.
• Mutabakat. Gün sonunda banka kayıtları ile sipariş kayıtlarının karşılaştırılması; tutarsızlık raporlanır.
• İade akışı. Kısmi iade destekleniyor mu, hangi süre içinde yapılabiliyor?

Takvim planlaması

Gerçekçi bir sıralama şöyle kurulur:

• Site yayına alınır, zorunlu sayfalar tamamlanır.
• Sanal POS başvurusu yapılır. Değerlendirme genellikle birkaç iş günü ile birkaç hafta arasında sürer.
• Onay sonrası test bilgileri alınır, entegrasyon tamamlanır ve senaryolar denenir.
• Canlı bilgiler tanımlanır, düşük tutarlı bir gerçek işlem yapılarak uçtan uca doğrulanır.

Bu sıralamada geliştirme, banka onayını beklerken duraklamaz: ödeme adımı test ortamında tamamlanmış olur, canlıya geçiş yalnızca bilgi değişimidir.