Ödeme Bildirimi Gecikince Siparişi Kim Yönetiyor? E-Pin Scriptinin Sana Hiç Anlatılmayan Bekleme Penceresi ve Durum Makinesi Sırrı

Çoğu işletme sahibi, ödeme bildiriminin gecikmesini "bankanın yavaşlığı" sanır ve konuyu kapatır. Oysa müşterinin ekranında dönen o çarkın arkasında bir banka değil, senin sistemindeki karar boşluğu duruyor. Para sağlayıcının tarafında çoktan bloke edilmiştir; senin tarafında ise sipariş hâlâ tek bir kelimeye bakıyor: "bekliyor". O kelime bir durum değil, bir bahanedir. Çünkü "bekliyor" hiçbir şey anlatmaz: bildirim mi gelmedi, geldi de doğrulanamadı mı, doğrulandı da stok mu tükendi, bunların hiçbiri belli olmaz.

Asıl mesele şu: e-pin ve dijital ürün satışında teslimat saniyeler içinde beklenir, ödeme bildirimi ise bazen dakikalar sürer. Bu iki hız arasındaki fark, senin kâr marjını yiyen tüm olayların doğduğu yerdir. Bu yazıda o farkı bir durum makinesi olarak nasıl modelleyeceğini, hangi katmanların şart olduğunu ve iyi bir e-pin scripti ile kötüsünü birbirinden ayıran o görünmez mimariyi tek tek açacağım.

Ödeme bildirimi neden gecikir? Sağlayıcının sana söylemediği kısım

Bir ödeme sağlayıcısı sana iki ayrı hikâye anlatır: kullanıcının tarayıcısına dönen sonuç ve sunucundan sunucuna gelen bildirim. Bu ikisi aynı anda gelmek zorunda değildir, çoğu zaman gelmez de. Kullanıcı 3D doğrulamayı bitirir, ekranı kapatır; bildirim ise sağlayıcının kuyruğunda sıraya girer. Kuyruk yoğunsa, senin sunucun o an 200 yerine 502 döndüyse ya da SSL el sıkışması bir saniye uzadıysa bildirim ertelenir ve tekrar denenir. Sağlayıcı bunu bir arıza saymaz, normal işleyiş sayar.

İşin en can sıkıcı tarafı, tekrar denemelerin artan aralıklarla yapılmasıdır. İlk deneme 30 saniye sonra, ikincisi iki dakika, üçüncüsü on dakika sonra gelir. Yani bir ağ hıçkırığı, siparişin on dakika boyunca havada kalmasına yeter. Senin scriptin bu on dakikayı bir tasarım problemi olarak kabul etmediği sürece, her gecikme bir müşteri kaybıdır.

Tek sipariş, altı durum: neden "bekliyor" tek başına yetmez

Siparişi ikili düşünmek (ödendi / ödenmedi) en yaygın hatadır. Gerçekte sipariş, ödeme ve teslimat olmak üzere iki bağımsız eksende ilerler. Ödeme başarılı olup teslimat başarısız olabilir; teslimat rezerve edilip ödeme iptal olabilir. Bu yüzden her sipariş, aralarındaki geçişleri açıkça tanımlanmış sonlu sayıda durumdan oluşan bir makine olarak tutulmalıdır. Bir dijital ürün satış scriptinde bu tablo, kodun kalbidir.

Bu ayrımın pratik faydası şudur: müşteri sorduğunda ona "bekliyor" değil, "ödemen doğrulandı, teslimat kuyruğunda" diyebilirsin. Aynı cümle, destek yükünü tek başına yarıya indirir.

Webhook gelmezse ne olur? Sorgulama katmanı şart mı?

Evet, şart. Yalnızca bildirime güvenen bir mimari, sağlayıcının altyapısını kendi altyapın sanmaktır. Doğru kurgu çift yönlüdür: sağlayıcı sana haber verir, sen de belirli aralıklarla sağlayıcıya sorarsın. "odeme_bekliyor" durumundaki her sipariş için 60, 180 ve 420. saniyelerde bir durum sorgusu çalıştırılır. Bu sorgu, bildirimden bağımsız olarak siparişi ileri taşıyabilir.

