Çoğu kişi sanal POS'u bir "form doldurma" işi sanır. Bankaya başvuru yaparsın, birkaç belge yüklersin, sana bir merchant kodu verilir, sen de bunu e-pin scriptinin ayar ekranına yazarsın. Bitti. Oysa bu işi yıllardır yapan satıcıların bildiği çok daha can sıkıcı bir gerçek var: sanal POS başvurusunun kaderi, sen bankaya hiç dokunmadan, kendi sitenin teknik olgunluğuyla belirleniyor. Banka risk ekibi senin ürün sayfana, teslimat metnine, iade politikana ve sipariş akışına bakıyor; "e-pin satıyorum" cümlesini duyduğunda ise otomatik olarak yüksek risk kutusunu işaretliyor.
İşin ilginç tarafı, bu kutuyu işaretlenmemiş hale getirmenin yolu pazarlık değil, mimari. Doğru kurgulanmış bir e-pin satış scripti, bankaya "bu satıcı chargeback üretmez" mesajını sessizce verir: anında teslimat kaydı, kod bazlı log, KVKK uyumlu üyelik, açık iptal-iade sayfası, sipariş durumu şeffaflığı. Bu yazıda entegrasyonu ayar ekranına bir anahtar yazmak olarak değil, uçtan uca bir süreç olarak açıyorum. Sıralamayı bozmadan ilerlersen, onay süresi haftalardan günlere iner.
Sanal POS'u banka mı verir, sen mi hak ettirirsin?
Bankanın sana baktığı yer bilanço değil, davranış öngörüsü. Dijital ürün satan bir işletmede en büyük korku "ürün teslim edilmedi" itirazıdır, çünkü kargo takip numarası gibi fiziksel bir kanıt yoktur. Burada senin kanıtın, epin yazılım tarafında tutulan teslimat kaydıdır: hangi kod, hangi siparişe, hangi saniyede, hangi IP'ye teslim edildi. Bu kaydı ekran görüntüsü olarak değil, tek tuşla PDF/CSV çıkabilen bir rapor olarak sunabiliyorsan itirazların büyük kısmını kaybetmeden kapatırsın.
Başvuru öncesinde sitende bulunması gereken şeyler sıkıcı ama pazarlık dışıdır: kurumsal kimlik bilgileri, vergi levhası, mesafeli satış sözleşmesi, teslimat ve iade koşulları, iletişim kanalı ve çalışan bir üyelik-sipariş akışı. Bunları "sonra ekleriz" diye bırakırsan risk ekibi dosyayı bekletir. Deneyimli satıcının yaptığı şey basittir: başvuruyu, script canlıya alınıp test siparişleri döndükten sonra yapmak.
Neden dosyanı reddeden şey fiyat değil, teknik hazırlıksızlık?
Reddedilen dosyaları incelediğinde aynı üç kalıbı görürsün. Birincisi, sipariş akışında ödeme sonrası ne olduğunun belirsiz olması: kullanıcı ödeme yapıyor ama sayfa boş dönüyor, sipariş durumu "beklemede" kalıyor. İkincisi, fiyatın ürün sayfasında net olmaması; kampanya, kupon ve vergi gösterimi tutarsızsa banka bunu "tutar manipülasyonu riski" olarak okur. Üçüncüsü, deneme amaçlı bırakılmış sahte ürünler, kırık görseller ve boş kategoriler.
Pinova gibi lisanslı bir dijital ürün satış yazılımı kullanmanın en somut faydası tam burada ortaya çıkıyor: bu kalıpların hiçbirini sen elle düzeltmiyorsun. Sipariş durumu makinesi, kupon-vergi hesaplama, teslimat logu ve yasal sayfa şablonları kutudan çıkıyor. Sen sadece içeriği dolduruyorsun. Banka tarafına giden görüntü, "kurumsal altyapı üzerinde çalışan bir işletme" oluyor; "bir arkadaşın yaptığı site" değil.
| Adım | Ne yapılır | Script tarafındaki karşılığı | Süre |
|---|---|---|---|
| 1 | Şirket ve vergi belgelerini toparla | Kurumsal bilgi alanları, fatura ünvanı | 1 gün |
| 2 | Yasal sayfaları yayınla | Mesafeli satış, iade, gizlilik şablonları | 2 saat |
| 3 | Ürün ve kategori vitrinini doldur | Katalog, stok tipi, teslimat yöntemi | 1 gün |
| 4 | Sanal POS başvurusunu aç | — | 1 gün |
| 5 | Test anahtarlarını tanımla | Geçit ayarları, sandbox modu | 30 dk |
| 6 | Başarılı/başarısız dönüşleri test et | Callback ve sipariş durumu | 2 saat |
| 7 | Teslimat otomasyonunu doğrula | Stok düşümü, kod teslimi, e-posta | 1 saat |
| 8 | Canlı anahtarlara geç | Prod anahtar, log seviyesi | 15 dk |
| 9 | Mutabakatı kur | Gün sonu raporu, hakediş eşleştirme | Sürekli |
Entegrasyonun gerçek sırası nedir: anahtar, callback, mutabakat
Entegrasyonu üç katmana ayır. Birinci katman kimlik: merchant kimliği, mağaza anahtarı, API kullanıcısı. Bu bilgileri asla dosya içine gömmezsin; yazılımın kendi şifreli ayar deposunda tutulur ve yetkisiz yönetici rolü bunları göremez. İkinci katman akış: ödeme başlatma isteği, banka tarafındaki yönlendirme, geri dönüş adresi ve sunucudan sunucuya bildirim. Üçüncü katman ise mutabakat: bankanın gün sonu dosyasıyla senin sipariş tablonun birebir örtüşmesi.
Satıcıların en sık atladığı kısım üçüncü katman. İlk hafta her şey yolunda gider, sonra bir gün bankada tahsil edilmiş ama sitede "beklemede" kalmış bir sipariş bulursun. Sebep genelde tek bir şeydir: geri dönüş sayfasını doğruluk kaynağı saymak. Tarayıcı kapanırsa, internet giderse, kullanıcı sekmeyi öldürürse o dönüş hiç gelmez. Kalıcı doğruluk kaynağı, sunucudan sunucuya gelen bildirim ve sorgu API'sidir.
Sanal POS başvurusu red nedenleri
- Eksik yasal sayfa ve belirsiz teslimat 45%
- Çalışmayan sipariş/ödeme akışı 25%
- Sektör risk skoru 20%
- Diğer 10%
Sipariş durumu tek doğruluk kaynağı olmazsa ne kaybedersin?
Bir siparişin hayatı boyunca geçebileceği durumlar sınırlı olmalı: oluşturuldu, ödeme bekliyor, ödendi, teslim edildi, iptal, iade. Bu listeyi büyüttüğün an kaos başlar. İyi kurulmuş bir e-pin scripti durum geçişlerini tek noktadan yönetir ve her geçişi kimin, neyin tetiklediğini loglar. Böylece "para geldi ama kod gitmedi" durumu bir muamma değil, tek satırlık bir kayıt olur.
Bir de idempotency konusu var. Banka aynı bildirimi iki kez gönderebilir; ağ gecikmesi yüzünden üç kez de gönderebilir. Eğer yazılımın her bildirimi yeni bir olay sayıyorsa, aynı siparişe iki kod teslim eder ve stoktan iki düşer. Bunu engelleyen şey, işlem kimliği üzerine kurulu tekillik kontrolüdür: aynı referans için ikinci bildirim geldiğinde sistem "bu iş zaten yapıldı" der ve sessizce onaylar.
Canlıya geçmeden önce en az bir test siparişini gerçek tutarla çekip sonra iade akışından geçir. İade yolu çalışmayan bir kurulum, ilk itirazda elle müdahale borcu yaratır ve o borç hep en yoğun günde faturalanır.
Komisyon, blokaj ve iptal-iade: marjını sessizce yiyen üç kalem
Sanal POS maliyeti sadece komisyon değildir. Taksit maliyeti, blokaj süresi, iade kesintisi ve itiraz başına uygulanan ücret bir arada düşünülmezse fiyat listen ilk aydan zarara döner. Dijital üründe ortalama sepet küçük, işlem adedi yüksektir; bu yüzden yüzdelik komisyondan çok sabit işlem ücreti canını yakar. 40 TL'lik bir satışta sabit ücret, yüzde birkaç puanlık bir farktan daha belirleyicidir.
Yazılım tarafında yapılacak iş net: her ödeme geçidi için komisyon ve sabit ücret tanımını sisteme girmek, sonra sipariş raporunda brüt değil net hakediş görmek. Bunu göremediğin sürece hangi kampanyanın kâr, hangisinin zarar ettiğini tahminle yönetirsin. Fiyat ve paket seçeneklerini fiyat sayfasında karşılaştırırken bu maliyet kalemlerini de aynı tabloya koymanı öneririm.
Tek sanal POS'a bağlı kalmak neden en pahalı tasarruf?
Bir satıcının en kötü günü, tek ödeme geçidinin bakıma girdiği veya hesabının aniden incelemeye alındığı gündür. O gün ciron sıfırdır. Çok geçitli mimari bunun sigortasıdır: iki farklı sağlayıcıyı aynı anda tanımlar, birini varsayılan yapar, hata oranı yükselince trafiği diğerine kaydırırsın. Modern bir dijital ürün satış scripti bunu ayar ekranından yapmanı sağlar; kod değiştirmeni gerektirmez.
İkinci faydası pazarlık gücüdür. İki aktif geçidin varsa komisyon konuşması yaparken elin güçlüdür, çünkü trafiği kaydırma tehdidin gerçektir. Üçüncüsü ise müşteri deneyimi: kart, havale ve bakiye seçeneklerini aynı sepette sunduğunda dönüşüm oranın belirgin biçimde artar. Hangi yeteneklerin kutudan çıktığını görmek istersen özellikler bölümüne göz at.
| Kontrol | Neden kritik | Durum |
|---|---|---|
| Anahtarlar şifreli ayar deposunda | Yetkisiz erişim ve sızıntı riski | Zorunlu |
| Sunucudan sunucuya bildirim aktif | Tarayıcı kapanınca sipariş kaybı | Zorunlu |
| İşlem kimliğinde tekillik kontrolü | Çift teslimat ve çift stok düşümü | Zorunlu |
| Başarısız ödeme ekranı anlamlı | Terk edilen sepet oranı | Önerilir |
| Gün sonu mutabakat raporu | Eksik tahsilatın erken yakalanması | Zorunlu |
| İade ve iptal akışı test edildi | İtiraz yönetimi ve banka güveni | Zorunlu |
| İkinci ödeme geçidi tanımlı | Kesinti gününde ciro koruması | Önerilir |
Ödeme altyapısını bir hafta sonuna sığdır
Sanal POS, havale, bakiye ve otomatik teslimat tek panelde hazır gelsin; sen sadece anahtarları gir ve satmaya başla.
Sanal POS başvurusunu siteyi kurmadan yapabilir miyim?
Yapabilirsin ama onay şansın düşer. Risk ekibi çalışan bir vitrin, yasal sayfalar ve tamamlanabilen bir sipariş akışı görmek ister. Scripti kurup test siparişi döndürdükten sonra başvurmak süreci belirgin biçimde kısaltır.
Aynı anda kaç ödeme geçidi tanımlayabilirim?
Teknik bir üst sınır yoktur; pratikte iki kart geçidi, bir havale ve bir bakiye yöntemi çoğu satıcı için yeterlidir. Önemli olan hangisinin varsayılan olduğunu ve hata durumunda devreye girecek yedeği net tanımlamaktır.
Ödeme geldi ama sipariş beklemede kaldı, sebebi ne olabilir?
Neredeyse her zaman sunucudan sunucuya bildirimin ulaşmaması veya doğrulanamamasıdır. Güvenlik duvarı, yanlış geri dönüş adresi ya da imza doğrulama hatası ilk bakılacak yerlerdir. Sorgu API'siyle yapılan periyodik kontrol bu siparişleri kendiliğinden kapatır.
Küçük tutarlı satışlarda hangi maliyet kalemine dikkat etmeliyim?
Sabit işlem ücretine. 30-60 TL bandındaki satışlarda sabit ücret, yüzdelik komisyondan daha çok marj yer. Minimum sepet tutarı veya bakiye yükleme teşviki bu etkiyi azaltır.
Bu dokuz adımı sırayla uyguladığında sanal POS artık korktuğun bir bürokrasi değil, yönettiğin bir kaldıraç olur. Panelde bu akışın nasıl göründüğünü kendi gözünle görmek istersen canlı demo üzerinden bir test siparişi oluşturup ödeme, teslimat ve mutabakat ekranlarını uçtan uca gez; kurulum kararını tahminle değil deneyimle ver.