Genera numeri di carta di credito fittizi validi secondo l'algoritmo Luhn (ISO/IEC 7812) con prefissi corretti per Visa, Mastercard, American Express, Discover, JCB e Diners. Include numero, CVV/CVC e scadenza casuali. Indispensabile per testare form di pagamento, gateway, e-commerce in sandbox.
Un numero di carta "valido" non è un numero vero: è una sequenza che rispetta le regole di formato dei circuiti, a partire dall'algoritmo di Luhn. Questo generatore produce cifre fittizie che superano quel controllo di coerenza, con prefissi corretti per Visa, Mastercard, American Express e Discover, così sviluppatori, tester QA e docenti possono provare form di pagamento, validatori e flussi di checkout senza toccare dati reali. Nessuno di questi numeri è collegato a un conto, a una banca o a una persona: servono a far girare il codice, non a pagare. Dati fittizi, solo per test: mai utilizzabili per pagamenti o frodi.
Il primo passo è la scelta del circuito, che fissa prefisso (IIN/BIN) e lunghezza. Visa parte per 4 con 16 cifre, Mastercard usa i range 51-55 o 2221-2720, American Express inizia per 34 o 37 con 15 cifre, Discover per 6011, 644-649 o 65 con 16. Le cifre intermedie vengono riempite da una sorgente crittografica (random_int / CSPRNG), non dal classico rand pseudo-casuale, così le sequenze non sono prevedibili né ripetitive.
L'ultima cifra non è casuale: è il check digit calcolato con l'algoritmo di Luhn. Partendo da destra si raddoppia una cifra sì e una no, si sommano tutte le cifre (sottraendo 9 a chi supera il 9) e si sceglie la cifra finale che porta il totale a un multiplo di 10. È lo stesso controllo che ogni gateway esegue lato client per bocciare al volo un 4539 0000 0000 0001 digitato male.
Dove serve, il generatore accompagna il PAN con una scadenza futura plausibile (es. 09/29) e un CVV della lunghezza giusta: 3 cifre per Visa, Mastercard e Discover, 4 per Amex. Restano valori inventati. Il CVV, in particolare, non è derivabile dal numero, quindi qualsiasi terzina va bene solo per riempire un campo, mai per un'autorizzazione reale.
Compilare il form di pagamento in staging per verificare che la validazione lato client accetti un Visa a 16 cifre e rifiuti un numero con check digit di Luhn errato.
Popolare una schermata di riepilogo o uno screenshot con un numero dall'aspetto realistico, mostrando le ultime 4 cifre senza mai esporre una carta vera.
Verificare che una funzione isValidCard() applichi correttamente Luhn e riconosca il circuito dal prefisso, provandola su un Amex a 15 cifre e su un Mastercard che parte per 2221.
Mostrare in aula come funziona l'algoritmo di Luhn calcolando a mano il check digit e confrontandolo con quello prodotto dal generatore.
Riempire un database di sviluppo con centinaia di record fittizi per collaudare paginazione, ricerca e mascheramento dei numeri (es. 4539 **** **** 1234).
Simulare come il backend instrada verso processori diversi in base al BIN, generando un campione di numeri per ciascun circuito.
L'algoritmo che rende "valido" un numero di carta porta il nome di Hans Peter Luhn, ricercatore IBM che ne depositò il brevetto nel 1954 (concesso nel 1960). Non è un sistema di sicurezza: è un semplice controllo di parità pensato per intercettare gli errori di digitazione più comuni, come una cifra sbagliata o due cifre adiacenti invertite. Per questo è pubblico, banale da implementare ed eseguito ovunque, dai POS alle app.
La struttura del numero segue lo standard ISO/IEC 7812. La prima cifra è il Major Industry Identifier (4 e 5 storicamente per il settore bancario e finanziario), le prime 6-8 formano l'IIN/BIN che identifica l'emittente, seguono l'identificativo del conto e infine la cifra di Luhn. Ecco perché un generatore non può "inventare" liberamente: deve rispettare prefissi e lunghezze reali per superare la validazione.
Va ribadito il confine etico e legale: un numero Luhn-valido è comunque privo di autorizzazione. Nessun circuito approverà una transazione senza il riscontro con emittente, scadenza, CVV e fondi reali. Usare questi valori per test è legittimo; usarli per tentare pagamenti o ingannare qualcuno non è "un trucco che non funziona", è una frode.
No, in nessun caso. Sono validi solo nel formato: superano il controllo di Luhn e hanno prefissi corretti, ma non sono collegati ad alcun conto, banca o persona. Qualsiasi tentativo di pagamento viene rifiutato in fase di autorizzazione.
È un controllo matematico che verifica la coerenza di un numero di carta tramite una cifra finale (check digit). Serve a intercettare errori di battitura, non a garantire sicurezza. È lo stesso calcolo che i siti eseguono per bocciare subito un numero digitato male.
Servono per test di sviluppo, QA, mockup, didattica e per riempire database di prova. Permettono di collaudare form di pagamento e validatori senza usare dati reali di carte, evitando rischi di privacy e sicurezza.
I gateway come Stripe o PayPal forniscono carte di test dedicate (es. 4242 4242 4242 4242) che i loro ambienti sandbox riconoscono e "autorizzano". I numeri di questo generatore superano solo Luhn: sono ideali per i test lato client, ma nessun processore li approva.
No. Il CVV non è calcolabile dal numero: è un valore che l'emittente associa segretamente alla carta reale tramite chiavi proprie. La terzina o quaterna fornita ha solo la lunghezza corretta per riempire un campo, ma è del tutto inventata.
Generarli e usarli per test, sviluppo o studio è legittimo, perché non corrispondono a carte esistenti. Diventa illegale usarli per frodare, tentare pagamenti o ingannare persone e sistemi: l'intento fraudolento è ciò che la legge punisce.