3D Secure 2.2 ve Tokenizasyon Nedir?

İnternet üzerinden yapılan kartlı ödemelerde (Card-Not-Present / CNP) işletmelerin yıllardır çözmeye çalıştığı en büyük ikilem, maksimum güvenlik ile sürtünmesiz kullanıcı deneyimi (Zero-Friction UX) arasındaki hassas dengedir. Güvenlik duvarlarını çok sertleştirdiğinizde gerçek müşteriler SMS şifresi beklerken sepeti terk eder; güvenliği gevşettiğinizde ise çalıntı kart dolandırıcılığı ve ters ibraz (Chargeback) maliyetleri kontrolden çıkar. İşte küresel ödeme endüstrisi ve FinTech ekosistemi, bu ikilemi kökten çözmek için iki devrimsel standardı bir araya getirmiştir: EMV 3D Secure 2.2 (3DS2) protokolü ve Ağ Tokenizasyonu (Network Tokenization) mimarisi. Dijital ödemelerde güvenlik standartlarını yeniden tanımlayan bu iki teknoloji, hem PCI-DSS 4.0 uyumluluğunun temelini oluşturur hem de e-ticaret onay oranlarını (Authorization Rate) rekor seviyelere taşır.

On yılı aşkın süre kullanılan eski nesil 3D Secure 1.0 (3DS1) protokolü, masaüstü web tarayıcıları çağında tasarlanmıştı. Müşteriyi ödeme sırasında bankanın statik bir pop-up veya yönlendirme sayfasına gönderiyor, mobil ekranlarda bozuk görünüyor ve her işlemde istisnasız SMS OTP (Tek Kullanımlık Şifre) girmeyi zorunlu kılıyordu. SMS mesajlarının gecikmesi, operatör sorunları veya kullanıcının o an telefonuna erişememesi nedeniyle ödeme aşamasındaki sepet terk oranları %15 ila %25 seviyelerine ulaşıyordu. EMVCo (Visa, Mastercard, American Express, Discover, JCB ve UnionPay konsorsiyumu) tarafından geliştirilen EMV 3D Secure 2.1 ve 2.2 standartları ise bu hantal yapıyı tamamen terk ederek biyometrik doğrulama, mobil SDK entegrasyonu ve arka planda çalışan yapay zeka tabanlı risk analizini devreye sokmuştur.

EMV 3D Secure 2.2 (3DS 2.2) Nedir ve Nasıl Çalışır?

3D Secure (Three-Domain Secure), kartlı ödeme işlemini üç farklı etki alanı (Domain) arasında kriptografik olarak doğrulayan bir güvenlik protokolüdür: Üye İşyeri/Acquirer Alanı (Acquirer Domain), Kartı Basan Banka Alanı (Issuer Domain) ve bu ikisini birbirine bağlayan Şema/Birlikte Çalışabilirlik Alanı (Interoperability Domain - Directory Server). Sanal POS üzerinden başlatılan bir işlemde 3D Secure 2.2, eski sürümden farklı olarak kartı basan bankaya (Issuer ACS - Access Control Server) yalnızca kart numarasını ve tutarı değil, 100'den fazla bağlamsal veri noktasını (Contextual Data Elements) şifreli bir JSON paketi halinde gönderir.

Bu 100+ veri alanı içerisinde şunlar yer alır:

• Cihaz ve Tarayıcı Telemetrisi: Cihazın ekran çözünürlüğü, işletim sistemi sürümü, tarayıcı dili, saat dilimi, IP adresi, cihaz kimliği (Device ID) ve donanım parmak izi.
• İşlem ve Teslimat Bağlamı: Teslimat adresi ile fatura adresinin eşleşip eşleşmediği, kargo yöntemi (mağazadan teslim, adrese teslim, dijital kod), sepet içindeki ürünlerin risk kategorisi.
• Üye İşyeri Müşteri Geçmişi: Kullanıcının e-ticaret sitesindeki hesabını ne zaman açtığı, şifresini veya teslimat adresini son kaç gün içinde değiştirdiği, son 6 ayda bu kartla kaç başarılı sipariş tamamladığı.

