Geçtiğimiz hafta, 3D Secure Masterclass'ta 3D Secure mesaj yapısının detaylarını kapsamlı bir şekilde inceledik. Bugünkü blog yazımızda ise Frictionless ve Challenge kavramlarını ele alacağız. Eski alışkanlıklarla gelen “Doğrulama olmadıysa 3D değildir” algısını ortadan kaldırmaya çalışacağız. E-ticaret uygulamalarında kartlı ödeme seçildiğinde, işyeri arka planda entegre olduğu ödeme servis sağlayıcısının "Payment Service Provider (PSP)" sunduğu iki servisten birini çağırır. Bu servisler, secure ve non-secure olarak ikiye ayrılır.
Non-secure servisi ile başlatılan ödeme talebini alan acquirer, 3D Secure işlemi başlatmadan doğrudan otorizasyon mesajını oluşturur ve Visa, Mastercard veya BKM switch'e yönlendirir. Bu tür işlemlerde dolandırıcılık olması durumunda sorumluluk işyerine aittir.
Secure işlemlerde ise işyeri, 3D Secure işleminde kullanılacak ek bilgileri de ekleyerek ödeme servis sağlayıcısına (PSP) iletir. Ödeme servisi sağlayan firma, aynı zamanda acquirer ise (örneğin sanal POS hizmeti veren Garanti Bankası), 3D Secure işlemini kendisi başlatır. Eğer PSP bir acquirer değilse (örneğin Craftgate), işlemi acquiring lisansı olan bir kuruluşa iletir ve o kuruluş 3D Secure işlemini başlatır.
İşyeri tarafından secure olarak başlatılan işleme ait bilgiler, acquirer bankanın kullandığı 3DS Server tarafından Authentication Request mesajına eklenir ve kart network'ünün DS’ine, oradan da kartı basan kuruluş olan Issuer’ın kullandığı ACS’e iletilir. Buraya kadar olan kısım, yakın zamana kadar bildiğimiz ve alışık olduğumuz işlem akışıydı. Ancak, EMV 3D Secure ile hayatımıza giren Frictionless kavramı sayesinde, ek kart sahibi etkileşimi gerektirmeyen bir doğrulama yöntemi ortaya çıkmış oldu.
Frictionless İşlem Akışı
1- AReq mesajını alan ACS, risk tabanlı kimlik doğrulama (RBA) modülüne sahip olan ve ACS ile birlikte çalışan SecureScore uygulamasına işlem bilgilerini ileterek risk analizi yapılmasını ister.
2- SecureScore uygulaması, önceden tanımlanmış kurallar üzerinden bir risk skoru oluşturur ve bu risk skoruna dayalı bir tavsiye kararını ACS’ye iletir.
a) SecureScore, kart ağına ait risk değerlendirmesi, işlem tutarı, işyeri bilgileri ve cihaz bilgileri gibi birçok parametrenin kural oluşturulmasında kullanılmasına olanak sağlar.
b)Sadece mevcut işlem verilerini değil, karta ait geçmiş işlem ve doğrulama verilerini de kullanarak risk analizini güçlendirir.
3- ACS, SecureScore'un tavsiye kararını da ekleyerek issuer'a Verify Account mesajını iletir.
4- Issuer, kart statüsü ve bakiye gibi bilgileri sorguladıktan sonra ekstra bir risk görmüyorsa, Verify Account Response mesajında transStatus: Y değeri belirterek işlemin frictionless (sürtünmesiz) tamamlanacağını ACS’ye iletir.
|
{ "verifyAccountRes": { "acsTransID": "a43d8477-0e93-4bfc-89e9-cd259001ed0e", "issuerTransID": "86447365-1160-4b8d-af71-f3eed493f600", "transStatus": "Y", // İşlemin frictionless tamamlanması için ACS’e iletilen değer "challengeType": null, // Ek doğrulama olmayacağı için challenge tipi de belirtilmeyecektir. "language": "tr", "cardholderInfo": "Risk Değerlendirmesi sonucunda ek doğrulamaya ihtiyaç duyulmamıştır.", // İşyeri ödeme sayfasında kullanıcıya gösterilecek ekstra bilgi. "timeStamp": 20240903134051, "version": "1.0.0", "result": { "resultCode": "00", "resultMsg": "SUCCESS", "resultDetail": "Success" } |
Frictionless İşlem Kullanıcı Deneyimi
Challenge İşlem Akışı
Verify Account mesajında işlem bilgilerini alan issuer, eğer işlemin sonlandırılmasını veya işlemi frictionless olarak doğrulamayı istemiyorsa, işlemi challenge akışına yönlendirmek için Verify Account Response mesajında transStatus: C değerini belirterek challengeType alanında tercih ettiği doğrulama metodunu belirtir. Seçilen doğrulama metoduna göre, ek bilgiler (doğrulama sayfasında görülecek telefon numarası vb.) iletilir.
|
{ "verifyAccountRes": { "acsTransID": "a43d8477-0e93-4bfc-89e9-cd259001ed0e", "issuerTransID": "86447365-1160-4b8d-af71-f3eed493f600", "transStatus": "C", // İşlemin Challenge akış ile devam etmesi için C setlenir. "challengeType": "02", // SMS-OTP için 01, Mobil Bildirim için 02, Passkey için 03 değerleri setlenir. "language": "tr", "deviceName": "Sarac’s iPhone", "mobilePhone": { "cc": "90", "subscriber": "5317150621" }, "cardholderInfo": "Risk Değerlendirmesi sonucunda ek doğrulamaya ihtiyaç duyulmamıştır.", // İşyeri ödeme sayfasında kullanıcıya gösterilecek ekstra bilgi. "timeStamp": 20240903134051, "version": "1.0.0", "result": { "resultCode": "00", "resultMsg": "SUCCESS", "resultDetail": "Success" |
3DS Server’dan CReq mesajı geldikten sonra, diyagramda yer alan 12. adım ile birlikte Challenge Action mesajı issuer’a iletilir. Bu mesaj içerisinde, issuer’ın tercih ettiği doğrulama metoduna göre ek yönlendirmelerde bulunulur.
|
{ "challengeActionReq": { "acsTransID": "dd290456-4b19-49a1-a8ad-5bf65b0b18be", "refNo": "SUZLXCZV", "issuerTransID": "007df537-b431-4aef-9041-f41074a18c2a", "actionType": "START_OOB", // Mobil bildirimi göndermesi için gelen actionType bilgisidir. Eğer OTP gönderilmesi istenirse bu alanda “SEND_OTP” bilgisi yer alacaktır. "notificationURL": "https://release2-acs-mysql.finartz.dev/acs/crstn", // Issuer mobil uygulaması aracılığı ile kullanıcısını doğruladıktan sonra doğrulama sonucunu ileteceği ACS URL’idir. "otpData": null, // Mobil bildirim doğrulama metodunda iletilmez, eğer SMS-OTP ile doğrulama yapılacak olsaydı kullanıcıya iletilecek OTP bilgisi burada yer alacaktı. "version": "1.0.0", "timeStamp": 20240903173831 } |
Challenge İşlem Kullanıcı Deneyimi
