Chargeback (Ters İbraz) Riskine Karşı E-Pin Scripti Önlemleri

Bir e-pin sitesinde en korkulan e-posta "chargeback bildirimi" başlıklıdır — çünkü ürün çoktan teslim edilmiş, kod muhtemelen kullanılmış, ama para artık bankada askıdadır. Fiziksel ürün satan bir mağaza kargo takip numarasıyla kendini savunabilirken, dijital kod satan bir site elinde ne varsa onunla itiraz eder. Bu yazıda chargeback'in e-pin sektöründe neden bu kadar keskin bir risk olduğunu ve scriptin hangi katmanlarında hangi önlemlerin alınması gerektiğini anlatıyoruz.

Chargeback e-pin satıcıları için neden diğer sektörlerden daha tehlikeli?

Chargeback (ters ibraz), kart sahibinin bankasına "bu işlemi ben yapmadım" veya "ürünü almadım" diyerek itiraz etmesiyle başlar ve banka parayı satıcıdan geri çeker. Fiziksel ticarette satıcı elindeki teslimat kanıtıyla bu itirazı çoğu zaman geri çevirebilir. E-pin ve dijital ürün satışında durum farklıdır: ürün saniyeler içinde teslim edilir, kod anında kullanılabilir hale gelir ve "mal zaten elimde değil" savunması işe yaramaz — çünkü zaten kimse fiziksel bir paket beklemez.

Bu da e-pin sitelerini iki açıdan kırılgan yapar:

• Teslimat çok hızlı olduğu için sahte kart kullanan biri, gerçek kart sahibi fark etmeden kodu tüketebilir
• İtiraz sürecinde sunulacak "somut teslimat kanıtı" kavramı belirsizdir — bir kargo fişi yoktur, sadece bir veritabanı kaydı vardır
• Kod bir kez kullanıldıysa (özellikle oyun içi bakiye veya hesap yüklemesi) geri alınamaz, zarar kesinleşir

Bu üç özellik bir araya geldiğinde, sistemli kayıt tutmayan bir site için chargeback yalnızca "arada bir olan zarar" değil, kâr marjını doğrudan tehdit eden yapısal bir risk haline gelir. Üstelik zarar iki katmanlı işler: bir yandan satılan kodun bedeli geri alınır, diğer yandan ödeme sağlayıcısı çoğu zaman işlem başına ayrı bir chargeback ceza ücreti keser. Yani tek bir kötü niyetli sipariş, hem ürün maliyetini hem ekstra bir bedeli birden kaybettirebilir.

Bu yapısal kırılganlığı büyüten bir başka etken de e-pin ürünlerinin kolay nakde çevrilebilir olmasıdır. Çalıntı bir kartla alınan Steam bakiyesi ya da oyun içi para, dakikalar içinde başka bir hesaba aktarılabilir veya üçüncü şahıslara satılabilir. Bu da dolandırıcılık girişimlerinin fiziksel ürünlere göre e-pin sektörünü orantısız şekilde hedef almasına yol açar — sektörün kendisi, doğası gereği "yüksek riskli" kategoride değerlendirilir.

Hangi sipariş türleri ters ibraz riskini asıl büyütüyor?

Her chargeback aynı ağırlıkta değildir. Deneyimler gösteriyor ki risk belirli sipariş kalıplarında yoğunlaşıyor. Script bu kalıpları otomatik tanıyabiliyorsa, insan gözünün kaçırdığı işlemleri de yakalar.

• Kayıt olur olmaz, hiç gezinme yapmadan doğrudan yüksek tutarlı ürüne yönelen "hızlı geçiş" siparişleri
• Aynı IP'den kısa aralıklarla farklı kart bilgileriyle denenen art arda ödemeler
• Fatura adresi ile kart bankasının ülkesi arasında tutarsızlık (örneğin yurt dışı banka, yerel IP)
• Gece saatlerinde, mobil veri üzerinden ve VPN/proxy izi taşıyan bağlantılardan gelen büyük tutarlı alımlar
• Aynı cihaz parmak izinden farklı e-posta ve kart kombinasyonlarıyla kısa sürede tekrarlanan denemeler

Bu sinyallerin tek tek görülmesi normal olabilir; asıl anlam birden fazlasının aynı siparişte üst üste binmesinden çıkar. Bu yüzden manuel takip yerine kural tabanlı bir puanlama mantığı gerekir.

