Küresel ticaret ağları dijitalleştikçe, B2B tahsilat operasyonları benzeri görülmemiş bir hıza ulaşıyor. Ancak bu olağanüstü hız, şirketleri devasa siber güvenlik tehditleri ve karmaşık yasal regülasyonlarla karşı karşıya bırakıyor. Günümüzde teknoloji ekipleri, milyonlarca liralık nakit akışını yöneten bir B2B tahsilat yazılımı inşa ederken sadece performanslı kod yazmakla yetinemez; aynı zamanda global veri standartları ile yerel kanunlar arasında kusursuz bir köprü kurmak zorundadır. Peki, yüksek hacimli B2B ödeme altyapılarını hukuki risklerden arındırırken teknik mimariyi tam olarak nasıl kurgulamalısınız?

B2B tahsilat yazılımları, bir 'Hizmet Sağlayıcı' (Service Provider) olarak yıllık 300.000 işlem eşiğini aştığında, Visa ve Mastercard risk kriterleri uyarınca PCI DSS Level 1 sertifikasyonuna ve QSA yerinde denetimine tabi olur. Bu uyumluluk, v4.0 standartlarında çok faktörlü kimlik doğrulama (MFA) sistemlerini ve KVKK kapsamında açık rıza yönetimini şart koşarken; kart verilerinin tokenizasyon teknolojisiyle sistemden yalıtılmasını zorunlu kılar.

Kullanıcının Asıl Problemi

İşletmeler, geçmişin manuel ve kağıt tabanlı açık hesap süreçlerini terk ederek ERP entegrasyonlu dijital tahsilat platformlarına geçiş yapıyor. Fakat bu dönüşüm, teknoloji firmalarını hem küresel regülasyonları hem de yerel kanunları aynı anda karşılayan bir mimari inşa etme zorluğuyla yüzleştiriyor. Online tahsilat yazılımı üreten şirketler, altyapılarını tasarlarken güvenlikten ödün vermeden operasyonel hızı korumak zorundadır.

B2B Tahsilat Ekosisteminde PCI DSS Uyumluluk Çerçevesi

PCI DSS, kartlı ödeme sistemlerinin güvenliğini sağlamak amacıyla kurulan PCI Güvenlik Standartları Konseyi (PCI SSC) tarafından denetlenir. B2B tahsilat yazılımları geliştiren firmalar için bu standart, sadece teknik bir kontrol listesi değil, aynı zamanda bankalarla entegre çalışabilmenin anahtarıdır.

İşletme Sınıflandırması: Merchant vs. Service Provider

Yazılım ekiplerinin uyumluluk yol haritasını belirlerken yaptıkları en temel ayrım, işletmenin ekosistemdeki rolüdür. Geleneksel e-ticarette satıcı "Merchant", altyapıyı sağlayan kuruluş ise "Service Provider" statüsündedir. Bununla birlikte, B2B dünyasında bu sınırlar sıklıkla bulanıklaşır.

• Merchant (Üye İşyeri): Kendi mal veya hizmetleri karşılığında ödeme kabul eden işletmeleri tanımlar. Örneğin, ana dağıtıcı bir firma sadece kendi bayilerinden tahsilat yapıyorsa bu kategoriye girer.

• Service Provider (Hizmet Sağlayıcı): Başka bir işletmenin ödeme işlemlerini işleyen, saklayan veya ileten kuruluşları ifade eder. Dahası, eğer bir teknoloji firması geliştirdiği B2B tahsilat portalını birden fazla kuruma SaaS (Software as a Service) modeliyle sunuyorsa, PCI Konseyi bu firmayı doğrudan Hizmet Sağlayıcı kabul eder.

İşlem Hacmi Eşikleri ve Level 1 Zorunluluğu

PCI DSS uyumluluk seviyeleri, sistem üzerinden geçen yıllık işlem hacmine göre değişir. Visa ve Mastercard gibi endüstri otoriteleri, bu eşikleri belirlerken risk odaklı bir yaklaşım izler.

Analiz: Tabloda açıkça görüldüğü üzere Hizmet Sağlayıcılar için belirlenen 300.000 işlem eşiği, B2B SaaS platformları için aşılması çok kolay bir bariyerdir. Nitekim günde ortalama sadece 822 işlem yapan bir platform, doğrudan en yüksek risk grubuna (Level 1) girer. Başlangıçta bu gerçeği göz ardı eden girişimler, büyüme evresinde hazırlıksız yakalanarak devasa bir teknik borç yaratır. Bu nedenle yazılım mimarları, sistemi ilk günden itibaren Level 1 standartlarına uygun inşa etmelidir.

PCI DSS v4.0 Teknik Derinlik ve B2B Yazılımlarına Etkisi

PCI SSC'nin yayınladığı v4.0 sürümü, standardın statik yapısını "Sürekli Güvenlik" modeline dönüştürüyor. Bu yeni yapı, teknoloji ekiplerine mimari esneklik sunarken denetim yükümlülüklerini artırıyor.

