Sanal Pos Entegrasyonu

Sanal POS entegrasyonu, e-ticaret sitelerinin banka veya ödeme kuruluşlarından API üzerinden güvenli ödeme almasını sağlayan teknik süreçtir. Online perakende operasyonlarında kartlı ödemelerin sorunsuz biçimde tahsil edilebilmesi, müşterinin ödeme deneyiminin optimize edilmesi ve finansal verilerin korunması bu entegrasyonun kalitesine doğrudan bağlıdır. Süreç boyunca PCI-DSS ve SSL standartları temeldir ve bu teknik protokollerin eksiksiz biçimde yapılandırılması siber güvenlik risklerini önlemenin en güvenilir yoludur. Altyapının doğru kurgulanması, teknik karar vericiler ve işletme yöneticileri için hem operasyonel verimliliği hem de sepet terk oranlarını doğrudan etkileyen stratejik bir karardır.

Sanal POS Entegrasyonu Temel Kavramları ve Çalışma Mantığı

Sanal POS Nedir ve Geleneksel POS'tan Farkı Nedir?

Sanal POS (Virtual Point of Sale veya vPOS), fiziksel mağazalarda kartın manyetik şerit, çip veya temassız özelliklerini okuyan donanımsal POS terminalinin, internet ortamındaki yazılımsal karşılığıdır. Fiziksel kart kabul terminalleri yüz yüze (Card Present - CP) işlem yaparken, sanal POS sistemleri kartın fiziksel olarak bulunmadığı (Card Not Present - CNP) senaryolarda çalışır. Bu temel fark, güvenlik ve doğrulama süreçlerinde tamamen farklı teknik protokollerin uygulanmasını zorunlu kılar.

Fiziksel POS cihazları üzerinde gerçekleşen işlemlerde şifre girişi ya da biyometrik doğrulama donanım seviyesinde yapılırken, sanal POS altyapılarında bu işlem web tarayıcıları, mobil SDK'ler ve API (Application Programming Interface) katmanları üzerinden yürütülür. Sistem; üye iş yeri (merchant), ödeme ağ geçidi (payment gateway), kart şemaları (Visa, Mastercard, TROY, American Express) ve kartı ihraç eden banka (issuer) arasındaki veri transferini saniyeler içinde koordine etmekle yükümlüdür.

Online ödeme süreçlerinde her işlemin benzersiz bir kimliği (Transaction ID) bulunur. Fiziksel POS'taki gün sonu mutabakatı donanım üzerinden tetiklenirken, sanal POS sistemlerinde bu süreç API uç noktaları (endpoint) üzerinden otomatik ya da zamanlanmış görevler (cron jobs) vasıtasıyla yürütülür. Kart bilgilerinin güvenli iletimi ve doğrulanması için kullanılan her yazılımsal katman, geleneksel POS cihazlarının sunduğu basit veri iletim modelinden çok daha karmaşık bir şifreleme ve doğrulama mekanizmasına dayanır.

API ve 3D Secure Teknolojileri Nasıl Çalışır?

API entegrasyonu, e-ticaret platformunun veritabanı ile ödeme kuruluşunun ya da bankanın sunucuları arasında gerçek zamanlı ve iki yönlü bir veri köprüsü kurar. Müşteri ödeme formuna kart bilgilerini girdiğinde, bu veriler tarayıcı tarafında (client-side) doğrudan şifrelenerek veya sunucu tarafında (server-side) güvenli API istekleri (HTTP POST) halinde ödeme ağ geçidine iletilir. Modern altyapılarda RESTful mimari ve JSON veri formatı standart olarak benimsenmiştir. Bu süreçte üye iş yerinin güvenliğini doğrulamak amacıyla her API isteği, SHA-256 veya SHA-512 gibi algoritmalarla oluşturulan benzersiz bir imza (signature/hash) ve API anahtarı (API Key) çiftini barındırır.

