Çoğu e-pin satıcısı sanal POS başvurusunun "şirket yeni olduğu için" reddedildiğini sanır. Bankadan gelen o iki satırlık e-postada zaten başka bir şey yazmaz: "Başvurunuz risk politikalarımız gereği uygun görülmemiştir." Sen de bunu bir kader gibi kabul edip bir sonraki bankaya aynı dosyayla, aynı web sitesiyle, aynı eksiklerle başvurursun. Üçüncü retten sonra da "bu sektöre POS vermiyorlar" diye bir efsane üretip aracı hesaplara, tanıdık şirketlere, kayıt dışı çözümlere yönelirsin. İşte asıl kaybın tam orada başlar.
Gerçek şu: bankalar dijital ürün satışına POS veriyor. Vermedikleri şey, teslimatını kanıtlayamayan ve iade sürecini yönetemeyen bir satıcıya POS. Onay masasındaki kişi senin ürününü değerlendirmiyor; senin kurduğun sistemi değerlendiriyor. Ve o sistemin ne olduğunu tek bir yerden okuyor: web siten ve gönderdiğin dosya. Bu yazıda retten sonra ne yapılacağını sırayla anlatıyorum — hangi belgenin neyi ispat ettiğini, hangi sayfanın hangi risk sorusunu kapattığını ve doğru kurulmuş bir e-pin satış scriptinin bu denklemde neden belgeden daha fazla iş gördüğünü.
Ret e-postası neden hiçbir şey açıklamıyor?
Bankalar ve ödeme kuruluşları ret gerekçesini bilinçli olarak yazmaz. Çünkü gerekçeyi yazmak, risk modelinin nasıl çalıştığını dışarı sızdırmak demek. Açıkça "teslimat kanıtı üretmiyorsun" derse, ertesi gün sahte teslimat kaydı üreten başvurular gelir. Bu yüzden sana kapalı bir cümle döner ve sen de tahmin yürütmeye başlarsın.
Retten sonra yapılacak ilk iş tahmin etmeyi bırakmaktır. Başvurunu değerlendiren üç ayrı katman vardır: uyum (compliance), risk ve ticari. Uyum katmanı belgelerin tutarlılığına bakar — unvan, adres, vergi no, IBAN, imza sirküleri birbirini doğruluyor mu. Risk katmanı işin doğasına bakar — ürün anında mı teslim ediliyor, geri alınabilir mi, itiraz geldiğinde satıcı ne gösterebiliyor. Ticari katman ise hacmine bakar. Retlerin büyük kısmı ilk iki katmanda, üstelik saniyeler içinde olur.
Dolayısıyla ikinci başvurun bir "rica" değil, bir dosya tamiri olmalı. Aynı dosyayı başka bankaya göndermek, aynı sınavı aynı boş kağıtla ikinci kez vermektir.
Bankanın gerçekte aradığı dört kanıt ne?
Onay masası senin iyi niyetini ölçemez, sadece kanıt okur. Aradığı kanıtlar şaşırtıcı derecede sade. Birincisi kimlik kanıtı: tüzel kişilik belgeleriyle web sitesindeki iletişim bilgilerinin birebir örtüşmesi. Sicil gazetesinde "Ltd. Şti." yazıp sitede sadece marka adı kullanmak bile gereksiz soru işareti üretir.
İkincisi ürün kanıtı: ne sattığın, birim fiyatın, teslim süresinin sayfada açıkça yazması. "Oyun ürünleri" gibi belirsiz ifadeler risk puanını yükseltir; "dijital kod, satın alma sonrası panelden anında teslim" gibi net ifadeler düşürür. Üçüncüsü teslimat kanıtı: siparişin hangi saniyede, hangi koda, hangi IP'ye teslim edildiğini gösteren kayıt. Bu, dijital ürün satış yazılımının en kritik çıktısıdır ve dosyaya ekran görüntüsü olarak konabilir.
Dördüncüsü ise süreç kanıtı: iade ve itiraz politikan. Dijital üründe cayma hakkının hangi koşulda düştüğünü, kod teslim edildikten sonra iade kuralının ne olduğunu yazılı biçimde göstermelisin. Bu dört kanıt tamamsa, risk puanın sektör ortalamasının altına iner.
| Ret gerekçesi | Bankanın gördüğü sinyal | Senin yapman gereken | Düzeltme süresi |
|---|---|---|---|
| Belge tutarsızlığı | Unvan/adres/IBAN uyuşmuyor | Sicil, vergi levhası ve site künyesini eşitle | 1-2 gün |
| Belirsiz ürün tanımı | Ne satıldığı anlaşılmıyor | Kategori ve birim fiyatlı ürün sayfaları yayınla | 2-4 gün |
| Teslimat kanıtı yok | İtirazda satıcı savunmasız | Sipariş-kod-zaman logu üreten panel kur | 3-7 gün |
| Eksik yasal metin | Mesafeli satış uyumu şüpheli | Mesafeli satış, gizlilik, iade sayfaları | 1 gün |
| Riskli ödeme yöntemi karışımı | Kayıt dışı tahsilat izi | Havale/kripto yönlendirmelerini kaldır | 1 gün |
| Aşırı hacim beyanı | Gerçek dışı projeksiyon | Son 3 ayın gerçek cirosunu sun | 1 gün |
İkinci başvuruyu nasıl kurgulamalısın?
İkinci başvuru zamanlaması önemlidir. Reddedilen dosyayı 48 saat içinde yeniden göndermek, sistemde "aynı başvuru" olarak işaretlenip otomatik düşebilir. Önerim şu: eksikleri kapatmak için iki hafta çalış, bu süre boyunca sitede gerçek sipariş akışı üret (küçük hacimli de olsa), sonra başvur. Çünkü bankanın en sevdiği kanıt, işleyen bir sistemin ekran görüntüsüdür.
Dosyaya tek sayfalık bir "operasyon notu" ekle. Bu notta sipariş akışını beş adımda anlat: müşteri ürünü seçer, ödeme alınır, stoktan kod ayrılır, panelden teslim edilir, kayıt tutulur. Altına ortalama teslim süresini ve son üç ayın itiraz sayısını yaz. Bu tek sayfa, onay masasında çoğu zaman geri kalan tüm evraktan daha fazla iş görür; çünkü karar veren kişinin sormak isteyip soramadığı soruların cevabı orada.
Bir de şunu unutma: aynı anda üç sağlayıcıya başvurmak akıllı değil. Reddedilen her başvuru iz bırakır. Tek tek, düzelterek, öğrenerek ilerle.
Sanal POS ret gerekçelerinin dağılımı
- Belge ve künye tutarsızlığı 40%
- Teslimat ve kayıt altyapısı yok 30%
- Eksik yasal metin / site altyapısı 20%
- Diğer (hacim, geçmiş, sektör) 10%
Altyapı, evraktan neden daha güçlü bir argüman?
Evrak durumu anlatır, altyapı ise davranışı ispat eder. Bir e-pin scripti üzerinde çalışıyorsan her siparişin arkasında otomatik oluşan bir zincir vardır: ödeme referansı, stoktan düşen kod, teslim zamanı, müşteri IP'si, fatura kaydı. İtiraz geldiğinde bankaya göndereceğin savunma dosyası bu zincirden tek tuşla çıkar. Bu yeteneğe sahip bir satıcı, sağlayıcı için düşük riskli müşteridir.
Pinova'yı burada devreye sokuyorum çünkü tam bu sorunu çözmek için kurulmuş bir e-pin satış yazılımı: kendisi e-pin satmaz, e-pin satan işletmenin sipariş, stok, teslimat ve kayıt katmanını yönetir. Manuel kod gönderen bir yapıda bu kayıtları sonradan üretmek imkânsızdır; WhatsApp ekran görüntüsü bankaya kanıt sayılmaz. Otomatik teslimat kaydı ise sayılır.
Ek olarak, bir epin yazılım altyapısı sana risk eşiklerini önceden görme imkânı verir: hangi müşterinin kaç kez itiraz açtığı, hangi ürünün iade oranının yüksek olduğu, hangi saatlerde şüpheli sipariş yoğunlaştığı. Bunları bilmek, POS'unu aldıktan sonra elinde tutmanın da tek yolu.
Başvuru dosyanın en üstüne sipariş akışı şemasını ve son 90 günün itiraz istatistiğini koy. Onay masası önce onu okur, gerisini teyit için tarar.
Reddedilen başvuru sonrası köprü çözümler ne olmalı?
POS onayını beklerken satışı durdurmak zorunda değilsin ama seçtiğin geçici yöntem, ikinci başvurunu baltalamamalı. Kişisel hesaba havale almak, tanıdık bir şirketin POS'unu kullanmak veya tek link üreten kayıt dışı yöntemlere yönelmek üç ayrı risk üretir: vergisel sorun, sağlayıcıya "aracı satıcı" izlenimi ve müşteri güvenini kaybetme.
Kabul edilebilir köprüler şunlar: kurumsal hesaba havale/EFT (fatura kesilerek), ödeme kuruluşlarının düşük limitli başlangıç paketleri ve sanal POS sağlayan aracı kurumların denetlenmiş ürünleri. Bunların hepsinde tek kural geçerli: tahsilatın adı, faturanın adı ve sitenin adı aynı olacak. Bu üçlü örtüştüğü sürece geçici çözüm kalıcı zarar üretmez.
Bu dönemi aynı zamanda veri toplama dönemi olarak kullan. Üç ay boyunca düzenli satış, temiz kayıt ve sıfıra yakın itirazla ilerlersen, dördüncü ayda yapacağın başvuru artık "yeni satıcı" değil, "geçmişi olan satıcı" başvurusu olur. Fark bu.
| Kontrol maddesi | Hazır mı? | Nerede ispatlanıyor |
|---|---|---|
| Sicil gazetesi, vergi levhası, imza sirküleri güncel | Evet / Hayır | Başvuru dosyası |
| Site künyesi ile unvan birebir aynı | Evet / Hayır | İletişim sayfası |
| Mesafeli satış, gizlilik, iade, teslimat metinleri | Evet / Hayır | Yasal sayfalar |
| Her ürünün birim fiyatı ve teslim süresi yazılı | Evet / Hayır | Ürün sayfaları |
| Sipariş-kod-zaman kaydı otomatik üretiliyor | Evet / Hayır | Yönetim paneli |
| SSL, kurumsal e-posta, sabit telefon mevcut | Evet / Hayır | Teknik altyapı |
| Son 90 gün itiraz oranı %1 altında | Evet / Hayır | Sipariş raporu |
| Operasyon notu tek sayfa halinde hazır | Evet / Hayır | Dosya ilk sayfası |
Onay dosyanı güçlendiren altyapıyı bugün kur
Teslimat kaydı, stok takibi ve itiraz savunması üreten bir panelle başvuruya git. Pinova'nın modüllerini ve fiyatlandırmasını incele.
Sanal POS reddedildikten sonra ne kadar bekleyip tekrar başvurmalıyım?
Eksikleri kapatmadan hemen başvurma. Ortalama iki hafta içinde belge, yasal metin ve teslimat kaydı eksiklerini gider, bu sürede gerçek sipariş verisi üret, sonra başvur. Aynı dosyayla 48 saat içinde yapılan tekrar başvurular genelde otomatik düşer.
Şahıs şirketiyle e-pin satışına sanal POS alınır mı?
Alınır, ancak limitler daha düşük ve inceleme daha sıkı olur. Şahıs şirketinde teslimat kaydı ve yasal metinler daha da kritik hale gelir; ciro büyüdüğünde limited şirkete geçmek komisyon pazarlığını da kolaylaştırır.
Hangi belge en çok rede sebep oluyor?
Tek bir belge değil, belgeler arası tutarsızlık. Unvan, adres, vergi numarası ve IBAN sahibinin site künyesiyle birebir örtüşmemesi retlerin en büyük bölümünü oluşturuyor. Başvuru öncesi bu dört alanı satır satır karşılaştır.
Yazılım değiştirmek onay şansımı gerçekten etkiler mi?
Evet, çünkü onay kararı sistemin ürettiği kanıta bakar. Sipariş, stok ve teslimat kaydını otomatik tutan bir altyapı, itiraz savunmasını mümkün kıldığı için risk puanını düşürür. Manuel kod gönderiminde bu kanıt hiç oluşmaz.
Sanal POS reddi bir kapanış değil, sistemindeki eksiğin faturasıdır. Belgeni tutarlı hale getir, yasal metinlerini tamamla, ürün sayfalarını netleştir ve en önemlisi her siparişin kaydını otomatik tutan bir altyapıya geç; üçüncü başvuruda konuştuğun dil değişir. Pinova'nın hangi modüllerle bu kaydı ürettiğini özellikler listesinden görebilir, paket farklarını fiyat bölümünde karşılaştırabilir ve kendi başvuru dosyanda kullanacağın panel ekranlarını canlı demo üzerinden tek tek inceleyebilirsin.