Bu işe yeni girenlerin kafasındaki resim genelde şöyledir: bir yazılım vardır, düğmeye basarsın, kod üretir, satarsın. Forumlarda "kod üretici" diye dolaşan şeyler bu yanılgıyı besler. Gerçek ise çok daha kurumsal ve çok daha katı: bir e-pin kodu, satıcının değil yayıncının muhasebesinde doğar ve o kodun değeri, yayıncının sisteminde karşılığı olan bir kayıttan gelir.
Yani senin işin kod üretmek değil, üretilmiş kodu doğru halkadan alıp doğru şekilde tek bir müşteriye teslim etmektir. Bu cümle sıkıcı gelebilir ama bütün riski de, bütün marjı da açıklıyor. Aşağıda kodun teknik olarak nasıl doğduğunu, zincirdeki dört halkayı, sahte ve çift satılmış kodun nasıl ayırt edildiğini ve kullandığın e-pin scriptinin bu havuzu nasıl koruması gerektiğini anlatacağım.
E-pin kodunu kim üretir: yayıncı mı, bayi mi, sen mi?
Cevap tek kelimeyle yayıncıdır. Bir oyunun ya da servisin sahibi, kendi sisteminde belirli bir değere karşılık gelen kayıtlar açar ve her kayda eşleşen bir seri üretir. Kod, o kaydın anahtarıdır; kendi başına bir değeri yoktur, değeri yayıncının veritabanındaki karşılığından gelir. Bu yüzden dışarıdan "üretilen" bir dizi hiçbir zaman çalışmaz: sistemde karşılığı olmayan bir anahtar, kilidi olmayan bir anahtardan farksızdır. Bazı durumlarda üretim yetkisi sözleşmeyle bir distribütöre devredilir; distribütör yayıncının tahsis ettiği aralıktan kod basar. Ama üretim yetkisi hiçbir senaryoda perakende satıcıya inmez. Sen zincirin sonundasın ve orada yaptığın iş üretim değil, envanter ve teslimat yönetimidir. Bunu kabul etmek ilk bakışta iddiasız görünür; oysa işin bütün kârı tam bu iki kelimenin iyi yapılmasında saklıdır.
Bir kodun teknik olarak doğuşu: seri, havuz, aktivasyon
Kodun hayatı üç aşamada geçer. Birincisi seri üretimi: yayıncı, tahmin edilemez uzunlukta ve genelde kontrol hanesi taşıyan diziler üretir; kontrol hanesi sayesinde sistem, bir kodu sorgulamadan önce formatının bile geçerli olup olmadığını anlar. İkincisi havuz tahsisi: üretilen partiler kanallara ayrılır, bölge ve para birimi etiketlenir. Bir kodun neden "yanlış bölge" hatası verdiği bu adımda belirlenir. Üçüncüsü aktivasyon: müşteri kodu girdiğinde yayıncı sistemi kaydı bulur, tek kullanımlık olarak işaretler ve değeri hesaba yazar. Bu andan sonra kod ölür. Senin tarafındaki kritik nokta şudur: kodun ölümü yayıncı tarafında olur, ama kodun teslim edildiği an senin tarafında kayıt altına alınmalıdır. İki kaydın arasındaki boşluk ne kadar küçükse, yaşadığın itiraz da o kadar az olur. İyi tasarlanmış bir dijital ürün satış scripti bu yüzden kodu "gönderdim" diye değil, "şu saniyede şu siparişe kilitlendi" diye kaydeder.
Kodu kendin üretirsen ne olur (ve neden hiç olmaz)?
Bu sorunun teknik cevabı ilginçtir: matematiksel olarak doğru formatta bir dizi üretmek zor değil. Ancak formatı doğru olan dizi, karşılığı olmadığı için aktive edilemez. Yani ürettiğin şey kod değil, kod görünümlü bir metindir. Piyasada "çalışan üretici" iddiasıyla dolaşan araçların tamamı ya işe yaramaz çıktılar üretir ya da asıl amacı kullanıcının kendi bilgilerini toplamaktır. Bunun ötesinde, çalıştığı varsayılan bir senaryoda bile karşı tarafta yayıncı kayıtları, dolandırıcılık tespiti ve hukuki sonuç vardır. Ticari açıdan da anlamsızdır: bu işte kalıcı gelir, tedarik fiyatını iyileştirmek ve operasyonu otomatikleştirmekle gelir, kestirme yollarla değil. Kestirme yol arayan satıcı bir kez kazanır, sonra hesabını, itibarını ve tedarikçisini birlikte kaybeder.
| Halka | Ne yapar | Kod üretebilir mi? | Senin ilişkin |
|---|---|---|---|
| Yayıncı | Değeri ve kaydı oluşturur | Evet, tek gerçek kaynak | Genelde dolaylı |
| Distribütör | Bölgesel tahsis ve toptan dağıtım | Yetki devriyle kısmen | Büyük hacimde doğrudan |
| Bayi / toptancı | Partileri böler, API ile satar | Hayır | Ana tedarik kanalın |
| Perakende satıcı (sen) | Vitrin, tahsilat, teslimat | Hayır | Doğrudan müşteri |
| Şüpheli kaynak | Ucuz parti, belirsiz köken | Hayır | Kaçınılması gereken |
Tedarik zincirinin dördüncü halkası: bayi katmanını doğru okumak
Pratikte çoğu satıcı kodu bir bayi API'sinden alır. Burada dikkat edilecek şey fiyat değil, üç teknik ayrıntıdır. Birincisi idempotans: aynı sipariş için iki kez istek attığında bayi sana iki kod mu yoksa aynı kodu mu döner? Cevap "iki kod" ise ağ hatası her seferinde sana zarar yazar. İkincisi mutabakat: gün sonunda çekilen kodların listesini alıp kendi kayıtlarınla eşleştirebiliyor musun? Eşleşmeyen satır, kaybolmuş sermayedir. Üçüncüsü iade/iptal kuralı: çekilmiş ama teslim edilmemiş kodu geri verebiliyor musun? Bu üç soruyu sormayan satıcılar aradaki farkı ancak aylar sonra, envanterle ciro arasındaki açığı görünce keşfeder. Bir e-pin satış yazılımı seçerken bayi entegrasyonunun varlığı yeterli değildir; istek tekilleştirme, mutabakat raporu ve başarısız çekim kuyruğu da olmalıdır. Özellik sayfasında bu üç maddeyi arayarak bakmak, listedeki onlarca satırı okumaktan daha çok şey söyler.
Geçersiz kod şikâyetlerinin gerçek kaynak dağılımı
- Daha önce kullanılmış kod 50%
- Bölge/para birimi uyuşmazlığı 25%
- Süresi geçmiş parti 15%
- Yanlış ürün eşleşmesi 10%
Sahte ve çift satılmış kod nasıl ayırt edilir?
Geçersiz kod şikâyetinin büyük kısmı sahte koddan değil, daha önce kullanılmış koddan gelir. Bu da iki şeyden doğar: aynı kodun iki müşteriye gösterilmesi ya da tedarikçinin ikinci elden dolaşan parti satması. Kendini korumanın yolu üç katmanlıdır. Birinci katman tekillik: havuzdaki her satır yalnız bir siparişe kilitlenebilir ve bir kez gösterildikten sonra ikinci kez tam haliyle ekrana düşmez. İkinci katman köken kaydı: her kod satırında hangi tedarikçiden, hangi partiden, hangi tarihte geldiği yazılı olmalı; böylece bir şikâyette tek kodu değil, o partinin tamamını inceleyebilirsin. Üçüncü katman maskeleme ve erişim izi: personel panelinde kodlar maskeli görünmeli ve kim hangi kodu açtı bilgisi tutulmalı. İçeriden sızma vakalarının neredeyse tamamı, bu üçüncü katmanın olmadığı sistemlerde yaşanır.
Havuza kod yüklerken her yüklemeye bir parti etiketi ver: tedarikçi, tarih, adet. Tek bir şikâyet geldiğinde o partinin tamamını tarayabilir, gerekiyorsa satışı durdurabilirsin. Bu alışkanlık, tek bir kötü partinin bütün itibarını yakmasını engeller.
Scriptin kod havuzunu nasıl korumalı?
Kod havuzu senin kasandır; dolayısıyla ona kasa gibi davranan bir sistem gerekir. Aradığın davranış şudur: ödeme onaylanmadan havuzdan satır çıkmaz, çıkan satır rezerve durumuna geçer, teslimat tamamlanınca kapanır, ödeme başarısız olursa satır havuza geri döner. Bu döngünün her adımı zaman damgalı olmalı. Üstüne düşük stok uyarısı, süresi yaklaşan parti bildirimi ve ürün-parti eşleşme kontrolü eklendiğinde ölü stok riski büyük ölçüde kapanır. Pinova'nın kod tarafındaki mantığı bu çerçeveye oturur: havuz düz bir liste değil, durum geçişleri kayıt altına alınan bir envanterdir. Böyle bir yapıda bir itirazla karşılaştığında elinde tartışmayı kapatan tek bir ekran olur. Ölçek büyüdükçe bu ekranın değeri de büyür; paket seçimini yaparken bugünkü sipariş sayına değil, altı ay sonraki havuz büyüklüğüne göre karar vermek daha akıllıdır.
| Kontrol listesi | Neyi engeller | Durum |
|---|---|---|
| Ödeme onayı öncesi kod çıkışı yok | Boşa yakılan stok | Zorunlu |
| Rezerve → teslim → kapat akışı | Çift teslimat | Zorunlu |
| Parti ve tedarikçi etiketi | Kötü partinin yayılması | Zorunlu |
| Panelde maskeli kod + erişim izi | İçeriden sızma | Zorunlu |
| Bayi isteğinde tekilleştirme | Mükerrer çekim zararı | Zorunlu |
| Gün sonu mutabakat raporu | Envanter-ciro açığı | Önerilir |
| Süresi yaklaşan parti uyarısı | Ölü stok | Önerilir |
| Bölge/para birimi kontrolü | Yanlış bölge şikâyeti | Önerilir |
Kod havuzuna kasa gibi davranan bir altyapı kur
Pinova, rezerve akışı, parti takibi, maskeleme ve mutabakat mantığıyla e-pin envanterini yönetmek için tasarlanmış lisanslı bir satış yönetim yazılımıdır.
E-pin kodunu satıcı olarak kendim üretebilir miyim?
Hayır. Geçerli bir kod yalnızca yayıncının sisteminde karşılığı olan bir kayıtla doğar. Dışarıdan üretilen diziler doğru formatta olsa bile aktive edilemez; bu iddiayla dolaşan araçlar ya işlevsizdir ya da kullanıcı bilgisi toplamayı amaçlar.
Kod partisi alırken nelere bakmalıyım?
Kökenin belgeli olmasına, bölge ve para birimi etiketine, varsa son kullanma tarihine ve iade/iptal koşullarına bak. Piyasa fiyatının belirgin biçimde altındaki teklifler genelde ikinci elden dolaşan ya da kısmen kullanılmış partilerdir.
Müşteri "kod daha önce kullanılmış" diyorsa ne yapmalıyım?
Önce kendi kaydına bak: o kod hangi siparişe, hangi saatte kilitlendi ve kaç kez görüntülendi. Tek teslimat kaydı varsa sorun tedarik kaynaklıdır ve aynı partideki diğer kodları da incelemen gerekir. Kaydın yoksa tartışmayı kaybedersin; bu yüzden log şart.
Bayi API'si kullanmak kendi havuzumu tutmaktan daha güvenli mi?
İkisi farklı riskler taşır. API tarafında stok riski azalır ama mükerrer çekim ve mutabakat riski doğar; kendi havuzunda kontrol artar, karşılığında ölü stok ve saklama riski gelir. Sağlıklı yapı, çok satan üründe kendi havuzunu, değişken üründe API'yi kullanmaktır.
Toparlayalım: e-pin kodu üretmek senin işin değil, kodu tek bir müşteriye izi sürülebilir biçimde teslim etmek senin işin. Zincirdeki yerini bilmek ucuz partilerin cazibesine karşı en iyi korumadır, havuzunu kasa gibi yönetmek ise itibarını koruyan tek sistemdir. Rezerve akışının, parti etiketinin ve teslimat logunun pratikte nasıl göründüğünü kendi gözünle görmek istersen canlı demo üzerinde bir ürüne örnek kod havuzu yükleyip test siparişi geçmen, anlatılanların hepsini tek turda somutlaştıracaktır.