Sanal POS Entegrasyonu Nasıl Yapılır? Adımlar, 3D Secure ve ERP

Sanal POS entegrasyonu, e-ticaret sitenizin ödeme adımını bir bankanın ya da lisanslı bir ödeme kuruluşunun kart altyapısına bağlama işidir. Pratikte üç aşamadan oluşur: ödeme sağlayıcısıyla üye işyeri anlaşması, sitenin sağlayıcıya API ya da hazır modülle bağlanması ve 3D Secure dahil tüm senaryoların test ortamında denenip canlıya alınması. Hazır bir e-ticaret altyapısında bu iş çoğunlukla modül ayarından ibarettir; özel yazılımda ise geliştirme, test ve muhasebe bağlantısı gerektirir.

Banka sanal POS'u mu, ödeme kuruluşu mu?

İlk karar, ödemeyi kimin alacağıdır. İki yol var:

• Banka sanal POS'u: Doğrudan bir bankayla üye işyeri sözleşmesi yaparsınız, para o bankadaki hesabınıza geçer. Birden fazla bankayla çalışmak isterseniz her biri ayrı anlaşma ve ayrı entegrasyon demektir.
• Ödeme kuruluşu: Tek anlaşma ve tek entegrasyonla birçok bankanın kartını ve taksit seçeneğini kabul edersiniz. Başvuru genellikle daha hızlı sonuçlanır; komisyon yapısı ve paranın hesabınıza geçiş süresi ise sözleşmeye bağlıdır.

Hangi yolu seçerseniz seçin, çalıştığınız kuruluşun yetkili olduğunu kontrol edin. Türkiye'de ödeme kuruluşları ve elektronik para kuruluşları 6493 sayılı Kanun kapsamında faaliyet gösterir ve Türkiye Cumhuriyet Merkez Bankası (TCMB) izinli kuruluşların listesini sitesinde yayımlar. Örneğin iyzico ve PayTR, TCMB'nin elektronik para kuruluşları listesinde yer alır.

Yeni açılan bir mağaza için ödeme kuruluşu çoğu zaman daha pratik bir başlangıçtır. Cirosu oturmuş ve bankayla komisyon pazarlığı yapabilecek işletmeler ise doğrudan banka POS'unu ya da ikisini birlikte değerlendirir.

Sanal POS entegrasyonu adım adım nasıl yapılır?

1. Başvuru ve sözleşme. Sağlayıcı şirket belgelerinizi, sitenizin adresini ve sattığınız ürün grubunu ister. Başvuruyu incelerken genellikle sitedeki mesafeli satış sözleşmesine, iade koşullarına ve iletişim bilgilerine de bakılır; bu sayfaları önceden yayına almak süreci hızlandırır.
2. Test ortamı bilgileri. Onaydan sonra üye işyeri numarası, API anahtarları ve test kartları verilir. Bu bilgiler kodun içine yazılmaz, sunucu tarafında gizli ortam değişkeni olarak saklanır.
3. Entegrasyon yönteminin seçimi. Hazır platformda sağlayıcının modülü kurulur. Özel yazılımda sağlayıcının API belgesine göre ödeme başlatma, 3D Secure yönlendirmesi ve sonuç bildirimi yazılır.
4. Sonuç bildiriminin doğrulanması. Siparişi "ödendi" durumuna geçiren şey, tarayıcının döndüğü sayfa değil, sağlayıcının sunucunuza gönderdiği ve imzası (hash) doğrulanan bildirim olmalıdır. Bu kontrol atlanırsa sahte "ödeme başarılı" dönüşleri siparişe dönüşebilir.
5. Senaryo testleri. Başarılı ödeme, yetersiz bakiye, 3D Secure ekranında vazgeçme, zaman aşımı, aynı siparişin iki kez ödenmesi, kısmi iade ve tam iade ayrı ayrı denenir.
6. Canlıya alma ve izleme. Canlı anahtarlar girildikten sonra küçük tutarlı gerçek bir ödeme ve iadesiyle zincir kontrol edilir. İlk haftalarda reddedilen işlem oranı ve hata kodları takip edilir.

Ortak ödeme sayfası mı, doğrudan API mi?

Entegrasyonun en önemli teknik kararı, kart bilgisinin nerede girildiğidir.

Sağlayıcının ödeme sayfası ya da gömülü ödeme formu kullanıldığında kart numarası sizin sunucunuza hiç uğramaz. Kurulum hızlıdır, güvenlik yükü düşüktür; tasarım esnekliği ise sağlayıcının izin verdiği kadardır.

Doğrudan API ile kendi formunuzdan kart almak tam tasarım kontrolü verir ama sorumluluğu da büyütür. Kart verisini saklayan, işleyen ya da ileten her kuruluş PCI DSS (Ödeme Kartı Endüstrisi Veri Güvenliği Standardı) kapsamına girer. Kart verisi sunucunuzdan geçiyorsa bu standarda uyumu sağlamanız ve belgelemeniz gerekir.