3D Secure (Üç Boyutlu Güvenlik), kart hamili, üye iş yeri ve kartı çıkaran banka arasındaki kimlik doğrulama sürecini üç ayrı alanda (domain) yöneten bir protokoldür. 3D Secure 2.0 (ve güncel 2.2 / 2.3 sürümleri), eski sürümlerin aksine kullanıcı deneyimini kesintiye uğratmayan "Risk Tabanlı Kimlik Doğrulama" (Risk-Based Authentication) mekanizmasına sahiptir. Bu teknoloji sayesinde, müşterinin cihaz bilgisi, IP adresi, işlem geçmişi ve konum verileri gibi yüzden fazla veri noktası arka planda analiz edilir.

İşlem düşük riskli bulunursa "Sürtünmesiz Akış" (Frictionless Flow) tetiklenir ve müşteri tek kullanımlık şifre (OTP) girmeden ödemeyi tamamlar. Yüksek riskli işlemlerde ise "Mücadele Akışı" (Challenge Flow) devreye girerek müşteriyi bankanın doğrulama ekranına (SMS, mobil bankacılık onayı veya biyometrik veri girişi) yönlendirir. Bu iki yönlü mimari, hem sepet terk oranlarını düşürür hem de ters ibraz (chargeback) maliyetlerine karşı üye iş yerine yasal koruma sağlar.

E-Ticaret Siteleri İçin Sanal POS Entegrasyon Süreci Adımları

Banka veya Ödeme Kuruluşu Seçimi ve Başvuru Kriterleri

Sanal POS entegrasyonuna başlarken karar verilmesi gereken ilk adım, doğrudan ticari bankalarla mı (Single/Multi-Bank POS) yoksa Türkiye Cumhuriyet Merkez Bankası (TCMB) lisanslı ödeme kuruluşlarıyla mı (Payment Service Provider - PSP) çalışılacağıdır. Doğrudan banka entegrasyonları, her bankanın kendi API yapısını ayrı ayrı kodlamayı gerektirdiği için yüksek teknik bakım maliyeti yaratır; ancak yüksek işlem hacmine ulaşmış büyük ölçekli e-ticaret operasyonlarında daha düşük komisyon oranları sunabilir. Ödeme kuruluşları ise tek bir API entegrasyonu ile tüm yaygın kart şemalarına (Visa, Mastercard, TROY, AMEX) ve bankaların taksit programlarına erişim imkanı tanır.

Sağlayıcı seçiminde değerlendirilmesi gereken temel operasyonel kriterler şunlardır:

• Desteklenen Taksit Programları: Türkiye pazarındaki yaygın bonus, maximum, world, axess, cardfinans, paraf gibi kart programlarına taksit yapabilme yetkinliği.

• TROY Kart Desteği: Yerel pazarın önemli bir bölümünü oluşturan ulusal kart şemasının sorunsuz işlenmesi.

• Nakit Akışı (Valör) Süresi: Tahsil edilen tutarların üye iş yeri banka hesabına aktarılma süresi (ertesi gün ödeme, 7 gün, 14 gün veya 30 gün blokeli çalışma modelleri).

• Uluslararası Ödeme ve Döviz Çeşitliliği: Çoklu para birimiyle (USD, EUR, GBP) tahsilat ve yurt dışı kartları kabul etme oranı.

• Teknik Dokümantasyon ve SDK Kalitesi: Yazılım ekibinin entegrasyonu hızla tamamlamasını sağlayacak güncel yazılım geliştirme kitlerinin (SDK) ve API referanslarının varlığı.

Yasal belgelerin yanı sıra, başvuru yapılan web sitesinin de yasal ve operasyonel olarak hazır olması gerekir. Eksik hukuki metinlere sahip e-ticaret sitelerinin başvuruları doğrudan reddedilir. Sitede bulunması zorunlu olan sayfalar ve teknik bileşenler şunlardır:

• Mesafeli Satış Sözleşmesi (MSS): Her satın alma adımında müşteriye onaylatılması zorunlu yasal metin.

• Ön Bilgilendirme Formu: Satış öncesinde tüketicinin bilgilendirilmesini sağlayan belge.

