A credit card test number is a card number that a payment processor publishes for use in its sandbox or test mode. It looks like a real card: correct length, a plausible issuer prefix, and a valid Luhn checksum. It will never authorize a live charge. Developers use these numbers to build checkout forms, webhook handlers, refund flows, and error handling without touching a real account. If you are looking for numbers that approve against a live storefront, that is not testing. That is carding, and in the US it falls under 18 U.S.C. 1029. Test numbers belong in test mode, with test keys, against test data.

What to look for when you choose test numbers

  • Start with your processor's own documentation. Stripe, PayPal, Adyen, Square, and Braintree each maintain separate sets, and a number from one gateway carries no meaning in another.
  • Response coverage. You want approvals plus a spread of declines: generic decline, insufficient funds, expired card, incorrect CVC, and a processing error.
  • Brand variety. Visa, Mastercard, American Express, and Discover behave differently on CVC length and address verification, so test each brand you plan to accept.
  • Authentication cases. Ask for a 3D Secure card that triggers a challenge and one that passes without friction, so you can exercise both branches of your code.
  • Region and currency coverage if you sell outside the US, since cross-border rules affect decline behavior.

Parameter bands that matter

  • Digit length: 16 for Visa, Mastercard, and Discover, 15 for American Express.
  • Security code: 3 digits for most brands, 4 digits on American Express.
  • Expiry: any future date in the sandbox, though some gateways want a fixed month and year for specific test cases.
  • Postal code: US formats are 5 digits or ZIP+4, and a wrong value is a common way to force an AVS mismatch.
  • Amount: keep test charges small and expect gateway limits on the largest sandbox transaction.

Pitfalls to avoid

  • Pasting a test number into a production form. It will fail, and the failed attempt may trip your own fraud rules.
  • Hardcoding test numbers in a repository that also holds live API keys. Separate the two sets of credentials.
  • Treating a passing test as card validation. A test number confirms your integration works, nothing about any cardholder.
  • Generating numbers that pass Luhn and calling that a test suite. Luhn only checks digit structure, not whether a gateway will route the number.
  • Ignoring webhook states. Plenty of failures surface after the initial authorization, during capture or settlement simulation.

FAQ

Do test card numbers work on real websites?

No. Processors route them to sandbox systems, where they are flagged as test instruments. A live endpoint will reject one or, worse, log it as a suspicious attempt.

Is a test number the same as a virtual card?

No. A virtual card is a real, funded, single-use or limited-use number issued by a bank or fintech for a genuine payment. A test number has no account behind it.

Can I generate my own test numbers?

You can produce digits that pass a Luhn check, and a few custom harnesses accept them. Most gateways run a fixed allow list, so generated values have no effect. Pointing generated numbers at live endpoints is a federal offense.

Why does my test card get declined in test mode?

Check that you are using a test API key, that the number is on your processor's current list, and that the number is not one designed to decline. Documentation changes more often than people expect.