Ödeme Sayfası Güvenliği: Kart Verisine Hiç Dokunmamak

Sitenizde ödeme alacaksınız. Kart bilgilerini kendi formunuzda toplayıp sağlayıcıya iletmek en kolay yol gibi görünüyor — ve bu, alabileceğiniz en riskli kararlardan biri.

Bu yazı, ödeme entegrasyonunda güvenlik sorumluluğunu doğru dağıtmayı ele alıyor.

Temel İlke

Ödeme güvenliğinin özü tek bir cümlede toplanır:

Kart verisine hiç dokunmayan bir sistem, kart verisini sızdıramaz.

Bu ilke, sorumluluğun büyük kısmını sizden alır:

• Sunucunuz kart numarası görmez.
• Günlüklerinize kart bilgisi yazılmaz.
• Veritabanınızda kart verisi bulunmaz.
• Uyum yükümlülüğünüz büyük ölçüde azalır.

İkinci madde çoğu kişinin düşünmediği bir sızıntı yoludur: kart bilgisi form üzerinden geçtiğinde, bir hata durumunda tüm istek gövdesi hata günlüğüne yazılabilir — ve orada aylarca durur.

Entegrasyon Yöntemleri

Kart verisiyle temasınıza göre üç model vardır:

Üçüncü satır kaçınılması gereken modeldir: kart verisini kendi sunucunuzdan geçirmek, tüm sunucunuzu ödeme güvenliği kapsamına sokar — ve denetim yükümlülüğü ciddi biçimde artar.

İkinci satır iyi bir denge kurar. Ödeme alanları sağlayıcının çerçevesi içinde yüklenir, kullanıcı sitenizden ayrılmaz ama veri sizin sayfanıza hiç girmez.

Bu yöntemde tasarım kontrolü sınırlıdır ama kazanılan güvenlik bunu fazlasıyla karşılar.

Belirteç Kullanımı

Tekrarlayan ödemeler için kart saklamak gerektiğinde:

1. Kart bilgisi sağlayıcıya gider.
2. Sağlayıcı bir belirteç döner.
3. Siz yalnızca belirteci saklarsınız.
4. Sonraki ödemelerde belirteci gönderirsiniz.

Üçüncü madde riski dönüştürür: belirteç çalınsa bile yalnızca sizin hesabınız üzerinden ve yalnızca o sağlayıcıda kullanılabilir — kart numarası gibi her yerde geçerli değildir.

Bu, "kartı sakla" özelliğini güvenli biçimde sunmanın tek doğru yoludur. Kart numarasını şifreleyip kendi veritabanınızda tutmak, kabul edilebilir bir alternatif değildir.

Sunucu Tarafı Doğrulama

Ödeme akışında en kritik kural:

Tutarı ve sipariş bilgisini asla istemciden gelen veriye dayandırmayın.

Doğru akış şöyle olmalıdır:

• İstemci yalnızca sipariş kimliğini gönderir.
• Sunucu tutarı veritabanından okur.
• Ödeme talebi sunucudan oluşturulur.
• İmza veya doğrulama kodu sunucuda üretilir.

Bu yapı olmadan ciddi bir açık doğar: tutarı gizli bir form alanında taşıyan bir ödeme sayfasında, kullanıcı o değeri değiştirip ürünü istediği fiyata alabilir.

Bu senaryo teorik değildir ve e-ticaret sitelerinde gerçekten yaşanır.

Ödeme Bildirimi

Sağlayıcının gönderdiği başarı bildirimi doğrulanmalıdır:

Birinci satır olmadan sistem tamamen açıktır: imza doğrulaması yapılmayan bir bildirim uç noktasına, herkes sahte bir "ödeme başarılı" isteği gönderebilir ve siparişi ödenmiş olarak işaretletebilir.

Üçüncü satır tekrar eden bildirimleri güvenli kılar. Sağlayıcılar bildirimi birden fazla kez gönderebilir; sipariş zaten ödenmişse ikinci bildirim yok sayılmalıdır.

Beşinci satır ise en sağlam yaklaşımdır. Bildirimi bir tetikleyici olarak kabul edip, ödeme durumunu sağlayıcıya sorarak teyit etmek, sahte bildirim riskini tamamen ortadan kaldırır.

Kullanıcı Dönüşüne Güvenmemek

Ödeme sonrası kullanıcı sitenize geri döner — ama bu bir kanıt değildir:

1. Kullanıcı ödeme yapmadan da dönüş adresine gidebilir
2. Tarayıcı kapanırsa dönüş hiç gerçekleşmeyebilir
3. Ödeme başarılı olsa bile dönüş kaybolabilir

Bu yüzden iki kanal ayrılmalıdır: kullanıcı dönüşü yalnızca ekran göstermek içindir, siparişi onaylayan tek kaynak sunucudan sunucuya gelen bildirimdir.