EMV 3D Secure 2.2, ödemeyi doğrulamak için müşteriyi yormak yerine veriyi konuşturur: Arka planda iletilen 100'den fazla cihaz ve davranış parametresi sayesinde düşük riskli işlemlerin %80'ine yakını müşteriye hiçbir SMS şifresi sorulmadan milisaniyeler içinde "Sürtünmesiz Akış" (Frictionless Flow) ile onaylanır.

Sürtünmesiz Akış (Frictionless Flow) vs. Doğrulamalı Akış (Challenge Flow)

EMV 3DS 2.2 mimarisinde kartı basan bankanın risk motoru (ACS), üye işyerinin 3DS Sunucusundan (3DS Server) gelen bu zengin veri paketini milisaniyeler içinde değerlendirir ve işlemi iki farklı yoldan birine sokar:

1. Sürtünmesiz Akış (Frictionless Flow - Pasif Doğrulama): Eğer müşteri daha önce aynı cihazdan, aynı IP bloğundan ve aynı teslimat adresine düzenli alışveriş yapıyorsa, bankanın yapay zeka motoru işlemin gerçek kart sahibi tarafından yapıldığını arka planda doğrular. Müşterinin ekranına hiçbir SMS şifre ekranı çıkmaz; işlem 1-2 saniye içinde doğrudan onaylanır. En önemli nokta şudur: Sürtünmesiz akışla onaylanan bir işlemde de Sorumluluk Devri (Liability Shift) tam olarak geçerlidir; yani olası bir dolandırıcılık itirazında sorumluluk yine bankaya aittir.
2. Doğrulamalı Akış (Challenge Flow - Aktif Doğrulama): Eğer işlem yeni bir cihazdan yapılıyorsa, tutar kullanıcının normal harcama alışkanlığının çok üzerindeyse veya Avrupa PSD2 SCA (Strong Customer Authentication - Güçlü Müşteri Doğrulaması) regülasyonları gereği ek doğrulama zorunluysa banka "Challenge" (Meydan Okuma) başlatır. Ancak 3DS 2.2'de bu doğrulama sadece SMS şifresiyle sınırlı değildir; kullanıcının telefonundaki mobil bankacılık uygulaması üzerinden FaceID (Yüz Tanıma), TouchID (Parmak İzi) veya tek dokunuşla anlık bildirim (Push Notification) onayı ile saniyeler içinde tamamlanır.

3D Secure 2.1 ile 3D Secure 2.2 Arasındaki Kritik Farklar

3DS 2.1 sürümü temel zengin veri paylaşımını ve mobil SDK desteğini getirirken, 3D Secure 2.2 sürümü özellikle kurumsal e-ticaret ve dijital tahsilat sistemleri için hayati öneme sahip Muafiyet Yönetimi (Exemption Management) ve Ayrıştırılmış Doğrulama (Decoupled Authentication) yeteneklerini eklemiştir:

• TRA (Transaction Risk Analysis) ve Düşük Tutar Muafiyetleri: 3DS 2.2 ile üye işyeri veya ödeme kuruluşu, kendi dolandırıcılık oranının çok düşük olduğunu belirterek bankadan doğrudan "Sürtünmesiz Akış Muafiyeti" talep edebilir.
• MIT (Merchant Initiated Transactions - Üye İşyeri Kaynaklı İşlemler): Abonelik yenilemeleri, otomatik fatura ödemeleri veya sonradan tahsilat işlemlerinde ilk işlemde alınan 3DS doğrulama referans numarası (Scheme Transaction ID) bağlanarak, sonraki aylarda müşteri ekran başında olmasa dahi güvenli ve yüksek onay oranlı çekim yapılabilir.
• Decoupled Authentication (Ayrık Doğrulama): Müşterinin ödeme oturumu kapansa veya sesli yanıt sistemi / IoT cihazı üzerinden sipariş verilse bile, doğrulamanın asenkron olarak müşterinin mobil bankacılık uygulamasına gönderilip tamamlanmasına imkan tanır.
• Güvenilir Alıcı Listesi (Whitelisting / Trusted Beneficiaries): Kart sahibi, sürekli alışveriş yaptığı favori e-ticaret sitelerini veya B2B tedarikçilerini banka nezdinde "Güvenilir İşyeri" listesine ekleyerek sonraki tüm alışverişlerinde şifre adımını kalıcı olarak atlayabilir.

