E-Ticaret Sistemlerinde Ödeme Adımları Testi: 3D Secure, İptal/İade ve Fraud Senaryoları
E-ticaret platformlarında kullanıcı deneyiminin ve finansal tutarlılığın en kritik olduğu aşama, ödeme (checkout) ve ödeme sonrası süreçlerdir. Kullanıcının kart bilgilerini girmeye başladığı an ile herhangi bir sebeple siparişten vazgeçtiği an arasındaki tüm akışlar, kuruşu kuruşuna hatasız işlemek zorundadır.
Bu yazımda, bir manuel test mühendisinin e-ticaret sitelerinde uçtan uca test etmesi gereken ödeme adımlarını ve sınır durumları (Edge Case) bir araya getirdim.
1. Kart Giriş Alanları ve BIN Sorgulama Testleri (Arayüz ve Ön Yüz)
Ödeme süreci, kullanıcının kart bilgilerini form alanlarına girmesiyle başlar. Bu ilk adımda ön yüz (frontend) validation kuralları test edilmelidir.
Luhn Algoritması ve Maskeleme: Kredi kartı numarasının geçerliliğini kontrol eden Luhn algoritmasının çalışıp çalışmadığı doğrulanmalıdır. Kart numarası girilirken aralara otomatik boşluk bırakılması ve son kullanma tarihinin
AA/YYformatında maskelenmesi kontrol edilmelidir.BIN (Bank Identification Number) Kontrolü: Kartın ilk 6 veya 8 hanesi girildiği an, sistemin bankayı ve kart tipini (Visa, Mastercard, Troy vb.) doğru algıladığı teyit edilmelidir.
Dinamik Taksit Tablosu: BIN numarası algılandığı an, o bankaya ait taksit seçeneklerinin ve vade farkı tablosunun ekranda listelenip listelenmediği; farklı bir kart girildiğinde tablonun dinamik olarak güncellendiği test edilmelidir.
Taksit Yasaklı Kategoriler: Sepette mevzuat gereği taksit yapılamayan bir ürün (altın, kozmetik, gıda vb.) varsa, kart bilgileri girilse dahi taksit tablosunun kapalı kaldığı veya sadece "Tek Çekim" seçeneğinin aktif olduğu doğrulanmalıdır.
2. Sanal POS Entegrasyonu ve Request Yönetimi
Kullanıcı "Ödeme Yap" butonuna bastığı an arka planda API istekleri ve ödeme geçitleri (iyzico, PayTR, Stripe vb.) devreye girer.
Doğru POS Yönlendirmesi: Sistemin, girilen karta ait işlemi arka planda o bankanın Sanal POS'una veya en avantajlı ödeme geçidi rotasına doğru yönlendirdiği test edilmelidir.
Matematiksel Tutar Eşleşmesi: Sepetteki ürünlerin toplamı + kargo ücreti + varsa taksit vade farkı toplamının, bankaya gönderilen ham istekteki (payload) tutarla kuruşu kuruşuna eşleştiği doğrulanmalıdır.
Para Birimi (Multi-Currency) Kontrolleri: Eğer platform yurt dışına satış yapıyorsa; Dolar veya Euro ile yapılan ödemelerin, Sanal POS'a doğru döviz koduyla gönderildiği ve kur dönüşümlerinin back-end sistemine doğru yansıtıldığı test edilmelidir.
3. 3D Secure Güvenlik ve Doğrulama Testleri
3D Secure, online alışverişlerde sahte işlem riskini azaltan ve banka ile entegre çalışan en temel güvenlik katmanıdır.
Yönlendirme ve Doğrulama: Doğru SMS/şifre girildiğinde siparişin sorunsuz oluştuğu ve kullanıcının "Sipariş Başarılı" sayfasına yönlendirildiği doğrulanmalıdır. Yanlış şifre girildiğinde ise karttan para çekilmediği, kullanıcının net bir hata mesajı gördüğü ve sepetinin bozulmadan kaldığı kontrol edilmelidir.
Doğrulama Ekranı Zaman Aşımı (Timeout): Kullanıcı 3D Secure şifre giriş ekranında hiçbir işlem yapmadan sürenin dolmasını beklediğinde (bankaların standardı genellikle 180 saniyedir), sistemin işlemi güvenli bir şekilde sonlandırıp kullanıcıyı "Ödeme Başarısız" sayfasına yönlendirdiği test edilmelidir.
Pencereyi Kapatma ve Geri Tuşu: Kullanıcı tam 3D şifre ekranındayken tarayıcı penceresini kapatırsa, "X" butonuna basarak sayfadan çıkarsa veya tarayıcının "Geri" butonuna basarsa; arka planda bankayla olan oturumun güvenli bir şekilde sonlandığı ve mükerrer isteklerin engellendiği doğrulanmalıdır.
4. Hata Kodları ve Kullanıcı Bilgilendirme Testleri
Bankadan her zaman başarılı yanıt dönmez. Dönen hata kodlarının hem kullanıcıya hem de sisteme doğru yansıması gerekir.
Anlaşılır Hata Mesajları: Bankadan dönen teknik hata kodlarının (Örn: Yetersiz Bakiye - 51, Sınır Aşımı - 61, Geçersiz Kart - 14) kullanıcı arayüzünde "Kartınızın limiti yetersizdir" veya "Son kullanma tarihi geçersizdir" gibi anlaşılır Türkçe mesajlara dönüştüğü doğrulanmalıdır.
Sistem Loglama Kontrolü: Başarısız olan tüm ödeme denemelerinin, bankadan dönen ham hata kodları ve hata mesajlarıyla birlikte admin panelinde ve veri tabanında loglandığı test edilmelidir.
5. Fraud (Sahtekarlık ve Dolandırıcılık) Önleme Testleri
Sistem, çalıntı kart denemelerine ve kötü niyetli sipariş girişimlerine karşı kendini koruyabilmelidir. Manuel testte bu güvenlik duvarlarını şu senaryolarla zorlamalıyız:
Kart Deneme (Carding) ve Hız Limitleri (Velocity Checks): Aynı tarayıcıdan, aynı kullanıcı hesabıyla veya aynı IP adresinden 1 dakika içinde arka arkaya 5-10 kez farklı kartlarla ödeme denendiğinde; sistemin bu durumu "şüpheli işlem" olarak algılayıp IP'yi/hesabı geçici olarak bloklayıp bloklamadığı veya Captcha zorunluluğu getirip getirmediği test edilmelidir.
3D Secure Bypass Girişimi (İstek Manipülasyonu): Kötü niyetli kişilerin ödeme isteğini araya girerek (örneğin proxy araçlarıyla) manipüle etmesi ve 3D Secure onay adımına hiç uğramadan (3D parametresini
falseyaparak) geçmeye çalışması durumunda, API düzeyinde bu işlemin reddedildiği doğrulanmalıdır.Kara Liste (Blacklist) Kontrolleri: Sistemde daha önce fraud riski sebebiyle bloke edilmiş bir e-posta adresi, telefon numarası veya IP adresiyle yeni bir üyelik açıp ödeme yapılmaya çalışıldığında, sistemin işlemi anında durdurduğu test edilmelidir.
Response (Yanıt) Manipülasyonu ile Bedava Alışveriş: Bankadan dönen "Başarısız" ödeme yanıtının, tarayıcıda araya girilerek (Response Manipulation) "Başarılı" koduna (
status: success) dönüştürülmesi durumunda; arka plandaki sipariş veritabanının bu hileyi yutmayıp siparişi "Başarısız/İptal" statüsünde tuttuğu doğrulanmalıdır.
6. İptal ve İade Senaryoları (Ödeme Sonrası)
Sipariş tamamlandıktan sonra, finansal sürecin tersine işletilmesi adımıdır.
İptal Akışı: Müşteri siparişi verdikten hemen sonra (mağaza henüz gün sonu raporu almadan) siparişi iptal etmek istediğinde, bloke edilen tutarın banka tarafından karta anında geri yansıtıldığı test edilmelidir.
Kısmi İade (Partial Refund) Akışı: Kullanıcı birden fazla ürün içeren bir siparişin sadece tek bir ürününü iade etmek istediğinde; sistemin sadece o ürünün tutarını karta iade edip etmediği, kalan ürünlerin sipariş durumunun ise doğru kaldığı test edilmelidir.
Kuponlu ve Kampanyalı İadeler: Sepette "100 TL İndirim Kuponu" veya "3 Al 2 Öde" gibi kampanyalar varken ürün iadesi istendiğinde; indirim tutarının ürün fiyatlarına doğru oranlanarak iade edilecek net tutardan düşülüp düşülmediği kontrol edilmelidir.
Kargo Ücreti İade Kuralları: Siparişteki tüm ürünler iade edildiğinde kargo ücreti müşteriye geri ödeniyor mu? Ya da kısmi iade yapıldığında kalan ürünler minimum kargo limitinin altına düşerse sistem kargo ücretini nasıl hesaplıyor? Bu sınır durumlar doğrulanmalıdır.
Test Mühendisleri İçin Pratik Uygulama İpuçları
Test Kartı Kütüphaneleri: Sanal POS sağlayıcınızın dökümantasyonunda yer alan başarılı ödeme, yetersiz bakiye, 3D hatası veya sahtekarlık şüphesi uyandıran özel test kart numaralarını kullanarak her senaryoyu manuel olarak tetikleyin.
Network Sekmesini İzlemek: Ödeme veya iade butonuna bastığınızda arka planda dönen ham verileri görmek için sistem mimarisine göre Chrome DevTools (F12) > Network veya Postman'i açık tutun.
/payveya/refundAPI isteklerinin dönen yanıtlarında (Response) sisteminizin ürettiği durum kodlarını (Status Code: 200, 400, 500) inceleyin.Excel ile Doğrulama: Karmaşık sepetlerde (kargo ücreti, kupon kodu ve kampanyalar bir arada olduğunda) manuel iade yaparken, iade edilecek net tutarı önce bir Excel tablosunda formülize edin. Ardından admin panelinin hesapladığı iade tutarıyla Excel'deki değerin birebir eşleştiğini teyit edin.
Özetle, ödeme adımlarının uçtan uca testi, bir e-ticaret uygulamasının kalitesini gösteren en büyük sınavdır. Kartın ilk hanesinden başlayıp olası bir iade sürecine kadar uzanan bu zincirde hiçbir halka kırılmamalıdır. Bu senaryoları metodolojik bir şekilde manuel test süreçlerine dahil etmek, platformu canlı ortamda yaşanabilecek büyük finansal krizlerden, prestij ve müşteri kaybından korur.