Credit Card Number Generator

Generate valid test credit card numbers by brand.

Brand

Count (1-50)

0 numbers

Cards Generated: 0Brand: VISA

Test card numbers, not real cards

These numbers use real brand prefixes and pass Luhn algorithm checks for testing purposes.

Built and maintained by Meet Shah · Last updated 28 July 2026

What this tool is used for

Producing test numbers that pass a Luhn check for a payment integration.
Generating input to exercise brand detection from a prefix.
Filling a fixture with numbers of different brands and lengths.
Testing a form's validation without using a real card.
Producing values to check that a field masks and stores them correctly.

How it works in practice

A worked example

A QA engineer is testing a checkout form in a staging build and needs card numbers that clear the form's own Luhn and brand checks before anything is sent to the payment sandbox.

Input

Brand          Mastercard
Count (1-50)   4

Output

5135873081276997
5406749090958787
5360543717591277
2699066745843220

Four numbers, one per line, sixteen digits each and no spaces, which is the bare form a field's validator sees once it has stripped whatever separators the user typed. Each starts in one of Mastercard's two issuer series, picked at random: a 5 followed by a digit from 1 to 5, or a four-digit prefix from 2221 to 2720, like the 2699 on the last line. The rest are random digits except the last, which is not random at all: it is computed so that the Luhn total comes out a multiple of ten, so exactly one of the ten possible final digits passes. Change any single digit of any line and the check fails, so the same list tests both halves of a validator, accepting a well-formed number and rejecting a mistyped one. Every generate draws a fresh set; the list above is one real run.

The edge case that catches people

Each number picks its range independently, so a short run can miss one. Mastercard's two series are equally likely, which means all four of a four-number run come from the same series one time in eight; Discover draws from 6011, 644 to 649 and 65, and a run of four leaves at least one of those three out more often than not. Generate twenty or more before concluding that a brand detector copes with every range. Length is fixed per brand, too: Visa and Discover numbers always come out at sixteen digits, although both networks also issue nineteen-digit cards, so a validator that caps the field at sixteen passes every number here.

When not to use this tool

Anything past your own validation layer. Once a request reaches a payment provider these numbers stop being useful: Stripe's test mode, for one, answers a number that is not on its published test list with a decline saying the request was in test mode but used a non test card. The subtler trap is logic keyed on the issuer. After the brand prefix the digits are random, so a generated Visa can land in a range a real bank owns, and a BIN lookup that shows the issuer, the country or debit versus credit will describe that bank's card rather than a test fixture.

Frequently Asked Questions

Are these real card numbers?: No. They are syntactically valid — correct length, correct issuer prefix, passing the Luhn check — but they correspond to no account and will be declined by any real payment processor. They exist to exercise validation code.
What is the Luhn algorithm?: A checksum from 1954: double every second digit from the right, subtract 9 from any result over 9, sum everything, and a valid number is divisible by 10. It catches single-digit typos and most adjacent transpositions — its actual purpose.
What do the leading digits mean?: The issuer identification number: 4 is Visa, 51-55 and 2221-2720 Mastercard, 34 and 37 American Express (15 digits, not 16), 6011, 644-649 and 65 Discover. Validators use these to identify the network before the Luhn check.
Should I use these to test a payment gateway?: No — use the gateway's OWN published test numbers (Stripe's 4242 4242 4242 4242, for instance). Those trigger defined sandbox behaviours including specific decline reasons, which a generic Luhn-valid number cannot.
Is generating these legal?: Generating Luhn-valid digit strings for testing is legitimate and routine. Using one in an attempt to obtain goods or services is fraud regardless of whether it succeeds — the tool is for validating your own forms.
Why do the leading digits matter?: They are the issuer identification number, identifying the bank and network — and the standard expanded from six digits to eight in 2022 because six ran out. That prefix is what lets a checkout show the right card logo before the number is finished.
What should a test suite use instead?: The processor's documented test cards, because each triggers a specific outcome — approval, decline, insufficient funds, a 3-D Secure challenge. A merely Luhn-valid number produces one behaviour, and it is not one worth asserting against.
Why do the test numbers differ between payment providers?: Because each provider defines its own sandbox set, often with numbers that trigger specific outcomes — a decline, an expired card, a fraud flag. Using another provider's numbers gets you a generic rejection rather than the case you meant to test.

Common errors and gotchas

Attempting to use a generated number for a real transaction, which will simply be declined.
Assuming a Luhn-valid number is a usable test card, when gateways publish their own specific test numbers.
Storing generated numbers in a system that treats them as real cardholder data.
Testing only 16-digit numbers, so 13, 15 and 19 digit brands go unhandled.
Confusing a valid checksum with a valid account, which it never implies.