What are CVV format validation test cases?

CVV format validation test cases check that a payment form accepts only the digits a card brand allows. That means 3 digits for Visa, Mastercard, and Discover, and 4 digits for American Express. A complete suite covers length, character set, leading zeros, paste input, and the rejection of card numbers or Luhn checks run against the wrong field.

read more

Format validation happens before the authorization request. It decides whether the value gets sent to the issuer or bounced back to the customer with an error.

related article

CVV format rules by card brand

The card security code has several names. The format depends on the network, not on the issuer or the payment gateway.

more on this topic

• Visa (CVV2): 3 digits on the back signature panel.
• Mastercard (CVC2): 3 digits on the back signature panel.
• Discover (CID): 3 digits on the back.
• American Express (CID): 4 digits printed on the front, above the card number.
• UnionPay and Diners Club: 3 digits on the back.

No network uses 2 digits. None use letters. None use a check digit. The Luhn algorithm validates the primary account number, and running it against the CVV rejects valid input such as 000 or 123.

cvv input validation test cases

Positive test cases

• 3-digit value on a Visa card, for example 123.
• 3-digit value with leading zeros, for example 001 or 000.
• 4-digit value on an American Express card, for example 1234.
• Repeated digits, for example 111 or 9999.
• Value pasted from the clipboard with no separators.

Each case should pass format validation and reach the authorization request. A green check in the UI proves nothing about the processor, so confirm the value arrives in the gateway payload with leading zeros intact.

Negative test cases

Negative cases are where payment forms break. Group them by the rule they violate.

Length failures

• Empty field and a field holding only spaces.
• Two digits, five digits, and a 300-character string.
• 3 digits submitted with an American Express card number.
• 4 digits submitted with a Visa card number.

Character set failures

• Letters (12a), mixed alphanumeric (1a3), and full text (abc).
• Symbols, decimal point (1.2), minus (-12), plus (+12), and hyphen (1-2).
• Arabic-Indic digits (١٢٣), Devanagari digits, and full-width digits (１２３).
• Combining marks, zero-width joiners, newline inside the value, and a right-to-left override character.

Injection and encoding failures

• SQL fragments such as 1' OR '1.
• HTML tags, null bytes, and percent-encoded values.
• Tab characters and carriage returns mixed into the digits.

Every negative case must return a field-level validation message. No stack trace, no raw gateway error, no silent pass.

Why the brand check matters

Length validation without a brand check lets a 4-digit CVV through on a Visa form. The gateway returns a decline or a CVV code of N, and the customer sees a failure they cannot fix. Derive the expected length from the detected card brand, then test each brand on its own.

What CVV validation should never do

• Store the CVV after authorization. PCI DSS Requirement 3.2 bans retaining sensitive authentication data.
• Write the CVV to application logs, crash reports, or analytics events.
• Trim leading zeros or cast the value to an integer. Both change a valid CVV.
• Mask or transform the value before it reaches the payment gateway.
• Autofill the field from a stored customer profile. Merchants cannot keep the value.

Sample test case table

How to structure the suite

1. Format cases: length and character set per brand.
2. Brand mismatch cases: correct length, wrong network.
3. Normalization cases: spaces, hyphens, paste, autofill.
4. Security cases: injection strings, log inspection, storage inspection.
5. Response cases: gateway CVV codes mapped to UI messages.

Tag each case with the rule it proves, so one failure points to one requirement instead of a whole group.

CVV response codes to test against

Once format validation passes, the issuer returns a single-letter CVV code. Check that your UI handles each one.

• M match
• N no match
• P not processed
• U unknown, the issuer does not support the check
• S should have been present but was not
• X not supported by the issuer

Codes U and X are not fraud signals. Treating them as failures blocks real customers at checkout.

FAQ

Does CVV use the Luhn algorithm?

No. Luhn applies to the card number only. A CVV has no check digit, so any 3-digit or 4-digit string is format-valid, including 000.

Should a form reject 000?

No. Real cards carry 000, 001, and other low values. Rejecting them fails legitimate transactions and generates support tickets.

Can a merchant store the CVV?

No. PCI DSS forbids storing sensitive authentication data after authorization, even in encrypted form. Validation must happen in memory and the value must be discarded right after the request.

How many test cases are enough?

About 30 to 50 cases cover format, brand, normalization, and security. Add one case per supported card brand and one per gateway response code.