3D Secure İşlemi Neden Reddedilir? Onay Akışı Kurulumu

3D Secure doğrulamasında bir işlem, kart sahibinin bankası kimlik doğrulamayı tamamlamadığında veya banka tarafı işlemi riskli bulup onay vermediğinde reddedilir; yazılımın görevi bu reddi doğru noktada yakalayıp kullanıcıya anlaşılır bir mesajla göstermektir. Özel yazılım projelerinde sanal POS entegrasyonu çoğu zaman ödeme başarılı / başarısız gibi iki durumlu düşünülür, ama 3D Secure akışı aslında üç ayrı aşamadan geçer ve her aşamada farklı bir hata türü ortaya çıkar. Bu üç aşamayı birbirinden ayırmadan kurulan bir entegrasyon, hem müşteriye yanlış mesaj gösterir hem de muhasebe tarafında hangi siparişin gerçekten ödendiğini belirsizleştirir.

3D Secure akışı kaç adımdan oluşur

Akış, sipariş oluşturma ile ödeme sağlayıcısının sonuç bildirimi arasında üç adıma ayrılır. Yazılımın her adımda ayrı bir durum tutması, hangi adımda sorun çıktığını sonradan tespit edebilmek için gereklidir; tek bir "ödeme durumu" alanı üç adımın hiçbirini ayırt edemez.

• Başlatma: Sipariş ve kart bilgisi sağlayıcıya iletilir, sağlayıcı bankanın doğrulama sayfasının adresini döner.
• Doğrulama: Müşteri bankanın kendi sayfasında SMS kodu ya da banka uygulaması üzerinden kimliğini doğrular; yazılım bu aşamada sağlayıcının sonucunu bekler.
• Sonuçlanma: Sağlayıcı, banka cevabını yazılıma bildirim (callback/webhook) olarak geri gönderir; sipariş bu bildirime göre kapanır.

Bu üç adımın her biri farklı bir sistemde (yazılım, bankanın doğrulama sayfası, ödeme sağlayıcısının sunucusu) gerçekleştiği için, adımlar arasındaki geçişte ağ gecikmesi veya tarayıcı sekmesinin kapanması gibi durumlar da hesaba katılmalıdır.

Ret hangi adımda ve neden oluşur

Her adımın kendine özgü bir ret nedeni vardır ve bu nedenler karıştırılırsa müşteriye yanlış mesaj gösterilir; örneğin doğrulama adımında oluşan bir gecikme, başlatma adımındaki bir kart hatasıyla aynı mesajla gösterilirse müşteri hangi bilgiyi düzelteceğini anlayamaz.

Onay akışı nasıl tasarlanır

Sağlam bir onay akışı, sipariş durumunu doğrulama tamamlanmadan "başarılı" yapmaz ve bildirim gelmeden siparişi kapatmaz. Pratikte iki kural akışın omurgasını oluşturur: sipariş, sağlayıcıdan kesin sonuç bildirimi gelene kadar geçici bir durumda kalır; bildirim geldiğinde sipariş numarası üzerinden eşleştirme yapılır, tutar tekrar karşılaştırılır ve ancak o zaman durum kesinleştirilir.

Bildirim bir süre içinde gelmezse yazılım sağlayıcıya durumu sorgulayan bir kontrol isteği göndermelidir; müşterinin ödediği halde siparişin "reddedildi" görünmesi, iade taleplerinin en sık nedenidir. Bu kontrol isteği, bildirim mekanizmasının yedeği gibi çalışır ve özellikle sağlayıcı tarafında geçici bir aksama olduğunda siparişin kalıcı olarak yanlış durumda kalmasını önler. Kontrol isteğinin hangi aralıklarla ve ne kadar süre tekrarlanacağı, sağlayıcının kendi bildirim gecikme ortalamasına göre belirlenmelidir; bu sayı sağlayıcıdan sağlayıcıya değiştiği için projeye özel ayarlanır.

Müşteriye geri bildirim nasıl olmalı

Reddedilen bir işlemde müşteriye gösterilecek mesaj, ret nedenine göre değişmelidir; aksi hâlde müşteri kartını değiştirmesi gerekirken formu tekrar tekrar doldurur ve aynı hatayı tekrar alır.

1. Kart bilgisi hatalıysa: bilgiyi düzeltip yeniden denemesi istenir.
2. Doğrulama tamamlanmadıysa: işlemin iptal edildiği, tutarın çekilmediği belirtilir.
3. Banka onay vermediyse: bankasıyla görüşmesi ya da başka bir kartla denemesi önerilir.

Bu üç mesaj türünün ayrı tutulması, müşteri hizmetlerine gelen "param gitti ama sipariş görünmüyor" tipi şikayetlerin büyük kısmını da önler; çünkü müşteri hangi adımda kaldığını zaten ekrandan görmüş olur.

Test ortamında sık yapılan hata

3D Secure akışı test edilirken en sık yapılan hata, sadece "başarılı" senaryosunun denenmesidir. Oysa canlıda asıl riskli olan, doğrulama sayfası açıldıktan sonra müşterinin sekmeyi kapatması, bağlantısının kesilmesi ya da aynı siparişi iki farklı sekmeden başlatmasıdır. Test ortamında bu üç senaryo ayrı ayrı denenmeden canlıya geçilirse, sipariş durumunun "beklemede" takılıp kaldığı durumlar ancak gerçek müşteri şikayetiyle fark edilir.

Bir diğer sık görülen hata, sipariş numarasının sağlayıcıya tek yönlü gönderilip geri bildirimde tekrar doğrulanmamasıdır. Sağlayıcıdan gelen bildirimdeki sipariş numarası, tutar ve para birimi; yazılımın kendi kayıtlarıyla tekrar karşılaştırılmalıdır. Bu karşılaştırma atlanırsa, teorik olarak başka bir siparişe ait bir bildirim yanlış siparişi kapatabilir.

Birden fazla sağlayıcı kullanılıyorsa

Bazı işletmeler, farklı kart türleri veya yedeklilik amacıyla birden fazla ödeme sağlayıcısıyla aynı anda çalışır. Bu durumda her sağlayıcının kendi bildirim formatı, kendi ret kodu listesi ve kendi zaman aşımı süresi vardır; yazılımın tek bir ortak "ödeme sonucu" modeli tutması, bu farkları gizleyebilir. Sağlayıcı bazında ayrı ret kodu eşlemesi tutulmadan yapılan bir birleştirme, bir sağlayıcının "beklemede" kodunu başka bir sağlayıcının "reddedildi" koduyla aynı anlama getirebilir.

Bu nedenle entegrasyon katmanında, her sağlayıcının kendi ret kodları önce ortak bir iç duruma (başlatma hatası, doğrulama tamamlanmadı, banka onayı yok gibi) çevrilmeli, müşteriye gösterilecek mesaj bu iç durumdan üretilmelidir. Sağlayıcı değiştiğinde ya da yeni bir sağlayıcı eklendiğinde, değişmesi gereken tek yer bu eşleme katmanı olur; müşteri ekranları ve sipariş akışı aynı kalır.

Özet

3D Secure'de ret, tek bir hata değil üç farklı aşamanın sonucudur; yazılımın bu aşamaları ayrı ayrı izlemesi hem doğru müşteri mesajını hem de doğru muhasebe kaydını garanti eder. KAV Yazılım, sanal POS entegrasyonlarını bu üç aşamalı akışa göre kurar.