• İptal ve İade Koşulları: Tüketici Kanunu'na uygun cayma hakkı ve iade süreçlerini açıklayan bilgilendirme sayfası.

• Gizlilik Sözleşmesi ve KVKK Politikası: Kullanıcı verilerinin nasıl işleneceğini ve korunacağını açıklayan aydınlatma metni.

• İletişim ve Şirket Bilgileri: Şirketin unvanı, adresi, Mersis numarası ve aktif iletişim kanalları sitenin alt bilgi (footer) alanında açıkça yer almalıdır.

Teknik Entegrasyon ve API Bilgilerinin Alınması

Başvurunun onaylanmasının ardından sağlayıcı, geliştirici paneli üzerinden üye iş yerine özel API kimlik bilgilerini (API Credentials) iletir. Bu bilgiler genellikle şunlardan oluşur:

• Merchant ID (Üye İşyeri Numarası): İşletmeyi sistemde benzersiz şekilde tanımlayan kod.

• API Key (Uygulama Anahtarı): API çağrılarında kimlik doğrulamak için kullanılan genel anahtar.

• API Secret / Salt Key (Gizli Anahtar): İsteklerin bütünlüğünü doğrulamak ve imza (hash) oluşturmak için kullanılan, asla istemci tarafında (JavaScript) paylaşılmaması gereken gizli anahtar.

Teknik entegrasyon iki farklı modelde gerçekleştirilebilir:

1. Ortak Ödeme Sayfası (Hosted Payment Page): Kart verilerinin güvenliği tamamen ödeme kuruluşu sunucularında işlenir. Müşteri ödeme adımında sağlayıcının sayfasına yönlendirilir veya sayfa içine gömülü bir iframe ekranı üzerinden kart bilgilerini girer. Geliştirici tarafında PCI-DSS uyumluluk yükümlülüğünü en aza indiren en güvenli ve hızlı yöntemdir.

2. Doğrudan API Entegrasyonu (API-Direct / Custom Form): Kart bilgileri doğrudan e-ticaret sitesinin kendi tasarladığı arayüzde toplanır. PHP, Node.js, Python veya .NET gibi sunucu tarafı teknolojileriyle arka planda ödeme sağlayıcısının API'sine gönderilir. Bu yöntemde kart verileri üye iş yeri sunucularına uğradığı için en yüksek düzeyde siber güvenlik önlemleri ve PCI-DSS SAQ-A-EP veya SAQ-D sertifikasyonu gereklidir.

Sandbox Testleri ve Canlı Ortama Geçiş

Yazılım geliştirme aşamasında entegrasyonun doğruluğunu kontrol etmek amacıyla mutlaka "Sandbox" veya "Test" ortamı kullanılmalıdır. Bu ortam, gerçek finansal işlem yapmadan, tamamen sanal bakiyeler ve test kartlarıyla API'nin nasıl yanıt verdiğini simüle etmeye yarar. Sağlayıcılar geliştiricilere başarılı ödeme, limit yetersizliği, yanlış CVV girişi, süresi geçmiş kart ve 3D Secure hata kodları gibi farklı senaryoları tetikleyebilecek özel test kartı numaraları sunar.

Entegrasyon kodunun hata yönetimi (Error Handling) katmanı bu aşamada test edilmelidir. Örneğin, bankadan dönecek olan hata kodlarının (ISO 8583 standartlarındaki @@CODE0@@ - limit yetersiz, @@CODE1@@ - vade tarihi geçmiş kart, 05 - onaylanmadı vb.) kullanıcıya dostane ve yönlendirici hata mesajları olarak gösterilmesi sağlanmalıdır. Testlerin başarıyla tamamlanmasının ardından API uç noktası (endpoint URL) test adresinden canlı (production) adrese çevrilir, test anahtarları canlı anahtarlarla değiştirilir ve sembolik bir tutarla (örneğin 1 TL) ilk gerçek kart işlemi yapılarak sistemin çalıştığı doğrulanır.

Sanal POS Entegrasyonunda Güvenlik ve Uyumluluk Standartları

