Test Credit Card Number Generator

Luhn-valid card numbers drawn only from the networks' published test ranges, so nothing generated here is an account anybody holds, plus a Luhn checker.

Live output

Enable JavaScript to customise; default output below.

Any future date works in a gateway's test mode. It is not part of the number and Luhn does not check it.

Live preview test-cards.txt
Numbers are drawn in your browser when the page loads.

Network            Visa
How many           6
The canonical one
  Visa             Stripe and most gateways publish 4242 4242 4242 4242
  which is         the number to use when a gateway asks for a specific test card, since its documentation pins the behaviour

Every number here starts from a published test prefix for Visa, so none
of them is an account anybody holds. A live gateway declines them; a
gateway's test mode accepts them. That is the difference between a test
card generator and a card number generator, and it is the reason this
one only draws from those ranges.

Luhn is a checksum, not a secret. It catches a mistyped or transposed
digit and nothing else, so a Luhn-valid number is a number that is
internally consistent. Validating a card properly means asking the
gateway, which is the only thing that knows.

Use your gateway's own published test numbers when the test needs a
specific outcome. Stripe, Adyen, PayPal and the rest each publish
numbers that force a decline, an insufficient funds response, a 3D
Secure challenge or a fraud block, and a randomly generated number gets
you none of that.

Never put a real card number in test data, a fixture, a screenshot or a
bug report, including your own. It is the fastest route to a PCI
incident, and a number in a repository stays there in the history after
it is deleted.

The expiry and security code are not checked by Luhn and are not part of
the number. Any future expiry works in test mode, and a gateway that
asks for a specific security code publishes which one.

The first six to eight digits are the issuer identification number,
which identifies the network and the issuing bank. That is why a form
can tell you it is a Visa before you finish typing, and why these
prefixes are the part that has to come from a reserved range.

A number that passes Luhn and starts with a real issuer prefix may
belong to somebody. That is exactly what this tool avoids generating,
and it is worth checking before using any other generator.

Output is valid and updates as you type.

A random sixteen-digit string is almost never a card number, because the last digit is a Luhn checksum. So a generator that produces Luhn-valid numbers at random produces numbers that look exactly like accounts issued to real people, and those end up in fixtures, in screenshots, in bug reports and occasionally in a live payment attempt.

Everything here starts from a prefix the card networks publish as a test range: 4111 11, 4242 42, 3782 82 and the rest, the numbers that appear in every payment gateway’s documentation. No issuer holds them. A live gateway declines them. Only a gateway’s test mode accepts them.

The other half of the tool is the checker, because Luhn is a checksum for catching a mistyped digit and nothing more. It tells you the digits are internally consistent. It does not tell you a card exists, has funds, or belongs to the person typing it.

How to use

  1. Pick the network and how many numbers you need. They are drawn in your browser, not on a server.
  2. Keep the grouping on to see the numbers the way the network prints them, which is four-six-five for American Express rather than four-four-four-four.
  3. Paste a number into the checker to test its checksum, and to see which last digit would make it consistent.

Example

Six Visa test numbers with security codes:

Network                       Visa, 16 digits
Security code                 3 digits
Expiry to use                 12/34, or any date in the future

Numbers
  4111 1114 7913 1925         cvv 358
  4111 1118 7812 7508         cvv 080
  4111 1117 2115 1788         cvv 918

The canonical one
  Visa                        Stripe and most gateways publish 4242 4242 4242 4242
  which is                    the number to use when a gateway asks for a specific test card

Checking the number you gave
  digits                      16
  Luhn                        not consistent
  would be consistent         if the last digit were 1
  what that means             a digit is wrong or transposed, which is exactly what the checksum is for

The last block is the useful half for anybody debugging a payment form: a number that fails Luhn failed before it ever reached the gateway, which usually means a typo rather than a decline.

Pitfalls

Never put a real card number anywhere in a codebase. Including your own, including in a comment, including in a screenshot attached to a ticket. A number in git history stays there after the file is deleted, and it is the fastest route to a PCI incident.

Luhn validity is not validity. It is a check for transcription errors. Any number can be made Luhn-valid by changing its last digit, which is what this tool shows you.

Use your gateway’s published numbers for specific outcomes. Stripe, Adyen, PayPal and the rest publish numbers that force a decline, insufficient funds, a 3D Secure challenge or a fraud block. A randomly generated number gets you none of those behaviours.

Test numbers only work in test mode. With live keys they are declined, which is the intended behaviour and occasionally a confusing hour if the environment is not what you thought.

The expiry and security code are not part of the number. Luhn does not check them. Any future expiry is accepted in test mode, and a gateway that requires a specific security code says so.

Do not store test card numbers in a real customer record. They look like card numbers to every other system that touches them, including analytics, logs and support tooling.

Card numbers are personal data. Even a partly masked one. Treat anything that looks like a PAN as something that should not be in a log line.

Compatibility

Runs in the browser: nothing is uploaded, and the numbers are drawn from the browser’s own cryptographic random source rather than from a server or from Math.random.

Because the numbers are random, the page renders a placeholder at build time and draws real ones when it loads. That is deliberate: a number baked into the published HTML would be the same for everybody and would end up copied into more places than it should.

The Luhn implementation and the prefix table are tested against the numbers the gateways publish, which is the only meaningful check: 4111 1111 1111 1111, 4242 4242 4242 4242, 5555 5555 5555 4444, 3782 822463 10005 and the rest all have to pass, and a single changed digit has to fail.

Lengths follow the networks: 16 digits for Visa, Mastercard, Discover and JCB, 15 for American Express, 14 for Diners Club, with a three or four digit security code to match.

Frequently asked questions

Are these real card numbers?
No. They start from prefixes published as test ranges and no issuer has assigned them. They are valid in the sense that the checksum works, which is what a payment form’s front-end validation checks.
Will they work on a live site?
No, and that is the point. A live gateway declines them. They work in a gateway’s test or sandbox mode.
What is the Luhn algorithm?
A checksum from the 1950s that catches most single-digit errors and most transpositions. Double every second digit from the right, subtract nine from anything over nine, add it all up, and a valid number is divisible by ten.
Why does my form reject a generated number?
Usually because the form checks the prefix against a stricter list, or because the gateway is in live mode. Check the network the number belongs to and which keys the environment is using.
Can I use these for anything other than testing?
No. Attempting to use any card number you are not authorised to use is fraud, whether or not it exists. These are for test suites, form validation and documentation.
Weekly drops

New tools, when there are new tools

One email when something worth using ships. No schedule to fill, so no filler.

Your address goes nowhere else, and one click unsubscribes.