A credit card test number is a published fake card number that works only inside a payment processor's test or sandbox environment. The number most developers reach for first is 4242 4242 4242 4242, the standard Visa test card that Stripe documents, and it is the top pick for a first integration pass. It passes the Luhn checksum, accepts any future expiry and any three-digit CVV, and returns a successful authorization from a sandbox endpoint. It is declined by every live gateway. The numbers below were judged on three criteria: whether the processor publishes them in its own documentation, whether they cover all four major card networks, and whether they can trigger the specific decline and error scenarios a checkout needs to handle.
credit card test number for verification
What makes a number a test number
Test numbers are not random strings. Each one is a syntactically valid card number built on an issuer identification number range that the processor has reserved for testing. That is why 4242 4242 4242 4242 reads as a Visa credit card: the leading 4 and the 16-digit length are correct, and the final digit satisfies the Luhn algorithm.
Three properties separate a test number from a live one. It is published in the processor's documentation. It is routed to a sandbox endpoint instead of the card networks. And it is bound to a fixed set of outcomes the processor decides in advance.
credit card test number and cvv validation
Test numbers that cover the major networks
- 4242 4242 4242 4242 Visa credit, the default success case in most sandbox setups
- 4000 0566 5566 5556 Visa debit
- 5555 5555 5555 4444 Mastercard credit
- 5200 8282 8282 8210 Mastercard debit
- 3782 822463 10005 American Express, 15 digits with a four-digit CVV field
- 6011 1111 1111 1117 Discover
- 3056 9300 0902 0004 Diners Club
Use an expiry date at least a year out so your own validation logic does not reject the input before the gateway sees it. In most sandbox environments the CVV field accepts any three digits for the Visa and Mastercard cards above, and any four for the Amex card.
credit card test number and cvv validation
Using test numbers to force declines
A success path is the easy half of an integration. Most bugs surface in the failure paths, where a checkout has to show the right message and leave the cart intact. Processors publish dedicated decline cards for this. Stripe documents 4000 0000 0000 0002 for a generic decline, 4000 0000 0000 9995 for insufficient funds, 4000 0000 0000 0069 for an expired card, and 4000 0000 0000 0127 for a failed CVC check. Other processors publish equivalent lists keyed to their own error codes, so pull the list from whichever gateway you actually integrate.
What test numbers cannot do
A test number has no account behind it. There is no issuer, no credit line, and no settlement, so no money moves and no purchase completes. The number is accepted only when the request goes to a sandbox endpoint with test API credentials.
For the same reason, a test number cannot tell you whether a real card is live. Confirming that a live card works requires an authorization against the card networks, which requires a merchant account and the cardholder's consent. Running that check on a card number you did not receive from its owner is card testing, and card testing is fraud under US federal law and state law, regardless of whether the charge is later reversed.
Legal and compliance notes
Handling card data creates obligations that go beyond code. PCI DSS requires that the card verification value not be retained after authorization, even by a merchant that is compliant in every other respect. Test numbers sit outside that rule because they are not cardholder data, but the exemption ends the moment a sandbox is pointed at a real number. Keep live credentials out of development machines and out of source control.
Choosing the right number for your case
Match the card to the scenario you are testing rather than to the network you happen to prefer.
- First integration pass: 4242 4242 4242 4242 with any future expiry and any three-digit CVV, to confirm the happy path end to end.
- Amex-specific layout: 3782 822463 10005, to exercise the 15-digit format and the four-digit CVC field.
- Error handling and messaging: the decline cards from your own processor's list, so the error codes match what production will return.
- Subscription and stored-credential flows: a debit test card, because debit and credit can diverge in how a gateway handles repeat charges and network tokens.
Store the numbers in a fixture file or environment configuration rather than in application code, and seed your test suite with them so that a sandbox key never reaches production.