SSL Olmadan Sanal POS Kullanımı – 5 Kesin Çözüm

Öne Çıkanlar

• SSL, sanal POS için zorunludur: bazı geçici testler mümkün olsa da canlı ödemelerde hem güvenlik hem de mevzuat gereği gerekli.
• Bankalar ve PCI‑DSS standartları kart bilgilerinin şifrelenmesini talep eder; HTTP/SSL eksikliği callback ve 3D testlerini engeller.
• Performans: SSL tek başına yeterli değil — CPU/RAM/IO, doğru cache ve indekslenmiş sorgular ödeme anında kritik rol oynar.
• Güvenlik ve ağ: 443 dışındaki açık portlar, yanlış firewall/DNS ayarları ve callback hataları ödemelerin görünmesini engeller.
• Yayına alma sırası önemlidir: önce alan adı ve SSL, sonra sanal POS kurulumu ve son olarak kapsamlı testler.

SSL Olmadan Sanal POS Çalışır mı? Hakkında Bilmeniz Gerekenler

Şöyle düşünün: Sanal POS, müşterinin kredi kartından para çekmek için banka ile sizin siteniz arasında kurulan bir köprü. SSL ise bu köprünün üstüne çekilen koruyucu tünel. Tünel yoksa, köprü hala orada durur; ama üzerinden geçen herkes dışarıya açıktır. Kart numarası, CVV, son kullanım tarihi… Hepsi ağ üzerinde düz metin olarak dolaşır.

Bankalar ve ödeme kuruluşları, PCI‑DSS denen uluslararası bir güvenlik standardına uymak zorunda. Bu standart da çok net: Kart bilgileri şifrelenmeden taşınamaz. Yani “Tarayıcı – Siteniz – Banka” hattında SSL zorunluluğu fiilen bir kural. Çoğu banka, sanal POS başvurusunda açıkça “Geçerli SSL sertifikası” ister. Hatta bazıları, sitenizi manuel ziyaret edip https olup olmadığını ve form sayfasında SSL zorunluluğu kullanıp kullanmadığınızı kontrol eder.

Piyasada sık duyduğum bir efsane var: “Ödeme sayfasını bankanın 3D Secure sayfasına yönlendiriyorum, benim sitede SSL olmasa da olur.” Aslında durum tam olarak şöyle: Sadece bankanın hosted (barındırılan) ödeme sayfasını kullanıyorsanız teknik olarak kart girişi bankanın alan adında olur ve SSL onlarda zorunludur. Ama siz sepetten o sayfaya veri gönderirken, müşteri oturumu yönetirken, callback / bildirim URL’leriyle işlem durumunu işlerken yine SSL’e ihtiyaç duyarsınız. Aksi halde hem güvenlik açığı hem de tarayıcı “Güvenli değil” uyarılarıyla terk oranlarınız tavan yapar.

Özetle: “Bir şekilde çalıştırırım” evet, “sağlıklı, güvenli ve banka uyumlu çalıştırırım” hayır. İşin püf noktası burada.

Yapılandırma ve Yönetim: Adım Adım

Kaynak Yönetimi – Limitleri Zorlamayın

SSL ve sanal POS tarafına odaklanırken, asıl ihmal edilen konu sunucu kaynakları oluyor. Genelde kullanıcılarımızdan duyduğumuz en büyük şikayet şu oluyor: “Ödeme sayfasında site bir anda yavaşlıyor, kullanıcı vazgeçip gidiyor.” Çoğu zaman sorun SSL değil, arka plandaki CPU/RAM/IO kullanımı.

Şöyle düşünün: Ödeme anı, trafiğin en hassas olduğu yer. Veritabanı sorguları, stok kontrolü, kampanya hesaplaması, kargo ücreti derken CPU tek seferde yükleniyor. Eğer paylaşımlı hostingde iseniz ve CPU limit’lere dayanıyorsanız, sanal POS ekranına geçişte bile gecikme yaşarsınız.

İlk bakmanız gereken yer genelde bu oluyor:

• cPanel / Plesk kullanıyorsanız Kaynak Kullanımı (Resource Usage) raporları
• SSH erişiminiz varsa top veya htop ile anlık CPU/RAM tüketimi
• Disk IO için iostat veya hosting panelindeki IO grafikleri

