A test card number is a fake card number that a payment gateway publishes so developers can run transactions without moving real money. It passes the same Luhn checksum as a live card, but the gateway routes it to a sandbox instead of a bank. Use it to test checkout flows, declines, refunds, and webhooks before you take real payments.

What Is a Test Card Number?

A test card number is placeholder card data tied to a sandbox account at a payment processor. The number looks real because card networks reserve certain ranges for testing. No bank account sits behind it, so any charge returns a simulated response instead of a settlement.

The name, expiry, and CVC you type beside it are placeholders too. The gateway ignores them unless you pick a number that is coded to fail a specific check.

How Test Cards Differ From Real Cards

• No money moves. The gateway returns a status code, not funds.
• Any future expiry date works. Pick 12/34 or 01/30.
• Any 3-digit CVC passes on most gateways (4 digits for American Express).
• Results are scripted. Certain numbers trigger certain errors by design.

Test numbers live in public developer documentation. That is the main difference from real card data, which never appears in a docs page and carries legal weight when mishandled.

Common Test Card Numbers

Each processor publishes its own list, and the ranges overlap. These numbers appear in open developer docs:

• Visa approval: 4242 4242 4242 4242 (Stripe, Adyen, Checkout.com)
• Mastercard approval: 5555 5555 5555 4444
• American Express: 3782 822463 10005
• Discover: 6011 1111 1111 1117
• JCB: 3566 0020 2036 0505
• Visa (Braintree, PayPal): 4111 1111 1111 1111

Authorize.Net uses a separate set, including 4007000000027 for Visa and 5424000000000015 for Mastercard. Always confirm the list on your own gateway's docs before you build a test suite.

How Do You Use a Test Card Number?

1. Create a sandbox or test account with your gateway.
2. Swap your live API keys for test keys in your environment variables.
3. Run a checkout and enter the test number, a future expiry, and any CVC.
4. Check the response in the dashboard or through a webhook.
5. Repeat with decline cards and error cards.

Most gateways label every sandbox transaction as a test in the dashboard, so you can tell them apart from live volume at a glance.

Which CVV, Expiry, and ZIP Should You Use in Test Mode?

Most gateways accept any 3-digit CVC, any future expiry, and any ZIP that matches the country format. Stripe accepts 12345 for US addresses, while Adyen accepts any three digits. Braintree lets you force a CVC mismatch with specific codes, so read that gateway's docs if you need to test a failed verification.

How Do You Test Declines and Errors?

Gateways assign error behavior to special numbers. Stripe's 4000 0000 0000 0002 returns a generic decline, 4000 0000 0000 9995 returns insufficient funds, and 4000 0000 0000 0127 fails the CVC check.

Test at least four cases before launch: approval, decline, expired card, and a gateway timeout. Some processors also ship 3D Secure test cards that trigger an authentication challenge, which is the only way to confirm your challenge flow works.

Can You Use a Test Card Number on a Real Store?

No. Test numbers only work against a sandbox. A live gateway rejects them, and entering fake card data on a live checkout breaks the processor's terms of service.

There is one useful signal here. If a production checkout accepts 4242 4242 4242 4242, that store has pointed its test keys at a live site, which is a misconfiguration your own team should catch in code review.

Are Test Card Numbers the Same as Buying a CVV?

No. Test numbers come from public developer docs and cost nothing. A CVV sold on an open market refers to card data tied to a real account, and buying, selling, or using that data is a crime in the US and most other countries.

Developers who need card data for testing should stick to sandbox numbers. Nothing else is legal to handle outside a PCI-compliant production environment.

Checklist Before You Go Live

• Swap test keys for live keys in every environment file.
• Delete hardcoded test card numbers from your test fixtures and code.
• Run one live transaction with a real card, then refund it.
• Point webhooks at the production endpoint.
• Confirm your logs never store full card numbers or CVCs.

Frequently Asked Questions

Does 4242 4242 4242 4242 work everywhere?

It works in most sandboxes, including Stripe and Adyen. A few gateways require their own number, so check your processor's docs.

Is a test card number a real card?

No. No bank account backs it, and no funds move. The number exists only for sandbox testing.

What expiry date should I use?

Any date in the future. Docs often list 12/34, but 01/30 works too.

Can a test card number be charged for real money?

No. A sandbox charge returns a simulated authorization, and the dashboard marks the transaction as a test.

Do test card numbers expire?

The numbers stay valid, but the expiry date you attach must be in the future. A past date triggers an expired card error, which is useful when you want to test that path.