Sanal POS Entegrasyonu ve 3D Secure 2.0 Güvenlik Standartları

Sanal POS entegrasyonu, bir ödeme formunu banka servisine bağlamaktan çok daha kapsamlıdır. Sepetin oluşturulmasından ödemenin doğrulanmasına, banka yanıtından sipariş durumunun güncellenmesine ve finansal mutabakata kadar birbirini etkileyen çok sayıda adım içerir. Sağlam bir yapı; müşterinin ödemeyi kolayca tamamlamasını, hassas verilerin korunmasını ve operasyon ekibinin başarısız ya da belirsiz işlemleri güvenle yönetmesini birlikte sağlamalıdır.

Bu nedenle sanal POS entegrasyonu yalnızca teknik bir API çalışması olarak değerlendirilmemelidir. Kullanıcı deneyimi, 3D Secure 2.0 akışları, hata yönetimi, kayıt ve izlenebilirlik, veri gizliliği, performans ve sürdürülebilir operasyon aynı mimari içinde planlanmalıdır. Özellikle birden fazla banka veya ödeme hizmeti sağlayıcısıyla çalışan işletmeler için ortak durum modeli ve yönetim araçları kritik önem taşır.

Sanal POS entegrasyonu nedir?

Sanal POS entegrasyonu; e-ticaret platformunun banka ya da ödeme kuruluşu altyapısıyla haberleşerek kartlı ödemeyi başlatması, doğrulaması, sonuçlandırması ve kaydetmesidir. Bu yapı genellikle tutar ve para birimi kontrolü, ödeme oturumu oluşturma, 3D Secure doğrulaması, provizyon, iptal, iade ve mutabakat süreçlerini kapsar.

Entegrasyon modeline göre müşteri ödeme kuruluşunun barındırdığı sayfaya yönlendirilebilir, güvenli bir form bileşeni kullanılabilir veya ödeme arayüzünün daha büyük bölümü işletme tarafından yönetilebilir. Seçim yalnızca görsel esneklik üzerinden yapılmamalıdır. Kart verisinin hangi sistemlere temas ettiği, PCI DSS kapsamı, sağlayıcının desteklediği özellikler, mobil deneyim ve operasyon ihtiyacı birlikte değerlendirilmelidir.

Markanın görsel dilini hızlı ve anlaşılır bir satış sürecine taşımak isteyen işletmeler için e-ticaret deneyimi; ürün keşfi, sepet ve ödeme adımlarının aynı kullanıcı yolculuğu içinde tasarlanmasını gerektirir. Ödeme ekranı diğer sayfalardan kopuk görünmemeli, fakat estetik tercihler güvenlik kontrollerinin önüne de geçmemelidir.

3D Secure 2.0 nasıl çalışır?

3D Secure 2.0, kartın mevcut olmadığı çevrim içi işlemlerde kart sahibinin bankası tarafından doğrulanmasını destekleyen bir mesajlaşma protokolüdür. “3D Secure 2.0” yaygın bir üst adlandırmadır; kullanılacak gerçek protokol sürümü, kart şeması, banka, sağlayıcı ve teknik uyumluluk koşullarına göre belirlenmelidir.

EMVCo’nun EMV 3-D Secure açıklamasına göre yapı; işlem, cihaz ve kart sahibi bağlamının risk değerlendirmesinde kullanılmasına imkân verir. Böylece her müşteriye aynı doğrulama adımını göstermek yerine işlemin sürtünmesiz veya ek doğrulama gerektiren akışa yönlendirilmesi mümkün olur.

Sürtünmesiz doğrulama akışı

Risk değerlendirmesi sonucunda kartı veren kuruluş ek kullanıcı etkileşimine ihtiyaç duymayabilir. Müşteri ayrı bir şifre ya da onay ekranıyla karşılaşmadan doğrulama tamamlanabilir. Bu sonuç, 3D Secure kontrolünün atlandığı anlamına gelmez; doğrulamanın arka plandaki veriler üzerinden sonuçlandığını gösterir.

