Sanal POS Nedir, Nasıl Alınır?

Sitenizi kurdunuz, ürünleri girdiniz, kargo anlaşmasını yaptınız; geriye tek bir şey kaldı: müşteri kartını girdiğinde paranın hesabınıza geçmesi. İşte o iş sanal POS'un işi. Ama "sanal POS nedir, nasıl alınır" diye aradığınızda karşınıza çıkan sayfaların neredeyse tamamı kendi POS'unu satan taraf: bankanın kendi sayfası, ödeme kuruluşunun kendi sayfası ya da komisyon üzerinden aracılık geliri alan bir karşılaştırma sitesi. Hiçbiri size başvurunuzun neden reddedildiğini, banka POS'u ile ödeme kuruluşu arasındaki gerçek farkın ne olduğunu ya da "%1,5 komisyon" yazan tablodaki rakamın cebinize gerçekte nasıl yansıdığını anlatmıyor.

Bu yazı tarafsız tarafta duruyor. Sanal POS'un ödeme zincirindeki yerini, banka POS'u ile ödeme kuruluşu arasındaki operasyonel farkı, başvuruda gerçekten istenen belgeleri, başvuruların neden reddedildiğini (bu bölüm en çok işinize yarayacak olan), komisyon–valör–taksit üçlüsünün hesabını ve teknik entegrasyonun sunucu tarafında ne gerektirdiğini anlatıyoruz. Ürün satmıyoruz; hangi yolun size uygun olduğuna kendiniz karar veresiniz diye yazıyoruz.

Sanal POS Nedir, Fiziki POS'tan Farkı Ne#

Sanal POS, kart bilgisiyle uzaktan tahsilat yapmanızı sağlayan sanal terminaldir; fiziki POS cihazının yaptığı işi, kartın fiziksel olarak okutulmadığı bir ortamda yapar. Bankacılık dilinde bu işleme "kart hamili işyerinde değil" anlamına gelen CNP (Card Not Present) işlemi denir ve fiziki POS'tan iki temel noktada ayrılır.

Birincisi risk. Fiziki POS'ta kart cihaza takılır, çip okunur, PIN girilir; itiraz (chargeback) durumunda banka çoğunlukla üye işyerini haklı bulur. Sanal POS'ta ise kartı gerçekten kart sahibinin mi kullandığı belirsizdir. Bu belirsizlik iki sonuç doğurur: komisyon oranları CNP tarafında daha yüksektir ve bankalar başvuruyu çok daha sıkı inceler.

İkincisi entegrasyon. Fiziki POS'ta cihaz kurulur, iş biter. Sanal POS'ta bankanın veya kuruluşun sistemine bir API entegrasyonu yapmanız, 3D Secure akışını kurmanız ve dönen yanıtı doğru yorumlayıp siparişi ona göre onaylamanız gerekir. Bu kısmı atlayanların başına gelen klasik hata şudur: kullanıcı ödemeyi yarıda bırakır, siteniz siparişi "ödendi" işaretler, ürün kargolanır, para hiç gelmez.

Banka Sanal POS'u ile Ödeme Kuruluşu Arasındaki Gerçek Fark#

En çok karıştırılan konu bu. İki modeli ayıran şey komisyon oranı değil, paranın kimin hesabına düştüğü ve bankayla ilişkiyi kimin kurduğu.

Banka sanal POS'unda banka ile doğrudan üye işyeri sözleşmesi imzalarsınız. Para bankadaki ticari hesabınıza geçer. Her banka için ayrı başvuru, ayrı sözleşme, ayrı entegrasyon gerekir; Visa/Mastercard'ı bir bankadan, yerli kart ailesini başka bir bankadan almak istiyorsanız bu iş çoğalır.

Ödeme kuruluşunda ise arada lisanslı bir kuruluş vardır. Kuruluş bankalarla anlaşmayı kendisi yapmış, tek bir API'nin arkasına birden fazla bankanın POS'unu toplamıştır. Siz tek entegrasyon yaparsınız, para önce kuruluşun havuz hesabına düşer, hakedişiniz sözleşmedeki valör süresi sonunda size aktarılır.

