3D Secure 2.0 geçişinin E-Ticaret işyerlerine ve SanalPOS hizmet sağlayıcılarına etkileri
2019 Nisan ayı itibariyle, 3D Secure 2.0 (3DS 2.0) işlemler, tüm dünya ile birlikte, Türkiye’de de gerçekleşmeye başladı. 3D Secure sistemindeki bu dönüşüm planlandığı gibi, öncelikle kart sahibi Bankalar ve e-Para Kuruluşlarının 3DS 2.0 bileşenlerinden ACS (Access Control Server) uygulamalarının devreye girmesiyle başlamış oldu.
Doğal olarak, bir 3DS 2.0 işleminin gerçekleşebilmesi için, sadece ACS uygulamalarının hizmet vermesi yeterli olmuyor. 3DS 2.0 işlemin başlayabilmesi için, 3DS 2.0 bileşenlerinden 3DS Server(MPI)’ların da hizmet vermesi ve buna E-Ticaret işyerlerinin entegre olması da gerekiyor.
Şu anda, Visa/Mastercard gibi Kart Şemaları ile yakın çalışan, yurt dışında faaliyet gösteren, çeşitli Sanal POS Hizmet Sağlayıcılar ile Bankaların 3DS Server(MPI)’ları ve bunlara entegre olan pilot E-Ticaret işyerleri üzerinden başlatılan işlemler, 3DS 2.0 işlem trafiğini oluşturuyor. Dolayısıyla Türkiye’de 3DS 2.0 geçişini tamamlamış kart sahibi Bankalar veya e-Para Kuruluşlarının kartları ile, yurt dışı E-Ticaret işyerlerinden başlatılan 3DS 2.0 işlemleri gerçekleşiyor.
Ancak 2020 Ocak ayı itibariyle 3DS 2.0 çözümleri, Türkiye’de faaliyet gösteren E-Ticaret işyerleri için de, SanalPOS Hizmet Sağlayıcılar ile Bankalar tarafından sunulmaya başlanacak.
Bu yazımda, 3DS 2.0'ın akışlarını ve mevcut 3DS 1.0'ın entegrasyonlarını da gözeterekten, Sanal POS Hizmet Sağlayıcılar ile Bankalar/e-Para Kuruluşlarının nasıl bir çözüm ortaya koyabileceğini ve bu çözümler doğrultusunda, bir E-Ticaret işyerinin 3DS 2.0 entegrasyonu için nasıl ve ne kadar bir çalışma yapabileceğini anlatacağım.
E-Ticaret işyerlerinin mevcutta kullandıkları 3DS Ödeme Modelleri nelerdir?
Bir E-Ticaret işyeri, web sitesinde 3DS Ödeme fonksiyonunu hayata geçirmek istiyorsa, SanalPOS Hizmet Sağlayıcılar ile Bankalar/e-Para Kuruluşlarının SanalPOS platformlarına entegre olmak için gerekli yazılım değişikliklerini, paylaşılmış olan dokümanlar doğrultusunda yapıyorlar. Bu entegrasyonlar her bir kuruluş için farklılık gösterebiliyor. Dolayısıyla, bir işyeri birden fazla, SanalPOS Hizmet Sağlayıcı veya Banka/e-Para Kuruluşu ile çalışmak istiyorsa, her birisi ile teker teker entegrasyon yapması gerekiyor.
3DS Ödeme entegrasyonu gerçekleştirmiş olan bir E-Ticaret işyerinin ilgili kuruluşlarla olan etkileşimi en basit haliyle aşağıdaki gibi oluyor.
3DS Ödeme akışında, öncelikle 3DS doğrulaması gerçekleşiyor. Eğer ki 3DS doğrulaması başarıyla gerçekleşti ise, Ödeme Akışı(Otorizasyon) başlatılıyor. Bu işlemlerin başlatıldığı yere göre, farklı çalışma modelleri ve entegrasyonları, SanalPOS Hizmet Sağlayıcılar, Bankalar veya e-Para Kuruluşları tarafından sunuluyor. Dolayısıyla, E-Ticaret işyerlerinin entegrasyon yöntemleri de, seçilen çalışma modeline göre farklılaşabiliyor. Bu farklı çalışma modelleri aşağıdaki gibi 3 ana başlıkta toplanabiliyor.
Model (1) : Kart bilgilerinin işyeri web sitesinde girildiği, 3DS Doğrulaması ve Ödeme akışının işyeri tarafından başlatıldığı ve yönetildiği model,
Model (2) : Kart bilgilerinin işyeri web sitesinde girildiği, işlemin 3DS Doğrulaması ile işyeri tarafından başlatıldığı, 3DS Doğrulama sonucuna göre de, SanalPOS Hizmet Sağlayıcılar, Bankalar veya e-Para Kuruluşları tarafından Ödeme işleminin gerçekleştirilip, işlem sonucunun işyerine dönüldüğü model,
Model (3) : Ödeme işlemi için işyerinin, SanalPOS Hizmet Sağlayıcılar, Bankalar veya e-Para Kuruluşlarının Ortak Ödeme Sayfaları’na yönlendirdiği, Kart bilgilerinin bu sayfalarda girilerek, 3DS Doğrulama ve Ödeme işlemlerinin gerçekleştirildiği ve işlem sonucunun işyerine dönüldüğü model.
3DS 2.0 sistemi, mevcut 3DS Ödeme akışında nasıl konumlandırılmalı?
3DS Ödeme akışı incelendiğinde, bir E-Ticaret işyerinin doğrudan 3DS Bileşenleri ile etkileşimi olmuyor. SanalPOS Hizmet Sağlayıcılar, Bankalar veya e-Para Kuruluşlarının 3DS Gateway hizmeti üzerinden 3DS işlemi başlatılıyor. 3DS Gateway’in entegrasyon spesifikasyonları da, kendi standartlarına uygun olarak bu kuruluşlar tarafından hazırlanıyor.
Mevcut 3DS çalışma modellerinde, E-Ticaret işyerleri 3DS akışının detaylarından bağımsız olarak, 3DS Sistemi’ne 3DS Gateway’ler üzerinden entegre olup, 3DS işlemlerini gerçekleştirebiliyorlar. Dolayısıyla, 3DS 2.0 Sistemi’nin de, SanalPOS Hizmet Sağlayıcılar, Bankalar veya e-Para Kuruluşlarının 3DS Gateway hizmetine entegre edilmesi uygun bir çözüm olabilir. 3DS 1.0 ve 2.0'daki farklılıklar, 3DS Gateway’ler üzerinden yönetilip, mümkün olduğunca E-Ticaret işyerlerinin mevcut entegrasyon akışı üzerinden 3DS 2.0 işlemlerinin gerçekleştirilmesi için çözümlerin sağlanması da, 3DS 2.0'a hızlı ve sorunsuz bir geçişi mümkün kılabilir.
3DS 2.0 geçişinde, E-Ticaret işyerlerinin nasıl bir değişiklik yapmaları gerekebilir?
3DS 2.0'a geçiş yaparken, bir E-Ticaret işyerinin yapacağı değişiklikleri aşağıdaki faktörler etkileyebilir.
- İşyerinin kullandığı 3DS 1.0 Ödeme modeli,
- 3DS 1.0 entegrasyonunda kullandığı yöntem,
- 3DS 2.0 entegrasyonu için, SanalPOS Hizmet Sağlayıcılar, Bankalar veya e-Para Kuruluşlarının ortaya koyduğu çözüm,
3DS Ödeme modellerinden Model (1), diğer modellere göre biraz daha fazla değişiklik gerektirebilir. Çünkü bu modelde, 3DS Doğrulama ve Ödeme entegrasyonları ve bunların yönetimi işyerindedir. Eğer ki, SanalPOS Hizmet Sağlayıcılar, Bankalar veya e-Para Kuruluşlarının 3DS 2.0 entegrasyonu için ortaya koyduğu çözüm, yeni bir servis entegrasyonu gerektiriyorsa, bu durumdan en çok Model (1) etkilenir. Diğer taraftan, Model (1) için yapılan entegrasyonda kullanılan yöntem de, 3DS 2.0 geçişindeki yazılım değişikliğini etkileyebilecektir.
Tüm bunlara ek olarak, 3DS 2.0 bir işlemin gerçekleştirilebilmesi için, Visa/MasterCard gibi Kart Şemaları tarafından zorunlu tutulan bazı ek bilgilerin de sağlanması gerekebilir. 3DS 1.0'da bir işlem için gereken bazı bilgiler, Kart Numarası, Kart Son Kullanım Tarihi, İşlem Tutarı, Para Birimi, İşyeri Numarası ve İsmi gibi bilgilerdir. 3DS 2.0 ile birlikte, bazı ek bilgilerin de işyeri tarafından kullanıcılardan alınarak iletilmesi gerekebilir. Örneğin Visa, bir 3DS 2.0 işlem için, 3DS 1.0’daki bilgilere ek olarak, kart hamilinin İsmi, e-Mail Adresi ve Fatura Adresi gibi bilgilerin de gönderilmesini bekliyor. Dolayısıyla, işyerinin 3DS çalışma modeli veya entegrasyon yöntemi ne olursa olsun, bu bilgilerin kullanıcıdan alınması ve ek alanlarla 3DS Gateway’e gönderilmesine yönelik geliştirmelerin yapılması gerekebilir.
3DS 1.0'da, tek akış olan WEB akışı, 3DS 2.0'daki WEB akışı ile benzerlik göstermektedir. Dolayısıyla, işyerlerinin 3DS 1.0 için entegre olduğu servislere yeni alanların eklenmesi ile, 3DS 2.0 entegrasyon çözümü E-Ticaret işyerlerine sunulabilir. Yalnız, işyerinin 3DS entegrasyon yöntemine göre de, ek bazı geliştirmelerin işyeri tarafından yapılması da gerekebilir.
3DS entegrasyon yöntemleri nelerdir ve nasıl farklılaşıyor?
E-Ticaret işyerleri, 3DS Ödeme yöntemini kendi web sitelerinde sunmak isterlerse, birlikte çalıştıkları SanalPOS Hizmet Sağlayıcılar, Bankalar veya e-Para Kuruluşlarının SanalPOS entegrasyon spesifikasyonlarına uygun olacak şekilde geliştirmelerini yapıyorlar. Bu kuruluşlardan her birinin kendi standartları ve çözümleri olsa da, entegrasyon yöntemleri 3 ana gruba ayrılabiliyor.
Yöntem (1) : ACS’e yönlendirmenin 3DS Server(MPI)’dan gerçekleştirildiği yöntem,
Yöntem (2) : ACS’e yönlendirmenin 3DS Gateway’den gerçekleştirildiği yöntem,
Yöntem (3) : ACS’e yönlendirmenin İşyeri Web Sitesi’nden gerçekleştirildiği yöntem.
Bu entegrasyon yöntemlerini anlayabilmek için, öncelikle 3DS akışında ACS’e yönlendirme adımını hatırlamamız gerekiyor.
3DS 1.0 spesifikasyonlarında tariflenen standart bir 3DS akışında, MPI’ya yapılan 4 no’lu istek ile 3DS işlem akışı başlar. MPI’ın DS üzerinden ACS ile yapmış olduğu arka plandaki mesajlaşma sonucunda MPI, kart hamili doğrulamasının yapılabilmesi için, kullanıcıyı 9 no’lu adım ile ACS’e yönlendirir. Kullanıcı ACS’te doğrulandıktan sonra, bunun sonucu 10 no’lu adım ile yeniden MPI’ya yönlendirilerek iletilir.
Bu örnek akışta, kullanıcı en başta “www.merchant.com” adresinde bulunmaktadır. 3DS işlem akışı başlatıldığında işyeri, Redirection-Form-Post (HTTP 302) yöntemi ile kullanıcıyı, “www.3dsgateway.com” adresine, gerekli işlem bilgileri ile yönlendirir. Kullanıcı buradan da, 3DS işleminin başlatılabilmesi için, “www.mpi.com” a yönlendirilir. Doğrulama aşamasında da en son kullanıcı, “acs.bkm.com”a yönlendirilmiş olur. Dolayısıyla kullanıcı, 4 farklı domain’de gezmiş olur. Domain’ler arası bu gezinme iki sebepten dolayı pek tercih edilmez.
- Her bir domain adresine erişim, kullanıcının browser’ının internet üzerinden tekrardan bir istek yapması ile sağlanır. O sırada, internet erişiminde olan bir problem, bu işlem akışının yarıda kalmasına sebep olabilir. Bu durumda kullanıcı, 3DS işlem akışını işyeri sitesinden yeniden başlatması gerekir.
- Domain’ler arası gezinme kullanıcının browser’ı üzerinden olduğu için, ilgili mesajlaşmalar kaydedilebilir ve gerekli önlemler alınmazsa, kötü niyetli kullanıcıların “Replay Attack”lar ile sistemi kandırmasına sebep olabilir.
Bu sebeplerle, 3DS akışındaki yönlendirmelerin azaltılmasına yönelik entegrasyon yöntemleri işyerleri tarafından uygulanabilir. Ancak hiçbir yöntem, yönlendirme akışını tamamiyle ortadan kaldıramaz.
Yöntem (2), 3DS Gateway’den MPI’ya (4–11 no’lu adımlar); Yöntem (3) ise İşyeri Web Sitesi’nden 3DS Gateway’e (3–12 no’lu adımlar) olan yönlendirmeleri ortadan kaldırmaktadır. Yöntem (3) doğrultusunda bir entegrasyon yapan işyeri, doğrudan ACS bileşeni ile mesajlaşacağından (3DS 1.0'da PAReq/PARes akışı), 3DS protokolündeki standartlara uygun bir entegrasyonu da gerçekleştirmesi gerekir. Bu da, işyerini 3DS sistemindeki değişimlere doğrudan bağımlı hale getirir.
3DS 2.0 açısından değerlendirildiğinde, özellikle Yöntem (3) entegrasyonu olan işyerlerinin, 3DS 2.0'a uygun bir düzenlemeyi de kendi uygulamalarında yapmaları gerekir.
E-Ticaret işyerlerinin 3DS 2.0 entegrasyonu, mevcuttaki 3DS entegrasyon yöntemlerini nasıl etkileyecek?
ACS’e yönlendirmenin 3DS Server(MPI)’dan gerçekleştirildiği Yöntem (1)’de, işyerleri açısından akış 3DS 1.0'dan pek farklı olmayabilir. SanalPOS Hizmet Sağlayıcılar, Bankalar veya e-Para Kuruluşlarının 3DS Gateway ve SanalPOS uygulamalarında, işyerlerini etkilemeden, gerekli 3DS 2.0 entegrasyonunu hayata geçirebilirler. Bu entegrasyon yönteminde, işyerlerinden 3DS 2.0 akışında ihtiyaç duyulan ek bilgilerin (kart hamilinin İsmi, e-Mail Adresi ve Fatura Adresi gibi) alınması ve 3 no’lu adımda iletilmesi istenebilir.
ACS’e yönlendirmenin 3DS Gateway’den gerçekleştirildiği Yöntem (2)’deki durum da, Yöntem (1) ile aynıdır. İşyerleri açısından akış 3DS 1.0'dan pek farklı olmayabilir. SanalPOS Hizmet Sağlayıcılar, Bankalar veya e-Para Kuruluşlarının 3DS Gateway ve SanalPOS uygulamalarında, işyerlerini etkilemeden, gerekli 3DS 2.0 entegrasyonunu hayata geçirebilirler. Bu yöntemde kullanıcı, “www.mpi.com”a yönlendirilmez. 3DS Gateway ile 3DS Server(MPI) arasındaki iletişim arka planda gerçekleşir.
Yöntem (1) ve Yöntem (2)’deki 3DS işlem akışı, kullanıcının 3DS ile Ödeme’yi seçip onaylaması, 1 no’lu mesajın iletilmesi ile başlar. 3DS Gateway’den dönen 18 no’lu cevap ile işyeri bir sonraki adımı belirler.
- 3DS doğrulaması başarılı ise 20 no’lu istek ile SanalPOS otorizasyon akışı başlatılır.
- 3DS doğrulaması başarısız ise işlem akışı sonlandırılır, kullanıcıya 3DS doğrulamasının yapılamadığına yönelik hata mesajı gösterilir.
ACS’e yönlendirmenin İşyeri Web Sitesi’nden gerçekleştirildiği Yöntem (3)’te ise, işyerlerinin 3DS 2.0'a uygun olacak şekilde entegrasyonlarını gözden geçirmeleri ve gerekli yazılım değişikliklerini yapmaları gerekir. Yöntem (3)’ü kullanan işyerleri, 3DS 1.0'da PAReq mesajını içeren bir HTML Form’u bir javascript ile ACS’e otomatik yönlendirecek şekilde bir yapı kurmuşlardır. İlgili işyerlerinin, 3DS 2.0'da da CReq mesajını benzer şekilde ACS’e yönlendirecek şekilde bir akışı kurmaları gerekir. Buna ek olarak, 3DS 1.0'da kendilerine ACS tarafından yönlendirilen PARes mesajlarını çözümleyebilmek için, 3DS Gateway uygulamasının ilgili servisine yapmış oldukları çağrının benzerini 3DS 2.0'daki CRes mesajları için de yapmaları gerekir.
Bu yöntemde 3DS işlem akışı, kullanıcının 3DS ile Ödeme’yi seçip onaylaması, 1 no’lu mesajın iletilmesi ile başlar. 3DS Gateway’den dönen 9 no’lu cevap ile işyeri bir sonraki adımı belirler.
- Cevap, “Frictionless” ise bu aşamada 3DS akışı sonlandırılır ve 22 no’lu istek ile SanalPOS otorizasyon akışı başlatılır.
- Cevap, “Challenge” ise 10 no’lu istek ile CReq mesajının bulunduğu HTML Form, kullanıcının browser’ı aracılığıyla, ACS’e yönlendirilir. ACS, bu aşamada kullanıcıyı doğrular ve sonucunu 16 no’lu CRes mesajı ile işyeri web sitesine döner. CRes mesajı, ACS tarafından encode edilmiş bir mesajtır ve bu mesajın çözümlenmesi ve 3DS Server(MPI)’da işlem akışının tamamlanabilmesi için, işyeri web sitesi CRes mesajını 18 no’lu istek ile 3DS Server(MPI)’a iletir. 3DS Server(MPI) da, ilgili CRes mesajının çözümlenmiş halini, işyeri web sitesine 21 no’lu adımda geri döner. İşyeri web sitesi, eğer ki kullanıcı doğrulandıysa, 22 no’lu istek ile SanalPOS otorizasyon akışı başlatır.
- Cevap, “Not Authenticated” veya “Rejected” ise işlem akışı sonlandırılır, kullanıcıya 3DS doğrulamasının yapılamadığına yönelik hata mesajı gösterilir.
Bir E-Ticaret işyeri, 3DS 2.0'a geçtiği durumda, bütün 3DS işlemleri 3DS 2.0 mı gerçekleşmek zorundadır?
Bir E-Ticaret işyeri için 3DS 2.0 aktivasyonu yapıldığında, başlatılan bir 3DS işleminin 3DS 2.0 gerçekleşme zorunluluğu yoktur. Burada, Sanal POS Hizmet Sağlayıcılar, Bankalar veya e-Para Kuruluşlarının 3DS 2.0 için ortaya koyduğu çözüm ön plana çıkar. Önerilen çözüm, 3DS 1.0 ve 2.0 yönlendirmesinin, 3DS Gateway gibi merkezi sistemlerde yapılması, 3DS 2.0'daki hata durumlarının işyerine yansıtılmadan, ilgili işlemin 3DS 1.0 devam etmesinin sağlanmasıdır.
Bu doğrultuda, 3DS 2.0 aktivasyonu yapılmış olan bir işyerinde bir 3DS işlemi başlatıldığında;
- Öncelikle ilgili kartın 3DS 2.0'ı destekleyip desteklemediği 3DS Gateway uygulamasında kontrol edilmelidir. 3DS 2.0 akışında, 3DS 2.0’ı destekleyen kart numarası aralıklarının bilgisi (Preparation Messages), Visa/MasterCard DS’ler tarafından 3DS Server(MPI)’a iletilebilmektedir. Dolayısıyla, 3DS Gateway uygulaması, bu kontrolü 3DS Server(MPI)’lar üzerinden yapabilir. Eğer ki, ilgili kart 3DS 2.0'ı desteklemiyorsa, 3DS Gateway işlemi 3DS 1.0'a yönlendirebilir ve işlemin 3DS 1.0 tamamlanması sağlanabilir.
- İlgili kart 3DS 2.0'ı destekliyorsa, 3DS Gateway uygulaması 3DS 2.0 işlem akışını başlatır. Eğer ki ACS, Authentication cevap mesajında hata dönüyorsa, 3DS Gateway uygulaması işyerine geri dönmeden 3DS 1.0 işlem akışını otomatikman başlatabilir.
- İlgili kart 3DS 2.0'ı destekliyorsa, 3DS Gateway uygulamasından başlatılan 3DS 2.0 işlem için ACS, “Frictionless” veya “Challenge” cevaplarını dönüyorsa, işlem akışı gerektiği gibi devam edebilir.
Normalde, işyerine sunulacak olan çözüm, 3DS versiyonundan bağımsız olarak bir 3DS işleminin yapılabilmesidir. Ancak, bir işyeri 3DS ödeme akışında, girilen kartın 3DS 2.0 desteğinin olup olmadığını yönelik bir akış geliştirmek istiyorsa, SanalPOS Hizmet Sağlayıcılar, Bankalar veya e-Para Kuruluşlarının 3DS Gateway uygulamalarında buna özel bir servis sunulabilir.
3DS 2.0 ile birlikte gelen Mobil SDK çözümü için nasıl bir entegrasyonun yapılması gerekecek?
3DS 1.0 ve 2.0'daki gerek çalışma modelleri, gerekse de entegrasyon yöntemlerine yönelik vermiş olduğum bilgiler WEB akışlarına yönelik bilgilerdi. 3DS 2.0 ile birlikte, hayatımıza Mobil SDK çözümü de girmiş oldu. Bu çözüm ile birlikte, BKM olarak biz de, hem Android, hem de IOS platformları için bir SDK geliştirip, EMVCo sertifikasyonunu tamamladık.
Bir E-Ticaret işyerinin bir Mobil SDK’yı kendi Mobil uygulamasında kullanılabilmesi için şu ana kadar sunulan WEB entegrasyonlarından biraz daha farklı bir entegrasyonu gerçekleştirmesi gerekecek. Bunun için de, öncelikle SanalPOS Hizmet Sağlayıcılar, Bankalar veya e-Para Kuruluşlarının 3DS Gateway uygulamalarında, APP akışına uygun çözümleri sunmaları gerekecek.
Ortaya konulacak olan çözümler ile birlikte, 3DS Mobil SDK’da 3DS 2.0 işlem akışının aşağıdaki gibi olabileceğini düşünüyorum.
3DS 2.0 Mobil SDK’da işlem akışı, kullanıcının Mobil uygulamada 3DS ile Ödeme’yi seçip onaylaması ve Mobil uygulamanın 3DS 2.0 SDK’ya 1 no’lu çağrısı ile başlar. 3DS 2.0 SDK’dan dönülen parametrelerin, Mobil uygulamadan İşyeri Web Sitesi ve 3DS Gateway uygulamaları üzerinden 5 no’lu mesaj ile 3DS Server(MPI)’a iletilmesi ile 3DS 2.0 işlemi başlamış olur. 3DS Gateway’den dönen 11 no’lu cevap içerisindeki SDK’ya özel işlem sonuç bilgileri, 13 no’lu mesaj ile Mobil uygulama üzerinden 3DS 2.0 SDK’ya iletilir.
- Cevap, “Frictionless” ise bu aşamada 3DS akışı sonlandırılır ve 22 no’lu istek ile SanalPOS otorizasyon akışı başlatılır.
- Cevap, “Challenge” ise 3DS doğrulamasının başlayabilmesi için, 3DS 2.0 SDK, 14 no’lu isteği ACS’e iletir. 3DS doğrulama süreci tamamlandıktan sonra, Mobil uygulamaya doğrulama sonucu 20 no’lu mesaj ile dönülür. İşyeri web sitesi, eğer ki kullanıcı doğrulandıysa, 22 no’lu istek ile SanalPOS otorizasyon akışını başlatır. SanalPOS işleminde, 3DS doğrulaması sonucunda üretilen kriptogramın(CAVV/AAV) gönderilebilmesi için, 23 no’lu istek ile, ilgili işlemin kriptogramı 3DS Server(MPI)’dan sorgulanır ve otorizasyon mesajında gönderilir.
- Cevap, “Not Authenticated” veya “Rejected” ise işlem akışı sonlandırılır, kullanıcıya 3DS doğrulamasının yapılamadığına yönelik hata mesajı gösterilir.
Bu yazımda, 3D Secure 2.0 geçişinin E-Ticaret işyerleri ve SanalPOS Servis Sağlayacılarına olası etkilerini anlatmaya çalıştım. 3D Secure 2.0 ile ilgili daha fazla bilgi edinmek için diğer yazılarıma aşağıdaki linklerden erişebilirsiniz.
