Sanal POS Ödeme Modelleri: 3D Secure, 3D Pay, 3D Host, Non Secure

5 min readApr 30, 2024

Günümüzde bankalar birkaç tane ödeme yöntemleri sunulmaktadır. Bu makalede bu ödeme modellerin farklarını anlamamız açısından detaylarına gireceğiz.

Öncelikle kullanacağım bazı terimleri açıklayarak başlayayım:

Gateway — payment Gateway yani sanal POS API’yı

Provizyon — para çekim işlemi

Müşteri — kredi kart sahibi / alışverişi yapan kişi

Bu alttakilerle bitmeyen ancak en popüler ödeme modeller:

3D Secure
3D Pay
3D Host
Non Secure

Bankalar aynı isimlendirmeyi kullanmasalar da altında çalışan mekanizma aynıdır.

Örnek olarak bankalar bu alttaki isimleri kullanırlar:

3D Secure — 3D Model
3D Host — 3D Hosting, 3D OOS (Ortak Ödeme Sayfası), 3D Güvenli Ödeme Sayfası
Non Secure — Non 3D Secure, Non 3D Model, Standart Satış

Mağazaların bankalardan sanal POS hizmeti isterken ne tür bir ödeme sağlamak istedikleri belirtmeleri gerekiyor. İhtiyaca göre bu yukarıdaki ödeme modellerden biri ya da birkaçı aktif edilir.

Karşılaştırma

Aşağıda sağladığım diyagramlarda her adımı numaralandırmadım, sanal POS entegrasyonu yapacak geliştiriciler sadece numaralandırdığım adımlar için geliştirme yapması gerekir.

3D Secure Model

En yaygın kullanılan ödeme yöntemidir. Kart sahipleri 3D şifresi kullanarak kimlik doğrulamasından sonra provizyon işlemi gerçekleştirilir.

Özet olarak işlem akışı şu şekildedir:

Müşteriden kredi kart bilgileri alınır.
Kredi kart, sipariş bilgileri ve sanal POS API hesap bilgilerini kullanarak form verisi oluşturulur.
HTML form verisini bankanın verdiği URLa POST ederek müşteri banka sayfasına yönlendirilir.
Müşteri 3D kimlik doğrulama aşamasından sonra geri e-ticaret web siteye yönlendirilir.
3D kimlik doğrulama başarılı ise provizyon işlemi gerçekleştirilir.

Detaylı diyagram şu şekildedir:

Diyagramdaki numaralandırılan adımların detayına gelince:

3. ve 4. adımlar birkaç sanal POS gateway’lerde bu istek yapılır ve farklı amaçlar için kullanılmaktadır. Sonuç olarak 4. adımda gelen verileri, POST edilecek HTML form verisine dahil etmemiz gerekiyor.
5. adımda
1. Form verisi oluştururken kredi kart bilgileri, sipariş bilgileri (ya da 4. adımda bankadan gelen veriler) kullanılır.
2. Ayrıca bankaya isteğin gerçekten bizden geldiğini kanıtlamak için bankanın verdiği gizli şifreyle bir HASH verisini hesaplayıp form verisine eklenir.
3. Oluşturulan form verilerini HTML forma type=hidden olarak basılır.
4. Bankanın verdiği 3D Gate URL HTML formun action’i olarak kullanılır.
5. Formu JS ile otomatik submit yaparak müşteri 3D Gate’e yönlendirilir.
bu formda ayrıca success URL ve fail URL bilgileri yer alır. Müşteri 3D kimlik doğrulama işlemi bittiğinde duruma göre müşteri success veya fail URL’a, yani e-ticaret web sitesine geri yönlendirilir. Bazı gatewaylerse 2 ayrı (fail/success) URL kullanmak yerine tek URL kullanırlar. Örnek form yapısı:

<form method="POST"
action="https://virtualpospaymentgatewaypre.akbank.com/securepay"
name="redirect-form"
>
    <input type="hidden" name="paymentModel" value="3D">
    <input type="hidden" name="okUrl" value="https://example.com/success.php">
    <input type="hidden" name="failUrl" value="https://example.com/fail.php">
    <!-- kredi kart ve sipariş verileri -->
</form>
<script>
    setTimeout(function () {
        document.forms['redirect-form'].submit();
    }, 1000);
</script>

7. adımda müşteri success/fail URL’a yönlendirilirme ile beraber banka tarafından POST ile (bazı gateway’lerde GET ile cevap dönülür, Kuveyt Türk BOA gateway’de ise HTML form dönülür) kimlik doğrulama sonucu dönülür. Gelen verilerdeki alanları kontrol edilerek kimlik doğrulama işlemin başarılı olup olmadığı kontrol edilir. Çoğu gatewaylerde kimlik doğrulama sonucu için md değeri yer alır.
- Eğer md = 1 ise kimlik doğrulama başarılı.
- Eğer md 2, 3, 4 değerlerden biri ise kart sahibi 3D işlemlere izin vermemiş olabilir. Bu durum Half 3D olarak adlandırılır, banka işlem yapılan kart sahibini doğrulayamıyor demektir. Duruma göre md 2, 3, 4 durumlarda da provizyon işlemi yapılabilir.
- Diğer md değerlerde kimlik doğrulama işlemi başarısız sayılır.
8. adımda güvenlik amaçlı bankadan gelen response’daki (POST verilerdeki) hash değeri kontrol edilir. Response verileri bankanın verdiği gizli şifreyle hashlenir, hesaplanan hash ile response’daki hash eşit ise veriler bankadan geldiği kanaatine varılır. Bu adım zorunlu olmamakla beraber her gateway’lerde bu kontrol istenmiyor.
9. adımda provizyon işlemi gerçekleştirilir. 3D Secure ödemenin 3D Pay’den farkı kimlik doğrulama işleminden sonra bu provizyon isteğinin e-ticaret web sitesi tarafından yapılmasıdır. Provizyon isteği yapılmadan ödeme tamamlanmaz. Provizyon isteğinde kredi kart bilgileri genelde kullanılmazken bazı gateway’ler bu aşamada da kart bilgileri ister.
11. adımda ise provizyon işlemin başarılı başarısız olma durumuna göre müşteriye dönüş yapılır.

