Sahte Bayi Başvurularını E-Pin Yazılımı ile Nasıl Tespit Edersiniz?

Bayi sistemi açan hemen her e-pin ve dijital ürün satış sitesi, er ya da geç aynı sahneyle karşılaşır: bir sabah panelde onay bekleyen "bayi başvurusu" bildirimi görürsünüz, isim gerçek gibidir, telefon numarası doğrulanmıştır, ama iki hafta sonra o hesaptan çalıntı kartla toplu UC alımı yapılır ya da alınan bakiye başka hesaplara aktarılıp ortadan kaybolur. Sorun şu ki sahte bir bayi başvurusu, gerçek bir bayi başvurusuyla neredeyse birebir aynı görünür — fark, formda değil, formun arkasındaki verilerdedir.

Sahte bayi başvurusu neden bu kadar kolay sızıyor?

E-pin sitelerinde bayilik genelde iki adımda açılır: kullanıcı bir form doldurur, admin "onayla" butonuna basar. Aradaki tek filtre insan gözüdür — ve insan gözü, e-posta adresinin bir dakika önce kurulmuş geçici bir kutu olduğunu, telefon numarasının sanal SMS servisinden alındığını ya da aynı kişinin farklı isimlerle beşinci başvurusunu yaptığını göremez. Sahte başvurular genelde üç amaçtan biriyle açılır:

• Çalıntı kredi kartıyla yüklenen bakiyeyi bayi indirimiyle hızlıca "temizlemek" (kart iadesi geldiğinde site zararı üstlenir)
• Bayi paneli üzerinden tedarikçi API'sine erişip toplu kod çekmek, sonra hesabı terk etmek
• Gerçek bir bayi gibi davranıp güven kazandıktan sonra tek seferlik büyük bir dolandırıcılık yapmak

Manuel onay süreci bu üçünü de aynı formda görür: "ad soyad, telefon, e-posta, neden bayi olmak istiyorsunuz." Formun kendisi hiçbir şey söylemez; asıl ipucu, başvurunun arkasındaki teknik iz düşümündedir.

Sorunu büyüten bir başka etken de bayilik başvurusunun genelde "iyi haber" olarak algılanmasıdır. Bir müşteri bayilik istediğinde, işletmeci içgüdüsel olarak bunu büyüme sinyali sayar ve onay sürecini olabildiğince hızlı geçirmeye çalışır. Bu isteklilik, aslında dolandırıcının en çok yararlandığı zaaftır — çünkü hızlı onaylanan bir başvuru, arkasındaki riski hiç sorgulamadan geçer. Oysa gerçek büyüme ile sahte hacim arasındaki fark, ilk 48 saat içindeki davranışta netleşir; sorun şu ki o 48 saati kimse elle takip etmez.

Hangi sinyaller bir başvuruyu "şüpheli" yapar?

Deneyimli bir e-pin işletmecisi zamanla bir sezgi geliştirir ama sezgi ölçeklenmez — günde 3 başvuruda işe yarar, günde 40 başvuruda yorulur ve gözden kaçırır. Yazılımın yapması gereken, bu sezgiyi somut kurallara dönüştürmektir. Gerçekte bakılması gereken sinyaller şunlardır:

• IP geçmişi: Aynı IP veya aynı /24 alt ağından kısa sürede birden fazla bayi başvurusu gelmiş mi?
• Cihaz parmak izi: Farklı isim ve e-postalarla başvuran kişiler aslında aynı tarayıcı/cihaz izine mi sahip?
• E-posta yaşı ve tipi: Adres bilinen bir geçici mail sağlayıcısından mı, yoksa siteyle daha önce sipariş geçmişi olan bir hesap mı?
• Hesap yaşı ve davranışı: Başvuru, hesap açıldıktan saniyeler sonra mı geldi, yoksa aylardır sipariş veren sadık bir müşteriden mi?
• Doldurma hızı: Form saniyeler içinde, insan yazma hızının çok üstünde bir tempoda mı dolduruldu (bot işareti)?

