E-ticaret sitesine sanal POS kurmak tek bir iş değildir ve kurulumdaki gecikmelerin çoğu bu iki işin birbirine karıştırılmasından doğar. Bir tarafta bankayla yürüyen ticari başvuru vardır, diğer tarafta sitenin ödeme altyapısına bağlanması. Teknik tarafta seçilecek üç yol bulunur: hazır eklenti, API ve SDK. Aralarındaki tercihi sitenin cirosu veya trafiği değil, o siteye kimin dokunduğu belirler.

Yolu doğru seçmek kurulum süresini kısaltmaktan fazlasını yapar. Yanlış seçilen yol, ödeme adımında küçük bir değişiklik istediğinizde ya bir geliştiriciyi zorunlu kılar ya da eklentinin izin verdiği kadarıyla yetinmenizi gerektirir. Bu yüzden karar, ekipte bir yıl sonra kimin olacağına da bakılarak verilir.

Ticari başvuru ile teknik bağlantı aynı takvimde yürümez

Ticari hat bankayla kurulur. İşletme çalışmak istediği bankaya başvurur, onay çıktığında banka üye işyeri adına bir POS tanımlar ve komisyon oranı o bankayla imzalanan sözleşmede belirlenir. Ödeme altyapısı sağlayıcısı bu oranın tarafı değildir; oran işletmenin kendi banka sözleşmesinin konusudur.

Teknik hat ise sitenin bu POS ile nasıl konuşacağıyla ilgilidir. Ödeme geçidi, sitedeki sipariş ile banka tarafındaki işlem arasındaki iletişimi kurar, kart verisini kendi güvenli ortamında işler ve sonucu siteye geri bildirir. Tahsilat.com bu hatta teknik ödeme altyapısını kuran taraftır; ödeme kuruluşu veya elektronik para kuruluşu sıfatı taşımaz. Müşterinin ödediği tutar altyapı sağlayıcısının hesabında beklemez, üye işyeri adına tanımlanan sanal POS üzerinden doğrudan işletmenin kendi banka hesabına aktarılır.

Ücret tarafında da iki kalem ayrı durur. Banka komisyonu yukarıdaki sözleşmeye bağlıdır. Altyapı tarafında kurulum ücreti ve taahhüt yoktur, ücretlendirme başarılı işlemler üzerinden yapılır, başvurunun kendisi ücretsizdir. Başvuru sayfasında yayınlanan “%0,79’dan başlayan oranlar” ifadesi bir başlangıç oranıdır ve her işletmeye uygulanan sabit bir oran anlamına gelmez. Sitede görünen aylık paket ücretleri ise Pos Yönlendirme ve B2B bayi tahsilatı ürünleri içindir; yalnızca sanal POS başvurusu yapan bir işletme için aylık paket bedeli çıkmaz.

İki hattın ayrı yürümesinin pratik sonucu şudur: banka onayı beklenirken teknik kurulum durmaz. Altyapı tarafında 25 banka ve kuruluşla entegrasyon bulunduğu için banka seçimi, site tarafındaki bağlantı yönteminden ayrı bir karar olarak kalır.

Üç entegrasyon yolu ve karşılık geldikleri ekip profilleri

Üç yol da aynı altyapıya bağlanır. Arkadaki sanal POS her üçünde aynı işi yapar, kart doğrulaması aynı katmandan geçer, tutar aynı hesaba gider. Değişen tek şey sitenizle altyapı arasındaki bağlantıyı kimin ve ne kadar kodla kurduğudur.

Hazır eklenti: kod yazmadan bağlanan yol

Site hazır bir e-ticaret altyapısı üzerinde çalışıyorsa en kısa yol budur. Magento (Adobe Commerce), OpenCart, Ticimax ve PrestaShop tarafında hazır entegrasyonlar bulunur. Eklenti kurulur, panelden üye işyeri bilgileri girilir, ödeme yöntemi açılır. Sosyal medya ve pazaryeri üzerinden yürüyen satışlar için de hazır bağlantılar vardır.

Bu yol, içeride sürekli çalışan bir geliştirici bulundurmayan işletmelere oturur. Site bakımını bir ajansa veya tek bir yazılımcıya yaptıran, ödeme adımının standart görünmesinde sakınca görmeyen ekipler kurulumu genelde siteyi zaten yöneten kişiyle tamamlar.

API: ödeme adımını kendi yazan ekip için

