A test card number is a card number that a payment processor publishes for sandbox use. It passes the Luhn check, looks like a real card to your checkout form, and returns a scripted result such as an approval or a specific decline. No money moves. Test numbers work only in test mode and are rejected on live gateways.

Prerequisites

• A sandbox account with a payment processor such as Stripe, Adyen, PayPal, Braintree, or Authorize.net.
• Test API keys, kept separate from your live keys.
• A checkout page or API client pointed at the sandbox host.

Where test card numbers come from

Every processor maintains its own list in its developer documentation. A number that returns an approval at one gateway may return an error at another, because the response is driven by the processor's own test rules rather than by the card network. Treat the list as part of the gateway, not as a universal set of magic numbers.

Common test card numbers

• 4242 4242 4242 4242: Visa credit, approval.
• 4000 0566 5566 5556: Visa debit, approval.
• 5555 5555 5555 4444: Mastercard credit, approval.
• 5200 8282 8282 8210: Mastercard debit, approval.
• 3782 822463 10005: American Express, approval.
• 6011 1111 1111 1117: Discover, approval.
• 4000 0000 0000 0002: generic decline.

For an expiry date, use any month and year in the future. For the security code, use any three digits, or four digits for American Express. Billing address fields accept any plausible value unless the processor documents a specific test case for address verification.

How to use a test card number

1. Open your sandbox dashboard and confirm the account is in test mode, not live mode.
2. Copy a test card number from that processor's documentation, not from a random blog post.
3. Enter the number in your checkout form with a future expiry and any valid security code.
4. Submit the payment and watch the response in your dashboard or API log.
5. Confirm your application handles the returned status, such as succeeded, requires_action, or declined.
6. Repeat the test with a decline card to check your error messaging and retry logic.
7. Verify that no charge appears in your live balance and no email receipt reaches a real customer.

Triggering declines on purpose

Most gateways reserve a few numbers for failure paths. Stripe, for example, uses 4000 0000 0000 0002 for a generic decline and other numbers for insufficient funds, lost cards, and expired cards. Run at least one decline case before launch so you know what your user sees when a payment fails.

Rules for test data

• Never enter a real customer card number in test mode, and never enter a test number in live mode.
• Keep test keys out of production configuration and out of public code repositories.
• Do not use test numbers to probe a live merchant site. That activity is indistinguishable from card testing attacks and may be reported.
• Re-check the published list after a gateway migration, because test behavior can change between API versions.