Fake CVV for Testing: Sandbox Test Card Values Explained

For testing a checkout or subscription flow, the top pick is a test card number published by your own payment processor, combined with any CVC value the sandbox accepts. Stripe's documented test cards are the common example: in test mode, 4242 4242 4242 4242 succeeds with any three digit CVC. The criteria used here are narrow. The number must come from the processor's own documentation, it must only work against a sandbox endpoint, and it must never require a real cardholder's data.

What a test CVV actually is

A sandbox does not verify the CVC against an issuing bank. There is no bank in the loop. The gateway decides the result from the card number you submit and from the rules of its test environment. Some processors return CVC check failures for specific test numbers so you can exercise that decline path. Others ignore the field entirely and return success. That means a fake CVV has no meaning outside the test environment it was designed for.

Option 1: Processor-published test cards

• Pros: documented, stable, free, and updated when the API changes. They cover success, decline, insufficient funds, and CVC failure paths.
• Pros: no legal exposure and no risk to a real account.
• Cons: they only work inside that processor's sandbox. A Stripe test number will not behave the same way at a different gateway.
• Cons: behavior can shift between API versions, so old blog posts go stale.

Use it when you are building against one gateway and need predictable results in automated tests. Pin the test numbers you rely on in a fixtures file next to your test suite, and read the processor's current documentation before you debug a failure.

Option 2: Sandbox cards from a second processor

• Pros: useful when you support multiple gateways and want coverage across each integration.
• Pros: Adyen, Braintree, and similar providers maintain their own test card lists with clearly labeled outcomes.
• Cons: naming conventions and error codes differ, so test assertions rarely transfer between providers.
• Cons: more documentation to track and more sandbox credentials to keep separate.

Use it when your integration layer wraps more than one processor, or when you are evaluating a provider before committing to it.

Option 3: Luhn-valid numbers you generate yourself

The Luhn algorithm, also called the mod 10 check, is the checksum that card numbers satisfy. You can generate a sixteen digit string that passes it and use any three digits as the CVC.

• Pros: built into your own unit tests with no third party dependency.
• Pros: good for testing client side input masks, length rules, and formatting.
• Cons: a Luhn-valid number carries no issuer meaning. It will not authorize anything against a live endpoint.
• Cons: a generated string can collide with a real account number. Never point generated numbers at production.

Use it when you are testing your own validation logic, not the gateway.

Why purchased CVV data is not a testing tool

Buying or selling real card data, including CVVs, is a federal crime in the United States under access device fraud statutes, and PCI DSS forbids storing the verification value after a transaction is authorized. Sites that advertise CVV sales are fraud operations. A common pattern is to take payment and deliver nothing, or to deliver data that was reported stolen and is already blocked. There is no legitimate testing scenario that requires real card data. If you need production-realistic behavior, use a sandbox, a tokenization service, or your processor's test mode.

Recommended setup

1. Copy the current test card list from your processor's documentation into a fixtures file.
2. Use any three digits for the CVC unless the documentation names a specific number for a CVC failure case.
3. Assert on the gateway's response code, not on the input values.
4. Keep sandbox keys out of production configuration and out of your repository history.