Sanal POS Nedir, Nasıl Alınır? İşletmeniz İçin Ödeme Modeli Seçimi

İnternetten kartla ödeme almak isteyen işletmelerin ilk sorusu çoğu zaman komisyon oranıdır. Ancak tahsilat sistemini yalnız bu oran üzerinden seçmek, ödeme akışının diğer parçalarını görünmez bırakır. Paranın ne zaman kullanılabilir olacağı, hangi kartlarda taksit sunulacağı, iadelerin nasıl yürütüleceği ve sipariş kaydının nasıl güncelleneceği de kararın parçasıdır.

Düşük komisyonlu bir teklif, uzun tahsilat süresi veya yoğun manuel kontrol gerektiriyorsa işletme için beklenen sonucu vermeyebilir. Daha geniş özellikli bir çözüm de kullanılmayacak hizmetler ve ek bakım yükü oluşturabilir. Doğru karşılaştırma, işletmenin gerçekten ihtiyaç duyduğu tahsilat akışından başlar.

Bu rehberde sanal POS'un görevini, banka ve yetkili ödeme kuruluşu modellerini, başvuru koşullarını ve entegrasyon seçeneklerini birlikte ele alıyoruz. Amaç sağlayıcı sıralamak değil, teklifleri aynı sorularla değerlendirebileceğiniz bir karar modeli oluşturmaktır.

Sanal POS nedir ve ödeme akışında nerede yer alır?

Sanal POS, internet üzerinden kartlı ödeme kabul edilmesini sağlayan tahsilat altyapısıdır. Müşterinin ödeme bilgileri ilgili ödeme akışına iletilir; gerekli kontroller sonucunda işlem onaylanır veya reddedilir. Bankaların resmi ürün açıklamaları da sanal POS'u çevrim içi kart kabulü bağlamında tanımlar. QNB Sanal POS

Sanal POS, mağazanın tamamı değildir. Ürün kataloğunu, stok politikasını veya kargo operasyonunu tek başına yönetmez. Mağaza ile ödeme sistemi arasındaki bağlantı, tahsilat sonucunun doğru siparişe işlenmesini sağlar. Bu bağlantı zayıfsa para alınmasına rağmen sipariş beklemede kalabilir veya başarısız işlem hazırlanacak siparişe dönüşebilir.

Ödeme modeli belirlenirken kart tahsilatının yanında havale, kapıda ödeme veya işletmenin kullandığı diğer yöntemler de düşünülmelidir. Her yöntemin sipariş onayı, takip ve mutabakat ihtiyacı farklıdır. Kartla ödeme altyapısı seçimi, bütün tahsilat planının içinde değerlendirilmelidir.

Ödeme onayı, sipariş kaydı ve hesaba geçiş farklı aşamalardır

Müşterinin ödeme ekranında başarı mesajı görmesi, mağazadaki sipariş kaydının doğru güncellendiğini tek başına kanıtlamaz. Aynı şekilde işlem onayı, tutarın hemen işletmenin banka hesabında kullanılabilir olduğu anlamına gelmez. Teknik sonuç ve sözleşmedeki aktarım takvimi ayrı aşamalardır.

Bu nedenle üç kaydı birlikte düşünün: müşterinin gördüğü sonuç, sağlayıcının işlem kaydı ve mağazanızdaki sipariş durumu. Ardından tahsilatın hesaba geçişini ayrıca izleyin. Model seçimi, bu kayıtların nasıl bağlanacağını ve fark oluştuğunda kimin kontrol edeceğini de açıklamalıdır.

Banka sanal POS'u ile ödeme kuruluşu modeli nasıl ayrılır?

Banka modelinde işletme, bankanın sanal POS hizmeti ve üye işyeri koşulları üzerinden çalışır. Birden fazla banka kullanılıyorsa sözleşme, teknik bağlantı ve mutabakat yapısının nasıl yönetileceği belirlenmelidir. Tek bir banka ilişkisiyle başlamak mümkün olsa da ihtiyaç büyüdükçe yapı değişebilir.

Ödeme veya elektronik para kuruluşu modelinde işletme, ilgili kuruluşun yetkili olduğu hizmet kapsamında tahsilat altyapısından yararlanır. Birden fazla banka bağlantısı veya ödeme seçeneği tek entegrasyonda sunulabilir; gerçek kapsam ürün ve sözleşmeden doğrulanmalıdır. Bütün kuruluşların aynı hizmetleri sunduğu varsayılmamalıdır.

