Bu Akışın Hangi Entegrasyona Ait Olduğunu Bilin
iyzico doğrudan API 3DS uygulaması, başlatma ve ödeme tamamlama adımlarını ayrı yürütür. Müşterinin banka doğrulama ekranına ulaşması veya SMS kodunu girmesi tek başına siparişin tahsil edildiğini kanıtlamaz. Bu açıklama, doğrudan API içindeki 3DS yapısı içindir; hazır ödeme formuna aynı işlemler gelişigüzel eklenmemelidir. İncelemeye başlamadan önce kullanılan ödeme yönteminin CheckoutForm mu yoksa doğrudan API mi olduğu belirlenir. Aynı sağlayıcının farklı ürünleri, aynı sunucu çağrılarını işletmenin kendisinin yapmasını gerektirmeyebilir. Yanlış entegrasyon tarifine göre müdahale etmek sorunu büyütebilir.
Doğrulama Dönüşünü Doğru İşlemle Eşleştirin
Banka doğrulaması sonrasında callback adresine gelen veride paymentId, status ve mdStatus gibi alanlar bulunur. Başarılı 3D doğrulama için mdStatus değeri 1 olarak belgelenir. conversationData gönderilmişse Auth isteğine taşınmalıdır. Örneğin müşteri iki ayrı ödeme denemesi başlattığında ikinci sekmeden gelen sonucun ilk denemeye yazılması yanlış sipariş onayı oluşturabilir. Bu nedenle ödeme kimliği, işletmenin işlem referansı ve beklenen sipariş birlikte eşleştirilir. Tarayıcının başarı sayfasına ulaşmasını sunucu doğrulaması yerine kullanmak, kayıp veya tekrar eden dönüşlerde güvenilir sonuç vermez.
iyzico Sandbox Doğrulama Ekranı
iyzico resmî dokümanındaki sandbox örneği, SMS doğrulama aşamasını gösterir. Bu test ekranı tahsilatın tamamlandığını göstermez; canlı bankanın ekranı farklı olabilir.
Auth Yanıtını Ayrı Değerlendirin
Auth 3DS çağrısı, başarılı doğrulama sonrasında ödemeyi tamamlayan adımdır. Yanıttaki işlem sonucu ile paymentId, tutar ve para birimi beklenen kayıtla karşılaştırılmalıdır. Başarılı doğrulama sonucunu alıp Auth adımını hiç çalıştırmayan bir uygulama, müşteriye olumlu ekran gösterse bile tamamlanmış tahsilat kaydı üretmeyebilir. Ayrıca fraudStatus alanı onay, inceleme veya ret durumunu belirtir; bu alanın anlamı uygulamanın sevkiyat kararında göz ardı edilmemelidir. Tek bir HTTP yanıt kodunu okuyup bütün ödeme alanlarını aynı başarılı durumuna dönüştürmek yeterli bir kontrol değildir.
Belirsiz Sonuçta Aynı Tahsilatı Körlemesine Tekrarlamayın
Sunucu bağlantısı kesildiğinde uygulama yanıtı alamamış olabilir; bu durum işlemin sağlayıcı tarafında hiç oluşmadığını tek başına kanıtlamaz. Önerilen operasyon yaklaşımı, mevcut ödeme kimliğinin sonucunu araştırmadan müşteriden yeniden ödeme istememektir. Aynı sipariş için birden fazla bildirim geldiğinde sipariş onayı ve sevkiyat gibi yan etkilerin tekrar oluşması da engellenmelidir. Destek incelemesinde olayların sırası, işlem referansı ve alınan yanıt kodu kaydedilir. Kartın tamamı, güvenlik kodu veya doğrulama parolası tanılama notuna eklenmez. Müşteriye gösterilen mesaj kesinleşmemiş tahsilatı kesin başarılı olarak sunmamalıdır.
Başarılı ve Başarısız Senaryoları Ayırın
Doğrulama reddi, müşterinin pencereyi kapatması, Auth hatası ve başarılı ödeme ayrı test senaryolarıdır. Örneğin SMS doğrulaması başarısız olduğunda sipariş beklenen hata durumunda kalmalı; başarılı doğrulama ve tamamlanmış ödeme birlikte gerçekleştiğinde doğru sipariş güncellenmelidir. Testte aynı dönüşün yeniden gelmesi ve sayfanın yenilenmesi de değerlendirilir. Görseldeki sandbox ekranı doğrulama aşamasını örnekler; canlı banka ekranının aynı görüneceği veya aynı kodu kullanacağı anlamına gelmez. Başarılı entegrasyon, müşterinin gördüğü sonuçla sağlayıcıdaki ödeme ve mağazadaki sipariş kaydının tutarlı olmasıdır.
Bu Yazıdaki Terimler 1 Kavram
Kısa açıklamaları burada okuyabilir, ayrıntılar için sözlüğe geçebilirsiniz.
- HTTP Durum Kodu (HTTP Status Code)
- HTTP durum kodu, sunucunun bir tarayıcıdan, bottan ya da uygulamadan gelen isteğe verdiği yanıtın sonucunu bildiren üç haneli sayıdır; ilk hane yanıtın beş sınıftan hangisine girdiğini gösterir.
Bu Konuda Nasıl Destek Oluyoruz?
AdPix’in bu alandaki hizmet kapsamını ve çalışma sürecini inceleyin.