CVV Test Plan: Test Cases for Card Security Code Fields

A CVV test plan lists the checks a payment team runs to confirm that the card security code field accepts, validates, and passes the code to the processor without storing it. It covers positive and negative input cases, error messaging, and the PCI DSS rules that limit how CVV data moves through a system. The plan runs in a processor sandbox with test card numbers, not live cards.

cvv validation scenario

What goes into a CVV test plan?

Start with scope. List every point where the security code touches the system: the checkout form, browser validation, the API request, the processor call, and application logs. Anything that holds the code for even a second belongs in the plan.

CVV Verification Scenario: When Card Checks Trigger and What Follows

• In scope: CVV input field, card type detection, tokenized card data, decline messages tied to security code results.
• Out of scope: issuer authorization logic, 3-D Secure challenges, fraud scoring. Those get their own plans.
• Environments: processor sandbox for logic, staging for the UI, production only for one controlled smoke test.
• Test data: sandbox card numbers from your processor, at least one per brand, plus a table of invalid codes.

Which positive cases should you cover?

Positive tests prove the field takes valid codes and hands them off intact.

cvv test example

• Three-digit code on Visa, Mastercard, and Discover.
• Four-digit code on American Express, which sits on the front of the card.
• Codes with leading zeros such as 0001 or 0123 stay intact after submit. A field typed as an integer will drop them.
• Paste and autofill paths produce the same value a typed entry does.
• The authorization returns a match result and the order moves to capture.

Which negative cases matter most?

Most payment bugs live in the failure paths. Build one test per row and check both the message and the order state.

• Empty field, two digits, five digits, letters, and symbols.
• Injected strings such as <script>alert(1)</script> and SQL fragments. The field should reject or escape them.
• Long input (500+ characters) hits a length cap and an error, not a crash.
• Processor returns a no-match result. The page shows a plain decline and does not retry the charge.
• Processor returns a not-verified or not-present result. The order must not be marked paid on a soft result.
• Network timeout during the processor call. The UI offers a retry path and the order stays pending.

Why should the plan avoid live card numbers?

PCI DSS bars storing the card verification code after authorization, and a CVV pasted into a test ticket or captured in a debug log counts as storage. Test data leaks the same way live data does. Use sandbox cards for the bulk of the plan. For the one live smoke test, use a company card, a fixed small amount, and an environment with request logging turned off.

How do you test results from the processor?

The processor returns a result code for the security code check, separate from the approval decision. Test each branch the integration can receive.

• Match: the check passes. Confirm the order state and the receipt.
• No match: the code is wrong. Confirm the decline reason shown to the customer and the behavior of the retry screen.
• Not verified or not present: the issuer or the merchant skipped the check. Set your own risk rule and confirm the code follows it.

Write the expected order status next to each result in the test list. That one column catches most integration mistakes.

What does a single test case need?

A test case that another engineer cannot run is not finished. Give each row the same fields.

• ID and short name, for example PAY-114 Amex four-digit code.
• Precondition: card brand, saved card state, cart total.
• Input value and the exact action taken.
• Expected result: field message, processor call, order status.
• Evidence: a redacted screenshot or a log line with the code masked.

How do you keep the plan current?

• Store cases as data (brand, code length, expected result) so new brands and rules drop in without rewrites.
• Run the full plan on any release that touches checkout, payment APIs, or logging.
• Keep the plan in the same repo as the code and review it when the processor changes its API.
• Delete test artifacts after each run. Screenshots and HAR files holding card data are a compliance problem.

Who owns the plan?

QA writes and runs the cases, a payments engineer owns the sandbox and the processor config, and a compliance lead signs off on any test that touches live data. One named owner per section stops the plan from rotting after a team change.

Common questions

Can we store the CVV for recurring billing?

No. The code cannot be kept after authorization. Use the processor token or stored-credential framework to charge repeat customers.

Can we test security code checks in production?

In narrow cases only: one card, one amount, logging off, and a rollback plan ready. Every other case stays in the sandbox.

Do mobile SDKs need their own CVV tests?

Yes. Native keyboards, autofill, and SDK masking behave in ways a browser form does not. Run the positive and negative cases again on iOS and Android builds.

What if the field lets a wrong-length code through?

Fix the client rule and add a server-side check. Client validation alone can be bypassed, so the API must reject bad lengths too.