1. Ağ Güvenlik Kontrolleri (NSC) ve Mikro-Segmentasyon

Eski nesil güvenlik duvarı (firewall) kavramı, v4.0 ile yerini daha kapsamlı "Ağ Güvenlik Kontrolleri" (NSC) tanımına bırakıyor. Özellikle bulut tabanlı B2B yazılımları, sadece dış çevre güvenliğini değil, iç ağdaki konteynerler (Docker/Kubernetes) arasındaki trafiği de denetlemek zorundadır. Buna karşın mikro-segmentasyon stratejisi, sunucuları kesin sınırlarla ayırır. Sistem yöneticileri internete açık DMZ (Demilitarized Zone) katmanında sadece HTTPS (443) portunu açık tutar. Veritabanı sunucuları ise internet erişimini tamamen kapatarak sadece uygulama sunucularından gelen istekleri kabul eder.

2. Çok Faktörlü Kimlik Doğrulama (MFA) ve Zero Trust

Güvenlik ekipleri, v4.0 ile birlikte erişim güvenliğinde radikal değişiklikler uyguluyor. Geçmişte sadece uzaktan erişim için zorunlu olan MFA, günümüzde Kart Sahibi Veri Ortamına (CDE) dokunan her kullanıcı için şart koşuluyor. ABD Ulusal Standartlar ve Teknoloji Enstitüsü (NIST) prensiplerine dayanan "Sıfır Güven" (Zero Trust) yaklaşımı, sistemin iç ağdaki hiçbir kullanıcıya veya cihaza peşinen güvenmemesini emreder (Akademik). Sonuç olarak şirketler, FIDO2 gibi kimlik avına (phishing) dirençli donanım anahtarlarını sistemlerine entegre ediyor.

3. Web Skimming Koruması (Yazılım Yaşam Döngüsü)

Yeni standardın en çarpıcı gerekliliklerinden biri (Req 6.4.3), ödeme sayfalarında çalışan JavaScript kodlarını hedef alıyor. Magecart gibi saldırı grupları, üçüncü taraf analitik veya sohbet eklentilerini manipüle ederek kart verilerini çalıyor. Dolayısıyla B2B yazılımı, ödeme sayfasındaki tüm scriptlerin envanterini tutmak ve yetkisiz değişiklikleri anında tespit ederek alarm üretmek zorundadır.

KVKK Uyumu ve Veri Egemenliği Kesişimi

Türkiye sınırları içerisinde faaliyet gösteren tahsilat yazılımları, PCI DSS'in teknik kurallarını 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) ile harmanlamak zorundadır.

PCI DSS doğrudan kart numarasına (PAN) odaklanır. KVKK ise, kartın üzerindeki isim veya IP adresi gibi kimliği belirli kılan her veriyi "Kişisel Veri" (PII) kabul eder. Çakışma tam da bu noktada başlar. PCI DSS standardı kart sahibinin adını tek başına şifrelemeyi zorunlu kılmaz. Öte yandan KVKK, veri güvenliği rehberi uyarınca "uygun güvenlik düzeyinin temin edilmesini" kesin bir dille emreder. Bu bağlamda, uyumluluk ekipleri her iki standardın en katı kuralını baz alarak tüm veritabanını (Transparent Data Encryption) şifreler.

Ayrıca B2B süreçlerinde vazgeçilmez olan "Kart Saklama" özelliği yasal bir engele takılır. KVKK mevzuatı, yazılım firmasının kart saklama işlemi için kullanıcıdan açık ve özgür iradeye dayalı "Açık Rıza" almasını şart koşar. Üstelik tasarımcılar, "Kartımı sakla" kutucuğunu önceden işaretlenmiş (pre-ticked) olarak sunamaz.

Descoping (Kapsam Daraltma) ve Tokenizasyon

Geliştirici ekipler, güvenlik risklerini ve denetim maliyetlerini düşürmek için "Descoping" stratejisini merkeze alır. En güvenli veri, hiç sahip olmadığınız veridir.

Hosted Fields (iFrame) ve Token Mimarisi

B2B yazılımı ödeme sayfasını oluşturur; ancak kullanıcı kredi kartı numarasını girdiği anda veri, yazılımın kendi sunucularına uğramaz. Sistem, bu alanları doğrudan lisanslı bir Ödeme Hizmet Sağlayıcısının (PSP) sunucularından iFrame aracılığıyla çeker. Sonucunda PSP, kart verisini güvenle işler ve B2B yazılımına rastgele üretilmiş, anlamsız bir "Token" (Jeton) gönderir. Yazılım sadece bu jetonu veritabanında saklar. Bilgisayar korsanları sistemi ele geçirse bile, elde ettikleri jetonları matematiksel olarak kart numarasına geri çeviremezler. Bu strateji, firmanın PCI DSS denetim kapsamını devasa oranda küçültür.

