Çoğu kişi e-pin satışının basit bir denklem olduğunu sanır: müşteri öder, sistem kodu gönderir, iş biter. Bu bakış açısıyla kurulan yüzlerce mağaza gördük ve hepsi aynı duvara tosladı. Çünkü ödeme ile teslimat arasında, dışarıdan görünmeyen ama tüm kâr marjını sessizce yiyen bir aralık var. O aralıkta banka bildirimi gecikir, tedarikçi API'si zaman aşımına uğrar, müşteri sayfayı yeniler, ödeme sağlayıcısı aynı bildirimi iki kez yollar. Ve senin e-pin scriptin bu kaosu yönetecek bir durum makinesine sahip değilse, kodlar tek tek kayıp gider.
İşin gerçeği şu: teslimat bir olay değil, bir zincir. Zincirin her halkası bir sipariş durumudur ve her geçiş bir tetikleyiciye bağlıdır. Profesyonel bir dijital ürün satış scripti ile amatör bir kurulumu ayıran şey arayüzün güzelliği değil, bu geçişlerin ne kadar katı tanımlandığıdır. Aşağıda o zincirin nasıl kurulduğunu, hangi noktada kırıldığını ve neden bunu en baştan doğru tasarlamanın ikinci yıl seni binlerce liralık zarardan kurtardığını tek tek açıyorum.
Sipariş durumu neden sadece renkli bir etiket değildir?
Pek çok mağaza sahibi sipariş durumunu panelde görünen bir rozet sanır. Yeşilse iyi, kırmızıysa kötü. Oysa durum alanı, sistemin o siparişe hangi işlemleri yapmasına izin verildiğini belirleyen bir yetki kapısıdır. "Ödeme bekleniyor" durumundaki bir siparişe stok düşülemez. "Teslim edildi" durumundaki bir siparişe ikinci kez kod atanamaz. "İade edildi" durumundaki bir siparişin kuponu tekrar harcanamaz. Durum, yasak listesidir.
Bu yüzden iyi kurgulanmış bir e-pin satış yazılımı durumları serbest metin olarak tutmaz. Sabit bir liste, sabit geçiş haritası ve her geçiş için bir kayıt satırı vardır. Sipariş "hazırlanıyor" durumundan doğrudan "iade" durumuna atlayamaz; arada mutlaka "başarısız" ya da "iptal" uğrağı bulunur. Bu katılık can sıkıcı görünür ama gece üçte tedarikçi API'si çöktüğünde seni kurtaran tam da budur.
Teslimat tetikleyicisi tam olarak hangi anda ateşlenmeli?
Yanlış cevap: müşteri ödeme sayfasından döndüğünde. Bu, en sık yapılan ve en pahalı hatadır. Tarayıcı dönüşü bir kanıt değildir; kullanıcı ödeme yapmadan da o adrese elle gidebilir, ya da ödeme yapıp dönüş sayfasını hiç görmeyebilir. Doğru cevap: ödeme sağlayıcısının sunucudan sunucuya gönderdiği bildirim doğrulandığında ve bu bildirimin imzası, tutarı, para birimi ve sipariş numarası birebir eşleştiğinde.
Bunun pratikteki karşılığı şudur: teslimat mantığın dönüş sayfasında değil, bildirim uç noktasında yaşamalıdır. Dönüş sayfası sadece müşteriye "işlemin alındı" der ve durumu okur. Kodu düşüren, stoğu azaltan, e-postayı tetikleyen kod ise arka kapıda çalışır. Pinova gibi bu ayrımı mimari seviyede kuran bir yazılımda, müşteri internetini kaybetse bile teslimat tamamlanır; çünkü tetikleyici müşterinin tarayıcısına bağımlı değildir.
| Sipariş durumu | Tetikleyici olay | Sistemin yaptığı | Müşterinin gördüğü |
|---|---|---|---|
| Oluşturuldu | Sepet onayı | Stok rezerve edilir, kod atanmaz | Ödeme ekranı |
| Ödeme bekleniyor | Ödeme sayfasına yönlenme | Zaman aşımı sayacı başlar | Bekleme bildirimi |
| Ödeme doğrulandı | Sunucu bildirimi + imza kontrolü | Teslimat kuyruğuna alınır | Hazırlanıyor mesajı |
| Teslim ediliyor | Kuyruk işçisi görevi alır | Kod kilidi konur, tekrar girişi engellenir | Canlı durum çubuğu |
| Teslim edildi | Kod başarıyla atandı | Stok düşer, fatura ve e-posta çıkar | Kod ekranı |
| Başarısız | Stok yok veya API hatası | Rezerv serbest, iade önerisi | Açıklamalı hata + iade butonu |
| İade edildi | Operatör veya otomatik kural | Bakiye iadesi, kod karantinaya | İade bildirimi |
Aynı siparişe iki kez kod düşerse suçlu kim?
Suçlu ödeme sağlayıcısı değil. Ödeme sağlayıcıları bildirimi bilinçli olarak birden fazla kez gönderir; çünkü senin sunucunun ilk seferde cevap verdiğinden emin olamazlar. Bu bir arıza değil, standart davranıştır. Suçlu, aynı bildirimi iki kez işleyen scripttir. Çözüm ise tek kelimeyle idempotenstir: her bildirim için benzersiz bir anahtar üretilir, o anahtar veritabanına tekil indeksle yazılır ve ikinci gelen aynı anahtar sessizce reddedilir.
Buna ek olarak teslimat anında sipariş satırının kilitlenmesi gerekir. İki işçi süreci aynı anda aynı siparişi alırsa, veritabanı seviyesinde satır kilidi olmadan ikisi de kod atamaya çalışır. Bir e-pin yazılımının olgunluk testi budur: yoğun kampanya gecesinde aynı anda yüzlerce sipariş akarken tek bir kodu bile iki müşteriye göndermemesi.
Teslimat başarısızlıklarının gerçek kaynağı
- Tetikleyicinin yanlış noktada olması 45%
- Stok ve rezervasyon çakışması 25%
- Tedarikçi API zaman aşımı 20%
- Operatör kaynaklı manuel hata 10%
Panelde görünen durum ile gerçekte olan biten neden ayrışır?
Çünkü çoğu kurulumda durum alanı tek bir sütundur ve her güncelleme öncekini ezer. Sipariş başarısız olup sonra elle düzeltildiğinde, panelde yalnızca son hali görünür. Oysa sen bir ay sonra "bu siparişte ne oldu" diye bakmak zorunda kalacaksın. Bunun için durum geçiş günlüğü şart: hangi durumdan hangisine, hangi saniyede, hangi tetikleyiciyle, hangi kullanıcı veya sistem süreciyle geçildi.
Bu günlük aynı zamanda tartışmalı iadelerde senin kanıtın olur. Müşteri "kod gelmedi" dediğinde, elinde kodun hangi saniyede oluşturulduğu, hangi IP'den görüntülendiği ve e-postanın hangi saatte teslim edildiği bilgisi bulunur. Kanıtsız itiraz yönetimi, dijital üründe en hızlı marj eriten şeydir.
Teslimat kuyruğuna bir de "ilk deneme gecikmesi" koy. Ödeme doğrulandıktan sonra iki saniye bekleyen bir kuyruk, ödeme sağlayıcısından gelen iptal veya ters ibraz bildirimini yakalayıp teslimatı hiç başlatmadan durdurabilir. İki saniye müşteriyi rahatsız etmez ama seni sahte ödeme zararından korur.
Durum makinesini kim tasarlarsa marjı o belirler
Bu cümle abartılı görünebilir ama rakamlar net. İade oranı, destek yükü, tedarikçi maliyeti ve stok devir hızı; hepsi durum geçişlerinin ne kadar temiz tanımlandığına bağlıdır. Zayıf kurguda operatör her gün onlarca siparişi elle kurcalar, her kurcalama yeni bir tutarsızlık üretir ve üç ay sonra hangi kodun kime gittiğini kimse bilemez hale gelir.
Buna karşılık iyi tanımlanmış bir epin yazılım altyapısında operatörün yapabileceği işlem sayısı bilinçli olarak kısıtlıdır. Sadece izin verilen geçişler arayüzde görünür; gerisi kapalıdır. Bu kısıtlama, personelin deneyimsiz olduğu dönemde bile sistemi tutarlı tutar. Kurgu detaylarını özellikler bölümünde inceleyebilir, ölçeğine uygun paketi fiyat tablosundan seçebilirsin.
| Kontrol noktası | Neden gerekli | Durum |
|---|---|---|
| Teslimat yalnızca sunucu bildirimiyle tetikleniyor mu? | Sahte dönüş sayfası istismarını keser | Zorunlu |
| Her bildirim için idempotens anahtarı var mı? | Çift teslimatı imkânsız kılar | Zorunlu |
| Sipariş satırı teslimat sırasında kilitleniyor mu? | Eşzamanlı işçi çakışmasını önler | Zorunlu |
| Durum geçiş günlüğü tutuluyor mu? | İtiraz ve denetimde kanıt sağlar | Zorunlu |
| Başarısız teslimatta stok rezervi serbest bırakılıyor mu? | Hayalet stok kaybını engeller | Yüksek |
| Tedarikçi zaman aşımında otomatik yeniden deneme var mı? | Geçici kesintide siparişi kurtarır | Yüksek |
| Müşteriye durum değişimi anlık bildiriliyor mu? | Destek talebini belirgin biçimde azaltır | Orta |
Peki bu kurguyu sıfırdan yazmaya değer mi?
Teknik olarak mümkün, ticari olarak nadiren mantıklı. Yukarıdaki yedi durumu, idempotens katmanını, kuyruk işçilerini, geçiş günlüğünü ve tedarikçi yeniden deneme mantığını kendin yazmak aylar sürer. Üstelik asıl maliyet yazmak değil, canlı trafikte öğrenmektir. Her kaybolan kod, her çift teslimat ve her haksız iade senin ödediğin okul parasıdır.
Hazır ve olgun bir dijital ürün satış yazılımı bu bedeli daha önce ödemiş binlerce siparişin deneyimini sana devreder. Sen enerjini tedarikçi pazarlığına, reklam verimine ve marka güvenine harcarsın; teslimat zinciri arka planda sessizce çalışır. Zaten bir e-pin işinde müşterinin hatırladığı tek şey vardır: kod, saniyeler içinde ve doğru şekilde geldi mi?
Teslimat zincirini şansa bırakma
Durum makinesi, idempotens ve kuyruk mimarisi hazır kurulu gelen bir altyapıyla ilk gününden itibaren tutarlı satış yap.
Teslimat tetikleyicisini dönüş sayfasına bağlamak neden riskli?
Dönüş sayfası kullanıcının tarayıcısında çalışır ve doğrulanmamış bir kaynaktır. Kullanıcı ödeme yapmadan o adrese gidebilir ya da ödeme yapıp sayfayı hiç görmeyebilir. Teslimat, yalnızca ödeme sağlayıcısının sunucudan sunucuya gönderdiği ve imzası doğrulanan bildirimle tetiklenmelidir.
Kaç sipariş durumu yeterlidir?
Sağlıklı bir kurguda en az yedi durum bulunur: oluşturuldu, ödeme bekleniyor, ödeme doğrulandı, teslim ediliyor, teslim edildi, başarısız ve iade edildi. Daha azı geçişleri belirsizleştirir, çok daha fazlası operasyonu gereksiz karmaşıklaştırır.
Çift teslimatı tamamen engellemek mümkün mü?
Evet. Her ödeme bildirimine benzersiz bir anahtar atanır, bu anahtar veritabanında tekil indeksle saklanır ve aynı anahtarla gelen ikinci istek işlenmeden geçilir. Buna sipariş satırı kilidi eklendiğinde eşzamanlı süreçlerin aynı kodu iki kez atama ihtimali ortadan kalkar.
Tedarikçi API'si cevap vermezse sipariş ne olmalı?
Sipariş doğrudan başarısız işaretlenmemeli, önce artan aralıklarla birkaç kez yeniden denenmeli. Tanımlı deneme sayısı dolduğunda durum başarısıza çekilir, stok rezervi serbest bırakılır ve müşteriye otomatik iade ya da alternatif ürün seçeneği sunulur.
Teslimat zinciri, e-pin işinin görünmeyen omurgasıdır ve bir kez doğru kurulduğunda yıllarca sessizce çalışır. Bu yazıdaki durum haritasının, tetikleyici mantığının ve kontrol listesinin gerçek bir panelde nasıl göründüğünü merak ediyorsan canlı demo üzerinden sipariş akışını baştan sona kendin deneyebilirsin.