CVV Test Cases: A QA Guide to Card Security Code Validation

CVV test cases are the checks a QA engineer runs on the card security code field of a payment form. They confirm the field accepts a 3-digit code from Visa, Mastercard, and Discover, a 4-digit code from American Express, and rejects letters, symbols, and blank entries. A full set of cvv test cases also covers what the application does when the code fails or when the issuing bank does not support verification at all.

Which rules do CVV test cases verify?

Every rule below becomes at least one test case, plus one negative case for the boundary.

• Length is 3 digits for most brands and 4 digits for American Express.
• Digits only. No letters, no punctuation, no symbols.
• The field is never prefilled from stored data on a returning customer.
• The value is masked in the UI and never written to a log, a crash report, or an analytics event.
• The value is sent over TLS and dropped from memory after the authorization response.

What are the core positive CVV test cases?

Positive cases prove the happy path works for each card brand and each input method.

1. Enter a valid 3-digit code on a Visa, Mastercard, or Discover test card and confirm the charge is approved.
2. Enter a valid 4-digit code on an American Express test card and confirm the charge is approved.
3. Complete a purchase with a saved card and re-enter the code when the flow asks for it.
4. Type the code with the numeric keypad on mobile, using the inputmode="numeric" hint.
5. Paste a code from the clipboard and confirm the field strips surrounding whitespace.
6. Fill the code through browser autofill (the cc-csc token) and confirm the value lands in the right field.

What are the negative CVV test cases?

Negative cases are where most payment bugs hide. Run each one against the same card and record the response.

• Two digits and five digits, to check both sides of the length boundary.
• Letters (abc), mixed input (1a2), and symbols (!@#).
• A blank field submitted with the rest of the form complete.
• Whitespace only, and a valid code with a trailing space.
• A leading-zero code such as 012, to confirm the field treats it as a string and not a number.
• A repeated-digit code such as 000 or 1111, which is a valid format and must reach the gateway.
• Long strings and script payloads, to check that input is validated at the boundary and escaped on output.
• Unicode digits from a non-Latin keyboard, which a strict character set should block.

How do you test CVV verification against the processor?

Format validation happens in your own code. Verification happens at the issuer, and the result comes back as a response code. A match returns M, no match returns N, not processed returns P, unsupported returns U, and a code the bank expected but did not receive returns S.

Payment processors publish test cards that force each of those responses, so you can exercise the full branch logic without touching a real account. Test that a failed code shows a clear message, that a retry is allowed, and that the order moves to the right state after three failures if your risk rules cap attempts.

What test data should you use?

Use sandbox card numbers from the processor you integrate with. Those numbers are published for testing and are not tied to real accounts.

Never copy a live card number, expiry, or code into a test environment, a ticket, a screenshot, or a spreadsheet. Live card data in a test system breaks PCI DSS scope and turns a routine QA task into an incident.

Can a CVV be stored after the payment?

No. PCI DSS classifies the card verification value as sensitive authentication data, and the standard bars storing it after authorization, even in encrypted form. The code may be used to complete one transaction and then must be gone.

In practice that means no database column, no session variable that outlives the request, and no capture in application logs, error trackers, or session-replay tools. A common failing test case is a rejected payment that writes the whole request body, code included, into a debug log.

How should a CVV test suite be organized?

• One group for format rules: length, character set, and boundaries.
• One group per card brand, since Amex changes the length.
• One group for gateway response codes, using forced test cards.
• One group for storage and logging, checked with a network trace and a log review.
• One group for accessibility and device behavior: label association, error text, mobile keyboards, screen reader output.

Tag each case so it can run in regression on any change to the checkout page. Card fields break when a front-end refactor touches the form, when a new payment method ships, and when the processor updates its API version.

Frequently asked questions about CVV test cases

What is the difference between CVV, CVV2, CVC, and CID?

CVV1 sits on the magnetic stripe and is read at a terminal. CVV2 is the printed 3-digit code on Visa and Discover cards. CVC2 is Mastercard's name for the same printed code, and CID is American Express's 4-digit version. Online forms collect the printed code, so CVV2, CVC2, and CID are the ones you test.

Should a code of 000 pass format validation?

Yes. 000 is a valid 3-digit string. The form should accept it and let the issuer decide the match result, because a screen that blocks it will also block real codes that start with zero.

Can you test CVV handling without a live gateway?

Yes. Sandbox mode covers format validation, response-code branches, tokenization, and error messaging. The only thing it cannot reproduce is a real issuer decision, which is not needed to test your own code.

Why does a sandbox card fail the CVV check when the code looks right?

Test cards are wired to return fixed responses. A card built to trigger a no-match reply returns N no matter what you type. Check the processor's test card table and pick the card that matches the response you want to exercise.