If you are a developer building a checkout flow, a fraud rule, or a subscription module, you need fake card numbers that act like real cards but settle to nothing. Real cards belong nowhere near a test database. Dummy or test cards are the right answer, and every major payment processor publishes a set for sandbox use.
This 2026 guide covers what counts as a safe dummy credit card number, where to find them, and the rules to follow so test data never leaks into production. If you are also evaluating what processors charge, see how credit card processing fees for small businesses compare across providers.
What Counts as a "Dummy" Credit Card Number
A dummy or test credit card number is a Luhn-valid 16 to 19 digit string that processors recognize as test data. It looks real to most checkout pages but never charges a real account. Two categories live under the label:
- Sandbox-issued test cards. Numbers published by Stripe, Adyen, Braintree, Square, PayPal, and other processors. They only work inside that processor's sandbox or test mode.
- Luhn-valid generated numbers. Strings produced by an online generator that pass the Luhn checksum. These pass front-end validation but fail at the gateway, which is sometimes useful for testing form-side logic only.
For anything past the form layer, always use sandbox-issued test cards from the processor you actually integrate with.
Stripe Test Cards
Stripe publishes the most-used test card numbers in 2026. The full list lives at docs.stripe.com under "Testing." The most common:
- 4242 4242 4242 4242 (Visa, succeeds)
- 4000 0566 5566 5556 (Visa debit, succeeds)
- 5555 5555 5555 4444 (Mastercard, succeeds)
- 3782 8224 6310 005 (American Express, succeeds)
- 4000 0000 0000 0002 (declined, generic)
- 4000 0000 0000 9995 (insufficient funds)
- 4000 0027 6000 3184 (3D Secure 2 authentication required)
Use any future expiration date and any 3 or 4 digit CVC. Stripe also publishes special numbers for SCA, dispute simulation, and Radar fraud testing.
Adyen Test Cards
Adyen has a deep set of test cards for every Visa, Mastercard, Amex, JCB, Discover, and Diners scenario in their docs. Common ones:
- 4111 1111 4555 1142 (Visa, success)
- 5454 5454 5454 5454 (Mastercard, success)
- 3700 0000 0001 002 (Amex, success)
- 4000 0200 0000 0000 (declined)
Adyen test numbers also support 3D Secure 2 friction simulation, which is critical when you build a checkout that has to handle SCA.
Braintree, Square, and PayPal Test Cards
Braintree publishes test cards that overlap with the Stripe set, including 4111 1111 1111 1111 for a generic Visa success. Square's sandbox accepts 4111 1111 1111 1111 for a generic success and 4000 0000 0000 0002 for a generic decline. PayPal sandbox uses generated buyer accounts in their developer dashboard, with test cards tied to each buyer.
The rule of thumb is simple: use the test cards from the docs of the processor you integrate with. A Stripe test card will not run successfully against a Braintree sandbox.
What Dummy Cards Are Not For
A dummy credit card number is not a way to make a real purchase. The numbers are flagged everywhere outside the sandbox. If you try to use one on a real merchant, the gateway will decline it or your account may get flagged for fraud, even when the attempt fails.
Dummy cards are also not for testing real consumer credit-building products. If you want to build credit, you need a real credit builder card that reports to the bureaus, like the Self Visa® Credit Card or OpenSky.
How to Generate Luhn-Valid Numbers Safely
If you only need a string that passes form-side validation, online generators produce Luhn-valid 16 digit numbers. A few rules:
- Never store the generated numbers next to real customer records, even in dev databases.
- Always tag the data as test in your schema so it never accidentally ships.
- Pair generated numbers with synthetic name and address data, never your own real info.
For anything that touches a real gateway, abandon generated numbers and use the sandbox set published by the processor.
Common Mistakes Developers Make
- Using a real card to test a flow. Even a $0 authorization can trigger fraud rules at your bank. Always use a sandbox card.
- Hardcoding test cards in production code. A junior dev once shipped 4242 4242 4242 4242 to a live checkout, which let any user bypass payment by using that string. Always switch to live cards in production by config flag.
- Mixing sandbox and live keys. Set up two distinct projects in your processor dashboard. Use environment variables. Never reuse a key.
- Skipping the 3D Secure flows. SCA is mandatory in many regions. Test the 3D Secure 2 friction path with the right test card before you go live.
Security Rules for Storing Card Data, Even Test Data
PCI DSS does not technically apply to test card data, but bad habits start in dev. Treat test data the way you treat real data:
- Do not log full card numbers, even in test environments.
- Use tokenization in your sandbox the same way you do in production.
- Rotate API keys quarterly.
- Review your payment-form code for any client-side console logging that could leak PAN data.
If your team handles real production card data, use a PCI-compliant tokenization vault from your processor. Stripe Elements, Adyen Drop-in, and Braintree's hosted fields are common picks because they keep raw card data out of your servers.
A Real Card for Testing Your Own Tools
Developers sometimes need a real card to confirm a real transaction in a sandbox-to-live promotion. For testing real-world purchases without exposing a high-limit personal card, a small starter card like the Self Visa® Credit Card or Current Build Card has a low credit line that limits the blast radius if something goes wrong. Both report to the major bureaus and approve thin or zero-credit applicants. You can track your credit score for free to measure the impact as you use the card.
A $200 to $500 limit card is plenty for testing dropshipping, subscription, or e-commerce flows.
Related: Credit Cards for New Users: How to Get Approved With No History
Frequently Asked Questions
Are dummy credit card numbers safe to use in test environments?
Yes, when you use the test card numbers published by your processor's documentation. They only work inside that processor's sandbox and never charge a real account.
Can a dummy credit card number be used to make a real purchase?
No. Real merchants never accept sandbox or generated test card numbers. Trying to use one can flag your account for fraud, even when the attempt fails.
Where do I get test card numbers for Stripe?
Stripe publishes its complete test card list at docs.stripe.com under "Testing." Common picks include 4242 4242 4242 4242 for a successful Visa charge and 4000 0000 0000 0002 for a generic decline.
Can I use the same test card for Stripe and Braintree?
Not reliably. Each processor has its own sandbox, and test cards only work inside the processor that issued them. Always use the test card list from the processor your code is integrating with.