3D Pay Model

3D Pay’in 3D secure ödeme modelinden tek farkı provizyon işlemin sanal POS müşterisi (merchant) tarafından değil de Sanal POS hizmeti sağlayan banka tarafından yapılmasıdır. Oluşturulan HTML form verisi 3D Secure modele göre azcık da olsa fark edebilir.

Detaylı diyagram şu şekildedir:

3D Host Model

3D Host ödeme modelde müşteri kredi kart bilgisi sanal POS müşterisi tarafından değil de, bankanın sağladığı web arayüzü tarafından alınır. Provizyon işlemi de 3D Pay’de olduğu gibi banka tarafından yapılır. Oluşturulan HTML form verisinde diğer 3D modellerden farklı olarak kredi kartı bilgileri yer almaz.

Non Secure Model

Müşteri 3D şifresi girmeden, yani kimlik doğrulaması yapmadan, yapılan ödeme yöntemi.

İşlem akışı oldukça basit:

Sanal POS API çeşitleri

Bazı bankalar özel geliştirdiği sanal POS uygulamasını sunarken, diğerleri Payten gibi third party sanal POS çözümleri kullanmaktadır.

Örneğin hazır olarak web siteye Payten entegrasyonu yapılmışken, Payten’i destekleyen başka bir bankanın sanal POS’una geçiş yapmak istendiğinde, kod değişikliği gerektirmeden, sadece API bilgileri değiştirilmesi yeterli oluyor.

Bir takım bankalar ise aynı anda birden fazla sanal POS API çeşidi üzerinden hizmet vermektedir.

Bazı durumlarda ise bankalar third party sanal POS sistemi kullanmasına rağmen sanal POS’larını özel bir isimle sunar.

Peki hangi ödeme modeli kullanmalısınız?

İlk önce sanal POS hizmeti veren bankanın hangi ödeme yöntemi desteklediğini öğrenmeniz gerekiyor. Desteklenen ödeme modelleri gateway’den gateway’e değişir.

3D kimlik doğrulama olsun ama en az geliştirme istiyorsanız 3D Host’u tercih etmeniz gerekiyor.
3D Pay ile 3D Secure arasındaki fark 3D Secure’de ekstra provizyon isteğin yapılması; yani, ekstra geliştirme/kod gerektirmesidir.
3D Pay ve 3D Host’ta “Secure” kelimesi geçmese de güvenlik açıdan bu 3 3D modeller arasında bir fark yoktur.

Peki 3D ödeme çeşitleri varken neden Non Secure ödemeye ihtiyacımız var?

Örneğin hepsiburada.com kredi kartı kaydet seçeneği verir. Kredi kartınızı kaydettikten sonra bir sonraki alışverişte 3D kimlik doğrulaması yapmadan daha kolay ödeme yapılabilir.
Telefon hattınıza müşteri hizmetlerini arayarak para yüklemek istediğinizde telefon üzerinden kart bilgilerinizi vererek bakiye yüklemesi yapabilirsiniz.
Ön otorizasyon kapama işleminde zorunlu olarak Non Secure model kullanılır. Ön otorizasyon kapama işleminden önce ön otorizasyon işlemi yapılır. Örneğin araba kiraladığınızda mağaza kredi kartınızdan para çekmek yerine belli bir miktarı bloke etmek isteyebilir. Bu bloke işlemi ön otorizasyon işlemi ile yapılır. Ön otorizasyon işlemi 3D ödeme modelleri veya Non Secure ödeme modeli ile gerçekleştirilirken, ön otorizasyon kapama işlemi (bloke edilen tutarın çekim işlemi) kart sahibi olmadan Non Secure model ile yapılır. Aynı şekilde blokeyi kaldırmak için de Non Secure model kullanılır.

Sonuç

Diyagramlarda paylaştığım işlem akışları gateway’ler arası aynı olsa da yapılan isteklerin yapısı çok değişkendir.

Bazıları iletişim için XML kullanır, diğerleri JSON kullanır.
HASH algoritmaları ve HASH hesaplamada kullanılan veriler farklı olur.
Gönderilen verilerin formatı farklı olur:
- örneğin 10TL çekim için miktar formatı birinde 10.0 diğerinde ise 1000 olması gerekiyor.
- TL para birimi için biri 949 isterken diğeri 0949 veya TL ister ve vs.
Bankadan dönen veriler de farklılık gösterir, bu da bankada gelen cevabı yorumlamayı zorlaştırır.

Gateway’ler arası yukarıda saydığım farklılıklardan dolayı, işlem akışı aynı olmasına rağmen, bir gateway’den diğerine geçiş yapmak oldukça zordur.