Kuruluşun yalnız marka adını değil, sözleşmedeki tüzel kişiliğini ve güncel faaliyet iznini kontrol edin. TCMB, ödeme kuruluşları ile elektronik para kuruluşlarının izin kapsamlarını ayrı listelerde yayımlar. Elektronik para ihraç yetkisi, her ödeme hizmetinin otomatik olarak sunulabileceği anlamına gelmez. TCMB ödeme kuruluşları, TCMB elektronik para kuruluşları

Tek banka, çoklu banka ve kart kapsamını karıştırmayın

Tek bankanın sanal POS'unu kullanmak, yalnız o bankanın kartlarını kabul etmek anlamına gelmez. Kart kabulü, desteklenen kart ağları ve sözleşme kapsamına bağlıdır. Taksit ve kampanya kapsamı ise kart kabulünden farklı bir konudur.

Çoklu banka yaklaşımı da yalnız kart çeşitliliği için değerlendirilmemelidir. İşlemlerin yönlendirilmesi, farklı ticari koşullar ve bağlantıların yönetimi önem kazanabilir. Ancak çoklu yapı kendiliğinden daha düşük maliyet veya daha yüksek başarı sağlamaz.

Teknik bağlantıları birleştiren bir yazılım katmanının kendisi de mutlaka ödeme kuruluşu değildir. Fon akışını hangi tüzel kişinin yürüttüğünü, sözleşmenin kimle yapıldığını ve teknik hizmetin nerede başladığını açıkça ayırın.

Sanal POS başvurusunda hangi koşullar değişebilir?

Başvuru değerlendirmesi işletmenin hukuki yapısına, faaliyet alanına, satış modeline ve sağlayıcının kabul politikasına göre değişebilir. İstenen belgelerin tamamını tek bir evrensel liste gibi sunmak doğru değildir. Başvuru öncesinde işletmenize uygulanacak güncel listeyi yazılı olarak alın.

Vergi ve şirket bilgileri, yetkili kişiye ilişkin belgeler, hesap bilgileri ve satış sitesinin içeriği incelemeye konu olabilir. Örneğin Garanti BBVA'nın resmi sayfası; ürünlerin sitede hazır bulunması, güvenli bağlantı ve sözleşme metinleri gibi şartları ve işletme türüne göre istenen belgeleri yayımlar. Bunlar ilgili bankanın koşullarıdır. Garanti BBVA başvuru şartları

Başvuru sırasında satışa konu ürün veya hizmeti doğru tanımlayın. Teslimat süresi, abonelik yapısı veya alışılmıştan farklı sipariş modeli varsa açıklayın. Sonradan değişen faaliyet kapsamının sözleşmeye etkisini de öğrenin; başlangıç onayının her yeni satış modelini kapsadığını varsaymayın.

Başvuru onayı ile satışa hazır olmak aynı şey değildir

Başvuru kabul edildikten sonra mağaza hesabı, entegrasyon, işlem yetkileri ve canlı ortam ayarları tamamlanmalıdır. Başarılı ödeme kadar başarısız ödeme, iptal ve iade de doğrulanmalıdır. Onaylanan hizmetin mağazanızda gerçekten çalıştığı gösterilmelidir.

Bu hazırlıkların genel sırası için e-ticaret sitesi kurmak için gerekenler rehberini kullanabilirsiniz. Burada ödeme modelini seçiyoruz; şirketin bütün başlangıç hazırlıklarını veya kurulum adımlarını tekrar etmiyoruz.

Komisyonu toplam tahsilat yükü içinde değerlendirin

Komisyon oranını karşılaştırmadan önce hangi işlemler için geçerli olduğunu sorun. Banka kartı, kredi kartı, yerli veya yabancı kart ve taksitli işlem koşulları farklılaşabilir. Vergi dahil ve hariç tutarları da aynı temelde değerlendirin.

Oranın yanında başlangıç, aylık veya yıllık hizmet bedeli bulunabilir. İşlem başına ücret, minimum bedel, kullanım koşulu veya ek raporlama hizmeti de toplamı etkileyebilir. Resmi banka tarifelerinde komisyon ve bloke seçeneklerinin yanında ayrı hizmet kalemleri görülebilir. Halkbank üye işyeri ücret ve komisyonları

