A sandbox test card is a fake card number issued by a payment processor so developers can simulate payments inside a test environment. It behaves like a live card in the sandbox, but it carries no value, moves no real money, and is rejected by production systems.
What a sandbox test card actually does
When you build a checkout, subscription, or refund flow, you need to see what happens when a card succeeds, declines, expires, or triggers extra verification. A live card cannot be used for that work. Test cards let you force each outcome on demand by entering a specific number, expiry date, and security code that the processor recognizes as a simulation.
Most processors return a standard response object either way. That means your code paths for authorization, capture, and error handling can be exercised exactly as they would be with a real customer.
Why processors publish test cards
- They let engineers test without touching customer data.
- They make decline and fraud scenarios reproducible instead of random.
- They keep compliance simple, since no real cardholder data enters the test system.
- They allow automated test suites to run on every deploy.
Common test card categories
Documentation usually groups test cards by the outcome they produce:
- Approval cards for a normal successful charge.
- Decline cards for insufficient funds, lost card, or do-not-honor responses.
- Authentication cards for 3D Secure flows that pass or fail.
- Verification cards for CVC mismatch, expired date, or postal code failure.
- Dispute and refund cards for testing chargebacks and reversals.
Where to get sandbox test card numbers
Use the official developer documentation for the processor you integrate with. Stripe, PayPal, Adyen, Braintree, and Checkout.com all maintain public test card tables alongside their API references. These pages also explain which API keys pair with which card set.
Do not take card numbers from forums, chat groups, or sites that sell card data. Numbers shared that way are either stolen data or invalid strings, and neither belongs in a test environment. A real card data marketplace is not a testing resource, and using one can expose you to fraud liability and criminal charges.
How to run a test payment
- Switch your integration to test or sandbox API keys.
- Open the processor's test card table and pick the outcome you need.
- Enter the number, a future expiry date, and the CVC listed in the docs.
- Confirm the response code and the dashboard event match your expectation.
- Repeat for every failure branch your application handles.
Rules worth following
Never paste real card numbers into a sandbox. Industry security standards require production cardholder data to stay out of test systems, and test tools are not built to protect it. Keep test keys out of production builds, and remember that a sandbox test card will always fail against a live account.