A CVV test suite for a payment form must cover four things: digit length per card brand, numeric-only input, mismatch and decline handling, and proof that the code is never stored after authorization. Build those first, then add edge cases for leading zeros, pasted values, browser autofill, and mobile keypads.

more on this topic

What is a CVV and which rules apply to the field?

CVV (card verification value) is the short code printed on a card that shows the person paying holds the physical card. Visa, Mastercard, and Discover print three digits on the back. American Express prints four digits on the front and calls it a CID.

test cases for cvv field

Payment Card Industry rules add one hard constraint that shapes the whole test plan. Sensitive authentication data, which includes the CVV, must not be stored after authorization completes. That turns "confirm the code is gone" into a test case, not an afterthought.

how to write cvv test cases

• Input length: 3 digits for most brands, 4 for American Express.
• Character set: digits 0 through 9, nothing else.
• Storage: never kept in the database, cache, logs, or analytics after the auth call.
• Display: masked in the interface and in any support tool that shows transactions.

Which CVV test cases should every payment form pass?

Run these against a sandbox account using the test card numbers your processor publishes. Every case needs a pass condition, not a vague "looks fine".

CVV Field Validation Examples: A Comprehensive Guide

1. Valid 3-digit code on a Visa or Mastercard test card authorizes as expected.
2. Valid 4-digit CID on an American Express test card authorizes as expected.
3. Empty CVV field blocks submission and shows a clear message.
4. Letters, symbols, and mixed input are rejected before the request leaves the browser.
5. Two digits fail validation, and a five-digit entry on a 3-digit brand fails too.
6. Leading zeros pass. Codes like 001 and 0123 are real and must not be stripped.
7. Leading and trailing spaces are trimmed; internal spaces such as "1 23" are rejected.
8. Pasted values behave the same as typed ones, including paste of a value that is too long.
9. The field caps length at the brand limit (3 or 4) as the user types.
10. Mobile devices open a numeric keypad, not a full keyboard.
11. Browser and password-manager autofill fills the field without breaking validation.
12. The digits are masked on screen when the field loses focus, if your design masks them at all.

Why leading zeros break so many forms

A JavaScript check such as parseInt(cvv) turns "001" into 1, which then fails a length test. Store and compare the CVV as a string from the first line of code. The same bug appears when a form trims whitespace with a numeric cast.

Which mismatch and decline cases matter?

A wrong CVV is a normal event, so the form has to handle it without leaking card data or hammering the issuer.

• Correct card number with wrong CVV: the issuer declines, the form shows a generic message, and the user can retry.
• Repeated wrong CVV attempts: the form throttles retries instead of sending an unbounded stream of auth requests.
• Network timeout on the auth call: the UI shows a recoverable error and does not mark the order paid.
• Duplicate submit from a double click, refresh, or back button: only one authorization is created.
• Decline responses never echo the CVV, the card number, or the issuer's raw response back to the browser.

Do not let error messages leak

An error that says "wrong CVV" for one card and "invalid card" for another hands an attacker a way to test stolen numbers. Keep the wording identical for both cases. Log the internal reason, show the user one neutral message.

Which security and compliance test cases apply to CVV data?

These checks fail in logs and third-party scripts far more often than in the form itself.

• Search application logs for the submitted CVV after a test transaction. Expect zero matches.
• Check the database, cache, and session store for the value after authorization.
• Confirm the CVV never appears in a URL query string or a GET request body.
• Confirm analytics tools, session-replay scripts, and crash reporters do not capture the field.
• Verify the field is excluded from browser autofill history for other forms on the same site.

How should you build test data?

Use sandbox test cards from your payment processor. Most processors publish card numbers paired with CVV values that trigger approval, CVV mismatch, and decline.

Never test with a live card number, even your own. Track the CVV values next to the card numbers in your test fixtures so a reviewer can see which case each row covers, and keep those fixtures out of production configuration.

FAQ

Should a payment form reject a CVV with a leading zero?

No. Codes such as 001 are valid. Treat the value as a string from input to comparison.

Is a CVV always required?

No. Card-not-present merchants ask for it on most one-time payments, but recurring charges, some mail and telephone orders, and certain regions do not use it. Make the field required only when your processor requires it.

Does the CVV have a checksum like the card number?

No. There is no Luhn-style validation for the CVV. Length and character set are the only offline checks available.

Should the form detect the card brand before checking CVV length?

Yes. Read the brand from the leading digits (34 and 37 for American Express) and set the expected length from that. Otherwise a 4-digit Amex code fails a 3-digit rule and real customers get blocked.

How do you keep the suite maintainable?

Field rules such as length, character set, trimming, and maxlength belong in unit tests that run in milliseconds. Decline handling, storage checks, and log scans need integration tests against the sandbox. Add a new case whenever your processor changes a rule or you add a card brand to the form.