A test payment card is a fake card number, CVV, and expiry date that a payment processor issues for use in its sandbox. It acts like a real card inside a test environment, but it cannot be charged and it is not tied to any bank account. Developers use test cards to build, debug, and demo checkout flows without handling live card data.
What is a test payment card used for?
Test cards let you run the full payment path, from card entry to authorization response, without moving real money. They are standard equipment for anyone integrating a gateway, building a subscription flow, or checking that error messages display correctly. Because the numbers are published in vendor docs, they carry no value to a criminal and no risk to a merchant.
How do test payment cards work?
Processors map each sandbox number to a fixed outcome. One number always approves, another always declines with insufficient funds, and a third triggers a 3D Secure challenge. The gateway reads the number, matches it against its test rules, and returns the matching response code to your application.
Test mode is separated from live mode by API keys, not by the card itself. If you paste a sandbox number into a live terminal, the transaction fails or the number is rejected outright.
Do test cards pass the Luhn check?
Yes. Published sandbox numbers are built to pass the Luhn checksum, the same math a real checkout runs. That means your client-side validation logic gets exercised exactly as it would in production.
Common test card numbers
- 4242 4242 4242 4242 (Visa): approves a standard payment.
- 4000 0000 0000 0002 (Visa): always declines.
- 4000 0025 0000 3155 (Visa): requires 3D Secure authentication.
- 5555 5555 5555 4444 (Mastercard): approves a standard payment.
- 3782 822463 10005 (American Express): approves a standard payment.
- 6011 1111 1111 1117 (Discover): approves a standard payment.
Always confirm the current list in your processor's documentation. Vendors add, retire, and re-map sandbox numbers over time.
What CVV and expiry date do you enter on a test card?
Any value the format accepts will work. Use a three digit CVV for Visa, Mastercard, and Discover, and a four digit CID for American Express. Any future expiry date is fine, and most processors accept any valid month and year combination.
Some sandbox numbers do check the security code. If a specific test card rejects your CVV, read that vendor's card table, because a few entries use the code to trigger a declined response.
Why do gateways block real card numbers in test mode?
Card industry rules require that live account data stays out of development and staging systems. Sandbox numbers enforce that boundary and keep real cardholders out of your test logs. They also stop a stray production key from accidentally authorizing a charge during a demo.
How do you test declines and error codes?
- Pick the sandbox number mapped to the response you want, such as a generic decline or a lost card.
- Submit the charge in test mode with a test API key.
- Confirm your app shows the correct message and does not retry a hard decline.
- Log the raw response code so support can trace failed checkouts later.
Testing only the happy path leaves you blind to the errors customers actually hit. Run at least one decline case per payment method you accept.
Can you use a test card for a real purchase?
No. Test numbers exist only inside sandbox environments and have no funds behind them. Attempting to use one against a live merchant account results in a failed transaction and, depending on the processor, a flagged account.
Best practices for using a test card
- Keep sandbox and live API keys in separate configuration files with clear names.
- Never store test card data in the same database table as live tokens.
- Add a visible banner to any staging checkout page so testers know which mode is active.
- Cover approvals, declines, 3D Secure, and network timeouts in your test suite.
- Recheck the vendor card list before each major release.