Test credit card number generator
This tool produces fake, Luhn-valid card numbers for developers and QA engineers who need to exercise payment forms, validation logic, and sandbox checkouts without touching real card data. Pick a brand, choose how many you need, and copy structurally valid numbers complete with a random future expiry and CVC.
How it works
Each number is built from a real test BIN prefix for the chosen brand, padded to the brand’s length with cryptographically random digits (crypto.getRandomValues with rejection sampling to avoid modulo bias). The final digit is the Luhn (mod 10) check digit: every second digit from the right is doubled (subtracting 9 if over 9), all digits are summed, and the check digit is chosen so the total is divisible by 10 — the same test front-end validators run.
| Brand | Prefixes | Length | CVC |
|---|---|---|---|
| Visa | 4 | 16 | 3 |
| Mastercard | 51–55, 2221, 2720 | 16 | 3 |
| American Express | 34, 37 | 15 | 4 |
| Discover | 6011, 65 | 16 | 3 |
Example
Choosing Visa might yield 4929 9384 1057 2098 — it starts with 4, is 16 digits, and its last digit satisfies the Luhn checksum, so it passes a typical card-field validator. It is paired with a random expiry like 08/29 and a 3-digit CVC.
These numbers are not real cards: they hold no funds and can never be charged. Everything is generated in your browser and nothing leaves your device.
What the Luhn algorithm actually checks
The Luhn (mod 10) algorithm is not an encryption or fraud-detection system — it is a simple checksum that catches accidental typos. Here is how it works step by step:
- Starting from the rightmost digit (excluding the check digit), double every second digit going left.
- If doubling a digit gives a value over 9, subtract 9 (equivalent to summing the two digits of the double).
- Sum all digits including the unmodified ones.
- The check digit is the number that makes the total divisible by 10.
For example, 4929 9384 1057 without a check digit: working right to left, doubling positions 2, 4, 6… gives a running sum. The final digit is chosen to complete the checksum. This one arithmetic step is what every payment form’s client-side validator performs.
Luhn catches most single-digit transcription errors, but it cannot detect two adjacent transposed digits or random-number forgeries that happen to satisfy the formula — which is why banks add many more layers of validation at the processing stage.
When to use generated numbers vs official sandbox cards
Use these generated numbers for:
- Testing that your card input field correctly formats 16 digits with spaces.
- Checking that the CVC field accepts 3 digits for Visa/Mastercard and 4 for Amex.
- Verifying that the expiry field rejects past dates.
- Automated UI tests that need valid-looking card input without calling any API.
Use your payment gateway’s official test cards for:
- Testing the payment processor integration end-to-end.
- Triggering specific payment states (decline, fraud hold, 3DS challenge, successful charge).
- Any test that touches a real sandbox environment.
Stripe, for example, publishes a documented set of test card numbers for specific scenarios (4242 4242 4242 4242 for a successful charge, 4000 0000 0000 9995 to trigger a decline). These are on their allowlist; a randomly generated Luhn-valid number would simply return an error from their API even in test mode.
Privacy and security note
All generation happens inside your browser. The tool uses crypto.getRandomValues — the same source of randomness used by password managers and cryptographic libraries — rather than Math.random(), which is not suitable for security-sensitive generation. No numbers are logged, transmitted, or stored anywhere.