Pratikte tercih şöyle şekilleniyor: yeni açılmış, cirosu belirsiz, hızlı başlamak isteyen işletmeler ödeme kuruluşuyla başlıyor. Cirosu oturmuş, taksit kampanyalarını kendi yönetmek isteyen, kuruşları önemseyen işletmeler zamanla banka POS'una geçiyor ya da ikisini birlikte kullanıyor. İkisini birlikte kullanmak da geçerli bir strateji: kuruluş yedek olarak durur, bir banka POS'u arıza verdiğinde ödeme akışı durmaz.

Dikkat edilecek bir nokta daha var: aracı kuruluşla çalışıyorsanız, kuruluşun hesabınızı kesintiye alma ihtimalini sözleşmede okumadan geçmeyin. Yüksek itiraz oranı, ani ciro sıçraması veya şüpheli işlem deseni tespit edildiğinde hakediş bloke edilebilir. Bu tamamen olağan bir risk yönetimi refleksidir ama nakit akışınızı bir haftada altüst edebilir.

Ödeme Akışında Kim Ne Yapıyor#

Sanal POS'u tek başına bir kutu sanmak yanlış anlamaya yol açıyor. Gerçekte dört ayrı rol var:

1. Üye işyeri (siz). Sepeti oluşturur, tutarı belirler, ödeme isteğini başlatır.
2. Ödeme geçidi (payment gateway). Kart verisini toplar, bankaya iletir. Ödeme kuruluşları genelde geçidi de kendileri sağlar.
3. Sanal POS (banka tarafı). İşlemi karta yollar, provizyon alır.
4. 3D Secure sunucusu. Kart sahibini bankaya doğrulatır; SMS/uygulama onayı bu adımdadır.

Akış tipik olarak şöyle ilerler: sitede "Öde" butonuna basılır → kart verisi geçide gider → 3D Secure sayfası açılır → banka kart sahibini doğrular → doğrulama sonucu sitenize callback ile döner → siz bu sonucu doğrularsınız → tutar provizyona alınır → gün sonu hakediş oluşur.

Kritik nokta beşinci adım. Callback'i doğrulamadan siparişi onaylayan sitelerin başına gelen en yaygın olay, tarayıcıdan gelen "başarılı" parametresine güvenip stok düşmektir. Bankadan gelen yanıtın hash imzası mutlaka sunucu tarafında kontrol edilmelidir:

<?php
// 3D Secure dönüşünde gelen alanların bankanın imzasıyla doğrulanması.
// Alan adları ve sıralama BANKAYA GÖRE DEĞİŞİR; entegrasyon dokümanından teyit edin.
$gelenHash = $_POST['HASH'] ?? '';

$imzaliAlanlar = [
    $_POST['merchantId']   ?? '',
    $_POST['orderId']      ?? '',
    $_POST['amount']       ?? '',
    $_POST['currency']     ?? '',
    $_POST['mdStatus']     ?? '',
    $storeKey, // bankadan aldığınız gizli anahtar, .env'de tutulur
];

$hesaplanan = base64_encode(hash('sha512', implode('|', $imzaliAlanlar), true));

if (!hash_equals($hesaplanan, $gelenHash)) {
    error_log('3D dönüşü imza uyuşmadı, orderId=' . ($_POST['orderId'] ?? '-'));
    http_response_code(400);
    exit('Doğrulanamayan ödeme dönüşü');
}

// mdStatus 1 tam doğrulama; 2,3,4 yarı doğrulama (banka politikasına göre kabul/ret)
if (($_POST['mdStatus'] ?? '0') !== '1') {
    // siparişi ONAYLAMA, ödeme başarısız sayfasına yönlendir
}

hash_equals() kullanımı tesadüf değil: normal == karşılaştırması zamanlama saldırısına açıktır. Bu tür detaylar entegrasyon dokümanlarında yazmaz ama ödeme kodunda fark yaratır.