İkinci madde pratikte sık yaşanır. Kullanıcı ödemeyi tamamlar, tarayıcı kapanır ve siteye hiç dönmez — ama ödeme gerçekleşmiştir ve sipariş işlenmelidir.

Ödeme Sayfası Gereklilikleri

Ödeme adımının kendisinde dikkat edilecekler:

• Şifreli bağlantı zorunlu. İstisnasız.
• Karışık içerik olmamalı. Tüm kaynaklar şifreli.
• Üçüncü taraf betikler sınırlanmalı.
• Önbelleklenmemeli.
• Güvenlik başlıkları eklenmeli.

Üçüncü madde çoğu sitede ihlal edilir: ödeme sayfasına yüklenen bir analitik veya sohbet betiği, o sayfadaki tüm alanları okuyabilecek yetkiye sahiptir.

Bu betiklerden birinin ele geçirilmesi, kart verilerinin sızmasına yol açabilir. Ödeme adımında yalnızca gerekli olanlar yüklenmelidir.

Neyi Kaydetmeli, Neyi Kaydetmemeli

Ödeme işlemlerinde kayıt tutma sınırları:

Sağ sütundaki ikinci satır kesin bir yasaktır: güvenlik kodu, işlem tamamlandıktan sonra hiçbir koşulda saklanamaz — şifrelenmiş olsa bile.

Sol sütundaki üçüncü satır ise kullanıcıya kartını tanıtmak için yeterlidir ve saklanmasında sakınca yoktur.

Test Ortamı

Ödeme entegrasyonu mutlaka test edilmelidir:

1. Sağlayıcının test ortamını kullanın.
2. Test anahtarlarını canlıya karıştırmayın.
3. Başarısız ödeme senaryolarını da deneyin.
4. İptal ve iade akışını test edin.
5. Bildirim uç noktasını doğrulayın.

Üçüncü madde en çok atlanan testtir: başarısız bir ödemede kullanıcıya ne gösterildiği ve siparişin hangi duruma geçtiği, başarılı senaryo kadar önemlidir.

Yanlış yönetilen bir başarısızlık, kullanıcının tekrar denemesine ve iki kez ödeme yapmasına yol açabilir.

İkinci madde ise klasik bir kazadır. Test ortamı canlının kopyasıysa, test anahtarları da kopyalanmış olabilir ve canlı ödemeler test moduna düşer.

Bu ayrımı yapılandırma dosyalarını ortama göre ayırarak kurabileceğiniz hosting paketi ortamında, test ve canlı ayarların birbirine karışmaması sağlanabilir.

Sonuç

Ödeme güvenliğinin özü sorumluluğu üstlenmemektir: kart verisine hiç dokunmayan bir sistem, kart verisini sızdıramaz. Kendi formunuzdan geçirmek tüm sunucunuzu kapsama sokar; gömülü alan veya yönlendirme yöntemini tercih edin. Akış tarafında en ağır açık tutar manipülasyonudur — tutarı gizli form alanında taşımak, kullanıcının ürünü istediği fiyata almasına imkân verir. Ve siparişi onaylayan tek kaynak kullanıcı dönüşü değil, sunucudan sunucuya gelen doğrulanmış bildirimdir.

Sıkça Sorulan Sorular (SSS)

Kart bilgilerini kendi formumda alabilir miyim?

Teknik olarak mümkün ama kaçınılması gereken bir modeldir. Kart verisini kendi sunucunuzdan geçirmek tüm sunucunuzu ödeme güvenliği kapsamına sokar ve denetim yükümlülüğünü ciddi biçimde artırır. Gömülü alan veya yönlendirme yöntemini tercih edin.

Tutarı formda taşımanın riski ne?

Kullanıcı o değeri değiştirip ürünü istediği fiyata alabilir. İstemciden yalnızca sipariş kimliği gelmeli, tutar sunucuda veritabanından okunmalı ve ödeme talebi sunucuda oluşturulmalıdır.

Ödeme bildirimini nasıl doğrularım?

İmza doğrulaması zorunludur — onsuz herkes sahte bir "ödeme başarılı" isteği gönderip siparişi ödenmiş işaretletebilir. En sağlam yaklaşım ise bildirimi bir tetikleyici sayıp ödeme durumunu sağlayıcıya sorarak teyit etmektir.

Kullanıcı ödeme yapıp siteye dönmedi, sipariş ne olacak?

Yine işlenmelidir. Kullanıcı dönüşü yalnızca ekran göstermek içindir; siparişi onaylayan tek kaynak sunucudan sunucuya gelen bildirimdir. Tarayıcı kapansa bile ödeme gerçekleşmişse sipariş tamamlanmalıdır.