A CVV test input is a fake card verification value you type into a payment sandbox to simulate a transaction. In test mode, gateways skip the real checksum rules that guard live cards, so most accept any three digits. A few providers publish specific values that force a CVV mismatch decline, which lets you test your failure path. The "v4" label almost always marks the fourth revision of a QA input sheet or an API version, not a separate class of number.
CVV Test Input V10: What You Need to Know
What a test CVV does and does not do
A test CVV exercises the same field, validation logic, and response codes as a live CVV. It does not touch a real cardholder account, does not move funds, and does not need to match any bank record. Gateways route the request to a simulator that returns a canned result: approved, declined, or an error code you can assert against in automated tests.
Three digits is the standard length for Visa, Mastercard, and Discover test cards. American Express uses four. If your form hardcodes three, an Amex test case will fail before it reaches the gateway.
CVV Test Input V8 Buying Guide
Prerequisites
- A sandbox or test-mode account with your payment provider.
- A published test card number from that provider's developer reference.
- A non-production endpoint so no live money can move.
- Access to the provider's test response and decline codes.
How to submit a CVV test input
- Pull up your provider's test card list and copy one card number.
- Switch your integration's environment flag to test or sandbox.
- Enter a future expiry date, such as 12/34.
- Type a three digit CVV. The common default across gateways is 123.
- Submit the charge and read the response code in your logs.
- Run the same charge again with the provider's mismatch trigger value.
- Confirm your UI shows the decline message you wrote for a CVV failure.
- Repeat with a four digit value against an Amex test card.
Values that trigger specific results
Some gateways assign meaning to particular test CVVs so you can reach a branch without editing code. Stripe, for example, treats any three digits as valid in test mode but lets you force a CVV check failure through its decline test cards. Adyen and Braintree publish similar trigger sets. Read your provider's table before you invent values, because a number that returns "approved" on one gateway can return "invalid cvc" on another.
If your provider has no trigger list, you can still test the failure path by sending an empty CVV field, a two digit value, or a string of letters. Those inputs hit local validation before the network call, which is a different test than a gateway decline.
Mistakes that break test runs
- Using a live key in the test environment, which produces real authorizations.
- Assuming one gateway's trigger values work on another.
- Testing only the happy path and never the mismatch decline.
- Hardcoding three digits and skipping Amex coverage.
- Logging the full CVV field in application output.
Handling rules you cannot skip
PCI DSS requirement 3.2 forbids storing the card verification value after authorization, in test or live systems. That rule applies to your logs, your database, and your support tickets. Test values are not sensitive, but the habit of capturing the field is. Write your integration so the CVV passes through memory, gets sent, and is never written to disk. If you need a record for debugging, store the response code instead of the input.
Never paste a real card number into a sandbox to "see what happens." Real card data in a test environment breaks your PCI scope and gives you no extra signal. Published test numbers reproduce every response you need.
Quick reference
- Default test CVV, three digit cards: 123
- Default test CVV, Amex: 1234
- Local validation failure: blank field, 1 to 2 digits, or letters
- Gateway mismatch decline: the trigger value in your provider's table