E-pin Satış Scriptin Aynı Kodu İki Kişiye Sattıysa Bu Bir Kaza Değil: Panelinde Sessizce Çalışan O Yarış Durumunu İfşa Ediyorum

Aynı kodun iki farklı müşteriye gitmesi, satıcıların "bir kere oldu, tesadüf" diye geçiştirdiği ama asla tesadüf olmayan bir olaydır. Çoğu kişi bunu personel hatası ya da müşterinin dolandırıcılığı sanır. Gerçek çok daha teknik: iki istek, aynı saniyenin içinde, aynı stok satırını okumuş ve ikisi de o satırı kendine ait saymıştır. Buna yarış durumu denir ve bir kez ortaya çıktıysa koşullar tekrarlandığında yine çıkar.

Bu yüzden mesele bir siparişi iade etmekle kapanmaz. Kapanması için kodun tek bir siparişe bağlanmasını garanti eden mekanizmanın kurulması gerekir. Aşağıda bu mekanizmanın nerede eksik kaldığını, hangi üç davranışın çift teslimatı ürettiğini ve bunun ticari faturasının neden düşündüğünden büyük olduğunu tek tek açıyorum. Bir e-pin satış scripti için bu konu kozmetik bir iyileştirme değil, doğrudan varlık güvenliği meselesidir.

Aynı Kodun İki Kişiye Gitmesi Bir Tesadüf Değil, Bir Yarış Durumudur

Klasik teslimat kodu şöyle çalışır: önce havuzdan boş bir satır seç, sonra onu siparişe yaz, sonra satılmış işaretle. Tek başına çalışan bir istek için kusursuz görünür. Ama iki istek milisaniyeler arayla geldiğinde ikisi de aynı "boş" satırı görür, ikisi de kendi siparişine yazar ve ikinci yazma birincinin üzerine biner. Sonuçta panelde tek satış görünür, sahada iki müşteri aynı kodu kullanmaya çalışır.

Çözüm mantıksal değil altyapısaldır: seçme ve işaretleme tek ve bölünemez bir işlem olmalıdır. Satır ya bu siparişe kilitlenir ya hiç verilmez. Bu garantiyi kurmayan her epin yazılım kurulumu, trafik arttığı ilk kampanya gününde aynı hatayı üretir. Dikkat çekici olan şu: hata düşük trafikte neredeyse hiç görünmez. Yani sistem aylarca sorunsuz çalışıp tam da en çok sattığın gün seni yakar. Bu da satıcıların "bizde böyle bir sorun yok" demesinin asıl nedenidir.

Eşzamanlı İki Sipariş Aynı Satırı Neden Okur?

Çünkü okuma ve yazma arasında geçen her mikrosaniye bir açık penceredir. O pencerede başka bir istek aynı sorguyu çalıştırabilir. Pencereyi kapatmanın bilinen yolları var: satırı okurken kilitlemek, stok satırına sipariş numarasını koşullu olarak yazmak, ya da sipariş-kod eşleşmesine veritabanı düzeyinde tekillik kısıtı koymak. Üçü de aynı sonuca hizmet eder: ikinci yazma girişimi başarısız olmak zorundadır.

Buradaki en önemli nokta, başarısızlığın sessiz geçmemesi. İkinci sipariş satır bulamadığında bunu bir hata olarak kaydedip yeni bir satır denemeli, hiç satır yoksa siparişi bekletmeli ve seni uyarmalı. Sessizce boş alan göstermek en kötü davranıştır; hem müşteri kodsuz kalır hem sen olaydan haberdar olmazsın. İyi tasarlanmış bir dijital ürün satış scripti için kural basit: kodun iki kez verilmesi imkansız, verilememesi ise görünür olmalı.

Yenile Tuşu ve Çift Callback: Sessiz Çoğaltıcılar

Yarış durumu tek suçlu değil. İkinci büyük kaynak, aynı teslimat işleminin iki kez çağrılmasıdır. Ödeme sağlayıcıları bildirim aldığına dair beklediği yanıtı alamazsa aynı bildirimi tekrar gönderir; bu normal bir davranıştır. Senin tarafın bu tekrarı ayırt edemiyorsa ikinci bildirim ikinci bir teslimat başlatır ve havuzdan bir kod daha yakar.

Aynı sorun müşteri tarafında da yaşanır: teslim sayfasında yenile tuşuna basmak, tarayıcının sayfayı önceden yüklemesi, ya da kullanıcının iki sekmede aynı siparişi açması. Teslimat uç noktası idempotent değilse her tetikleme yeni satır tüketir. Kural şudur: bir sipariş numarası için teslimat yalnızca bir kez üretilir; sonraki tüm çağrılar aynı sonucu okuyup döner. Bunu sağlamak için bildirim kimliklerini kaydetmek ve teslimat sonucunu siparişe yazıp tekrar üretmemek yeterli. Basit ama atlandığında en pahalıya çıkan önlemlerden biri.

