What a CVV test input is
A CVV test input is a fake three- or four-digit verification value paired with a test card number inside a payment gateway sandbox. It never touches a real account. Developers use these values to confirm that the checkout form validates the field, that the gateway returns the decline code they expect, and that the order record stores the response correctly. Each processor publishes its own test values, and they only resolve inside test mode.
Prerequisites
- A sandbox account with a payment processor such as Stripe, Adyen, Braintree, or Authorize.net
- Test API keys loaded in your development environment, never live keys
- A test card number issued by that same processor
- Access to the gateway response log so you can read the returned code and reason
How to run a CVV test
- Open the sandbox dashboard and copy the test publishable and secret keys.
- Point your checkout form at the processor's test API host.
- Enter a test card number taken from the processor's documentation.
- Enter a test CVV from the same list, commonly 123, 999, or 000.
- Submit the payment and open the raw response body.
- Compare the returned decline code against the processor's error reference.
- Repeat the request with a two-digit value to confirm your client-side check blocks it before the call reaches the gateway.
- Record the result in your test matrix and move to the next case.
Values that trigger specific responses
Processors map selected test CVVs to fixed outcomes so you can exercise each branch of your error handling.
- Any three digits with a generic approval test card returns a successful charge in most sandboxes.
- A value from the processor's CVV failure list returns a decline with a CVV mismatch reason code.
- An empty field returns a client-side validation error and no gateway call.
- A four-digit value on a Visa or Mastercard test card is rejected, because those brands use three digits.
- A three-digit value on an American Express test card is rejected, because that brand uses four.
Why real card data never belongs in a test
PCI DSS forbids storing the verification value after authorization, in any form, encrypted or hashed. That rule applies to your test database too. Running a real card number with a guessed CVV against a live endpoint is card testing, a pattern the FTC treats as fraud, and in the US it falls under 18 U.S.C. 1029. If your QA team wants realistic field lengths, pull synthetic numbers from the processor's test card generator. Test values only work against test keys, so a mismatch between key type and endpoint will surface as an authentication error, not a CVV error.
Checklist before you ship
- Live keys absent from the repository and from environment files
- CVV field masked in the UI and excluded from logs
- Decline codes mapped to user-facing messages
- Test matrix covering approval, mismatch, empty, and wrong-length inputs
- Sandbox credentials rotated after the release