Credit Card Test Numbers

Two tools in one: the sandbox card numbers that Stripe, Braintree and Adyen actually document, filterable by provider and by the result each number is scripted to trigger, and a generator for random Luhn-valid numbers when you need plausible card data in bulk. Nothing on this page is a real card.

Sandbox lists vs. Luhn-valid randoms

Every "fake credit card number" you find online falls into one of two buckets, and mixing them up is the single most common reason a checkout test fails.

The first bucket is the documented sandbox lists. Stripe, Braintree and Adyen each publish a fixed set of numbers, and their test backends recognize exactly those. 4242 4242 4242 4242 succeeds in Stripe's test mode because Stripe's code contains that number, not because the digits have any property a random number lacks. The decline cards work the same way: 4000 0000 0000 9995 returns insufficient_funds because Stripe looks it up and answers with the scripted result. These numbers are the table in step 01, and the provider column matters, because a Stripe scenario card means nothing to an Adyen sandbox.

The second bucket is Luhn-valid randoms, which is what the generator in step 02 produces. These numbers carry a real brand prefix, the right length and a correctly computed check digit, so they get past every client-side check: the card form accepts them, your regex matches, your import pipeline treats them like card numbers. That is their entire job, and it makes them the right choice for seeding databases, validating forms, screenshots, demos and load fixtures.

What they will not do is authorize. A PSP sandbox compares incoming numbers against its documented list and declines everything else, and a live gateway forwards the number to an issuing bank that has never heard of it. So if you generated a random number and your sandbox declined it, nothing is broken; you brought a bucket-two number to a bucket-one problem. Take one from the table instead. This distinction is the reason both halves sit on one page.

Why test numbers exist at all

PCI DSS is blunt about it: requirement 6.5.5 of version 4.0 forbids live PANs in pre-production environments. The logic is scope. Any system that stores, processes or transmits real card numbers falls under the full compliance regime, with the access controls, logging and audits that entails, and a staging database full of production card data is a cardholder-data breach waiting to happen in the least protected part of your infrastructure. Test numbers let every environment below production stay out of scope entirely.

The habit is older than PCI. Numbers like 4111 1111 1111 1111 have been printed in processor integration guides since the nineties, long enough that fraud systems recognize them on sight, and the brands' IIN ranges leave room for numbers that no issuer will ever assign. When Stripe arrived it picked 4242 4242 4242 4242, easier to type and to remember, and a decade of tutorials made it the best-known card number in the world. Keep exactly one success card per provider in your test fixtures and name the constant after the provider, because a fixture called VALID_CARD that quietly means "valid in Stripe test mode" is how the wrong number ends up in an Adyen test suite.

How to use this page

The table is the part you will use most. Filter by provider and by result, click a row, and the bare digits land in your clipboard without spaces, ready for a card form. Note that the same number can appear under several providers: 4111 1111 1111 1111 succeeds in both the Braintree and Adyen sandboxes and is also the classic network test number, while Stripe went its own way with 4242 4242 4242 4242.

The generator takes a brand, a count up to 100 and an output format. Plain gives one card per line with number, expiry, CVC and brand; --json emits an array of objects with brand, number, exp and cvc keys; --csv produces the same columns under a header row, ready for a spreadsheet or a fixture file. Every number is built from crypto.getRandomValues, gets a correct Luhn check digit, an expiry 6 to 48 months in the future and a CVC of the right length, four digits for Amex, three for everyone else. Click a row to copy it in the selected format, or download the whole batch. If you need entire fake user records around the card, our test data generator builds the names, addresses and emails to match.

Testing declines and 3D Secure on purpose

A checkout that has only ever seen successful payments is untested. The paths that break in production are the failures: what your UI shows on insufficient_funds, whether your retry logic treats processing_error differently from generic_decline, what your session does when 3D Secure interrupts the redirect flow. Scenario cards exist so you can walk each of those paths deliberately instead of waiting for a customer to find them.