Sanal POS Başvurusu İçin Gereken Belgeler#

Belge listesi banka ve kuruluşa göre değişse de çekirdek set hemen hemen aynıdır:

• Vergi levhası. Şirket unvanı, faaliyet konusu ve adresi burada okunur. Bunun için önce şirketinizin kurulu olması gerekir; süreci e-ticaret için şirket kurmak ve vergi yükümlülükleri yazısında baştan sona anlattık.
• Ticaret sicil gazetesi (şahıs şirketlerinde çoğu zaman istenmez, sermaye şirketlerinde istenir).
• İmza sirküleri / imza beyannamesi.
• Kimlik fotokopisi (yetkili kişi).
• Faaliyet belgesi ya da oda kayıt belgesi.
• Banka hesap bilgisi (IBAN), şirket unvanına ait olmak zorunda.
• ETBİS kaydı. Elektronik ticaret bilgi sistemi kaydı; ETBİS kaydı nasıl yapılır yazısında adımları var.
• Web sitesi adresi ve sitenin yayında olduğunun teyidi.

Son madde en çok hafife alınandır. Başvuru formundaki alan adı, inceleme ekibi tarafından elle açılıp gezilir. "Yakında" sayfası, şifreli bakım modu ya da yarım kalmış ürün listesi gördüğü anda başvuru döner.

Sanal POS Başvurusu Neden Reddedilir#

Reddedilme sebeplerinin büyük çoğunluğu mali değil, sitenizle ilgilidir. Yıllardır gördüğüm en yaygın kalıplar sırasıyla şunlar:

1. Sitede yasal metinler eksik. Mesafeli satış sözleşmesi, ön bilgilendirme formu, iptal ve iade koşulları, gizlilik politikası, çerez politikası, KVKK aydınlatma metni ve iletişim bilgileri. Bunların hepsi ayrı ayrı erişilebilir sayfalar olarak bulunmalı. Ayrıntı için web sitesinde zorunlu yasal metinler ve mesafeli satış sözleşmesi nedir yazılarına bakın.
2. Vergi levhasındaki faaliyet konusu ile sitede satılan ürün uyuşmuyor. Levhada "yazılım danışmanlığı" yazıp sitede gıda takviyesi satarsanız başvuru döner. Bu, en sık gözden kaçan ve en sessiz reddedilme sebebidir.
3. Ürünler yayında değil. Kategori sayfaları boş, ürün detay sayfası açılmıyor, fiyat görünmüyor. İnceleyen kişi "burada gerçekten satış var mı" sorusuna yanıt arıyor.
4. Fiyat ve kargo bilgisi belirsiz. KDV dahil mi, kargo ücreti ne, teslim süresi kaç gün — bunlar yazmıyorsa risk sinyali sayılır.
5. Site HTTPS değil ya da sertifika hatalı. Ödeme alacak bir sitede bu tartışmasız bir ret sebebidir. Sertifika türü seçimi için ücretsiz SSL mi ücretli SSL mi yazısı yol gösterir.
6. İletişim bilgisi yetersiz. Sadece bir form var, adres ve telefon yok. Kurumsal bir e-posta adresi yerine ücretsiz bir posta hesabı kullanılıyor.
7. Yasaklı veya kısıtlı ürün kategorisi. Reçeteli ilaç, silah, kripto varlık, kumar, yetişkin içerik, bazı takviye edici gıdalar. Bir kısmı için ek izin belgesi gerekir.
8. Alan adı çok yeni ve içerik ince. Bu tek başına ret sebebi değildir ama diğer eksiklerle birleşince tereddüt yaratır.
9. Şirket adresi ile fatura adresi tutarsız.
10. Dropshipping / ön sipariş modeli açıkça yazılmış. Teslim süresi uzun olan modeller itiraz riski yüksek sayılır; reddedilmez ama ek teminat veya uzun valör istenebilir.

