Kredi kartı numarası üretici, ödeme formlarını ve doğrulama mantığını sınamak için biçimsel olarak geçerli ama hiçbir gerçek hesaba bağlı olmayan numaralar üretir. Ödeme akışı, bir uygulamanın en az hata affeden bölümüdür; bu yüzden buradaki test verisinin hem doğru biçimde hem de sınırları bilinerek kullanılması gerekir. Bu yazıda test numarası ile gerçek numara arasındaki farkı, Luhn kontrol basamağının ne işe yaradığını, BIN aralıklarının nasıl ayrıldığını, CVV ve son kullanma tarihinin neden numarayla tutarlı olması gerektiğini ve PCI DSS çerçevesinin test ortamına çizdiği sınırı bulacaksınız.
Kredi kartı numarası üretici ne üretir ve neyi üretmez?
Bu araç, bir kart numarasının yapısına uyan diziler üretir. Uzunluk, kart ağının kuralına göre belirlenir; baştaki hane grubu seçilen ağa ait olur; son hane ise kontrol basamağı olarak hesaplanır. Böylece üretilen numara, biçim denetiminden geçer.
Aracın üretmediği şey, bir hesaptır. Numaranın arkasında banka yoktur, bakiye yoktur, yetkilendirme yoktur. Numara biçimsel olarak geçerli olduğu için bazı formlar onu kabul eder; ama hiçbir ödeme ağı bu numarayla işlem onaylamaz.
Bu ayrımı anlamak, testin doğru kurulmasının ön koşuludur. Gerçek bir ödeme akışını sınamak için ödeme sağlayıcısının kendi test ortamı ve kendi test kartları kullanılır. Buradaki üretici ise doğrulama kodunuzu, form denetimini ve kullanıcı deneyimini sınamak içindir. Aracın çıktısını görmek için kredi kartı araçları sayfasından başlayabilirsiniz.
Test kartı numarası ile gerçek kart numarası arasındaki fark nedir?
Gerçek bir kart numarası, bir bankanın kaydına bağlıdır. Numaranın hangi kuruma ait olduğu, hangi hesabı temsil ettiği ve hangi limitlerle çalıştığı o kayıtta tanımlıdır. Numara bu kaydın dışında bir anlam taşımaz.
Test numarası ise yalnızca biçimi taşır. Aynı uzunlukta, aynı başlangıç grubunda ve aynı kontrol basamağı kuralına uygun olabilir; ama hiçbir kayda bağlı değildir. Bu yüzden gerçek bir numarayla test etmek, test etmek değil gerçek bir hesabı kullanmaktır.
Bu farkın pratik sonucu şudur: test ortamında bile gerçek kart numarası kullanılmamalıdır. Gerçek numara, test ortamının günlüklerine, veritabanına ve yedeklerine düşer; oradan temizlenmesi ise neredeyse imkânsızdır.
Luhn kontrol basamağı neden tek başına yeterli değildir?
Luhn kuralı, bir numaranın yazım hatası içerip içermediğini anlamak için kullanılan basit bir toplama yöntemidir. Sağdan başlanarak ikinci haneler ikiyle çarpılır, çarpım iki haneli çıkarsa rakamları toplanır, ardından bütün haneler toplanır. Toplamın ona tam bölünmesi beklenir.
Bu kural, tek hane hatası ve yanlış sıralamadan kaynaklanan hataların büyük bölümünü yakalar. Ancak iki hanenin birbirine karıştığı bazı durumları kaçırabilir ve numaranın gerçekten var olduğuna dair hiçbir bilgi vermez.
Bu yüzden Luhn denetimi tek başına bir güvenlik önlemi değil, yalnızca bir tutarlılık sınavıdır. Doğru kurulmuş bir doğrulama, kontrol basamağını BIN aralığı ve uzunluk denetimiyle birlikte değerlendirir. Algoritmanın adım adım anlatımı Luhn algoritması yazısında yer alıyor.
BIN aralıkları ve kart ağları nasıl ayrılır?
Numaranın başındaki hane grubu, kartı veren kurum aralığını gösterir ve ağın kimliğini belirler. Bu grup, kartın ait olduğu ağı ve o ağın kullandığı uzunluk kurallarını tanımlar. Uzunluk her ağda aynı değildir; on üç ile on dokuz hane arasında değişen yapılar vardır.
Ağ ayrımı yalnızca görsel bir ayrıntı değildir. Ödeme formunun kart logosunu doğru göstermesi, alan maskesini doğru kurması ve doğrulama mesajını doğru yazması bu ayrıma bağlıdır. Yanlış ağ tespiti, kullanıcıyı daha ilk adımda yanıltır.
Test kümelerinde her ağdan en az bir örnek bulunmalıdır. Farklı uzunluklarla çalışan örnekler, formun alan maskesini sabit varsayıp varsaymadığını ortaya çıkarır. Ağ bazlı örnekler için kart ağlarına göre test kartları yazısına bakabilirsiniz.
CVV ve son kullanma tarihi neden numarayla tutarlı olmalıdır?
Ödeme formunda üç alan birlikte çalışır: numara, son kullanma tarihi ve güvenlik kodu. Numara geçerli olsa bile diğer iki alan anlamsızsa form tutarsız davranır. Bu yüzden test verisinin bu üç alanı birlikte üretmesi gerekir.
Güvenlik kodunun uzunluğu kart ağına göre değişir; bazı ağlarda üç, bazılarında dört hanedir. Formun bu alanı her zaman sabit uzunlukta kabul etmesi, geçerli kartları gereksiz yere reddeder. Alanın yalnızca rakam kabul etmesi ise ayrı bir doğrulama maddesidir.
Son kullanma tarihinin biçimi de ağdan bağımsız olarak sınanmalıdır. Geçmiş bir tarih nasıl ele alınıyor, gelecekteki çok uzak bir tarih kabul ediliyor mu, ay değeri on ikinin üzerinde girildiğinde ne oluyor? Bu soruların cevapları formun gerçek davranışını gösterir. Alanların ayrıntısı CVV açıklaması ve son kullanma tarihi yazılarında ele alınıyor.
PCI DSS test ortamında neyi yasaklar?
Ödeme kartı verisiyle çalışan sistemler için tanımlanmış güvenlik çerçevesi, test ortamını da kapsar. Bu çerçevenin temel kuralı, gerçek kart verisinin yalnızca gerekli olan en dar kapsamda bulunmasıdır. Test ortamı bu kapsamın dışında kalır.
Bunun pratik anlamı, test ortamına gerçek numara kopyalanmamasıdır. Kopyalanan her numara, korunması gereken bir veri hâline gelir ve beraberinde saklama, erişim ve denetim yükümlülüğü getirir. Sentetik numaralar bu yükümlülüklerin hiçbirini doğurmaz.
Çerçevenin ikinci etkisi, kullanılan test yöntemidir. Kart verisini kendi sunucunuzda hiç tutmamak, sorumluluğun büyük bölümünü ortadan kaldırır. Bu nedenle testlerde ödeme sağlayıcısının barındırılan alanları tercih edilir. Çerçevenin test verisine bakan yönü PCI DSS ve test verisi yazısında özetleniyor; resmî metinler için PCI Güvenlik Standartları Konseyi sitesi başvuru kaynağıdır.
Ödeme formu test listesinde hangi maddeler bulunmalıdır?
İyi bir test listesi hem mutlu yolu hem de bozuk girdileri kapsar. Mutlu yol, geçerli biçimde üretilmiş bir numara, gelecekteki bir tarih ve doğru uzunlukta bir güvenlik koduyla formun başarıyla gönderilmesidir.
Bozuk girdiler ise sınırları zorlar. Bir hane eksik ya da fazla numara, kontrol basamağı bozuk numara, geçmiş tarih, boş alan ve harf içeren girdi bu gruba girer. Her biri için beklenen davranış testte açıkça yazılmalıdır.
Listenin üçüncü bölümü kullanıcı deneyimidir. Alan maskesi doğru ilerliyor mu, kart logosu numara yazılırken doğru değişiyor mu, hata mesajı hangi alanı işaret ediyor? Bu maddeler işlevsel doğruluktan bağımsız olarak sınanmalıdır. Hazır bir liste için ödeme formu test listesi yazısına göz atabilirsiniz.
Üretilen numarayı hangi katmanlarda doğrulamalıyım?
Kart numarası doğrulaması tek bir kontrol değil, üst üste binmiş katmanlardan oluşur. İlk katman uzunluk ve karakter kümesidir; alan yalnızca rakam kabul etmeli ve beklenen aralıkta kalmalıdır.
İkinci katman başlangıç grubudur. Numaranın ilk haneleri tanınan bir aralığa düşmüyorsa form bunu erken bir uyarıyla bildirmelidir. Üçüncü katman kontrol basamağıdır; yazım hatası en çok burada yakalanır.
Katmanların sırası da önemlidir. Kontrol basamağını uzunluk denetiminden önce çalıştırmak, eksik haneli bir numarada yanıltıcı bir sonuç üretir. Hataların doğru mesajla gösterilmesi için sıralama baştan belirlenmelidir.
Ödeme formunda hangi erişilebilirlik konuları öne çıkar?
Kart numarası alanı, klavyeyle doldurulması en zor alanlardan biridir. Alan maskesi imlecin konumunu ve silme davranışını bozarsa kullanıcı yazdığı haneyi göremez hâle gelir.
İkinci konu, ekran okuyucularla uyumdur. Dört haneli gruplara ayrılmış bir numara, ekran okuyucu tarafından tek tek rakam olarak okunmalıdır; aksi hâlde uzun bir sayı olarak okunur ve takip edilemez.
Üçüncü konu, yapıştırmanın engellenmemesidir. Kullanıcıların bir bölümü numarayı başka bir yerden kopyalar; yapıştırmayı engellemek güvenlik sağlamaz, yalnızca kullanıcıyı yavaşlatır. Alanın biçim kuralları için kart numarası biçimi yazısına bakabilirsiniz.
Test kartları neden sağlayıcıya göre değişir?
Her ödeme sağlayıcısı kendi test ortamında belirli numaraları tanır ve her birine farklı bir sonuç bağlar. Bir numara onay üretirken bir diğeri reddedilmeyi, bir başkası ek doğrulama gerektiren bir durumu temsil eder.
Bu numaraların ortak özelliği, gerçek hesaplara bağlı olmamasıdır. Yalnızca sağlayıcının kendi test ortamında anlam taşırlar; canlı ortamda hiçbir işlem üretmezler.
Test listesini sağlayıcının belgelerinden almak, uydurma numaralarla çalışmaktan çok daha güvenilirdir. Sağlayıcıya özgü örnekler Stripe test kartları yazısında toplanmış durumda.
Ek doğrulama adımları testte nasıl ele alınır?
Bazı ödeme akışları, işlemi tamamlamadan önce ek bir doğrulama adımı çalıştırır. Bu adım kullanıcıyı başka bir ekrana yönlendirir ve dönen sonuca göre işlemi onaylar ya da iptal eder.
Test ortamlarında bu adım genellikle taklit edilir; çünkü gerçek doğrulama sağlayıcısına bağlanmak testi yavaş ve kararsız yapar. Taklit akışın üretebileceği sonuçlar açıkça tanımlanmalıdır: onay, red ve kullanıcının vazgeçmesi.
En sık atlanan durum, kullanıcının doğrulama ekranından geri dönmesidir. Bu durumda sepetin, siparişin ve ödeme kaydının hangi durumda kaldığı mutlaka sınanmalıdır; aksi hâlde yarım kalan siparişler fark edilmez.
Numara üretirken hangi hatalar sık yapılır?
İlk sık hata, uzunluğu sabit varsaymaktır. Bütün kartları aynı hane sayısında kabul eden bir doğrulama, geçerli numaraların bir bölümünü reddeder.
İkinci hata, kontrol basamağını hesaplamamaktır. Rastgele üretilen bir numara doğru uzunlukta olabilir ama doğrulama kodunun ilgili bölümünü hiç çalıştırmaz.
Üçüncü hata, üretilen numarayı test kümesine elle yazmaktır. Elle yazılan bir numarada tek bir hane hatası, testin kendisini bozar ve saatler kaybettirir.
Test verisi üretim akışı nasıl kurulur?
Üretim akışı, girdiyi ve çıktıyı birbirinden ayırmalıdır. Girdi kart ağı ve uzunluk gibi seçimlerden, çıktı ise doğrulanmış bir numaradan oluşur.
Akışın ikinci parçası doğrulamadır. Üretilen numara kendi doğrulayıcınızdan geçirilmeden kümeye eklenmemelidir; böylece hatalı veri baştan engellenir.
Üçüncü parça, kaydın üretildiği anahtarın saklanmasıdır. Bu bilgi, aynı numaranın ileride yeniden üretilmesini ve testin tekrarlanabilir kalmasını sağlar.
Ödeme sağlayıcısı test ortamı nasıl izole edilir?
Ödeme sağlayıcısının test ortamı, canlı ortamdan tamamen ayrı anahtarlarla çalışır. Test anahtarı canlı işlem başlatamaz; bu ayrım en temel güvenlik kuralıdır.
İkinci kural, test ortamına canlı veri taşımamaktır. Gerçek bir kart numarası ya da gerçek bir müşteri kaydı, test ortamında tutulmamalıdır.
Üçüncü kural, test ortamının dışa kapalı olmasıdır. Test akışı gerçek e-posta göndermemeli ve gerçek kargo süreçlerini tetiklememelidir.
Test verisini canlı veriden nasıl ayırırım?
Ayrım, yalnızca etiketleme ile sağlanmaz. Test verisinin canlı ortama hiç ulaşamaması gerekir; bunun için teknik engeller şarttır.
İlk engel, ortamların ayrı veritabanları kullanmasıdır. Aynı tabloyu paylaşan iki ortamda tek bir yapılandırma hatası, test kaydını canlı veriye karıştırır.
İkinci engel, anahtar ayrımıdır. Test anahtarları canlı işlem başlatamaz ve bu kural sağlayıcı tarafında da uygulanır.
Üçüncü engel, kayıtların açıkça işaretlenmesidir. Bir kaydın sentetik olduğu kendi alanında yazmıyorsa, sızma sonrası temizlik neredeyse imkânsız hâle gelir.
Üretilen numaraları test kümesine nasıl eklerim?
Numaralar kümeye elle eklenmemelidir. Elle aktarılan bir numarada tek hane hatası, testin kendi verisini bozar ve hata uygulamada sanılır.
Doğru yol, numarayı üreten adımın çıktısını doğrudan kümeye yazmasıdır. Böylece aktarım sırasında bozulma olasılığı ortadan kalkar.
Kümeye eklenen her numaranın yanına hangi ağa ait olduğu ve hangi senaryoyu temsil ettiği yazılmalıdır. Bu not olmadan, küme büyüdükçe hangi kaydın neyi sınadığı unutulur.
Bu kayıtların sınırı nedir?
Bu araçla üretilen numaralar sentetik test verisidir. Biçimleri ilgili kart ağının kurallarına uyar ve kontrol basamağı doğru hesaplanır; ama bu numaralar hiçbir hesaba bağlı değildir, hiçbir ödeme ağı tarafından tanınmaz ve gerçek bir işlemde kullanılamaz.
Bu numaralar kendi ödeme formunuzu, doğrulama kodunuzu ve arayüz davranışınızı sınamak için üretilir. Bir başkasının kartını kullanmak, gerçek bir hesap açmak ya da bir ödeme sistemini yanıltmak amacıyla kullanılamaz; böyle bir kullanım hem aracın amacının dışındadır hem de hukuki sonuçlar doğurur.