Çoğu KOBİ için doğru tercih, sağlayıcının ödeme formunu kendi tasarımınıza yaklaştırmak ve kart verisini hiç sunucunuza almamaktır. Abonelik ya da tek tıkla ödeme isteniyorsa kart saklama işi de sağlayıcının kart saklama (tokenizasyon) hizmetine bırakılır.

3D Secure ödeme akışını nasıl etkiler?

3D Secure, kart sahibinin ödeme sırasında kartı veren banka tarafından doğrulandığı protokoldür. Güncel sürümü EMV 3-D Secure, satış ve cihaz bilgisini bankayla paylaşarak riski değerlendirir: düşük riskli işlemler ek adım olmadan geçebilir, riskli görülenlerde tek kullanımlık şifre ya da biyometrik doğrulama istenir.

Entegrasyonda 3D Secure'ün asıl zorluğu kullanıcı deneyimidir. Sık gördüğümüz sorunlar şunlar:

• Mobilde banka doğrulama ekranından siteye dönüşte oturumun düşmesi ve sepetin boşalması.
• Dönüş adresinin yanlış ayarlanması yüzünden paranın çekildiği ama siparişin oluşmadığı durumlar.
• Sosyal medya uygulamalarının kendi içindeki tarayıcılarda yönlendirmenin takılması.

Özellikle sosyal medya reklamlarıyla satış yapıyorsanız bu üç senaryoyu testte ayrıca deneyin.

Taksit, BIN sorgusu ve komisyon nasıl kurgulanır?

Taksit seçenekleri kartın hangi bankaya ve hangi kart programına ait olduğuna göre değişir. Ödeme formu kartın ilk hanelerinden (BIN) bankayı tanır ve o karta açık taksitleri gösterir. Kredi kartında taksit sayısı her ürün grubunda serbest değildir; bazı kategorilerde üst sınır ya da taksit yasağı bulunur. Sattığınız kategori için geçerli sınırı sağlayıcınızdan teyit edin.

Taksit maliyetini kimin üstleneceği bir fiyatlama kararıdır. Vade farkını müşteriye yansıtabilir, belirli taksitleri vade farksız sunup maliyeti marjınıza katabilir ya da ikisini birlikte kullanabilirsiniz. Önemli olan, ödeme ekranında gösterilen toplam tutarın müşterinin kart ekstresinde göreceği tutarla aynı olmasıdır.

Komisyonda tek bir orana bakmak yanıltır. Teklifleri karşılaştırırken şu kalemleri birlikte değerlendirin:

• Peşin ve taksitli işlem komisyonları
• Paranın hesaba geçiş süresi (valör) ve bu sürenin orana etkisi
• İşlem başına sabit ücret, iade ve iptal ücretleri
• Yurt dışı kart kabulü ve kur dönüşüm koşulları

Sanal POS ERP entegrasyonu neden ayrıca planlanmalı?

Ödemenin alınması işin bittiği anlamına gelmez; tahsilatın muhasebeye doğru düşmesi gerekir. Sanal POS'u ERP ya da muhasebe yazılımına bağlamadığınızda ekip her gün sağlayıcının panelinden rapor indirip siparişlerle elle eşleştirir. Hata en çok iadelerde, kısmi iadelerde ve komisyon kesintilerinde çıkar.

İyi kurulmuş bir yapıda ödeme bildirimi geldiğinde sipariş, tahsilat kaydı ve fatura akışı tetiklenir; sağlayıcının hesap özeti de her gün ERP'deki kayıtlarla otomatik karşılaştırılır. Bu tarafı CRM ve ERP çözümlerimiz sayfasında ayrıca anlattık.

Sık yapılan hatalar

• Siparişi yalnızca tarayıcı dönüşüne göre onaylamak, sunucu bildirimini doğrulamamak.
• Canlı API anahtarlarını kodun içine ya da erişime açık bir dosyaya yazmak.
• Test ortamında yalnızca başarılı ödemeyi denemek.
• İadeyi sağlayıcı panelinden elle yapıp sitedeki sipariş durumunu güncellemeyi unutmak.
• Ödeme sayfasına gereksiz üçüncü taraf kodları (sohbet eklentisi, fazladan takip kodu) eklemek.

Kısaca: canlıya almadan önce kontrol listesi

• Sağlayıcı TCMB listesinde mi, komisyon, valör ve iade ücreti sözleşmede yazılı mı?
• Kart verisi sunucunuza uğruyor mu? Uğruyorsa PCI DSS yükümlülüğü planlandı mı?
• 3D Secure akışı mobilde ve uygulama içi tarayıcıda denendi mi?
• Sunucu bildirimi imza kontrolüyle doğrulanıyor mu?
• İade, kısmi iade ve mükerrer ödeme senaryoları test edildi mi?
• Tahsilat ve iadeler ERP'ye ya da muhasebeye otomatik düşüyor mu?

Mağazanızın ödeme altyapısını sıfırdan kurmak ya da mevcut yapıyı muhasebeyle konuşturmak istiyorsanız e-ticaret hizmetimizi inceleyebilir, kendi durumunuzu konuşmak için bizimle iletişime geçebilirsiniz.