A fake credit card generator produces card numbers that are correctly formatted and pass the Luhn check-digit test, so they flow through validation logic the same way a real number would — but they belong to no account and can never be charged. Use them to test checkout forms, payment SDK integrations, and fraud rules in sandbox environments.
How it works
Each number is built to match its brand and then closed out with a valid checksum:
- The chosen brand fixes the IIN prefix and total length: Visa
4/ 16 digits, Mastercard51–55/ 16, American Express34or37/ 15, Discover6011/ 16. - The middle digits are filled randomly up to one short of the full length.
- The final check digit is computed with the Luhn algorithm: double every second digit from the right, subtract 9 from any result over 9, sum everything, and choose the last digit that makes the total a multiple of 10.
A random future expiry and a random CVV (three digits, four for Amex) round out a complete test record.
Example
For a Visa number 4xxxxxxxxxxxxxxc, the generator picks the first 15 digits, runs Luhn over them, and sets c so the whole 16-digit number checksums to a multiple of 10. You can paste the result into any Luhn validator and it will report valid.
Notes
These are deliberately non-functional. Major networks also publish official test numbers (such as 4242 4242 4242 4242) for sandbox use; this tool gives you an endless supply of fresh, Luhn-valid alternatives for local testing.
When to use generated numbers vs network-provided test numbers
Payment processors like Stripe, Braintree, and Adyen publish their own dedicated test card numbers that trigger specific behaviors in their sandbox environments — for example, a number that always declines, one that simulates a 3DS challenge, or one that produces a particular error code. Those official numbers are the right choice when you are testing processor-specific scenarios within a connected sandbox.
Generated Luhn-valid numbers from this tool serve a different purpose: they exercise the client-side validation layer of your own code before the request ever reaches a payment gateway. If your checkout form validates the Luhn checksum and rejects mismatched IIN prefixes before making an API call, you can test that logic locally with these numbers, without needing a sandbox connection or network request. They also work for populating test fixtures in unit tests and in database seed files where the payment processor is mocked.
The Luhn algorithm step by step
For a 16-digit number like a Visa card, starting from the second-to-last digit and moving left, double every other digit:
Original: 4 5 3 9 1 4 8 8 0 3 4 3 6 4 8 ?
Step 1: 8 5 6 9 2 4 16 8 0 3 8 3 12 4 16 ?
Step 2: 8 5 6 9 2 4 7 8 0 3 8 3 3 4 7 ?
(Step 2: subtract 9 from any doubled value that exceeds 9.)
Sum all the digits: 8 + 5 + 6 + 9 + 2 + 4 + 7 + 8 + 0 + 3 + 8 + 3 + 3 + 4 + 7 = 77. The check digit ? is the number that makes the total a multiple of 10, so ? = 3 (77 + 3 = 80). The generator performs exactly this computation to produce the final digit.
Brand IIN prefixes and lengths
| Brand | IIN prefix | Total length |
|---|---|---|
| Visa | 4 | 16 digits |
| Mastercard | 51 – 55 | 16 digits |
| American Express | 34 or 37 | 15 digits |
| Discover | 6011 | 16 digits |