Teklifleri kendi işlem dağılımınızla hesaplayın. Bütün satışların tek çekim ve aynı kart türünde olacağını varsaymak, gerçek yükü yanlış gösterebilir. Sağlayıcıdan, işlem türleri ve aktarım koşulları belirtilmiş örnek bir kesinti dökümü isteyin.

Valör, bloke ve taksit koşulları

Valör, aktarım takvimi ve bloke ifadelerinin sözleşmedeki anlamını netleştirin. Hangi tarihten itibaren sayım yapılıyor? İş günü mü takvim günü mü kullanılıyor? Tatil ve hafta sonu işlemleri nasıl aktarılıyor? Risk nedeniyle ayrıca tutulan rezerv var mı?

Müşteri taksitle öderken işletmenin tahsilatı nasıl alacağını da öğrenin. Taksit sayısı, kart kapsamı ve ürün kategorisine ilişkin uygulanabilir koşullar ayrıca doğrulanmalıdır. "Taksit var" açıklaması bütün kartlarda aynı seçeneğin kullanılabileceğini göstermez.

Tahsilat gecikmesi, kargo ve tedarik ödemelerinizle birlikte değerlendirilmelidir. Bunun nakit etkisini komisyonla aynı satıra gizlemeyin. İki teklifte hem doğrudan hizmet giderini hem paraya erişim takvimini ayrı gösterin; sonucu işletmenizin ödeme planıyla karşılaştırın.

İade, iptal ve chargeback süreçlerini karşılaştırın

İptal ve iade işlemlerinin sağlayıcıdaki teknik anlamları ve uygulanabildikleri aşamalar değişebilir. İşlemin hangi durumda iptal edilebildiğini, tam ve kısmi iadenin nasıl yapıldığını ve sonuçların nasıl takip edildiğini sorun. Aynı terimin bütün sistemlerde aynı akışı taşıdığını varsaymayın.

İade sonrasında ilk işlem kesintilerinin nasıl ele alındığını sözleşmeden doğrulayın. İade işlemi için ayrıca bedel bulunup bulunmadığını ve işletme bakiyesi yetersizken sürecin nasıl yürüdüğünü öğrenin. Bu koşullar müşteriye verilecek bilginin doğruluğunu da etkiler.

Chargeback, işletmenin başlattığı normal iade işleminden farklı bir kartlı işlem itirazı sürecidir. Belge toplama, yanıt süresi, ilgili kesintiler ve sorumluluk sözleşme ile kart kurallarına bağlıdır. Teslimat, iptal ve müşteri iletişimi kayıtlarının gerektiğinde erişilebilir olması önemlidir. Garanti BBVA işlem itirazı açıklamaları

3D Secure neyi çözer, neyi çözmez?

3D Secure, kartlı ödeme sırasında kimlik doğrulama katmanıdır. Doğrulama ile tahsilat onayı aynı işlem sonucu değildir. Müşterinin doğrulama adımını tamamlamasının ardından ödeme yine de reddedilebilir veya teknik sonuç mağazaya doğru işlenmeyebilir.

Başarılı doğrulama bazı yetkisiz işlem itirazlarında sorumluluğu etkileyebilir. Ancak teslim edilmeyen ürün, yanlış hizmet veya diğer uyuşmazlıkları ortadan kaldırmaz. "3D Secure kullanınca chargeback riski sıfırlanır" şeklinde genel bir vaat doğru değildir. Bankanın 3D işlem açıklaması, işlem itirazı kapsamı

Ödeme başarısını checkout dönüşümünden ayırın

Checkout dönüşümü, ödeme aşamasına gelen müşterilerin ne kadarının satın almayı tamamladığını gösterir. Ödeme başarısı ise belirli ödeme denemelerinin sonucunu inceler. Adres formunda ayrılan müşteri ile bankadan ret alan işlem aynı sorunun göstergesi değildir.

Başarısız ödemeleri nedenlerine göre ayırın. Doğrulama sorunu, yetersiz bakiye, desteklenmeyen taksit, risk kontrolü veya teknik bağlantı hatası farklı müdahaleler gerektirir. Her başarısızlığı sağlayıcının altyapı kalitesiyle açıklamak yanıltıcıdır.

