CVV Test Case Scenarios: QA Guide for Payment Forms

CVV test case scenarios are the specific checks a QA team runs against the card verification value field on a payment form. They cover format rules, brand-specific lengths, rejection of invalid characters, and how the application responds when the processor returns a CVC mismatch or a decline. A complete set covers the 3-digit CVV2 on Visa, Mastercard, and Discover, plus the 4-digit CID on American Express, all run against sandbox credentials rather than a real card.

What should a CVV test suite cover?

Group the cases into three buckets: input validation, processor response handling, and data handling. Input validation tests the field itself. Response handling tests what the app does with the answer from the gateway. Data handling confirms the code is never written to logs, databases, or analytics events.

Input validation cases

• Happy path: a valid 3-digit value on a Visa test number submits successfully.
• Amex path: a 4-digit CID is accepted, and the field switches from a 3-digit to a 4-digit maximum when the brand is detected.
• Too short: 1 and 2 digits are blocked with an inline error before submit.
• Too long: 5 or 6 digits are truncated or rejected, matching your stated rule.
• Non-numeric: letters, symbols, emoji, and Unicode digits are rejected.
• Leading zeros: 001 and 0123 are accepted as valid and not stripped.
• Whitespace: leading, trailing, and internal spaces are trimmed or blocked.
• Empty and whitespace-only values are blocked at submit.
• Paste behavior: pasting "123 " or "1 2 3" produces the same result as typing.
• Autofill: browser and mobile wallet autofill populate the field correctly.
• Injection strings: script tags, SQL fragments, and oversized payloads are handled safely.
• Brand switch: entering a Visa number and then editing to an Amex number clears or re-validates the CVV length.

Processor response cases

Use the sandbox test cards your processor publishes for CVC and decline simulations. Stripe documents cards that trigger specific outcomes, and PayPal's sandbox does the same for its own gateways. Assert that each returned code maps to the correct user-facing message.

• CVC mismatch maps to a clear message with a retry path.
• Generic decline shows a neutral message that does not reveal which check failed.
• Repeated failures hit your rate-limit or lockout rule.
• Timeout and network error preserve entered data and offer retry.
• Idempotency: resubmitting after a timeout does not create a duplicate charge.

Data handling cases

PCI DSS forbids storing the CVV after an authorization, so your tests must prove the value leaves no trace. Assert that the CVV is absent from application logs, database rows, error trackers, and session replays. Confirm the card number is masked in confirmation emails and account statements.

How many CVV test cases are enough?

Most teams land between 20 and 40 cases once brand variants, boundary values, and processor responses are combined. Prioritize format boundaries, brand switching, and the CVC mismatch path, since those break most often. Automate the input validation layer and keep processor response tests in a smaller contract suite.

What tools run these scenarios?

Unit tests with your validation library cover format rules fastest. End-to-end frameworks such as Playwright or Cypress cover the field, the brand detection, and the error state together. Contract tests against gateway sandbox endpoints confirm that response codes map to the right UI.

What should you avoid in CVV testing?

Never test with real card numbers, including your own. Never log the CVV, even in a debug build, because debug logs tend to ship. Never assert on a full card number in test output when a masked version proves the same point.