Sürtünmesiz akışın sağlıklı çalışması için sağlayıcının talep ettiği alanların doğru, tutarlı ve izin verilen kapsamda gönderilmesi gerekir. Eksik cihaz veya işlem bağlamı, risk değerlendirmesini ve doğrulama sonucunu etkileyebilir. Bununla birlikte daha fazla veri göndermek otomatik olarak daha iyi sonuç yaratmaz; veri minimizasyonu ve açık amaç ilkeleri korunmalıdır.

Ek doğrulama gerektiren challenge akışı

Banka daha fazla doğrulama istediğinde müşteri tek kullanımlık parola, mobil bankacılık onayı, biyometri veya bankanın desteklediği başka bir yöntemle karşılaşabilir. EMVCo’nun challenge akışı açıklaması, kart sahibinin güvenli bağlantı üzerinden kartı veren kuruluşla etkileşime girdiğini ve sonucun protokol mesajlarıyla iletildiğini ortaya koyar.

Bu aşamada açılan pencerenin ölçüsü, mobil ekrandaki görünüm, uygulamalar arası geçiş, geri tuşu ve zaman aşımı davranışı test edilmelidir. Kullanıcıya “Bankanızda doğrulama yapılıyor” gibi açık bir durum mesajı gösterilmeli; sayfanın yenilenmesi veya ödeme düğmesine tekrar basılmasıyla ikinci tahsilat oluşması engellenmelidir.

Ödeme akışı uçtan uca nasıl tasarlanmalıdır?

1. Siparişi ve ödenecek tutarı sunucuda doğrulayın

Ürün fiyatı, indirim, kargo, vergi, para birimi ve toplam tutar ödeme başlatılmadan önce güvenilir sunucu verisiyle yeniden hesaplanmalıdır. Tarayıcıdan gelen toplam doğrudan kabul edilmemelidir. Her ödeme denemesi benzersiz bir sipariş, ödeme ve deneme kimliğiyle ilişkilendirilmelidir.

2. Ödeme oturumunu güvenli biçimde oluşturun

Banka veya ödeme hizmeti sağlayıcısıyla iletişim yalnızca sunucu tarafında korunması gereken anahtarlar üzerinden kurulmalıdır. Gizli anahtarlar istemci koduna, mobil uygulama paketine veya herkese açık depolara eklenmemelidir. Geliştirme, test ve canlı ortamlarının kimlik bilgileri ile geri dönüş adresleri ayrılmalıdır.

3. 3D Secure sonucunu provizyondan ayırın

Kimlik doğrulamasının başarılı olması, tahsilatın kesin olarak tamamlandığı anlamına gelmeyebilir. Sistem; 3D Secure sonucunu, provizyon yanıtını ve sipariş durumunu ayrı fakat ilişkili kayıtlar olarak ele almalıdır. “Doğrulandı”, “provizyon bekliyor” ve “ödendi” durumlarının tek bir etikete dönüştürülmesi operasyonel hatalara yol açabilir.

4. Sonucu sunucudan teyit edin

Kullanıcının başarı sayfasına ulaşması tek başına ödeme kanıtı değildir. Geri dönüş parametrelerinin bütünlüğü kontrol edilmeli, sağlayıcının sunucudan sunucuya bildirimleri doğrulanmalı ve gerektiğinde işlem durumu API üzerinden sorgulanmalıdır. Sipariş yalnızca güvenilir nihai sonuca göre kesinleştirilmelidir.

5. Sipariş ve finans kayıtlarını güncelleyin

Başarılı ödeme sonrasında stok, fatura, bildirim ve ERP adımları kontrollü biçimde tetiklenmelidir. Bu işlerden biri başarısız olduğunda ödeme kaydı kaybolmamalıdır. Kuyruk tabanlı işlemler ve yeniden deneme politikaları, geçici servis kesintilerinde sürecin kaldığı yerden devam etmesini sağlayabilir.

Başarısız ve bekleyen işlemler nasıl yönetilir?

Ödeme dünyasında her istek anında “başarılı” veya “başarısız” sonucuna ulaşmaz. Kullanıcı doğrulama ekranını kapatabilir, bankadan geç yanıt gelebilir, geri dönüş isteği ulaşmayabilir veya istemci bağlantısı kesilebilir. Bu durumlarda “sonuç bilinmiyor” ile “ödeme reddedildi” birbirinden ayrılmalıdır.

