Bakiye sistemi kuran hemen her satıcı, ilk aylarda yalnızca paranın girişini düşünür. Yükleme yöntemlerini çeşitlendirir, komisyonları optimize eder, dönüşümü kovalar. Sonra bir gün gelen mesaj her şeyi değiştirir: "Hesabımda 1.850 TL bakiye var, kullanmayacağım, banka hesabıma geri gönder." O an fark edersin ki sistemin çıkış kapısı hiç tasarlanmamıştır.
Çoğu kişi bunun küçük bir operasyon detayı olduğunu sanır. Gerçekte bakiye iadesi ve para çekme, e-pin işinin en yoğun risk kesişimidir: burada tüketici hakları, chargeback mekanizması, kara para aklama riski ve muhasebe aynı anda masadadır. Kullandığın dijital ürün satış scripti bu üçünü ayrı ayrı yönetebilmiyorsa, iyi niyetli bir iade bile seni zarara sokabilir.
"Bakiyemi geri çekmek istiyorum" mesajı neden kabusa döner?
Çünkü bu tek bir talep değil, birbirine bağlı üç sorunun kısaltmasıdır. Birinci soru: bu para gerçekten bu kişiye mi ait? İkinci soru: bu para hangi kanaldan girdi ve o kanala geri gönderilmesi zorunlu mu? Üçüncü soru: bu talep bir sistem istismarının parçası mı?
Üçünü aynı anda cevaplayamadığın her talepte iki kötü seçenekten birini yaparsın: reddedip meşru müşteriyi kaybedersin ya da onaylayıp riski üstlenirsin. Çözüm talep başına karar vermek değil, kural kurmaktır. Sağlam bir e-pin scripti çekme talebini bir varlık olarak modeller: durumu, kaynağı, doğrulama seviyesi, onaylayan personel ve değişmez zaman damgası olan bir kayıt. Karar o kaydın üzerine yazılır, sohbet penceresinde kaybolmaz.
İade mi bakiye kredisi mi? İkisi aynı şey değil
Burada çok kritik bir ayrım var. Müşteri aldığı üründen memnun kalmadıysa yapılan iş iadedir ve ödeme aynı kanala geri gitmelidir; kart ile ödediyse karta, havale ile ödediyse hesabına. Müşteri sadece bakiyesini kullanmaktan vazgeçtiyse yapılan iş bakiye geri ödemesidir ve bu tamamen farklı bir süreçtir.
Aradaki farkı silip her şeyi "bakiye olarak iade ettim" diye kapatmak kısa vadede pratik görünür ama iki sorun yaratır. Birincisi tüketici açısından ürün bedelinin nakde dönmesini talep etme hakkı vardır; bakiyeye yazmak bu hakkı ortadan kaldırmaz. İkincisi muhasebe açısından karta dönen iade ile bakiyeye yazılan kredi bambaşka kalemlerdir. İyi bir e-pin satış yazılımı bu ikisini ayrı işlem tipleriyle tutar ki dönem sonunda ne kadar gerçek iade, ne kadar cüzdan kredisi verdiğini görebilirsin.
| Senaryo | Doğru işlem tipi | Hedef kanal | Tipik süre |
|---|---|---|---|
| Teslim edilemeyen kod | Sipariş iadesi | Ödeme yapılan kanal | Anında - 24 saat |
| Çalışmayan / kullanılmış kod | İnceleme sonrası iade | Bakiye veya kaynak | 1-3 iş günü |
| Kullanılmamış bakiye talebi | Para çekme | Sadece kimlik eşleşen hesap | 3-7 iş günü |
| Yanlış tutarda yükleme | Düzeltme kaydı | Aynı kanal | Aynı gün |
| Hesap kapatma isteği | Bakiye tasfiyesi | Doğrulanmış banka hesabı | 7-15 iş günü |
| Şüpheli işlem zinciri | Dondurma + inceleme | Karar çıkana kadar yok | Belirsiz |
Para çekme hakkı kimde var, kimde yok?
En savunmasız kurulum, "bakiyesi olan herkes çekebilir" kuralıdır. Bunun neden tehlikeli olduğunu görmek için tek bir senaryo yeter: kötü niyetli kişi çalıntı kartla 5.000 TL bakiye yükler, hemen çekme talebi açar, para kendi banka hesabına gider. İki hafta sonra kart sahibi itiraz eder, chargeback gelir, sen 5.000 TL'yi bankaya geri ödersin. Kötü niyetli kişi hiçbir ürün bile satın almamıştır; sisteminde para yıkamıştır.
Bu yüzden çekme hakkı üç koşula bağlanmalıdır. Birincisi kanal eşleşmesi: paranın çıkacağı hesap, paranın girdiği hesapla aynı kimliğe ait olmalı. İkincisi bekleme süresi: kartla yüklenen bakiye chargeback penceresinin makul bir bölümü geçmeden çekilemez. Üçüncüsü harcama oranı: hiç alışveriş yapmamış bir hesabın çekme talebi otomatik olarak insan incelemesine düşer.
Para çekme taleplerinin gerçek hayattaki sonuç dağılımı
- Doğrulanıp ödenen 50%
- Bakiye kredisine dönen 20%
- Belge eksiği ile bekleyen 20%
- Risk nedeniyle reddedilen 10%
Chargeback ve para çekme birleştiğinde oluşan döngü
Bu ikilinin birleşimi, dijital ürün satıcılarının en pahalı dersidir. Dijital teslimde kargo takip numarası yoktur; itiraz durumunda bankaya "ürün teslim edildi" demek için elinde yalnızca kendi loglarınız olur. Bu yüzden savunma dosyanı en baştan kurmalısın: teslim zamanı, IP, cihaz parmak izi, kodun görüntülendiği an ve kullanıcının onay kaydı.
İkinci savunma katmanı ise akıştır. Kartla yüklenen bakiyeyi çekilemez olarak etiketle; yalnızca ürün satın almak için kullanılabilsin. Sadece havale gibi geri alınamayan kanallardan gelen ve belirli süre bekleyen tutarlar çekilebilir olsun. Bu tek kural, sisteminin para yıkama aracı olarak kullanılma ihtimalini neredeyse tamamen kapatır ve meşru müşterinin deneyimine de dokunmaz.
Otomatik mi manuel mi? Onay eşiğini nasıl belirlersin
Her talebi elle incelemek 30 talep/gün sonrasında sürdürülemez; her talebi otomatik ödemek ise ilk kötü niyetli kullanıcıda biter. Doğru cevap eşik tabanlı hibrit modeldir. Belirlediğin tutarın altındaki, kanal eşleşmesi doğrulanmış, hesabı belirli bir süredir aktif ve harcama geçmişi olan kullanıcıların talepleri otomatik akar. Bu kriterlerden birini bile karşılamayan talep kuyruğa düşer.
Eşiği belirlerken bak: son üç ayda reddettiğin taleplerin tutar dağılımı nedir? Çoğu red 2.000 TL üzerindeyse eşiğini oraya kur. Ayrıca günlük toplam çıkış limiti koy; tek kullanıcı değil, tüm sistem için. Bir güvenlik açığı yaşansa bile kaybın o limitle sınırlı kalır. Bu iki ayarı bile olmayan bir dijital ürün satış yazılımı ile büyümek, frenleri kontrol etmeden hız yapmaya benzer.
| Kontrol listesi | Ne engeller | Uygulama yeri |
|---|---|---|
| Kanal eşleşme zorunluluğu | Üçüncü hesaba para aktarımı | Talep açılışı |
| Kartla yüklenen bakiye çekilemez | Chargeback ile para yıkama | Bakiye etiketleme |
| Bekleme süresi kuralı | Hızlı giriş-çıkış istismarı | Uygunluk hesabı |
| Harcama oranı kontrolü | Hiç alışveriş yapmayan hesap | Otomatik onay filtresi |
| Tutar bazlı onay eşiği | Yüksek tutarlı tek seferlik kayıp | Kural motoru |
| Sistem geneli günlük limit | Açık durumunda toplu kayıp | Ödeme kuyruğu |
| Değişmez talep geçmişi | Sonradan düzenleme şüphesi | İşlem defteri |
| İade ve kredi ayrı işlem tipi | Muhasebe karmaşası | Kayıt şeması |
Kullanım koşullarında para çekme kurallarını, bekleme sürelerini ve kanal eşleşme şartını net biçimde belirt. Yazılı kural, bir talebin pazarlığa dönmesini baştan engeller.
Muhasebe tarafı: bakiye senin gelirin değil, borcun
Bu cümle basit görünür ama işletmelerin yarısı tersini yapar. Kullanıcıların cüzdanında duran toplam tutar, sen henüz hiçbir ürün satmadığın için gelir değildir; yükümlülüktür. Gelir, bakiye harcandığında ve ürün teslim edildiğinde doğar. Bu ayrımı yapmazsan cironu şişirmiş, aynı zamanda beklenmeyen bir çekme dalgasına karşı nakit rezervini yanlış hesaplamış olursun.
Pratikte yapman gereken şudur: her ay sonunda açık bakiye yükümlülüğü raporu al ve bunun en az bir kısmını çekilebilir nakit olarak tutmayı alışkanlık hâline getir. Pinova bu raporu bakiye hareket defterinden otomatik üretir; iade, kredi ve çekme işlemlerini ayrı tiplerde tutar, onay zincirini kayda geçirir ve eşik kurallarını panelden yönetmene izin verir. Modül kırılımını özellikler bölümünde, lisans seçeneklerini fiyat bölümünde inceleyebilirsin.
Çıkış kapını da güvenli kur
Kural tabanlı para çekme, kanal eşleşmesi ve denetlenebilir işlem defteri hazır gelir. Riskli talepler sana ulaşmadan filtrelenir.
Kullanıcının bakiyesini geri ödemek zorunda mıyım?
Kullanılmamış ön ödemeli tutar için makul bir talep geldiğinde iade etmek hem doğru hem itibar açısından güvenlidir. Ancak kuralları yazılı hâle getirip kanal eşleşmesi ve bekleme süresi şartı koyman gerekir.
Kartla yüklenen bakiye çekilebilir olmalı mı?
Olmamalı. Kart kaynaklı bakiyeyi yalnızca ürün alımına açık tutmak, chargeback üzerinden para yıkama girişimlerini büyük ölçüde ortadan kaldırır.
Çekme taleplerini ne kadar sürede kapatmalıyım?
Doğrulanmış talepler için 3-7 iş günü sektörde kabul gören aralıktır. Önemli olan süreyi kısaltmak değil, kullanıcının talebinin hangi aşamada olduğunu panelden görebilmesidir.
İade işlemini bakiyeye yazmak yeterli mi?
Ürün kaynaklı bir iadede yeterli değildir; ödeme aynı kanala dönmelidir. Bakiye kredisi yalnızca kullanıcının kendi tercih ettiği ya da jest niteliğinde verilen durumlar için uygundur.
Bakiye sisteminin olgunluğu, para girerken değil çıkarken belli olur. İade ile bakiye kredisini ayırdığında, kanal eşleşmesini zorunlu kıldığında ve eşik tabanlı onayı kurduğunda hem dolandırıcılığa kapıyı kapatırsın hem meşru müşterine hızlı cevap verirsin. Bu kuralların gerçek bir panelde nasıl tanımlandığını ve bir çekme talebinin baştan sona hangi ekranlardan geçtiğini görmek istersen canlı demo üzerinden test talebi açıp akışı kendi elinle izleyebilirsin.