Demo credit card numbers are test numbers that let you practice entering card information without risking real money or creating an actual account
A demo credit card number is a fake card number that payment systems accept during testing. Developers, designers, and companies use them to check whether their checkout pages work correctly before customers arrive. The numbers follow real card formatting rules — they have the right length, pass checksum validation, and trigger specific test responses — but they are not connected to any real bank account or person.
If you are building a website, testing payment software, or learning how online transactions work, demo numbers let you run through the entire payment flow without moving actual money. They are also called test card numbers or sandbox numbers, and they exist in a separate testing environment that never touches live banking systems.
Key Takeaways
- Demo card numbers work only in test environments created by payment processors like Stripe, Square, or PayPal — they will be rejected on real shopping websites.
- Different demo numbers trigger different test outcomes: some simulate successful charges, others simulate declines or fraud flags, letting you test error handling.
- The most widely used test number is 4242 4242 4242 4242, which simulates a successful Visa transaction in most payment systems.
- You can use any future expiration date and any three-digit security code when testing with demo numbers.
- Demo numbers are completely safe to share in documentation, tutorials, and code examples because they have no real money attached.
How demo numbers differ from real card numbers
A real credit card number is connected to a bank account and a person's identity. Charging it moves actual money. A demo number is a string of digits that a payment processor recognizes as a test signal. It goes nowhere near a bank.
Real card numbers are kept secret because anyone with the number, expiration date, and security code can attempt a charge. Demo numbers are published in documentation and tutorials because there is nothing to steal. They cannot be used to buy anything on a real store, and they cannot be used to drain an account.
Payment processors maintain separate testing environments where demo numbers work. When you use a demo number in a real checkout on a real website, the system rejects it when ready. The two environments never cross.
Common demo card numbers and what they test
Different payment processors publish their own test numbers, and different numbers within a system trigger different responses. This lets you test not just the happy path — the charge goes through — but also what happens when things go wrong.
| Demo Number | Card Type | Test Outcome | Used By |
|---|---|---|---|
| 4242 4242 4242 4242 | Visa | Successful charge | Stripe, Square, most processors |
| 5555 5555 5555 4444 | Mastercard | Successful charge | Stripe, Square, most processors |
| 378282246310005 | American Express | Successful charge | Stripe, Square, most processors |
| 4000 0000 0000 0002 | Visa | Charge declined | Stripe, Square |
| 4000 0000 0000 9995 | Visa | Charge declined (insufficient funds) | Stripe, Square |
| 4000 0000 0000 0069 | Visa | Charge flagged as lost card | Stripe, Square |
When you use 4242 4242 4242 4242 in a test environment, the payment processor approves the charge and returns a success message. When you use 4000 0000 0000 0002, it declines the charge and returns a decline code. This lets developers write code to handle both outcomes before a real customer ever enters a card number.
Each processor publishes its own full list of test numbers. Stripe's testing documentation includes numbers that trigger 3D find authentication, international responses, and specific error codes. PayPal has its own sandbox numbers. Square has its own. If you are building on a specific platform, check that platform's developer documentation for the exact numbers it recognizes.
Where demo numbers are used
Anyone building or testing a payment system uses demo numbers. This includes software developers writing checkout code, designers testing how a payment form looks, QA teams checking whether error messages display correctly, and educators teaching how online payments work.
Demo numbers also appear in tutorials, documentation, and code examples across the internet. You will see them in blog posts about building a Shopify store, in GitHub repositories, in payment processor guides, and in online courses about web development. They are safe to publish because they carry no risk.
If you are learning to code and you encounter a tutorial that asks you to test a payment form, the tutorial will give you a demo number to use. You can type it in, submit the form, and see what happens — all without any real transaction occurring.
Why demo numbers cannot be used on real websites
Real payment processors reject demo numbers when ready when they arrive in a live environment. The processor checks whether the number is in its test list, and if it is, the transaction fails before it ever reaches a bank.
This is a safety feature. It prevents someone from accidentally using a test number in production, and it prevents someone from trying to use a published demo number to make a fraudulent purchase. The separation between test and live is absolute.
If you try to use 4242 4242 4242 4242 to buy something on Amazon or any other real store, the checkout will reject it with a message like "Your card was declined" or "Invalid card number." The store's payment processor will not even attempt to contact a bank.
How to find demo numbers for your payment processor
Every major payment processor publishes test card numbers in its developer documentation. If you are building on Stripe, go to Stripe's testing documentation. If you are using Square, check Square's testing guide. If you are using PayPal, Braintree, or another processor, that processor has published its own list.
The documentation also explains what expiration date and security code to use. Most processors accept any future date for expiration and any three-digit number for the CVV or security code. Some processors have specific test codes that trigger specific responses — for example, a security code of 123 might trigger a fraud flag — so check the documentation for the full list.
If you are taking an online course or following a tutorial, the instructor will tell you which demo number to use and which processor's test environment to use it in. You do not have to hunt for the number yourself.
The difference between demo numbers and real testing practices
Demo numbers are one tool for testing payment flows. Real payment systems also use other approaches: test merchant accounts that process real transactions but in a sandbox environment, test customer accounts that can be created and deleted without affecting production data, and staging servers that mirror the live website but process no real money.
A complete testing strategy uses all of these together. Demo numbers let you test the form and the basic flow. A sandbox merchant account lets you test the full transaction lifecycle. A staging server lets you test the entire website in conditions that match production.
If you are building a payment system professionally, you will use demo numbers as a starting point, then move to more sophisticated testing as your system grows. If you are learning or prototyping, demo numbers are usually enough.
Frequently Asked Questions
Can I use a demo card number on a real shopping website?
No. Real payment processors reject demo numbers when ready in their live environments. The checkout will decline the card and display an error message. Demo numbers work only in test environments created by the processor.
Is it safe to share demo card numbers online?
Yes. Demo numbers are published in official documentation and tutorials specifically because they are safe to share. They are not connected to any real account or money, so sharing them carries no risk.
What expiration date and security code should I use with a demo number?
Most payment processors accept any future expiration date and any three-digit security code. Some processors have specific test codes that trigger specific responses, so check the processor's documentation. For basic testing, any future date and any three digits will work.
Do demo numbers work across all payment processors?
No. A demo number that works in Stripe's test environment may not work in Square's or PayPal's. Each processor maintains its own list of test numbers. Use the numbers published by the processor you are actually building on.
What happens if I accidentally use a demo number in production?
The payment processor will reject it before any real transaction occurs. The customer will see a decline message, and no money will move. This is by design — the separation between test and live environments prevents accidental use of test data in production.