CVV test cases are scripted checks that confirm how a payment form, gateway, or checkout flow handles the card verification value, the 3 digit code on the back of most cards and the 4 digit code on the front of American Express. A full set covers correct codes, wrong codes, empty fields, non numeric input, and the decline responses a processor sends back. Testers run them against sandbox card numbers that card networks and processors publish for development.

Why CVV test cases matter in payment QA

The CVV is a fraud control rather than a payment field. A checkout that accepts a wrong code may pass valid transactions while failing to block the ones it should reject. Regression testing this field protects revenue and chargeback rates.

  • False accepts: a wrong CVV returns an approval.
  • False declines: a correct CVV fails because of a formatting bug.
  • Data storage: the code lands in logs or a database, which breaks PCI DSS.
  • Mobile input: numeric keypads, autofill, and paste behavior differ from desktop.

Which test card numbers do you use?

Every major processor publishes sandbox PANs for development. Stripe, Adyen, and Braintree all document cards that approve, decline, or trigger a specific CVV response. Use the list from your own provider, because the same number can behave in different ways across gateways.

  • 4242 4242 4242 4242 is the common Visa sandbox number for a successful authorization with any CVV. Confirm it inside your provider docs before you build a suite around it.
  • 4000 0000 0000 0002 is a common Stripe card for a generic decline.
  • Provider docs also list dedicated cards for a CVC check failure and for a "CVV not checked" response.

Sandbox CVVs follow the same format rules as live cards: 3 digits for Visa, Mastercard, and Discover, 4 digits for American Express. Some processors accept any 3 digit value on a success card, so a passing test proves the field was captured, not that the code was checked.

The core CVV test case matrix

  1. Valid 3 digit CVV on a Visa sandbox card. Expect approval.
  2. Valid 4 digit CID on an Amex sandbox card. Expect approval.
  3. Wrong CVV on a card configured to fail the check. Expect a CVV decline code.
  4. Empty CVV field. Expect client side validation to block submit.
  5. Two digit and five digit values. Expect rejection before the request leaves the browser.
  6. Letters and symbols, including a pasted string such as "12a" or "1 2 3". Expect rejection or stripping, with no server error.
  7. Spaces and hyphens typed into the field. Expect the same result as a clean value.
  8. CVV of 000. Record the processor response.
  9. Leading zeros, such as 007. Confirm the value is sent as a string and not trimmed to 7.
  10. Paste from clipboard on mobile and desktop.

CVV validation rules to verify

  • Field length tied to card brand, so switching from Visa to Amex changes the input from 3 digits to 4.
  • Brand detection updates the label between CVV, CVC, CVV2, and CID.
  • Autocomplete attributes are set so browsers and password managers fill the correct field.
  • The code never appears in application logs, analytics events, or error messages.
  • No CVV value is stored after authorization. PCI DSS bars retention of sensitive authentication data once a transaction is complete.

CVV decline codes your tests should cover

Gateways translate a failed check into a decline reason you have to handle in the UI and in your order records. Stripe returns a decline code such as incorrect_cvc. Braintree returns a CVV result code, where M means match and N means no match. Adyen reports a refusal reason for CVC problems.

Write a test for each code path. A user facing message of "your card was declined" on a CVV mismatch sends customers to the wrong fix.

Testing CVV with 3D Secure

Under 3D Secure the issuer, not your form, decides the outcome. Sandbox environments let you force an authentication success, a failure, or a challenge that is abandoned. Test the CVV field alongside each 3DS path, because the liability shift changes what you do with a mismatch.

Some authenticated flows return a CVV status of "not checked". Treat that as unknown, not as a match.

How to document CVV test cases

  1. List the preconditions: sandbox account, test card, currency, browser.
  2. State the steps in the order a shopper clicks them.
  3. Record the expected result for the form, the API response, and the order status.
  4. Add the actual processor response code so a future tester can compare.
  5. Tag each case by risk, then rerun the high risk ones with every checkout change.

Common CVV testing mistakes

  • Testing only the happy path with one test card.
  • Checking the front end message but not the stored order or webhook payload.
  • Skipping Amex, which breaks the 3 digit assumption.
  • Leaving test mode keys in a staging build that talks to a live account.

FAQ

What is a CVV test case?

A CVV test case is a documented scenario that checks whether a payment system accepts, rejects, or ignores a card verification value in a given situation. It pairs a sandbox card with an expected response.

Can you test CVV without a real card?

Yes. Processors publish sandbox card numbers that trigger approvals, declines, and CVV mismatches in test mode. No live card data is needed.

How many digits is a CVV?

Visa, Mastercard, Discover, and most other brands use 3 digits. American Express uses a 4 digit code printed on the front of the card, called the CID.

Is it legal to store a CVV after a payment?

No. PCI DSS forbids storing sensitive authentication data, which includes the CVV, after authorization. Test environments should avoid logging it too.

How often should CVV tests run?

Run the full set at launch and after any change to the payment form, gateway version, or card brand rules. A short smoke test can run with every deploy.