CVV validation test cases check the 3 or 4 digit security code field on a payment form: digits only, length that matches the card brand, leading zeros kept intact, and clean rejection of letters, spaces, and symbols. A complete suite covers valid input, boundary lengths, brand switching, and paste or autofill behavior.

cvv test cases for qa

The CVV check is a format check, not a correctness check. Your form can confirm the field holds "1234" for an Amex card number. Only the issuer can confirm the code matches the account, and that answer arrives in the authorization response.

test cases for cvv field

What does the CVV field check?

Client-side validation enforces shape. It never proves the code is real.

read more

• Character set: digits 0-9 only. Letters, symbols, punctuation, and emoji all fail.
• Length: 3 digits for Visa, Mastercard, Discover, JCB, and most brands; 4 digits for American Express.
• Leading zeros: "000" and "0123" are valid strings. A field that casts the value to a number and drops the zeros is broken.
• Whitespace: interior spaces fail. A trailing space from a paste should be trimmed or rejected, and the choice must hold across every input path.
• Empty value: behavior depends on your gateway and on whether the code is required for that transaction type.

Which positive test cases should pass?

1. Visa with code "123" and a sandbox PAN such as 4111 1111 1111 1111: accepted, form submits.
2. Amex with code "1234" and sandbox PAN 3782 822463 10005: accepted.
3. Code "000" on a 3 digit brand: accepted as a string, not treated as empty.
4. Codes "007" and "099": leading zeros reach the gateway payload unchanged.
5. Code typed at max length: the field stops accepting input and focus moves to the next field.

Use the sandbox numbers published in your gateway documentation. Never test with a live card number.

more on this topic

Which negative test cases should fail?

1. Empty field when the code is required: field-level error, submit blocked.
2. Two digits, "12": rejected on all brands.
3. Five digits, "12345": rejected.
4. Letters, "12a" or "abc": rejected.
5. Symbols, "12#" or "-12": rejected.
6. Interior space, "1 23": rejected.
7. Pasted "123" with a trailing newline: trimmed and accepted, or rejected with a clear message. Pick one rule and test it.
8. Non-ASCII digits such as Arabic-Indic "١٢٣": rejected unless you convert on purpose.
9. Script payload "" and SQL strings: stopped at the character check and never reflected unescaped.

How should the field behave when the card brand changes?

Length has to follow the card number, not the other way around.

• Start with a Visa PAN, enter 3 digits, then swap in an Amex PAN. The field must clear or extend to 4 digits.
• Enter 4 digits on a Visa PAN. The fourth keystroke must be blocked or flagged.
• Switch from Amex to Mastercard with a stale 4 digit value. Submit must fail rather than truncate without telling the user.
• Empty or unknown PAN: default to 3 digits and stay permissive.

What breaks on paste, autofill, and mobile?

• Password managers write the code as a string. Verify "0123" stays "0123" after autofill.
• iOS and Android numeric keypads still allow pasting text. Test the paste path, not just the keypad.
• Confirm the input carries autocomplete="cc-csc" so managers target the right field.
• Screen readers should announce the field as a security code with the digit count. Check the 4 digit case with VoiceOver or TalkBack.

What should the CVV field never do?

Testing covers storage, logging, and error handling, not just the widget.

• Never store the code after authorization. PCI DSS treats the CVV as sensitive authentication data and forbids retaining it.
• Never write it to application logs, crash reports, or analytics events.
• Never put it in a URL, a hidden field that persists across checkout steps, or a cookie.
• Never keep it in the form after a failed payment attempt. Clear the field and ask for it again.

Does CVV validation use the Luhn algorithm?

No. Luhn checks the primary account number for typos. The code is far too short for a checksum to mean anything, so a Luhn-style check on it rejects valid cards.

Should the form reject "000"?

No. The format is valid. Only the issuer can say whether the code matches the account, and the verdict arrives in the authorization response. Rejecting it client-side blocks real customers.

What should the error message say?

Field errors belong next to the field and describe the fix, not the rule. "Enter the 3 digit code from the back of your card" beats "Invalid CVV".

• Keep messages generic so they do not help someone probing the form with sequential numbers.
• Do not wipe the whole checkout because one field failed.
• Rate-limit repeated failures in the same session.

Which gateway responses need coverage?

A valid format can still come back as a mismatch.

• Match: the issuer confirms the code. The charge can still fail for other reasons.
• Mismatch: the issuer rejects the code. Show a retry path with a clear message.
• Not present: the field was empty, or the issuer does not support the check.
• Unavailable: the issuer cannot answer. Some gateways let the charge proceed under your fraud rules.

Run all four through your sandbox before launch, then confirm each one renders a different message to the customer.