A test transaction card is not a real card
A test transaction card is a card number that works only inside a payment provider's sandbox. It passes Luhn validation, returns realistic authorization responses, and never reaches a card network. No bank is contacted, no funds move, and no cardholder exists. The point is to build and break a checkout flow before live keys ever touch the code.
When a provider tags a card set as v10, that is a revision label, not a card type. It means the tenth published version of that provider's test card library. Check the changelog when you upgrade. Numbers get retired, expiry rules shift, and some entries move to a legacy list that stops returning the responses you expect.
Test Transaction Card V8 Guide
How to run a test transaction
- Put your account in test mode and use test API keys. One live key in a sandbox flow is the most common reason a test fails in a confusing way.
- Enter the test number at checkout. Use any future expiry date and any three digit CVC unless the docs specify values.
- Set the amount. Some providers tie behavior to the amount, so a small charge may approve and a larger one may decline.
- Read the response object, then read the webhook. The response tells you what the API decided. The webhook tells you what your system did with that decision.
- Repeat with a decline number to confirm your error states and retry logic hold up.
Numbers you will use most
- 4242 4242 4242 4242, Visa, approves.
- 4000 0000 0000 0002, generic decline.
- 4000 0000 0000 9995, insufficient funds.
- 4000 0000 0000 3220, authentication required for 3D Secure testing.
- 5555 5555 5555 4444, Mastercard.
- 3782 822463 10005, American Express, fifteen digits.
Amex breaks copy and paste habits because of the shorter length and the four digit CVC. Test it early if you accept Amex, since form validation often fails there first.
Decline and error codes to expect
Generic declines, expired card, incorrect CVC, insufficient funds, processing error, and authentication required cover most of what you see. Map each one to a message a customer can act on. "Something went wrong" is not a message. "Your bank declined this card, try another" is.
Where test setups go wrong
- Live keys mixed with test numbers.
- Reused payment method tokens from an earlier run.
- Cached 3D Secure challenges that skip the redirect.
- Idempotency keys that return the first response forever.
- AVS checks with a postal code the sandbox does not recognize.
One more: never put a live card number into a staging server, a spreadsheet, or a test tool. Test cards exist so you never need to. Handling real card data pulls you into PCI DSS scope, and sandbox testing is supposed to keep you out of it.
Ship checklist
- Approval path passes with a Visa test number.
- Decline path passes with a decline number and shows a useful message.
- 3D Secure challenge completes and returns to the right page.
- Webhook fires once, and your handler is idempotent.
- Refund and void run against a test charge.