CVV test cases for payment forms check that a security code field accepts valid input, rejects invalid input, and sends the value to the gateway without storing it. Teams run them in a sandbox using the fake card numbers and CVV values each payment provider publishes. Real card data does not belong in a test environment.

cvv test cases for qa

Where do the test CVV values come from?

Each payment gateway publishes a table of sandbox card numbers with matching expiry dates and, in many cases, fixed CVV values. Those tables are the source of truth for your test data.

CVV Format Validation Test Cases: Guide to Where to Buy CVV

• Stripe: test card 4242 4242 4242 4242 accepts any 3-digit CVV and any future expiry date. Stripe also lists cards that trigger specific declines.
• PayPal Braintree: sandbox card numbers respond to AVS and CVV rules, and certain transaction amounts force a CVV or postal code failure.
• Adyen: the test card documentation pairs each number with a fixed CVC and lists the refusal reason it returns.
• Authorize.net and most other gateways: a similar test card page with CVV response codes.

Read the table before you write a scenario. A guessed CVV value wastes a test run because the sandbox returns a mismatch instead of an approval.

CVV Negative Test Cases: Practical Payment Testing Guide

Never paste a live card number into a sandbox to check the real path. Sandboxes reject live numbers, and PCI rules treat that data as sensitive wherever it lands.

CVV Field Validation Examples: A Comprehensive Guide

What are the core CVV validation cases?

Cover both card families and every input path a user can take. The list below works as a starting checklist.

1. Valid 3-digit code accepted for Visa, Mastercard, and Discover.
2. Valid 4-digit code accepted for American Express.
3. Empty field blocked with a clear inline message.
4. Two digits blocked, because the length rule fails.
5. Five digits blocked on a 3-digit card.
6. Letters, spaces, and symbols rejected, including on paste.
7. Leading zeros kept, so "000" and "0123" reach the gateway unchanged.
8. Trailing whitespace trimmed or blocked, never passed through.
9. Card type switch updates the field: entering Amex after Visa moves the limit from 3 to 4.
10. Card type switch clears a stale value that no longer fits.
11. Browser autofill fills the field without breaking validation.
12. Field masks the digits on screen and blocks copy.

Add a case for the keyboard: numeric keypad on mobile, backspace to empty, and tab order through the form.

How do you test a CVV mismatch?

Use a sandbox card or amount that returns a CVV failure, then check what the user sees and what the order does. The gateway returns a decline code such as incorrect_cvc in Stripe or a CVC refusal reason in Adyen.

Confirm three things: the message names the CVV field rather than the whole card, the customer can correct the code and retry, and the failed attempt leaves no authorized order behind.

• Check soft declines apart from hard declines. A CVV mismatch is soft and should allow a retry.
• Check the retry limit. Some gateways lock the card after repeated CVV failures.
• Check the audit trail. The decline code and timestamp should appear in your logs; the CVV should not.

What belongs in a CVV test case template?

A short template keeps runs repeatable across testers and releases.

• Case ID and title.
• Preconditions: sandbox keys, test card, gateway mode.
• Steps with exact input values.
• Expected result, including the gateway response code.
• Actual result and pass or fail.
• Cleanup: void the transaction, reset the test card state.

Store the test card numbers inside the case file, not in a shared spreadsheet of live data. Anyone reading the case should see at a glance that it is sandbox-only.

How do you automate CVV checks?

Unit tests cover the length and character rules because those are pure functions. Parse the brand from the card number, apply the matching length, and assert pass or fail for each input class.

End-to-end tests cover the gateway round trip. Run them against the sandbox in CI, on a schedule, and before each release. Keep the count small because each run consumes sandbox capacity and adds minutes to the build.

• Test the brand-to-length map for every card type you accept.
• Test the paste event with spaces and dashes in the string.
• Test the decline path with the provider's mismatch card.
• Test that the CVV field is absent from the payload your server logs.

Mock the gateway for logic tests and hit the real sandbox for the small set that must prove the integration. Mixing the two keeps the suite fast and honest.

Which CVV bugs show up most?

• A hardcoded length of 3, which fails every Amex customer.
• Validation that strips leading zeros before the value reaches the gateway.
• Brand detection that runs after validation, so Amex codes fail the first pass.
• The CVV written to application logs, error trackers, or analytics events.
• Suites that cover the happy path only and never check mismatch handling.
• Production keys left in a test config, which turns a bug into a live charge.

Each of these passes a casual manual check and fails a real user. Automate the length and character rules, then walk the mismatch flow by hand.

How does PCI DSS shape CVV testing?

PCI DSS classes the CVV as sensitive authentication data. It must not be stored after authorization, and it must not appear in logs, databases, or backups, even in encrypted form. Testing that rule is part of the job.

Search your logs, APM traces, and error reports for the test CVV after a sandbox run. If it turns up, you have a finding. A code review of the request payload and the gateway call catches most leaks before they ship.

Use hosted fields or tokenization so the CVV goes from the browser straight to the gateway. Your server never sees the value, which removes a class of test cases and a class of risk at the same time.