A fake CVV for testing is a made-up 3 or 4 digit security code used with a published test card number inside a payment sandbox. No bank account backs it, so the charge never settles and no issuer sees the request. Processors such as Stripe, PayPal, and Adyen publish these codes along with test card numbers so developers can test checkout, subscription, and refund flows without spending real money.
What Is a Fake CVV for Testing?
The term covers two things: a documented test CVV value from a processor's developer docs, and any 3 or 4 digit string you invent to fill a sandbox form.
Both work in test mode only. In a live transaction the CVV gets checked against the issuer's records, and a made-up number comes back as a decline.
Why Sandboxes Accept a Made-Up Code
A sandbox skips the card network. The processor's test environment reads the card number, matches it to a known test card, and returns a scripted result.
Since nothing leaves the sandbox, the CVV field acts as a placeholder. Stripe's test cards accept any 3 digit CVC, and any 4 digit CID for American Express.
What a Real CVV Does
A CVV is a 3 digit code on the back of Visa, Mastercard, and Discover cards, and a 4 digit code on the front of American Express cards.
Issuers generate it when the card is printed. The value stays out of merchant databases, which is what makes it a useful fraud check at authorization.
Which Test CVV Values Do Processors Publish?
Most processors publish a short list of test cards. Each card maps to an expected result, and the CVV field is either open or fixed.
- Visa: 4242 4242 4242 4242 with any future expiry date and any 3 digit CVC.
- Mastercard: 5555 5555 5555 4444 with any 3 digit CVC.
- American Express: 3782 822463 10005 with any 4 digit CID.
- Discover: 6011 1111 1111 1117 with any 3 digit CVC.
- PayPal sandbox: card numbers generated per test account in the developer dashboard.
- Adyen and Braintree: their own lists, with CVV values that vary per card.
Use the list from your own processor. A card that passes in one sandbox can return a different result in another.
Does the Test CVV Need to Match the Card Number?
No. In test mode the processor does not compare the CVV to the card number. It checks that the field has the right length and format.
Visa, Mastercard, and Discover cards need 3 digits. American Express needs 4 digits. A wrong length triggers a form error before the request reaches the processor.
Luhn Check and BIN Ranges
Checkout forms run a Luhn check on the card number before submitting. Test cards from processor docs pass it because they follow the same format as live cards.
The first six digits, the BIN, tell the form which brand to expect. A Visa test card starts with 4, Mastercard with 5 or 2, and Amex with 34 or 37.
How Do You Test CVV Declines?
A random code will not trigger a CVV failure in most sandboxes. Use the dedicated decline cards instead.
- 4000 0000 0000 0127 returns an incorrect CVC error in Stripe's test mode.
- 4000 0000 0000 0002 returns a generic decline.
- 4000 0000 0000 9995 returns an insufficient funds error.
Check your processor's docs before you build test cases. Decline scenarios get added and renamed as gateways change.
Why a Fake CVV Fails on a Live Payment
The issuer validates the CVV at authorization. A code that does not match the issuer's record returns a decline, and the merchant sees a CVV mismatch code.
There is no browser trick around that check. The CVV never gets stored on the merchant side, so no form field or script can bypass validation.
Test cards stop working the moment you swap the API key from test to live. A live gateway rejects them at the BIN level.
How Do You Set Up a Test Checkout Flow?
- Switch your API key from live to test in the processor dashboard.
- Load a published test card and a matching CVV length into the payment form.
- Run a successful charge to confirm the happy path works end to end.
- Run a decline card to confirm your error handling surfaces the right message.
- Run a refund and a subscription renewal against the same test card.
Keep a spreadsheet of the cards you use and the result each one returns. That record saves time when a teammate picks up the test suite later.
Rules for Handling Test Card Data
Treat test cards as data, and keep real card data out of your codebase. PCI DSS Requirement 3.2 bans storing the CVV after authorization, even in encrypted form.
- Store test keys in environment variables, not in source files.
- Never commit real card numbers or CVVs to a repository.
- Use hosted fields so card data never touches your server.
- Log a decline code, not the card number.
FAQ
Can I use a fake CVV on a real website?
No. A live checkout sends the code to the issuer, and a made-up value returns a decline. Test numbers only work in sandbox mode.
Where do I find official test card numbers?
Stripe, PayPal, Adyen, Braintree, and Authorize.Net publish test cards in their developer docs. Use the list from your own processor, since formats differ between gateways.
Is using a fake CVV illegal?
Testing with published sandbox cards is legal. Using card data that belongs to someone else is a federal crime under 18 U.S.C. § 1029, with penalties that include prison and fines.
Do test cards work in production mode?
No. Live gateways reject test BINs. You need a real card or a processor-approved test merchant account to check production behavior.
The Bottom Line
A fake CVV for testing is a sandbox tool, not a shortcut past real fraud checks. Use published test cards, confirm the CVV length matches the brand, and keep real card data out of your systems.