Sitenize ödeme almak istiyorsunuz. Ödeme sağlayıcısı size bir entegrasyon dokümanı verdi ama hosting tarafında nelerin hazır olması gerektiği net değil.
Bu yazı, hosting hesabınızda ödeme entegrasyonu için karşılanması gereken teknik gereksinimleri anlatıyor.
Ön Koşullar
| Gereksinim | Neden |
|---|---|
| Geçerli SSL sertifikası | Zorunlu, istisnasız |
| Güncel çalışma zamanı sürümü | Güvenlik ve kütüphane uyumu |
| Giden bağlantı izni | Sağlayıcıya istek gönderilecek |
| Güncel kök sertifika deposu | Sağlayıcı sertifikası doğrulanacak |
| Modern şifreleme desteği | Eski protokoller reddedilir |
| Doğru sunucu saati | İmza doğrulaması zaman bazlı |
Son satır beklenmedik bir sorun kaynağıdır ve teşhisi zordur: sunucu saati kaymışsa ödeme istekleriniz imza doğrulamasından geçemez ve hata mesajı size zaman sorununu göstermez.
Üçüncü satır da paylaşımlı hosting ortamlarında karşılaşılan bir kısıttır: bazı hesaplarda dışarıya giden bağlantılar kısıtlıdır ve entegrasyon çalışmaz.
SSL: Pazarlıksız
Ödeme alan hiçbir sayfa şifresiz olmamalıdır. Ancak sertifikanın varlığı yeterli değildir:
- Tüm site HTTPS olmalı. Yalnızca ödeme sayfası değil.
- Karışık içerik olmamalı. Güvenli sayfada güvensiz kaynak yüklenirse tarayıcı uyarı verir.
- Sertifika zinciri eksiksiz olmalı. Bazı cihazlarda hata vermemeli.
- Otomatik yenileme çalışmalı. Süresi dolmuş sertifika, ödemeyi tamamen durdurur.
Dördüncü madde en yüksek maliyetli kesintiyi üretir: sertifika süresi dolduğunda site açılmaz hâle gelir ve her dakika doğrudan satış kaybıdır. Sertifika bitiş tarihini izleme sisteminize mutlaka ekleyin.
Kart Verisi: En Kritik Karar
Ödeme entegrasyonunda alacağınız en önemli karar şudur: kart bilgileri sizin sunucunuzdan geçecek mi?
| Model | Kart verisi nerede | Sorumluluk |
|---|---|---|
| Yönlendirmeli | Sağlayıcının sayfasında | En düşük |
| Çerçeveli / gömülü form | Sağlayıcının alanında | Düşük |
| Doğrudan entegrasyon | Sizin sunucunuzdan geçer | Çok yüksek |
Üçüncü satır güçlü bir uyarı gerektirir: kart verisinin sizin sunucunuzdan geçmesi, ağır güvenlik ve uyum yükümlülükleri getirir. Paylaşımlı bir hosting hesabında bu yükümlülükleri karşılamak pratikte mümkün değildir.
Pratik tavsiye: kart verisi sizin sunucunuza hiç uğramasın. Yönlendirmeli veya gömülü form modelini seçin. Bu, hem güvenlik riskini hem uyum yükünü sağlayıcıya devreder.
Bildirim Adresi
Ödeme sağlayıcıları, işlem sonucunu sunucunuza bir bildirimle iletir. Bu, entegrasyonun en kritik parçasıdır çünkü:
- Kullanıcı sayfayı kapatmış olabilir. Ödeme başarılı ama sipariş oluşmamış olur.
- Tarayıcı yönlendirmesine güvenilmez. Bağlantı kopabilir.
- Sunucudan sunucuya bildirim güvenilirdir. Ve tekrar denenir.
Bu adresin yapılandırmasında dikkat edilecekler:
- Dışarıdan erişilebilir olmalı. Giriş gerektiren bir sayfa olamaz.
- İmza doğrulaması yapmalı. Sahte bildirim gönderilebilir.
- Hızlı yanıt vermeli. Sağlayıcı zaman aşımına uğramamalı.
- Tekrarlanabilir olmalı. Aynı bildirim iki kez gelebilir.
- Loglanmalı. Sorun olduğunda ne geldiğini görmelisiniz.
İkinci madde ciddi bir güvenlik konusudur: imza doğrulaması yapılmayan bir bildirim adresi, sahte "ödeme başarılı" mesajlarıyla ücretsiz sipariş oluşturmaya açıktır.
Dördüncü madde de sık yaşanan bir sorunu önler: bildirim ulaştı ama yanıtınız zamanında gitmediyse sağlayıcı tekrar dener. Aynı sipariş iki kez işlenmemelidir.
Oturum Sorunu
Ödeme akışında kullanıcı sitenizden çıkıp sağlayıcıya gider ve geri döner. Bu geçişte oturum kaybolabilir.
Nedeni, çerezlerin site dışı gönderim politikasıdır: tarayıcılar bu konuda giderek katılaşmaktadır ve yanlış yapılandırılmış bir çerez, dönüşte gönderilmez.
Sonuç: kullanıcı ödemeyi yapar, siteye döner ve sepeti boş bulur.
Çözümler:
- Çerezin site dışı gönderim politikasını ödeme akışınıza uygun ayarlayın
- Sipariş durumunu oturuma değil veritabanına bağlayın
- Dönüş adresine sipariş kimliği ekleyin
- Bildirim adresini asıl kaynak olarak kullanın
Son madde en sağlam yaklaşımdır: siparişin durumunu tarayıcı dönüşüne değil sunucudan gelen bildirime göre belirleyin. Böylece kullanıcı sayfayı kapatsa bile sipariş doğru işlenir.
Test Süreci
Ödeme sağlayıcıları test ortamı sunar. Kullanılması gerekenler:
- Başarılı ödeme senaryosu
- Başarısız ödeme senaryosu
- Kullanıcının iptal etmesi
- Ödeme sonrası sayfayı kapatma
- Bildirim gecikmesi
- Aynı bildirimin tekrar gelmesi
- İade işlemi
Dördüncü ve altıncı senaryolar en çok atlanan ve canlıda en çok soruna yol açanlardır. Test ortamında bilinçli olarak sayfayı kapatın ve siparişin yine de oluştuğunu doğrulayın.
Ayrıca test ortamından canlıya geçerken anahtarları değiştirmeyi unutmayın — test anahtarlarıyla canlıya çıkmak, hiçbir ödemenin gerçekleşmemesi demektir.
Güvenlik Kontrolleri
- API anahtarlarını kod içine yazmayın. Yapılandırma dosyasında ve web kökü dışında tutun.
- Tutar doğrulaması yapın. Ödenen tutar, sipariş tutarıyla eşleşmeli.
- Tutarı istemciden almayın. Sunucu tarafında hesaplayın.
- Sipariş durumunu tek yönlü ilerletin. Tamamlanmış bir sipariş geriye dönmemeli.
- İşlem loglarını saklayın. Ama kart verisi yazmayın.
Üçüncü madde temel bir güvenlik kuralıdır ve ihlali kolayca istismar edilir: tutar bilgisi tarayıcıdan geliyorsa, kullanıcı onu değiştirebilir ve bir ürünü istediği fiyata satın alabilir.
Kaynak Gereksinimleri
Ödeme entegrasyonu hosting kaynaklarınızı da etkiler:
- Her ödeme, dış bir servise istek demektir ve süreç bloke olur
- Kampanya dönemlerinde eşzamanlı istek sayısı artar
- Bildirim adresine gelen istekler ek yük üretir
İlk madde önemli bir performans etkisidir: ödeme sağlayıcısı yavaş yanıt verirse, o süre boyunca bir işçi süreciniz meşgul kalır. Yoğun dönemlerde bu, eşzamanlı kapasitenizi tüketebilir.
Bu yüzden ödeme alan sitelerde kaynak limitleri daha kritiktir. Hosting paketinizin eşzamanlı işlem limitini, beklenen kampanya trafiğinizle karşılaştırın.
Sonuç
Ödeme entegrasyonunda alacağınız en önemli karar teknik değil mimari: kart verisi sunucunuza hiç uğramamalıdır. Yönlendirmeli veya gömülü form modeli, güvenlik riskini ve uyum yükünü sağlayıcıya devreder — paylaşımlı hostingde doğrudan entegrasyonun gereklerini karşılamak zaten mümkün değildir. Sipariş durumunu tarayıcı dönüşüne değil sunucudan gelen bildirime göre belirleyin ve o bildirimde mutlaka imza doğrulaması yapın. Ve teşhisi en zor sorunu unutmayın: kaymış bir sunucu saati, ödemelerin sessizce reddedilmesine yol açar.
Sıkça Sorulan Sorular (SSS)
Hangi entegrasyon modelini seçmeliyim?
Kart verisinin sunucunuzdan geçmediği bir model — yönlendirmeli veya gömülü form. Doğrudan entegrasyon ağır güvenlik ve uyum yükümlülükleri getirir ve paylaşımlı bir hosting hesabında bunları karşılamak pratikte mümkün değildir.
Sipariş durumunu neye göre belirlemeliyim?
Sunucudan gelen bildirime göre, tarayıcı dönüşüne değil. Kullanıcı ödeme sonrası sayfayı kapatabilir veya bağlantısı kopabilir; bu durumda tarayıcı dönüşü hiç gerçekleşmez ama ödeme başarılı olmuştur. Bildirim adresini asıl kaynak olarak kullanın.
Ödemeden dönünce sepet boş görünüyor?
Çerezin site dışı gönderim politikası yanlış ayarlanmış olabilir — tarayıcılar bu konuda giderek katılaşıyor ve dönüşte çerez gönderilmiyor. Ayrıca sipariş durumunu oturuma değil veritabanına bağlayın.
Ödemelerim reddediliyor ama hata anlaşılmıyor?
Sunucu saatinizi kontrol edin. Ödeme sağlayıcıları isteklerin zaman damgasını doğrular; saat kaymışsa istekleriniz imza doğrulamasından geçemez ve hata mesajı size zaman sorununu göstermez. Bu, teşhisi en zor sorunlardan biridir.