Tokenizasyon (Kart Saklama ve Şifreleme) Nedir?

FinTech dünyasında güvenliğin ikinci büyük sütunu Tokenizasyon (Tokenization) teknolojisidir. Tokenizasyon; üzerinde 16 haneli gerçek kart numarası (PAN - Primary Account Number), son kullanma tarihi ve CVV kodu bulunan hassas ödeme verisinin, matematiksel olarak geri döndürülemez, tekil ve rastgele üretilmiş alfa-nümerik bir referans dizisi (Token) ile değiştirilmesi işlemidir.

Şifreleme (Encryption) ile Tokenizasyon arasındaki fark çok kritiktir: Klasik şifrelemede (örneğin AES-256) orijinal veri bir matematiksel algoritma ve anahtar (Key) ile karıştırılır; eğer saldırganlar şifreleme anahtarını ele geçirirse tüm kart numaralarını geri çözebilirler. Tokenizasyonda ise token ile gerçek kart numarası arasında hiçbir matematiksel formül yoktur. Token yalnızca yüksek güvenlikli PCI-DSS Seviye 1 Donanım Güvenlik Modülü (HSM) kasasında tutulan bir indeks referansıdır; dolayısıyla bir e-ticaret sitesinin veri tabanı sızdırılsa dahi saldırganların eline geçen token'lar dış dünyada tamamen değersiz ve kullanılamaz karakter dizileridir.

Geçit Tokenizasyonu (Gateway Token) vs. Ağ Tokenizasyonu (Network Tokenization)

Dijital ödeme sistemleri gelişirken tokenizasyon teknolojisi de kendi içinde evrim geçirerek iki farklı mimariye ayrılmıştır: Birincisi ödeme kuruluşlarının kendi kasalarında ürettikleri Geçit/Kasa Tokenizasyonu (Gateway/Vault Tokenization), ikincisi ise doğrudan Visa (VTS - Visa Token Service) ve Mastercard (MDES - Mastercard Digital Enablement Service) tarafından üretilen Ağ Tokenizasyonu (Network Tokenization).

1. Gateway / Acquirer Tokenizasyonu Nasıl Çalışır?

Müşteri bir e-ticaret sitesinde "Kartımı sonraki alışverişler için kaydet" seçeneğini işaretlediğinde, ödeme kuruluşu gerçek kart numarasını (FPAN - Funding Primary Account Number) kendi PCI-DSS kasasına kaydeder ve üye işyerine tok_98a7b6c5d4 gibi bir referans kodu verir. Ancak işlem yapılacağı zaman ödeme kuruluşu kasadan gerçek kart numarasını (FPAN) çıkarır ve bankanın sanal POS'una yine bu gerçek kart numarasını gönderir. Eğer müşterinin kartının son kullanma tarihi dolarsa veya müşteri kartını kaybedip yenisini çıkarırsa, kasadaki gerçek kart numarası geçersiz hale gelir ve kayıtlı kart ödemesi başarısız olur.

2. Ağ Tokenizasyonu (Network Tokenization - VTS & MDES) Nasıl Çalışır?

Ağ tokenizasyonunda ise kart numarası doğrudan kart şemasına (Visa veya Mastercard) iletilir ve kartı basan bankanın (Issuer) onayıyla gerçek kart numarası (FPAN) yerine geçecek, yine 16 haneli ama sadece belirli bir üye işyeri (Merchant-Specific) veya belirli bir cihaz (Apple Pay / Google Pay gibi) için geçerli olan özel bir Ağ Token'ı (DPAN - Device/Digital Primary Account Number) üretilir.

Ağ tokenizasyonunun e-ticaret işletmeleri için finansal teknolojiler açısından sunduğu 4 benzersiz üstünlük vardır:

1. Otomatik Kart Yaşam Döngüsü Güncellemesi (Real-Time Account Updater): Müşterinin fiziksel kartının süresi dolduğunda, kart yenilendiğinde veya kayıp/çalıntı nedeniyle yeni kart basıldığında, banka arka planda yeni kartı mevcut Ağ Token'ına (DPAN) otomatik olarak bağlar. Üye işyerinin hiçbir şey yapmasına veya müşteriden yeni kart bilgisi istemesine gerek kalmaz; abonelik ve tek tıkla ödemeler kesintisiz devam eder.
2. Dinamik Kriptogram (Cryptogram) Güvenliği: Ağ token'ı ile yapılan her ödeme işleminde, o işleme özel tek kullanımlık bir kriptogram (TAVV / DSRP) üretilir. Bu sayede token çalınsa bile başka bir üye işyerinde veya başka bir kanalda kullanılması kriptografik olarak imkansızdır.
3. %3 ila %5 Daha Yüksek Onay Oranı: Kartı basan bankalar, işlemin kendi ürettikleri ve doğruladıkları bir Ağ Token'ı (DPAN) üzerinden geldiğini gördüklerinde işleme çok daha yüksek güven duyarlar ve "Genel Ret / Do Not Honor" oranları dramatik biçimde düşer.
4. Daha Düşük Şema Komisyonları: Visa ve Mastercard, güvenli ağ token'ı kullanan üye işyerlerini teşvik etmek amacıyla standart kart numarası (FPAN) işlemlerine kıyasla daha düşük takas/şema ücretleri uygular.

Karşılaştırma Tablosu: 3DS 1.0, 3DS 2.2 ve Tokenizasyon Mimarileri

Ödeme güvenliği ve kart saklama teknolojilerinin teknik kabiliyetlerini ve ticari etkilerini aşağıdaki karşılaştırma tablosunda net olarak görebilirsiniz:

Özellik / Kriter	Eski Nesil 3D Secure 1.0 + Klasik Kart Saklama	EMV 3D Secure 2.2 + Ağ Tokenizasyonu (Network Token)
Paylaşılan Veri Noktası	Sadece temel işlem verisi (~10-15 statik alan).	100'den fazla cihaz, davranış, geçmiş ve risk parametresi.
Kullanıcı Deneyimi (UX)	Her işlemde zorunlu SMS şifresi ve sayfa yönlendirmesi (Yüksek terk oranı).	Düşük riskte %80'e varan Sürtünmesiz Akış (Şifresiz onay) ve yerel mobil SDK.
Kimlik Doğrulama Yöntemi	Statik şifre veya SMS OTP (SIM Swap saldırılarına açık).	Biyometrik onay (FaceID, Parmak İzi), Mobil Push ve FIDO2/Passkey desteği.
Kart Yenilenmesi Durumu	Kart süresi dolduğunda veya yenilendiğinde kayıtlı kart ödemesi reddedilir.	Kart yenilense bile Ağ Token'ı arka planda otomatik güncellenir; tahsilat aksamaz.
Kriptografik Koruma	Kasada statik PAN tutulur; işlem anında açık kart numarası POS'a gider.	İşyeri bazlı kısıtlanmış DPAN ve her işleme özel dinamik kriptogram kullanılır.
Ortalama Onay Oranı Etkisi	Baz seviye (SMS zaman aşımları ve süresi dolan kartlar nedeniyle kayıp yaşanır).	Toplam ödeme dönüşüm ve onay oranlarında %4 ila %9 arasında net artış sağlar.

PCI-DSS 4.0 Uyumluluğu ve Ön Yüz (Client-Side) Güvenliği

Ödeme Kartları Endüstrisi Güvenlik Standartları Konseyi (PCI SSC) tarafından yürürlüğe alınan PCI-DSS 4.0 standardı, e-ticaret sitelerinin ve ödeme mutabakatı / tahsilat platformlarının güvenlik yükümlülüklerini önemli ölçüde sıkılaştırmıştır. Özellikle Gereksinim 6.4.3 ve 11.6.1 kapsamında, ödeme sayfalarında çalışan üçüncü taraf JavaScript kodlarının (Magecart / Formjacking / E-Skimming saldırıları) izlenmesi ve kart verisinin üye işyeri sunucularından tamamen izole edilmesi zorunlu hale gelmiştir.

