Stripe Test Card Numbers Explained: Sandbox Cards

If you are wiring up payments and need a card that approves a charge without touching real money, the answer is 4242 4242 4242 4242 in Stripe test mode. That number, and the rest of Stripe's published set, are real card numbers in format but inert in function: they pass the same Luhn and brand checks as a live card, yet they map to no account and authorize no funds ^{[stripe-testing]}. This guide explains what test cards are, why processors publish them, the canonical Stripe cards for every outcome, and how test mode keeps them safely separated from real payments.

What are test card numbers and why do processors publish them?

A test card number (also called a sandbox card) is a payment card number that a processor reserves specifically for development. It is Luhn-valid and brand-correct, so it survives client-side validation and looks like a Visa, Mastercard, or Amex to your code, but it is non-chargeable: it resolves to no issued account and authorizes no transfer of funds ^{[stripe-testing]}. Stripe, PayPal, Adyen, and every other major processor publish their own sets so that developers never need to touch a real card while building a checkout.

Processors publish these for a regulatory reason as much as a convenience one. Under PCI DSS, handling real cardholder data pulls your systems into a strict compliance scope covering storage, transmission, and access controls ^[pci-dss]. Test cards let you exercise the full payment path, including authorization, capture, declines, and refunds, without any real Primary Account Number (PAN) ever entering your fixtures, logs, or databases. To produce arbitrary format-valid numbers for the surrounding test data, you can generate Luhn-valid sandbox test cards on demand and reserve Stripe's documented numbers for behaviors that must match a specific outcome.

Are Stripe test cards Luhn-valid but non-chargeable?

Both are true at once, and the combination is the whole point. Payment forms and card libraries run the Luhn checksum locally before they ever call Stripe, rejecting mistyped numbers at the form. A test card therefore has to pass that arithmetic or it would never reach the API ^[luhn]. Stripe satisfies this by reserving genuine, never-issued PANs whose final digit is a correct Luhn check digit, so they clear local validation and brand detection while still pointing at nothing real.

The non-chargeable half comes from the environment, not the number itself. A test card only behaves as documented when it is sent with test API keys against Stripe's test infrastructure. The same digits submitted to a live endpoint are simply declined. We walk through the checksum math, worked examples, and code in /blog/luhn-algorithm-explained, and you can confirm any candidate number with our /tools/credit-card-validator.

What are the canonical Stripe test card numbers?

Stripe documents a stable set of cards for the common networks. Each one approves a payment in test mode when paired with any future expiry date (for example 12/34) and any CVC (3 digits, or 4 for American Express) ^{[stripe-testing]}. The numbers below are the generic success cards per brand.

Notice that the success cards span the same prefixes and lengths real cards use: Visa starts with 4 at 16 digits, Mastercard uses 51-55 and the 2-series, and Amex uses 34/37 at 15 digits with a 4-digit CVC. That fidelity is deliberate, so your brand-detection and length-validation logic gets exercised the same way it would in production. If you need many format-correct numbers for a single brand rather than Stripe's fixed set, the generator offers per-network variants such as Visa sandbox test cards.

How do I test declines and insufficient funds?

Approvals are the easy half. Robust checkout code also has to handle the dozens of ways a charge can fail, and Stripe publishes a dedicated card for each so you can assert that your UI shows the right message and your server records the right state. Every decline card returns a specific error code and, where applicable, a decline code ^{[stripe-testing]}.

Wire each of these into an integration test. The insufficient-funds and generic-decline cards verify that a customer sees a recoverable message and can retry, the expired and incorrect-CVC cards confirm your field-level validation messaging, and the always-blocked card lets you check that a Radar block surfaces correctly without exposing the underlying risk score to the user.

How do I test 3D Secure and authentication?

Many regions require Strong Customer Authentication (SCA), which triggers a 3D Secure challenge where the cardholder confirms the payment with their bank. Stripe provides cards that force this flow so you can verify the challenge screen renders and the redirect back into your app completes ^[stripe-3ds].

What is the difference between test mode and live mode?

Stripe runs two fully isolated environments. Test mode and live mode have separate data, separate dashboards, and, critically, separate API keys. Objects created in one never appear in the other, so a test customer or charge can never leak into your real ledger ^{[stripe-keys]}.

The key prefix tells you which environment a request hits. Anything beginning pk_test_ (publishable) or sk_test_ (secret) runs in test mode and accepts test cards; anything beginning pk_live_ or sk_live_ processes real money. A frequent integration mistake is mixing a test publishable key on the client with a live secret key on the server, which produces confusing key-mismatch errors, so confirm both ends use the same mode.

Don't use real card details. The Stripe Services Agreement prohibits testing in live mode using real payment method details. Use your test API keys and the documented test card numbers.

Why you must never put a real card in a test

Beyond Stripe's own prohibition, dropping a real PAN into test code, fixtures, or logs is a serious PCI DSS problem. The moment real cardholder data lands in a repository or a log file, those systems fall into PCI scope and must satisfy controls around encryption, retention, and access that test infrastructure is rarely built to meet ^[pci-dss]. A real card pasted into a test fixture is the kind of thing that surfaces in a breach or a leaked repo.

• Never paste a real card number into a test, a seed script, a ticket, or a commit message.
• Use Stripe's documented test cards for processor-specific behaviors (success, decline, 3DS).
• For surrounding sample data, use never-issued, Luhn-valid generated numbers instead of real ones.
• Keep test and live API keys in separate secrets and never hardcode either in source.
• Scrub PANs from logs and error reports so a real number can never be captured by accident.

Generating your own sandbox card numbers

Stripe's documented cards are perfect for asserting a specific outcome, but they are a small fixed set. When you need volume, for example seeding hundreds of orders or stress-testing a validation routine, generate format-correct numbers that were never issued: choose a network prefix, fill the account identifier, then append a correct Luhn check digit so the number passes local validation ^[luhn]. This is the same approach faker-style libraries use for their card providers.

Our credit card generator does exactly this, emitting Luhn-valid, brand-correct numbers for every major scheme, with per-network options like Visa sandbox test cards for targeted fixtures. Treat the output as synthetic by definition: it satisfies the format and exercises your parsing and validation code, but for behaviors that depend on Stripe's response, reach for the documented cards above and confirm formatting with the /tools/credit-card-validator.

A quick checklist before you ship a payment flow

1. Confirm both client and server use the same mode (pk_test_ with sk_test_).
2. Verify a clean approval with 4242 4242 4242 4242 and any future expiry.
3. Drive at least one decline, including insufficient funds, and check the user-facing message.
4. Run the always-authenticate 3DS card and confirm both the success and cancel return paths.
5. Grep your code, fixtures, and logs to be certain no real PAN is present anywhere.

Build these checks once and they pay off on every change to checkout. Pairing Stripe's documented cards with generated synthetic numbers and the /tools/credit-card-validator covers both the processor-specific behaviors and the broader format validation your code depends on.