Müşteriye verilen mesaj ve yeniden deneme akışı da önemlidir. Teknik hata kodunun doğrudan müşteriye gösterilmesi yerine anlaşılır bir sonuç sunulmalı; ödeme durumu belirsizse yeniden tahsilat yaratılmamalıdır. Sepetin korunması ve işlemin doğru kontrol edilmesi birlikte düşünülmelidir.

Aynı işlem tanımıyla ölçüm yapın

İki sağlayıcının başarı oranını karşılaştırırken payda aynı olmalıdır. Ödeme formunu açanlar, bankaya gönderilen denemeler ve benzersiz siparişler farklı ölçülerdir. Aynı sipariş için tekrar denemeler de sonucu değiştirebilir.

Kart türü, taksit, cihaz ve dönem farklarını dikkate alın. Farklı müşteri gruplarına ait oranları doğrudan karşılaştırmayın. Sağlayıcıdan ölçüm tanımını isteyin; mümkünse kendi işlem kayıtlarınızla doğrulayın. Genel başarı yüzdesi, mağazanızdaki sonucu tek başına öngörmez.

Hosted payment page ve doğrudan entegrasyon nasıl seçilir?

Hosted payment page modelinde kart bilgilerinin girildiği ödeme sayfası sağlayıcı tarafından sunulur. Müşteri başka sayfaya yönlendirilebilir veya sağlayıcının formu mağaza içinde gömülü biçimde gösterilebilir. Garanti BBVA'nın ortak ödeme sayfası bu yaklaşımın banka tarafından sunulan bir örneğidir. Resmi ortak ödeme sayfası açıklaması

Doğrudan entegrasyon ifadesi ise tek bir veri akışını tanımlamaz. Kart bilgisinin işletmenin sunucusuna uğrayıp uğramadığını, formun kim tarafından üretildiğini ve hangi bileşenlerin ödeme verisine eriştiğini ayrıca incelemek gerekir. Ürün adı, teknik sorumluluğun kapsamını açıklamaya yetmez.

Seçimde ekip kapasitesini değerlendirin. Özelleştirilmiş ödeme deneyimi; geliştirme, güvenlik, test ve sürdürme sorumluluğu oluşturabilir. Sağlayıcının sunduğu sayfa da doğru dönüş ve bildirim bağlantısı gerektirir. Her iki modelde mağazanın sipariş akışıyla uyum aranmalıdır.

Görünüm kadar veri akışını değerlendirin

Ödeme ekranının mağazanın içinde görünmesi, kart bilgisinin mağaza sisteminden geçtiğini göstermez. Benzer biçimde başka sayfaya yönlendirme yapılması, işletmenin bütün teknik sorumluluğunu kaldırmaz.

Mobil akışı, geri dönüşü, süre aşımını ve müşterinin sayfayı kapatmasını test edin. Görsel uyumun yanında sonucu izlenebilir kılan bir yapı gerekir. Model seçimi, tasarım tercihiyle teknik veri akışını birlikte açıklamalıdır.

PCI DSS sorumluluğu entegrasyon modeline göre nasıl değişir?

PCI DSS kapsamını belirlerken kart verisinin nerede toplandığına, işlendiğine ve aktarıldığına bakılır. Ödeme işlevlerinin uygun bir üçüncü tarafa dış kaynakla verilmesi işletmenin kapsamını azaltabilir; fakat sorumluluğu otomatik olarak sıfırlamaz.

SAQ, uygun koşullarda kullanılan öz değerlendirme formudur. Hangi formun uygun olduğu yalnız "iframe kullanıyoruz" açıklamasından çıkarılmamalıdır. PCI SSC, gömülü ödeme formuyla yönlendirme akışının bazı uygunluk koşullarında farklı değerlendirildiğini açıklıyor. İşletmenin gerçek uygulaması ve bütün uygunluk şartları birlikte kontrol edilmelidir. PCI SSC: SAQ A ve script güvenliği

PCI SSC'nin Haziran 2026 açıklaması, SAQ A kapsamındaki yönlendirme veya gömülü form kullanan e-ticaret sayfalarında dış güvenlik taraması sorumluluklarının da bulunduğunu belirtiyor. Bu nedenle "kart verisi bize gelmiyor, PCI işi tamamen sağlayıcıda" varsayımı kullanılmamalıdır. PCI SSC: dış tarama sorumlulukları

