CVV Test Case Guidelines for Payment Form Validation

CVV test case guidelines define the checks a payment form must run on the card verification value before an authorization request leaves the checkout. They cover format (three digits for Visa, Mastercard, and Discover, four for American Express), required-field behavior, invalid-character handling, and how the system reacts to each issuer response code. A complete suite tests the input field and the server-side response path.

What Do CVV Test Case Guidelines Cover?

• Format validation: digits only, with no letters, spaces, or symbols.
• Length rules by brand: three digits for Visa, Mastercard, and Discover; four for American Express.
• Required-field rules and empty-submit behavior.
• Boundary values such as 000, 999, and codes with leading zeros.
• Issuer response handling: match, mismatch, not processed, and unavailable.
• Data handling: the code never reaches logs, databases, or session storage.

CVV Format Rules by Card Brand

Card brands use different lengths and names for the same security code. Build the test matrix from the brand, not from a fixed three-digit assumption.

• Visa (CVV2): three digits printed on the back.
• Mastercard (CVC2): three digits printed on the back.
• Discover (CID): three digits printed on the back.
• American Express (CID): four digits printed on the front, above the card number.

Field-Level Test Cases to Write First

These cases exercise the input itself. Run each one on the checkout form, then confirm the request payload matches what the field should send.

1. Valid three-digit value on a Visa test number. Expect a successful authorization.
2. Valid four-digit value on an Amex test number. Expect a successful authorization.
3. Two digits. Expect an inline validation error before submit.
4. Five digits on a three-digit brand. Expect rejection.
5. Letters or symbols (abc, 12/3). Expect rejection, and check that the field blocks or strips them.
6. Empty field on a form where the code is required. Expect an error message tied to that field.
7. Leading zeros (007, 0123). Expect acceptance, since these are valid values.
8. Paste and browser autofill. Pasted values should behave the same as typed input.
9. Trailing spaces. Check whether the value is trimmed before it reaches the gateway.
10. Double submit with the same value. Confirm no duplicate authorization is created.

How Should CVV Failures Be Handled?

A mismatch does not always stop an authorization. The issuer returns a verification result, and the merchant decides how to act on it. Test every branch.

• Match (M): the code matches. Proceed with the charge.
• No match (N): the code is wrong. Void the authorization and ask for the code again or another payment method.
• Not processed (P): the code was not checked. Treat it as unknown, never as a pass.
• Unavailable (U): the issuer cannot verify. Decide the risk policy in advance and test both outcomes.

Test Data: What to Use Instead of Live Card Numbers

Use sandbox card numbers from your payment processor. Stripe, Adyen, Braintree, and similar gateways publish test PANs that trigger specific verification responses. Never paste a real card number into a staging environment, even for a quick check, because the number then sits in logs, fixtures, and screenshots.

Name test cards by behavior in your fixtures: cvv-match, cvv-mismatch, cvv-unchecked. Behavioral names keep the suite readable when a processor rotates its test numbers.

PCI DSS Rules That Shape the Tests

PCI DSS treats the CVV as sensitive authentication data. It may be used to process a transaction and must not be stored after authorization, in any form, including encrypted form.

• Confirm the code is absent from application logs, debug output, and error traces.
• Confirm it is not written to the database, cache, session store, or analytics events.
• Confirm test environments hold no live cardholder data.
• Confirm the field is masked or cleared after submit.

Add a negative test that searches the log output for the test value after a run. If the string appears anywhere, the build fails.

Common Mistakes in CVV Test Suites

• Hardcoding three digits, which breaks Amex support.
• Testing only the happy path and skipping declined-verification handling.
• Ignoring the not-processed and unavailable responses, which turn up on international and prepaid cards.
• Trusting a client-side check alone, without confirming the server validates again.
• Leaving the code in the request log written by the gateway integration.

FAQ

Is the CVV always required for card-not-present payments?

No. Most gateways let you submit an authorization without it, and the issuer returns an unverified result. Many processors charge a higher rate or decline when the code is missing, so check your gateway rules.

Can a business store the CVV for repeat payments?

No. PCI DSS forbids storing sensitive authentication data after authorization. Recurring and subscription charges rely on a token or a stored account number instead.

What does a mismatch mean on a test transaction?

In a sandbox it means you used a test card number configured to return a mismatch. In production it means the code entered does not match the issuer record, which may point to a typo or to a card number that does not belong to the person paying.

How many digits does the CVV have on Amex?

Four. American Express prints a four-digit CID on the front of the card, above and to the right of the card number. Every other major brand uses three digits on the back.