E-Pin Sitesinde Cüzdan Güvenliği: Bakiyeniz Gerçekten Ne Kadar Güvende?

Bir e-pin sitesinde asıl değerli olan ürün kataloğu değil, üstünde para hareket eden cüzdan sistemidir. Yüzlerce bayinin bakiye yatırıp harcadığı, saniyede birkaç işlemin geçtiği bir yapıda küçük bir açık, gece kimse fark etmeden binlerce liralık zarara dönüşebilir. Peki bu riskler nerede saklanıyor ve gerçekten neyi önlemek gerekiyor?

Cüzdan sistemi neden e-pin sitesinin en kritik noktası?

Fiziksel bir mağazada kasadaki parayı çalmak için oraya gitmeniz gerekir. E-pin sitesinde ise cüzdan, sunucudaki bir veritabanı satırından ibarettir — ve o satırı değiştirebilen herkes parayı "yaratabilir". Bu yüzden cüzdan güvenliği, sitenin tasarımından çok daha önemli bir mühendislik meselesidir.

Sorunun büyüklüğünü anlamak için tipik bir e-pin sitesinde bakiyenin kaç noktadan etkilendiğine bakmak yeterli:

• Havale/EFT onayı ile manuel bakiye yükleme
• PayTR, Shopier gibi otomatik ödeme bildirimleri (webhook)
• Ürün satın alma sırasında bakiyeden düşme
• Bayi komisyon ve alt bayi kâr payı hesaplamaları
• İade, iptal ve manuel admin düzeltmeleri

Bu beş nokta ne kadar çok kişi tarafından elle yönetiliyorsa, hata ve suistimal olasılığı da o kadar artıyor. Sıfırdan yazılmış bir sistemde genelde eksik kalan şey özellik değil, bu noktaların hepsini aynı kurala bağlayan tek bir merkezi mantıktır.

Çift harcama ve bakiye hileleri nasıl oluyor?

En sık karşılaşılan gerçek dünya saldırısı, aslında karmaşık bir hackleme değil — sistemin aynı anda gelen iki isteği doğru sırayla işleyememesidir. Buna "race condition" denir ve e-pin sektöründe çok tanıdıktır: bir bayi 50 TL bakiyesiyle art arda iki ürün siparişi açar, sistem her iki isteği de "bakiye yeterli" diye onaylar ve aslında 100 TL'lik ürün 50 TL karşılığında teslim edilmiş olur.

Bunun kök nedeni genelde şudur: bakiye kontrolü ile bakiyeden düşme işlemi arasında bir gecikme vardır ve bu iki adım "atomik" (bölünemez, tek seferde tamamlanan) bir veritabanı işlemi olarak yazılmamıştır. Yoğun trafikte, özellikle çoklu API isteği gönderen otomasyon araçlarıyla çalışan bayilerde bu açık kasıtlı olarak da denenebilir.

Korunmanın yolu satır kilitleme (row locking) ve transaction mantığıdır — her bakiye hareketi, kontrol ve düşme birlikte tek bir işlem olarak veritabanına yazılmalı, araya başka bir isteğin girmesine izin verilmemelidir. Bu, üstünkörü yazılmış scriptlerde neredeyse hiç düşünülmeyen bir detaydır.

Bir bayi hesabı ele geçirilirse ne kaybedersiniz?

Çok seviyeli bayilik modelinde tehlike tek bir yönetici hesabıyla sınırlı değildir — her bayi hesabı, kendi bakiyesi ve alt bayi ağıyla birlikte küçük bir hedef haline gelir. Zayıf şifre, şifre sıfırlama e-postasının ele geçirilmesi ya da aynı şifrenin başka sitede kullanılması (credential stuffing) en yaygın giriş noktalarıdır.

Bir bayi hesabı ele geçirildiğinde tipik senaryo şudur:

• Saldırgan mevcut bakiyeyi hızlıca kod/pin ürünlerine çevirir
• Kodlar anında farklı kanallarda satılır, geri alınması imkânsız hale gelir
• Alt bayi ağı varsa, üst bayinin komisyon ayarları değiştirilip haksız kazanç sağlanabilir
• Site sahibi durumu genelde saatler sonra, bakiye raporunu kontrol ettiğinde fark eder

Buradaki en büyük risk faktörü hız: bir e-pin kodu bir kez görüntülendiğinde artık geri döndürülemez bir varlıktır. Bu yüzden hesap güvenliği, ödeme güvenliğinden ayrı düşünülemeyecek kadar cüzdanla iç içedir.

Ödeme entegrasyonlarındaki açıklar cüzdanı nasıl vuruyor?

PayTR, Shopier veya banka havalesi entegrasyonu kurarken en çok atlanan nokta, "ödeme bildirimi geldi" ile "ödeme gerçekten yapıldı" arasındaki farktır. Bir webhook adresi (bildirim URL'si) imza kontrolü yapmadan bakiye yüklüyorsa, o adresi bulan herkes sahte bir bildirim göndererek bakiyesini sıfır maliyetle şişirebilir.

Sık görülen zayıf noktalar şunlardır:

• Ödeme sağlayıcısının imza/hash doğrulamasının atlanması ya da yanlış uygulanması
• Aynı bildirimin iki kez işlenip bakiyenin mükerrer yüklenmesi (idempotency eksikliği)
• Tutar ve sipariş numarasının çapraz kontrol edilmeden doğrudan güvenilmesi
• Test/sandbox modunun canlıya taşınırken kapatılmayı unutulması

Bu maddelerin her biri, kod tabanında tek bir satırlık eksiklik gibi görünse de sonucu doğrudan cüzdana yansıyan gerçek bir para kaybıdır. Pinova'da PayTR ve Shopier entegrasyonları imza doğrulama ve mükerrer bildirim kontrolüyle birlikte gelir; site sahibinin bu detayları ayrıca kodlaması gerekmez.

İşlem kaydınız yoksa bir anlaşmazlığı nasıl çözersiniz?

"Bakiyem eksik yüklendi", "sipariş bana ait değil" gibi bir bayi itirazı geldiğinde elinizde ne olduğu, sorunu dakikalar içinde mi yoksa günler içinde mi çözeceğinizi belirler. Her bakiye hareketinin — kim, ne zaman, ne kadar, hangi işlem için — kalıcı ve değiştirilemez şekilde kaydedilmesi, cüzdan güvenliğinin görünmeyen ama en pratik parçasıdır.

İyi bir işlem kaydı (audit log) şu soruları anında cevaplayabilmelidir:

• Bu bakiye hangi ödeme veya admin işleminden geldi?
• Hangi siparişte, hangi üründe harcandı?
• Admin panelinden manuel bir bakiye düzeltmesi yapıldıysa kim, ne zaman yaptı?
• Aynı IP'den kısa sürede kaç farklı hesaba giriş denemesi oldu?

Bu kayıtlar olmadan, bir anlaşmazlıkta site sahibinin elinde bayinin sözünden başka bir şey kalmaz — bu da hem güven kaybına hem de gereksiz kayıplara yol açar.

Manuel takip mi, otomatik güvenlik katmanı mı?

Küçük ölçekli bir e-pin sitesinde bu kontrolleri Excel ve elle takip ederek bir süre idare etmek mümkün. Ama bayi sayısı ve günlük işlem hacmi arttıkça, insan gözüyle yakalanamayacak hızda hareketler oluşur — ve tam da o noktada zarar başlar.

Buradaki fark bir "özellik listesi" farkı değil, sorumluluğun kimde olduğu farkıdır. Kendi yazdığınız bir sistemde her açığı siz veya geliştiriciniz kapatmak zorundadır; hazır ve test edilmiş bir altyapıda bu kontroller zaten üretim ortamında binlerce işlemden geçmiştir.