Test Card Guide: Sandbox Card Numbers and Test Payments

A test card is a payment card number that a payment processor publishes for use in its sandbox. It has the same format as a live card number and passes the same validation checks, but the processor routes it to a simulator instead of the card networks. No account is charged, no cardholder exists, and a production gateway will reject the number. Use it to build and verify checkout flows before you switch to live credentials.

Where test cards come from

Every major processor maintains a set of test cards in its developer documentation: Stripe, Adyen, PayPal and Braintree, Worldpay, and Checkout.com all publish them. Each set usually includes a general success number, several numbers that force a specific decline, and numbers that trigger a 3-D Secure challenge. The numbers are tied to a fixed expiry date and accept any CVC value. Some processors also accept any future expiry date you enter.

Because the numbers are public, they carry no value and no risk. They are documentation, not credentials. Treat them as fixtures that belong in your test suite next to your mock API responses.

Run a test payment in a sandbox

1. Open your processor's dashboard and confirm you are in test mode, not live mode.
2. Copy the test card numbers from the processor's test data page into a local fixture file in your repo.
3. Enter the success test number in your checkout form.
4. Enter any future expiry date and any three-digit CVC when the form asks for them.
5. Submit the payment and confirm the response returns an approved status with an authorization code.
6. Repeat the flow with each decline test card and confirm your UI shows the matching error message.
7. Run the 3-D Secure test card and confirm the challenge modal appears and completes.
8. Record the request and response payloads for each scenario so you can compare them after future changes.
9. Swap test keys for live keys only after every scenario passes, and remove hardcoded test numbers from production code paths.

Scenarios worth covering

• Successful authorization and capture, including partial refunds.
• Generic decline and insufficient funds, to check your error copy.
• Expired card and incorrect CVC, to check field-level validation.
• Address verification mismatch, to confirm your AVS rules behave as configured.
• 3-D Secure challenge and challenge failure, to confirm the redirect and fallback paths.
• Network timeout, using the processor's simulation header or a mocked response.

What a test card cannot do

A test card cannot verify a real card. It only exercises your integration. Running a small live charge to check whether a real card number works is card testing, a form of payment fraud. Processors score for it, and the usual outcome is blocked traffic, fines, and account termination. Card networks also prohibit testing live numbers without cardholder authorization, and in the United States such conduct falls under wire fraud statutes.

Compliance notes

PCI DSS requires that live cardholder data stay out of test and development environments. Keep sandbox accounts free of real card numbers, real customer names, and real billing addresses. If you need realistic-looking data for screenshots or demos, generate synthetic values instead. Store test credentials in the same secret manager you use for live keys, so the separation between environments stays visible to everyone on the team.