PCI-DSS Standartlarının E-Ticaret İçin Kritik Önemi

Payment Card Industry Data Security Standard (PCI-DSS), kredi kartı bilgilerinin işlenmesi, iletilmesi ve saklanması süreçlerinde güvenliği sağlamak amacıyla Visa, Mastercard ve diğer büyük kart şemaları tarafından oluşturulmuş küresel bir veri güvenliği standardıdır. E-ticaret sitelerinin işlem hacimlerine ve kart verilerine dokunma düzeylerine göre farklı PCI-DSS uyumluluk seviyeleri (Level 1-4) ve Öz Değerlendirme Formları (Self-Assessment Questionnaire - SAQ) bulunur.

• SAQ-A: Ödeme sayfasının tamamen dış sunucuda (hosted payment page) veya iframe içinde barındırıldığı modeldir. Kart bilgileri hiçbir şekilde üye iş yerinin sunucularına temas etmez. Küçük ve orta ölçekli e-ticaret siteleri için en düşük siber güvenlik yükümlülüğünü getirir.

• SAQ-A-EP: Kart bilgileri üye iş yerinin sitesindeki form alanına girilir ancak tarayıcı üzerinden doğrudan ödeme sağlayıcısının sunucularına post edilir. Kodun güvenliği ve manipüle edilmemesi üye iş yerinin sorumluluğundadır.

• SAQ-D: Kart verilerinin doğrudan üye iş yerinin kendi veritabanında saklandığı veya sunucularından geçerek işlendiği en riskli modeldir. Çok sıkı siber güvenlik denetimleri, sızma testleri (penetration tests) ve altyapı sertifikasyonu gerektirir.

Ödeme kartı verilerinin ham (raw) biçimde veritabanında saklanması kesinlikle yasaktır. Bu kuralın ihlali, büyük finansal cezalara ve kart kabul yetkisinin iptal edilmesine yol açar. Bilgilerin sonraki alışverişlerde kullanılmak üzere saklanması gerekiyorsa, bu işlem ancak PCI-DSS sertifikalı ödeme kuruluşlarının sunduğu "Kart Saklama / Tokenizasyon" (Card Tokenization) API'leri üzerinden yapılmalıdır. Bu modelde kart verisi karşılığında üretilen rastgele bir belirteç (token) veritabanında tutulur ve sonraki işlemlerde bu güvenli token kullanılır.

SSL Sertifikası ve Veri Şifreleme Protokolleri

Sanal POS entegrasyonu yapılan bir web sitesinde SSL/TLS (Secure Sockets Layer / Transport Layer Security) protokolünün aktif olması teknik olarak zorunludur. SSL/TLS, kullanıcının web tarayıcısı ile e-ticaret sunucusu arasındaki veri trafiğini asimetrik şifreleme algoritmalarıyla koruyarak "ortadaki adam" (Man-in-the-Middle - MitM) saldırılarını engeller.

Modern tarayıcı standartları ve ödeme ağ geçidi API'leri, güvenli olmayan HTTP protokolü üzerinden gelen ödeme isteklerini doğrudan reddeder. Entegrasyonun sorunsuz çalışabilmesi için:

• Sitede en az 256-bit şifreleme derinliğine sahip, SHA-256 imzalı geçerli bir SSL sertifikası bulunmalıdır.

• Güvenli olmayan TLS 1.0 ve TLS 1.1 protokolleri sunucu seviyesinde tamamen devre dışı bırakılmalı, siber güvenlik standartlarına uygun olarak en az TLS 1.2 veya modern TLS 1.3 kullanımı zorunlu tutulmalıdır.

• HSTS (HTTP Strict Transport Security) başlığı (header) etkinleştirilerek, sitenin her koşulda yalnızca HTTPS üzerinden yüklenmesi sağlanmalıdır.

Dolandırıcılık (Fraud) Önleme ve Risk Yönetimi

