A test payment card is a card number that a payment processor issues for sandbox or test mode. It acts like a real card in every way except one: no money moves. You can run charges, refunds, and declines without touching a live account.
Why developers use test payment cards
I reach for test cards when I build checkout flows. They let me check that my code handles approvals, declines, and errors. A live card would create real charges and fees. A test card keeps the work safe and repeatable.
Where to find them
Every major gateway publishes its own list. Stripe, PayPal, Braintree, and Authorize.Net all offer test numbers in their developer docs. You do not need to guess. The numbers follow card network patterns, so a Visa test card starts with 4, and a Mastercard test card starts with 5.
What different test numbers do
Processors design test cards to trigger specific outcomes. Some numbers always approve. Others always decline. A few simulate fraud checks or require 3D Secure. Here are common categories:
- Successful charge: a standard test number that returns an approval.
- Declined charge: a number that returns a generic decline code.
- Insufficient funds: a number that mimics a lack of balance.
- Expired card: a number with a past expiry date.
- CVV failure: a number that rejects the security code.
Best practices
- Use only the numbers from your gateway's documentation. Random numbers may not work.
- Keep test mode separate from live mode. Most gateways use different API keys.
- Check expiry dates. Some test cards expire after a set year.
- Test every path: success, decline, error, and timeout.
- Never use test cards in production. They will fail or cause confusion.
Test payment cards are a quiet tool. They save you from real charges and let you break things on purpose. Learn the handful your gateway provides, and your checkout tests will run smoother.