Generator testowych numerów kart (z sumą Luhna, tylko środowisko testowe)

To narzędzie generuje fałszywe, syntetyczne numery kart tylko w jednym celu: do przećwiczenia formularza checkoutu, integracji SDK płatności lub zautomatyzowanego zestawu testów bez dotykania prawdziwego konta. Nie jest to sposób na uzyskanie działającej karty, a żadne dane wyjściowe nie są powiązane z jakimkolwiek prawdziwym kontem, posiadaczem karty czy bankiem. Każdy numer zbudowany jest na prefiksie BIN, który operatorzy płatności publikują we własnej dokumentacji deweloperskiej środowiska testowego właśnie po to, aby inżynierowie mogli wypełniać testowe formularze płatności – dokładnie te same prefiksy w stylu 424242..., 411111..., 555555..., 510510..., 378282..., 371449... i 601111..., przywoływane w głównych dokumentacjach trybu testowego bramek. Nic tutaj nie zadziała przy prawdziwym zakupie, w prawdziwym sklepie, na prawdziwej sieci płatniczej.

To, co sprawia, że dane wyjściowe wyglądają na poprawne, a nie są jedynie losowym ciągiem znaków, to prawdziwa suma kontrolna Luhna (mod-10), obliczana od podstaw przy każdej generacji: zaczynając od cyfry skrajnie prawej numeru kandydującego, podwaja się co drugą cyfrę, od każdego podwojonego wyniku większego niż 9 odejmuje się 9, sumuje wszystkie cyfry, a pozostałą jedną cyfrę dobiera tak, aby całkowita suma była wielokrotnością dziesięciu. To ta sama arytmetyka, którą wykonuje sprawdzenie „wygląda na prawidłowy numer karty” po stronie przeglądarki, więc te numery przechodzą ten konkretny, wąski test tak samo, jak zrobiłby to prawdziwy numer karty – pozostając przy tym całkowicie fałszywymi, wygenerowanymi lokalnie i bezużytecznymi dla faktycznej transakcji.

Narzędzie utrzymuje udokumentowany prefiks testowy stały dla danej sieci i losuje wszystko po nim, tak aby partia do 20 numerów była naprawdę 20 różnymi numerami z poprawną sumą Luhna, a nie tym samym dobrze znanym, dosłownym numerem testowym wydrukowanym wielokrotnie. Każdy wynik jest następnie ponownie klasyfikowany według rzeczywistych reguł zakresów BIN używanych przez formularze płatności do wykrywania sieci karty (początkowa cyfra 4 dla Visa, 51 do 55 lub 2221 do 2720 dla Mastercard, 34 lub 37 dla Amex, 6011 lub 65 dla Discover) wyłącznie w celu potwierdzenia, że pokazana etykieta pasuje do wygenerowanych cyfr, plus poprawnie dobrany rozmiar CVV (3 cyfry, lub 4 dla Amex) i opcjonalna losowa przyszła data ważności dla wygody przy wypełnianiu pełnego formularza testowego.

To udogodnienie dla programistów i testerów QA, a nie produkt płatniczy: istnieje, ponieważ Stripe, PayPal i większość innych procesorów już publikuje te dokładne numery tylko do testów dla każdego, kto integruje ich checkout, a posiadanie szybkiego sposobu generowania wariantów, które wciąż spełniają walidację Luhna po stronie klienta, oszczędza ręcznego przepisywania tych samych kilku podręcznikowych numerów. Wszystko działa lokalnie w przeglądarce z losowością wspieraną przez Web Crypto – nic nie jest nigdzie przesyłane, a niczego, co tu powstanie, nie należy nigdy wprowadzać w produkcyjnym checkoutcie prawdziwego sprzedawcy.