Başvuru öncesi yapılacak iş basit: bu on maddeyi bir kontrol listesi gibi tek tek doğrulayın. Reddedilen bir başvuruyu tekrar açtırmak, ilk seferde doğru göndermekten her zaman daha yorucudur.

Komisyon, Valör ve Taksit Maliyeti Nasıl Hesaplanır#

Komisyon oranı tek bir sayı değildir; işlem türüne göre değişen bir tablodur. Tek çekim, 2 taksit, 6 taksit ve 12 taksit farklı oranlara tabidir çünkü taksitte parayı size peşin veren taraf bankadır ve o farkı finanse eder.

Hesabın mantığını sabit bir oran vererek değil, formülle göstermek daha doğru — çünkü oranlar sözleşmeden sözleşmeye ve dönemden döneme değişir:

Net hakediş = Brüt tutar
            − (Brüt tutar × komisyon oranı)
            − (Komisyon üzerinden hesaplanan BSMV/vergi, sözleşmeye göre)
            − Varsa işlem başı sabit ücret

Diyelim komisyon oranınızın tek çekimde %2,5, 6 taksitte %6 olduğunu varsayalım (bu bir örnek varsayımdır, teklif değildir). 1.000 TL'lik bir satışta tek çekimde 25 TL, 6 taksitte 60 TL komisyon ödersiniz. Aradaki 35 TL, "6 taksit yapalım da satış artsın" kararının gerçek maliyetidir. Kâr marjınız %10 ise 6 taksitli satışta marjınızın yarısından fazlasını komisyona vermiş olursunuz.

Valör, işlemin hesabınıza geçmesi için beklenen gündür. "T+1" ertesi iş günü, "T+7" yedi gün sonra demektir ve iş günü üzerinden sayılır. Cuma günü yapılan T+2 bir satışın parası salı günü gelir; araya resmî tatil girerse daha da uzar. Yeni açılan işletmelere risk gerekçesiyle daha uzun valör verilmesi olağandır ve ciro geçmişi oluştukça pazarlığa açıktır.

Son satırı özellikle sorun: iade edilen bir siparişte komisyon geri veriliyor mu? Bazı sözleşmelerde verilmez. İade oranı yüksek bir kategoride (giyim gibi) çalışıyorsanız bu tek madde, komisyon oranındaki yarım puanlık farktan daha çok para eder.

Teknik Entegrasyon: Sunucu Tarafında Ne Gerekir#

Ödeme entegrasyonunun sunucu tarafında beklentileri nettir ve paylaşımlı hosting üzerinde de karşılanabilir; ihtiyaç duyulan şey güçlü donanım değil, doğru yapılandırmadır.

Geçerli TLS. Ödeme sayfası ve callback adresi HTTPS olmalı, sertifika zinciri eksiksiz olmalı. Zinciri komut satırından doğrulayın:

# Sertifika zinciri ve süresi
openssl s_client -connect ornek.com.tr:443 -servername ornek.com.tr </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

# Sadece HTTP başlıklarını görmek için
curl -sI https://ornek.com.tr/odeme/callback | head -20

unable to get local issuer certificate çıktısı görüyorsanız ara sertifika (chain) eksiktir; tarayıcı bunu tolere edebilir ama bankanın sunucu-sunucu isteği tolere etmez.

Giden bağlantıya izin. Bazı entegrasyonlarda sizin sunucunuz bankaya doğrudan istek atar. Paylaşımlı hostingte giden portlar kısıtlı olabilir; kısıtlıysa istek sessizce zaman aşımına düşer ve hatayı ancak loglarda görürsünüz.

Sabit çıkış IP'si. Bazı bankalar üye işyerinin IP adresini beyaz listeye alır. Paylaşımlı sunucuda çıkış IP'si paylaşılır ve değişebilir; IP kısıtı olan bir entegrasyonda VDS gibi kendi IP'nizin olduğu bir ortam gerekir.

Callback adresi WAF veya bot korumasının arkasında kalmamalı. Bankadan gelen POST isteği tarayıcı gibi davranmadığı için agresif bot kurallarına takılabilir. Ödeme dönüş yolunu kural setinden muaf tutun.