“Aşırı CPU kullanımı” ya da “Resource limit reached” uyarısı alıyorsanız, önce ödeme sürecinde çalışan eklentileri inceleyin. Özellikle ağır sorgular çalışan rapor/analytics eklentileri, ödeme anında büyük yük bindirebiliyor. Gerekirse VDS’e geçmek için VDS sanal sunucu seçeneklerine bakmak mantıklı olabilir. Dürüst olmak gerekirse, gelişen trafikte paylaşımlı hosting bir yere kadar idare ediyor.

Güvenlik Duvarı ve Port Ayarları

Dış dünyaya açık her port, açık bir penceredir. Özellikle ödeme sistemleriyle çalışan sitelerde bu pencereleri olabildiğince küçültmek gerekiyor. Sanal POS tarafı genellikle 443 (HTTPS) üzerinden çalışır. Yani SSL olmadan sanal POS çalışır mı? sorusunun aslında ikinci kısmı: “443 portunu ne kadar sağlıklı koruyorsun?”

Temel pratikler:

• SSH: Varsayılan 22 portunu değiştirin, mümkünse sadece belirli IP’lere izin verin. Root ile direkt giriş yerine normal kullanıcı + sudo tercih edin.
• FTP: Mümkünse klasik FTP yerine SFTP veya FTPS kullanın. Aktif kullanılmıyorsa FTP servisini tamamen kapatın.
• HTTP → HTTPS yönlendirme: 80 portundan gelen tüm trafiği 443’e kalıcı (301) yönlendirme ile taşıyın. Böylece ödeme sayfasına yanlışlıkla http ile girilmesini engellersiniz.

Firewall kullanıyorsanız (CSF, UFW veya panel içi güvenlik duvarları), bankanın sanal POS sisteminin size bilgi gönderdiği IP bloklarına izin vermeyi unutmayın. Aksi halde işlem bankada başarıyla sonuçlanır ama sizin site “callback” alamadığı için siparişi ödenmemiş zannedebilir.

Yazılım Uyumluluğu ve PHP/Veritabanı Seçimi

En güncel sürüm her zaman en iyisi mi? Güvenlik açısından genelde evet; stabilite açısından ise “tema/eklenti yazarlarının hızına bağlı”. Örneğin PHP 8.x’e geçmek performans ve güvenlikte ciddi artı sağlar, ama eski bir sanal POS modülü kullanıyorsanız uyumsuzluk çıkabilir.

Buradaki yaklaşım şu olmalı:

• Önce staging/test ortamında PHP versiyonunu yükseltin.
• Ödeme akışını başlangıç → 3D ekranı → başarı/başarısızlık dönüşü şeklinde baştan sona test edin.
• Hata loglarını kontrol edin: error_log veya paneldeki hata günlükleri, “deprecated” veya fatal hataları net gösterir.

Veritabanı tarafında altın kural şu: Ödeme sırasında çalışan sorgular mümkün olduğunca hafif ve indeksli olmalı. “Tüm sepeti, kuponları, stokları tek sorguda karmaşık join’lerle çekelim” mantığı, yüksek trafikte sitenizi kilitleyebilir. Özellikle orders veya transactions tablolarında index’lerin doğru tanımlandığından emin olun; WHERE ile süzme yaptığınız sütunlar indeksli değilse, ödeme sayfası anlamsız şekilde ağırlaşır.

Bu arada performansınızı artırmak için E-Ticaret sayfamızdaki diğer çözümlere de bakabilirsiniz. Genelde cache + doğru DB tasarımı + SSL üçlüsü, e-ticaret sitelerini bambaşka seviyeye taşıyor.

Uygulama: Kurulum ve Yayına Alma

Terminali açın, şu komutu girin demiyorum ama mantık şu: Önce SSL, sonra sanal POS, en son ince ayarlar. Sıralamayı ters yaparsanız, bankayla 3 tur mailleşirsiniz.