Ürün türü de riski değiştiren bir faktördür. Örneğin doğrudan bakiye yüklemesi ya da anlık hesap içi para transferi yapan ürünler, fiziksel bir teslimat adımı olmayan işlemler oldukları için sahte kart kullanan biri tarafından tercih edilme ihtimali daha yüksektir. Buna karşılık kod bazlı, tekil ve tek kullanımlık ürünlerde (belirli bir oyun anahtarı gibi) kötüye kullanım biraz daha iz bırakır, çünkü kod tekil olduğu için kullanım anı ve kaynağı net şekilde takip edilebilir. Bu ayrımı bilen bir satıcı, riskli kategorideki ürünlerde daha sıkı kural uygulayabilir.

Sipariş anında hangi izler tutulmazsa itiraz sürecinde elde hiçbir şey kalmaz?

Chargeback bankaya ulaştığında satıcının elinde somut kayıt yoksa, itiraz süreci baştan kaybedilmiş sayılır. Bir siparişin "gerçekten o kişi tarafından, o an, o kodla teslim alındığını" gösterecek asgari kayıt seti şudur:

• Sipariş anındaki IP adresi, tarayıcı/cihaz bilgisi ve zaman damgası
• Ödeme sağlayıcısından dönen işlem referans numarası ve onay kodu
• Hangi kodun, hangi sipariş numarasına, hangi saniyede teslim edildiğine dair değiştirilemez bir log satırı
• Kullanıcı girişindeyse hesap oluşturma tarihi, önceki sipariş geçmişi ve doğrulanmış e-posta/telefon bilgisi
• Varsa müşteri destek yazışması (kod çalışmıyor şikâyeti geldiyse, bu da ayrı bir kanıt parçasıdır)

Bu kayıtların tek tek dosyalarda değil, sipariş kaydına bağlı tek bir "kanıt paketi" halinde tutulması, itiraz yazılırken saatler kaybetmeyi önler. Ödeme sağlayıcıların itiraz formları genelde 3-7 gün gibi kısa sürelerle sınırlıdır; kanıt dağınıksa bu süre kolayca kaçırılır.

Burada sık yapılan bir hata, logların yalnızca sunucu seviyesinde (Apache/Nginx access log gibi) tutulup uygulama katmanında sipariş numarasıyla ilişkilendirilmemesidir. Sunucu logu haftalar sonra rotasyona girip silinebilir ya da binlerce satır arasında ilgili kaydı bulmak saatler alabilir. Kanıtın değeri, ona ne kadar hızlı ve eksiksiz ulaşılabildiğiyle doğru orantılıdır; bu yüzden logun sipariş tablosuna gömülü, kalıcı ve aranabilir olması, sunucu logundan çok daha değerlidir.

Otomatik teslimat chargeback riskini azaltır mı, yoksa büyütür mü?

Bu soru ilk bakışta çelişkili görünür: 7/24 otomatik teslimat hem e-pin işinin temel vaadidir hem de "kodun anında tüketilmesi" riskini büyüten şeydir. Gerçek cevap ise otomasyonun kendisinde değil, otomasyonun neyi otomatikleştirdiğinde saklıdır.

Kötü kurulmuş bir otomasyon, ödeme onaylanır onaylanmaz hiçbir kontrolden geçmeden kodu ekrana basar — hız vardır ama filtre yoktur. İyi kurulmuş bir otomasyon ise iki katmanlıdır: ödeme sağlayıcısının kendi risk skorunu (3D Secure durumu, banka onay kodu, IP-ülke uyuşmazlığı gibi) okur ve yalnızca "temiz" görünen siparişleri anında teslim eder; şüpheli görünenleri ise otomatik olarak kısa bir onay adımına yönlendirir. Bu adım kullanıcı için birkaç dakikalık bir bekleme demektir, ama satıcı için chargeback'in önüne geçebilecek tek fren noktasıdır.

Yani doğru soru "otomatik teslimatı kapatalım mı" değil, "otomasyona hangi filtreyi ekliyoruz" sorusudur.

Şüpheli bir siparişi kod tüketilmeden nasıl yakalarsınız?

