The fastest way to get a working mock CVV is to pull the fixed test CVC that ships with your payment gateway's sandbox card list. Stripe, Braintree, Adyen, and Authorize.Net each publish test card numbers paired with a specific CVC, and those values pass the same format and Luhn checks that run against live traffic. The criteria that matter are narrow: does the sandbox accept the value, does your own validation logic still execute, and does every byte of the test data stay fake. This guide covers test environments only. Real cardholder CVV data has no legitimate resale market, and buying or selling it is a federal crime in the United States.

What a mock CVV actually is

A mock CVV, sometimes called a test CVC or dummy CVV, is a three or four digit number that exists only inside a payment sandbox. It is not tied to a real account, not issued by a bank, and not validated by any card network. When you type it into a test checkout form, the gateway's test mode reads it, applies its format rules, and returns a simulated authorization response.

Three traits separate a mock CVV from a real one:

  • It maps to a test card number published in vendor documentation.
  • It never reaches an issuer, so no authorization request leaves the sandbox.
  • It can be reused across unlimited test transactions without triggering fraud rules.

Where mock CVVs come from

Gateway test card tables

Every major processor maintains a documentation page listing test card numbers. Each entry includes an expiry date and a CVC. Stripe uses values such as 123 for most test cards. Braintree publishes its own set. Adyen and Authorize.Net do the same. These are the safest source because they are guaranteed to return a predictable response code.

Self-generated mock values

Some testers skip the vendor list and generate their own digits. That works in sandboxes that do not validate CVC at all, which is common for decline and error simulation.

  • Pros: no dependency on vendor docs, easy to script, useful for fuzzing length and character validation.
  • Cons: may produce an unintended decline, hides real gateway behavior, and gives no reference response to compare against.

Format rules your form still has to enforce

Test mode relaxes authorization, not input validation. A checkout form that accepts a mock CVV should still enforce the same shape it enforces in production:

  • Visa, Mastercard, and Discover: three digits on the back of the card.
  • American Express: four digits on the front, above the card number.
  • Numeric only, no spaces, no letters, no leading field labels inside the input.
  • Rejected when the card number fails the Luhn checksum or the length does not match the detected brand.

Test this pair together. A form that accepts 123 for a 16 digit Visa but also accepts 123 for a 15 digit Amex has a brand detection bug, and the mock CVV is what exposes it.

Gateway test cards versus custom mocks

Gateway test cards

  • Pros: documented, stable, return known success and decline codes, safe to commit to a test fixture file.
  • Cons: limited set, tied to one processor, occasionally rotated when a vendor retires a sandbox card.

Custom mock values

  • Pros: unlimited combinations, good for edge case coverage, works across multiple gateways with one fixture.
  • Cons: no guaranteed response, requires you to verify behavior yourself, can mask a gateway that quietly accepts anything.

When to use each approach

Use gateway test cards when you are building or debugging an integration and need a predictable approved response. Use custom mock values when you are writing validation unit tests for the card form itself, where the network response does not matter and you only care whether your code rejects bad input. Most teams need both, and the split is usually clean: gateway cards in end to end tests, custom mocks in unit tests.

The legal boundary around CVV data

A mock CVV has value because it is fake. A real CVV has no legal resale channel. Under PCI DSS, the CVV must not be stored after authorization, which means there is no legitimate database of CVV values for anyone to sell. Listings that advertise real card verification values are selling stolen data, and using one to complete a purchase is fraud. If a project needs card data for testing, the sandbox is the only source.