Tek başına hiçbiri kesin kanıt değildir — geçici mail kullanan herkes dolandırıcı olmadığı gibi, aynı IP'den başvuran iki kişi de aynı ofiste çalışan gerçek iş ortakları olabilir. Ama bu sinyaller üst üste bindiğinde ortaya net bir risk puanı çıkar, ve işte tam burada otomasyon devreye girmelidir.

Burada dikkat edilmesi gereken bir nüans var: sinyallerin tek başına değil, birlikte okunması gerekir. Örneğin geçici bir e-posta adresiyle başvuran biri, gerçekten sadece gizliliğine önem veren bir bireysel bayi adayı olabilir. Ama aynı kişi hem geçici e-posta kullanıyor hem daha önce hiç sipariş vermemiş hem de form doldurma hızı insan tempi değilse, artık üç ayrı zayıf sinyal değil, tek bir güçlü uyarı vardır. İyi bir risk modeli, sinyalleri toplarken bu tür birleşimlere ağırlık verir; hiçbirini tek başına diskalifiye sebebi saymaz.

IP, cihaz ve davranış verisi neden bayi güvenliğinin temelini oluşturur?

Pinova gibi bir e-pin yazılımında bayi başvurusu, tek bir form gönderimi değil, o kullanıcının siteyle olan tüm geçmişiyle birlikte değerlendirilen bir olaydır. Sistem başvuru anında kullanıcının IP adresini, cihaz bilgisini ve önceki sipariş/oturum kayıtlarını otomatik olarak eşleştirir. Bu sayede admin paneline düşen her başvuru, çıplak bir formdan çok, arkasında küçük bir dosya taşıyan bir kayıt olarak gelir: "bu IP daha önce 2 farklı hesapla giriş yaptı", "bu cihaz son 24 saatte 5 sipariş denedi ve 3'ü kartı reddedildi" gibi.

Bunun pratikteki karşılığı basittir: admin artık "onaylayayım mı?" sorusuna körü körüne cevap vermez, elinde somut bir gerekçe olur. Riskli sinyali olan başvurular otomatik olarak "incelemede" kuyruğuna düşer, temiz geçmişi olan sadık müşteriler ise hızlı onay akışından geçebilir. Yani güvenlik, hız kesmez — tam tersine, düşük riskli başvuruların önünü açarken yüksek riskli olanları yavaşlatır.

Bu eşleştirmenin bir başka faydası, bayilik başvurusundan çok önce başlamasıdır. Kullanıcı siteye ilk üye olduğu andan itibaren cihaz ve IP bilgisi sistemde birikir; dolayısıyla bayilik başvurusu geldiğinde admin sıfırdan bir profil okumaz, kullanıcının aylardır süren gerçek geçmişini görür. Bu da sahte hesapların en çok güvendiği taktiği boşa çıkarır: "yeni hesap açıp hemen bayilik iste" yöntemi, geçmişi olmayan hesapları otomatik olarak daha temkinli bir kademeye düşürür.

Kademeli onay sistemi sahteciliği nasıl durdurur?

En büyük hata, bayilik başvurusunu tek adımlı bir "evet/hayır" kararına indirgemektir. Oysa gerçek koruma, başvurunun risk seviyesine göre değişen kademeli bir süreçte saklıdır: düşük limitli deneme bayiliği, sipariş geçmişine göre yükselen kredi limiti, belirli bir ciro eşiğinden sonra açılan toplu indirim kademeleri gibi. Sahte bir hesap genelde ilk birkaç işlemde art niyetini gösterir — küçük limitli bir deneme döneminde bu, gerçek zarara dönüşmeden yakalanır.

Bu tablo aslında şunu gösteriyor: fark, "kontrol yapılıyor mu yapılmıyor mu" değil, "kontrol her başvuruda tutarlı biçimde yapılabiliyor mu" sorusunda. Yorgun bir admin, yoğun bir günde bu kontrollerin çoğunu atlar; sistem asla atlamaz.

Kademeli yapının bir diğer avantajı, sahte hesabın ilk hamlesini "ucuz" bir hataya çevirmesidir. Deneme limitiyle başlayan bir bayi, ilk denemesinde büyük hacimli bir dolandırıcılık yapamaz; sistemin izin verdiği üst sınır zaten düşüktür. Limit yükseldikçe geçmiş de birikir, geçmiş biriktikçe risk azalır. Bu, tek seferlik bir "onayla/reddet" kararına kıyasla çok daha dayanıklı bir savunma hattıdır — çünkü tek bir yanlış karar, tüm siteyi riske atmaz.

