A test card number is a fake card number issued by a payment processor for testing checkout flows. It passes format and Luhn validation but is tied to a sandbox environment, so it never authorizes against a real account or moves real money. Developers use these numbers to confirm that charges, declines, refunds, and error messages behave correctly before a site goes live.
What is a test card number?
A test card number mimics the structure of a real primary account number (PAN) but exists only inside a processor's test mode. Gateways publish these numbers in their developer docs so engineers can run end-to-end tests without touching customer data. Because the numbers are public and non-functional, sharing them carries no risk.
Which test card numbers do most gateways accept?
Stripe, PayPal, Adyen, and most other processors publish sandbox numbers that behave like standard Visa, Mastercard, and American Express cards. These are the widely used examples:
- Visa: 4242 4242 4242 4242
- Visa (alternate): 4111 1111 1111 1111
- Mastercard: 5555 5555 5555 4444
- American Express: 3782 822463 10005
- Discover: 6011 1111 1111 1117
Some processors map specific numbers to specific outcomes, such as a card that always declines or one that triggers a fraud check. Check your gateway's test documentation for the full list of behavior-mapped numbers.
How does a test card pass validation?
Most test numbers are built to satisfy the Luhn algorithm, the checksum that catches typos in card entry forms. The final digit is calculated from the preceding digits, so an accidental transposition usually fails validation. Testing with a Luhn-valid number confirms that your form logic, not just your gateway call, works correctly.
What expiry date and CVC should you use in test mode?
Any future expiry date works, and most sandboxes accept any three-digit CVC, or four digits for American Express. Some gateways require a fixed future date such as 12/34 to simulate a specific scenario. Invalid combinations usually return the same error codes you would see in production.
Test card number vs real card number
A real card number is tied to a funding account and must be handled under PCI DSS rules. A test number has no linked account, no balance, and no cardholder, so it cannot be charged. Never place real card data in a test environment, because that expands your compliance scope for no benefit.
How do you test declines and error paths?
Sandbox processors provide dedicated numbers that return specific decline codes, such as insufficient funds, expired card, or incorrect CVC. Running these cases verifies that your error messaging is accurate and that failed payments do not create phantom orders. Test the happy path and the decline path before every release.
Frequently asked questions
Do test card numbers work in live mode?
No. A test number is rejected outside sandbox mode because no issuing bank recognizes it. You must switch to live API keys and a real card to process an actual payment.
Are test card numbers safe to share publicly?
Yes. Sandbox numbers are published in developer documentation and are useless to anyone trying to make a purchase. Real card numbers are the opposite and must never be posted, logged, or stored outside a PCI-compliant system.
Can I use a test card number on any website?
Only on sites running in test mode with a sandbox key. A live storefront will reject the number at authorization, and attempting to use it there can trigger fraud screening on your account.