Sanal POS entegrasyonu nedir, nasıl yapılır?

Sanal POS, bir web sitesinin kredi kartıyla tahsilat yapabilmesini sağlayan banka ya da ödeme kuruluşu hizmetidir. Entegrasyon denince çoğu zaman akla "ödeme formu eklemek" gelir; oysa işin büyük kısmı formda değil, formdan sonra olanlardadır. Doğru kurulmuş bir sanal POS entegrasyonunda kart verisi sitenin sunucusuna hiç uğramaz, her işlemin bir karşılığı vardır ve iade süreci elle müdahale gerektirmez.

Kart verisi siteye uğramamalı

Entegrasyonun en kritik kararı, kart numarasının nereden geçeceğidir. İki yaygın yöntem vardır. Yönlendirmeli yöntemde müşteri ödeme kuruluşunun sayfasına gider, kart bilgisini orada girer ve sonucu alıp geri döner. Gömülü yöntemde form sitede görünür ama alanlar ödeme kuruluşunun çerçevesi içindedir ve veri doğrudan onlara gider.

Her iki yöntemde de kart numarası sitenin sunucusuna düşmez. Bu yalnızca güvenlik tercihi değil, uyum gereğidir: kart verisini kendi sunucusunda tutan ya da işleyen taraf, kart endüstrisinin güvenlik standardı olan PCI DSS kapsamında ağır bir denetim yükümlülüğü altına girer. Küçük ve orta ölçekli bir işletmenin bu yükü taşıması gerekmez; doğru entegrasyon bu yükü ödeme kuruluşunda bırakır.

3D Secure akışı ve sonucun doğrulanması

3D Secure, kart sahibinin bankası tarafından ek bir doğrulama adımı eklenmesidir; müşteriye gelen tek kullanımlık kod bu adımın parçasıdır. Akış kabaca şöyledir: site ödeme isteğini başlatır, müşteri bankanın doğrulama ekranına gider, doğrulama sonucu siteye bildirilir ve site bu sonuçla tahsilatı tamamlar.

Burada en sık yapılan hata, bankadan dönen sonuca olduğu gibi güvenmektir. Dönüş mesajının gerçekten bankadan geldiği imza doğrulamasıyla kontrol edilmelidir; aksi hâlde başarılı ödeme sonucu taklit edilebilir. İkinci hata, siparişi tarayıcıdan dönen bilgiyle tamamlamaktır. Müşteri tarayıcıyı kapatırsa ödeme alınmış ama sipariş oluşmamış olur. Doğru kurgu, sunucudan sunucuya gelen bildirimi esas almak ve tarayıcı dönüşünü yalnızca kullanıcıya ekran göstermek için kullanmaktır.

Taksit tablosu banka tarafında değişir

Taksit seçenekleri sabit bir liste değildir. Hangi bankanın kartına kaç taksit yapılabileceği, komisyon oranları ve kampanyalar banka ile işletme arasındaki anlaşmaya bağlıdır ve zaman içinde değişir. Bu tabloyu site koduna gömmek, her değişiklikte geliştirici beklemek demektir.

Doğru kurgu, taksit tablosunun yönetim panelinde tutulması ve ödeme adımında kart numarasının ilk altı hanesine göre ilgili bankanın seçeneklerinin gösterilmesidir. Vade farkı uygulanacaksa bunun müşteriye ödeme ekranında açıkça gösterilmesi gerekir; toplam tutarın sepetten farklı çıkması, terk edilen sepetlerin en yaygın sebeplerindendir.

Her işlemin bir karşılığı olmalı

Ödeme entegrasyonunda en can sıkıcı durum, bankada görünen ama sistemde görünmeyen işlemdir. Bunu önlemenin yolu, ödeme girişiminin tahsilat denemesinden önce kaydedilmesidir. Müşteri ödeme adımına geldiğinde sistemde bekleyen bir kayıt oluşur; sonuç ne olursa olsun o kayıt başarılı, başarısız ya da yarıda kalmış olarak kapanır.

Bu yapı, gün sonunda banka ekstresi ile sistem kayıtlarının karşılaştırılmasını mümkün kılar. Karşılaştırma otomatik yapılmalı ve eşleşmeyen işlemler bir listeye düşmelidir. Bu liste boş kaldığı sürece entegrasyonun sağlıklı çalıştığını bilirsiniz.

İade ve kısmi iade

İade, satışın aynadaki görüntüsü değildir; kendi kuralları vardır. Aynı gün içinde yapılan iptal ile sonraki günlerde yapılan iade bankada farklı işlemlerdir ve farklı uçlardan çağrılır. Kısmi iade her bankada desteklenmeyebilir. Taksitli bir satışın iadesi, müşterinin kartına taksitler hâlinde yansıyabilir.

Bu nedenle iade akışı en baştan tasarlanmalı ve yönetim panelinden tek tuşla yapılabilmelidir. İadenin elle, banka ekranından yapıldığı sistemlerde sipariş durumu ile gerçek durum birbirinden kopar ve müşteri hizmetleri tarafı ne olduğunu göremez.

Canlıya almadan önce yapılacak kontroller

Test ortamında şu senaryoların hepsi denenmelidir: başarılı ödeme, yetersiz bakiye, yanlış doğrulama kodu, müşterinin ortada vazgeçmesi, tarayıcının kapanması, aynı siparişin iki kez gönderilmesi, iade ve kısmi iade. Bunların her birinde sistemde oluşan kaydın doğru durumda kaldığı görülmelidir.

Son olarak, ödeme sayfasının mobilde çalıştığı gerçek bir telefonda denenmelidir. Tahsilatın büyük kısmı mobilden gelir ve doğrulama ekranının dar ekranda taşması, tamamlanamayan ödemelerin sessiz sebebidir.

Hangi ödeme kuruluşu seçilir

Seçimi belirleyen tek şey komisyon oranı değildir. En az dört başlık karşılaştırılmalıdır. Birincisi, hangi bankaların kartlarına taksit yapılabildiği: müşteri kitlenizin kullandığı bankalar listede yoksa düşük komisyonun anlamı kalmaz. İkincisi, para çekim süresi; tahsilatın hesaba geçme süresi nakit akışınızı doğrudan etkiler.

Üçüncüsü teknik belgelerin ve test ortamının durumudur. Test kartlarıyla her senaryonun denenebildiği, hata kodlarının açıklandığı bir belge seti, entegrasyon süresini belirgin biçimde kısaltır. Dördüncüsü ise arıza anında kime ulaşılacağıdır: ödeme durduğunda satış da durur, bu yüzden teknik destek kanalının ve cevap süresinin baştan bilinmesi gerekir.

Kaydedilen kart ve tekrarlayan ödeme

Müşterinin kartını her alışverişte yeniden girmesini istemiyorsanız, kart saklama işini de ödeme kuruluşu üstlenir. Sitede kart numarası değil, o karta karşılık gelen bir anahtar saklanır; sonraki ödemelerde bu anahtar gönderilir. Anahtarın sızması hâlinde bile kart numarası elde edilemez, çünkü anahtar yalnızca sizin üye iş yeri hesabınızda geçerlidir.

Abonelik gibi tekrarlayan tahsilatlarda ek bir konu vardır: 3D Secure doğrulaması müşterinin o anda ekran başında olmasını gerektirir. Tekrarlayan ödemeler bu yüzden farklı bir işlem tipiyle, müşterinin ilk seferde verdiği onaya dayanarak yapılır. Bu izin akışının sözleşmede ve ekranda açıkça yer alması gerekir.