Çoğu satıcı, bir kodun "satıldı" olarak işaretlenmesini tek satırlık bir işlem sanır. Sipariş onaylanır, veritabanındaki satırın durumu değişir, kod müşteriye gider. Kâğıt üzerinde kusursuz. Ama sen bir gün iki farklı müşterinin aynı 100 TL'lik kodu ekran görüntüsüyle gönderdiğini gördüğünde, o tek satırın aslında bir zincirin en son halkası olduğunu anlarsın. Sorun kodu işaretlemek değil, kodu ne zaman ve hangi sırayla işaretlediğin.
İşin acı tarafı şu: bu kâbusu yaşayan işletmelerin büyük bölümünde kod gerçekten iki kez satılmamıştır. Kod bir kez satılmış, ama iki kez gösterilmiştir. Aradaki fark, kullandığın e-pin scripti içindeki stok yaşam döngüsünün tasarımında saklı. Bu yazıda o döngüyü parça parça açıyorum; sonunda kendi panelinde hangi halkanın eksik olduğunu tek bakışta göreceksin.
Çoğu E-pin Scripti Kodu Neden "Satıldı" Diye İşaretler de İş Yine de Karışır?
Basit kurgulu bir dijital ürün satış scriptinde akış şöyledir: ödeme bildirimi gelir, sistem stoktan boştaki ilk kodu seçer, o kodu sipariş numarasıyla eşler ve durumunu değiştirir. Üç adım. Ama bu üç adım arasında milisaniyelerle ölçülen boşluklar var ve o boşluklar tek kullanıcılık bir dünyada görünmez, kampanya saatinde ise fay hattına dönüşür.
Diyelim ki ödeme sağlayıcın aynı bildirimi iki kez gönderdi; bu son derece normaldir, birçok geçit yanıt alamadığında tekrar dener. Script "boştaki ilk kodu seç" dediğinde iki istek de aynı anda aynı satırı okur, ikisi de o satırı kendi siparişine yazar. Son yazan kazanır ama ilk yazanın müşterisi kodu çoktan ekranda görmüştür. İşte çift teslimat böyle doğar. Kodun durum alanı doğru çalışmıştır; eksik olan şey okuma ile yazma arasındaki güvenli bölgedir.
Rezervasyon mu, Kilit mi? İki Kelime Arasındaki Fark Kasandaki Fark
Sağlam bir e-pin satış yazılımı kodu satış anında değil, sipariş oluşturma anında ayırır. Buna rezervasyon denir. Müşteri ödeme sayfasına geçtiği saniyede kod "ayrıldı" durumuna alınır, bir süre sonuna kadar kimseye gösterilmez, ödeme başarısız olursa süre dolunca havuza geri döner. Bu yaklaşımın güzelliği, stok sayımının her an gerçeği söylemesidir: vitrinde gördüğün adet, gerçekten satılabilir adettir.
Kilit ise daha alt seviyede bir mekanizmadır ve veritabanı düzeyinde çalışır. Kod satırı seçilirken aynı satırı başka bir işlemin okumasına izin verilmez; işlem bitene kadar sıra bekler. Rezervasyon iş mantığını, kilit ise veri bütünlüğünü korur ve ikisi birbirinin yerine geçmez. Rezervasyonu olup kilidi olmayan sistem yoğunlukta çakılır, kilidi olup rezervasyonu olmayan sistem ise stok sayısını sürekli yanlış gösterir.
Durum Alanı Tek Başına Yeterli mi, Yoksa Yaşam Döngüsü mü Gerekiyor?
Tek bir "satildi" sütunu, sadece iki soruya cevap verir: satıldı mı, satılmadı mı. Oysa gerçek işletmede sorular bunlar değil. Bu kod hangi siparişte gitti? Gösterildi mi, yoksa sadece atandı mı? Müşteri panelde görüntüledi mi, kopyaladı mı? İade açıldığında kod yakıldı mı, yoksa geri mi alındı? Tedarikçin bu kodu bize hangi partide verdi ve geçerlilik tarihi ne?
Bu soruların hepsinin karşılığı ayrı bir aşamadır. Deneyimli bir epin yazılım mimarisinde kod; havuzda, ayrıldı, atandı, teslim edildi, doğrulandı, iade edildi ve yakıldı gibi aşamalar arasında yalnızca izin verilen yönlerde ilerler. Geri dönüşler kontrollüdür. "Teslim edildi" olan bir kod asla doğrudan "havuzda" durumuna dönemez; önce iade aşamasından geçmek zorundadır. Bu tek kural bile envanterindeki hayalet stoğun büyük kısmını yok eder.
| Aşama | Ne zaman girilir | Vitrinde sayılır mı | Geri dönüş izni |
|---|---|---|---|
| Havuzda | Kod sisteme yüklendiğinde | Evet | — |
| Ayrıldı (rezerve) | Sipariş oluşturulduğunda | Hayır | Süre dolunca havuza |
| Atandı | Ödeme onayı geldiğinde | Hayır | Yalnız iptalle |
| Teslim edildi | Kod müşteriye ilk kez gösterildiğinde | Hayır | Yalnız iade akışıyla |
| Doğrulandı | Müşteri kullandığını bildirdiğinde | Hayır | Yok |
| İade edildi | Talep onaylandığında | Hayır | Yakıldı ya da havuza |
| Yakıldı | Kod geçersiz veya kullanılmış çıktığında | Hayır | Yok |
Kodun "Görüldü" Anı Neden Teslimatın Gerçek Saatidir?
Birçok satıcı teslim zamanını, sistemin siparişi kapattığı an olarak kaydeder. Bu ölçüm yanıltıcıdır, çünkü müşteri o an uyuyor olabilir. Uyuşmazlık çıktığında ise sana lazım olan bilgi tam olarak şudur: kod ekranda ilk kez ne zaman, hangi oturumdan ve hangi ağ adresinden açıldı. Teslimatın hukuki saati, kodun görüntülendiği saattir.
Bu yüzden ciddi bir e-pin scripti kodu maskeli tutar ve müşteri "göster" dediğinde kaydı düşer. İlk görüntülemeden sonra kod artık geri alınamaz sayılır, çünkü kopyalanmış kabul edilir. Aynı kayıt, bankaya giden itiraz dosyanda da en güçlü belgendir. Görüntüleme kaydı olmayan satıcı, her itirazda peşinen kaybeder.
Çift teslimat vakalarının kök nedeni dağılımı
- Tekrarlı ödeme bildirimi 45%
- Rezervasyonsuz stok seçimi 25%
- Manuel panel müdahalesi 20%
- Tedarikçi kaynaklı mükerrer kod 10%
İade, İptal ve Çift Ödeme: Kod Geri Dönerse Ne Olacak?
Kodun geri dönüşü, işaretleme mantığının en çok ihmal edilen yüzüdür. İki seçenek vardır ve ikisi de meşrudur: kodu havuza iade etmek ya da yakmak. Karar, kodun görüntülenip görüntülenmediğine bağlıdır. Hiç gösterilmemiş bir kod güvenle havuza döner. Bir kez gösterilmiş kodu havuza döndürmek ise ikinci müşterine bozuk mal satmak demektir; o kodu yakıp zararı tedarikçiyle konuşman gerekir.
Bu ayrımı otomatikleştirmeyen sistemlerde karar operatöre kalır ve operatör yoğun günde en kolay yolu seçer. Bu nedenle iade politikasını kodun durumuna bağlayan bir kural motoru, insan inisiyatifinden çok daha ucuzdur. Pinova tarafında bu kuralları ürün bazında ayarlayabildiğin bir yapı var; ayrıntısına özellikler bölümünden bakabilirsin.
Rezervasyon süresini ödeme sağlayıcının ortalama onay süresinin en az üç katı yap. Çok kısa süre, ödemesi geciken müşterinin kodunu elinden alır ve iki kat destek talebi üretir.
Denetim İzi Olmayan Sistemde Kimse Kimseyi Suçlayamaz
Bir kodun kim tarafından, hangi saniyede, hangi sebeple durum değiştirdiğini yazmayan sistemde tartışmanın sonu gelmez. Personelin mi yanlış tuşa bastı, tedarikçin mi aynı kodu iki kez yolladı, müşterin mi ekran görüntüsünü düzenledi? Denetim izi olmadan hiçbirini kanıtlayamazsın. İyi bir dijital ürün satış yazılımında her durum değişimi ayrı bir satır olarak yazılır ve bu satırlar asla silinmez, yalnızca eklenir.
Bu kaydın maliyeti neredeyse sıfır, getirisi ise çok büyük. Ay sonunda "kaç kod yandı, kaçı hangi personel tarafından iade edildi, hangi tedarikçinin partisinden ne kadar sorun çıktı" sorularının hepsi tek sorguyla cevaplanır. Aşağıdaki kontrol listesini kendi panelinde tek tek işaretle; boş bıraktığın her satır, gelecekte ödeyeceğin bir fatura.
| Kontrol | Neden önemli | Sende var mı |
|---|---|---|
| Sipariş anında rezervasyon | Vitrin stoğunu gerçeğe eşitler | — |
| Satır düzeyinde kilit | Eşzamanlı seçimde çakışmayı önler | — |
| Tekrarlı bildirim koruması | Aynı ödemenin iki kez işlenmesini keser | — |
| Maskeli kod + görüntüleme kaydı | Teslim saatini kanıtlar | — |
| Duruma bağlı iade kuralı | Yanlış kodun havuza dönmesini engeller | — |
| Silinemez denetim izi | Sorumluluğu netleştirir | — |
| Parti ve tedarikçi etiketi | Sorunlu kaynağı hızlı bulur | — |
Kod yaşam döngüsü hazır gelsin, sen satışa odaklan
Rezervasyon, kilit, görüntüleme kaydı ve denetim izi Pinova'da kutudan çıktığı gibi çalışır. Lisans seçeneklerini inceleyip kendi mağazanı aynı gün kurabilirsin.
Kod ne zaman kullanılmış sayılmalı?
Müşteriye ilk kez açık biçimde gösterildiği anda. Sipariş kapanışı ya da ödeme onayı değil, görüntüleme kaydı esas alınmalıdır; itiraz süreçlerinde kanıt değeri olan tek an budur.
Rezervasyon süresi ne kadar olmalı?
Ödeme sağlayıcının onay süresine bağlı olarak genelde 10 ila 30 dakika arası uygundur. Havale ve EFT gibi yavaş yöntemlerde bu süreyi ürün bazında uzatman gerekir.
İade edilen kodu tekrar satabilir miyim?
Kod hiç görüntülenmediyse evet, güvenle havuza dönebilir. Bir kez görüntülendiyse kopyalanmış kabul edilmeli ve yakılmalıdır; aksi halde ikinci müşteriye geçersiz kod satmış olursun.
Küçük mağazada bu kadar aşamaya gerek var mı?
Günde birkaç sipariş alırken bile denetim izi ve görüntüleme kaydı hayat kurtarır. Rezervasyon ve kilit ise ciddi bir maliyet getirmediği için baştan açık olmalı; hacim büyüdüğünde geriye dönük eklemek çok daha zordur.
Kod işaretleme mantığı, dışarıdan bakınca teknik bir ayrıntı gibi görünür ama aslında müşterine verdiğin sözün altyapısıdır. Bu döngüyü kurduğun gün destek kutunun sessizleştiğini, iade oranının düştüğünü ve ay sonu sayımının ilk kez tuttuğunu fark edeceksin. Yukarıdaki yedi aşamanın kendi panelinde nasıl göründüğünü merak ediyorsan canlı demo üzerinden bir sipariş oluşturup kodun durumlar arasında nasıl ilerlediğini kendi gözünle izleyebilir, ardından fiyat seçeneklerine göz atabilirsin.