Kaçak E-Pin Satışlarından Korunmak İçin Yazılım Önlemleri

Bir gecede stoğunuzun yarısının "tükendi" görünmesi, aynı e-pin kodunun üç farklı forumda satılması, ya da hiç sipariş vermediğiniz bir bayinin panelinizden yüzlerce kod çekmesi — e-pin ve dijital ürün satan hemen her işletme sahibinin en az bir kez yaşadığı kabus budur. Kaçak satış sadece gelir kaybı değil, tedarikçinizle ilişkinizi de riske atar; çünkü Turkpin veya Pinabi gibi API sağlayıcılar, anormal tüketim tespit ettiğinde hesabınızı askıya alabilir. Bu yazıda, sorunun nereden geldiğini ve hangi yazılımsal önlemlerin gerçekten işe yaradığını adım adım ele alıyoruz.

Sorunun can sıkıcı yanı, çoğu zaman zararın fark edilmesinin haftalar sürmesidir. Küçük ölçekli bir kaçak satış, aylık raporlarda genel bir "beklenmeyen stok açığı" olarak görünür ve kaynağı tespit edilene kadar tekrar tekrar yaşanır. Bu yazıdaki önlemlerin ortak noktası, sorunu rapor döneminde değil, tam olduğu anda görünür kılmaktır.

Kaçak e-pin satışı gerçekte nasıl başlıyor?

Çoğu satıcı "hack" kelimesini duyunca karmaşık bir siber saldırı hayal eder, oysa gerçek tablo çok daha sıradandır. Kaçak satışın büyük kısmı, sistemdeki küçük tasarım açıklarının sabırla istismar edilmesiyle ortaya çıkar:

• Bir bayi hesabının şifresi zayıf olduğu için ele geçirilir ve bakiye limitine kadar kod çekilir.
• Sipariş sonrası kod ekranının önbelleğe (cache) alınması, aynı linkin tekrar tekrar açılıp aynı kodun görüntülenmesine izin verir.
• API'den çekilen kodlar sistemde "kullanıldı" olarak işaretlenmeden loglanır, bu da aynı kodun iki farklı siparişe eşlenmesine yol açar.
• Test/deneme siparişleri için açılan arka kapılar (backdoor) üretime taşınır ve unutulur.

Yani mesele genelde bir "saldırgan" değil, günlük operasyonda gözden kaçan küçük boşluklardır. Pinova gibi bir altyapıda bu noktaların çoğu zaten kapalı gelir, ama kendi yazdırdığınız veya eski bir scripti kullandığınız sistemlerde bu kontrolleri tek tek siz eklemek zorundasınız.

Bir diğer önemli nokta, kaçak satışın çoğu zaman "yavaş yavaş" büyümesidir. İlk başta tek bir kullanıcı, tek bir kodu ikinci kez satmayı dener; sistem tepki vermeyince bu davranış tekrarlanır, zamanla organize bir yeniden-satış ağına dönüşür. Bu yüzden erken tespit mekanizmaları, büyük bir saldırıyı engellemekten çok, küçük istismarları daha büyümeden fark edip kapatmak için tasarlanmalıdır. Sisteminizde her işlemin izlenebilir olması, bu erken uyarıyı mümkün kılan en temel şarttır.

Sisteminize sızan botları nasıl fark edersiniz?

Kaçak satışın çoğu zaman insan eliyle değil, otomatik botlarla yapıldığını bilmek önemlidir. Bot trafiğinin bıraktığı izler genelde belirgindir, yeter ki bakmayı bilin:

• Kısa sürede aynı IP adresinden art arda açılan çok sayıda hesap veya sipariş.
• Ödeme denemelerinde art arda başarısız kart girişleri (kart doğrulama/"carding" denemesi).
• Normal bir kullanıcının yazamayacağı kadar hızlı form doldurma süreleri (ör. 1-2 saniyede checkout tamamlama).
• Belirli saatlerde (gece 03:00-05:00 gibi) yoğunlaşan, insan davranışına uymayan sipariş grafiği.

Bu sinyalleri yakalamak için sitenizde sipariş loglarını IP, cihaz parmak izi (fingerprint) ve zaman damgasıyla birlikte tutan bir yapı şart. Pinova'nın admin panelinde sipariş geçmişi bu üç veriyle birlikte kayıt altına alınır, böylece anormal bir dalga başladığında geriye dönük analiz dakikalar içinde yapılabilir.

