3D Secure Doğrulama Sürecinde AReq ve ARes Aşaması [2. Kısım]
- Giriş
Önceki yazımızda 3D Secure doğrulama sürecinin başlangıç aşamasını ve kartın 3D Secure doğrulamasına uygunluğunun nasıl kontrol edildiğini ele aldık.
Bu bölümde ise EMV 3-D Secure 2.x protokolünün en önemli mesajlarından olan AReq (Authentication Request) ve ARes (Authentication Response) mesajlarını inceleyeceğiz.
AReq mesajının gönderilmesiyle birlikte kart sahibi, üye işyeri ve kartı çıkaran banka arasındaki gerçek kimlik doğrulama süreci başlar.
Bu aşamada amaç yalnızca kartın 3D Secure sistemini destekleyip desteklemediğini öğrenmek değildir. İşleme ait çok sayıda veri kart çıkaran bankaya iletilerek işlemin risk değerlendirmesinin yapılması ve kart sahibinden ek doğrulama istenip istenmeyeceğinin belirlenmesi amaçlanır.
- AReq (Authentication Request) Nedir?
AReq (Authentication Request), EMV 3DS doğrulama sürecini başlatmak amacıyla oluşturulan kimlik doğrulama isteğidir.
AReq içerisinde yalnızca kart bilgileri bulunmaz. İşlemin risk seviyesinin değerlendirilebilmesi için işlem, üye işyeri, cihaz ve kart sahibi hakkında çeşitli bilgiler de taşınabilir.
Örneğin AReq mesajında aşağıdaki bilgiler bulunabilir:
Kart numarası
Kartın son kullanma tarihi
İşlem tutarı
Para birimi
Üye işyeri bilgileri
İşlem zamanı
Browser bilgileri
IP adresi
Cihaz bilgileri
3DS Server bilgileri
İşlem tipi
Challenge tercihleri
Bu bilgiler kullanılarak Issuer/ACS tarafında işlemin risk değerlendirmesi gerçekleştirilir.
- AReq Mesaj Akışı
EMV 3DS mimarisinde AReq mesajının temel akışı aşağıdaki şekilde düşünülebilir:
Kart Sahibi | v Üye İşyeri | v 3DS Server | | AReq v Directory Server (DS) | | AReq v Access Control Server (ACS) | | ARes v Directory Server (DS) | | ARes v 3DS Server
Burada önemli noktalardan biri, üye işyerinin doğrudan Issuer bankanın ACS sistemine bağlanmamasıdır.
3DS Server tarafından oluşturulan AReq mesajı ilgili kart şemasının Directory Server (DS) sistemine gönderilir. Directory Server ise kart bilgilerine göre ilgili ACS (Access Control Server) sistemini belirleyerek mesajın doğru Issuer tarafına yönlendirilmesini sağlar.
- AReq Mesajının Hazırlanması
AReq mesajında EMV 3DS protokolünün çalışabilmesi için çeşitli alanlar bulunur.
Basitleştirilmiş bir AReq mesajı aşağıdaki gibi düşünülebilir:
{ "messageType": "AReq", "messageVersion": "2.2.0", "threeDSServerTransID": "550e8400-e29b-41d4-a716-446655440000", "acctNumber": "4111111111111111", "cardExpiryDate": "2812", "purchaseAmount": "10000", "purchaseCurrency": "949", "purchaseExponent": "2", "purchaseDate": "20260918183000", "merchantName": "Example Store", "merchantCountryCode": "792", "deviceChannel": "02" }
Bu örnek yalnızca mesaj yapısını anlatmak amacıyla sadeleştirilmiştir. Gerçek EMV 3DS AReq mesajında kullanılan alanlar ve zorunlulukları protokol sürümüne, cihaz kanalına ve işlem tipine göre değişebilir.
Buradaki bazı önemli alanları inceleyelim.
messageType
Gönderilen mesajın türünü belirtir.
AReq
değeri mesajın bir Authentication Request olduğunu gösterir.
messageVersion
Kullanılan EMV 3DS protokol sürümünü belirtir.
Örneğin:
2.2.0
threeDSServerTransID
3DS Server tarafından oluşturulan ve işlemin 3DS doğrulama süreci boyunca takip edilmesini sağlayan benzersiz işlem kimliğidir.
Genellikle UUID formatındadır.
acctNumber
Kimlik doğrulaması gerçekleştirilecek kartın PAN bilgisidir.
cardExpiryDate
Kartın son kullanma tarihidir.
purchaseAmount
İşlem tutarını belirtir.
Burada dikkat edilmesi gereken önemli nokta, tutarın çoğunlukla para biriminin exponent değerine göre en küçük para birimi üzerinden gönderilmesidir.
Örneğin:
100.00 TL
için:
purchaseAmount = 10000 purchaseExponent = 2
şeklinde bir gösterim kullanılabilir.
purchaseCurrency
İşlemin para birimini ISO 4217 numeric currency code formatında belirtir.
Örneğin Türk Lirası:
949
olarak ifade edilir.
deviceChannel
3D Secure işleminin hangi kanal üzerinden gerçekleştirildiğini belirtir.
Örneğin browser tabanlı bir işlemde ilgili browser/device channel değeri kullanılır.
- AReq Mesajının Directory Server'a Gönderilmesi
3DS Server gerekli bilgileri topladıktan sonra AReq mesajını oluşturur ve ilgili kart şemasının Directory Server (DS) sistemine gönderir.
Directory Server'ın temel görevlerinden biri gelen kart bilgisini değerlendirerek işlemin hangi ACS sistemine yönlendirilmesi gerektiğini belirlemektir.
Basitleştirilmiş olarak:
3DS Server | | AReq v Directory Server | | Kart hangi Issuer'a ait? | v Issuer ACS
Directory Server böylece 3DS Server ile farklı bankaların ACS sistemleri arasında yönlendirme katmanı görevi görür.
- ACS Tarafında Risk Değerlendirmesi
AReq mesajı ACS sistemine ulaştığında kartı çıkaran kuruluş işlem hakkında risk değerlendirmesi gerçekleştirebilir.
Bu değerlendirmede birçok farklı veri kullanılabilir.
Örneğin:
İşlem tutarı
Üye işyeri
Kart sahibinin geçmiş işlem davranışları
Kullanılan cihaz
IP adresi
Browser bilgileri
İşlem yapılan ülke
Kartın geçmiş kullanım davranışları
Şüpheli işlem göstergeleri
Issuer'ın kendi fraud/risk sistemleri
Bu değerlendirme sonucunda ACS, işlemin nasıl devam edeceğine karar verir.
Temel olarak iki önemli senaryo ortaya çıkar:
AReq
|
v
Risk Analizi
/ \
/ \
v v
Frictionless Challenge
Flow Flow
- ARes (Authentication Response) Nedir?
ACS tarafından AReq mesajına karşılık oluşturulan cevap ARes (Authentication Response) mesajıdır.
ARes, kimlik doğrulama işleminin nasıl devam edeceğini 3DS Server'a bildirir.
Basitleştirilmiş bir ARes örneği:
{ "messageType": "ARes", "messageVersion": "2.2.0", "threeDSServerTransID": "550e8400-e29b-41d4-a716-446655440000", "acsTransID": "660e8400-e29b-41d4-a716-446655440001", "dsTransID": "770e8400-e29b-41d4-a716-446655440002", "transStatus": "Y" }
ARes içerisindeki en önemli alanlardan biri:
transStatus
alanıdır.
Bu alan, authentication işleminin sonucunu veya sonraki adımını belirler.
- transStatus Değeri
ARes mesajındaki transStatus, 3D Secure akışının nasıl devam edeceğinin anlaşılması açısından kritik öneme sahiptir.
Örneğin:
transStatus = Y
kimlik doğrulamanın başarılı olduğunu ifade eder.
Bu durumda kart sahibine OTP veya mobil bankacılık onayı gibi ek bir ekran gösterilmeden işlem tamamlanabilir.
Bu senaryoya:
Frictionless Flow
adı verilir.
Ancak:
transStatus = C
dönmesi durumunda kart sahibinin ek doğrulama gerçekleştirmesi gerekir.
Bu senaryoya ise:
Challenge Flow
adı verilir.
Akış şu şekilde ilerler:
AReq | v ACS | v ARes | +----------------------+ | | v v transStatus = Y transStatus = C | | v v Authentication Challenge başarılı gerekli
- Frictionless Flow
EMV 3DS 2.x ile gelen en önemli geliştirmelerden biri Frictionless Flow mekanizmasıdır.
Issuer/ACS, AReq içerisindeki bilgileri kullanarak işlemin düşük riskli olduğuna karar verebilir.
Bu durumda kart sahibinden:
SMS OTP
Mobil bankacılık onayı
Şifre
Biyometrik doğrulama
gibi ek bir doğrulama istenmeden authentication işlemi tamamlanabilir.
Kullanıcı açısından bakıldığında süreç yaklaşık olarak:
Ödeme Yap | v AReq | v Risk Analizi | v ARes (Y) | v Ödeme Akışına Devam
şeklinde gerçekleşir.
Kart sahibi arka planda gerçekleştirilen 3D Secure doğrulamasını çoğu zaman fark etmez.
- Challenge Flow
ACS işlemin riskli olduğunu düşünürse veya başka bir nedenle kart sahibinin doğrulanmasını gerekli görürse ARes içerisinde:
transStatus = C
dönebilir.
Bu durumda Challenge Flow başlatılır.
Challenge aşamasında kart sahibinden ek doğrulama istenir.
Örneğin:
SMS OTP
Mobil bankacılık bildirimi
Banka uygulaması üzerinden onay
Biyometrik doğrulama
Bankanın desteklediği başka bir doğrulama yöntemi
kullanılabilir.
Challenge işlemi EMV 3DS içerisinde ayrı mesajlarla devam eder.
Bunların en önemlileri:
CReq – Challenge Request CRes – Challenge Response
mesajlarıdır.
- AReq ve ARes İşlem Kimlikleri
EMV 3DS işlemlerinde aynı authentication işleminin farklı sistemlerde takip edilebilmesi için çeşitli Transaction ID değerleri kullanılır.
Önemli olanlardan bazıları:
threeDSServerTransID acsTransID dsTransID
şeklindedir.
threeDSServerTransID
3DS Server tarafından oluşturulur.
acsTransID
ACS tarafından oluşturulur.
dsTransID
Directory Server tarafından oluşturulur.
Bu ID'ler sayesinde aynı 3D Secure işlemi farklı bileşenlerin loglarında takip edilebilir.
Örneğin:
Merchant | 3DS Server | threeDSServerTransID v Directory Server | dsTransID v ACS | acsTransID v Issuer
Özellikle production ortamlarında 3D Secure hatalarının araştırılması sırasında bu transaction ID değerleri oldukça önemlidir.
- Authentication ve Authorization Farkı
Burada sık karıştırılan önemli bir konu bulunmaktadır.
AReq, Authorization Request anlamına gelmez.
EMV 3DS protokolünde:
AReq = Authentication Request ARes = Authentication Response
anlamına gelir.
Authentication işleminin amacı:
Kartı kullanan kişinin gerçekten kart sahibi olup olmadığının doğrulanmasına yardımcı olmaktır.
Authorization işleminin amacı ise:
Karttan ilgili tutarın çekilip çekilemeyeceğinin Issuer tarafından değerlendirilmesidir.
Dolayısıyla genel ödeme akışını kavramsal olarak şöyle ayırabiliriz:
3D Secure Authentication | | AReq / ARes | | gerekirse | CReq / CRes v Authentication Result | v Payment Authorization | v Issuer | v Approved / Declined
Bu iki süreç birbirleriyle ilişkili olsa da aynı işlem değildir.
- AReq/ARes Aşamasının Önemi
AReq ve ARes mesajları EMV 3DS doğrulamasının merkezinde yer alır.
Bu aşamada Issuer, işlem hakkında çok daha fazla bilgiye sahip olarak risk değerlendirmesi gerçekleştirebilir.
Bunun sonucunda düşük riskli işlemler Frictionless Flow üzerinden hızlı şekilde tamamlanabilirken, daha fazla doğrulama gerektiren işlemler Challenge Flow sürecine yönlendirilebilir.
Böylece güvenlik ile kullanıcı deneyimi arasında daha iyi bir denge kurulması amaçlanır.
- Sonuç
Bu bölümde EMV 3DS doğrulama sürecindeki AReq (Authentication Request) ve ARes (Authentication Response) mesajlarını ele aldık.
Genel akışı özetlersek:
Kart Sahibi | v Üye İşyeri | v 3DS Server | | AReq v Directory Server | | AReq v ACS | | Risk Analizi | | ARes v Directory Server | v 3DS Server
ARes sonucunda işlem Frictionless Flow ile doğrudan tamamlanabilir veya kart sahibinden ek doğrulama alınması için Challenge Flow başlatılabilir.
Challenge gerektiğinde artık EMV 3DS protokolünün bir sonraki önemli mesajları devreye girer:
CReq – Challenge Request CRes – Challenge Response
- kısımda, transStatus = C dönen bir işlemin ardından Challenge sürecinin nasıl başlatıldığını, CReq ve CRes mesajlarını, ACS ekranının kart sahibine nasıl gösterildiğini ve doğrulama sonucunun 3DS Server'a nasıl ulaştığını inceleyeceğiz.