Online tahsilatta güvenlik tek bir özellik değil, üç ayrı soruya verilen üç ayrı cevaptır. Kartı kullanan kişi gerçekten kart hamili mi? Kart numarası hangi sistemde duruyor ve ele geçirilirse ne işe yarar? Kimliği doğrulanmış bir işlem ticari olarak da kabul edilmeli mi? Birinci soruyu 3D Secure 2.0, ikincisini tokenization, üçüncüsünü fraud kontrolü çözer. Üçü birbirinin yedeği değildir; biri eksik kaldığında kalan ikisi o boşluğu kapatmaz.

Bu ayrımın pratikteki karşılığı, iş ters gittiğinde maliyetin kimde kaldığıdır. Katmanları özelliğin adıyla değil üstlendikleri riskle okumak, hem entegrasyon kararını hem de bir itiraz geldiğinde ne beklenebileceğini netleştirir.

3D Secure 2.0 kimliği doğrular, işlemin ticari doğruluğunu değil

3D Secure 2.0, ödeme talebi işleme alınmadan önce kart hamilinin kartı çıkaran bankaya doğrulatılmasını sağlar. Doğrulama isteğiyle birlikte cihaz ve tarayıcı bilgisi, fatura ile teslimat verisi ve sepetin özellikleri bankaya taşınır. Banka bu sinyalleri yeterli bulursa işlemi ek bir adım istemeden onaylar, şüphe duyarsa tek kullanımlık kod, bankacılık uygulaması üzerinden onay veya biyometrik doğrulama ister.

Sürümün önceki nesle göre farkı burada belli olur. Doğrulama artık yalnızca tarayıcıda açılan bir pencereye bağlı değildir, mobil uygulama içi akışları da kapsar ve karar daha geniş bir veri setine dayanır. Sonuç olarak doğrulama her müşteriye ek bir engel gibi yansımak zorunda kalmaz.

Riskin yeri de bu katmanda değişir. Doğrulaması başarıyla tamamlanmış bir işlemde, kart hamilinin işlemi kendisinin yapmadığı yönündeki itirazından doğan sorumluluk kural olarak kartı çıkaran bankaya geçer. Doğrulama hiç yapılmadıysa veya tamamlanamadıysa aynı itirazın maliyeti üye işyerinde kalır. Bu bir garanti değil, kart kurallarından gelen bir sorumluluk dağılımıdır ve her itiraz türü için işlemez.

Kapsamadığı alan da net. Ürünün teslim edilmemesi, açıklamaya uymaması veya iadenin yapılmaması gibi uyuşmazlıklar kimlikle ilgili değildir; bunlarda sorumluluk işletmede kalmayı sürdürür. Kimlik doğrulaması bir ödeme güvencesi değil, tek bir sorunun cevabıdır.

Kart numarası nerede duruyor ve tokenization neyi değiştirir

Tokenization, kart numarasının işletmenin tarafında hiç bulunmaması esasına dayanır. Müşteri kart bilgisini girdiğinde bu veri doğrudan PCI-DSS kapsamındaki ödeme altyapısına gider. İşletmenin sunucusuna, veritabanına, log kayıtlarına ve sipariş ekranına düşen şey kart numarası değil, o kayda işaret eden bir referanstır.

Bu referans kendi bağlamı dışında işe yaramaz. Sipariş veritabanı ele geçirilse bile elde edilen kayıt başka bir sitede ödeme aracına dönüşmez, çünkü karşılığı yalnızca ilgili altyapıda ve yalnızca o üye işyeri için tanımlıdır. Aynı yapı, tekrar eden tahsilatlarda kart numarasını saklamadan yeniden çekim yapılmasını da mümkün kılar.

Bu nedenle güvenli online tahsilat kurgusunun ilk adımı kart verisini kendi tarafında tutmamaktır: işletmenin sisteminde hiç bulunmayan bir kart numarası o sistemden sızdırılamaz. Verinin aktarımı TLS 1.3 ve 256-bit SSL ile, saklanması 256-bit AES ile korunur; altyapı Tier III+ veri merkezlerinde çalışır ve 7/24 SOC izlemesi altındadır.