Otomatik red mi, manuel inceleme mi tercih edilmeli?

Burada işletmecilerin düştüğü tipik bir tuzak var: "madem risk tespiti var, o zaman şüpheli başvuruları direkt reddedeyim." Bu yaklaşım, hem gerçek müşteri kaybettirir hem de dolandırıcılara sisteminizin kurallarını öğretir (kural ihlal edilince anında red geliyorsa, saldırgan bir sonraki denemesinde eşiğin altında kalmayı öğrenir). Doğru yaklaşım, risk puanlamasını bir filtre değil bir önceliklendirme aracı olarak kullanmaktır:

• Düşük risk → otomatik onay, standart bayi limitiyle başlar
• Orta risk → onaylanır ama düşük limit ve yakın takiple başlar
• Yüksek risk → admin onayı beklemeden hesap açılmaz, ek belge/telefon doğrulaması istenebilir

Bu üç kademe, hem büyüme hızını korur hem de riski kabul edilebilir seviyede tutar. Pinova'daki bayi modülü tam olarak bu mantıkla kurulmuştur: başvuru formunun arkasında çalışan risk puanı, admin panelinde başvuruların yanına küçük bir etiket olarak düşer — "temiz", "gözden geçir", "dikkat" gibi — ve karar yine insanda kalır, ama insan artık kör değildir.

Bu yaklaşımın gizli bir avantajı daha var: dolandırıcılar genelde en az direnç gösteren siteyi hedef alır. Bir e-pin sitesinde kademeli onay ve risk etiketleme olduğu görüldüğünde — ki bu genelde ilk birkaç denemeden sonra anlaşılır — kötü niyetli başvuru sahipleri başka bir hedefe yönelir. Yani sistem sadece mevcut sahteleri yakalamakla kalmaz, zamanla sitenin "kolay hedef" listesinden çıkmasını da sağlar.

Bir sahte bayi sisteme sızarsa gerçekte ne kaybedersiniz?

Sahte bayi başvurusunun maliyeti, çoğu işletmecinin tahmin ettiğinden büyüktür. Doğrudan kayıp — chargeback, tedarikçiden çekilen kod bedeli — sadece görünen kısımdır. Asıl kayıp, genellikle şu üç noktada çıkar:

• Tedarikçi ilişkisi: Turkpin/Pinabi gibi tedarikçiler, hesabınızdan anormal yüksek iade/itiraz oranı görürse limitinizi düşürür ya da API erişiminizi askıya alır — bu, tüm sitenizin teslimat hızını etkiler.
• Gerçek bayilerin güveni: Sahte bir bayinin sebep olduğu stok/bakiye krizi, o anda sistemde işlem yapan dürüst bayileri de gecikme veya iptal ile etkiler.
• Zaman: Bir sahte hesabı geriye dönük tespit edip temizlemek, işlemleri geri almak, tedarikçiyle görüşmek — bunların hepsi, önceden filtrelenmiş bir başvuruya harcanmayacak saatlerdir.

Yani mesele sadece "birkaç yüz lira kayıp" değil; sistemin bütününün güvenilirliğidir. Bir e-pin sitesinin en değerli varlığı stoktan önce güvendir — tedarikçinin size, bayilerin siteye duyduğu güven. Sahte bir başvuru bu zincirin herhangi bir halkasını kırdığında, etkisi tek işlemle sınırlı kalmaz.

Bunu somutlaştırmak gerekirse: orta ölçekli bir e-pin sitesinde tek bir sahte bayi vakası, doğrudan chargeback tutarının kat kat üzerinde bir maliyete yol açabilir. Tedarikçi API limitinin geçici olarak düşürülmesi, o hafta boyunca tüm müşterilere yapılan teslimatların yavaşlamasına neden olur; bu da müşteri şikayetlerine, iade taleplerine ve nihayetinde marka güveninde kalıcı bir aşınmaya dönüşür. Yani erken tespit, sadece bir hesabı korumakla kalmaz, o haftaki tüm sipariş akışını korumuş olur.