EMV 3D Secure 2.2 ve Tokenizasyon altyapısını barındıran modern ödeme geçitleri (Hosted Fields / Tokenization iFrame / Native SDK), müşterinin girdiği kart numarasını daha tarayıcı seviyesindeyken yakalar ve doğrudan PCI-DSS Seviye 1 kasasında token'a dönüştürür. Böylece üye işyerinin kendi sunucularına hiçbir zaman ham kart verisi (Raw PAN) uğramaz. Bu mimari, işletmenin PCI-DSS denetim kapsamını en ağır seviye olan SAQ-D'den en hafif öz değerlendirme seviyesi olan SAQ-A'ya düşürerek hem siber güvenlik riskini hem de yıllık denetim maliyetlerini minimize eder.

Teknik Mimari: 3DS Server, Directory Server (DS) ve ACS İletişim Akışı

Yazılım mimarları ve ödeme sistemleri yöneticileri için EMV 3D Secure 2.2'nin kaputunun altında gerçekleşen mesajlaşma protokolünü anlamak, olası entegrasyon darboğazlarını çözmek açısından kritik önem taşır. 3DS 2.2 akışı dört temel teknik bileşen ve kriptografik mesaj çifti (AReq/ARes ve CReq/CRes) üzerinden yürütülür:

1. 3DS Method (Cihaz Parmak İzi Toplama): Müşteri ödeme sayfasında kart numarasının ilk 6-8 hanesini (BIN) girdiğinde, üye işyerinin 3DS Sunucusu (3DS Server) kartı basan bankanın ACS sunucusuna ait gizli bir iFrame (3DS Method URL) çalıştırır. Bu adım, müşteriye hiçbir şey hissettirmeden tarayıcı ve cihaz telemetrisini doğrudan bankaya ileterek Sürtünmesiz Akış (Frictionless) şansını iki katına çıkarır.
2. AReq ve ARes (Authentication Request / Response): Müşteri "Öde" butonuna bastığında 3DS Server, 100'den fazla veri noktasını içeren AReq (Doğrulama İsteği) mesajını kart şemasının (Visa, Mastercard veya BKM/Troy) Directory Server (DS - Dizin Sunucusu) katmanına gönderir. Directory Server bu mesajı kartı basan bankanın ACS (Access Control Server) sistemine iletir. Banka riski düşük bulursa ARes (Doğrulama Yanıtı) içinde TransStatus = Y (Başarılı / Sürtünmesiz Onay) ve kriptografik kanıt olan CAVV / AAV değerini döndürür.
3. CReq ve CRes (Challenge Request / Response): Eğer banka ek doğrulama isterse ARes mesajında TransStatus = C (Challenge Gerekli) döner. Bu durumda tarayıcı veya mobil uygulama içerisindeki 3DS SDK doğrudan bankanın ACS sunucusuyla CReq / CRes mesajlaşması başlatarak biyometrik onay veya SMS OTP ekranını açar.
4. RReq ve RRes (Results Request / Response): Challenge tamamlandığında ACS, sonucu Directory Server üzerinden üye işyerinin 3DS Sunucusuna bildirir ve oluşan ECI (Electronic Commerce Indicator) ile CAVV değeri sanal POS otorizasyon (provizyon) mesajına eklenerek bankadan para çekimi tamamlanır.

Kayıtlı Kart Ödemelerinde CIT ve MIT (Sözleşmeli İşlem) Çerçevesi

Tokenizasyon ve 3D Secure 2.2 birlikte kullanıldığında, kart şemaları kayıtlı kart işlemlerini iki ayrı regülatif sınıfa ayırır: CIT (Cardholder Initiated Transaction - Kart Hamili Kaynaklı İşlem) ve MIT (Merchant Initiated Transaction - Üye İşyeri Kaynaklı İşlem). İlk kart kaydetme anında müşteri ekran başındadır ve işlem mutlaka 3D Secure 2.2 ile doğrulanarak bir CIT işlemi olarak kaydedilir. Bu ilk başarılı işlemde kart şeması (Visa/Mastercard) üye işyerine benzersiz bir Scheme Transaction ID (Şema İşlem Kimliği) verir.