ERP Entegrasyonu ve "Atomic Settlement" Prensibi

B2B tahsilatının nihai amacı faturanın ERP (Netsis, SAP, Logo vb.) sisteminde anında muhasebeleşmesidir. Ödemenin karttan çekilmesi ile faturanın ERP'de kapanması eşzamanlı gerçekleşmelidir. Geliştiriciler bu bütünlüğü "Atomic Settlement" (Bütünleşik İşlem) yapısıyla kurar. Eğer ağda bir kesinti yaşanırsa, sistem işlemi tamamen geri alır (Rollback). Ayrıca ekipler, mükerrer tahsilatları önlemek için her API çağrısına benzersiz bir "Idempotency Key" atar. Bu sayede ERP sistemi, aynı anahtarı ikinci kez gördüğünde işlemi tekrarlamaz.

Yüksek Erişilebilirlik ve Olay Müdahalesi

Level 1 seviyesindeki bir sistemin çökmesi, ticaretin durması anlamına gelir. Bu nedenle altyapı mühendisleri, sunucuları coğrafi olarak yedekli (örneğin İstanbul ve Ankara veri merkezleri) ve "Active-Active" mantığında çalıştırır. Herhangi bir felaket anında Küresel Yük Dengeleyiciler (Load Balancer) trafiği saniyeler içinde sağlam olan merkeze kaydırır.

Dahası PCI DSS v4.0 (Req 12.10), olay müdahalesini proaktif bir zemine çeker. Güvenlik ekipleri sadece teyit edilmiş siber saldırıları değil; şüpheli IP adreslerinden gelen başarısız giriş denemelerini bile SIEM (Güvenlik Bilgi ve Olay Yönetimi) üzerinden analiz ederek acil müdahale planını tetikler.

B2B tahsilat yazılımı kullanırken kart saklamak yasal mı?

Evet yasaldır. İşletmeler KVKK Madde 5 uyarınca kullanıcıdan 'Açık Rıza' aldığı ve kart numaralarını gerçek veriyi sistemden yalıtan tokenizasyon yöntemiyle sakladığı sürece bu işlem yasaldır.

Hangi şirketler PCI DSS Level 1 sertifikası almak zorundadır?

Yazılım altyapısı üzerinden yılda 300.000 adetten fazla kartlı ödeme işlemi geçiren tüm "Hizmet Sağlayıcı" (Service Provider) statüsündeki B2B teknoloji firmaları bu sertifikayı almak zorundadır.

PCI DSS v4.0 MFA zorunluluğu kimleri kapsıyor?

v4.0 standardı, Kart Sahibi Veri Ortamına (CDE) uzaktan veya ofis içinden erişen tüm yöneticiler, geliştiriciler ve yetkili kullanıcılar için Çok Faktörlü Kimlik Doğrulama (MFA) kullanımını zorunlu kılıyor.

Tokenizasyon ile şifreleme (encryption) arasındaki fark nedir?

Şifreleme, bir veriyi anahtarla gizler ve aynı anahtarla geri çözülmesini sağlar. Öte yandan tokenizasyon, gerçek veriyi kalıcı olarak kendi kasasında saklar ve dışarıya matematiksel geri dönüşü olmayan rastgele bir jeton verir.

Bir ihlal anında B2B yazılım sağlayıcısının sorumluluğu nedir?

Yazılım sağlayıcısı (Veri İşleyen), bir ihlali tespit ettiği anda herhangi bir süre kısıtlaması beklemeksizin, durumu gecikmeksizin ilgili ana işletmeye (Veri Sorumlusu) bildirmekle yükümlüdür. Veri Sorumlusu ise bu ihlali öğrendiği andan itibaren en geç 72 saat içerisinde Kişisel Verileri Koruma Kurulu’na raporlamalı ve ihlalden etkilenen ilgili kişilere bildirim yapmalıdır.

Bilgilendirme: Bu rehber teknik bilgilendirme amaçlıdır. Uyum süreçleriniz için yetkili bir QSA (Qualified Security Assessor) ve hukuk danışmanına başvurunuz.

PCI DSS ve KVKK Uyum Yükünü Netahsilat ile Ortadan Kaldırın

Kendi iç kaynaklarınızla sıfırdan PCI DSS v4.0 Level 1 sertifikasyonuna hazırlanmak ve KVKK teknik tedbirlerini uçtan uca mimarinize uygulamak, aylar süren bir efor ve devasa bir maliyet yaratır. Bunun yerine, 5.000'den fazla kurumsal firmanın güvendiği ve yıllık 630 Milyar TL işlem hacmini yöneten Finrota Netahsilat altyapısına geçiş yaparak operasyonel verimliliğinizi anında katlayabilirsiniz.

Online Tahsilat için Ücretsiz Demo İsteyin!