Excel'den Toplu Yükleme Neden Mükerrer Kod Doğurur?

Bu kaynağı neredeyse hiç kimse hesaba katmaz. Tedarikçinden gelen dosyayı panele yüklersin, yükleme yarıda kesilir veya tarayıcı zaman aşımına düşer, sen de dosyayı ikinci kez yüklersin. Havuzda artık aynı kodun iki satırı var. Sistem bunları iki ayrı varlık sanır ve zamanla ikisini iki ayrı müşteriye satar. Aradan haftalar geçtiği için de olayı yarış durumuna bağlayamazsın; halbuki sebep tamamen içe alma aşamasındadır.

Korunmak için tek bir kural yeter: kod değeri havuzda tekil olmalı. İçe alma sırasında var olan bir kod tekrar gelirse atlanmalı ve raporda "şu kadar mükerrer atlandı" diye gösterilmeli. Ayrıca her yükleme kendi parti numarasını almalı ki hangi kodun hangi dosyadan geldiği izlenebilsin. Bu iki ayrıntı, bir dijital ürün satış yazılımı ile elle tutulan bir tablo arasındaki asıl farktır. Tekillik kısıtı olmayan bir havuz, ne kadar düzenli görünse de bomba taşır.

İtibar Maliyeti: Bir Kodun İki Kez Satılmasının Gerçek Faturası

Hesabı çoğu satıcı yanlış yapar. "Bir kod, bir iade" diye düşünür. Gerçek fatura ise şöyle: kodun maliyetini bir kez ödedin, iadeyi yaptın, ödeme sağlayıcısının kesintisini geri alamadın, destek ekibin yarım saat harcadı ve en önemlisi kodu kullanamayan müşteri bunu forumda, yorumda, oyun topluluğunda anlattı. Dijital ürün satışında güven tek satın alma gerekçesidir; kırıldığında yerine koyacağın bir indirim yoktur.

Daha ince bir zarar da var: çift teslimat yaşayan satıcılar refleks olarak otomatik teslimatı kapatıp her siparişi elle onaylamaya geçer. Böylece bir teknik eksiği, tüm operasyonu yavaşlatan kalıcı bir sürece dönüştürürler. Doğru tepki otomasyondan kaçmak değil, otomasyonu garantili hale getirmektir. Tek-satış garantisi kurulduğunda hem hız hem güven aynı anda elde edilir; ikisinden birini seçmek zorunda değilsin.

Pinova Tarafında Tek-Satış Garantisi Nasıl Kurulur?

Pinova e-pin satmaz; e-pin satan işletmelerin satış ve teslimat süreçlerini yönettiği lisanslı bir yazılımdır. Güvenlik tarafındaki temel duruşu da bu yazının çekirdeğiyle aynı: bir kodun iki kez satılması bir ihtimal olarak bile bırakılmamalı. Stok satırı bir siparişe bağlanırken kilitlenir, eşleşme veritabanı düzeyinde tekil tutulur, aynı sipariş için ikinci teslimat girişimi yeni satır tüketmek yerine mevcut sonucu döner.

İçe alma tarafında da aynı mantık sürer: mükerrer kod sessizce havuza girmez, atlanır ve raporda gösterilir; her parti izlenebilir kalır. Ödeme bildirimleri kimlikleriyle kaydedildiği için sağlayıcının tekrar denemeleri ikinci teslimat başlatmaz. Sonuç olarak hem otomatik teslimatın hızını korursun hem "acaba aynı kodu iki kez mi sattım" endişesini masadan kaldırırsın. Mimarinin ayrıntılarına özellikler bölümünden, hangi paketin hangi güvenlik katmanını kapsadığına fiyat bölümünden bakabilirsin.

Aynı kodun iki kez satılması, dışarıdan küçük bir aksaklık gibi görünür ama aslında altyapının en temel sözünü bozar: sattığın şeyin gerçekten tek sahibi olduğu sözünü. Bu sözü koruyan şey dikkatli olmak değil, ikinci teslimatı teknik olarak imkansız kılan kilitler ve kısıtlardır. Pinova'nın stok kilidi davranışını, tekillik kontrollerini ve eşzamanlı sipariş testini kendi senaryonla denemek istersen canlı demo ortamında tek stoklu bir ürün oluşturup üzerine yüklen; sonucu gördükten sonra kurulum adımına geçmek çok daha rahat olacak.