Sanal POS Entegrasyonu: E-Ticaret Ödeme Altyapısı Rehberi

Bir e-ticaret sitesinde ödemeyi tahsil etmek göründüğünden fazlasıdır: kartın doğrulanması, 3D Secure adımı, taksit seçeneklerinin doğru gösterilmesi, başarısız ödemelerin yönetilmesi ve iade/iptal süreçlerinin sağlıklı işlemesi gerekir. Bunların tamamı sanal POS entegrasyonu ile kurulur. Sanal POS, daha geniş e-ticaret entegrasyonları zincirinin ilk halkasıdır; bu rehber, hangi ödeme altyapısını seçeceğinizi, entegrasyonun nasıl çalıştığını ve pazaryeri kuruyorsanız işleri değiştiren submerchant modelini açıklar.

Sanal POS nedir ve nasıl çalışır?

Sanal POS, fiziksel bir POS cihazı olmadan internet üzerinden kart ile ödeme almanızı sağlayan altyapıdır. Basitleştirilmiş akış şöyledir: müşteri kart bilgisini girer → istek ödeme sağlayıcısına iletilir → 3D Secure ile banka müşteriyi doğrular → banka tahsilatı onaylar → siteye başarılı/başarısız sonucu döner. Başarılı sonuç, sipariş onayını ve sonraki adımları (fatura, kargo) tetikler.

Kritik nokta: bu akışta kart verisinin sizin sunucunuza uğramaması gerekir. Modern entegrasyonlar, kart bilgisini doğrudan sağlayıcının güvenli sayfasında/iFrame’inde toplar; böylece hem güvenlik artar hem de yasal yük (PCI-DSS) azalır. Bu konuya aşağıda ayrıca değiniyoruz.

Banka sanal POS mu, ödeme kuruluşu (PSP) mu?

İki temel yol vardır ve karar, hacminize ve operasyon tercihinize bağlıdır.

Ölçüt	Banka sanal POS	Ödeme kuruluşu / PSP (iyzico, PayTR vb.)
Entegrasyon sayısı	Her banka için ayrı API	Tek API ile birçok banka
Kurulum hızı	Yavaş (banka başına anlaşma)	Hızlı
Komisyon	Genelde daha düşük	Genelde daha yüksek
3DS / taksit yönetimi	Kendiniz kurgularsınız	Hazır gelir
Pazaryeri / submerchant	Yok (kendiniz çözemezsiniz)	Destekler
Uygun profil	Yüksek hacim, tek tahsilat hesabı	Hız ve esneklik önceliği, pazaryeri

Pratikte çoğu e-ticaret operasyonu bir ödeme kuruluşu ile başlar: tek API, hızlı kurulum, hazır 3DS ve taksit yönetimi. İyzico ve PayTR bu alanda en yaygın tercihlerdir; ikisi de düzenleyici lisansına sahip kurumlardır. Banka sanal POS’a geçiş, hacim büyüyüp komisyon farkının anlam kazandığı ve teknik ekibin bu yükü taşıyabildiği noktada mantıklı hale gelir.

3D Secure zorunlu mu?

E-ticaret için pratikte evet. 3D Secure (3DS), ödeme sırasında kart sahibinin banka tarafından doğrulanmasıdır (SMS/uygulama onayı). İki önemli faydası vardır: dolandırıcılığı ciddi biçimde azaltır ve sahtecilik durumunda sorumluluğu (chargeback riski) bankaya kaydırır. 3D’siz (non-secure) tahsilat teknik olarak mümkün olsa da, çoğu sağlayıcı e-ticaret için kısıtlar ve risk işletmede kalır. Öneri: e-ticarette varsayılan olarak 3DS kullanın.

Taksit ve komisyon nasıl yönetilir?

Türkiye pazarında taksit belirleyicidir. Doğru entegrasyon, müşteri kartını girdiği anda BIN sorgusu yaparak kartın bankasını ve o bankaya uygun taksit seçeneklerini (Bonus, World, Maximum, Axess, Paraf vb.) gösterir. Yanlış taksit tablosu göstermek hem satış kaybettirir hem de tahsilat hatalarına yol açar.

Komisyon; sağlayıcıya, taksit sayısına ve kart tipine göre değişir. İyi kurgulanmış bir sistemde komisyon farklarını fiyatlandırmaya yansıtma kuralları (taksit farkı) da entegrasyonun parçasıdır. Komisyon oranları zamanla değiştiği için sağlayıcınızdan güncel tabloyu almanızı öneririz.

Pazaryeri kuruyorsanız: alt üye iş yeri (submerchant) modeli

Standart e-ticarette para tek bir hesaba akar. Ancak birden fazla satıcının yer aldığı bir pazaryeri/platform kuruyorsanız (örneğin farklı işletmelerin satış yaptığı bir platform ya da rezervasyon sistemi), her satıcıya ait tahsilatın ayrıştırılıp doğru tarafa ödenmesi gerekir. Bunu alt üye iş yeri (submerchant) modeli çözer.

Bu modelde entegrasyonun ele alması gerekenler:

