A test card is a synthetic card number published by a payment processor so you can simulate approvals, declines, CVV errors, and 3D Secure challenges in a sandbox without touching a real account. There is no legitimate "latest working link" to a card shop and no such thing as a safe place to buy live CVV or fullz data, because selling or purchasing stolen card records is a crime in the United States and most other countries. The card market known as Joker's Stash was reported to have closed in early 2021, and searches for its link today lead to scams, malware, or law enforcement decoys. Everything below covers sandbox testing only.
What a test card is and what it is not
- It is a sandbox artifact. Test numbers are tied to a processor's test environment and return scripted responses.
- It is not a live card. The same digits entered on a production gateway will fail authorization.
- It carries no funds. A test card can show a successful charge without any money moving.
- It is published openly. Stripe, Authorize.net, Adyen, and others document their test numbers in developer portals.
How the Luhn check works
The Luhn check, also called the mod 10 algorithm, is the first filter most checkout forms apply before a card number is sent to the processor. Starting from the rightmost digit and moving left, double every second digit. If a doubled value lands above 9, subtract 9 from it. Add all the digits together. If the total divides evenly by 10, the number passes.
Test card numbers are generated to pass this check, which is why they look plausible. Some sandbox suites also publish deliberately invalid numbers so you can verify that your form rejects a failing Luhn check and shows the right error message. Run the calculation on both a passing and a failing sample during QA, since a broken Luhn implementation is one of the most common causes of false declines.
CVV test values and expiry fields
Card verification value testing is about triggering the right response, not about guessing numbers. Most processors reserve one CVV value that approves, one that fails with a mismatch code, and sometimes one that returns an "unavailable" status when the issuer cannot respond. American Express uses a four digit code, so your input field, your validation, and your error copy all need to handle that case.
- Send the CVV only over TLS, and never write it to application logs or analytics events.
- Test the mismatch path, not just the success path, so your decline messaging is accurate.
- Check whether your gateway accepts a CVV result of "not processed" instead of forcing a hard fail.
3DS challenge testing
A 3D Secure test usually has two outcomes: frictionless, where the issuer approves without prompting the cardholder, and a challenge, where a test authentication page appears and asks for a code. Sandbox test cards are often assigned to one flow or the other, so you may need several test numbers to cover both.
Build for the messy parts of the round trip: the redirect back to your site, the browser tab that gets closed mid challenge, a session that expires, and a customer who retries after a failed authentication. Confirm that an authentication failure does not create a charge, and that a successful challenge is recorded on the order so support can trace it later.
Authorize.net test card behavior
Authorize.net test cards only work while the account is in test mode against the sandbox endpoint. In that mode the gateway returns simulated responses, including address verification and CVV result codes, so you can verify how your application maps each code to a customer-facing message. Before you switch to production, re-run your suite against live mode with a real card you own, because sandbox behavior and live issuer behavior are not identical.
Mobile CVV entry and checkout UX
CVV fields are the most common source of mobile checkout drop off. Small improvements matter more than a redesign.
- Set
inputmode="numeric"andautocomplete="cc-csc"so the right keypad opens and autofill works. - Allow paste. Blocking it frustrates customers and does not stop fraud.
- Validate on blur, not on every keystroke, so users do not see an error before they finish typing.
- Keep the card number, expiry, and CVV in one visual group on narrow screens.
- Write error text that says what to do, such as "Check the 3 digit code on the back of your card."
Compliance and safe practice
PCI DSS rules apply to anyone who stores, processes, or transmits card data, and they do not exempt test environments that touch real numbers. Use synthetic test cards for every scenario, keep production keys out of development builds, and tokenize card data so your servers never hold a full primary account number. If a vendor offers to sell you fresh CVV or fullz data, that offer is itself evidence of a crime, not a testing tool.