Risk şöyle yer değiştirir: kart verisini saklama yükümlülüğü ve buna bağlı denetim maliyeti işletmeden altyapı tarafına geçer. Ancak işletmenin kapsamı daralır, sıfırlanmaz. Ödeme formunun sayfaya nasıl yüklendiği, panele kimin eriştiği ve entegrasyon anahtarlarının nasıl korunduğu işletmenin sorumluluğunda kalır.

Burada karıştırılmaması gereken bir ayrım var. Kart verisinin altyapı tarafında tutulması, paranın da orada beklediği anlamına gelmez. Lirbon Teknoloji ve Elektronik Ticaret A.Ş. markası olan Tahsilat.com bir ödeme kuruluşu ya da elektronik para kuruluşu değildir; verdiği hizmet teknik ödeme altyapısının sağlanmasıdır ve tahsil edilen tutar işlemin hiçbir aşamasında bu altyapıda durmaz, üye işyeri adına tanımlanan sanal POS üzerinden doğrudan işletmenin kendi banka hesabına geçer. Güvenlik tartışması bu yüzden bakiyenin kimde durduğu üzerinden değil, kart verisinin nerede saklandığı ve kimliğin nasıl doğrulandığı üzerinden yürür.

Kimliği doğrulanmış her işlem kabul edilmesi gereken işlem değildir

Fraud kontrolü işlemin teknik geçerliliğini değil ticari mantığını sorgular. Kart doğru, doğrulama tamam ve limit yeterli olabilir; buna rağmen sipariş kalıbı olağan davranışa uymayabilir. Bu katman, ödeme akışı tamamlanmadan önce cihaz parmak izi, kart deneme sıklığı, adres ile sipariş arasındaki tutarsızlıklar ve geçmiş davranış gibi sinyalleri bir risk skoruna dönüştürür.

Tahsilat.com bu katmanı SmartCheck ile kurar ve modül için %99.9 doğruluk oranı bildirir. Sayının nasıl okunacağı önemlidir: skorlama iki farklı hata üretebilir, sahte bir işlemi kaçırmak ve gerçek bir müşteriyi reddetmek. Eşiği sıkılaştırmak birincisini azaltırken ikincisini artırır. Bu yüzden kural seti sektöre, ortalama sepet tutarına ve iade politikasına göre ayarlanır, sabit bir ayar herkes için doğru sonuç vermez.

Riskin yeri bu katmanda değişmez. 3D Secure doğrulaması sorumluluğu kartı çıkaran bankaya taşıyabilir, risk skorlaması taşımaz. Kabul edilen sahte işlemin de reddedilen gerçek müşterinin de maliyeti işletmede kalır. Fraud kontrolü bir sorumluluk devri değil, karar destek katmanıdır.

Üç katman aynı anda değil, işlemin üç ayrı anında çalışır

Katmanların birbirini tamamlama biçimi zaman ekseninde daha net görülür. Risk skorlaması işlem oluşurken sinyal toplar. 3D Secure doğrulaması ödeme anında kart hamilini bankasına onaylatır. Tokenization ise işlem bittikten sonra da çalışmayı sürdürür, çünkü kart verisinin ömrü tek bir ödemeden uzundur ve tekrar eden tahsilat, iade ve iptal aynı referans üzerinden yürür.

Bir katman eksik kaldığında diğerleri o boşluğu kapatmaz. Doğrulaması yapılmayan bir işlem yüksek risk skoruyla durdurulabilir, ama skorlama kart verisinin nerede saklandığını değiştirmez. Tokenization sızıntı riskini işletmenin dışına taşır, kartı çalınmış birinin işlem denemesini engellemez. Ödeme linki, QR kod veya uygulama içi akış gibi farklı yüzeylerde de bu üç soru aynı kalır; değişen yalnızca müşterinin ödeme ekranına nereden geldiğidir.

Sertifikalar neyi kanıtlar, neyi kanıtlamaz

