A card test number is a fake card number that a payment processor publishes for sandbox use. It passes the same format checks as a real card, triggers a predictable approve or decline response, and moves no money. It only works in test mode. It cannot tell you whether a real card is active, and using it that way is card fraud, not testing.
What a card test number actually is
Processors such as Stripe, PayPal, and Adyen hard-code a small set of numbers that their test environments recognize. Each number maps to a fixed outcome. One always approves. Another always returns a decline. Others simulate specific error codes like insufficient funds or an expired card.
- The number is not tied to any bank account or cardholder.
- It is rejected the moment you submit it against a live endpoint.
- Any expiry date in the future usually works, since the sandbox ignores real expiry data.
- The CVC is typically any three digits, or a value the processor's docs specify.
Prerequisites
- A developer account with a payment processor.
- Test API keys, kept separate from live keys.
- Access to that processor's published test card list.
- A staging checkout page or API client you can point at the sandbox.
How to use a test card number
- Open your processor's test card documentation and copy a number from the official table.
- Switch your checkout or API client to test mode using the test keys.
- Paste the test number into the card field on your staging checkout.
- Enter any future expiry date, such as 12/34.
- Enter the test CVC value the documentation lists.
- Submit the payment and read the response code your integration returns.
- Repeat with a decline number to confirm your error handling shows the right message.
- Check the sandbox dashboard to confirm the charge appears as a test transaction.
- Switch back to live keys only after you finish every scenario.
Scenarios worth testing
- Successful charge and the receipt your customer sees.
- Generic decline and the message your checkout displays.
- Insufficient funds and any retry flow you built.
- Expired card and how your form validates the date.
- Authentication challenge flows if you use 3D Secure.
- Refunds, partial refunds, and voided authorizations.
Mistakes to avoid
- Never enter a real card number into a test environment. Test data should stay fake so no live cardholder data ever touches your sandbox.
- Never leave test mode enabled on a production endpoint.
- Never share sandbox keys in public repos or screenshots.
- Never assume a test approval predicts how a real bank will respond.
Where the legal line sits
Running a small charge against a card you do not own, with or without the cardholder's knowledge, is unauthorized use of a payment card. In the United States that falls under federal fraud statutes, and processors treat it as a terms-of-service violation that ends in an account ban and a report to law enforcement. Test card numbers exist so developers can build integrations without touching anyone's money. Keep them in that lane.