E-pin satışı dışarıdan bakınca basit görünür: müşteri öder, kod gider. Ama işin “sağlam” çalışması için arka tarafta iyi tasarlanmış bir altyapı gerekir. Çünkü dijital ürünlerde teslimat anlık, hata toleransı düşük, sahtekârlık riski yüksek ve müşteri beklentisi çok nettir: “Ödedim, kodum nerede?”
Bu yazıda, bir e-pin satış platformunun perde arkasını uçtan uca anlatacağım: ödeme onayı nasıl doğrulanır, kod nasıl ayrılır, teslimat nasıl yapılır, stok bitince ne olur, tedarikçiden otomatik kod çekme nasıl tasarlanır ve sistem nasıl güvenli kalır.
İçindekiler
- 1) Tipik mimari: Hangi parçalar var?
- 2) Satın alma akışı: “Buy” tıklanınca ne olur?
- 3) Kod ayırma (reservation) mantığı
- 4) Otomatik teslimat: Ekran + e-posta + hesap sayfası
- 5) Stok/kod yönetimi: Veritabanında nasıl tutulmalı?
- 6) Tedarikçi entegrasyonu: API ile otomatik kod çekme
- 7) Güvenlik ve fraud: E-pin’de kritik kontroller
- 8) Log, izleme ve hata senaryoları
- 9) Uygulama kontrol listesi
- SSS
1) Tipik mimari: Hangi parçalar var?
En basit haliyle e-pin altyapısında şu bileşenleri görürsün:
- Mağaza (Web/Mobil): Ürün listeleme, sepet, ödeme ekranı.
- Ödeme katmanı: Sanal POS / ödeme aracısı (callback/webhook ile doğrulama).
- Sipariş servisi: Siparişi oluşturur, durum yönetir.
- Kod servis/stok servisi: Kodları saklar, ayırır, satar, iade eder.
- Teslimat servisi: Kodları kullanıcıya gösterir ve e-posta/SMS gönderir.
- Fraud & güvenlik: Şüpheli işlemleri yakalar, rate limit, IP/device kontrolü.
- Tedarikçi entegrasyonu: Kodları API/CSV ile sisteme taşır.
- Log/izleme: “Kod gitti mi?” sorusunun cevabı burada.
2) Satın alma akışı: “Buy” tıklanınca ne olur?
Sağlam bir akış genelde şöyle çalışır:
- Sipariş taslağı oluşur (Pending/Created).
- Ödeme başlatılır (redirect veya ödeme formu).
- Ödeme sağlayıcı callback/webhook ile “ödendi” bilgisini gönderir.
- Platform ödeme doğrulamasını yapar (signature/transaction id kontrolü).
- Kod ayırma (reserve) → satma (consume) adımları çalışır.
- Teslimat yapılır (ekranda göster + e-posta + hesap sayfası).
- Sipariş Completed olur; loglar kapanır.
Kritik nokta: “Ödeme başarılı” bilgisi ekrandan değil, mutlaka sunucu tarafında doğrulanmış webhook/callback ile kesinleşmeli. Aksi halde sahte “başarılı” dönüşleriyle kod sızdırma riski doğar.
3) Kod ayırma (reservation) mantığı
Dijital ürünlerde en büyük problem şu: Aynı kodun iki kişiye gitmemesi. Bunu çözmek için “ayırma” mantığı kullanılır.
Reservation neden şart?
- Ödeme onayı geldiği anda sistem yoğun olabilir.
- Parça parça çalışan servislerde (ödeme → sipariş → stok) tutarsızlık çıkabilir.
- Aynı ürün için aynı anda 100 kişi ödeme yaparsa “ilk gelen alır” kuralları net olmalı.
İyi bir model
- AVAILABLE: Satılabilir kod
- RESERVED: Siparişe ayrılmış ama henüz teslim edilmemiş
- SOLD: Satıldı ve teslim edildi
- EXPIRED/FAILED: Rezerve edildi ama ödeme iptal/timeout oldu
Öneri: Kod ayırma işlemi veritabanında transaction içinde yapılmalı. “Bir kod seç → reserve et → siparişe bağla” adımı atomik olmalı. Böylece aynı kodun iki kez ayrılması engellenir.
4) Otomatik teslimat: Ekran + e-posta + hesap sayfası
“Kod teslimatı” sadece e-posta atmak değildir. E-pin’de en iyi deneyim genelde 3 kanallı olur:
- Anlık ekran teslimatı: Ödeme sonrası teşekkür sayfasında kod(lar) görünür.
- Hesabım → Siparişler: Kodlar sonradan tekrar erişilebilir (kayıp mail = panik yok).
- E-posta (opsiyonel SMS): Kullanıcıya kayıt bırakır, ama tek kaynak olmamalı.
Güven notu: Kodları e-postaya “çıplak” basmak yerine, bazı senaryolarda hesap sayfasında göster + mailde yönlendirme yaklaşımı daha güvenlidir. Özellikle yüksek riskli ürünlerde bu yöntem kod sızdırmayı azaltır.
5) Stok/kod yönetimi: Veritabanında nasıl tutulmalı?
Stok, burada fiziksel adet değil kod havuzu demek. Sağlam bir tasarım şunları hedefler:
- Kodun kaynağı (hangi tedarikçi / hangi batch)
- Kodun durumu (available/reserved/sold)
- Hangi siparişe gittiği (OrderId)
- Ne zaman ayrıldı / satıldı (timestamp)
- İzlenebilirlik (audit/log)
Basit bir mantık şeması
- Products (ürün)
- CodeBatches (yükleme paketi / tedarikçi partisi)
- Codes (tekil kod satırları)
- Orders / OrderItems (sipariş ve kalemler)
Stok bittiğinde ne olur? İki yaklaşım var:
- Önceden stokla: Kod yoksa satış kapalı (net, güvenli).
- On-demand çek: Satın alma anında tedarikçi API’den kod çekmeye çalış (hızlı ama riskli).
Benim net fikrim: Yeni başlayanlar için “önceden stokla” daha az kriz çıkarır. On-demand çekim, ancak tedarikçi API’si gerçekten stabilse ve iyi bir retry/timeout yönetimin varsa yapılmalı.
6) Tedarikçi entegrasyonu: API ile otomatik kod çekme
E-pin işinde büyümenin kilidi genelde burada: Kodları elle yüklemek bir yere kadar. Sonra otomasyon şart oluyor.
2 temel model
- Scheduled Sync: Saatlik/günlük kod çek, havuza ekle (daha stabil).
- Just-in-time: Satış anında çek, anında teslim et (hızlı ama hassas).
Sağlam entegrasyonun kuralları
- Idempotency: Aynı istek iki kez gelirse iki kod yazma/satma.
- Retry politikası: 3 kez dene, sonra kuyruğa al ve operatöre bildir.
- Timeout: Tedarikçi yavaşsa siparişi “beklemede” tut, kullanıcıyı doğru bilgilendir.
- Batch izleme: Hangi partiden kaç kod geldi, kaç satıldı?
Kullanıcıya söylemen gereken gerçek şu: “Kodunuz 30 saniye içinde gelmezse endişelenmeyin; siparişiniz güvenli, kod birazdan hesabınıza düşecek.” Bu cümle doğru kurgulanırsa support yükünü ciddi azaltır.
7) Güvenlik ve fraud: E-pin’de kritik kontroller
Dijital ürünlerde fraud riski fiziksele göre daha yüksek. Çünkü teslimat anlık ve geri almak zor. Bu yüzden minimum şunlar olmalı:
- Webhook doğrulama: Signature doğrulaması olmadan “ödendi” kabul etme.
- Rate limit: Aynı IP/cihazdan seri denemeleri yavaşlat.
- Şüpheli sepet kuralları: Çok yüksek tutar/çoklu deneme/çoklu kart gibi durumlar.
- Admin panel güvenliği: 2FA, IP kısıtı, detaylı audit log.
- Kod saklama güvenliği: Veritabanında erişim kısıtları, rol bazlı yetki.
Etik ve yasal hatırlatma: Kodların yetkili/legit kaynaklardan tedariki, faturalama ve iade politikası netliği bu işin “güven” tarafının temelidir. Kısa vadeli hileler uzun vadede markayı bitirir.
8) Log, izleme ve hata senaryoları
E-pin sisteminde en kritik destek soruları şunlar olur:
- “Ödedim ama kod gelmedi.”
- “Kod hatalı/çalışmıyor.”
- “Siparişim beklemede kaldı.”
Bu yüzden her sipariş için en az şu kayıtlar tutulmalı:
- Ödeme provider transaction id
- Webhook geldi mi? Ne zaman geldi?
- Kaç kod ayrıldı? Hangi kodlar? (maskeli gösterebilirsin)
- E-posta gönderildi mi? Başarılı mı?
- Kullanıcı ekranda kodu gördü mü? (event log)
3 klasik hata senaryosu ve çözüm yaklaşımı
- Webhook geldi, kod ayırma başarısız (stok yok): Siparişi “beklemede” tut, kullanıcıya doğru mesaj ver, otomatik iade/iptal akışı tanımla.
- Kod ayrıldı, e-posta gidemedi: Kod zaten hesap sayfasında erişilebilir olsun; maili tekrar dene.
- İki kez webhook geldi: Idempotency ile ikinciyi “zaten işlendi” diye kapat.
BerkiTech’te bu iş nasıl “temiz” çözülür?
- Atomik kod ayırma: Aynı kodun iki kez satılmasını engelleyen rezervasyon mantığı.
- Çok kanallı teslimat: Ekran + Hesabım + e-posta akışı.
- Entegrasyon esnekliği: Tedarikçi API/CSV senaryolarına uygun yapı.
- Gözlenebilirlik: Siparişin her adımını loglayıp support tarafını rahatlatan iz.
9) Uygulama kontrol listesi
- Ödeme doğrulaması sunucu tarafında mı?
- Kod ayırma transaction içinde mi?
- Idempotency var mı? (webhook tekrarına dayanıklı mı?)
- Kod teslimatı tek kanala bağlı mı, yoksa 2-3 kanallı mı?
- Stok bittiğinde kullanıcıya doğru bilgi veriliyor mu?
- Tedarikçi API’si için timeout/retry/kuyruk yapısı var mı?
- Admin panelde 2FA + audit log var mı?
- KVKK/GDPR ve faturalama/iade süreçleri net mi?
SSS
E-pin kodlarını e-postayla göndermek şart mı?
Şart değil. En sağlıklısı: kodu sipariş ekranında göster, hesap sayfasında sakla, e-postayı “bilgilendirme” olarak kullan.
Kodlar veritabanında şifreli mi tutulmalı?
En azından erişim yetkileri sıkı olmalı. Yüksek riskli ürünlerde kodu maskeli saklama/role göre çözme gibi yaklaşımlar tercih edilebilir.
Stok yokken satış açılır mı?
Açılır ama operasyon riski büyür. Yeni başlayanlar için “stok yoksa satış yok” daha güvenli bir modeldir.
Webhook gelmezse ne olur?
Ödeme sağlayıcının panelinden “ödendi” kontrolü yapılabilen bir geri dönüş (polling) mekanizması ve “beklemede” state’i olmalı.
Son söz: E-pin satışında kazananlar “kod yollayanlar” değil, hatasız teslimat + güvenlik + şeffaf iletişim üçlüsünü aynı anda yapanlardır. Altyapıyı böyle kurarsan hem müşteri mutlu olur hem de geceleri daha rahat uyursun.