Site özel yazılmışsa veya ödeme adımı standart bir eklentinin sunduğundan farklı çalışıyorsa bağlantı doğrudan API üzerinden kurulur. Bu yolda isteğin gövdesi, imza üretimi, hata kodlarının karşılığı ve sonuç bildiriminin işlenmesi işletmenin kendi kodunda yönetilir. Karşılığında ödeme adımının nerede, hangi sırada ve hangi ekranla görüneceği tamamen işletmenin kontrolünde kalır.

Profil nettir: sürekli çalışan bir backend geliştiricisi olan, sipariş yönetimini kendi yazmış ekipler. API dokümantasyonu bu yolun ana referansıdır ve entegrasyonun bakımı da aynı ekipte kalır.

SDK: API’yi hazır paketle kullanan orta yol

SDK, API çağrılarını hazır fonksiyonlara çeviren kütüphanedir. İmza üretimi, istek biçimi ve tekrar eden hata yönetimi kütüphanenin içinde durur, ekip yalnızca kendi iş akışını yazar. Ulaşılan sonuç API ile aynıdır, yol daha kısadır ve entegrasyonun ilk sürümünde yapılan klasik hatalar büyük ölçüde elenir.

Bu yol, geliştiricisi olan ama ödeme entegrasyonuyla ilk kez uğraşan ekiplere ve entegrasyonu kısa sürede bitirip zamanını ürün tarafına ayırmak isteyenlere uygundur.

Her yolun tıkandığı nokta

Hazır eklenti, ödeme adımını ciddi biçimde değiştiren sitelerde dar kalır. Sepet mantığı özel kurallar içeriyorsa veya ödeme ekranında ek bir alan gösterilmesi gerekiyorsa eklentinin verdiği çerçeve yetmez. İkinci nokta sürüm takibidir: site altyapısı yükseltildiğinde eklenti uyumunun da kontrol edilmesi gerekir.

API’de yol açıktır, yük işletmededir. Burada asıl ayrım kart verisinin nereden geçtiğidir. Ödeme sayfasının altyapı tarafında açıldığı bir kurgu ile kart alanlarının doğrudan sitede göründüğü bir kurgu aynı sorumluluğu taşımaz. Altyapı tarafı PCI-DSS Level 1 kapsamında bağımsız denetimden geçer; kart verisini kendi sunucusuna almayı seçen bir site ise kendi uyum yükünü de üstlenmiş olur.

SDK’nın sınırı ise kapsamdır. Ekibin kullandığı dilde hazır bir paket yoksa veya entegrasyon kütüphanenin öngörmediği bir akış gerektiriyorsa doğrudan API’ye dönmek gerekir. Bu durumda SDK ile başlanıp tek bir adımda API’ye inmek, bütün entegrasyonu baştan yazmaktan daha ucuzdur.

Sandbox ortamı canlıya çıkmadan neyi ucuza öğretir

Sandbox, gerçek kart ve gerçek para hareketi olmadan aynı akışın çalıştırıldığı ayrı bir ortamdır. Buradaki kazanç hızlı kurulum değil, başarısız senaryoların ilk kez müşteri üzerinde denenmemesidir. Başarılı ödeme zaten kolay doğrulanır; kurulumu asıl sınayan durumlar akışın yarıda kaldığı yerlerdir.

• Yarıda kalan doğrulama: müşteri 3D Secure adımını tamamlamazsa siparişin hangi durumda bekleyeceği burada belirlenir.
• Reddedilen işlem: banka onay vermediğinde sitenin gösterdiği mesaj ve o siparişin akıbeti.
• Bildirim doğrulaması: altyapıdan gelen sonuç bildirimi sunucuya ulaşıyor mu, aynı bildirim iki kez geldiğinde sipariş iki kez işleniyor mu. Webhook test araçları bu kontrolü gerçek işlem beklemeden yapmayı sağlar.
• İade ve kısmi iade: işlem geri alındığında sipariş kaydının nasıl güncelleneceği.
• Zaman aşımı ve tekrar deneme: müşteri ödeme sayfasında beklerse veya sayfayı yenilerse ne olacağı.

Bu senaryoların ortak yanı hepsinin canlıda er geç yaşanacak olmasıdır. Sandbox’ta yaşandığında maliyeti bir test kaydıdır. Canlıda yaşandığında karşılığı, ödemesi alınmış ama sistemde açık görünen bir sipariş ya da müşteriye iki kez yansımış bir tutar olur.

