CVV Test Case Example: Card Security Code QA Guide

A CVV test case example is a quality assurance scenario that checks whether a payment form accepts a valid card security code and rejects an invalid one. It runs against sandbox test card numbers published by a payment processor, never against a live card, and it confirms three things: the field validates length and format, the error messaging is clear, and the code is never written to logs or storage.

Developers and testers search for a CVV test case example when they are wiring up checkout flows, so the sections below cover formats, sample steps, value sets, and the edge cases that slip past a first draft.

Format rules the test case has to match

• Visa, Mastercard, Discover, and most other brands: 3 digits, printed on the back of the card.
• American Express: 4 digits, printed on the front.
• The input is numeric only, masked on screen, and treated as sensitive authentication data.
• Validation happens on the client for feedback and again on the server before the authorization request.

A sample CVV test case

This structure works in a spreadsheet or in a test management tool. Steps stay short and the expected result is observable.

1. Title: Reject a two-digit CVV for a Visa test card.
2. Preconditions: Sandbox merchant account active, checkout page loaded, test card number from the processor's published list available.
3. Steps: Enter the test card number, enter an expiry date in the future, type 12 into the security code field, click Pay.
4. Expected result: The form shows an inline validation message about the security code, the submit button stays on the checkout page, and no authorization request reaches the processor.
5. Postconditions: No code value appears in application logs, browser console output, or the order record.

Test values worth including

• Valid three-digit values such as 123 or 456 in sandbox mode.
• Valid four-digit values for American Express, such as 1234.
• Too short: 12.
• Too long: 12345.
• Non-numeric: abc, 12a, symbols.
• Empty field and whitespace-only input.
• Leading zeros: 001, 0123.
• Boundary values: 000 and 999.
• A mismatch case where the code length does not fit the selected card brand.

Edge cases teams often miss

• Pasting a code with trailing spaces and confirming the value is trimmed.
• Browser autofill filling the field and leaving the submit button in the right state.
• Numeric keypad on mobile and the correct input type attribute.
• Screen reader announcement of the field label and the error text.
• Refresh or back navigation, which should clear the field rather than repopulate it.
• Server response when the processor declines the transaction for a failed verification check.

Why live card data stays out of the test suite

The PCI Security Standards Council states that sensitive authentication data, which includes the card verification value, must not be stored after authorization. A proper test case therefore relies on sandbox values supplied by the payment processor under test. Reproducing a real card number or its code in a test plan puts the tester and the business on the wrong side of that requirement, and it adds no coverage that a sandbox value does not already provide.

Automating the check

An automated version of the CVV test case example usually drives the checkout page with a browser automation tool, submits known sandbox values, and asserts on the text of the validation message rather than on a screenshot. Keep the value set in a fixture file so new card brands can be added without rewriting the test. Run the suite against the sandbox environment on every change to the payment form, and keep a small manual pass for keyboard behavior and assistive technology, which automation still handles poorly.

Quick checklist before you ship

• Every card brand in your market has a valid and an invalid code case.
• Messages explain what to fix without revealing card details.
• Server side validation runs even when the client check passes.
• Code values are absent from logs, analytics events, and database tables.