Otomatik teslimat nedir? “Kod göster” değil, “güvenli teslim et” sistemidir
E-pin/dijital kod satışında otomatik teslimat çoğu kişinin düşündüğü gibi sadece “ödeme oldu, kodu ekrana bas” değildir. Asıl hedef şudur: doğru kodu doğru siparişe, tam bir kez teslim etmek ve bunu hata olduğunda bile sürdürülebilir şekilde yönetmek.
Çünkü dijital üründe teslimat bir kere yapıldı mı geri dönüş zor. Bu yüzden otomatik teslimat sistemi üç şeye aynı anda iyi olmalı:
- Doğruluk: Aynı kod iki kez satılmayacak, yanlış koda düşülmeyecek.
- Güven: “Ödeme başarılı” bilgisi gerçekten doğru kaynaktan doğrulanacak.
- Dayanıklılık: Callback gecikmesi, sunucu hatası, tekrar denemeler gibi durumlarda sistem bozulmayacak.
Büyük resim: 2 ana dünya var
Otomatik teslimat akışında iki ayrı “dünya” birlikte çalışır:
- E-ticaret uygulaman: sipariş, stok (kod havuzu), teslimat ekranı, loglar.
- Ödeme sağlayıcı: kart/havale vb. ödeme sonucu, callback (webhook), bazen sorgu API’si.
Sorunsuz otomatik teslimat, bu iki dünya arasındaki iletişimi doğru tasarlamakla başlar.
Temel veri modeli: Kodun 3 durumu
Otomatik teslimatın sağlam olması için kod havuzunda en az şu durumlar olmalıdır:
- Available (Müsait): Satışa hazır.
- Reserved (Rezerve): Bu sipariş için ayrıldı ama ödeme kesinleşmedi.
- Delivered/Sold (Teslim edildi): Müşteriye verildi, artık geri dönülmez.
Bu model olmadan “ödeme başarısız oldu” ya da “callback geç geldi” gibi senaryolarda kod kaybı veya çift teslimat riski büyür.
Adım adım otomatik teslimat akışı
1) Sipariş oluşturma (Order Created)
Kullanıcı ürünü seçer, sepetten ödemeye geçer. Bu anda sistem bir sipariş kaydı oluşturur. Bu kayıtta kritik olanlar:
- Sipariş ID (tekil)
- Ürün ID ve adet
- Müşteri ID / oturum bilgisi
- Ödeme durumu (Pending gibi)
2) Kod rezervasyonu (Reservation) — kritik güvenlik adımı
Sipariş oluştuğu anda (veya ödeme ekranına giderken) sistem kod havuzundan uygun bir kod seçip Reserved yapar. Rezervasyonun amacı:
- Aynı anda gelen siparişlerde aynı kodun seçilmesini engellemek
- Ödeme başarısız olursa kodu “boşa yakmamak”
Rezervasyonun atomik olması gerekir: “kodu seçtim” ve “durumunu rezerve yaptım” tek güvenli işlem gibi çalışmalı.
3) Ödeme başlatma (Payment Initiated)
Kullanıcı ödeme sayfasında kart bilgisini girer. Bu aşamada sipariş hâlâ “ödeme bekliyor” durumundadır. Burada yapılması gereken temel şey:
- Ödeme sağlayıcıya bir “ödeme denemesi” kaydı açmak (transaction id gibi)
- Sipariş ile ödeme denemesini eşleştirmek
4) Ödeme sonucu: Callback (Webhook) gelir
Ödeme sağlayıcı, ödemenin sonucunu sistemine bildirir. Buradaki ince nokta şu: callback her zaman “tek sefer ve anında” gelmeyebilir.
- Gecikebilir
- İki kez gelebilir (aynı bildirimin tekrarı)
- Bazen hiç gelmeyebilir (network/servis sorunu)
O yüzden sağlam sistemler callback’i “tek kaynak” değil, “bir sinyal” gibi ele alır.
5) Idempotency: Aynı ödeme bildirimi 2 kere gelince ne olacak?
Idempotency demek: aynı olayı 2 kez işlesen bile sonuç değişmemeli. Otomatik teslimatta bu hayati.
- Callback ilk kez geldiyse: siparişi Paid yap, rezerve kodu Delivered yap, müşteriye göster.
- Aynı callback ikinci kez geldiyse: “zaten işlendi” deyip hiçbir şeyi tekrar teslim etme.
Bunu sağlamak için genelde ödeme sağlayıcıdan gelen transaction id / payment reference gibi alanlar “tekil anahtar” gibi kullanılır ve “bu ödeme işlendi mi?” kontrolü yapılır.
6) Teslimat (Delivery): Kodun müşteriye sunulması
Ödeme başarıyla doğrulanınca sistem şu sırayla hareket eder:
- Sipariş durumu: Paid
- Rezerve kod: Delivered
- Müşteri ekranı: “Kodun hazır” (kodu görme/kopyalama)
- İsteğe bağlı: e-posta bildirim (kodun kendisini e-posta ile göndermek her işte doğru tercih olmayabilir)
Burada müşteri deneyimi için kritik detay: teslimat “anında” değilse bile kullanıcıya durum bilgisi gösterilmeli. “Teslimat hazırlanıyor” gibi.
7) Rezervasyon zaman aşımı (Timeout) ve otomatik geri bırakma
Ödeme tamamlanmadıysa rezerve kod sonsuza kadar beklememeli. Yoksa stok “kâğıt üzerinde” biter. Bu yüzden rezervasyona bir süre verilir (ör. 15–30 dk). Süre aşılırsa:
- Kod tekrar Available olur
- Sipariş iptal/timeout durumuna alınır
“Callback gelmedi” senaryosu: Sistem nasıl ayakta kalır?
En sık yaşanan stres testi şudur: müşteri “para çekildi” der, sitede kod görünmez. Bu, çoğu zaman callback’in gecikmesi veya uygulamada teslimat adımında bir hata olmasıdır.
Sağlam yaklaşım:
- Ödeme doğrulama sorgusu: Callback gelmediyse belirli aralıklarla sağlayıcının API’sinden “bu ödeme başarılı mı?” kontrol edilir.
- Retry mekanizması: Teslimat adımında hata olduysa sistem otomatik tekrar dener (aynı kodu tekrar üretmeden).
- Durum ekranı: Kullanıcıya “ödemen doğrulanıyor” gibi şeffaf bir mesaj gösterilir.
Güvenlik ve risk kontrolleri: Dijital ürün “hız + risk” paketidir
Dijital kodlarda hızlı teslimat dönüşüm getirir ama fraud riskini büyütür. Bu yüzden otomatik teslimat akışına “küçük ama etkili” kontroller eklenir:
- Risk bazlı 3DS: yeni müşteri / yüksek tutar / yüksek adet gibi durumlarda zorunlu
- Adet limitleri: kişi başı, saatlik/günlük limit
- Şüpheli siparişte frene basma: teslimatı manuel onaya düşürme
- Loglama: IP, cihaz, zaman, teslimat görüntüleme kayıtları
Buradaki amaç müşteriyi yormak değil; riskli durumlarda “otomatik” akışı kontrollü hale getirmek.
Loglama ve denetlenebilirlik: Sorun çıktığında “ne oldu?”yu 2 dakikada bulabilmek
Otomatik teslimat sisteminde loglar sadece teknik ekip için değil, destek ekibi için de hayat kurtarır. Minimum olarak şu kayıtlar olmalı:
- Sipariş oluşturma zamanı
- Hangi kod rezerve edildi (kim görsün seviyesinde maskeleme uygulanabilir)
- Ödeme callback zamanı ve sonucu
- Teslimat zamanı
- Kodun görüntülenme sayısı ve zamanı (gerekliyse)
Böylece “kod gelmedi” veya “aynı kod satıldı” gibi krizlerde kök nedeni hızlıca yakalarsın.
Hızlı kontrol listesi: “Otomatik teslimat hazır mı?”
- Kod havuzunda Available/Reserved/Delivered ayrımı var mı?
- Rezervasyon atomik mi? (eşzamanlı siparişlerde çakışmıyor mu?)
- Callback idempotent mi? (aynı bildirim 2 kez gelince ikinci teslimat yok mu?)
- Timeout ile rezerve kodlar otomatik serbest kalıyor mu?
- Callback gelmezse ödeme doğrulama/sorgu ve retry var mı?
- Riskli siparişler için limit/3DS/manuel onay gibi kontroller var mı?
- Loglar destek ekibinin işini kolaylaştıracak kadar net mi?
Kapanış
E-pin otomatik teslimatın özü “hız” gibi görünse de, gerçek başarı hatasızlık ve dayanıklılıkta yatar. Rezervasyon + callback + idempotency + timeout + loglama zinciri doğru kurulursa, sistem hem müşteri deneyimini güçlendirir hem de en pahalı hataları (çift kod satışı, sahte ödeme, kayıp stok) büyük ölçüde engeller.