Sabah panele girdiğinizde bir bayinizin dün yatırdığı bakiyenin sıfırlandığını, ya da hiç işlem yapmadığı halde cüzdanının eksiye düştüğünü görmek kadar can sıkıcı bir şey yoktur. Bu tür bir hata bir kere yaşandığında bile bayi güveni ciddi şekilde sarsılır, çünkü cüzdan bakiyesi bir e-pin sitesinde paradan farksızdır. İşin kötü tarafı, bu sorunun kaynağı çoğu zaman "gizemli bir bug" değil, alt yapının bakiyeyi nasıl hesapladığıyla ilgili çok somut ve önlenebilir tasarım hatalarıdır.
Cüzdan Bakiyesi Neden Aniden Sıfırlanır veya Eksilir?
Bakiye sıfırlanması ya da beklenmedik şekilde değişmesi genelde tek bir nedene bağlanamaz; birden fazla küçük hatanın üst üste binmesiyle ortaya çıkar. En sık rastlanan tetikleyiciler şunlardır:
- Bakiyenin veritabanında tek bir sabit sütun olarak tutulup, her işlemde doğrudan üzerine yazılması (toplama/çıkarma yerine).
- Sayfa yenilenirken veya oturum süresi dolarken cüzdan verisinin önbellekten eski/boş değerle tekrar yüklenmesi.
- Bir işlem sırasında sunucu zaman aşımına uğrarken bakiye önce düşülüp, iade adımının hiç çalışmaması.
- Aynı anda açılan iki sekmeden gönderilen isteklerin bakiyeyi birbirinin üzerine yazması.
Bu maddelerin ortak noktası şudur: bakiye, güvenilir bir "işlem defteri" yerine değişken bir sayı gibi ele alınmıştır. Oysa doğru yaklaşım, her artış ve azalışı ayrı bir kayıt olarak tutup güncel bakiyeyi bu kayıtların toplamından türetmektir. Pinova'da cüzdan bu mantıkla çalışır; her yükleme, harcama ve iade kendi satırına yazılır, ekranda gösterilen rakam bu satırların canlı toplamıdır.
Bayi Sipariş İptallerinde Bakiye Neden Tutmaz?
Çok seviyeli bayilik sistemlerinde en riskli an, bir siparişin iptal edilmesi veya iade edilmesi anıdır. Bakiye önce sipariş anında düşülür, ürün tedarikçiden (Turkpin, Pinabi gibi) gelmezse iade edilmesi gerekir. Bu iade adımı elle yapılıyorsa ya da yazılım tarafında "önce düş, sonra kontrol et" sırası yanlış kurgulanmışsa şu senaryolar ortaya çıkar:
- Tedarikçi API'sinden hata dönmesine rağmen bakiye zaten düşülmüş olur ve kimse fark etmeden kalır.
- Bayi siparişi iptal eder, sistem bakiyeyi iade eder ama aynı anda ikinci bir yenileme isteği eski (düşük) bakiyeyi tekrar kaydeder.
- Kısmi iadelerde (örneğin 5 adetlik siparişin 2'si başarısız) tutar hesaplaması yanlış yapılıp toplam bakiyeyi bozar.
Bu noktada kritik olan, iade işleminin de tıpkı harcama gibi kendi kaydına sahip olması ve sipariş durumuyla senkron çalışmasıdır. Pinova'da sipariş iptal/iade akışı otomatik tetiklenir ve tedarikçi cevabına göre bakiye satırı oluşturur; elle "bakiyeyi düzelt" butonuna basmaya gerek kalmaz.
Eşzamanlı İşlemler (Race Condition) Bakiyeyi Nasıl Bozar?
E-pin siteleri doğası gereği yoğun saatlerde çok sayıda eşzamanlı işlem alır: aynı bayi birden fazla sekmede sipariş verebilir, otomatik teslimat botları saniyede birkaç isteği işleyebilir. Bakiye kontrolü ile bakiye düşme işlemi arasında küçük bir zaman farkı varsa, iki işlem aynı anda "bakiyem yeterli" kontrolünü geçip ikisi de para düşürebilir — sonuçta bayi bakiyesi olması gerekenden fazla eksilir.
Bu tip hatalar test ortamında neredeyse hiç görülmez çünkü tek kullanıcı tek işlem yapar; sorun yalnızca gerçek trafik altında, özellikle yoğun kampanya günlerinde ortaya çıkar. Bu yüzden bir e-pin scriptinin bakiye mantığını değerlendirirken "az sipariş varken çalışıyor mu" değil, "aynı anda çok işlem gelirse ne olur" sorusunu sormak gerekir.
| Senaryo | Manuel / Elle | Pinova ile |
|---|---|---|
| Sipariş iptalinde bakiye iadesi | Admin panelden elle bulunup düzeltilir, unutulma riski yüksek | Sipariş durumuna bağlı otomatik iade, kayıt otomatik oluşur |
| Aynı anda gelen çoklu sipariş | Bakiye kontrolü çakışabilir, eksi bakiye oluşabilir | İşlem kilitleme ile sıralı işlenir, çakışma önlenir |
| Bakiye geçmişini görme | Genelde tutulmaz, sorun anında kanıt yok | Her hareket ayrı satır olarak loglanır, geriye dönük izlenir |
| Yanlış bakiye tespiti | Bayi şikayet edene kadar fark edilmez | Bakiye = hareket toplamı olduğu için tutarsızlık anında görülür |
| Tedarikçi API hatası sonrası bakiye | Elle takip gerekir, sık sık atlanır | API cevabına göre otomatik düşme/iade mantığı çalışır |
Manuel Bakiye Düzeltmesi Neden Yeni Sorunlar Doğurur?
Bir bayi "bakiyem eksik" dediğinde birçok site sahibi admin panelden bakiyeyi elle güncelleyerek sorunu "çözer". Kısa vadede işe yarasa da bu yöntem aslında sorunun kaynağını değil belirtisini ortadan kaldırır. Zamanla şu problemler birikir:
- Elle yapılan her düzeltme, neden yapıldığına dair bir kayıt bırakmaz; altı ay sonra "bu +50 TL neden eklenmiş" sorusuna cevap veremezsiniz.
- Aynı köksel hata (senkronizasyon, race condition, iade akışı) düzeltilmediği için sorun tekrar tekrar yaşanır, her seferinde manuel müdahale gerekir.
- Farklı yetkili kişiler farklı zamanlarda bakiye düzelttiğinde, kimin ne zaman ne yaptığı karışır ve muhasebe uyuşmazlığı büyür.
Manuel düzeltme, ancak altyapı sağlam olduğunda gerçekten istisnai bir durum olarak kalabilir. Asıl hedef, düzeltmeye ihtiyaç bırakmayan bir bakiye mimarisi kurmaktır.
Bakiyeyi tek bir sayı olarak değil, "hareket kayıtlarının toplamı" olarak tasarlayın. Her yükleme, harcama, iade ve iptal ayrı bir satır olsun; ekranda gösterilen rakam bu satırlardan hesaplansın. Bu tek değişiklik, sıfırlanma ve tutarsızlık şikayetlerinin büyük kısmını daha altyapı seviyesinde ortadan kaldırır.
İşlem Geçmişi Tutulmazsa Sorunu Nasıl Çözersiniz?
Bir bayi "bakiyem eksildi" dediğinde elinizde detaylı bir hareket dökümü yoksa, tartışma sizin aleyhinize döner; ne siz haklı olduğunuzu kanıtlayabilirsiniz ne de bayi neyin yanlış gittiğini anlayabilir. İşlem geçmişi eksik olan sitelerde destek süreci genelde şöyle işler: bayi şikayet eder, admin veritabanını elle kurcalar, tahmine dayalı bir düzeltme yapılır, güven biraz daha azalır.
Sağlıklı bir sistemde her cüzdan hareketinin en azından şu bilgileri taşıması gerekir:
- İşlem tipi (yükleme, sipariş, iade, bonus, düzeltme)
- Tarih-saat ve işlemi tetikleyen kaynak (bayi, sistem, admin)
- İşlem öncesi ve sonrası bakiye
- İlgili sipariş veya ödeme referans numarası
Bu bilgiler tutulduğunda, bir uyuşmazlık çıktığında dakikalar içinde "hangi işlem, hangi anda, ne kadar" sorusuna net cevap verebilirsiniz. Pinova panelinde bayi ve admin, cüzdan geçmişini bu detaylarla görebildiği için tartışmalı durumlarda ispat yükü ekran görüntüsüne değil, sistem kaydına dayanır.
Cüzdan Güvenliğini Kalıcı Olarak Nasıl Sağlarsınız?
Bakiye sorunlarını kökten çözmek, tek seferlik bir yama değil, sürekli uygulanan birkaç prensiple mümkündür:
- Hareket bazlı bakiye: Bakiyeyi doğrudan güncellemek yerine, her işlemi ayrı kayıt olarak ekleyip toplamdan hesaplayın.
- İşlem kilitleme: Aynı cüzdana eşzamanlı gelen istekleri sıraya alarak çakışmayı önleyin.
- Otomatik iade akışı: Tedarikçi hatası veya sipariş iptalinde bakiyenin sistem tarafından, elle müdahale gerekmeden geri yüklenmesini sağlayın.
- Görünür işlem geçmişi: Bayilerin kendi hareketlerini görebilmesi, hem güveni artırır hem destek yükünü azaltır.
- Düzenli mutabakat: Sistem bakiyesi ile ödeme sağlayıcı (PayTR, Shopier, havale) kayıtlarının periyodik olarak karşılaştırılması.
Bu prensipler kağıt üzerinde basit görünse de, sıfırdan yazılan veya eklenti üstüne eklenti ile büyütülmüş sitelerde uygulamak zaman alır. Bu yüzden hazır ve bu sorunları önceden çözmüş bir altyapı üzerine kurmak, uzun vadede hem daha az destek talebi hem de daha sağlam bir bayi ilişkisi anlamına gelir.
Bakiye Sorunlarını Bir Daha Yaşamak İstemiyor musunuz?
Pinova, hareket bazlı cüzdan mimarisi, otomatik iade akışı ve şeffaf işlem geçmişiyle bu sorunları altyapı seviyesinde önler; kendi sunucunuza kurup bayilerinize güven veren bir sistem sunabilirsiniz.
Cüzdan bakiyesi neden sıfırlanır?
Genelde bakiyenin tek bir sabit değer olarak tutulup üzerine yazılması, senkronizasyon hataları veya oturum/önbellek sorunları nedeniyle olur. Doğru çözüm, bakiyeyi hareket kayıtlarının toplamı olarak hesaplamaktır.
Bayi sipariş iptal ettiğinde bakiye otomatik iade edilir mi?
Pinova'da evet; sipariş durumu değiştiğinde iade işlemi otomatik tetiklenir ve kendi hareket kaydını oluşturur, elle düzeltme gerekmez.
Aynı anda birden fazla işlem yapılırsa bakiye bozulur mu?
Bakiye kontrolü ile düşme işlemi arasında kilitleme yapılmayan sistemlerde evet, bu risk yüksektir. Pinova işlem kilitleme mekanizmasıyla eşzamanlı istekleri sıraya alır.
Geçmişte yaşanan bakiye hatalarını nasıl tespit ederim?
Her cüzdan hareketinin ayrı kayıt olarak tutulduğu bir sistemde işlem öncesi/sonrası bakiye ve referans bilgisiyle geriye dönük inceleme yapılabilir; Pinova panelinde bu geçmiş hem admin hem bayi tarafından görüntülenebilir.