Botları yakalamanın bir başka yolu da "davranış eşiği" tanımlamaktır. Örneğin bir kullanıcı hesabının dakikada kaç kez sayfa yenilediği, sepete kaç kez ürün ekleyip çıkardığı gibi veriler normal bir alışverişçide belli bir aralıkta kalır; bu aralığın dışına çıkan hesaplar otomatik olarak "izlemeye alınmış" statüsüne geçirilebilir. Bu tür eşik tanımları bir kere kurulduktan sonra insan müdahalesi gerektirmeden çalışır, bu da özellikle küçük ekiplerle yönetilen sitelerde büyük zaman kazandırır.

Kod tekrarı ve stok hırsızlığını hangi mekanizmalar önler?

E-pin kodunun "iki kere satılması" ya da bir çalışanın panelden habersizce kod çekmesi, satıcıların en çok korktuğu senaryolardan biridir. Bunu önlemenin yolu, kodun yaşam döngüsünü baştan sona yazılımsal olarak kilitlemektir:

• Tek kullanımlık işaretleme: Bir kod tedarikçi API'sinden çekildiği anda sistemde "rezerve" durumuna geçmeli, ödeme onaylanmadan "satıldı" statüsüne alınmamalı, ödeme başarısız olursa otomatik iade edilmelidir.
• Değişmez işlem logu: Hangi kodun, hangi siparişe, hangi kullanıcı tarafından, hangi IP'den çekildiği silinemeyen bir log tablosunda tutulmalı.
• Panel içi çift kontrol: Belirli bir tutarın üzerindeki manuel kod çekme işlemleri, ikinci bir yöneticinin onayına bağlanmalı.
• Anlık tedarikçi senkronu: Stok miktarı tedarikçi tarafında değiştiğinde sitenizde de anında güncellenmeli; aksi halde "hayalet stok" üzerinden sipariş alıp müşteriyi mağdur edebilirsiniz.

Pinova, Turkpin ve Pinabi entegrasyonlarında bu akışı otomatik kod çekme + anlık log + tek kullanımlık teslimat üçlüsüyle kurar; yani kodun "ikinci kez satılabilmesi" için sistemin bilerek bypass edilmesi gerekir, bu da olağan işletme hatalarını büyük ölçüde eler.

Burada gözden kaçan bir detay da müşteri destek ekranlarıdır. Bir müşteri "kodum çalışmadı" dediğinde destek personeli genelde koda tekrar erişebilir; bu erişim de loglanmazsa, aynı destek ekranı zamanla bir kod sızıntısı kapısına dönüşebilir. Bu yüzden destek amaçlı görüntülemelerin bile ayrı bir yetki seviyesinde ve kayıt altında tutulması, tam anlamıyla kapalı bir sistem için gereklidir.

Bayi ve müşteri hesaplarını gerçekte kim denetliyor?

Çok seviyeli bayi sistemi olan e-pin sitelerinde en büyük risk, aslında dışarıdan değil, sisteme erişimi olan içeriden gelir. Bir bayi hesabının ele geçirilmesi, doğrudan cüzdan bakiyesi kadar kod hırsızlığı demektir. Alınabilecek önlemler şunlardır:

• Bayi girişlerinde iki adımlı doğrulama (2FA) zorunlu tutulmalı, özellikle yüksek bakiyeli hesaplarda.
• Her bayi hesabı, önceden tanımlı IP aralığı veya cihazla eşleştirilebilmeli; alışılmadık bir konumdan giriş denemesi otomatik uyarı üretmeli.
• Bayilere günlük/saatlik çekim limiti tanımlanmalı; limit aşımında sipariş otomatik değil, onaylı işleme düşmeli.
• Şüpheli hesap tek tıkla dondurulabilmeli, dondurma işlemi bakiyeyi ve bekleyen siparişleri otomatik güvenli moda almalı.

Bu kontroller manuel takip edildiğinde ekip büyüdükçe gözden kaçmaya başlar; oysa Pinova'nın bayi modülünde limit, IP kısıtı ve anlık dondurma özellikleri panel üzerinden birkaç saniyede tanımlanabilir, ayrıca her değişiklik kendiliğinden loglanır.