Online işlemlerde fiziksel kart kontrolü yapılamadığından, işletmeler dolandırıcılık (fraud) riskine karşı aktif savunma mekanizmaları kurmalıdır. Çalıntı kartlarla yapılan alışverişler sonrasında gerçek kart sahibinin yaptığı ters ibraz (chargeback) başvuruları, hem doğrudan finansal kayba hem de ödeme kuruluşları nezdinde üye iş yeri sicilinin bozulmasına neden olur.

Etkin bir dolandırıcılık önleme stratejisi şu teknik filtreleri içermelidir:

• Hız Limitleri (Velocity Checks): Aynı IP adresinden, aynı kullanıcı hesabından veya aynı kart numarasından çok kısa süre içinde ardışık denemelerin yapılmasının engellenmesi. Bu filtre, otomatik kart deneme yazılımlarının (card testing bots) önüne geçer.

• BIN Kontrolü ve Coğrafi Eşleştirme: Kartın ilk 6 ya da 8 hanesinden (BIN - Bank Identification Number) elde edilen ihraççı ülke bilgisi ile kullanıcının IP adresi veya teslimat adresinin uyumluluğunun kontrol edilmesi.

• Yapay Zeka Destekli Risk Skorlaması: Ödeme kuruluşlarının sunduğu makine öğrenimi modellerinin entegre edilerek, şüpheli alışveriş desenlerinin (örneğin gece yarısı yapılan olağan dışı büyük sepet tutarları) otomatik olarak durdurulması veya 3D Secure doğrulamasına zorlanması.

Sanal POS Maliyetleri, Komisyon Oranları ve Kesintiler

Blokeli ve Blokesiz Çalışma Modelleri

Sanal POS entegrasyonu tamamlandıktan sonra işletmenin nakit akışını ve işletme sermayesi döngüsünü belirleyen en kritik parametre, ödeme sağlayıcı ile anlaşılan tahsilat modelidir. Finansal ekosistemde bu durum temel olarak iki farklı işleyişe ayrılır:

1. Blokeli (Valörlü) Çalışma Modeli: Bu modelde, yapılan satışların tutarı hemen değil, önceden belirlenmiş bir süre boyunca (örneğin 14, 21, 30 veya 45 gün) bankanın veya ödeme kuruluşunun havuz hesabında bloke edilir. Bloke süresi dolduğunda para üye iş yerinin hesabına aktarılır. Bu modelin en büyük avantajı, paranın sistemde kalması karşılığında komisyon oranlarının son derece düşük tutulması, hatta bazı durumlarda sıfıra yakın olmasıdır. Yüksek kar marjıyla çalışan ancak işletme sermayesi ihtiyacı düşük olan firmalar için uygundur.

2. Blokesiz (Ertesi Gün Ödeme - T+1) Çalışma Modeli: Satıştan elde edilen ciro, işlem gününün hemen ertesi iş gününde (hafta sonu ve resmi tatil günleri hariç tutularak) komisyon oranı kesildikten sonra net tutar olarak üye iş yerinin hesabına yatırılır. Bu modelde komisyon oranları, paranın erken çekilmesi maliyetine bağlı olarak daha yüksektir. Ancak hızlı stok devir hızına sahip, kar marjı düşük fakat sürekli nakit akışına ihtiyaç duyan perakende işletmeleri için bu model operasyonel devamlılık açısından tercih edilir.

Komisyon Oranlarını Etkileyen Faktörler

Sanal POS sağlayıcıları tarafından uygulanan komisyon oranları standart veya sabit olmayıp, işletmenin işlem hacmine ve işlem karakteristiğine göre dinamik olarak ölçeklendirilir. Komisyon yapısını doğrudan etkileyen faktörler şunlardır:

• İşlem Hacmi (Ciro): Aylık veya yıllık toplam işlem hacmi arttıkça, ödeme kuruluşlarının üye iş yerlerine sunduğu komisyon oranları ters orantılı olarak düşer. Yüksek hacimli e-ticaret siteleri, özel pazarlıklar (custom pricing) yoluyla çok daha avantajlı finansal şartlar elde edebilir.

