E-Pin & Dijital Ürün Satışı Rehberi: Kod Havuzu, Otomatik Teslimat, Riskler

E-Pin & Dijital Ürün Satışı Rehberi: Kod Havuzu, Otomatik Teslimat, Riskler

10 Şubat 2026 8 dk okuma 159 görüntülenme

E-pin satışında asıl ürün “kod” değil, teslimat deneyimidir

Dijital ürün satan bir sitede müşteri tek bir şey bekler: ödeme yaptıktan sonra kodun hızlı ve sorunsuz gelmesi. Burada lojistik yok, kargo yok. Ama “teslimat” var ve müşteri gözünde teslimat hatası, fiziksel üründe kargonun kaybolması kadar yıkıcıdır.

Bu yüzden e-pin/dijital kod işinde altyapı; klasik B2C’den daha kritik bir rol oynar. Stok hatası, aynı kodun iki kez satılması, gecikmeli teslimat, fraud ve chargeback… Hepsi birkaç saatte itibarı zedeleyebilir.

Bu yazının tek odağı: Kod havuzu + otomatik teslimat + risk yönetimi üçlüsünü doğru kurmak.

1) Kod havuzu (code pool) nedir? Neden şart?

Kod havuzu; satılabilir dijital kodların, güvenli bir şekilde saklandığı ve satış anında doğru kodun seçilip müşteriye verildiği sistemdir. “Excel’den kopyala yapıştır” mantığıyla başlayan işler, ölçek büyüyünce mutlaka sorun çıkarır.

Kod havuzu neden şarttır?

  • Tekrarlı satışın önlenmesi: Aynı kodun iki kez satılması en kritik hatadır.
  • Stok doğruluğu: “Var görünüp yok” çıkması dijitalde daha sert tepki üretir.
  • Otomasyon: Gece-gündüz satış; manuel teslimatla sürdürülemez.
  • Denetlenebilirlik: Hangi koda ne oldu? Kim gördü? Ne zaman teslim edildi?

2) Dijital stok gerçekte 3 durumdan oluşur

Fiziksel stokta “var/yok” çoğu zaman yeter. Kod stokunda ise daha net bir model gerekir:

  • Available (Müsait): Satışa hazır, hiç kullanılmamış kod.
  • Reserved (Rezerve): Sipariş oluşturuldu ama ödeme kesinleşmedi; kod geçici olarak tutuluyor.
  • Delivered/Sold (Teslim edildi/Satıldı): Kod müşteriye verildi (geri dönüşü zordur).

Bu ayrım, özellikle ödeme hatası/iptal/chargeback senaryolarında hayat kurtarır.

3) Otomatik teslimat (auto delivery) nasıl çalışır?

Basit gibi görünür: “ödeme al, kod ver”. Ama güvenli ve hatasız olması için akışın doğru parçalanması gerekir.

Önerilen temel akış

  • 1) Sipariş oluştur: Kullanıcı ürünü seçer, sipariş kaydı açılır.
  • 2) Kod rezervasyonu: Siparişe uygun 1 adet kod “Reserved” yapılır (atomik işlem).
  • 3) Ödeme tamamlanır: Provider’dan “başarılı” callback gelir.
  • 4) Teslimat: Rezerve kod “Delivered” olur ve kullanıcıya gösterilir / e-posta ile iletilir.
  • 5) Loglama: Kod teslim edildiği an kayıt altına alınır (kim, ne zaman, hangi IP/cihaz).

Neden “rezerv” adımı şart?

Çünkü aynı anda iki kişi aynı ürünü satın alabilir. Rezerv adımı yoksa “stok var” sanıp aynı kodu iki kez dağıtabilirsin. Ayrıca ödeme başarısız olduğunda kodun boşa gitmesini de engellersin.

4) Aynı kodu iki kez satmamak için altın kurallar

  • Atomik seçim: Kod seçimi ve durum güncellemesi tek işlem gibi çalışmalı.
  • Tekil kısıt: Kodun bir siparişe bir kez bağlanması garanti olmalı.
  • Idempotent callback: Ödeme sağlayıcı aynı bildirimi 2 kez atabilir; sistem “ikinciyi” tekrar teslimat yapmadan yutmalı.
  • Zaman aşımı: Rezerve kodlar ödeme gelmezse otomatik “Available”a dönmeli (örn. 15–30 dk).

5) Riskler: Dijital ürünlerde en sık patlayan 6 senaryo

1) Fraud (çalınmış kart / hesap ele geçirme)

Dijital ürün hızlı teslim edildiği için fraud’da “geri alma” şansın düşüktür. Bu yüzden risk yönetimi şart.

2) Chargeback

Ödeme iadesi/itiraz geldiğinde kod çoktan tüketilmiş olabilir. Bu yüzden satın alma öncesi doğrulama ve loglar önemli.

3) Stok tutarsızlığı

Panelde “stok var” görünüp teslimat yapılamaması, müşteri güvenini hızla yıkar.

4) Callback gecikmesi / kopması

Ödeme tamamlanır ama callback gelmezse, kullanıcı kodu göremez. Bu durumda “ödeme doğrulama + yeniden deneme” mekanizması gerekir.

5) Kodların sızması

Kodlar admin panelde, Excel’de, e-postada dolaşırsa sızma riski artar. Erişim kontrolü ve maskeleme gerekir.

6) İade politikası krizi

“Kod görüldü” durumunda iade tartışması çıkar. Politikayı en baştan net koymak gerekir (Gün 12’de detaylı).

6) Pratik önlem seti: KOBİ için uygulanabilir güvenlik kalkanı

  • 3DS zorunluluğu (risk bazlı): yeni müşteri, yüksek tutar, hızlı teslimat
  • Limitler: kullanıcı başı adet limiti, saatlik/günlük limit
  • Hız freni: şüpheli siparişte teslimatı geciktirme/manuel onay
  • Loglar: sipariş, ödeme, teslimat, IP/cihaz kaydı
  • Maskeleme: admin panelde kodu tam gösterme (yetkili rol harici)
  • Monitoring: stok kritik seviyede uyarı, başarısız teslimat alarmı

7) Müşteri deneyimi: Hız kadar “şeffaflık” da satış getirir

E-pin müşterisi sabırsızdır. Kod 30 saniye gecikse bile destek yazabilir. Bu yüzden deneyimde şunlar çok etkili olur:

  • Ödeme sonrası “teslimat hazırlanıyor” ekranı ve durum göstergesi
  • Kodu nereden göreceğini net anlatan yönlendirme (panel, e-posta)
  • Bir sorun olursa hızlı çözüm kanalı (ticket/WhatsApp)

8) Hızlı kontrol listesi (go-live öncesi)

  • Kod havuzu durumları (Available/Reserved/Delivered) net mi?
  • Rezerv süreleri ve otomatik geri bırakma çalışıyor mu?
  • Callback idempotent mi? (aynı bildirim 2 kez gelince sorun çıkmıyor mu?)
  • Stok 0 iken satış engelleniyor mu?
  • Loglar ve yetkilendirme hazır mı?
  • Riskli sipariş limitleri var mı?

Kapanış

E-pin/dijital kod işinde rekabet “kim daha ucuz”dan çok “kim daha sorunsuz teslim eder”e kayar. Kod havuzu mantığını doğru kurup otomatik teslimatı güvenli hale getirdiğinde, hem müşteri memnuniyeti artar hem de fraud/chargeback gibi pahalı riskler kontrol altına girer.