A sandbox test card is a card number that works only inside a payment processor's test environment. It returns a result you pick, such as an approval, a decline, or a processing error, and no real money moves. Developers use these numbers to run a checkout from first click to final receipt before a live card is involved.
Test cards come from the processor, not from a bank. Each number is tied to a test account and stops working when you switch to live keys.
How does a sandbox test card work?
The number routes to a simulator instead of a card network. The simulator matches the digits to a scripted scenario and sends back the response a real issuer would send, including the authorization code and the decline reason.
- Test mode keys send each request to the simulator.
- Live mode keys send each request to the card networks.
- The same number passes in one mode and fails in the other.
Because the response is scripted, you can test paths that are hard to reproduce with a real card: a lost card, a stolen card, a bank timeout, a duplicate charge attempt.
What results can a test card trigger?
Most processors publish a list of numbers, and each one maps to a fixed outcome. Stripe's long-standing 4242 4242 4242 4242 approves, for example, while other published numbers return named decline codes.
- Approval, with funds captured in test mode only.
- Generic decline, which the checkout should show as a soft failure.
- Insufficient funds, a decline the customer can fix.
- Expired card and incorrect CVC, both good for form validation tests.
- Processing error, which exercises your retry logic.
- 3D Secure challenge, where the simulator asks for an extra authentication step.
Pull the exact numbers from your processor's test documentation. A guessed number returns an unknown-card error and proves nothing about your code.
Which other fields does the sandbox check?
A card number alone does not finish a payment. Sandbox environments also read the expiry, the CVC, the postal code, and the cardholder name, and each field has test values that pass or fail.
- Expiry: any future date passes. A past date triggers an expired-card decline.
- CVC: three digits for most brands, four for American Express.
- Postal code: some processors force a mismatch to test address verification.
- One-time code: a fixed value published in the same test docs covers the 3DS step.
How do you run a test payment step by step?
- Switch the account to test or sandbox mode and copy the test API keys.
- Load the checkout with those keys and confirm a test banner or test badge appears.
- Enter a published test number, a future expiry, and a test CVC.
- Submit the form and log the response code your code receives.
- Repeat with a decline number, a timeout number, and a 3DS number.
- Compare the order status, the email receipt, and the database row.
Step six catches most bugs. A checkout that shows declined while the orders table marks the sale as paid is a common failure, and it only shows up when you test both sides.
Why test payments in a sandbox first?
A live payment failure costs a sale and, in some cases, a chargeback. A sandbox failure costs a few seconds and leaves a clear error code to read.
The sandbox also lets you force states that almost never appear in real traffic. That matters when you write the recovery path for a timeout or a partial capture.
- No real money moves, so a broken loop cannot drain an account.
- Every decline code is reproducible on demand.
- Webhooks fire in test mode, so you can check event handling and ordering.
- You can reset test data without touching live customers.
Test card versus a real card number
A test card exists to be shared. It sits in public documentation, works for anyone with a test account, and cannot be charged. A real card number, CVC, and expiry belong to one person and one account.
- Test cards: published, reusable, tied to a sandbox, no money moves.
- Real cards: private, tied to an issuer, money moves on each charge.
- A real number entered in test mode returns an error, not a payment.
Any number that clears a live checkout is not a test card, whatever a seller calls it. Card data traded on open sites is stolen account data, and it fails at the first real authorization check.
Common sandbox testing mistakes
- Leaving live keys in a staging config, then testing with a published number.
- Testing the approval path and skipping declines, timeouts, and 3DS.
- Hard-coding a card number in source instead of a config value.
- Ignoring webhook events that arrive out of order.
- Reusing one test email, which hides duplicate-customer bugs.
Frequently asked questions
Do sandbox test cards expire?
The number stays in the docs while the processor supports it. The expiry date you type must still be in the future, or the simulator returns an expired-card decline.
Can a sandbox test card be charged?
No. The simulator returns a response, but no authorization reaches an issuer, so nothing is billed and no statement line appears.
Why does my test card fail in live mode?
Live mode routes to real networks. Published test numbers are not real accounts, so live mode rejects them with an error.
Where do I find the test card list for my processor?
In the provider's developer docs, under testing or test cards. Each processor keeps its own list, and numbers do not carry over between providers.