• Başarısız: Banka veya sağlayıcı tarafından kesin ret üretilmiştir. Kullanıcıya hassas teknik ayrıntı vermeden anlaşılır bir mesaj gösterilir.
• Bekliyor: Nihai sonuç henüz alınmamıştır. Sipariş geçici durumda tutulur ve işlem sorgulama mekanizması çalıştırılır.
• Zaman aşımı: İstek süresi dolmuştur; ancak banka tarafında tahsilat gerçekleşmiş olabilir. Yeni ödeme başlatmadan önce mevcut işlem araştırılır.
• İptal edildi: Kullanıcı ya da banka doğrulama akışını tamamlamamıştır. Sepete güvenli dönüş ve yeniden deneme seçeneği sunulur.
• Tutarsız: Bildirim, sorgu ve yerel kayıtlar farklı sonuç göstermektedir. İşlem otomatik veya yetkili manuel incelemeye alınır.

Yönetim ekranında sipariş numarası, sağlayıcı işlem kimliği, tutar, para birimi, zaman bilgisi, mevcut durum ve önceki durumlar görüntülenebilmelidir. Ham banka mesajları doğrudan müşteriye gösterilmemeli; operasyon ekibi için açıklanabilir hata sınıfları oluşturulmalıdır.

Güvenli tekrar ve çift tahsilatın önlenmesi

Müşteri yanıt alamadığında ödeme düğmesine yeniden basabilir. Ağ katmanı da zaman aşımına uğrayan isteği tekrarlayabilir. Her tekrar yeni bir tahsilat talebi oluşturursa aynı sipariş için birden fazla provizyon alınabilir. Bu riski azaltmak için ödeme başlatma ve sonuç işleme adımlarında idempotency yaklaşımı kullanılmalıdır.

Aynı sipariş, tutar ve deneme anahtarıyla gelen yinelenen istekler önceki güvenli sonuca bağlanmalıdır. Tekrar politikası yalnızca teknik hata koduna göre çalışmamalıdır. Kesin ret, geçici servis hatası ve belirsiz sonuç için farklı kurallar uygulanmalı; belirsiz işlemlerde önce sorgulama yapılmalıdır. İptal ve iade işlemlerinde de aynı denetim mantığı korunmalıdır.

Veri güvenliği ve müşteri gizliliği

3D Secure kullanılması, ödeme ortamını tek başına tüm tehditlere karşı güvenli hâle getirmez. Kart verisinin kapsamı, ödeme sayfasındaki betikler, erişim yetkileri, anahtar yönetimi, güncelleme süreçleri ve kayıt politikaları ayrıca ele alınmalıdır. Mümkün olan projelerde kart verisinin işletme sistemlerine hiç uğramadığı sağlayıcı barındırmalı yöntemler veya güvenli bileşenler değerlendirilmelidir.

PCI Security Standards Council, gömülü ödeme formlarını kullanan işletmeler için ödeme sayfasını etkileyebilecek betik saldırılarına karşı koruma beklentisini açıklar. Kurumun SAQ A ve ödeme sayfası betikleri açıklaması, entegrasyon türünün güvenlik ve uygunluk kapsamını nasıl etkileyebileceğini gösterir. Hangi PCI DSS doğrulama yönteminin geçerli olduğu ise işletmenin gerçek veri akışı, hizmet sağlayıcıları ve kabul kuruluşuyla birlikte değerlendirilmelidir.

• Kart numarası, güvenlik kodu, parola, erişim anahtarı ve kişisel veri uygulama kayıtlarına yazılmamalıdır.
• Aktarım sırasında güncel TLS yapılandırması, güvenli çerezler ve uygun güvenlik başlıkları kullanılmalıdır.
• Ödeme sayfasındaki üçüncü taraf betikler en aza indirilmeli; değişiklikler yetkilendirilmeli ve izlenmelidir.
• Yönetim ekranları rol tabanlı yetkilendirme, güçlü kimlik doğrulama ve işlem günlüğüyle korunmalıdır.
• Kişisel veriler yalnızca belirlenen amaç ve saklama süresi kapsamında tutulmalıdır.

