Çoğu satıcı bakiye ile ödemeyi tek satırlık bir iş sanır: kullanıcının bakiyesinden tutarı düş, siparişi oluştur, kodu gönder. Gerçekte o butona basıldığı anda arka planda birbirine bağlı yedi ayrı adım tetiklenir ve bu adımların herhangi birinde yarım kalan bir işlem, ya müşteriye bedava ürün ya sana açıklanamayan bir kasa açığı bırakır. Sorunun sinsi tarafı da bu: hata hemen görünmez, üç ay sonra mutabakatta ortaya çıkar.
Kullandığın dijital ürün satış scripti bu akışı "düş-sat-bitir" olarak kodladıysa, hacim arttığında mutlaka duvara çarpar. Sağlam kurulmuş bir e-pin satış yazılımı ise ödemeyi tek bir atomik iş olarak ele alır: ya hepsi olur ya hiçbiri. Bu yazıda o akışı adım adım açıp, en çok hangi noktada para kaybedildiğini net biçimde göstereceğiz.
"Bakiyemle öde" butonunun arkasında gerçekte ne oluyor?
Doğru kurulmuş bir akışta sıra şudur: önce sepet sunucu tarafında yeniden fiyatlandırılır — tarayıcıdan gelen tutara asla güvenilmez. Sonra kullanıcı bakiyesi kilitli okuma ile alınır. Üçüncü adımda stok veya kod havuzu rezerve edilir. Dördüncüde bakiyeden düşüm hareketi yazılır. Beşincide sipariş kaydı oluşur. Altıncıda kod veya dijital içerik teslim edilir. Yedincide teslim başarılıysa rezervasyon tüketilmiş olarak işaretlenir ve bildirimler gider.
Bu yedi adımın tamamı tek bir veritabanı işlemi içinde ya da telafi mekanizmalı bir kuyruk içinde yürümelidir. Arada bir adım patlarsa, önceki adımların geri alınması şart. Aksi hâlde en klasik senaryo yaşanır: bakiye düşer, kod bulunamaz, sipariş "beklemede" kalır ve müşteri haklı olarak bağırır. İyi bir e-pin scripti bu durumda otomatik olarak bakiyeyi geri yazar ve olayı loglar.
Çift harcama hatası nasıl oluşur, neden fark etmezsin?
Kullanıcı satın al butonuna hızlıca iki kez basar ya da iki sekmede aynı anda ödeme yapar. Bakiyesi 100 TL, ürün 100 TL. İki istek de aynı milisaniyede bakiyeyi okur, ikisi de "yeterli" der, ikisi de 100 TL düşer. Sonuç: bakiye -100 TL olur veya iki ürün birden teslim edilir. Bu, teoride nadir görünen ama trafik arttıkça haftalık yaşanan bir olaydır.
Kalıcı çözüm üç katmanlıdır. Birincisi satır kilidi: bakiye okunurken kayıt kilitlenir, ikinci istek bekler. İkincisi idempotency anahtarı: aynı sepet için üretilen tekil anahtar iki kez işlenmez. Üçüncüsü veritabanı kısıtı: bakiye alanı negatif olamaz kuralı en son savunma hattı olarak durur. Bu üçünden biri eksikse, sistem bir gün mutlaka açık verir; sadece zamanlamasını bilemezsin.
| Adım | Teknik olay | Yanlış kurulumda sonuç | Doğru davranış |
|---|---|---|---|
| Sepet fiyatlama | Sunucu tarafı yeniden hesap | Manipüle edilmiş tutar | İstemci tutarı tamamen yok sayılır |
| Bakiye okuma | Kilitli sorgu | Çift harcama, eksi bakiye | Satır kilidi + negatif yasağı |
| Stok rezervasyonu | Kod havuzundan ayırma | Aynı kod iki müşteriye | Kod tek işlemde işaretlenir |
| Bakiye düşümü | Hareket satırı yazma | İzsiz bakiye değişimi | Her düşüm ayrı kayıt |
| Sipariş oluşturma | Kalıcı kayıt | Parası alınmış hayalet sipariş | Aynı işlem bloğunda |
| Teslim | Kod veya içerik aktarımı | Sessiz teslim hatası | Teslim onayı zorunlu alan |
| Kapanış | Bildirim ve log | Takip edilemeyen işlem | Değişmez işlem defteri |
Kısmi ödeme: bakiye artı kart karışımının gizli tuzağı
Kullanıcının bakiyesi 40 TL, sepeti 120 TL. Mantıklı olan 40 TL'yi bakiyeden, 80 TL'yi karttan almaktır. Bu özellik dönüşümü ciddi biçimde yükseltir ama iki riski beraberinde getirir. Birincisi: bakiye düşülür, kart ödemesi başarısız olur ve düşülen 40 TL havada kalır. İkincisi: iade gerektiğinde paranın hangi kısmının bakiyeye, hangi kısmının karta döneceği belirsizleşir.
Doğru kurulum şudur: bakiye kısmı düşülmez, rezerve edilir. Kart ödemesi onaylandığında rezervasyon gerçek düşüme dönüşür; onaylanmazsa rezervasyon serbest kalır ve kullanıcı hiçbir şey kaybetmez. İadede ise ödeme kaynakları oranı korunarak geri verilir. Bu ayrımı yapmayan bir dijital ürün satış yazılımı ile kısmi ödeme açmak, destek ekibine her gün yeni bir bilmece yaratmak demektir.
Bakiye ile ödeme akışında açılan destek taleplerinin dağılımı
- Para düştü ürün gelmedi 40%
- Stok tükendi sipariş beklemede 30%
- Kısmi ödeme karmaşası 20%
- Limit ve yetki hataları 10%
Sipariş başarısız oldu, bakiye nerede? Rollback mimarisi
Dijital ürün satışında teslim her zaman yerel değildir; çoğu zaman bir tedarikçi API'sinden kod çekilir. API zaman aşımına düşerse üç olasılık vardır: kod hiç üretilmedi, kod üretildi ama sana ulaşmadı, ya da kod üretildi ve ulaştı. Üçünü ayırt edemeyen sistem ya müşteriyi mağdur eder ya seni zarara sokar.
Profesyonel yaklaşım iki fazlı teslimdir. Birinci fazda sipariş "işleniyor" durumunda açılır ve bakiye rezerve edilir. İkinci fazda tedarikçiden kesin sonuç alınır. Sonuç olumluysa rezervasyon düşüme çevrilir, olumsuzsa otomatik geri yazma çalışır ve kullanıcıya "tutarınız bakiyenize iade edildi" bildirimi gider. Belirsizse işlem elle inceleme kuyruğuna alınır; bu kuyruk hiçbir zaman boş bırakılmayacak bir operasyon kalemidir.
Bayi ve toptan kullanıcılarda limit, kredi ve özel fiyat
Bakiye akışı perakende kullanıcı için basittir ama bayilerde işin rengi değişir. Bayi genellikle kademeli fiyat görür, bazen negatif bakiye izni yani kredi limitiyle çalışır ve günlük harcama sınırı olabilir. Bu üç kural ödeme akışının tam ortasına girer: fiyat hesaplanırken bayi kademesi, bakiye kontrol edilirken kredi limiti, işlem yazılırken günlük limit devreye girmelidir.
Kredi limiti verirken en sık yapılan hata limiti kullanıcı bazında değil grup bazında tanımlamaktır. Bir bayi 50.000 TL açık çalışıp ödemezse, aynı gruptaki diğerleri de aynı riski taşır hâle gelir. Kullanıcı bazlı limit, otomatik limit aşımı bloğu ve vade hatırlatması olmadan kredili satış açmak, tahsilat sorununu yazılımla büyütmek olur.
| Kontrol maddesi | Nerede devreye girer | Eksikse riski |
|---|---|---|
| Sunucu taraflı yeniden fiyatlama | Ödeme öncesi | Tutar manipülasyonu |
| Idempotency anahtarı | İstek girişinde | Mükerrer sipariş ve düşüm |
| Bakiye satır kilidi | Düşüm anında | Eksi bakiye, çift harcama |
| Kod rezervasyonu | Stok ayırma | Aynı kodun iki satışı |
| İki fazlı teslim | Tedarikçi çağrısı | Belirsiz sipariş yığını |
| Otomatik geri yazma | Hata sonrası | Müşteride kalan mağduriyet |
| Kullanıcı bazlı kredi limiti | Bayi ödemesi | Tahsil edilemeyen açık |
| Hareket bazlı bakiye defteri | Her işlemde | Denetlenemez kasa |
Kullanıcı bakiyesini tek bir sayı alanında tutmak en pahalı kısayoldur. Bakiyeyi hareketlerin toplamı olarak hesapla; o zaman hiçbir tutarsızlık kaynağı gizli kalmaz.
Ölçmediğin akışı iyileştiremezsin
Bakiye ödemesinin sağlığını üç metrikle izle: ödeme denemesi başına başarı oranı, teslim süresi ortancası ve geri yazma oranı. Geri yazma oranı %1'in üzerine çıktıysa sorun müşteride değil tedarikçi entegrasyonunda ya da stok yönetimindedir. Teslim süresi ortancası gün içinde belirli saatlerde yükseliyorsa kuyruk kapasiten yetersizdir.
Pinova bu üç metriği akışın kendi içinden üretir; ayrı bir analitik kurmana gerek kalmaz. Rezervasyon mantığı, idempotent ödeme girişi, iki fazlı teslim ve kullanıcı bazlı limit yönetimi standart olarak gelir. Hangi sürümde hangi modülün açık olduğunu özellikler bölümünde, lisans kademelerini fiyat bölümünde görebilirsin.
Ödeme akışını sağlam temele taşı
Rezervasyon, geri yazma ve limit yönetimi kutudan çıkar. Destek taleplerinin büyük kısmını akış düzeyinde bitirir.
Bakiye düşümü hangi anda yapılmalı?
Kesin düşüm, ürün teslimi doğrulandıktan sonra yapılmalıdır. Öncesinde tutar rezerve edilir. Böylece teslim başarısız olduğunda kullanıcının parası hiç düşmemiş gibi serbest kalır.
Kısmi ödemeyi açmalı mıyım?
Sepet ortalaması bakiye ortalamasından yüksekse kesinlikle faydalıdır. Ancak bakiye kısmının rezervasyon mantığıyla çalışması ve iadede kaynak oranının korunması şart.
Aynı kod iki müşteriye nasıl gidiyor?
Kod havuzundan seçim ile işaretleme ayrı işlemlerde yapıldığında iki eşzamanlı istek aynı kodu okur. Seçim ve işaretleme tek atomik güncellemede birleştirilerek bu tamamen engellenir.
Bayiye negatif bakiye izni vermek riskli mi?
Kontrolsüz verilirse evet. Kullanıcı bazlı limit, otomatik aşım bloğu ve vade takibi kuruluysa kredili çalışma ciro artırıcı bir araca dönüşür.
Bakiye ile ödeme, dijital ürün satışının en görünmez ama en kritik mekanizması. Rezervasyon, atomik işlem ve geri yazma üçlüsünü kurduğunda hem müşteri güveni hem kasa tutarlılığı kendiliğinden gelir. Bu akışın gerçek bir panelde nasıl göründüğünü, bir siparişin yedi adımını sırayla izlemek istersen canlı demo üzerinden bakiyeli bir satın alma deneyip her adımın kaydını kendi gözünle görebilirsin.