3D Secure 2.0'a yakından bir bakış
E-Ticaret ’te Güvenli Ödemelerin Lokomotifi 3D Secure, “2.0” versiyonu ile geliyor ! başlıklı yazımda, 3D Secure (3DS) Sistemi ve bu sistemin 2.0 versiyonu ile ilgili genel bilgileri paylaşmıştım.
Bu yazımda ise, 3DS 2.0 ‘ı daha detaylı incelerken, temel bilgiler olarak, 3DS bileşenleri, işlem akışları ve akışlarda kullanılan mesajlarla ilgili detayları, 3DS 1.0 ile karşılaştırmalı anlatıyor olacağım.
2019 yılının ikinci çeyreği itibariyle, hayatımıza girecek olan 3DS 2.0, E-Ticaret dünyasında Güvenli Ödemeler ile ilgili değişiklikleri beraberinde getirecek. Bu değişikliklerin doğru şekilde hayata geçmesi için de, 3DS 2.0 ile ilgili bilgileri doğru şekilde anlamak, uygun çözümlerin ortaya konulması açısında önem arz ediyor olacak.
3 Domain nedir?
3DS Sistemi, E-Ticaret ’te ödeme işleminde kullanılan kartın, gerçek kart hamili olup olmadığını, üç bölgeye (3 Domain) yayılan bileşenlerin etkileşimi ile doğrulayan bir sistemdir ve sistemin ismi de buradan gelir.
3DS Sistemi ’ndeki üç Domain, iş yerlerini ve bunların çalıştığı bankaları bulunduran “Acquirer Domain”, ödemede kullanılan kartlar ile bu kartın basıldığı bankaların bulunduğu “Issuer Domain” ve bu iki Domain arasında iletişimi sağlayan, kart şemalarının bileşenlerinin bulunduğu “Interoperability Domain” den oluşmaktadır.
3DS Sistemi bileşenleri nelerdir?
3DS 2.0 ile birlikte, 3DS 1.0 'daki Domain yapısı bir değişikliğe uğramamış olup, bu Domain ’lerdeki bazı bileşenlerde çeşitli değişiklikler olmuştur. Bu değişikliklerin özeti aşağıdaki tablodaki gibidir:
Issuer Domain Bileşenleri
Access Control Server (ACS) : Issuer Domain ‘in tek bileşeni olan ACS, ilgili Issuer bankaların belirlediği kurallar ve yöntemlerle kart hamillerinin doğrulanmasını sağlar.
ACS ‘in 3DS 1.0 ‘da iki temel fonksiyonu vardır :
- İlgili kartın kayıtlı ve doğrulanabilir olup olmadığını kontrol eder.
- Issuer bankanın belirlediği yöntemler ile kart hamilini doğrular. (Challenge)
3DS 1.0 ‘da doğrulama akışı için “Challenge” in uygulandığı tek bir akış işletilirken, 3DS 2.0 ‘daki doğrulama akışı, iki farklı akış ile de sonuçlanabilir. 3DS 1.0 ‘dan farklı olarak ACS, bir Risk Doğrulaması yaparak, “Frictionless” akış sonucunda işlemin “Challenge” akışı işletilmeden tamamlanmasını sağlayabilir. Ayrıca 3DS 2.0 ‘da, sadece ödeme işlemleri için değil, ödeme haricindeki işlemler (Non-Payment) için de 3DS doğrulama akışı gerçekleştirilebilmektedir.
Interoperability Domain Bileşenleri
Directory Server Certificate Authority (DS CA) : 3DS Server/MPI ile DS, DS ile ACS arasındaki TLS haberleşmesinde kullanılan sertifikaları imzalayan Certificate Authority ‘lerdir. Ayrıca, 3DS işlem sonuçlarının ACS tarafından dijital olarak imzalanmasında kullanılan sertifikalar da, ilgili Certificate Authority ‘ler tarafından imzalanır. İlgili Certificate Authority, 3DS işlemlerde, işlem anında yer almaz. Sistemin kuruluş aşamasında ilgili sertifikalar burada imzalanır ve sistemlere tanıtılır. İmzalama işlemini gerçekleştiren Certificate Authority ‘ler, Visa, Mastercard, JCB, American Express, China UnionPay ve Discover gibi kart şemalarının kendileridir.
Directory Server (DS) : Directory Server, Acquirer Domain ile Issuer Domain bileşenleri arasındaki bağlantıyı sağlayan bir bileşendir. Bir 3DS işlemi, Acquirer Domain ‘deki 3DS Server/MPI ile başlar. Ancak bu bileşenlerde, kart hamilinin doğrulamasının yapılacağı ACS ‘lerin bilgileri bulunmamaktadır. Bu sebeple, öncelikle işlemler, DS ‘lere yönlendirilir.
3DS 1.0 akışında DS ‘lerin rolleri aşağıdaki gibidir :
- İlgili iş yerinin DS ‘te kayıtlı olup olmadığını doğrulamak,
- İşlemde kullanılan kart için, ilgili kart aralığını içeren bir ACS ‘in olup olmadığını kontrol etmek,
- İşlemi ilgili ACS ‘e yönlendirmek ve ACS ‘ten aldığı cevabı MPI ‘ya dönmek.
3DS 2.0 ile birlikte, DS ‘lerde de ek roller oluşmuştur :
- İş yerleri tarafında 3DS Server ‘da, 1.0 ve 2.0 işlem yönetiminin yapılabilmesi için, ACS ‘lerin versiyon ve çeşitli bilgilerini (3DS Method gibi) tutmak ve gerektiğinde bu bilgileri (PReq/PRes) iletmek,
- 3DS SDK tarafından şifreli olarak iletilen Cihaz Bilgisi ‘ni deşifre etmek ve AReq mesajında ACS ‘e iletmek,
- AReq mesajı içerisinde çeşitli bilgileri (DSTransactionID) doldurmak,
- 3DS işlem sonucunu (RReq/RRes), ACS ‘ten 3DS Server ‘a göndermek,
- Başarılı bir 3DS işlemi sonucunda ACS ‘te hesaplanan kriptogramı CAVV/AAV olarak 3DS Server ‘a iletmek.
Authentication History Server (AHS) : 3DS 1.0 akışında, Kart Hamili doğrulama sonucu (PARes) ACS ‘den MPI ‘ya doğrudan gönderildiğinden, 3DS işlem sonuçları kart şemaları tarafından bilinememektedir. Bu sebepten dolayı, kart şemalarının 3DS sistem performansını analiz edebilmeleri ve bir işlem ile ilgili itiraz süreçlerinde ilgili işlem detaylarını inceleyebilmeleri için, ACS ‘ler 3DS işlem sonuçlarını (PATransReq) asenkron bir şekilde Authentication History Server denilen bileşenlere göndermektedirler. 3DS 2.0 ‘da, bu bileşen kaldırılmıştır.
Acquirer Domain Bileşenleri
Merchant Server Plug-In (MPI) : 3DS 1.0 akışında, E-Ticaret web sitelerinin 3DS akışını başlatabilmek için entegre olduğu ve 3DS işlemini başlattığı bileşendir. Bu bileşenin rolleri aşağıdaki gibidir :
- 3DS akışı için gerekli olan işlem bilgilerini toplamak,
- İş yeri bilgilerini kontrol etmek,
- DS ‘e gönderilmek üzere VEReq mesajını hazırlamak ve iletmek,
- ACS ‘e yönlendirilmek üzere, PAReq mesajını hazırlamak ve iletmek,
- ACS ‘ten dönülen Kart Hamili doğrulama sonucunun geçerliliğini kontrol edip, 3DS Requestor ‘a yönlendirmek.
3DS 2.0 ‘da bu bileşenin ismi, 3DS Server olarak değişmiştir.
3DS Requestor Environment : 3DS 2.0 ile birlikte, Acquirer Domain bileşenleri, rolleri ve fonksiyonları doğrultusunda daha net olarak tanımlanmıştır. 3DS Requestor, 3DS Client ve 3DS Server isimli 3 bileşen, 3DS Requestor Environment ‘ı oluşturmaktadır.
3DS Requestor : İş yerinin web sitesinde, 3DS işlem akışını başlatmaktan sorumlu bileşendir. Hem Web, hem de Mobil App akışını destekleyecek şekilde, 3DS veri akışını sağlamaktadır.
3DS Client : 3DS App akışında 3DS SDK, 3DS Web akışında ise Browser olan bileşendir.
3DS App akışında, iş yerinin mobil uygulamasında 3DS SDK ‘yı çağıran, 3DS Requestor App isimli kavramsal bir bileşen bulunur. İlgili mobil uygulamadan, 3DS akışı başlatılmak istenirse, öncelikle bu 3DS Requestor App isimli bileşene bir çağrı yapılır. 3DS Requestor App de, 3DS SDK ile konuşarak, 3DS işleminin başlatılabilmesi için gerekli parametreleri hazırlamasını sağlar. Bu bilgiler alındıktan sonra, 3DS Requestor üzerinden yapılan çağrı ile 3DS Server, AReq mesajını iletilerek 3DS işlemini başlatmış olur.
3DS Web akışında ise, 3DS Client bileşeni olan Browser, ACS ‘teki Risk Doğrulaması için kendisi ile ilgili ortam bilgilerini paylaşıyor olur.
3DS Server : 3DS 1.0 ‘daki MPI ‘ın yerini alan bileşendir. 3DS işlem akışı içerisinde, 3DS Requestor ile DS arasındaki iletişimi sağlayan bileşendir. Bu bileşende, iş yerlerine ait bilgiler bulunur. Bir 3DS işlemi, 3DS Requestor aracılığıyla başlatıldığında, 3DS Server kendisine gelen bu isteği, uygun bir mesaj yapısına dönüştürerek (AReq) DS ‘e iletir. Ayrıca, DS ‘ten gelen mesajları (ARes, RReq) yorumlamak ve 3DS Requestor ‘a iletmekten de sorumludur.
3DS 2.0 işlem akışında kullanılan mesajlar nedir?
3DS 2.0 işlem akışında, 3DS 1.0 ‘da kullanılan XML mesajları yerine, artık daha basit bir yapısı olan JSON mesajları kullanılmaya başlanıyor. 3DS mesaj isimleri de bu doğrultuda farklılaşıyor.
Authentication Message (AReq/ARes) : 3DS 1.0 ‘daki “Verification Enrollment” mesajına karşılık gelen mesaj olup, 3DS 2.0 işlem akışında Acquierer Domain ‘deki işyeri ve 3DS Server ‘daki tüm işlem bilgilerinin ACS ‘e iletildiği mesajdır. İlgili işlem bilgilerinin sayısı, VEReq mesajındaki bilgilerin yaklaşık 10 katı olup, 4 ana başlıkta toplanabilir :
- Kart Hamili bilgileri
- İşlem bilgileri
- Cihaz bilgileri
- İşyeri bilgileri
Bu mesajın cevabında (ARes) ise, işlemin nasıl sonuçlanacağı veya devam edeceği (frictionless/challenge) bilgisi dönülmüş olunur.
Challenge Message (CReq/CRes) : 3DS 1.0 ‘daki “Payer Authentication” mesajına karşılık gelen mesaj olup, 3DS 2.0 ‘daki “Authentication” sonucu ilgili işlem için ek bir doğrulama yapılmasını gerektiriyorsa, App için 3DS SDK ‘dan, Web içinse 3DS Server ‘ın oluşturduğu HTML Form ile Browser üzerinden, “Challenge” mesaj akışı başlatılır.
3DS SDK ‘nın iletmiş olduğu mesajlar, Web ‘ten farklı olarak, Eliptic Curve algoritması ile şifreli olarak ACS ‘e iletilmektedir.
Bu mesaj, işlem akışında birkaç defa tekrarlanır. İlk mesaj, kart hamilini doğrulayacak olan soruları içeren içeriği, ikinci mesaj ise bunların cevabı ve sonucunu iletmek için gönderilir.
Result Message (RReq/RRes) : 3DS 2.0 ‘a özel olan bu mesaj, “Challenge” akışındaki doğrulama sonucunun 3DS Server ‘a iletilmesi için kullanılır. 3DS 1.0 ‘dan farklı olarak, CAVV/AAV kriptogramları, Browser üzerinden değil, bu mesaj içerisinde gönderilir.
Preparation Message (PReq/PRes) : 3DS 2.0 ‘a özel olan bu mesaj, ilgili BIN aralığı için hangi 3DS versiyonunu desteklediği bilgisinin, 3DS Server tarafından öğrenilmesi için kullanılır. 3DS Server, bu mesaj isteklerini belirli periyotlarda, örneğin günde 1 defa, DS ‘lere göndererek, tanımlı Kart BIN ‘leri ile ilgili gerekli bilgileri alır ve kendi sisteminde kaydeder. Böylece, hem 3DS 1.0, hem de 3DS 2.0 ‘ı destekleyen 3DS Server ’lar, kendisine bir 3DS isteği geldiğinde hangi 3DS mesaj protokolü ile işlemi başlatacağını bilip, ona göre ilgili sisteme yönlendiriyor olur.
3DS işlem akışı nasıl gerçekleşmektedir?
3DS 1.0, sadece bir ödeme işleminde bir kart hamilinin doğrulamasına olanak sağlarken, 3DS 2.0 ile birlikte, kart hamili için bir Risk Değerlendirmesi yapılarak ilgili kart hamilinin doğrulanmasına gerek kalmadan, “Frictionless” akış (yeşil ile belirtilen) ile işlem sonuçlanabilmektedir. Ek olarak 3DS 2.0, sadece ödeme işlemleri için değil, bir dijital cüzdana bir kullanıcı eklenmesi gibi, ödeme harici işlemler (Non-Payment) için de kullanılmasına olanak sağlar. “Non-Payment” işlemler için, mavi ile belirtilen provizyon akışı gerçekleşmemektedir.
Bir ödeme işleminde, 3DS akışının adımları 1.0 ve 2.0 karşılaştırmalı olarak aşağıdaki gibidir.