• Kart Türü (Debit / Credit): Müşterinin alışveriş yaparken kullandığı kartın türü komisyonu doğrudan etkiler. Banka kartları (debit) ve ön ödemeli kartlar üzerinden yapılan tahsilatların komisyon oranları, kredi kartlarına kıyasla çok daha düşüktür. Ayrıca yurt dışı bankalara ait kartların (international cards) komisyonları, yerel kartlara göre her zaman daha yüksek seviyededir.

• Taksitli İşlemler ve Vade Farkı: Taksitli satışlarda, bankanın uyguladığı fonlama maliyetine bağlı olarak komisyon oranı artar. Bu aşamada işletme, taksit maliyetini (vade farkı) doğrudan kendisi üstlenebilir veya bunu API üzerinden sepete yansıtarak müşteriye ödetebilir.

• Sabit ve Gizli Giderler: Komisyon oranlarının yanı sıra, kurulum ücretleri, yıllık üyelik/bakım bedelleri, işlem başına kesilen sabit ücretler (örneğin başarılı işlem başına 0.25 TL ila 1.50 TL arası) ve başarısız sorgulardan alınan teknik işlem ücretleri de toplam maliyet analizine dahil edilmelidir.

Alternatif Ödeme Yöntemleri Entegrasyon Çözümleri

Tek Tek Banka Entegrasyonu vs. Ödeme Geçitleri (Payment Gateway)

E-ticaret sitelerinde sanal POS altyapısı kurarken karşılaşılan en büyük mimari ikilem, her bankanın kendi sanal POS'unu doğrudan entegre etmek ile tüm bankaları tek bir çatı altında sunan lisanslı bir ödeme ağ geçidi (PSP) kullanmak arasındadır. Bu iki yaklaşımın teknik, operasyonel ve finansal süreçler üzerinde kendine has dengeleri mevcuttur.

Doğrudan banka entegrasyonları, her bankanın (örneğin Garanti BBVA, İş Bankası, Akbank) sunduğu API standartlarının (Nestpay, Posnet, Est3D vb.) ayrı ayrı kodlanmasını ve bakımını gerektirir. Bankaların API protokollerinde yapacağı güncellemeler, güvenlik sertifikası değişiklikleri veya altyapı kesintileri doğrudan yazılım ekibinizin müdahale etmesini zorunlu kılar. Bu durum ciddi bir teknik borç (technical debt) ve bakım maliyeti oluşturur. Finansal tarafta ise her banka ile ayrı ayrı komisyon pazarlığı yapılması ve her bankanın hesabının ayrı ayrı muhasebeleştirilmesi gerekir.

Ödeme geçitleri (Payment Gateways) ise bu karmaşıklığı tek bir API katmanı arkasında soyutlar. Yazılımcınız yalnızca tek bir entegrasyon şeması hazırlar; arka planda sistem, kartın hangi bankaya ait olduğunu BIN sorgusu üzerinden tespit ederek işlemi en uygun bankanın POS'una yönlendirir (Smart Routing - Akıllı Yönlendirme). Akıllı yönlendirme teknolojisi, bir bankanın altyapısında kesinti olduğunda işlemi anında alternatif bir banka POS'una aktararak sepet kaybını önler ve operasyonel kesintisizliği en üst düzeye çıkarır.

Alternatif Ödeme Yöntemlerinin Altyapıya Dahil Edilmesi

Modern e-ticaret tüketicileri, geleneksel kredi kartlarının ötesinde farklı finansal teknolojileri ve ödeme yöntemlerini kullanma eğilimindedir. Sepet terk oranlarını düşürmek ve dönüşüm oranlarını (conversion rate) optimize etmek için ödeme sayfasına alternatif kanalların entegre edilmesi kritik bir rol oynar.

Bu yöntemler arasında öne çıkanlar şunlardır:

• Dijital Cüzdanlar: Papara, BKM Express, GarantiPay gibi kullanıcının kart bilgilerini tekrar girmesine gerek kalmadan, yalnızca şifre veya biyometrik onay ile saniyeler içinde ödeme yapmasını sağlayan sistemler.