Chargeback'i tamamen sıfıra indirmek mümkün değildir, ama kodun elden çıkmasından önce yakalanan her şüpheli sipariş, gerçekleşmiş bir zararı önler. Bunun için scriptin sipariş akışına şu kontrol noktalarının yerleştirilmesi gerekir:

• Eşik tabanlı bekletme: Belirlenen tutarın üzerindeki ilk siparişler (özellikle yeni üyelerden gelenler) otomatik onaya düşer
• Hız kontrolü: Aynı kullanıcı/IP kısa sürede art arda birden fazla başarısız veya art arda kart deneyip başarılı olmuşsa uyarı üretilir
• Coğrafi tutarsızlık kontrolü: Kartın çıkış ülkesi ile bağlantı IP'sinin ülkesi örtüşmüyorsa bayrak konur
• Yeni hesap kısıtlaması: Kayıt olduğu gün yüksek tutarlı ilk sipariş veren hesaplar farklı bir kuyruğa alınır
• Bayi/alt kullanıcı gözetimi: Çok seviyeli bayi sisteminde bir bayinin altındaki anormal hareketlilik ana panelden görülebilir olmalı

Bu kontrollerin hepsi aynı anda sert şekilde uygulanırsa gerçek müşterileri de yorar; asıl marifet, kuralları sipariş geçmişine ve ürün riskine göre kademelendirmektir. Düşük tutarlı, kayıtlı ve geçmişte sorunsuz sipariş vermiş bir müşteri anında teslimat almaya devam ederken, riskli profildeki sipariş bir filtreden geçer.

Çok seviyeli bayi sistemi kullanan sitelerde bu konu bir kat daha karmaşıklaşır. Bayiler kendi müşterilerine kendi arayüzlerinden satış yaptığı için, ana sitenin göremediği bir sipariş trafiği oluşur. Bir bayinin altında anormal derecede yüksek iptal/itiraz oranı varsa, bu yalnızca o bayinin cüzdan bakiyesini değil, ana hesabın ödeme sağlayıcı nezdindeki genel risk skorunu da etkiler. Bu yüzden bayi bazlı chargeback/iptal oranının ana panelden tek bakışta görülebilmesi, büyüyen bir bayi ağında ihmal edilmemesi gereken bir kontrol noktasıdır.

Chargeback geldiğinde itiraz sürecini kim, nasıl yönetmeli?

Önlemler ne kadar iyi kurulursa kurulsun, bir gün chargeback bildirimi mutlaka gelir. Bu noktada asıl belirleyici olan hız ve düzendir — çünkü ödeme sağlayıcılarının itiraz pencereleri kısadır ve geç kalınan ya da eksik belgeyle yapılan itirazlar otomatik reddedilir.

• Bildirim geldiği anda ilgili sipariş kaydına doğrudan erişilebilmeli, aramakla vakit kaybedilmemeli
• Kanıt paketi (IP, cihaz, teslimat zamanı, ödeme referansı) tek ekrandan dışa aktarılabilmeli
• İtiraz sonucu ne olursa olsun (kabul/red), ilgili kullanıcı/kart/IP otomatik olarak izleme listesine alınmalı
• Chargeback oranı belli bir eşiği aştığında (ödeme sağlayıcılar genelde %1 civarını kritik eşik sayar) ödeme yönteminin risk ayarları gözden geçirilmeli

Sürecin sahibi kim olursa olsun (site sahibi, destek ekibi ya da dış muhasebe), elindeki verinin dağınık değil tek bir kayıt etrafında toplanmış olması, itirazı kazanma ihtimalini doğrudan yükseltir.

Bir diğer önemli nokta, itiraz kazanılsa da kaybedilse de o siparişten çıkan dersin sisteme geri beslenmesidir. Kazanılan bir itiraz "bu profil güvenli" demek değildir, sadece o seferlik yeterli kanıt bulunduğu anlamına gelir. Kaybedilen bir itiraz ise genelde kural setinde bir boşluk olduğunu gösterir — belki eşik çok yüksek ayarlanmıştı, belki yeni bir dolandırıcılık kalıbı daha önce görülmemişti. Chargeback yönetimini tek seferlik bir "yangın söndürme" işi değil, sürekli güncellenen bir kural listesi olarak ele alan siteler, zamanla oranlarını gözle görülür şekilde düşürür.