Çoğu e-pin satıcısı şunu sanır: kart numarası bana hiç uğramıyor, müşteri bankanın ya da ödeme kuruluşunun sayfasında kartını giriyor, ben sadece sonuç bildirimini alıyorum. Dolayısıyla PCI DSS denen o kalın dokümanın benimle ilgisi yok. Bu cümle, Türkiye'de dijital ürün satan yüzlerce sitenin ortak inancı. Ve tam da bu yüzden ilk ciddi kaza, hep en rahat olduğunu düşünen sitede oluyor.
Gerçek şu: kapsamı belirleyen şey kart verisini depolayıp depolamadığın değil, o veriye giden yolu kimin çizdiği. Ödeme formunu kendi şablonunda gösteriyorsan, tutarı kendi tarafında hesaplıyorsan, dönüş bildirimini kendi kodunla doğruluyorsan, sen o ödeme akışının bir parçasısın. İyi bir e-pin satış scripti bu ayrımı senin yerine kurar; kötü bir kurulum ise ödeme akışını kod içine dağıtır ve bir gün bir bankanın uyum ekibi kapını çaldığında elinde gösterecek tek bir kayıt bile bırakmaz. Aşağıda, bu sınırı nereye çizeceğini ve e-pin yazılımı tarafında hangi kontrolleri talep etmen gerektiğini tek tek açıyorum.
Kart Verisi Sana Hiç Gelmiyor Diye Kapsam Dışı mısın?
Kapsam, kart verisinin diskinde durmasıyla başlamaz; ödeme sayfasının bütünlüğünü kimin garanti ettiğiyle başlar. Yönlendirmeli (hosted) ödemede müşteri tamamen sağlayıcının alan adına gider, kart alanlarını o sayfa üretir ve senin HTML'in o an ekranda yoktur. Burada yükümlülüğün en hafif halidir. Ama bugün çoğu dijital ürün satış scripti dönüşüm kaygısıyla ödemeyi site içinde tutar: iframe gömer, alan bazlı tokenizasyon kullanır, kart maskesini kendi JavaScript'iyle çizer. O anda sayfaya enjekte edilen tek bir üçüncü parti script, kart alanını dinleyebilecek konuma gelir. Kapsamın büyümesinin sebebi budur: kart verisini sen görmesen de, kart verisini görebilecek kodu sen yüklüyorsun. Pratik ölçüt basit: ödeme ekranındaki her satır JavaScript'in sorumlusu sensen, o ekran senin uyum yükünün içindedir.
Ödeme Ekranını Kim Çiziyor? Kapsamı Belirleyen Tek Soru
Bu soruyu cevaplamadan güvenlik bütçesi ayırmak boşa kürek çekmektir. Aşağıdaki tablo, epin yazılım kurulumlarında en sık gördüğüm dört entegrasyon biçimini ve her birinin getirdiği yükü karşılaştırıyor. Kendi sitende hangi satırda durduğunu işaretle; geri kalan bütün kararlar bu satıra göre şekillenecek.
| Entegrasyon biçimi | Kart alanını kim üretir | Uyum yükü | Tipik kırılma noktası | Dönüşüm etkisi |
|---|---|---|---|---|
| Tam yönlendirme (hosted) | Sağlayıcı alan adı | En düşük | Dönüş bildirimi doğrulanmaz | Orta |
| iframe / gömülü form | Sağlayıcı, senin sayfanda | Orta | Sayfaya giren 3. parti script | İyi |
| Alan bazlı tokenizasyon | Sağlayıcı JS, senin DOM'un | Yüksek | CSP yok, script bütünlüğü yok | En iyi |
| Doğrudan API (kart sende) | Senin sunucun | Çok yüksek | Log ve bellek sızıntısı | En iyi |
Chargeback Neden Sahtecilikten Daha Çok Kanatıyor?
E-pin işinde kaybın büyük kısmı, gece yarısı sunucuna giren bir saldırgandan gelmez; teslim ettiğin kodun geri alınamamasından gelir. Fiziksel üründe kargo kaydı vardır, dijital üründe elinde ne varsa o kadar delil sunabilirsin. Bu yüzden ödeme güvenliğini yalnız şifreleme meselesi gibi düşünmek yanlış. Asıl mesele kanıt zinciri: hangi IP, hangi oturum, hangi cihaz parmak izi, hangi saniyede hangi kodu gördü; kod görüntülendikten sonra kaç kere kopyalandı; müşteri e-postası doğrulandı mı. İyi kurulmuş bir e-pin satış yazılımı her siparişe bu meta veriyi yapıştırır ve itiraz dosyasına tek tuşla üretir. Kanıtı olmayan satıcı, haklı olduğu dosyaları bile kaybeder.
Ödeme Kaynaklı Kayıpların Dağılımı
- İtiraz / chargeback 45%
- Sahte kart ve bot denemesi 25%
- Manuel iade ve operasyon 20%
- Komisyon ve kur farkı 10%
Webhook'unu Doğrulamıyorsan Kasan Açık Duruyor
Sahada gördüğüm en pahalı hata, ödeme bildirimine körü körüne güvenmek. Sağlayıcı sana bir dönüş isteği gönderiyor, script bu isteği alıp siparişi ödendi işaretliyor ve kodu teslim ediyor. Sorun şu ki o isteği taklit etmek, imza doğrulaması yoksa, bir tarayıcı eklentisi kadar basit. Doğru akış üç şarttan oluşur: imza doğrulaması (sağlayıcının gizli anahtarıyla üretilmiş hash'i sunucu tarafında yeniden hesapla), tutar ve para birimi karşılaştırması (bildirilen tutar sipariş tutarına eşit değilse teslim etme) ve idempotent işlem kaydı (aynı işlem numarası ikinci kez geldiğinde bakiye veya kod tekrar üretilmesin). Ayrıca durum sorgusunu otorite kabul et: bildirim geldi diye değil, sağlayıcıdan tekrar sorduğunda başarılı dönüyorsa teslim et.
Anahtarlar, Loglar ve Panel Erişimi: Sessiz Üç Sızıntı
API anahtarını web köküne bırakmak, Türkiye'de en sık rastlanan yapılandırma hatası. Anahtarların webroot dışında, dosya izinleri kısıtlı bir dizinde durması gerekir; yedeklerin ise şifreli olmalı, çünkü çoğu sızıntı canlı sunucudan değil eski bir yedek arşivinden çıkar. Log tarafında kural nettir: kart numarası, CVV ve tam yetkilendirme yanıtı loglanmaz; sadece maskeli son dört hane, işlem numarası ve durum kodu tutulur. Yönetim panelin ise ayrı bir cephe: tahmin edilebilir bir adres, tek parolalı bir giriş ve sınırsız deneme hakkı, bütün ödeme sertleştirmeni anlamsızlaştırır. Gizli yönetim yolu, iki adımlı doğrulama, IP kısıtı ve her yetkili işlemi yazan bir denetim kaydı; bunlar lüks değil, asgari sınır.
Peki Nereden Başlayacaksın? Sıralı Denetim Listesi
Güvenliği bir proje gibi değil, tekrar eden bir bakım gibi düşün. Aşağıdaki listeyi çeyrek dönem başlarında tepeden aşağı geç; her satırın kanıtı olsun. Kanıt, ekran görüntüsü değil; kaydın kendisidir.
| Kontrol | Ne aranır | Sıklık | Kanıt | Öncelik |
|---|---|---|---|---|
| Webhook imza doğrulama | Sunucu tarafı hash karşılaştırması | Her sürümde | Kod ve test kaydı | Kritik |
| Tutar ve idempotency | Çift teslim ve eksik tutar engeli | Her sürümde | İşlem tablosu tekil indeks | Kritik |
| Anahtar konumu | Webroot dışı, izin 600 | Aylık | Dizin listesi | Yüksek |
| Log hijyeni | PAN/CVV yok, maskeli kayıt | Aylık | Log örneklemi | Yüksek |
| Panel erişimi | 2FA, IP kısıtı, gizli yol | Çeyreklik | Denetim kaydı | Yüksek |
| Teslimat kanıtı | IP, oturum, görüntüleme zamanı | Sürekli | Sipariş meta verisi | Orta |
| Yedek şifreleme | Şifreli arşiv, ayrı erişim | Aylık | Yedek politikası | Orta |
Riskli siparişte kodu anında açmak yerine kısa bir bekleme penceresi tanımla. Yüksek tutar, yeni hesap ve uyuşmayan ülke kombinasyonunda manuel onay kuyruğu, chargeback oranını tek başına yarıya indirebilir.
Ödeme akışını sertleştirilmiş bir altyapıyla kur
Pinova, imza doğrulama, idempotent sipariş kaydı, teslimat kanıtı ve denetim logunu hazır getiren lisanslı bir e-pin satış yönetim yazılımıdır. Kendi kodunda tek tek keşfetmek zorunda kalmazsın.
Ödeme sayfasını yönlendirmeli kullanırsam PCI ile hiç işim olmaz mı?
Yükün en hafif hali budur ama sıfır değildir. Sunucu güvenliği, log hijyeni, anahtar yönetimi ve dönüş bildirimi doğrulaması hâlâ tamamen sende kalır.
Sanal POS entegrasyonunda en kritik tek kontrol hangisi?
Sunucu tarafında yapılan imza ve tutar doğrulaması. Bu iki kontrol olmadan teslim eden bir kurulum, bedava kod dağıtan bir uç noktaya dönüşür.
Kart bilgisini müşteri kolaylığı için saklayabilir miyim?
Kendi veritabanında saklama. Saklamayı gerektiren senaryolarda sağlayıcının kart saklama ve token hizmetini kullan; hassas veri sende durmasın.
İtiraz dosyasında hangi kayıtlar işe yarıyor?
Sipariş anındaki IP ve cihaz bilgisi, e-posta doğrulaması, kodun ilk görüntülenme zaman damgası, kullanım durumu ve müşteriyle yazışma kaydı.
Ödeme güvenliği, sonradan üstüne yapıştırılan bir eklenti değil; siparişin doğduğu andan teslimata kadar uzanan bir zincir. Bu zincirin halkalarını kendi kodunda tek tek kurmak yerine hazır ve denetlenmiş bir temelde ilerlemek istiyorsan, özellik listesini ve fiyatlandırmayı inceledikten sonra akışı kendi gözünle görmek için canlı demo üzerinden bir sipariş oluştur; imza doğrulamadan teslimat kanıtına kadar her adımın nereye yazıldığını orada takip edebilirsin.