Stripe's 4242 4242 4242 4242 is the test card number most developers reach for first, and it is the right starting point when you need a sandbox Visa payment to succeed without extra authentication. The criteria behind that pick: the number is published in the gateway's own test documentation, it passes the Luhn checksum, it approves in a sandbox with any future expiry date and any three or four digit CVC, and it does not trigger a 3D Secure challenge by default. The sections below cover what test numbers are, which sets the major processors publish, and how to choose one for a specific scenario.

What a test card number actually is

A test card number is a value that a payment processor's sandbox environment recognizes and routes to a simulator instead of the card networks. It is tied to a test merchant account, so no funds move and no real cardholder is involved. The same digits can be published by two different processors with different behavior, which is why the gateway documentation, not a random list, is the source that matters. A test number is not a CVV you can buy or use anywhere real, and it will be rejected by any live production endpoint.

The default pick: 4242 4242 4242 4242

This Stripe test Visa is the closest thing the industry has to a shared convention. It approves by default, accepts any CVC and any future expiry, and is recognized by plenty of developers who have never opened the Stripe docs.

• Pros: published in official documentation, Luhn valid, approves without a 3DS prompt, works for smoke tests and CI pipelines, easy for a whole team to remember.
• Cons: only exercises the happy path, tells you nothing about declines, insufficient funds, expired cards, or authentication flows, and some sandboxes treat it as a generic success response that skips brand specific rules.

Use-case recommendation

Use 4242 4242 4242 4242 for first integration runs, checkout UI checks, and automated test suites where the goal is a green pass. Switch to a scenario card the moment you need to prove your error handling works.

Stripe test cards for every branch

Stripe documents a full matrix, and the value is in the failure cases rather than the success case.

• 5555 5555 5555 4444 for a Mastercard approval.
• 3782 822463 10005 for an American Express approval, which also tests your four digit CVC field.
• 6011 1111 1111 1117 for a Discover approval.
• 4000 0000 0000 0002 for a generic card decline.
• 4000 0000 0000 9995 for an insufficient funds decline.
• 4000 0000 0000 3220 to force a 3D Secure 2 authentication step.

The Amex number matters more than people expect. It is the fastest way to catch a form that hardcodes a three digit CVC or rejects a 15 digit card length.

Braintree, PayPal, and Adyen

Braintree's sandbox documentation centers on 4111 1111 1111 1111 for a successful Visa authorization, with its own list for processor declines and AVS failures. Adyen maintains a test card set for its test environment that covers authorized, refused, and authentication required outcomes. Both publish the list inside their developer portals, and both expect you to use the values from the environment you are actually hitting. If you move an integration from one processor to another, re-run your card scenarios against the new sandbox instead of assuming the old numbers behave the same way.

Decline and error testing is the real work

Most production payment bugs show up in the unhappy path: a declined card that leaves an order in a pending state, a 3DS challenge that never returns, a network timeout that double charges. Scenario cards exist for exactly this. Pair each one with an assertion in your test suite, and check that your application writes the right order status, shows the right message, and retries or stops at the right moment.

Test numbers versus real card data

These are different categories, legally and technically. A test number is fake by design and only works in a sandbox. Real card numbers and their verification values belong to real cardholders, and using them without authorization is fraud in every US jurisdiction. The PCI Security Standards Council prohibits storing sensitive authentication data such as the card verification value after authorization, which is why test numbers exist in the first place: so you never need real card data to build and validate a checkout.

How to pick the right number for your test

1. Start in the docs for the processor you are actually integrating, not a third party list.
2. Confirm the number passes Luhn before you blame your form validation.
3. Pick the card brand that matches the edge case you are testing, including a 15 digit Amex for CVC field checks.
4. Add one decline card and one authentication card to every test suite, not just a success card.
5. Reset the sandbox between runs so a prior state does not mask a failure.

Treat the processor's test documentation as the source of truth, keep a short list of scenario cards in your repository, and your checkout will behave the same way in staging as it does in production.