Answer first
A test card is a card number that a payment processor accepts in its sandbox and rejects in live mode. You run a checkout with it to see what the code does at each step: approval, decline, authentication, webhook. No money moves. No real account gets charged.
testing card checkout integration
Test numbers are published by the processor, not by banks. Each processor keeps its own list. A Stripe test PAN means nothing at Adyen, and a number that returns an approval in one sandbox may return an error in another.
Test Checkout Flow for Card Payment Guide
How test mode differs from live mode
Test mode is a separate environment with separate API keys. The endpoint host, the key prefix, and the dashboard view all change. A request signed with a live key against a test PAN returns a card error, and a request signed with a test key against a live PAN returns an invalid number error. The two do not mix.
Test mode also skips the network. The processor resolves the number against an internal table, so results come back in milliseconds and stay the same on every run.
Approval numbers
These PANs return a successful authorization in most US sandboxes. Use any future expiry date and any 3 digit code, or 4 digits for American Express.
- 4242 4242 4242 4242, Visa, 16 digits
- 5555 5555 5555 4444, Mastercard, 16 digits
- 3782 822463 10005, American Express, 15 digits
- 6011 1111 1111 1117, Discover, 16 digits
The first digit is the issuer prefix. Visa numbers start with 4 and Mastercard with 5 under ISO/IEC 7812. A valid test PAN still passes a Luhn check, so the front end validation code will accept it.
Decline numbers
Approvals are the easy case. Most checkout bugs sit in the decline path, where a missing error handler drops the response and leaves the form frozen. Dedicated decline PANs trigger a specific code.
- 4000 0000 0000 0002, generic decline
- 4000 0000 0000 9995, insufficient funds
- 4000 0000 0000 0069, expired card
- 4000 0000 0000 0127, incorrect CVC
- 4000 0000 0000 0119, processing error
Each one maps to a distinct decline code in the API response. Assert on the code, not on the message string. Message text changes without notice.
Authentication and 3DS
Sandboxes ship separate PANs for the challenge flow. One number forces a challenge and passes it. A second forces a challenge and fails it. A third returns a challenge that the customer abandons. Run all three. The abandoned case is the one that leaves orders stuck in a pending state.
What to check after each run
- The response body carries the expected status and decline code.
- The order record lands in the correct state, paid or failed.
- The webhook fires once, with a matching event id.
- A retry with the same idempotency key returns the first result and does not double charge.
- The cart clears on success and holds on failure.
Limits
Test cards prove the integration logic. They do not prove issuer behavior, real fraud scoring, or settlement timing. Those paths need a live account with a small real charge. Sandbox data is not cardholder data, so PCI DSS scope rules do not apply to it, but the production code that handles real PANs is still in scope.