E-pin Scriptinin Otomatik Teslimat Motoru Perde Arkasında Nasıl Çalışır? Siparişten Koda Giden O 9 Saniyeyi Adım Adım Açıyorum

Dışarıdan bakan biri otomatik teslimatı basit sanır: müşteri öder, sistem veritabanından bir kod alır, ekrana yazar. Gerçekte o kısacık anın içinde en az yedi farklı karar verilir ve bu kararlardan herhangi biri yanlış sıralandığında ya aynı kod iki kişiye gider ya da ödemesi alınmış müşteri boş ekrana bakar. Sektörde en çok can yakan hatalar, kod bulunamamasından değil, kodun yanlış anda ayrılmasından doğar.

Bu yazıda bir e-pin scripti içindeki teslimat motorunu adım adım açıyorum. Ödeme bildiriminin geldiği andan kodun müşteriye ulaştığı ana kadar hangi kontroller yapılır, neden kilit gerekir, kuyruk ne işe yarar ve aynı bildirim iki kez geldiğinde sistem kendini nasıl korur. Teknik bir konu ama işletme sahibi olarak bu akışı bilmen gerekir; çünkü destek ekranında gördüğün her tuhaf sipariş, bu zincirdeki belirli bir halkanın izini taşır.

Zincir gerçekte nerede başlıyor?

Teslimat, ödeme onayıyla değil, sepet doğrulamasıyla başlar. Müşteri ödeme sayfasına geçmeden önce sistem ürünün hâlâ satılabilir olduğunu, fiyatın güncel olduğunu ve istenen adedin karşılanabilir olduğunu kontrol eder. Bu kontrol atlanırsa, ödeme tamamlandıktan sonra stoksuzluk keşfedilir ve elinde iade edilmesi gereken bir işlem kalır.

İkinci adım geçici rezervasyondur. Müşteri ödeme sayfasındayken kodlar "beklemede" durumuna alınır ama kimseye atanmaz. Bu ara durum çok kritiktir: kod ne satılmıştır ne de serbesttir. Ödeme belirlenen süre içinde tamamlanmazsa rezervasyon otomatik düşer ve kod havuza geri döner. İyi yazılmış bir dijital ürün satış yazılımı bu geri dönüşü bir zamanlayıcıya bırakmaz, her stok sorgusunda süresi geçmiş kilitleri kendiliğinden temizler.

Ödeme bildirimi neden iki kez gelir ve sistem ne yapmalı?

Ödeme sağlayıcıları, bildirimin ulaştığından emin olmak için aynı olayı tekrar gönderir. Bu bir arıza değil, tasarım gereğidir. Senin tarafında yapılması gereken, her bildirimi benzersiz bir anahtarla işaretlemek ve daha önce işlenmiş bir anahtar geldiğinde işlemi baştan yapmak yerine önceki sonucu geri döndürmektir. Buna idempotens denir ve çift teslimatın tek gerçek panzehiridir.

Uygulamada anahtar, sağlayıcının işlem numarası ile sipariş numarasının birleşimidir. Bu anahtar veritabanında benzersiz indeksle korunur; ikinci kayıt denemesi doğrudan reddedilir. Böylece iki bildirim aynı milisaniyede gelse bile yalnızca biri ilerleyebilir. Bir e-pin satış yazılımı bu korumayı uygulama katmanında değil, veritabanı kısıtında tutmalıdır; çünkü uygulama katmanı çoklu sunucuda yarış koşullarına açıktır.

Kod atama anında tam olarak ne oluyor?

Burası motorun kalbidir. Sistem, ilgili ürüne ait ilk uygun kodu seçerken onu aynı anda kilitler. Kilitsiz bir seçim, iki eşzamanlı siparişin aynı satırı okumasına ve ikisinin de "bu kod boş" sonucuna varmasına yol açar. Doğru yaklaşım, seçme ve işaretleme işlemini tek bir atomik güncellemede yapmaktır: kod yalnızca hâlâ boşsa güncellenir, güncellenen satır sayısı sıfırsa sistem bir sonraki koda geçer.

Bu detay küçük görünür ama yoğun kampanya saatlerinde tüm farkı yaratır. Saniyede onlarca siparişin geldiği bir anda, kilitsiz çalışan bir dijital ürün satış scripti kaçınılmaz olarak aynı kodu birden fazla müşteriye gönderir. Sonrası iade, itibar kaybı ve destek yüküdür.

Kuyruk mimarisi gerçekten gerekli mi?

Küçük hacimde her şeyi sipariş isteği içinde yapabilirsin. Ancak e-posta gönderimi, tedarikçi API çağrısı veya mesaj bildirimi gibi dış bağımlılıklar yavaşladığında müşteri ekranda bekler. Kuyruk, bu yan işleri asıl akıştan ayırır: kod atanır atanmaz müşteriye gösterilir, e-posta ve bildirim arka planda gönderilir. Müşteri açısından süre dokuz saniyeden iki saniyeye iner.

Kuyruğun ikinci faydası yeniden denemedir. Tedarikçi API'si anlık cevap vermezse iş kuyrukta kalır ve artan aralıklarla tekrar denenir. Müşteriye "hazırlanıyor" durumu gösterilir, sipariş kaybolmaz. Bu yapı özellikle anlık üretim yapan, yani stoğu depoda tutmayıp tedarikçiden o an çeken ürünlerde zorunludur.

Başarısız teslimat nasıl kurtarılır?

Her motor bir gün tökezler. Önemli olan tökezlediğinde ne yaptığıdır. İyi tasarlanmış bir akışta başarısız teslimat sessizce kaybolmaz; sipariş "beklemede" durumunda kalır, yöneticiye bildirim gider ve müşteriye durumu açıklayan bir mesaj gösterilir. Kesinlikle yapılmaması gereken şey, ödemesi alınmış siparişi "iptal" olarak işaretleyip stoğu serbest bırakmaktır; bu, müşterinin parasını sistemde görünmez hale getirir.

Kurtarma tarafında iki mekanizma yeterlidir. Birincisi otomatik yeniden deneme, ikincisi tek tuşla manuel teslimat. Manuel teslimat mutlaka gerekçe notu istemeli ve ayrı bir kayıt satırı oluşturmalıdır; aksi halde destek ekibinin elinde sınırsız kod dağıtma yetkisi oluşur. Yetki ve kayıt yapısını özellikler bölümünde ayrıntılı görebilirsin.

Kendi sistemini nasıl test edersin?

Teslimat motorunu övmek kolay, kanıtlamak zordur. Aşağıdaki listeyi bir test ürünü üzerinde uygula; her satır gerçek bir arıza senaryosunu taklit eder ve beklenen davranışı gördüğünde motorun gerçekten sağlam olduğunu bilirsin.

Otomatik teslimat, tek bir fonksiyon değil; doğrulama, kilit, idempotens, kuyruk ve kurtarma adımlarının doğru sırayla dizildiği bir zincirdir. Bu zincirin gerçek bir panelde nasıl aktığını görmek istersen canlı demo üzerinden bir test siparişi oluştur, ödeme onayından sonra sipariş detayının hangi saniyede güncellendiğini ve kayıt ekranında hangi adımların düştüğünü tek tek izle.