Stripe's testing docs assign each failure its own number, and the table above carries the ones you will reach for weekly: generic decline, insufficient funds, lost card, expired card, wrong CVC and a processing error. One of them deserves a special mention: 4242 4242 4242 4241 fails the Luhn check on purpose. It never reaches Stripe's decline logic because a correct card form rejects it locally, which makes it the number for testing your client-side validation, and the one row in our table a Luhn checker should flag as invalid.

For 3D Secure, 4000 0025 0000 3155 requires authentication on one-time payments, the common case, while 4000 0000 0000 3220 forces the full 3DS2 challenge window on every charge. In test mode the challenge is a stub with complete and fail buttons, so both outcomes of the authentication are one click away.

Braintree scripts most declines through the amount instead of the number: in its sandbox, a transaction amount between 2000.00 and 2999.99 is declined with the processor response code matching the amount, so charging 2001.00 to a valid test card yields code 2001, insufficient funds. That design surprises people coming from Stripe, where the number decides, and it is why the Braintree section of the table is shorter; the decline matrix lives in the amount, not in extra cards.

Brand prefixes, lengths and CVCs

The first digits of a card number are not random. The leading digit is the Major Industry Identifier, and the first 6 to 8 digits form the Issuer Identification Number (IIN, colloquially the BIN), which is how terminals and gateways route a card to its network and bank. ISO/IEC 7812 defines the scheme; the ranges below are the ones the generator uses, together with the most common length and CVC size per brand:

Two details trip up validators regularly. Mastercard's 2-series (2221 to 2720) was activated in 2017, and regexes written before that still reject 2223 0031 2200 3222, which is exactly why Stripe includes a 2-series number in its test list. And Amex is the double outlier, 15 digits and a 4-digit code, so a form that hard-codes 16 and 3 fails on a top-four brand. The generator sticks to the most common shape per brand (16 digits for Visa, 14 for Diners) because that is what almost every validator expects; if yours needs the exotic lengths, that is a deliberate edge case worth its own fixtures.

The Luhn check, briefly

The last digit of every card number is a check digit computed with the Luhn algorithm, patented by IBM's Hans Peter Luhn in 1960: walk the digits from the right, double every second one, subtract 9 from any result above 9, add everything up, and a valid number leaves a sum divisible by 10. The point is typo detection, not security. It catches every single-digit mistype and nearly every swap of adjacent digits before an API call is wasted on them, and it means exactly one in ten random digit strings validates by accident. The generator computes the check digit for each number it builds, which is what separates its output from mashing the number row. For the step-by-step math, worked examples and the IMEI variant of the same checksum, our Luhn checker is the dedicated page, and it will also tell you which digit to fix in an almost-valid number.

Expiry and CVC conventions

Sandboxes are deliberately lax about the fields around the number. Stripe and Braintree accept any future expiry and any CVC of the right length, which is why 12/34 and 123 show up in every tutorial screenshot; there is nothing special about those values beyond being easy to type. Adyen is the strict one: its test cards are documented with expiry 03/2030 and CVC 737, 7373 for Amex, and some flows verify them, so an Adyen test that declines on an otherwise correct card is often just a wrong CVC.

The generator always emits an expiry between 6 and 48 months out, so a batch never contains an already-expired card, and a CVC of the brand-correct length with leading zeros preserved. If a downstream system trims a CVC of 042 to 42 somewhere between the fixture file and the assertion, you have found a real bug, the same class of leading-zero loss that eats phone numbers and postal codes in spreadsheets.

What happens on a live gateway

Type a test number into a real checkout and the authorization request travels through the acquirer to the card network, which routes by BIN toward an issuing bank. For a test number there is no account and usually no issuer behind the BIN, so the answer comes back as a decline, typically invalid card number or do-not-honor, in under a second. No money can move, because there is nothing to move it from; the number is a key that opens no door.

The real-world risks are of a different kind. Repeated attempts with made-up numbers are indistinguishable from BIN probing, an actual fraud technique for discovering valid card ranges, so fraud systems block the source quickly, and a merchant testing against their own live keys can flag their own account. Depending on acquirer pricing, even declined authorization attempts can show up as per-transaction fees on the merchant's bill. All of which is avoidable by doing the intended thing: point your integration at the sandbox, use the documented cards for behavior and the generated ones for data, and let live keys see nothing but real customers.

Test card questions