A test transaction card is a fake card number that a payment processor publishes for sandbox testing. It passes the same format and checksum checks as a live card, but it moves no money and touches no real bank account. Developers use it to confirm that checkout, refunds, subscriptions, and decline rules work before a site goes live.
How does a test transaction card differ from a live card?
The card number itself is built the same way. The digits pass the Luhn check, the brand prefix points to a real network, and the expiry and CVC fields accept the same input.
The difference sits on the issuer side. A test card routes to a sandbox instead of a bank, so the processor can return any result the developer asks for.
- Money: a live card moves funds; a test card moves nothing.
- Numbers: test numbers are public property; live numbers are private and regulated.
- Keys: test cards work with test API keys; live cards work with live keys.
- Scope: test data carries no PCI obligations; live card data does.
Where do test transaction cards come from?
Each processor publishes its own set of numbers. There is no central registry, so you use the set that belongs to your gateway.
- Stripe lists test cards in its docs, with separate numbers for successes, declines, and authentication flows.
- PayPal and Braintree issue sandbox card numbers inside the developer dashboard.
- Adyen ships test cards tied to fixed shopper profiles, one per result code.
- Authorize.net shows test numbers inside sandbox account settings.
The card networks list a few generic sandbox numbers as well, but the processor copy is the one that matches your integration and your error codes.
How do you run a test transaction?
- Switch your integration to test mode and load a test API key.
- Pick a number from your processor's docs. Stripe's 4242 4242 4242 4242 is the common success case.
- Enter a future expiry date and any 3-digit CVC, unless the doc names a specific value.
- Submit the order and read the raw response object, not just what appears on screen.
- Repeat with a decline number, a past expiry date, and a wrong CVC so failure paths get covered.
- Test refunds, partial captures, and webhooks against the same test order.
Write down the result of each run. A test log that you can hand to a teammate saves hours when a real card declines in production.
Which test numbers trigger declines?
Processors hard-code decline behavior into specific numbers. One number returns insufficient funds, another returns a stolen card flag, another forces a network timeout.
Read the response code your gateway sends back. A decline that shows on the front end but never reaches your webhook points to a bug in your integration, not a problem with the card.
What are common mistakes when testing cards?
- Mixing test keys with a live endpoint, which returns authentication errors that look like card failures.
- Testing the happy path only, then meeting the first real decline in production.
- Skipping authentication and 3D Secure flows, which behave nothing like a plain charge.
- Hard-coding test numbers into production code instead of a test config file.
- Assuming CVC validation in sandbox mirrors the live rules for every region.
Is using a test transaction card legal?
Yes. Test cards exist for sandbox work and carry no account, no funds, and no personal data. Using them on a test endpoint is standard practice for any developer building a checkout.
The legal line sits with live card data. Using someone else's real card details without permission is fraud, and running a test number against a live key does not make it a test.
Keep test numbers in your test environment. Never route them through live keys, and never store live card data outside a PCI-compliant system.
Frequently asked questions
Do test cards work on live sites?
No. A test number sent to a live endpoint fails authentication or returns a decline. The gateway checks the key mode before it looks at the card.
Can a test card be charged?
No. A sandbox charge creates a record in your test dashboard and nothing else. No funds move.
Why did my test card get declined?
You either picked a number that maps to a decline code, used an expiry date in the past, or sent the request with live keys. Check the error code first.
Do I need a different test card for each currency?
Only if your processor says so. Some gateways tie card numbers to a currency or a country, and the docs list which number to use for each case.
Checklist before you go live
- Success, decline, and error paths all covered.
- Refund and partial capture tested on a test card.
- Authentication flow tested where your region requires it.
- Webhook handling verified, including retries.
- Test keys and test numbers removed from production config.
Run the full list once on a fresh sandbox account. A clean slate catches setup steps that a long-lived test account hides.