Tek entegrasyonla çok bankalı kart kabulü: operasyonel yük nereden nereye taşınır?

Çok bankalı kart kabulünde asıl maliyet kalemi kartların kendisi değil, kurulan bağlantı sayısıdır. Bir işletme hangi bankaların kartlarını kabul edeceğine karar verdiğinde aslında kaç ayrı sözleşmeyi, kaç ayrı test döngüsünü ve kaç ayrı hata kodu setini kimin taşıyacağına da karar vermiş olur. Tek entegrasyon modeli bu yükü yok etmez, sahibini değiştirir. Değişimin tam olarak nerede gerçekleştiğini görmek için işi kalem kalem ayırmak gerekir.

Her banka ayrı bir bağlantı demekse yük nasıl çoğalır

Bankalarla doğrudan çalışan bir kurulumda her banka kendi başına küçük bir proje gibi davranır. Sözleşme süreci, üye işyeri tanımı, teknik dokümantasyon, test ortamı ve canlıya geçiş onayı bankadan bankaya değişir. Bu yüzden ikinci bankayı eklemek birinci bankanın işini yarıya indirmez, aynı işi bir kez daha yaptırır.

Doğrudan modelde her banka için ayrı yürütülen kalemler şunlardır:

• Sözleşme, üye işyeri tanımı ve erişim bilgilerinin ayrı ayrı yönetilmesi
• Her bankanın kendi mesaj yapısına ve dokümantasyonuna göre yazılan entegrasyon kodu
• Ayrı test ortamı, ayrı test kartları ve ayrı canlıya geçiş kontrolü
• 3D Secure yönlendirmesinin banka tarafındaki davranış farkları
• Bankaya özgü hata kodlarının okunup müşteriye anlamlı bir mesaja çevrilmesi
• Taksit ve kampanya kurallarının her program için ayrı takibi
• Mutabakat ve raporlama dosyalarının farklı formatlarda işlenmesi

Bu kalemlerin ortak özelliği, teknik ekibin zamanını ürün geliştirmeden alıp bağlantı bakımına aktarmasıdır. Sepet akışını iyileştirmesi beklenen ekip, gününü hangi bankanın hangi durumda hangi hata kodunu döndürdüğünü çözmeye ayırır.

Yük tek seferlik de değildir. Regresyon testi matrisi banka sayısıyla birlikte büyür ve bir bankanın kendi tarafında yaptığı değişiklik işletmenin kod tabanında karşılık bulur. Doğrudan model, bu nedenle ödeme akışını sürekli bakım isteyen bir bileşene dönüştürür.

Tek bağlantı modeli işi nereye taşır

Tek entegrasyon modelinde işletme tarafında tek bir bağlantı vardır ve banka çeşitliliği o bağlantının arkasında yönetilir. Bu yüzden online ödeme için sanal POS değerlendiren bir ekibin sorması gereken ilk soru desteklenen banka sayısı değildir. Asıl soru şudur: bu bankalar tek sözleşme ve tek bağlantı üzerinden mi yönetiliyor, yoksa listedeki her satır ayrı bir entegrasyon işi olarak geri mi gelecek.

SanalPos.com kendi modelini tek başvuru ve tek entegrasyon üzerine kurar; her bankayla ayrı sözleşme yapılması ve ayrı bağlantı yazılması beklenmez. Kart tarafında Visa, Mastercard, Troy ve American Express olmak üzere dört kart ağı, taksit tarafında ise Axess, Bonus, Maximum, World ve Paraf gibi programların da içinde olduğu 9+ taksit programı aynı akıştan yürütülür.

Burada karışması kolay bir nokta var: taşınan şey iş yüküdür, para değildir. SanalPos.com bir banka değildir, ödeme kuruluşu veya elektronik para kuruluşu statüsü de taşımaz. Sunduğu şey teknik ödeme altyapısıdır ve 6563 sayılı kanun çerçevesinde aracı hizmet sağlayıcı olarak faaliyet gösterir. Kart işleminden doğan tutar bir ara hesapta biriktirilip sonradan gönderilmez, üye işyeri adına tanımlanan sanal POS üzerinden doğrudan işletmenin kendi banka hesabına aktarılır. Ödeme günü sitede T+1 olarak belirtilir.

Kurulum tarafında da tek kapı vardır. Başvuru formu 30 saniyelik bir adım olarak tanımlanır, belgeler panelden yüklenir ve marka, belgeler eksiksizse başvurunun 24 saat içinde sonuçlandığını belirtir. Süreç şubeye gitmeden, ıslak imza ve kargo olmadan tamamlanır. Onaydan sonra ödeme almaya başlamak için API, hazır eklenti veya ödeme linki seçeneklerinden biri kullanılır; sitede bu adım için 15 dakika süresi verilir.

Aynı iş kalemleri iki modelde nasıl dağılır

İki modeli karşılaştırmanın en dürüst yolu, aynı iş kalemini alıp sorumluluğun hangi tarafta durduğuna bakmaktır.

Tablodaki asıl bilgi sütunların içeriği değil, sağ sütunun tekrarsızlığıdır. Doğrudan modelde her satır banka sayısıyla çarpılır. Tek entegrasyon modelinde satırlar çarpılmaz, tek yerde toplanır. Teknik ekip açısından fark da burada ortaya çıkar: bakım işi ortadan kalkmaz, tek bir arayüzün bakımına iner.