Satıcı (submerchant) kaydı ve KYC: Her satıcının kimlik/işletme doğrulaması.
Ödeme bölüştürme (split): Tek bir müşteri ödemesinin komisyon ve satıcı payına ayrılması.
Ödeme (payout) takvimi: Satıcılara ne zaman, ne kadar aktarılacağı; gerekiyorsa bloke/escrow süresi.
İade akışının satıcı bazında yönetimi.

İyzico’nun submerchant modeli bu senaryo için yaygın kullanılır. Bu tip bir platform, standart bir mağaza entegrasyonundan belirgin şekilde daha karmaşıktır ve neredeyse her zaman özel geliştirme gerektirir — hazır eklentiler tek satıcılı akış için tasarlanmıştır. Çok satıcılı stok ve sipariş tarafı için pazaryeri entegrasyonu rehberine de göz atabilirsiniz.

İptal, iade ve kısmi iade senaryoları

Ödeme entegrasyonunun olgunluğu satış sonrası ortaya çıkar:

İptal (void): Tahsilat henüz bankaya kesinleşmeden (valör öncesi) aynı gün geri alınır. Genelde komisyon iadesi lehinizedir.
İade (refund): Tahsilat kesinleştikten sonra yapılan geri ödemedir; farklı bir API çağrısıdır ve komisyon iadesi sağlayıcıya göre değişir.
Kısmi iade: Siparişin bir kısmı iade edildiğinde tutar bazında geri ödeme; e-fatura tarafıyla senkron çalışmalıdır. (Bkz. E-fatura entegrasyonu)
Başarısız/askıda ödeme: 3DS yarıda kalan ya da timeout olan işlemlerin loglanıp mükerrer tahsilat oluşturmadan yönetilmesi.

Bu senaryoların iade/iptal ekranlarınızla ve muhasebeyle entegre olması gerekir; aksi halde tahsilat ile kayıt arasında fark birikir. (Bkz. Muhasebe entegrasyonu)

PCI-DSS ve güvenlik: kart verisi saklanmalı mı?

Kısa cevap: hayır, saklamayın. Kart numarasını (PAN) sisteminizde tutmak sizi ağır PCI-DSS yükümlülüklerinin içine sokar. Doğru yaklaşım, kart verisini sağlayıcının güvenli sayfasında/iFrame’inde toplamak ve tekrar eden ödemeler için tokenizasyon kullanmaktır — böylece elinizde gerçek kart yerine güvenli bir jeton bulunur. Bu hem güvenliği artırır hem de uyum kapsamınızı ciddi biçimde daraltır. E-ticarette güvenliğin bütününe E-ticarette güvenlik: KVKK, SSL ve güvenli ödeme yazımızdan bakabilirsiniz.

Hazır ödeme eklentisi mi, özel entegrasyon mı?

Tüm entegrasyon başlıklarında geçerli olan dürüst çizgi burada da geçerli:

Durum	Hazır eklenti	Özel entegrasyon
Tek satıcılı standart mağaza	Yeterli	Gereksiz
BIN bazlı özel taksit/komisyon kuralları	Sınırlı	Serbest
Pazaryeri / submerchant	Uygun değil	Şart
İade + e-fatura + muhasebe senkronu	Kısmi	Uçtan uca
Yüksek hacimde loglama/retry	Değişken	Kontrollü

Tek satıcılı, standart bir mağaza için hazır eklenti yeterlidir. Pazaryeri kuruyorsanız, özel taksit/komisyon kurallarınız varsa ya da ödeme–fatura–muhasebe zincirini kusursuz senkron istiyorsanız özel entegrasyon gerekir. RED Bilişim’in .NET tarafı özellikle submerchant modelli platformlar ve karmaşık ödeme kuralları için kurgulanır.

Sıkça sorulan sorular

Sanal POS nedir? Fiziksel cihaz olmadan internet üzerinden kart ile ödeme almanızı sağlayan altyapıdır. Kart doğrulama, 3D Secure, taksit ve tahsilat adımlarını yönetir.

Banka sanal POS mu, ödeme kuruluşu mu daha iyi? Çoğu operasyon için ödeme kuruluşu (iyzico, PayTR) tek API, hızlı kurulum ve hazır taksit/3DS yönetimi sunar. Banka sanal POS, yüksek hacimde komisyon avantajı için tercih edilir.

3D Secure zorunlu mu? E-ticaret için pratikte evet. Dolandırıcılığı azaltır ve sahtecilik sorumluluğunu bankaya kaydırır; varsayılan olarak kullanılması önerilir.

Pazaryeri için hangi ödeme modeli gerekir? Birden fazla satıcıya ödeme dağıtan platformlar alt üye iş yeri (submerchant) modelini kullanır: ödeme bölüştürme, satıcı KYC ve payout takvimi gerektirir. Genellikle özel geliştirme ister.

Ödeme entegrasyonunda kart bilgisi saklamak zorunda mıyım? Hayır. Kart numarasını saklamak PCI-DSS yükünü artırır. Kart verisini sağlayıcıda toplayıp tekrar eden ödemeler için tokenizasyon kullanmak en güvenli yoldur.

Ödeme altyapınızı submerchant modeli veya özel tahsilat kurallarıyla kurmak mı istiyorsunuz? RED Bilişim, .NET tabanlı özel çözümlerle sanal POS entegrasyonunu iade ve muhasebe senkronuyla birlikte kurar. E-ticaret entegrasyon hizmetlerimizi inceleyin.