• Alışveriş Kredileri (E-Ticaret Kredisi): Özellikle sepet tutarının yüksek olduğu (elektronik, mobilya vb.) sektörlerde, bankaların sunduğu anında dijital tüketici kredisi altyapılarının (Fibabanka Alışveriş Kredisi, Akbank Direkt Öde vb.) API üzerinden ödeme sayfasına entegre edilmesi.

• Şimdi Al Sonra Öde (Buy Now Pay Later - BNPL): Tüketicinin ürünü hemen teslim almasını, ödemeyi ise belirli taksitlerle veya ertelenmiş olarak yapmasını sağlayan, finansal riski ödeme sağlayıcısının üstlendiği yeni nesil ödeme modelleri.

Sanal POS Yönetimi ve Operasyonel Süreçlerin Optimizasyonu

İade ve İptal İşlemlerinin API Üzerinden Otomasyonu

Müşteri memnuniyetini sağlamak ve arka ofis operasyonlarının yükünü hafifletmek için e-ticaret yönetim paneli ile sanal POS altyapısının iade ve iptal mekanizmaları entegre çalışmalıdır. Bu iki işlem teknik olarak farklı finansal durumlara karşılık gelir:

• İptal (Void): Satış işleminin yapıldığı gün, bankanın gün sonu mutabakatı (batch closure) gerçekleşmeden önce yapılan işlemdir. İptal durumunda finansal transfer henüz kesinleşmediği için karttaki provizyon (bloke) kaldırılır. Kart limitine anında yansır ve kart hamilinin ekstresine borç-alacak kaydı girmez.

• İade (Refund): Gün sonu mutabakatı tamamlandıktan sonra yapılan işlemler için geçerlidir. Para transferi gerçekleştiği için süreç bankalararası takas sistemi üzerinden yürütülür. İade işlemi kart hamilinin hesabına bankanın işlem hızına bağlı olarak birkaç iş günü içerisinde yansır.

Geliştiricilerin, ödeme sağlayıcısının @@CODE0@@ ve @@CODE1@@ API uç noktalarını kendi e-ticaret yönetim panellerine entegre etmesi gerekir. Bu sayede müşteri temsilcileri, ödeme kuruluşu paneline ayrıca giriş yapmaya gerek kalmadan, doğrudan sitenin yönetim panelinden tek tuşla kısmi veya tam iade işlemlerini başlatabilir. Kısmi iade (partial refund) yeteneği, birden fazla ürün içeren siparişlerde yalnızca iade edilen tek bir ürünün tutarının geri ödenmesini sağlayarak finansal doğruluğu güvence altına alır.

Gün Sonu Mutabakatı ve Raporlama Entegrasyonu

E-ticaret işletmelerinin muhasebe ve finans departmanları için en zahmetli süreçlerden biri, banka hesaplarına gelen para transferleri ile sipariş kayıtlarının eşleştirilmesidir (reconciliation). Sanal POS entegrasyonunda mutabakat süreçlerinin otomatize edilmemesi, manuel hatalara ve finansal farkların tespit edilememesine neden olur.

Bu süreci optimize etmek için şu teknik yaklaşımlar uygulanmalıdır:

• MT940 Hesap Ekstresi Entegrasyonu: Bankalardan gelen günlük MT940 formatındaki elektronik hesap ekstrelerinin, işletmenin ERP (Logo, SAP, Nebim vb.) sistemine otomatik aktarılarak sipariş numaraları (Merchant Order ID) üzerinden otomatik eşleştirilmesi.

• Raporlama API’lerinin Kullanımı: Ödeme sağlayıcılarının sunduğu mutabakat API'leri yardımıyla, her günün sonunda başarılı işlemlerin, komisyon kesintilerinin ve net ödeme tutarlarının otomatik olarak sorgulanması.

• Ödeme Bildirimleri (Webhooks / IPN): İşlem durumundaki değişiklikleri (örneğin şüpheli işlem onayları, sonradan yapılan ters ibrazlar) anında bildiren Webhook mekanizmalarının kurulması, finansal tabloların her zaman güncel kalmasını sağlar.