Answer
A test card is a card number a payment processor publishes for use against its sandbox. The number passes the same format and Luhn checks a real card passes, but the request routes to a simulated authorization. No money moves. No issuer is contacted. Test cards work only with test API keys and sandbox endpoints. Used against a live endpoint they fail.
How to Use a Sandbox Payment Test Card for Secure Testing
What the sandbox checks
- Digit count and BIN range for the card brand.
- Luhn checksum, the final digit that validates the number.
- Expiry date in the future.
- Card verification code length: 3 digits for Visa and Mastercard, 4 for American Express.
A sandbox does not check the number against an issuer database. It checks the number against the processor's list of test values.
Common published numbers
Stripe, Adyen, PayPal and Braintree each publish their own set. Several numbers appear across vendors:
- 4242 4242 4242 4242 — Visa, approved.
- 5555 5555 5555 4444 — Mastercard, approved.
- 3782 822463 10005 — American Express, approved.
- 6011 1111 1111 1117 — Discover, approved.
- 4000 0000 0000 0002 — Visa, declined.
- 4000 0000 0000 3220 — Visa, requires 3-D Secure authentication.
Any future expiry date and any valid CVC work with these numbers on most platforms. Vendors differ on details, so check the processor's reference page for the exact list you need.
Sandbox Test Card Numbers: Guide for Test Payments
Decline and error cases
Sandboxes ship numbers that force specific failures. These cover insufficient funds, expired card, incorrect CVC, processing error and lost or stolen card. Teams use them to test error handling without waiting for a real failure.
3-D Secure test cases
Card networks define test profiles for authentication: successful challenge, failed challenge, and challenge not required. The processor maps these to its own test numbers. The result is a simulated liability shift you can assert on in your test suite.
Common mistakes
- Using a live API key with a test card. The request fails on a real network.
- Assuming one vendor's test number works on another vendor's sandbox.
- Hard-coding a single card. Test suites should cover approved, declined and 3-D Secure paths.
- Leaving test keys in a production build.
Keep the test card list inside your test fixtures and rotate to the vendor's current page when you upgrade SDKs.