3 minutes read
Sanal POS entegrasyonu kâğıt üstünde basit: banka üç kimlik bilgisi veriyor, eklentiye yazıyorsunuz, ödeme alıyorsunuz. Sahada ise ilk on siparişte çıkan sorunların çoğu aynı beş yerden geliyor. Yaşadıklarımdan derledim.
1. Taksit oranını istemciye bırakmak
Taksit tablosu tarayıcıda çiziliyor ve komisyon tarayıcıda hesaplanıyorsa, tarayıcıdaki değeri değiştiren biri dokuz taksidi tek çekim komisyonuyla geçirebilir. Oranlar sunucuda ikinci kez doğrulanmalı: müşteri hangi taksidi seçtiyse, tutar sunucuda o oranla yeniden hesaplanıp bankaya öyle gönderilmeli.
Bu sitede ödeme adımında on iki taksitlik tablo görünüyor; seçtiğiniz taksit sunucuda yeniden hesaplanıyor. Akış benzetim, ama doğrulama sırası gerçek üründeki sıra.
2. Kartı banka kodu yerine kart numarasından tanımamak
Bir müşterinin A bankası kartı var, sizin sanal POS’unuz B bankasında. İşlem geçer ama taksit yapılmaz; ya da tam tersi, A bankasında da POS’unuz var ama eklenti her kartı B’ye yolluyor ve yüksek komisyon ödüyorsunuz.
Çözüm BIN yönlendirmesi: kart numarasının ilk altı (artık sekiz) hanesi hangi bankaya aitse işlem o bankanın POS’una gidiyor. Bunun için güncel bir BIN tablosu gerekiyor; tablo eskidiğinde yeni kartlar yanlış bankaya düşüyor.
3. 3-D Secure dönüşünü doğrulamamak
Bankanın doğrulama sayfasından döndüğünüzde gelen POST verisinin bankadan geldiğine nasıl güveniyorsunuz? İmza doğrulamasını atlayan eklentiler var; bir istemci geri dönüş adresine kendi “onaylandı” POST’unu atıp siparişi ödenmiş gösterebilir.
Her bankanın imza şeması farklı: kimi SHA-1, kimi SHA-512, kimi ek alan sırasına duyarlı. Eklenti bankaya özgü şemayı uygulamalı ve imza tutmayan dönüşü reddetmeli — sipariş notuna da bunu yazmalı.
Reddedilen işlemin sebebi sipariş notuna düşsün
“Ödeme başarısız” tek başına işe yaramaz. Bankanın döndürdüğü hata kodu ve açıklaması (“limit yetersiz”, “kart internet alışverişine kapalı”) sipariş notuna yazılırsa müşteri hizmetleri telefonu çalmadan cevabı biliyor.
4. Test kipini üretimde açık bırakmak
Bankanın sandbox adresine giden ödemeler her zaman başarılı döner. Canlıya geçerken test kipini kapatmayı unutan bir mağaza iki gün boyunca gerçekte tahsil edilmeyen siparişleri kargoya verdi. Test kipi açıkken yönetim panelinde kırmızı bir uyarı görünmeli.
5. Uluslararası ve yerli sağlayıcıyı ayrı eklentilerde tutmak
Stripe için bir eklenti, yerli banka için başka bir eklenti, PayPal için üçüncüsü. Üç ayrı ayar ekranı, üç ayrı güncelleme, üç ayrı hata günlüğü. Ödeme motoru tek olursa kart tipine göre yönlendirme de tek yerden yapılır: yabancı kart Stripe’a, yerli kart bankanın POS’una.
Kontrol listesi
- Taksit oranı sunucuda yeniden hesaplanıyor.
- BIN tablosu güncel, kart doğru bankaya yönleniyor.
- 3-D Secure dönüş imzası doğrulanıyor, tutmayan dönüş reddediliyor.
- Banka hata sebebi sipariş notuna yazılıyor.
- Test kipi panelde görünür bir uyarı veriyor.
- Tüm sağlayıcılar tek ayar ekranından yönetiliyor.
Bu sitedeki ödeme akışında gerçek bir bankaya bağlanılmıyor; 4242 ile başlayan kart onay, 4111 ile başlayan kart ret döndürüyor. Kart numarası benzetim ekranına gönderilmiyor. Ayrıntı MevvPos vitrininde.
Bir yanıt yazın