Test credit card numbers

What the field emits

The Credit Card # field draws from the four canonical test numbers that payment gateways publish for exactly this purpose:

4111111111111111    Visa
5555555555554444    Mastercard
378282246310005     American Express
6011111111111117    Discover

These are not randomly generated numbers that happen to satisfy the Luhn check — they are the specific values Stripe, Braintree, Adyen and others document as test cards. Every payment sandbox recognises them; no real account exists behind any of them.

That is a deliberate limitation. A generator that produced arbitrary Luhn-valid numbers in real issuer ranges would be producing numbers that could belong to somebody, and there is no legitimate testing reason to want that. Four values is enough to exercise a card-type detector, a form validator and a checkout flow.

Building a checkout fixture

Card number alone is rarely the whole test. A useful payment fixture pairs it with:

• Credit Card Type — the brand label, for checking your detection logic agrees with the number.
• Date with a future range and MM/yyyy-style handling — expiry.
• Pattern ### — CVV, or #### for Amex.
• Price and Currency Code — the amount being charged.
• Full Name — cardholder, which should not match the account name in every row if you want to test that path.

Export the lot as JSON for a mock payment endpoint or CSV for a data-driven checkout test.

Declines are the interesting half

A checkout that works with a successful card is the easy case. What breaks in production is the decline path: insufficient funds, expired card, incorrect CVV, 3-D Secure challenge, gateway timeout. Gateways publish specific card numbers that trigger each of those, and they differ between providers.

Those numbers are not built into the generator, because they are provider-specific and change. Add them as a Custom List field, taken from your gateway's own test-card documentation, and you get a fixture that walks every branch of your payment code rather than the happy one. Weight the list by repeating the values you want more of.

Validation edge cases

For testing the card form rather than the payment, add a Custom List with the shapes that break input handling: a number with spaces every four digits, a number with hyphens, a 15-digit Amex where the form expects 16, a number one digit short, and a number that fails the Luhn check. Set Blank % on the CVV field to check required-field behaviour.

What this is not for

These numbers work in sandbox environments. They are rejected by live payment processing, which is the correct outcome and not a bug to work around. Nothing here generates a number that would function as a real payment instrument, and no request to do so would be reasonable — the value of a test card is precisely that it is known, published and inert.

The same principle runs through the rest of the data: IBANs are the right length but fail their checksum, emails land on reserved domains, and IP addresses use documentation ranges. The methodology page lays out each one.

Common questions

Related generators

• Fake IBAN generator — bank-transfer test data with the same safety design.
• Sales sample data — orders, prices and currencies.
• Mock API data guide — building a fake payment endpoint.
• Methodology — what every field draws from and why.