Answer
A test card is a card number that a payment processor publishes for use in a sandbox. The number passes the Luhn check. No bank account sits behind it. A gateway returns a fixed result for each test number, so a developer can reproduce an approval, a decline, or a 3-D Secure challenge without moving real money.
How test cards differ from live cards
Live card numbers map to an issuer and a cardholder account. Sandbox numbers map to a response code inside the gateway test environment. Test traffic runs against test API keys. Live traffic runs against live keys. The two key sets do not mix, and a test card sent to a live endpoint fails.
Test card data has no cash value. Real card data does. Traffic in real card numbers is a federal crime in the US under 18 U.S.C. 1029. Developers get test numbers from gateway documentation.
Numbers and the responses they trigger
- 4242 4242 4242 4242: Visa, approval, any future expiry, any CVC.
- 4000 0000 0000 0002: decline, generic.
- 4000 0000 0000 9995: decline, insufficient funds.
- 4000 0000 0000 0069: decline, expired card.
- 4000 0000 0000 0127: decline, incorrect CVC.
- 4000 0000 0000 3220: 3-D Secure authentication required.
Those numbers come from Stripe's published test set. Adyen, Braintree, and Checkout.com publish their own lists. Numbers differ between processors, so copy the list from the gateway you integrate.
What the Luhn check does
Luhn is a checksum. Double every second digit from the right. Subtract 9 from any result above 9. Sum all digits. A valid number gives a total that is a multiple of 10. Sandbox numbers satisfy this rule, which lets them pass client-side validation that rejects mistyped input.
Test cases worth covering
- Approval with a saved card and a repeat charge.
- Soft decline with a retry, then a hard decline.
- 3-D Secure challenge, pass, and fail paths.
- Expired card and bad CVC handling in the payment form.
- Idempotency key reuse on a duplicate submit.
- Webhook receipt for charge.succeeded and charge.failed.
Limits of test cards
A sandbox does not model issuer stand-in processing, network routing, settlement timing, or real chargeback evidence. Fraud scoring models stay quiet in test mode. A passing test suite shows that your code handles the responses the gateway scripts. It does not show that a live issuer will approve the charge.