Çoğu e-pin işletmesi bir gün şu cümleyi söyler: "Stok eksildi ama satış yok." Ya da tersi: "Satış var ama para gelmedi." İlk tepki hep aynı olur, siteye saldırıldığı düşünülür ve sunucu firewall'ı sıkılaştırılır. Gerçekte olayların büyük kısmı dışarıdan gelen bir saldırı değildir; içeride fark edilmeden biriken küçük anormalliklerin toplamıdır. İade zinciri, aynı kartla farklı hesaplardan alım, bir personelin yetkisini aşan kod görüntülemesi, tekrar tekrar denenen kupon kodları.
Bunların hiçbiri tek başına alarm çaldırmaz. Ancak hepsi ortak bir şeye ihtiyaç duyar: kayıt. Elinde kayıt yoksa ne olduğunu öğrenmen imkânsız, tekrar etmesini önlemen ise şansa bağlı. İşin acı tarafı, çoğu e-pin satış scriptinde log denildiğinde akla sadece sunucunun erişim kayıtları gelir; oysa e-pin işinde kritik olan uygulama içi olaylardır. Bu yazıda hangi olayların kaydedilmesi gerektiğini, kaydın hangi alanları içermesi gerektiğini ve ham logu şüpheli işlem tespitine çeviren basit kuralları anlatıyorum.
Sunucu logu neden yetmiyor, uygulama logu ne anlatır?
Erişim logu sana kimin hangi adrese istek attığını söyler. Bu, bir saldırı analizinde işe yarar ama ticari bir ihtilafta neredeyse hiçbir şey ifade etmez. Müşteri "kodu almadım" dediğinde bilmen gereken şey şudur: sipariş hangi saniyede ödendi, hangi stok kaydı ayrıldı, kod hangi kanaldan hangi adrese gönderildi, kullanıcı panelden kaç kez görüntüledi.
Uygulama logu bu soruların cevabını tutar. Her kayıt en az beş alan içermeli: olay türü, zaman damgası (saat dilimiyle birlikte), aktör (kullanıcı ya da personel kimliği), hedef nesne (sipariş, stok kaydı, bakiye hareketi) ve bağlam (IP, oturum kimliği, tutar, önceki-sonraki değer). Değer değişikliklerinde "öncesi ve sonrası" alanı altın değerindedir; bir bakiyenin elle artırıldığını ancak bu sayede görürsün. Ciddi bir dijital ürün satış scripti bu kaydı ayrı bir tabloda, uygulama mantığından bağımsız biçimde tutar; çünkü işlem iptal olsa bile kaydın kalması gerekir.
| Olay | Neden kritik | Tutulacak ek alan | Önerilen saklama |
|---|---|---|---|
| Giriş denemesi (başarılı/başarısız) | Hesap ele geçirme tespiti | IP, cihaz parmak izi | 6-12 ay |
| Sipariş oluşturma | İhtilafın başlangıç noktası | Tutar, kanal, sepet içeriği | 2 yıl |
| Ödeme durum değişimi | Sahte "ödedim" iddiaları | Sağlayıcı yanıtı, işlem kimliği | 10 yıl (mali) |
| Stok ayırma ve teslim | "Kod gelmedi" itirazı | Stok kaydı, gönderim kanalı | 2 yıl |
| Kod açığa çıkarma | İç suistimal tespiti | Personel kimliği, gerekçe | 2 yıl |
| Bakiye/cüzdan hareketi | Elle şişirme tespiti | Öncesi, sonrası, sebep | 10 yıl |
| İade ve iptal | İade zinciri suistimali | Onaylayan, gerekçe | 10 yıl |
| Yetki ve rol değişikliği | Sessiz yetki yükseltme | Eski rol, yeni rol | 3 yıl |
| Fiyat ve ürün düzenleme | Yanlış fiyattan boşaltma | Öncesi, sonrası | 3 yıl |
| Kupon denemesi | Kupon kaba kuvvet taraması | Denenen kod, sonuç | 6 ay |
| Toplu dışa aktarma | Veri sızdırma | Satır sayısı, filtre | 3 yıl |
Şüpheli işlem nasıl anlaşılır? Tek sinyal yoktur, örüntü vardır
Dolandırıcılık tespitinde acemi yaklaşım tek bir kurala yapışmaktır: "aynı IP'den üç sipariş gelirse durdur." Bu tür katı kurallar gerçek müşterileri de engeller, çünkü aynı işyeri ağından ya da mobil operatör NAT'ı arkasından yüzlerce kişi çıkabilir. İşe yarayan yaklaşım, birden fazla zayıf sinyali birleştirip bir risk puanı üretmektir.
Pratikte yüksek değerli sinyaller şunlar: hesabın yaşı ile ilk sipariş tutarı arasındaki uçurum, e-posta alan adının tek kullanımlık servislere ait olması, kart ile fatura ülkesinin uyuşmaması, ödemeden teslimata kadar geçen sürenin anormal kısalığı, aynı cihaz parmak izinden farklı hesaplara giriş, aynı kartın kısa aralıkla farklı hesaplarda görünmesi ve gece saatlerinde yüksek tutarlı tek seferlik alım. Her sinyale bir ağırlık ver, toplam puan bir eşiği geçtiğinde siparişi otomatik teslim etmek yerine manuel onaya al. Bu ince ayar, bir e-pin yazılımı kurulumunda kârı doğrudan etkileyen en az anlaşılan parametredir: eşiği çok düşük tutarsan satışı boğar, çok yüksek tutarsan chargeback yersin.
E-pin sitelerinde kaydın ortaya çıkardığı kayıp kalemleri
- Chargeback ve sahte ödeme iddiası 38%
- İç suistimal ve yetki aşımı 27%
- İade zinciri ve kupon istismarı 22%
- Operasyonel hata, yanlış teslim 13%
İç suistimali fark etmenin tek yolu: kim hangi kodu gördü?
Dışarıdan gelen risk konuşulurken içerideki risk hep görmezden gelinir. Oysa e-pin işinde personel, tanım gereği paraya eşdeğer veriye erişir. Destek elemanı bir kodu görebiliyorsa onu kopyalayabilir de. Bunu engellemenin yolu güveni artırmak değil, görünürlüğü artırmaktır.
İşleyen düzen şöyle kurulur: kodlar panelde varsayılan olarak maskeli görünür; tam kodu görmek ayrı bir işlem, ayrı bir yetki ve kısa bir gerekçe alanı gerektirir; her açığa çıkarma kaydı personel kimliği, sipariş numarası ve zamanla loglanır; haftalık bir rapor "kim kaç kod açtı" listesini yönetime gösterir. Bu düzen kurulduğunda suistimal çoğunlukla hiç başlamaz, çünkü izlenebilir olduğu bilinir. Ayrıca personel ayrıldığında hesabın kapatılmasının yanı sıra son otuz günde açtığı kodların listesini almak da bir dakikalık iştir. Bu tür bir denetim izi olmayan bir dijital ürün satış yazılımı ile çalışıyorsan, bir suistimal yaşandığında kimin yaptığını asla ispat edemezsin.
Kaydın değeri, değiştirilemez olmasından gelir. Log tablosunda güncelleme ve silme yetkisini uygulama kullanıcısından al, yalnızca ekleme bırak. Kritik olayları ayrıca ikinci bir hedefe (ayrı sunucu ya da bildirim kanalı) kopyala. Ve en önemlisi: okumadığın log yoktur, haftada bir on dakikalık göz gezdirme alışkanlığı kur.
Alarm kurmadan log tutmak neden işe yaramaz?
Onlarca gigabayt kayıt biriktirip hiç bakmamak, sektörde en yaygın hâl. Log ancak bir olay olduğunda seni uyandırdığında değer üretir. Bunun için karmaşık bir sisteme ihtiyaç yok; üç seviyeli basit bir eşik yapısı çoğu işletmeye yeter.
Anlık bildirim isteyen olaylar: tek işlemde belirli tutarın üzerinde satış, yönetici rolü verilmesi, elle bakiye ekleme, tek seferde yüzden fazla kod dışa aktarma, kısa süre içinde çok sayıda başarısız yönetici girişi. Günlük özet isteyen olaylar: iade oranı, manuel onaya düşen sipariş sayısı, açığa çıkarılan kod sayısı, stok-satış farkı. Haftalık inceleme isteyen olaylar: en çok işlem yapan personel, tekrarlayan cihaz parmak izleri, kupon deneme yoğunluğu. Bu üç katman kurulduğunda sürprizler biter; sorunlar büyümeden önce küçük sinyaller olarak masaya gelir. Pinova tarafındaki denetim izi ve risk kuralları tam bu mantıkla tasarlandı, ayrıntılarına özellikler bölümünden, paket farklarına ise fiyat sayfasından bakabilirsin.
Kayıtlarını ihtilafta kullanabilir hale nasıl getirirsin?
Bir chargeback itirazında ya da tüketici başvurusunda ekran görüntüsü yeterli olmaz; tutarlı bir zincir istenir. Sipariş, ödeme onayı, stok ayırma, teslim ve müşterinin erişim kaydı aynı zaman çizgisinde ve aynı sipariş numarasıyla bağlanmalı. Zaman damgalarının tek bir saat dilimine sabitlenmesi bu yüzden önemli; sunucu UTC, panel yerel saat gösteriyorsa itirazda ciddi biçimde zorlanırsın.
İkinci gereklilik dışa aktarılabilirlik. Belirli bir siparişin tüm olay zincirini tek tıkla PDF veya CSV olarak alabiliyor olmalısın. Üçüncüsü bütünlük: kaydın sonradan yazılmadığını göstermek için ardışık numara ya da zincirleme özet kullanmak ispat gücünü belirgin şekilde yükseltir. Bu üç unsuru sağlayan bir sistemde ihtilaf dosyaları kazanılır; sağlamayan sistemde ise haklı olsan bile ispat edemediğin için ödeme yaparsın. Basitçe söylemek gerekirse: iyi tutulmuş kayıt, ticari bir sigorta poliçesidir.
Kör noktalarını kapat, kaybını gör
Denetim izi, risk puanlama ve maskeli kod görüntüleme mekanizmaları hazır gelen bir altyapıyla sat.
Log tutmak sunucuyu yorar mı?
Doğru tasarlanırsa hayır. Kritik olaylar satırlık kayıtlardır ve ayrı bir tabloda indeksli tutulur. Yük yaratan şey her isteği ayrıntılı kaydetmeye çalışmaktır; olay bazlı yaklaşım ise gün içinde binlerce satır bile üretmez.
Logları ne kadar süre saklamalıyım?
Olay türüne göre değişir. Güvenlik amaçlı erişim ve giriş kayıtları için altı-on iki ay yeterliyken, mali sonuç doğuran ödeme, iade ve bakiye hareketleri yasal saklama süreleri boyunca tutulmalıdır.
Şüpheli işlemi otomatik iptal etmeli miyim?
Hayır, iptal etmek yerine manuel onaya almak daha kârlıdır. Otomatik iptal yanlış pozitiflerde gerçek satışı kaybettirir; onay kuyruğu ise riski teslimattan önce insan gözüyle değerlendirme fırsatı verir.
Küçük ölçekte bu kadar kayda gerek var mı?
Ölçek küçükken kurmak en kolay, en ucuz ve en faydalı zamandır. Hacim büyüdükten sonra geçmişe dönük kayıt üretemezsin; ilk ihtilafta eksik zincirin bedelini doğrudan kasadan ödersin.
| Kontrol | Nerede bakılır | Geçer ölçüt | Durum |
|---|---|---|---|
| Olay listesi | Log tablosu şeması | 11 kritik olay kayıtlı | ☐ |
| Aktör kimliği | Kayıt alanları | Her olayda kullanıcı/personel var | ☐ |
| Öncesi-sonrası | Bakiye ve fiyat kayıtları | Eski ve yeni değer saklı | ☐ |
| Saat dilimi | Zaman damgaları | Tek dilime sabit, tutarlı | ☐ |
| Değiştirilemezlik | Veritabanı yetkileri | Sadece ekleme yetkisi | ☐ |
| Maskeli kod | Destek ekranı | Varsayılan maskeli, yetkili açılış | ☐ |
| Risk puanı | Sipariş akışı | Çok sinyalli, eşikli onay kuyruğu | ☐ |
| Anlık alarm | Bildirim kanalı | Yüksek tutar ve rol değişimi bildirimi | ☐ |
| Günlük özet | Panel raporu | İade, onay, stok farkı metrikleri | ☐ |
| Dışa aktarma | Sipariş detayı | Olay zinciri tek tıkla alınabiliyor | ☐ |
Bu on maddenin kaçında geçer not aldığın, bir sonraki ihtilafta ne kadar rahat olacağını doğrudan belirler; eksikleri kapatmak çoğu zaman yeni bir yazılım değil, doğru ayarlanmış bir akış gerektirir. Denetim izinin nasıl göründüğünü, risk puanına düşen bir siparişin onay kuyruğunda nasıl beklediğini ve olay zincirinin sipariş detayında nasıl listelendiğini kendi elinle denemek istersen canlı demo üzerinden birkaç test siparişi geçirip kayıtların nasıl biriktiğini izleyebilirsin.