1. Alan adını netleştir: www ile mi, www olmadan mı kullanacağınıza baştan karar verin. SSL sertifikanız ve sanal POS bildirim URL’leriniz bu domaine bağlı olacak.
2. SSL sertifikasını kur: Ücretsiz Let’s Encrypt kullanabilirsiniz ama e-ticarette çoğu zaman kurumsal algı ve ek güvenlik için ücretli sertifikalar tercih ediliyor. Alternatifleri görmek isterseniz SSL sertifikası sayfasına göz atabilirsiniz.
3. HTTP → HTTPS zorunlu yönlendirme yapın: .htaccess veya Nginx config üzerinden. Tarayıcıda “Karışık içerik” (mixed content) kalmamasına dikkat edin.
4. Sanal POS modülünü/entegrasyonunu kur: WooCommerce, OpenCart, Magento veya özel yazılım; hepsinde mantık aynı. Bankanın verdiği Merchant ID, Store Key, Kullanıcı adı, Şifre, 3D store type bilgilerini modüle girin.
5. Callback (bildirim) URL’lerini SSL ile tanımla: Banka paneline girdiğiniz success, fail ve callback URL’lerinin tamamı https:// ile başlamalı.
6. Test kartlarıyla işlem yap: Önce düşük tutarlarda, farklı kart tipleriyle (Visa/Mastercard) test edin. Logları kontrol edin.

Genelde doğru SSL kurulumu sonrası, çalışır bir sanal POS’u yayına almak 5 dakikadan fazla sürmez. Asıl zaman kaybı, SSL’siz kurulum yapıp sonra bankanın “Siteniz güvenli görünmüyor, 3D testlerini geçemiyoruz” diye geri dönüş yapmasında yaşanıyor.

Sıkça Karşılaşılan Sorunlar ve Pratik Çözümler

Sıkça Sorulan Sorular

SSL olmadan sanal POS kullanmak güvenli mi?

Hayır. Kart bilgilerinin şifrelenmeden iletilmesi hem teknik olarak büyük risk, hem de bankalar ve PCI‑DSS standartları açısından kabul edilemez. Hatta bazı durumlarda, kart verisi sızarsa hukuki sorumluluk bile doğabilir. En düşük trafikli e‑ticaret sitesinde bile SSL’siz ödeme sayfası artık “geçmişte kalmış bir hata” olarak görülüyor.

Fiyat/Performans dengesini nasıl kurarım?

Temel ihtiyaçları şöyle sıralayabilirsiniz:

• İlk adım: Sağlam bir hosting veya VDS altyapısı (CPU/RAM/IO dengesini iyi veren bir plan). İsterseniz web hosting ya da ölçeklenebilir cloud sunucu seçeneklerine bakabilirsiniz.
• İkinci adım: Geçerli ve tarayıcı uyumlu bir SSL sertifikası.
• Üçüncü adım: Hafif tema, optimize edilmiş veritabanı, cache sistemi.

Dürüst olmak gerekirse, çoğu işletme gereğinden fazla pahalı POS çözümü ararken, en temel optimizasyonları yapmadığı için esas performans kazanımını kaçırıyor.

Taşıma (Migration) işlemi zor mu?

Korkutucu görünüyor ama doğru planla gayet yönetilebilir. E‑ticaret sitesi taşırken kritik olanlar:

• DNS geçişini planlı yapmak (downtime’ı minimuma indirmek)
• SSL sertifikasını yeni sunucuda da doğru kurmak
• Sanal POS callback adreslerini yeni domain veya alt alan adına göre güncellemek

Biz bu süreçte genelde “eski siteyi yeni sunucuya birebir taşı, hosts dosyasıyla lokal test yap, her şey yolundaysa DNS’i değiştir” mantığıyla ilerliyoruz. WordPress e‑ticaret gibi hazır altyapılarda ise bu iş çok daha hızlı ilerliyor; taşıma konusunda desteğe ihtiyacınız olursa süreç oldukça kolaylaştırılabiliyor.

Sonuç

İşin özü şu: SSL olmadan sanal POS çalışır mı? Evet, bazı uç senaryolarda “bir şekilde” tetiklenir; ama ne banka gözünde ne de güvenlik standartları açısından bu kabul edilebilir değil. E‑ticarette ödeme sayfanız, vitrininizden bile önemli. Orada güven vermiyorsanız, sepet toplam tutarının hiçbir anlamı kalmıyor.

Teknoloji ne kadar karmaşık görünürse görünsün, doğru yapılandırma gerçekten hayat kurtarır. Alan adı, hosting, SSL, sanal POS dörtgenini düzgün kurduğunuzda, ödeme süreçleri günlerce uğraştıran bir kabus olmaktan çıkıp, 1–2 testle kapanan bir iş haline geliyor. Eğer bir yerde takılırsanız biz buradayız, yorumlarda sorularınızı bekliyorum.