Loglama ve idempotency. Her ödeme denemesini orderId ile loglayın ve aynı orderId için ikinci bir başarılı dönüş geldiğinde siparişi tekrar onaylamayın. Ağ tarafında tekrar gönderim (retry) olağandır; idempotent yazmayan sistemler aynı siparişi iki kez kargolar.

# Ödeme dönüş yolunda güvenlik başlıkları ve önbelleklemeyi kapatma
location /odeme/callback {
    add_header Cache-Control "no-store" always;
    add_header X-Content-Type-Options "nosniff" always;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://127.0.0.1:9000;
}

Bir de test aşamasında dikkat: sanal POS sağlayıcıları test (sandbox) ortamı verir. Canlıya geçmeden önce başarısız kart, yetersiz bakiye, 3D iptali ve zaman aşımı senaryolarını mutlaka deneyin. Gerçek hayatta en çok para kaybettiren durum başarılı ödeme değil, yarım kalan ödemedir.

Sıkça Sorulan Sorular#

Şahıs şirketiyle sanal POS alınabilir mi#

Alınabilir. Şahıs şirketi de vergi mükellefidir ve vergi levhası çıkarabildiği için hem bankaların hem ödeme kuruluşlarının kabul ettiği bir yapıdır. Sermaye şirketlerine göre istenen belge sayısı genelde daha azdır; ticaret sicil gazetesi ve imza sirküleri çoğunlukla aranmaz. Buna karşılık ciro geçmişi olmayan yeni şahıs işletmelerine daha uzun valör veya düşük işlem limiti uygulanabilir. Birkaç ay düzenli ciro sonrası bu koşullar yeniden görüşülebilir.

Vergi levhası olmadan sanal POS alınır mı#

Hayır, alınamaz. Sanal POS bir üye işyeri sözleşmesidir ve karşı tarafın vergi mükellefi olması yasal bir zorunluluktur; bu yüzden vergi levhası veya mükellefiyet yazısı istisnasız istenir. Esnaf muafiyeti kapsamında satış yapanlar da bu kapsamda sanal POS alamaz, çünkü muafiyet vergi mükellefiyeti anlamına gelmez. Kartla tahsilat yapmak istiyorsanız önce mükellefiyet tesis ettirmeniz gerekir. Tek istisna, pazaryeri üzerinden satış yapmaktır: orada tahsilatı pazaryeri kendi POS'uyla yapar.

Komisyon oranı neden herkese farklı çıkıyor#

Komisyon, riskin fiyatlanmasıdır ve risk her işletmede farklıdır. Sektörünüz (iade oranı yüksek mi), aylık ciro büyüklüğünüz, ortalama sepet tutarınız, işletmenin yaşı, geçmiş itiraz oranınız ve taksit dağılımınız orana doğrudan etki eder. Aynı gün iki farklı işletmeye aynı bankadan farklı oran çıkması bu yüzden normaldir. Ciro büyüdükçe orana itiraz etme gücünüz artar; ilk sözleşmeyi kalıcı kabul etmeyin, altı ay sonra yeniden görüşün.

3D Secure zorunlu mu#

Kart kuruluşlarının ve düzenleyicilerin yaklaşımı 3D Secure'ü fiilen zorunlu hale getirmiştir; pratikte çoğu üye işyeri sözleşmesi 3D'siz işlem izni vermez. Vermesi durumunda bile 3D'siz işlemde itiraz riski tamamen size aittir: kart sahibi "ben yapmadım" derse tutar hesabınızdan geri alınır. 3D Secure ile yapılan işlemde bu sorumluluk büyük ölçüde bankaya geçer. Kısacası 3D'siz işlem, kâğıt üzerinde biraz daha yüksek dönüşüm, gerçekte çok daha yüksek risk demektir.

Valör süresi kısaltılabilir mi#