Sağlayıcıdan veri akışını ve sorumluluk paylaşımını yazılı alın. Uygun doğrulama yöntemini üye işyeri bankası veya ilgili kabul kuruluşuyla netleştirin. Rehberin görevi işletmeye hazır bir uygunluk kararı vermek değil, modelin hangi sorumlulukları doğurduğunu görünür kılmaktır.

E-ticaret altyapısının entegrasyonunu nasıl doğrularsınız?

Altyapının bir sağlayıcıyı desteklemesi önemli bir başlangıçtır. Ancak hazır bağlantının hangi sürümle çalıştığı, hangi işlem türlerini kapsadığı ve bakımını kimin yaptığı da bilinmelidir. Yalnız sağlayıcı logosunun bulunması yeterli değildir.

Ödeme sonucu mağazaya güvenilir biçimde ulaşmalı ve doğru siparişe işlenmelidir. PayTR'nin resmi bildirim dokümanı; sunucu tarafı sonuç bildirimi, doğruluk kontrolü ve tekrar gelen bildirimlerin mükerrer teslimata yol açmaması gibi gereksinimleri açıklıyor. Bunlar ilgili entegrasyonun uygulama koşullarıdır. PayTR sonuç bildirimi dokümanı

Canlıya çıkış kabulünde başarılı işlem, başarısız işlem, kesilen bağlantı, tekrar bildirim ve kısmi iade değerlendirilmelidir. Siparişin aynı işlem için iki kez oluşmadığını da kontrol edin. Uçtan uca hazırlık sırası için e-ticaret sitesi kurulum rehberine geçebilirsiniz.

Mutabakat, raporlama ve destek

Sipariş numarası, ödeme işlem kimliği ve hesaba geçen tutar arasında ilişki kurulmalıdır. Satış, iade, kesinti ve aktarım raporları aynı işlemi izlemeyi kolaylaştırmalıdır. Ekibin her gün elle eşleştirme yapması gerekiyorsa bu emek de modelin yüküdür.

Destekte hangi kanalın hangi sorunu üstlendiğini öğrenin. Banka reddi, ödeme bildirimi ve mağaza modülü arızası farklı taraflarda çözülebilir. Sözleşmedeki erişim saatleri, eskalasyon yöntemi ve teknik destek kapsamı yazılı olmalıdır; belirsiz "destek var" açıklaması yeterli değildir.

Sanal POS teklif karşılaştırma matrisini doldurun

Aşağıdaki matrisi aynı satış modeli ve işlem dağılımıyla doldurun. "Var" yanıtı yerine koşulu yazın. Bir özellik yalnız belirli kartlarda veya paketlerde kullanılabiliyorsa bunu görünür hale getirin.

Matrisin yanında teklif tarihini, geçerlilik süresini ve sözleşme eklerini kaydedin. Belirsiz hücreleri sıfır veya olumlu varsayımla doldurmayın. Eksik bilgi de kararın bir parçasıdır; önce toplamı değiştiren eksikleri doğrulayın.

Tahsilat modelini işletmenizin akışına göre seçin

Önce vazgeçilmez koşulları belirleyin. Kullanılan altyapıyla çalışmayan, gerekli tahsilat biçimini karşılamayan veya nakit takviminize uymayan seçenekler yalnız düşük komisyon nedeniyle uygun hale gelmez. Ardından yeterli seçeneklerin toplam yükünü karşılaştırın.

Gerçekleşen kesintilerle ödeme kontrolüne ayrılan emeği izlemek için e-ticaret operasyon maliyetleri modelini kullanabilirsiniz. Bu hesap, teklif aşamasındaki varsayımların gerçek siparişlerde nasıl sonuç verdiğini gösterir.

Karar sonrasında da koşulları yeniden değerlendirin. Kart dağılımı, satış hacmi, taksit ihtiyacı veya ekip yapısı değişebilir. İlk gün uygun olan modelin büyüyen operasyon için aynı sonucu vereceği varsayılmamalıdır. Değerlendirme, gerçekleşmiş kayıtlarla güncellenmelidir.

Kaynak kontrol tarihi: 9 Ekim 2026. Banka, ödeme kuruluşu ve PCI SSC koşulları değişebilir; teklif aşamasında güncel resmi metinleri esas alın.