Tek entegrasyon neyi ortadan kaldırmaz

Bağlantı sayısının azalması ödeme operasyonunun bittiği anlamına gelmez. Hiçbir altyapının devralmadığı işler işletmede kalır:

• Başvuru belgelerinin hazırlanması: güncel vergi levhası, şirket yetkilisinin kimlik belgesi, şirket adına açılmış banka hesabı, limited ve anonim şirketlerde imza sirküleri
• Web sitesinden ödeme alınacaksa SSL sertifikası, e-ticaret sitesi için mesafeli satış sözleşmesi gibi yayın koşulları
• Sipariş durumlarının kendi sisteminizde doğru yönetilmesi, iade ve iptal kararlarının verilmesi
• Muhasebe tarafında mutabakat ve kayıt düzeni; Logo, Luca veya Paraşüt gibi entegrasyonlar bu işi kolaylaştırır, yerine geçmez
• Müşteriyle iletişim: başarısız işlem sonrası yönlendirme, iade süresi bilgisi, itiraz süreçlerinde yanıt

Maliyet tarafında da net olmak gerekir. Kurulum ücreti ve aylık sabit ücret ₺0 olarak belirtilir, taahhüt ve aylık minimum işlem zorunluluğu yoktur, ücret yalnızca başarılı işlemlerden alınan komisyondur. Komisyon oranı işletmeye özel belirlenir ve sitede herhangi bir oran rakamı yayımlanmaz. Oranı etkileyen dört değişken açıkça yazılır: kart ailesi, taksit sayısı, aylık işlem hacmi ve sektör. Yani tek entegrasyona geçmek sabit gideri sıfırlar, işlem başına maliyeti ortadan kaldırmaz.

Hangi işletme hangi modele yakın durur

Doğrudan banka entegrasyonu her durumda yanlış değildir. Ayrım, işletmenin ödeme akışını kendi ürününün bir parçası olarak görüp görmediğinde ortaya çıkar.

• Kendi ödeme ekibini besleyen, banka koşullarını tek tek pazarlık edebilen ve bu bakımı sürekli üstlenmeyi göze alan yüksek hacimli işletmeler doğrudan modelden değer çıkarabilir
• Teknik ekibini ürün tarafında tutmak isteyen e-ticaret, SaaS ve abonelik iş modellerinde tekrarlanan bağlantı bakımı doğrudan kayıptır
• Geliştirici kaynağı olmayan işletmeler için karar zaten teknik değildir; kodsuz POS, hazır eklenti ve ödeme linki seçenekleri bağlantı işini tamamen dışarıda bırakır
• Çok şubeli yapılarda ve bayi tahsilatında yük banka sayısından çok raporlama tarafında birikir, bu durumda tek panelden izleme bağlantı sayısından daha belirleyicidir

Karar sorusu şudur: önümüzdeki bir yılda ödeme akışına ayıracağınız geliştirici zamanı yeni özellik üretmeye mi, yoksa mevcut bağlantıları ayakta tutmaya mı gidecek. Cevap ikincisiyse bağlantı sayısını azaltmak bir mimari tercih değil, kaynak tahsisi kararıdır.

Sık sorulan sorular

Tek entegrasyonla hangi kart ağları ve taksit programları kapsanır

Kart tarafında Visa, Mastercard, Troy ve American Express olmak üzere dört kart ağı yer alır. Taksit tarafında Axess, Bonus, Maximum, World ve Paraf gibi programların da bulunduğu 9+ taksit programı aynı bağlantı üzerinden çalışır. Fiyatlandırma sayfasında 2-12 ay aralığı, başvuru sayfasında ise 12 aya kadar taksit belirtilir. Dövizli satış yapan işletmeler için 10+ para biriminde ödeme seçeneği ayrıca tanımlıdır.

Banka sayısı arttıkça komisyon yapısı da karmaşıklaşır mı

Komisyon işletmeye özel belirlendiği için tek bir listeden okunmaz. Sitede oranı etkileyen dört değişken sayılır: kart ailesi, taksit sayısı, aylık işlem hacmi ve sektör. Banka sayısı bu başlıkların dışında ayrı bir kalem olarak yazılmaz. Tahmini bir sonuç görmek isteyenler için komisyon hesaplayıcı aracı sunulur. Ücret yalnızca başarılı işlemlerden alınır, başarısız veya iptal edilen işlem için ödeme yapılmaz.

Geliştirici ekibi olmayan bir işletme bu modeli kullanabilir mi

Evet. Kodsuz POS, hazır eklentiler ve ödeme linki seçenekleri kod yazmadan ödeme almayı mümkün kılar. Kendi akışını kurmak isteyen ekipler içinse REST API, webhook desteği, PHP, Node.js ve Python SDK’ları ile test kartlarının bulunduğu sandbox ortamı vardır.

Güvenlik güncellemeleri hangi tarafın işi olur

Ödeme bağlantısının güvenlik katmanı sağlayıcı tarafında yönetilir: PCI-DSS uyumlu altyapı, 256-bit SSL şifreleme, tüm hesaplarda varsayılan olarak aktif 3D Secure ve SmartCheck adı verilen yapay zeka destekli sahtecilik önleme katmanı. İşletmenin kendi sitesindeki SSL sertifikası, sipariş verisinin korunması ve panel erişim yetkilerinin düzeni ise işletmede kalır.