A test card is a card number a payment processor publishes for sandbox use. It passes the same checks as a live card, but it points at no real account and moves no money. Developers use it to test checkout forms, declines, refunds, and 3D Secure flows before a product goes live.
What is a test card used for?
Test cards let you run a payment flow end to end without touching a bank account. Each processor publishes its own list, and each number returns a set result: approve, decline, or ask for extra authentication.
- Check that a payment form accepts valid numbers and rejects bad ones.
- Trigger specific decline codes, such as insufficient funds, expired card, or blocked card.
- Test a 3D Secure challenge and the redirect back to your site.
- Run refunds, partial captures, and void flows.
- Confirm your error messages match what the customer sees.
How is a test card different from a real card?
A real card routes to an issuer. A test card routes to the processor's test environment and never reaches a bank. The digits look real, and many follow normal Visa or Mastercard prefix rules, which is why they pass client-side validation.
Some test numbers sit in a reserved range that can never be issued to a customer. Others borrow a live-looking prefix, such as 4242 for Visa, and stay inside the sandbox.
Which test card numbers do developers use most?
The most cited example is 4242 4242 4242 4242, the standard success case in Stripe's documentation. It accepts a future expiry date and a three-digit CVC.
Other gateways publish their own sets. Adyen, Braintree, Checkout.com, and Worldpay each keep a test page with a success number, decline numbers, and 3D Secure variants.
- Success: a plain Visa number that always approves.
- Decline: numbers that return a chosen reason code on purpose.
- 3D Secure: numbers that force a challenge screen.
- Error: numbers that fail validation so you can test form logic.
Copy numbers from your own processor. A card from one gateway may behave in a different way on another, because the response logic lives in the gateway, not on the card.
What about the CVV and expiry date on a test card?
Test cards come with a matching test CVV and a far-future expiry date. Stripe's default test card, for example, works with any three-digit CVC and any expiry year ahead of today.
CVV checks are testable too. Most gateways supply a number that returns a CVV mismatch, so you can see how your checkout handles a failed security code.
How do you set up a sandbox for card testing?
- Create a test account with your payment processor.
- Copy the API keys that carry the test prefix.
- Enter a test card number, a future expiry, and the matching CVC into your checkout.
- Read the raw response in the gateway dashboard and compare it with your own logs.
- Repeat the run with decline and 3D Secure numbers.
Keep the sandbox keys in a separate config file from live keys. Mixing them is the most common cause of a test that fails for no clear reason.
How do you test a decline or a refund?
Use the decline numbers your processor lists. Each one maps to a response code, such as insufficient funds or card expired. Watch the raw response in your logs, then check the message your site shows the buyer.
For refunds, run a successful charge with the success card, then send a refund against that transaction ID. Confirm the refund state in the gateway dashboard and in your own database.
Can you use a test card on a live payment page?
No. A live gateway rejects test numbers, and a test number on a production endpoint can trip fraud rules and trigger an account review. Keep test cards in sandbox mode and check the API key before you click pay.
The rule cuts both ways. A test key with a test card works. A live key with a test card fails. A live key with a real card charges a customer.
Why do test card numbers pass Luhn validation?
The Luhn algorithm checks a card number against a checksum. Test numbers are built to satisfy that checksum, so your client-side validation treats them as valid.
They also follow issuer rules: 16 digits for Visa and Mastercard, 15 for American Express, plus an expiry year in the future.
What should you avoid with a test card?
Do not store card data from a real payment unless you meet PCI DSS. Requirement 3.2 bars keeping the CVV after authorization, and that rule covers any environment that holds live card fields.
Test numbers need no protection, but a test number that shows up in production logs means your logging captures card fields at all. Mask the field and remove the entry.
Frequently asked questions
Is a test card a real credit card?
No. It has no account, no balance, and no bank behind it. It only answers inside a sandbox tied to a merchant account.
Can I get a test card for free?
Yes. Processors publish their lists in public docs, and a sandbox account costs nothing to open.
Do test cards expire?
The numbers do not expire, but the expiry field on the form still needs a future date. Some gateways rotate their test sets, so check the docs when a number stops working.
Are test cards safe to share?
Yes. They work only in test mode and cannot charge anyone. That is also why they appear in public documentation.