Get your dummy card numbers from the sandbox documentation of the processor you build on, and treat any other source as unusable. Test numbers published by gateways are static, pass the Luhn checksum, and route to a simulated authorization instead of a live account. A number marketed as a "dummy" or a "CVV" by a third party is not a test credential. Real card data paired with its verification value cannot be bought legally anywhere, and using it falls under card fraud and identity theft statutes. The rest of this guide covers what a legitimate test number looks like, the parameter bands that matter, and the mistakes that waste the most time.

What to look for in a test card number

• Published by the processor itself, in dated sandbox docs that ship with the API version you integrate.
• Mapped to a specific outcome so your code can branch on it: approval, generic decline, insufficient funds, expired card, or a step-up authentication challenge.
• Stable over time. A test PAN that changes every release breaks your fixtures and your regression suite.
• Available for every brand you accept, since Amex, Visa, Mastercard, and Discover handle length and verification codes differently.
• Documented alongside test expiry dates and test address verification values, so you can exercise the whole authorization request.

Parameter bands that matter

• Primary account number length: 15 digits for Amex, 16 digits for most Visa, Mastercard, and Discover test numbers.
• Checksum: the final digit must satisfy the Luhn algorithm, or the gateway rejects the request before it reaches the sandbox.
• Verification code length: 3 digits for Visa, Mastercard, and Discover; 4 digits for Amex.
• Expiry format: MM/YY for most forms, MM/YYYY where the field accepts four-digit years. Test dates should sit in the future.
• Test bank identification numbers are reserved ranges that were never issued to a cardholder, which is what keeps sandbox traffic separate from real accounts.

Common pitfalls

• Copying a card number out of a screenshot, forum post, or chat group. If it belongs to a real account, the test is fraud regardless of intent.
• Assuming one test PAN works across gateways. Each processor reserves its own ranges, and a number that approves in one sandbox can decline in another.
• Hardcoding a single number into the codebase. Cover at least one success path and two failure paths.
• Confusing a payment token with a dummy PAN. Tokens are processor-issued references, not numbers you can validate locally.
• Storing the verification value after authorization in anything that touches production data. PCI DSS Requirement 3.2 forbids retaining sensitive authentication data post-authorization.

FAQ

Are dummy card numbers real?

No. Reserved test ranges are never assigned to live accounts, so a charge against them cannot move money.

Can I use a dummy card number in a live storefront?

No. Live gateways reject them, and altering a test number to look live is an attempt to defeat fraud controls.

Where should test numbers come from?

From your processor's developer documentation and your own fixtures, generated from the documented test ranges.

Why do some test numbers fail three-domain secure authentication?

Sandboxes often simulate a challenge rather than completing it. Check the doc notes for which numbers force a challenge outcome.