Credit Card Number Generator

What is a credit card generator used for?

E-commerce developers and folks working with payment gateways often need card numbers valid under the Luhn algorithm. Those are what feed the tests for checkout forms, front-end validations and payment API integrations in sandbox.

The generated numbers pass the Luhn check, but they are entirely fictitious. None of them matches a real card, and you cannot use them in transactions.

For testing and development use only. Using these numbers for fraud is a crime.

The Luhn algorithm and the anatomy of a credit-card number

Every credit-card number printed on a piece of plastic — or stored in your wallet app — follows the same international layout described in ISO/IEC 7812. The number is split into three parts. The first six (lately eight) digits form the BIN/IIN (Bank Identification Number / Issuer Identification Number) and encode the network and the issuing bank. The middle block is the account identifier, assigned by the issuer. The very last digit is a check digit calculated by the Luhn algorithm, also known as modulo 10. Without that final digit, any single typo on a payment form would be impossible to catch before the network request.

The algorithm was designed by Hans Peter Luhn, a researcher at IBM, in 1954 and published as US patent 2.950.048 in 1960. Luhn intentionally placed it in the public domain, which is why it is now the universal check used not just by Visa, MasterCard and Amex, but also by IMEI numbers, US National Provider Identifiers and the Canadian Social Insurance Number.

How the Luhn check is computed

1. Take the card number and read its digits from right to left.
2. Double every second digit (positions 2, 4, 6 … counting from the right).
3. If doubling produces a two-digit result, sum its digits — equivalent to subtracting 9 (e.g. 8 × 2 = 16 → 1 + 6 = 7).
4. Add all the transformed digits together.
5. The number is valid if the total is divisible by 10.

To generate a Luhn-valid number, choose all digits except the last, run the algorithm with a 0 placeholder, and set the last digit to whatever value makes the sum a multiple of 10. That is exactly what this tool does for the brand you pick.

BIN ranges by brand

• Visa — starts with 4; 13, 16 or 19 digits.
• MasterCard — historical range 51-55 plus the modern 2221-2720 block opened in 2017; always 16 digits.
• American Express — 34 or 37; 15 digits with a 4-digit CID instead of a CVV.
• Discover — 6011, 65, plus selected sub-ranges; 16-19 digits.
• Diners Club — 300-305, 36, 38; 14-19 digits.
• JCB — 35 (3528-3589); 16-19 digits.
• Elo — brand from Brazilian Bradesco/Banco do Brasil/Caixa, with multiple specific BINs (4011 78, 4576 31, 5066, 5067, 6362 97…); 16 digits.
• Hipercard — Brazilian, BIN 606282; 16 or 19 digits.

Beyond Luhn: PCI-DSS, tokenisation, EMV and 3-D Secure

Luhn proves only that the number is well-formed. It says nothing about whether the card exists, has funds, or is yours. The real authorisation flow runs over three additional layers. PCI-DSS (Payment Card Industry Data Security Standard) defines how merchants must store, transmit and protect any portion of the card data; storing the full PAN almost always requires tokenisation, where the original number is replaced by a surrogate kept inside a hardened vault. EMV chips (named after Europay, MasterCard, Visa) carry an asymmetric-cryptography key pair that signs each transaction, so a cloned magnetic stripe is much less useful than it was a decade ago. 3-D Secure (Verified by Visa, MasterCard SecureCode, Amex SafeKey) adds a second-factor challenge for the cardholder on card-not-present transactions, shifting the chargeback liability from the merchant to the issuer.

Legitimate uses for generated numbers

Generated numbers are designed for environments where the network never sees them: unit tests of form validators and checkout flows, mock data for screenshots and demos, integration tests against payment-gateway sandboxes (Stripe, Adyen, Cielo, Pagar.me, Mercado Pago, Stone). Sandboxes typically publish their own dedicated test BINs (e.g. 4242 4242 4242 4242 for Stripe) and you should prefer those when integrating — they trigger deterministic success, decline or 3DS responses.

Strong warning

Submitting a Luhn-valid number to a real production payment system in an attempt to authorise a purchase, sign up to a paid service, or open a credit application is fraud. In Brazil it falls under Código Penal art. 171 (Estelionato) and the specific subsection 171, §2-A on electronic device fraud, with penalties of four to eight years of prison; in the US it is criminalised by 18 U.S.C. § 1029; in the EU by national implementations of Directive 2019/713. Most networks also run velocity and behavioural detection that flag invalid attempts to issuers and law enforcement.

FAQ

Why do all my test cards still get declined in the sandbox? Because gateways match against their own test BINs, not against the algorithm. Use the BIN published in the gateway documentation — Stripe's 4242…, Adyen's 4111…, Pagar.me's 4242…, and so on.

Does this generator also produce a valid CVV and expiry? No. The CVV/CVC2 is computed by the issuer from the PAN, a service code and a secret key (card verification key) the network never publishes. Expiry is assigned freely by the issuer. Sandboxes accept any well-formatted CVV and any future expiry date.

Why is Amex 15 digits while everyone else is 16? Historical. American Express launched its proprietary network in 1958 and standardised on 15 digits before the ISO 7812 family was harmonised. The shorter PAN is paired with a longer 4-digit CID printed on the front of the card.

Is Luhn cryptographically secure? No — it is a checksum, not a hash or signature. A determined attacker can trivially produce a Luhn-valid number; security against fraud comes from EMV, 3DS and the issuer's anti-fraud engine, not from the check digit.