Kısaltılabilir, ancak zamanla ve veriyle. Yeni işletmelere uzun valör verilmesinin sebebi iade ve itiraz geçmişinizin bilinmemesidir. Birkaç ay boyunca düşük itiraz oranı, düzenli ciro ve temiz işlem deseni gösterdiğinizde valörün kısaltılmasını talep edebilirsiniz. Ödeme kuruluşlarında bu talep genelde hesap yöneticisi üzerinden, bankada ise şube üzerinden ilerler. Ciro hacminiz belirli bir eşiği geçtiğinde teklif zaten kendiliğinden gelir.

Birden fazla sanal POS aynı anda kullanılabilir mi#

Kullanılabilir ve büyüyen işletmelerde yaygın bir uygulamadır. Bir bankanın POS'unda kesinti olduğunda ödeme akışı durmasın diye ikinci bir sağlayıcı yedekte tutulur; ayrıca farklı bankaların taksit kampanyalarından yararlanmak için çoklu POS gerekir. Teknik tarafta bunun bedeli, ödeme modülünüzün birden fazla entegrasyonu yönetebilecek şekilde soyutlanmasıdır. Muhasebe tarafında ise her sağlayıcının hakediş raporunu ayrı mutabakat etmeniz gerekir.

Sanal POS başvurusu ne kadar sürede sonuçlanır#

Ödeme kuruluşlarında belgeler eksiksizse süreç genellikle birkaç iş gününde tamamlanır; banka sanal POS'unda şube ve risk birimi incelemesi devreye girdiği için daha uzun sürebilir. Süreyi uzatan şey neredeyse her zaman eksik belge ya da sitedeki eksiklerdir: yasal metin yok, ürünler yayında değil, HTTPS yok. Başvurudan önce bu yazının "neden reddedilir" bölümündeki listeyi tamamlarsanız süreç belirgin şekilde kısalır. Reddedilen bir başvuruda gerekçeyi mutlaka yazılı isteyin; sözlü açıklama çoğu zaman eksik olur.

Sanal POS için özel sunucu şart mı#

Şart değil; düzgün yapılandırılmış bir paylaşımlı hosting üzerinde sanal POS entegrasyonu sorunsuz çalışır. Özel sunucu ihtiyacı iki durumda doğar: bankanın IP beyaz listesi istemesi ve işlem hacminin paylaşımlı ortamın kaynak sınırlarını zorlaması. Kendi IP'nize ihtiyacınız varsa VDS'e geçmek gerekir. Bunun dışında ödeme entegrasyonunun asıl gereksinimi donanım değil, geçerli TLS, güvenilir callback yolu ve doğru loglamadır.

Kapanış#

Sanal POS, e-ticaretin en çok gizli detay barındıran halkasıdır. Karar verirken bakılacak şey tabloda yazan komisyon oranı değil; valör, iade komisyonu politikası, blokaj koşulları ve entegrasyonun sizi ne kadar uğraştıracağıdır. Başvuru tarafında ise gerçek engel mali değil, sitenizin hazır olup olmadığıdır: yasal metinler tam, ürünler yayında, faaliyet konusu tutarlı ve site HTTPS ise başvurular çok büyük oranda geçer. Reddedildiğinizde de gerekçeyi yazılı isteyin — hangi maddede takıldığınızı bilmeden ikinci başvuru da aynı yerden döner.

Ödeme almaya hazır bir altyapı kurarken teknik tarafı da aynı titizlikle ele almakta fayda var. Ürünlerinizi ve ödeme modülünüzü barındıracak bir yer arıyorsanız e-ticaret hosting paketleri bu iş yükü için hazırlanmıştır; bankanın IP beyaz listesi istediği veya işlem hacminizin arttığı bir noktadaysanız kendi IP'nizle çalışabileceğiniz VDS sunucu tarafına geçmek gerekir. Ödeme sayfasının olmazsa olmazı olan sertifikayı SSL sertifikası sayfasından, ödeme dönüş yolunuzu kural setiyle boğmadan koruyacak katmanı ise WAF sayfasından inceleyebilirsiniz.