Sandbox’ın kapatamadığı bir boşluk da vardır. Banka tarafındaki gerçek onay davranışı ancak gerçek kartla yapılan ilk işlemde görülür. Bu yüzden canlıya geçiş, test ortamının bittiği yer değil, küçük tutarlı gerçek bir işlemle başlayan ikinci aşamadır.

Kurulum sırasında karar verilen noktalar

Aşağıdaki kararlar seçilen teknik yoldan bağımsız olarak verilir. Çoğu sonradan değiştirilebilir, ancak sonradan değiştirmek sipariş kayıtlarında iz bırakır ve eski kayıtlarla yeni kayıtların aynı mantıkla okunmasını zorlaştırır.

1. Ödeme sayfası nerede açılacak: müşterinin site içinde kaldığı bir alan mı, altyapı tarafında açılan ayrı bir sayfa mı. Bu karar aynı zamanda kart verisinin nereden geçtiğini belirler.
2. Sipariş durumunu ne belirleyecek: müşterinin tarayıcısının döndüğü adres mi, sunucuya gelen bildirim mi. Bildirim esas alınmalıdır, çünkü tarayıcı dönüşü müşteri sayfayı kapattığında gerçekleşmez.
3. 3D Secure 2.0 hangi işlemlerde uygulanacak ve doğrulama tamamlanmadığında işlem reddedilecek mi.
4. Kart saklanacak mı: abonelik gibi tekrar eden bir tahsilat planlanıyorsa tokenization devreye girer, planlanmıyorsa kuruluma gereksiz bir katman ekler.
5. Kart türü ve taksit kapsamı sitede nasıl görünecek: kapsamın kendisi bankayla yapılan sanal POS sözleşmesine bağlıdır, kurulumda yapılan iş bu kapsamı ödeme ekranında doğru göstermektir.
6. Para birimi: yurt dışına satış varsa hangi para birimlerinin açılacağı. Altyapı tarafında TRY, USD, EUR ve GBP dahil 20+ para birimi bulunur.
7. İade ve iptal kimin ekranından yürüyecek: panelden mi, site yönetiminden mi. İkisi de mümkünse hangi kaydın esas alınacağı baştan yazılmalıdır.
8. Panele kim erişecek: muhasebe, operasyon ve geliştirici aynı yetki setine ihtiyaç duymaz.

Bu listede en çok atlanan madde ikincisidir. Sipariş durumunu tarayıcı dönüşüne bağlayan bir kurulum sandbox’ta sorunsuz görünür, çünkü test sırasında kimse sayfayı yarıda kapatmaz. Canlıda ise kapatılan her sayfa, ödemesi alınmış ama sipariş listesinde görünmeyen bir kayıt üretir.

Canlıya geçtikten sonraki ilk kontroller

İlk gerçek işlem küçük bir tutarla ve gerçek bir kartla yapılır. Tek bir işlem üç şeyi aynı anda doğrular: akışın uçtan uca çalıştığını, siparişin doğru durumda kapandığını ve tutarın hesaba geçtiğini. Aktarım tarafında beklenen ilk kayıt ertesi iş günü görünür.

Panelde görünen işlem tutarı ile banka hesabına geçen tutar arasındaki fark komisyon kaleminden gelir. İlk mutabakat bu farkı doğrulamak için yapılır ve kurulumun ticari tarafının doğru kurulup kurulmadığını burada anlarsınız.

İkinci kontrol başarısız işlem oranıdır. Altyapı tarafında %99.95 uptime garantisi ve %99.8 ödeme başarı oranı bulunur; buna rağmen sitenizde başarısız işlemler birikiyorsa neden çoğunlukla entegrasyonun kendi tarafındadır. Yanlış tutar biçimi, eksik gönderilen bir parametre veya doğrulama adımında kesilen akış tipik nedenlerdir. 7/24 teknik destek, sorunun banka tarafında mı yoksa sitenin gönderdiği istekte mi olduğunu ayırmak için ilk başvurulacak yerdir.

Kurulum, ödeme yönteminin sitede görünmesiyle bitmiş sayılmaz. Bitiş noktası, ay sonunda sipariş kayıtlarının banka hesabındaki hareketlerle örtüşmesidir. Entegrasyon yolunun hangisi seçilirse seçilsin ölçü budur.