Çoğu kişi sipariş geçmişini basit bir liste sanır. Tarih, tutar, ürün adı; müşteri girer, bakar, çıkar. Oysa e-pin ve dijital ürün satan bir işletmede sipariş geçmişi bir liste değil, hukuki ve operasyonel bir kanıt defteridir. Fiziksel üründe kargo takip numarası senin yerine konuşur; dijital üründe ise konuşacak tek şey, kodun kime, hangi saniyede, hangi IP'den, kaç kez gösterildiğidir. Bu veriyi tutmayan bir e-pin scripti, ilk ciddi itirazda seni savunmasız bırakır.
İşin ilginç tarafı şu: bayilerin çoğu bu eksiği satış hacmi büyüyene kadar fark etmez. Günde on beş sipariş varken WhatsApp'tan "abi kodu tekrar atar mısın" mesajına elle cevap verirsin. Günde üç yüz siparişte aynı mesaj günde kırk kez gelir ve artık hangi kodun gerçekten teslim edildiğini, hangisinin kullanıldığını bilemezsin. İşte tam bu noktada dijital ürün satış scripti seçerken bakman gereken şey arayüzün güzelliği değil, arşiv mimarisinin derinliğidir. Bu yazıda o mimariyi, Pinova gibi profesyonel bir e-pin satış yazılımının arka planda ne tuttuğunu ve senin hangi alanları mutlaka sorman gerektiğini tek tek açıyorum.
Sipariş geçmişi neden bir "liste" değil, olay akışıdır?
Bir siparişin ömrü tek satırda bitmez. Ödeme başlar, sağlayıcı onay döner, stoktan kod ayrılır, kod müşteriye gösterilir, müşteri kodu kopyalar, belki iade talep eder. Bunların hepsi ayrı olaylardır ve tek bir durum alanında saklanamaz. Doğru kurgu, siparişin yanında değiştirilemez bir olay tablosu tutmaktır: her satır bir zaman damgası, bir aktör (müşteri, yönetici, sistem), bir eylem ve bir bağlam taşır. Bu yaklaşım, "sipariş neden iptal oldu" sorusunu tahmine değil kayda dayanarak cevaplamanı sağlar.
Olay akışının ikinci faydası, geriye dönük düzeltmedir. Diyelim ki bir ürünün yanlış stok havuzuna bağlandığını üç gün sonra fark ettin. Olay kaydı varsa, o üç gün içinde hangi siparişlerin hangi havuzdan beslendiğini filtreleyip yalnızca etkilenenleri telafi edersin. Olay kaydı yoksa ya herkese telafi verirsin ya da hiç kimseye veremezsin; ikisi de pahalıdır.
Kod arşivi nerede durmalı: veritabanında mı, şifreli kasada mı?
Bu, e-pin satış scripti değerlendirirken sorulacak en kritik teknik sorudur. Kodların düz metin olarak veritabanı sütununda durması en yaygın ve en tehlikeli yöntemdir. Bir yedek dosyası dışarı sızdığında, o dosyayı açan herkes tüm stok değerini eline geçirir. Doğru yöntem, kod gövdesinin uygulama seviyesinde şifrelenmesi ve şifre anahtarının veritabanından bağımsız bir yerde, tercihen web kökünün dışındaki bir yapılandırma dosyasında tutulmasıdır.
Burada ölçülü olmak gerekir: aşırı şifreleme, arama ve raporlamayı imkânsız hale getirir. Pratik çözüm ikili yapıdır. Kodun kendisi şifreli saklanır; kodun parmak izi (kısaltılmış özet değeri) ayrı bir sütunda açık tutulur. Böylece "bu kod daha önce satıldı mı" sorusunu şifre çözmeden, tek sorguda cevaplarsın. Mükerrer kod satışı, e-pin işinde en çok itibar yakan hatadır ve parmak izi sütunu onu doğrudan engeller.
| Arşiv Katmanı | Ne Tutar | Saklama Biçimi | Erişim Yetkisi | Tipik Ömür |
|---|---|---|---|---|
| Sipariş başlığı | Müşteri, tutar, ödeme yöntemi, durum | Açık | Müşteri + yönetici | Süresiz |
| Olay akışı | Zaman damgalı eylem kayıtları | Açık, salt-yazılır | Yönetici | Süresiz |
| Kod gövdesi | Gerçek e-pin veya seri anahtar | Şifreli | Sahip müşteri + yönetici | Teslimden sonra 12 ay |
| Kod parmak izi | Özet değer | Açık, benzersiz indeks | Sadece sistem | Süresiz |
| Teslim kanıtı | IP, tarayıcı izi, görüntüleme sayısı | Açık | Yönetici | 24 ay |
| Fatura belgesi | PDF ve vergi alanları | Dosya deposu | Müşteri + muhasebe | 10 yıl |
"Kodu göremiyorum" itirazını bitiren görüntüleme sayacı nedir?
Dijital satışta en sık yaşanan çatışma, müşterinin kodu gördüğünü inkâr etmesidir. Buna karşı en sade savunma, kodun her açılışında sayaç artıran ve o anın kaydını tutan bir mekanizmadır. Müşteri paneline girdi, siparişi açtı, kod alanı gösterildi: bu üç adım tek bir kayda dönüşür. İyi bir epin yazılım altyapısında bu kayıt müşteriye de görünür; çünkü şeffaflık, itirazın kendisini daha başlamadan azaltır.
Sayaç kurgusunda ince bir ayrıntı var: kodu ilk gösterimde tam, sonraki gösterimlerde maskeli sunmak. Müşteri koda tekrar baktığında yalnızca son dört karakteri görür, tamamını istemek için bir buton kullanır ve bu talep de kaydedilir. Bu küçük tasarım kararı, hem ekran görüntüsü paylaşımını zorlaştırır hem de gerçek ihtiyaç ile alışkanlık kaynaklı tıklamayı birbirinden ayırır.
Kod Arşivine Yönelik Destek Taleplerinin Dağılımı
- Kodu bulamıyorum 45%
- Kod çalışmıyor iddiası 25%
- Fatura ve belge talebi 20%
- Eski sipariş sorgusu 10%
Arama ve filtreleme mimarisi neden performansı belirler?
Arşiv büyüdükçe panelin yavaşlaması kaçınılmaz değildir; kötü indekslemenin sonucudur. Sipariş tablosunda en az üç bileşik indeks olmalıdır: müşteri kimliği ile tarih, durum ile tarih, ve ödeme referansı. Yönetici panelindeki her filtre bu indekslerden birine oturmalı; oturmayan filtre tam tablo taraması yapar ve yüz bin kayıttan sonra sayfayı kilitler.
İkinci mesele sayfalamadır. Klasik "kaçıncı sayfadan başla" yöntemi derin sayfalarda ağırlaşır; imleç tabanlı sayfalama, yani son görülen kaydın anahtarından devam etme yöntemi sabit hızda çalışır. Dijital ürün satış yazılımı seçerken demo panelinde elli bin kayıtlık bir veriyle arama yapmayı iste. Boş bir demoda her sistem hızlıdır.
Yedekleme olmadan arşiv sadece bir hikâyedir
Arşivin değeri, onu kaybetmediğin sürece vardır. Günlük tam yedek, saatlik artımlı yedek ve en az bir sunucu dışı kopya asgari kuraldır. Ancak asıl kritik nokta, yedeğin geri dönülebilir olduğunun test edilmesidir. Hiç açılmamış bir yedek, olmayan yedekle aynıdır. Ayda bir kez boş bir ortama geri yükleme denemesi yap; kaç dakikada ayağa kalktığını not et. O süre senin gerçek kesinti sürendir.
Şifreli kod sütunları için ek bir kural daha var: anahtar dosyasının yedeği, veritabanı yedeğiyle aynı yerde durmamalıdır. İkisini aynı arşive koyarsan şifrelemenin koruma değeri sıfırlanır.
Sipariş kayıtlarını asla fiziksel olarak silme. Bunun yerine arşiv bayrağı kullan; kayıt panelden düşer ama veri ve kanıt zinciri bozulmaz.
Kurulum öncesi kontrol listesi: neyi sormalısın?
Yazılım değerlendirirken arayüz turuna kapılmak kolaydır. Aşağıdaki tabloyu yanına al ve her maddeyi demo üzerinde canlı olarak doğrula. Cevabı "planlıyoruz" olan maddeler bugün yoktur.
| Kontrol Maddesi | Nasıl Test Edilir | Beklenen Sonuç |
|---|---|---|
| Kod şifreleme | Veritabanı satırını doğrudan görüntüle | Okunamaz veri |
| Mükerrer kod engeli | Aynı kodu iki kez stoğa yükle | Sistem ikinciyi reddeder |
| Görüntüleme logu | Kodu üç kez aç | Üç ayrı kayıt oluşur |
| Toplu dışa aktarım | Tarih aralığı ile tablo indir | Saniyeler içinde dosya |
| Yönetici işlem izi | Bir siparişi elle iptal et | Kim, ne zaman, neden kaydı |
| Sayfalama hızı | Son sayfaya atla | Gözle görülür gecikme yok |
| Yedek geri yükleme | Sağlayıcıdan prosedür iste | Yazılı, test edilmiş adımlar |
Arşivini rastgeleye bırakma
Pinova, sipariş olay akışı, şifreli kod kasası ve teslim kanıtı katmanlarını kutudan çıktığı gibi sunar. Özellik listesini incele, sonra kendi verinle dene.
Kod arşivini ne kadar süre saklamalıyım?
Teslim edilen kod gövdesini 12 ay tutmak çoğu senaryo için yeterlidir; ancak sipariş başlığı, fatura ve olay akışı kayıtlarını ticari saklama yükümlülükleri gereği çok daha uzun süre, pratikte on yıl ölçeğinde muhafaza etmen beklenir.
Müşteri eski siparişini kendisi görebilmeli mi?
Evet. Müşterinin kendi geçmişine erişebilmesi destek yükünü belirgin biçimde düşürür. Kod gövdesini maskeli göster, tam görüntüleme talebini ayrı bir eylem olarak kaydet.
Şifreli kod saklamak paneli yavaşlatır mı?
Hayır, doğru kurguda yavaşlamaz. Şifre çözme yalnızca tek bir kodun gösterildiği anda yapılır; listeleme ve arama işlemleri açık tutulan parmak izi ve durum sütunları üzerinden yürür.
Elle düzeltme yaptığımda iz kalmalı mı?
Kesinlikle. Yönetici müdahaleleri ayrı bir işlem izi tablosuna yazılmalı, hangi alanın eski ve yeni değerinin ne olduğu görünmelidir. Bu kayıt, ekip büyüdüğünde iç denetimin tek dayanağıdır.
Sipariş geçmişi ve kod arşivi, panelinin en az bakılan ama en çok işe yarayan bölümüdür. Bir gün mutlaka bir itiraz, bir iade ya da bir denetim talebi gelir; o gün elinde ne varsa onunla savunursun. Kurduğun altyapının bu yükü kaldırıp kaldırmadığını görmek için canlı demo üzerinden bir test siparişi oluştur, kodu birkaç kez aç ve arkasında hangi kayıtların biriktiğine kendi gözünle bak; fiyatlandırma sayfasında hangi paketin arşiv ihtiyacına yettiğini de birlikte değerlendirebilirsin.