Start here
If you need a dummy card number, take it from your payment processor's official sandbox documentation. These are non-functional test strings published so developers can run approvals, declines, refunds, and 3D Secure flows without touching a real account. Anything advertised for sale as a card number or CVV is a different product entirely, and a dangerous one. Stolen card data is illegal to possess or use, and fabricated card data is the standard bait in carding scams. The only dummy card numbers worth your time are the ones a processor hands you in writing.
What a dummy card number actually is
A dummy card number, sometimes called a test PAN or sandbox card, passes the same format validation as a live card while being tied to no account and no funds. Good test data mirrors production behavior closely enough that your checkout code exercises every branch it will hit in the real world.
- An issuer prefix reserved by the processor for testing, so it never collides with a live bank identification number.
- A valid Luhn checksum, so client-side validation runs the same path as production input.
- A future expiration date, so expiry checks do not reject the test before it reaches the gateway.
- A CVV placeholder, usually three digits, or the specific value the sandbox expects.
- A documented behavior map showing which numbers approve, which decline, and which trigger a challenge.
What to look for in a test card set
Judge a sandbox set by coverage and documentation, not by how many numbers it lists. A useful set covers approvals, soft declines, hard declines, insufficient funds, expired card responses, incorrect CVV, and at least one 3D Secure authentication path. Each entry should come with the exact response code it produces and the region or currency it simulates. If a source cannot tell you what a given test number returns, it is not test data, it is a number someone typed into a text file.
Parameter bands to expect
- Length: 15 to 19 digits, depending on the network format being simulated.
- CVV: three digits for most networks, four for American Express style formats.
- Expiration: sandbox dates usually sit at least a year ahead of the current date.
- Decline coverage: a complete set maps at least five distinct failure reasons.
- Currency: major sandboxes support several settlement currencies, sometimes with separate test ranges.
Pitfalls to avoid
- Testing with real card data. Storing or transmitting a real CVV after authorization violates PCI DSS, even in a development database.
- Buying numbers from a forum or messaging app. You either receive stolen data or a string that fails at the gateway, and you have handed your own details to a criminal.
- Assuming a test number works across providers. Every sandbox is separate, so a number from one processor often fails at another.
- Logging full card fields in development tools. Test data habits become production habits.
- Confusing a dummy number with a network token. Tokens are generated from real cards and behave differently.
FAQ
Are dummy card numbers legal?
Yes, when your payment processor publishes them for sandbox testing. They carry no account and no value. Numbers sourced from carding markets are not the same thing and carry real legal exposure.
Can I use a dummy card number on a live website?
No. A live gateway will reject it, and pointing a production terminal at test credentials can trigger risk flags on your merchant account.
Why does my test card keep declining?
Most often you are hitting the live endpoint instead of the sandbox, or you are using a number whose documented behavior is a decline. Check the response code against your processor's test matrix.
Do I need a real CVV to test my checkout?
No. Sandboxes accept placeholder values, which is the point. Card networks and PCI rules prohibit retaining the CVV after authorization, so never design a workflow that depends on storing one.