Güvenlik başlığı altında sıralanan belgeler aynı şeyi söylemez, bu yüzden hepsini tek bir güven listesi gibi okumak yanıltıcı olur. Her biri farklı bir soruyu yanıtlar.

• PCI-DSS Level 1, kart verisi işleyen hizmet sağlayıcılar için en yüksek işlem hacmi kademesidir ve kendi beyanla değil bağımsız bir QSA denetimiyle doğrulanır. Tahsilat.com altyapısı PCI DSS v4.0.1 Service Provider kapsamında bu kademede denetlenir.

• ISO 27001:2013, bilgi güvenliği yönetim sisteminin kurulduğunu ve işletildiğini gösterir. Tek tek teknik önlemlerin listesi değil, süreçlerin yönetildiğinin belgesidir.

• SOC 2 Type II, kontrollerin belirli bir zaman aralığı boyunca fiilen çalıştığını bağımsız denetimle ortaya koyar. Tek bir andaki tasarımı değerlendiren rapordan farkı budur.

• KVKK ve GDPR uyumu, kişisel verinin hangi hukuki temelle işlendiğine ve veri sahibinin haklarına ilişkin yükümlülük çerçevesidir. Altyapının uyumu, işletmenin kendi veri işleme süreçlerindeki yükümlülüğünü ortadan kaldırmaz.

Ortak sınır şudur: bir sertifika, denetim kapsamındaki sistemlerin belirli koşulları karşıladığını gösterir. Hiçbiri işlem bazında bir sonuç taahhüdü değildir ve işletmenin kendi tarafındaki yapılandırma hatalarını kapsamaz. Sertifikaya bakarken sorulacak doğru soru, belgenin var olup olmadığı kadar kapsamının nereye kadar uzandığıdır.

Altyapı devraldıktan sonra işletmede kalan işler

Üç katman da kurulmuş olsa bile zincirin işletme tarafındaki halkaları açık kalabilir. Uygulamada en sık atlanan noktalar şunlardır.

• Ödeme formundaki kart alanları işletmenin kendi sunucusuna hiç uğramamalı, doğrudan ödeme altyapısına bağlanmalıdır.

• Panel ve API erişimleri kişi bazlı verilir; görev değişikliğinde ve işten ayrılmalarda kapatılır.

• API anahtarları kod deposunda, paylaşılan dosyalarda veya mesajlaşma uygulamalarında tutulmaz.

• Ödeme onayı, müşterinin yönlendirildiği başarı sayfasına değil, sunucuya ulaşan ve doğrulanan webhook bildirimine bağlanır. Tarayıcı tarafındaki yönlendirme tek başına kanıt sayılmaz.

• Sipariş, kısmi iade ve iptal akışları canlıya çıkmadan sandbox ortamında denenir.

• İade ve iptal koşulları açık yazılır. Kimlik doğrulaması bu tür itirazları kapsamadığı için uyuşmazlık maliyetini asıl azaltan şey net bir politikadır.

Sık sorulan sorular

3D Secure 2.0 her işlemde tek kullanımlık kod ister mi?

Hayır. Doğrulama kararını kartı çıkaran banka verir. Gelen sinyaller yeterli görülürse işlem ek bir adım olmadan onaylanabilir; şüphe varsa kod, bankacılık uygulamasında onay veya biyometrik doğrulama istenir. Bu karar üye işyerinin tercihine bırakılmaz.

Kart numarası bizde durmuyorsa iade nasıl yapılır?

İade kart numarası üzerinden değil, işlemin kendi kaydı üzerinden yürür. Panelden ilgili işlem seçilir, tam veya kısmi iade aynı referansa bağlanır. Müşteriden kart bilgisini yeniden istemek gerekmez ve istenmemelidir.

Altyapı PCI-DSS kapsamındaysa işletmenin ayrıca yapması gereken bir şey kalır mı?

Kapsam daralır, sorumluluk sıfırlanmaz. Kart alanlarının sayfaya nasıl yüklendiği, kimin hangi yetkiyle panele eriştiği, anahtarların nasıl saklandığı ve sipariş verisinin nasıl tutulduğu işletmenin tarafındadır.