E-pin Satış Scripti Kurulumunda Herkesin Aynı Yerde Tökezlediği Hatalar: Sistemin Çalışıyor Görünürken Aslında Neden Sızdırdığını Anlatıyorum

Kurulum hataları hakkında yaygın bir yanlış inanç var: insanlar hatanın kendini bir hata mesajıyla göstereceğini sanır. Kırmızı bir uyarı, beyaz bir ekran, 500 hatası... Gerçekte bir e-pin satış scripti kurulumundaki ciddi hataların büyük bölümü hiçbir mesaj üretmez. Site açılır, ürünler listelenir, sepet çalışır, ödeme sayfası gelir. Her şey yolunda görünür. Sorun, o yolunda görünen sistemin belirli bir senaryoda sessizce yanlış davranmasıdır.

Bu yüzden kurulum denetimini "açılıyor mu" sorusuyla yapmak yetersizdir. Doğru soru şudur: hangi senaryoda bu sistem yanlış davranır ve ben bunu ne zaman fark ederim? Aşağıda, e-pin ve dijital ürün satışı yapan işletmelerin kurulum sonrası ilk iki haftada çarptığı hataları belirtileriyle, kök nedeniyle ve düzeltme yöntemiyle tek tek açıyorum. Pinova gibi lisanslı bir e-pin yazılımı bu tuzakların çoğunu varsayılan olarak kapatır; ama sunucu ve entegrasyon tarafı her zaman senin elindedir.

Hata neden kurulumda değil, kurulum sonrası ilk haftada ortaya çıkıyor?

Çünkü kurulum anında sistem üzerinde yalnızca mutlu yol denenir. Kurulumu yapan kişi bir ürün ekler, kendi adına bir sipariş oluşturur, kodu teslim edildiğini görür ve işi tamam sayar. O sırada denenmeyen şeyler şunlardır: ödeme yarıda bırakılırsa ne olur, iki kişi son stoğu aynı anda alırsa ne olur, tedarikçi cevap vermezse ne olur, kart itirazı gelirse ne olur, e-posta sağlayıcısı gönderimi reddederse ne olur?

Bu senaryolar ilk günde değil, gerçek trafik gelince oluşur. Gerçek müşteri sabırsızdır, sekmesini kapatır, farklı tarayıcı kullanır, yanlış e-posta yazar, aynı ürünü iki kez satın alır. Kurulum testini müşteri yapar ve maalesef bunun faturasını sana keser. O yüzden aşağıdaki hataları okurken "bende yok" demek yerine "bu senaryoyu hiç denedim mi" diye sor.

1. Hata: Yetersiz sunucu seçip zamanlanmış görevleri hiç kurmamak

En yaygın hata bu. Dijital ürün satış scripti kurulumu için en ucuz paylaşımlı paket alınır, kurulum tamamlanır, ancak cron desteği ya yoktur ya da kurulmaz. Sonuç, tam olarak bir otomasyon yazılımını manuel bir tabloya dönüştürmektir: kur güncellenmez, tedarikçi stoğu senkronlanmaz, bekleyen siparişler temizlenmez, terk edilmiş sepet hatırlatması gitmez.

İkinci katman, PHP sınırlarıdır. Düşük max_execution_time, düşük bellek limiti ve kapalı outbound bağlantılar; toplu kod yükleme veya tedarikçi API çağrısı gibi işlerde işi yarıda kestirir. Kötüsü, yarıda kesilen bir toplu stok yüklemesi bazen yarısı yüklenmiş bir havuz bırakır ve sen bunu ancak müşteri geçersiz kod bildirdiğinde anlarsın. Düzeltme: cron'u kur, görev günlüğünü aç, PHP limitlerini yükselt ve toplu işlemleri parça parça çalışan kuyruk mantığıyla yürüt.

2. Hata: Dosya izinlerini 777'ye çekip "çalıştı" demek

Kurulum sırasında bir yazma hatası alındığında en hızlı çözüm izinleri sonuna kadar açmaktır. İşe yarar; kurulum ilerler. Ama böylece web sunucusunun çalıştırabildiği her dosyaya yazma hakkı verilmiş olur. Bir e-pin satış yazılımı, içinde kullanılmamış kod havuzu tutan bir kasadır; bu kasanın kapısını rahatlık uğruna açık bırakmak, ilerideki en pahalı hatadır.

Doğru yaklaşım cerrahidir: dizinler 755, dosyalar 644, yazma hakkı sadece yükleme, önbellek ve günlük klasörlerinde. Yapılandırma dosyasını mümkünse web kökünün dışına taşı; taşıyamıyorsan doğrudan erişimi sunucu seviyesinde kapat. Kurulum sihirbazı dosyasını iş bittikten sonra sil; unutulan bir kurulum betiği, veritabanını sıfırlayabilecek en tuhaf açıktır. Yönetici paneli yolunu varsayılan bırakma ve iki adımlı doğrulamayı ilk gün aç.

3. Hata: Ödeme dönüşünü test etmeden canlıya almak