Bu kontroller, projeye özel web yazılım mimarisi içinde ele alındığında ödeme katmanı ile kullanıcı, sipariş, rol ve entegrasyon gereksinimleri tutarlı biçimde yönetilebilir.

Kayıt, izlenebilirlik ve operasyon paneli

İyi bir ödeme kaydı yalnızca “başarılı” sonucundan oluşmaz. İşlemin hangi sürüm ve sağlayıcı üzerinden başladığı, 3D Secure aşamasında hangi genel durumun alındığı, provizyonun ne zaman gönderildiği, bildirimlerin ne zaman işlendiği ve sipariş durumunu hangi servis ya da yetkilinin değiştirdiği izlenebilmelidir.

Kayıtlar ortak bir korelasyon kimliğiyle ilişkilendirilmeli, zaman damgaları tutarlı tutulmalı ve hassas alanlar maskelenmelidir. Operasyon paneli; duruma göre filtreleme, güvenli sorgulama, kontrollü yeniden işleme, iptal ve iade yetkisi sunabilir. Manuel müdahaleler gerekçe, kullanıcı ve zaman bilgisiyle denetim izine eklenmelidir.

Alarm kuralları da iş etkisine göre tasarlanmalıdır. Artan ret oranı, uzun süre bekleyen işlemler, bildirim kuyruğu birikmesi veya sağlayıcı yanıt sürelerindeki bozulma erken uyarı üretmelidir. Böylece sorun yalnızca müşteri şikâyeti geldiğinde fark edilmez.

Test ve canlıya geçiş kontrolü

Sanal POS testi tek bir başarılı kart senaryosuyla tamamlanamaz. Farklı cihazlar, tarayıcılar ve ekran ölçülerinde sürtünmesiz akış, challenge, yanlış doğrulama, kullanıcı iptali, zaman aşımı, kesin ret, geç bildirim ve tekrarlanan istek senaryoları denenmelidir.

• Başarılı ödeme ve başarılı 3D Secure sonrasında reddedilen provizyon ayrı ayrı test edilmelidir.
• Sayfa yenileme, geri tuşu, çift tıklama ve bağlantı kesilmesi simüle edilmelidir.
• Bildirimlerin sırasız, geç veya birden fazla kez gelmesi doğrulanmalıdır.
• İptal, tam iade, kısmi iade ve mutabakat kayıtları kontrol edilmelidir.
• Hassas verilerin loglarda, analiz araçlarında ve hata ekranlarında bulunmadığı teyit edilmelidir.
• Yoğun trafik altında sağlayıcı gecikmesi, kuyruk davranışı ve zaman aşımı sınırları ölçülmelidir.

Canlıya geçişte alan adı ve geri dönüş adresleri, güvenlik duvarı kuralları, sertifikalar, anahtarların güvenli saklanması, erişim rolleri, alarm kanalları ve destek sorumlulukları kontrol edilmelidir. Sağlayıcı kesintisi yaşandığında müşteriye hangi mesajın gösterileceği ve operasyon ekibinin nasıl hareket edeceği önceden belirlenmelidir.

Sürdürülebilir bir ödeme altyapısı için yaklaşım

Sanal POS entegrasyonunun başarısı yalnızca ilk yayında ölçülmez. Banka servisleri, 3D Secure sürümleri, güvenlik gereksinimleri ve iş kuralları zamanla değişebilir. Sağlayıcıya özgü kodun iş mantığından ayrılması; ortak ödeme durumları, sürümlü entegrasyon katmanı, otomatik testler ve ölçülebilir servis hedefleri oluşturulması değişiklik maliyetini azaltır.

Kumsal Ajans; markaya özel e-ticaret platformları ve web yazılımları geliştirirken ödeme adımı kullanıcı deneyimini, sanal POS bağlantılarını, kullanıcı rollerini, veri akışlarını ve operasyon süreçlerini birlikte kurgular. Mobil uyumlu arayüz, test, performans, veri güvenliği ve yönetilebilir yazılım mimarisi proje gereksinimlerine göre ele alınır.

Sanal POS ve 3D Secure 2.0 gereksinimlerinize uygun, hızlı, anlaşılır, yönetilebilir ve güvenlik odaklı ödeme deneyimini Kumsal Ajans ile planlayın.