What a sandbox test card is

A sandbox test card is a card number that a payment processor publishes for use in its test environment. It passes the Luhn checksum, carries a valid card brand prefix, and behaves like a real card inside the sandbox. No bank is contacted, no authorization is issued, and no money moves. The processor's test API recognizes the number and returns a scripted response.

Test cards exist so developers can build checkout flows, retry logic, and error handling without touching live cardholder data. They never work in production. If you enter one on a live payment page, the transaction fails.

Prerequisites

• A sandbox or test account with the processor
• Test-mode API keys
• The processor's test endpoint, not the live endpoint
• Access to the dashboard or API logs so you can read responses

How to run a test transaction

1. Sign in to the processor dashboard and switch the account to test mode.
2. Copy the test API keys into your application's environment variables.
3. Point your client at the sandbox base URL.
4. Open the processor's test card documentation page and pick a number for the brand you want to exercise.
5. Enter the number on your checkout form.
6. Use any future expiry date, such as 12/34.
7. Use any three-digit CVC, or any four-digit value for American Express.
8. Submit the payment.
9. Read the response in your dashboard, API log, or webhook receiver.
10. Repeat with a decline card to confirm your failure path renders the right message.

Common test numbers

Values differ by processor. These are the ones published most often.

• Stripe: 4242 4242 4242 4242 for a successful Visa charge, 4000 0000 0000 0002 for a generic decline, 4000 0025 0000 3155 for 3D Secure.
• Braintree and PayPal: 4111 1111 1111 1111.
• Authorize.Net: 4007000000027 for Visa, 5424000000000015 for Mastercard, 370000000000002 for American Express.
• Adyen: 4111 1111 1111 1111 for the basic test flow.

Confirm against your processor's current documentation before you hardcode anything. Numbers retire and new ones appear when card brands change test ranges.

Triggering specific failures

Most processors reserve separate numbers for each decline reason. One card returns a generic decline, another returns insufficient funds, another returns an expired card, and another returns a processing error. Some test cards force a 3D Secure challenge or hit a velocity limit.

Use these to verify that your UI shows a useful message, that your retry logic stops after the right number of attempts, and that your webhook handler records the decline code instead of dropping it.

Handling test card data

Test numbers are not cardholder data, so PCI requirements do not apply to them. Treat them as code constants anyway. Keep them out of production configuration, gate them behind a test-mode flag, and make sure a test number can never reach a live endpoint. If you copy production code into a sandbox, strip the real keys first.