Ödeme entegrasyonunun iki ayağı vardır: müşterinin gördüğü dönüş sayfası ve sunucunun aldığı bildirim çağrısı. İşletmeciler neredeyse her zaman ilkini test eder, ikincisini atlar. Çünkü dönüş sayfası çalışınca ekranda "ödeme başarılı" yazar ve iş bitmiş görünür. Oysa siparişi gerçekten tamamlayan, teslimatı tetikleyen ve stoğu düşen şey arka plandaki bildirimdir.

Bu ayak eksikse belirti şudur: ödeme alınmış, panelde sipariş bekliyor durumunda. Müşteri yazar, sen elle onaylarsın, kimse bunun bir arıza olduğunu fark etmez; her gün on kez tekrar eder. Kök nedenler genellikle basittir: bildirim adresi yanlış, güvenlik duvarı sağlayıcı IP'lerini engelliyor, imza doğrulaması yanlış anahtarla yapılıyor, ya da bildirim HTTPS zorunluluğunu karşılamıyor. Çözüm tek bir şey: canlıya geçmeden önce gerçek kartla küçük tutarlı bir sipariş verip zincirin her halkasını gözle doğrulamak.

4. Hata: Stok verisini tek sütuna sıkıştırmak

Toplu kod aktarımında hız uğruna her şey tek alana yazılır. Kod, seri numarası, bölge, son kullanma tarihi, tedarikçi referansı hepsi aynı hücrede. Aktarım tamamlanır, sistem kodları satar. Sonra ilk sorun gelir: müşteri kodun bölgesinin uyumsuz olduğunu söyler. Hangi partiden geldiğini bilmiyorsundur, hangi tedarikçiye geri dönüleceğini bilmiyorsundur, süresi geçmiş kodları ayırt edemiyorsundur.

Doğru kurgu, her bilginin kendi alanında durmasıdır. Bölge ayrı, son tarih ayrı, tedarikçi ve parti ayrı. Bu sayede süresi yaklaşan kodları uyarıyla önceliklendirir, sorunlu partiyi tek tuşla karantinaya alır, tedarikçi bazlı iade talebini kanıtla açarsın. Ayrıca içe aktarımda yinelenen kod kontrolü şart: aynı kodun iki kez havuza girmesi, iki müşteriye aynı ürünü satmak demektir ve bu hatayı telafi etmenin ucuz bir yolu yoktur.

5. Hata: Saat dilimi, para birimi ve yuvarlama üçlüsünü ihmal etmek

Sunucu UTC, panel Türkiye saati, ödeme sağlayıcısı kendi zaman damgasını kullanıyor. Kurulum sırasında kimse bunu düşünmez çünkü tek başına hiçbir şeyi bozmaz. Bozulma raporda başlar: günlük satış toplamı üç saat kaymış çıkar, kampanya gece yarısı değil sabaha karşı biter, sipariş zaman aşımı süresi beklediğinden farklı çalışır, mutabakatta hangi işlemin hangi güne ait olduğu karışır.

Aynı ihmalin para birimi tarafı da vardır. Ondalık hassasiyeti veritabanında yetersizse kuruşlar yuvarlanır; yüz siparişte fark edilmez, on bin siparişte kasada gerçek bir sapma oluşur. Kurulumda üç yeri hizala: sunucu saati, uygulama saat dilimi ve veritabanı oturum saati. Para tarafında ise tutarları ondalık alanla tut, kayan noktalı hesaptan uzak dur ve yuvarlamayı yalnızca gösterim katmanında yap.

6. Hata: Yedeği aynı sunucuda tutmak ve hiç geri yüklemeyi denememek

Bu hatanın özelliği, bedelini ödeyene kadar hiçbir maliyeti olmamasıdır. Yedekleme açıktır, arşivler her gece oluşur, panelde yeşil bir onay görünür. Ama arşivler sitenin yaşadığı sunucuda durur. Sunucu diski bozulduğunda, hesap askıya alındığında veya bir yapılandırma hatasıyla dizin silindiğinde hem site hem yedek aynı anda gider.

İkinci katman, hiç denenmemiş yedektir. Kurulum sonrası yedeği bir kez ayrı bir ortama açıp geri yüklemeyi denemeyen işletmelerin yarısında arşivin eksik olduğu ortaya çıkar: veritabanı var dosyalar yok, dosyalar var yüklenen görseller yok, ya da bir tabloda karakter kodlaması bozulmuş. Yedek, geri yüklenebildiği kanıtlandığı gün yedek olur. Bunu bir kez yapıp not al, ardından ayda bir tekrarla; kurulum hatalarının en pahalısına karşı en ucuz sigortadır.

Kurulum hatalarının ortak özelliği, hepsinin önceden bilinebilir olmasıdır. Listeyi elinde tutup tek tek doğruladığında iki haftaya yayılacak sürprizleri iki saate sıkıştırırsın. Bu denetimi kendi ürünlerinle prova etmek istiyorsan canlı demo üzerinden bir stok havuzu oluştur, test siparişi geç ve zincirin her adımını gözlerinle takip et; ardından özellik listesine dönüp hangi kontrollerin hazır geldiğini karşılaştır.