Burada kritik nokta, iki kaynağın çelişmesi hâlinde hangisine inanacağını baştan yazmış olmaktır. Kural basittir: sorgu yanıtı her zaman bildirimden üstündür, çünkü sorgu o anın gerçeğini okur, bildirim ise geçmişin fotoğrafıdır. İyi bir e-pin satış yazılımı bu önceliği koda gömer, yöneticinin insafına bırakmaz.

Idempotency: aynı bildirim iki kez gelirse stok neden erir?

Sağlayıcı bir bildirimi üç kez göndermişse, senin sistemin üç kez teslimat yapmamalıdır. Bunu sağlayan tek şey, her ödeme olayının benzersiz bir anahtarla kaydedilmesi ve o anahtarın veritabanında tekil kısıtla korunmasıdır. Anahtarı yalnızca sipariş numarası yapmak yetmez; sağlayıcının işlem kimliğiyle birlikte saklanmalıdır.

Teslimat atamasının da tek bir işlemin içinde, satır kilidiyle yapılması gerekir. Stok satırını okuyup sonra güncelleyen bir kod, iki eşzamanlı bildirimde aynı kodu iki müşteriye verir. Bu, aylar sonra "kod kullanılmış" şikâyetleri olarak geri döner ve kaynağını bulmak neredeyse imkânsız hâle gelir. Pinova gibi bu işi bilerek tasarlanmış bir epin yazılım altyapısında teslimat, okuma-yazma değil koşullu güncelleme mantığıyla yürür.

Bekleme penceresinde müşteriyi susturmak: bildirim koreografisi

Gecikmenin kendisi değil, sessizliği öfkelendirir. Müşteri bir dakika bekleyebilir, ama ne olduğunu bilmeden bekleyemez. Bu yüzden bekleme penceresini bir iletişim senaryosuyla doldurmalısın: sipariş ekranı kendini otomatik yenilesin, 45. saniyede "ödemen doğrulanıyor" mesajı görünsün, 3. dakikada sipariş takip bağlantısı e-posta ve SMS ile gitsin, 10. dakikada destek ekibine dâhili uyarı düşsün.

Bu koreografiyi elle kurmak yerine, sipariş durumuna bağlı tetikleyiciler olarak tanımlamak gerekir. Durum değiştiğinde mesaj gitsin; zaman geçtiğinde durum değişsin. Böylece iletişim, kodun içine dağılmış tek tek e-posta çağrıları olmaktan çıkar, yönetilebilir bir kural kümesine dönüşür. Bu yaklaşımı özellikler sayfasındaki otomasyon başlıklarıyla birlikte okumanı öneririm.

E-pin scriptinde gecikmeyi yöneten mimari nasıl kurulur?

Aşağıdaki liste, kendi sistemini ya da satın almayı düşündüğün bir e-pin yazılımını denetlerken kullanabileceğin somut kontrol setidir. Her satırı tek tek sorgula; "var" demek yetmez, nasıl olduğunu göstermeli.

Bu sekiz satırı karşılayan bir sistem, gecikmeyi bir kriz olmaktan çıkarıp rutin bir işleyişe dönüştürür. Karşılamayan sistem ise her yoğun günde aynı hatayı tekrar eder: para gelir, kod gitmez, müşteri bağırır, sen elle düzeltirsin. Aradaki fark yazılım kalitesi değil, durum tasarımı disiplinidir. Fiyatlandırma tarafını merak ediyorsan fiyat bölümüne göz atabilirsin.

Gecikmeyi yönetmenin sırrı daha hızlı bir sağlayıcı bulmak değil, beklemeyi öngörülebilir kılan bir mimari kurmaktır. Bu mimarinin gerçek bir panelde nasıl göründüğünü, bekleyen siparişin ekranda hangi bilgiyle karşılandığını ve otomatik doğrulamanın kaç saniyede devreye girdiğini kendi gözünle görmek istersen canlı demo üzerinden bir test siparişi oluşturup tüm durum geçişlerini adım adım izleyebilirsin.