A CVV test case is a documented QA scenario that checks how a payment form, checkout page, or gateway handles the card verification value: whether it accepts valid input, rejects malformed input, and returns the correct decline when the code does not match the issuer record. Testers run these cases in sandbox or certification environments using published test card numbers, never real cardholder data. A complete set covers format validation, mismatch responses, empty fields, and proof that the CVV is never stored or logged.

What does a CVV test case verify?

Each case pairs a specific input with a specific expected outcome, and the outcome is verified at the UI, the API response, and the database layer. The goal is confidence that the checkout behaves the same for every card brand and every failure mode.

  • Field length and numeric-only validation per card brand
  • Correct decline code when the CVV fails issuer verification
  • Behavior when the field is blank, padded, or contains letters
  • Confirmation that the CVV never appears in logs, API echoes, or stored records
  • Consistency between the card entry form and the payment processor response

CVV format rules to encode in validation tests

Format rules are the easiest place to start because they are deterministic and require no network call. They also catch most UI defects before a gateway is involved.

  • Visa, Mastercard, Discover, and JCB use a 3 digit code on the back of the card
  • American Express uses a 4 digit code, historically printed on the front
  • UnionPay cards commonly use 3 digits
  • No card brand applies a check digit algorithm to the CVV, so validation is length plus numeric content only

Positive CVV test cases

  1. Enter a valid 3 digit CVV on a Visa test card and confirm the authorization succeeds.
  2. Enter a valid 4 digit CID on an American Express test card and confirm the form accepts four characters.
  3. Submit a card with a matching CVV and confirm the response returns a match or pass code.
  4. Confirm autofill and paste populate the field without truncation.

Negative CVV test cases

  1. Submit a two digit CVV and expect a client side format error before any network request.
  2. Submit letters or symbols and confirm the field rejects non numeric input.
  3. Submit a CVV that does not match the issuer record and confirm the gateway returns a mismatch decline.
  4. Leave the field empty where the CVV is required and confirm checkout blocks submission.
  5. Submit an over length value and confirm it is truncated or rejected, not silently accepted.

What happens when the CVV field is left blank?

Many processors treat a blank CVV as "not processed" rather than a failure, so the authorization can still succeed while the fraud score rises. The test case should record which behavior the merchant account is configured for and assert that the checkout shows the right message to the buyer.

How do you test CVV mismatch declines?

Issuers return a range of responses, from match and no match to not processed and unavailable, and each maps to a different processor code. Build one case per response code your gateway documents, then assert that the order status, retry messaging, and fraud flags update as intended. Test both configurations where a mismatch blocks the sale and where it only downgrades the transaction.

Which test data should a CVV test case use?

Use card numbers published by your payment provider for sandbox testing; providers document numbers that accept any CVC value and numbers that trigger a specific CVC decline. Never paste a live card number into a test case document, a ticket, or a shared spreadsheet. Keep the test data in the sandbox and reference it by name in the test case rather than by value.

How does PCI DSS shape CVV testing?

PCI DSS treats the CVV as sensitive authentication data and prohibits storing it after authorization, which makes one test case mandatory for every release. That case verifies the CVV is not written to the database, not written to application logs, and not returned in API responses. Evidence usually comes from masked log samples plus a schema review, and auditors expect to see it.

What are common mistakes in CVV test coverage?

  • Testing only 3 digit brands and skipping the 4 digit American Express path
  • Checking the happy path but never verifying a mismatch decline code
  • Ignoring mobile keyboards, paste behavior, and autofill
  • Forgetting to assert that the CVV is absent from logs and stored records
  • Reusing production data, which turns a QA task into a compliance incident

How should you document a CVV test case?

Record an ID, the precondition, the exact steps, the sandbox card reference, the expected response code, and the observed result. Add a field for the environment and build number so a failure can be reproduced after the code moves on. Attach the masked gateway response as evidence instead of a screenshot of a real card.