Test Credit Card Number Generator
Generate Luhn-valid fake card numbers for testing, not real purchases.
About this tool
These are fabricated numbers for software testing. They are not issued by any bank, are linked to no account, hold no funds, and cannot be used to pay for anything. Every real payment processor rejects them. The tool exists so developers and QA testers can fill in a checkout or card-validation form without typing a real card number.
What it produces. A card number that (a) starts with the correct issuer identification number range for the network you pick, (b) has the right length (15 digits for American Express, 16 for the rest), and (c) passes the Luhn checksum. Optionally a random future expiry date and a format-correct CVV (3 digits, or 4 for Amex). That's exactly the set of things a front-end validator checks — so a correct validator accepts these, and a buggy one is caught.
The Luhn algorithm. Every real card number ends in a check digit computed so that, doubling every second digit from the right (and subtracting 9 from any result over 9), the digits sum to a multiple of 10. It catches most single-digit typos and adjacent transpositions before a request ever leaves the browser. Passing Luhn is necessary for a real card but nowhere near sufficient — it says nothing about whether a bank issued the number or whether it has funds. The card validator runs the same check the other way.
A worked example. Take the partial number 453210000000000 (15 digits, still needing a 16th check digit). Counting from the right, every second digit gets doubled (subtracting 9 if that exceeds 9): the 1st, 3rd, and 5th digits from the left — 4, 3, and 1 — double to 8, 6, and 2. The 2nd and 4th digits (5 and 2) are left alone, the run of zeros contributes nothing either way, and the check digit itself is never doubled. That gives 8 + 5 + 6 + 2 + 2 + 7 = 30 once the check digit 7 is included — a multiple of 10, so 4532 1000 0000 0007 passes Luhn. This is exactly what computeCheckDigit() in this tool's code does for every network's prefix.
Issuer identification number (IIN) ranges used here:
| Network | Starts with | Length |
|---|---|---|
| Visa | 4 | 16 |
| Mastercard | 51–55 | 16 |
| American Express | 34, 37 | 15 |
| Discover | 6011, 65 | 16 |
| Diners Club | 300–305, 36, 38 | 14 |
| JCB | 35 | 16 |
Legitimate uses. Unit tests and fixtures for payment code; exercising a checkout form's validation, formatting, and error states; QA scripts; demo and screenshot data; load-testing a validation service. For actually simulating a charge, use the dedicated test card numbers your payment provider publishes (Stripe's 4242 4242 4242 4242, and the equivalents from Adyen, Braintree, PayPal, etc.) in their sandbox — those trigger specific gateway behaviours that a generic Luhn-valid number can't.
What this is not. It is not a "working" card generator, it does not produce numbers tied to real accounts, and there is no CVV-guessing or card-checking function here. Using fabricated card details to attempt a real transaction, or to test whether stolen numbers are live, is fraud. This tool is for testing your own software with disposable data.
Everything runs in your browser. No number is generated on or sent to a server, and nothing is stored.
For other placeholder test records, see the test IBAN generator, fake name generator, and mock data generator.
Frequently asked questions
- Can these numbers be used to make a real purchase?
- No. They pass the Luhn checksum, but no bank issued them and they map to no account. Any real payment gateway declines them.
- What is the Luhn algorithm?
- A checksum that catches typos in a card number. The last digit is set so a specific weighted sum of all digits is divisible by 10. It's a format check, not proof a card is real or funded.
- Why include a fake expiry and CVV?
- Many checkout forms won't submit until all three fields are filled, so testing the full validation path needs them. They're random and format-correct only.
- Should I use these or my payment provider's test cards?
- For form validation and formatting, either works. For simulating an actual authorisation, decline, or 3-D Secure challenge, use your provider's published sandbox test numbers — they trigger defined gateway responses.
- Is generating these legal?
- Yes, for testing software. Using any fabricated or real card details to attempt a transaction you're not authorised to make is fraud.
- Does the tool check or validate real cards?
- No. It only generates format-valid test data. There is no lookup, no "card checker", and nothing leaves your browser.
- What do the graphical cards show, and are they based on a real design?
- Each generated number is also rendered as a generic card mockup — network label, chip icon, number, expiry, and CVV — purely so a batch of results is easier to scan than a wall of digits. They're deliberately generic layouts, not a copy of any specific bank's or network's actual card design.
- Why is the cardholder name always "TEST CARDHOLDER"?
- This tool only fabricates the card number, expiry, and CVV — the fields an issuer actually controls. It doesn't generate a fake person to go with them; pair it with the fake name generator if a form also needs a name.