Answer
A test transaction card is a card number issued by a payment processor for use in a sandbox. It has no linked bank account. When a merchant sends it to a test endpoint, the processor returns a programmed result: approval, decline, or a 3D Secure challenge. Test cards exist so developers can check payment flows without moving real money.
How test cards differ from live cards
Live cards pass through the card networks: Visa, Mastercard, American Express, Discover. Test cards stop at the processor. The number 4242 4242 4242 4242 is a Stripe test Visa. No live card carries that number.
Test numbers still follow ISO/IEC 7812. They carry a valid Luhn check digit, an issuer identification number, and a length of 15 or 16 digits. That lets a checkout form's client-side validation accept them.
- Expiry date: any future date.
- CVC: any three digits for Visa and Mastercard, four for American Express.
- Postal code: any value the test suite expects.
Common test card sets
- 4242 4242 4242 4242. Visa. Approval.
- 4000 0000 0000 0002. Visa. Generic decline.
- 4000 0000 0000 3220. Visa. 3D Secure authentication required.
- 4000 0000 0000 9995. Visa. Insufficient funds decline.
- 5555 5555 5555 4444. Mastercard. Approval.
- 3782 822463 10005. American Express. Approval.
Numbers vary by processor. Stripe, Adyen, Braintree, and Checkout.com each publish a separate list. A Stripe test number returns an error at Adyen.
What test cards cannot do
Test cards do not clear through a card network. They do not appear on a statement. They cannot be used at a live endpoint, and a live merchant account rejects them. They hold no funds, so no one can buy goods with them.
Testing decline paths
A test plan that covers approvals alone misses most of the work. Build cases for each response code the processor exposes.
- Map the decline messages your checkout shows to a card that triggers each one.
- Check that the order record keeps the decline reason code.
- Confirm retry logic does not charge twice after a timeout.
- Verify 3D Secure challenge and fallback paths.
- Run the same case against the live endpoint with a real card of low value.
Handling card data in test environments
Test numbers are public. Real numbers are not. Do not copy a live PAN into a sandbox, a log file, or a support ticket. PCI DSS covers test data when the data is a real account number. Test PANs fall outside scope because no account exists.
Where a processor's test number list is unclear, read that processor's own documentation. Do not guess a number. A wrong check digit fails validation before the request reaches the gateway.