What a CVV test use case is

A CVV test use case is a scripted check that your checkout form, tokenization layer, or gateway integration handles the three or four digit card security code correctly. You run it in a sandbox with test card numbers issued by your payment processor. You do not run it with real cardholder data outside an authorized live transaction.

cvv test procedure

The goal is narrow: prove that valid codes approve, invalid codes decline with the right reason, bad input is blocked before it reaches the gateway, and the code is never retained after authorization.

cvv test example

Prerequisites

  • Sandbox credentials from your payment processor
  • The processor's published test card list, including the CVV values that ship with each number
  • Access to gateway request and response logs
  • A staging build of the checkout page
  • A copy of your card brand's CVV length rules

How to run the test

  1. Open the processor's test card documentation and copy one card number with its matching CVV.
  2. Load the staging checkout and enter the test card number and expiry date.
  3. Enter the matching CVV and submit the form.
  4. Confirm the gateway returns an approval and that the code is not written to your order database.
  5. Repeat the same card with a mismatched CVV and confirm a CVV-specific decline code comes back.
  6. Repeat with an empty CVV field and confirm client-side validation blocks submission.
  7. Enter three digits on a brand that requires four and confirm the length check fires.
  8. Enter letters, spaces, and symbols and confirm the field rejects non-numeric input.
  9. Inspect the logged request payload and confirm the code is masked or absent outside the authorization call.
  10. Repeat every case for each card brand you accept.

Test matrix to cover

  • Match: correct CVV for the test number, expect approval
  • Mismatch: wrong CVV, expect a security code decline
  • Missing: empty field, expect a validation error before the network call
  • Wrong length: too few or too many digits
  • Wrong type: letters, punctuation, pasted whitespace
  • Retry after decline: confirm no CVV value is cached or reused
  • Token reuse: confirm a stored token does not require or expose the code

Common failures

  • Decline mapping that returns a generic failure for every CVV error, which hides the real cause from support
  • Validation that runs only on the client, allowing malformed codes through the API
  • The code landing in application logs, analytics events, or error trackers
  • Length rules hardcoded to three digits, which breaks on four-digit brands

Compliance limits

PCI DSS forbids storing the card verification value after authorization, in any form, including hashed or encrypted. Test runs must use processor-issued test numbers only. Real card data in a sandbox violates both the processor agreement and your merchant terms, and it turns a routine validation test into a data handling incident.

cvv test use case