Sonraki aylarda yapılacak abonelik tahsilatlarında, SaaS yenilemelerinde veya otomatik fatura ödemelerinde müşteri ekran başında değildir; işlem üye işyerinin sunucusu tarafından otomatik başlatılır (MIT). İşte bu MIT işlemlerinde, Ağ Token'ı (DPAN) ile birlikte ilk CIT işleminden alınan Scheme Transaction ID referansı bankaya gönderildiğinde, banka bu çekimin daha önce 3D Secure ile müşteri tarafından yetkilendirilmiş bir sözleşmenin devamı olduğunu anlar ve işlemi 3D Secure sormadan en yüksek onay oranıyla gerçekleştirir.

Sıkça Sorulan Sorular (SSS)

3D Secure 2.2'de şifre sormadan (Sürtünmesiz Akış) geçen işlemlerde dolandırıcılık olursa kim sorumludur?

Sürtünmesiz Akış (Frictionless Flow) kararı üye işyeri tarafından değil, bizzat kartı basan bankanın (Issuer) risk motoru tarafından 100+ veri parametresi incelenerek verilir ve işleme tam doğrulama kanıtı (ECI 05 / ECI 02 ve CAVV) üretilir. Dolayısıyla şifre sorulmadan sürtünmesiz akışla onaylanan işlemlerde de Sorumluluk Devri (Liability Shift) tam olarak geçerlidir; yetkisiz işlem (Fraud) itirazlarında finansal sorumluluk kartı basan bankaya aittir.

Ağ Tokenizasyonu (Network Tokenization) yalnızca Apple Pay ve Google Pay için mi geçerlidir?

Hayır. Ağ tokenizasyonu ilk olarak Apple Pay ve Google Pay gibi dijital cüzdanlarda (NFC/EMV Token) yaygınlaşmış olsa da, bugün e-ticaret sitelerindeki standart Kayıtlı Kart (Card-on-File / CoF) ve abonelik ödemelerinin tamamında kullanılmaktadır. Müşteri kartını herhangi bir e-ticaret sitesine veya ödeme kuruluşuna kaydettiğinde arka planda Visa (VTS) ve Mastercard (MDES) ağ token'ı üretilebilir.

Kayıtlı kart (Token) ile yapılan ödemelerde CVV kodu saklanabilir mi?

Hayır. PCI-DSS kuralları gereği kartın arkasındaki 3 haneli güvenlik kodunun (CVV2 / CVC2 / CID) işlem tamamlandıktan sonra herhangi bir veri tabanında şifreli dahi olsa saklanması kesinlikle yasaktır. Tokenizasyon sistemlerinde ilk kayıt anında CVV doğrulanır ve silinir; sonraki işlemlerde ise CVV yerine Ağ Token kriptogramı veya ilk işlemin 3DS referans kimliği (CIT/MIT protokolü) kullanılarak güvenli provizyon alınır.

Türkiye'deki bankalar ve Troy kart şeması 3D Secure 2.2 standardını destekliyor mu?

Evet. Bankalararası Kart Merkezi (BKM) koordinasyonunda Türkiye'deki tüm bankalar, ödeme kuruluşları ve ulusal kart şemamız Troy, EMV 3D Secure 2.x (GO - Güvenli Ödeme) altyapısına geçişini tamamlamıştır. Güncel sanal POS entegrasyonları üzerinden 3DS 2.2 veri parametreleri desteklenmektedir.

Mevcut sanal POS entegrasyonumuzu 3D Secure 2.2'ye geçirmek için ne yapmalıyız?

Çalıştığınız ödeme kuruluşunun veya banka sanal POS'unun güncel API dokümantasyonunda yer alan 3DS 2.2 ek veri alanlarını (tarayıcı bilgileri, cihaz ekran boyutları, müşteri hesap yaşı, teslimat/fatura adresi eşleşme bilgileri) ödeme isteği (Request) paketine eklemeniz ve ön yüzde 3DS Method URL (gizli cihaz parmak izi toplama iFrame'i) adımını çalıştırmanız yeterlidir.