Test Credit Card Generator
Generate valid Luhn-check test card numbers for developer testing only.
About the Test Credit Card Generator
These are test card numbers only. This generator produces mathematically valid credit card numbers that pass the Luhn checksum (ISO/IEC 7812-1) but are not tied to any real account, real bank, or real person. They are intended exclusively for QA testing of e-commerce checkout flows, form-validation logic, and payment-gateway sandbox environments such as Stripe’s test mode.
The Luhn algorithm — invented by IBM’s Hans Peter Luhn in 1954 — is a Modulo-10 checksum that catches single-digit transcription errors and most adjacent-digit transpositions. Every Visa, Mastercard, American Express, and Discover number in circulation ends with a check digit computed by Luhn over the prior digits. This generator applies the same algorithm to random digits to produce numbers that look real to client-side validators but cannot be used for actual purchases.
The numbers are generated with crypto.getRandomValues so each draw is unpredictable. Network prefixes (Visa 4, Mastercard 51–55, Amex 34/37, Discover 6011) are taken from the official ISO/IEC 7812-1 Issuer Identification Number ranges — the same ranges your bank uses to identify card networks.
How It Works
For each card, the generator picks a network-appropriate prefix (e.g. 4 for Visa), appends length - prefix.length - 1 random digits drawn from crypto.getRandomValues, then computes the final Luhn check digit and appends it.
The Luhn algorithm walks the digits from right to left, doubling every second digit. If a doubled digit exceeds 9, we subtract 9 (equivalent to summing the digits of the doubled value). The check digit is the value that makes the total sum divisible by 10: check_digit = (10 - (sum mod 10)) mod 10. The modulo on the outside handles the case where the sum is already divisible by 10, giving check digit 0.
Network prefixes follow ISO/IEC 7812-1: Visa uses a single 4 prefix and a 16-digit total length, Mastercard uses 51–55 at 16 digits, American Express uses 34 or 37 at 15 digits, and Discover uses 6011 at 16 digits. Amex formats differ in grouping (4-6-5) versus the standard 4-4-4-4 grouping for other networks.
The format selector outputs the same digits in spaced, plain, or dashed notation. Spaced format matches what most checkout forms display as the user types; dashed matches the legacy convention used by some payment gateways; plain is what you would paste into a CSV for bulk testing.
Worked Examples
A Visa test card (16 digits, prefix 4): 4123 5678 9012 3456. The first digit identifies Visa (Major Industry Identifier 4 = banking). The next 5 digits are the Issuer Identification Number, the following 9 are the individual account identifier, and the final 6 is the Luhn check digit. Pass this into Stripe’s test mode and the API accepts it without charging a real account.
A Mastercard test card (prefix 51-55): 5311 1111 1111 1111. Run the Luhn check: 5×2-9 + 3 + 1×2 + 1×2 + 1 + 1×2 + ... = 70, divisible by 10 — valid. A typo like 5311 1111 1111 1112 fails the check.
An American Express test card (15 digits, prefix 34/37, format 4-6-5): 3782 822463 10005. Stripe documents this exact number as one of their official Amex test cards; generating a fresh one produces a different number that equally passes Luhn.
When to Use This Tool
- QA testing of e-commerce checkout forms to verify validation logic catches invalid Luhn checksums.
- Stripe, Adyen, Braintree, and PayPal sandbox testing with their documented test card ranges.
- Demo environments for sales presentations where real card data must never appear.
- Load-testing payment APIs without risking real account holds or chargebacks.
- Developer training on PCI-DSS scope reduction by using synthetic numbers in non-production environments.
- Penetration-testing form validation logic for bypass attempts (e.g. Luhn-valid but non-routable numbers).
- Documentation and tutorials showing example card numbers without exposing real customer data.
Limitations & Disclaimer
These are test card numbers only and must never be used for real purchases. The numbers pass the Luhn checksum (ISO/IEC 7812-1) but are not tied to any real account, real bank, or real person. Using generated card numbers for actual transactions is credit card fraud, illegal under 18 U.S.C. §1029 (US), the Fraud Act 2006 (UK), and equivalent statutes worldwide. This tool is for QA testing of e-commerce validation logic, payment-gateway sandboxes, and developer training only. CVV codes cannot be generated — they are cryptographically derived from the PAN and the issuer’s secret key. Always use the gateway’s documented test cards (e.g. Stripe’s 4242 4242 4242 4242) for integration testing. See our disclaimer for full terms.
Frequently Asked Questions
Are these credit card numbers real?
No. They are mathematically valid (pass the Luhn checksum) but are not tied to any real bank account, real person, or real credit limit. They cannot be used for actual purchases. Using generated card numbers for real transactions is fraud and is illegal in every jurisdiction. Use them only in payment-gateway sandbox environments.
What is the Luhn algorithm?
Luhn (also called Modulo-10) is a checksum algorithm invented by IBM’s Hans Peter Luhn in 1954 and standardized as ISO/IEC 7812-1. Walk digits right-to-left, double every second digit, subtract 9 if the result exceeds 9, sum all digits, and the total must be divisible by 10. It catches all single-digit errors and most adjacent transpositions.
Will these numbers pass Stripe or PayPal test mode?
Some will, but Stripe and PayPal publish their own specific test card numbers (e.g. <code>4242 4242 4242 4242</code> for Visa) that their sandbox recognizes. Random Luhn-valid numbers will pass client-side validation but may be rejected by sandbox backends that maintain an allow-list. Always use the gateway’s documented test numbers for integration testing.
Is generating credit card numbers illegal?
Generating Luhn-valid numbers is not itself illegal — the algorithm is public knowledge and is taught in computer science courses. Using generated numbers to attempt actual purchases, fraud, or identity theft is illegal under 18 U.S.C. §1029 (US), the Fraud Act 2006 (UK), and equivalent statutes worldwide. This tool is for legitimate QA testing only.
Why do real card numbers pass Luhn?
Because every issuing bank computes the check digit using the same algorithm before shipping the card. Luhn is a typo-detection mechanism, not an anti-fraud measure — it stops cashiers from mistyping the last digit, not attackers from generating valid-looking numbers. Anti-fraud protection comes from CVV, AVS, 3-D Secure, and the issuer’s risk engine.
What about CVV and expiration date?
This tool generates only the card number (PAN). CVV is a 3- or 4-digit code cryptographically derived from the PAN and the bank’s secret key — it cannot be computed without that key, so it cannot be generated by any tool. Expiration dates are arbitrary future dates set by the issuer. For sandbox testing, use the CVV <code>123</code> (Visa/MC) or <code>1234</code> (Amex) and any future date.
Last updated: September 9, 2026 · Author: HT99 Tools Editorial Team