Çok seviyeli bayi yapısında bir de "yetki devri" sorunu vardır: üst seviye bir bayi, kendi alt bayisine tanımladığı limiti zamanla unutabilir veya güncellemeyi ihmal edebilir. Sistemin bu ilişkiyi otomatik hatırlatmalarla ("alt bayiniz X limitine yaklaştı" gibi) desteklemesi, hem üst bayinin hem de site sahibinin kontrolü kaybetmeden büyümesini sağlar. Aksi halde her yeni bayi eklendiğinde risk, kontrol edilemeyen bir noktadan artmaya devam eder.

Ödeme tarafında sahtecilik nasıl daha erken yakalanır?

Kaçak e-pin satışının bir kısmı da çalıntı kredi kartlarıyla yapılan siparişlerden beslenir; satıcı kodu teslim eder, birkaç gün sonra banka "chargeback" (ters ibraz) bildirimiyle geri döner ve kod çoktan elden çıkmış olur. Bu riski azaltmanın yolları:

• PayTR ve Shopier gibi altyapılarda 3D Secure'u zorunlu tutmak, opsiyonel bırakmamak.
• Aynı kart bilgisiyle kısa sürede birden fazla başarısız deneme yapan siparişleri otomatik olarak bekletmeye almak.
• Yüksek tutarlı ilk siparişlerde (yeni müşteri + yüksek tutar kombinasyonu) teslimatı birkaç dakika geciktirip risk skoru hesaplamak.
• Chargeback geçmişi olan kart/e-posta/IP kombinasyonlarını kara listeye alıp otomatik reddetmek.

Bu kuralların hepsini elle yönetmek, özellikle günde yüzlerce siparişi olan bir site için pratik değildir. Pinova'nın ödeme katmanı, PayTR/Shopier bildirimlerini işlerken risk skoruna göre siparişi anında onaylayan, bekleten veya reddeden bir mantıkla çalışır; böylece dolandırıcılık şüphesi olan siparişler kod teslim edilmeden önce durdurulur.

Havale/EFT ile yapılan ödemelerde de benzer bir dikkat gerekir. Dekont üzerindeki tutarın, gönderen ismin ve açıklamanın sistemde otomatik eşleştirilmesi, elle kontrol edilen bir muhasebe sürecine göre çok daha az hataya açıktır. Özellikle yoğun kampanya dönemlerinde, elle onaylanan havale siparişleri hem gecikir hem de sahte dekont paylaşımlarına karşı savunmasız kalır; otomatik eşleştirme bu iki riski de aynı anda azaltır.

Otomatik teslimat mı, manuel onay mı daha güvenli?

Bu soruyla sık karşılaşılır: "Kodları otomatik teslim etmek riski artırmaz mı, her siparişi elle kontrol etsem daha mı güvenli olur?" Gerçek şu ki, manuel süreç güvenliği artırmaz, sadece hatayı insana taşır. Yorgun bir çalışan, yoğun bir günde şüpheli bir siparişi fark etmeyebilir; otomasyon ise yorulmaz ve her siparişe aynı kuralı uygular.

Doğru yaklaşım "otomasyon ya da kontrol" değil, "kural tabanlı otomasyon + istisnai durumlarda insan onayı" ikilisidir:

• Düşük riskli, standart siparişler (bilinen müşteri, normal tutar, temiz IP) tamamen otomatik ve anında teslim edilir — bu da müşteri memnuniyetini korur.
• Risk skoru yüksek siparişler (yeni hesap + yüksek tutar + farklı ülke IP'si gibi) otomatik olarak "manuel onay" kuyruğuna düşer.
• Bayi çekimleri, tanımlı limitin üzerine çıktığında ikinci bir onay adımı ister.

Pinova bu hibrit modeli varsayılan olarak destekler: 7/24 otomatik teslimat çalışırken, sizin belirlediğiniz risk kurallarına takılan siparişler otomatik olarak beklemeye alınır ve panelden tek tıkla incelenebilir. Böylece hem hız hem güvenlik aynı anda korunmuş olur.

Uzun vadede en sürdürülebilir yaklaşım, güvenlik önlemlerini "bir kerelik proje" değil, sürekli ayarlanan bir sistem olarak görmektir. Risk kuralları zamanla eskir; bugün etkili olan bir eşik değeri, altı ay sonra ya çok gevşek ya da çok sıkı kalabilir. Bu yüzden sipariş verilerini düzenli olarak gözden geçirip kuralları güncellemek, yazılımın kendisi kadar önemli bir alışkanlıktır.