CVV Test Checklist: Field, Decline, and Compliance Checks

A CVV test checklist is the ordered set of checks a QA or payments team runs to confirm that a card verification value is collected, validated, sent for authorization, and then discarded correctly. A complete checklist covers field format, server-side validation, decline handling, logging, and the PCI DSS rule that the CVV must not be retained after authorization.

Run it before every release that touches checkout, and run it again whenever a processor changes an API version, a new card brand is enabled, or a payment method is added.

Why a CVV test checklist matters

The card verification value is one of the few pieces of payment data a merchant touches but is not allowed to keep. That creates a narrow set of behaviors the form has to get right. If the field accepts the wrong input, the authorization request fails for a reason the customer cannot fix. If the value leaks into a log, a database column, or an analytics event, the merchant moves into non-compliance territory. If the decline path is untested, a simple mismatch looks identical to a stolen card and support tickets pile up.

A written checklist turns those risks into repeatable steps that any tester can follow, including contractors who have never seen the payment stack before.

The core checklist

• Field accepts exactly three digits for most cards and four digits for American Express.
• Letters, spaces, punctuation, and pasted text are rejected without breaking the layout.
• Input is validated on the server as well as in the browser, using an allowlist of digits only.
• The field label and help text name the code clearly, for example "security code on the back of your card."
• Mobile browsers open a numeric keypad, and the input carries the correct autocomplete attribute for card security codes.
• The value is masked in the user interface and never echoed back in an error message.
• The form submits over TLS and never places the code in a URL query string.
• The authorization request carries the code only in the designated API field, not in a free-text field or a note.
• The code is absent from application logs, error trackers, analytics events, and support exports.
• The code is absent from the database after authorization completes.
• A mismatch returns the processor decline code and shows a customer-friendly message that invites a retry.
• Repeated failed attempts trigger rate limiting or a step-up challenge.

Sandbox test data

Most processors publish test card numbers that produce a specific verification outcome, so both the pass path and the fail path can be exercised without touching a live account. Build a small matrix of cases and record the expected response for each one:

• Correct code with an otherwise valid test card: authorization approved.
• Incorrect code: verification failure, order held or rejected.
• Missing code: field validation error before any network call.
• Four-digit code on a non-Amex test card: rejected on format.
• Correct code on a test card that returns a generic decline: order handled without exposing the reason to the customer.

Repeat the matrix on each supported browser and on at least one mobile device, because autofill and input masking behave differently across platforms.

What the checklist must never include

Never test with live card numbers you do not own or have written permission to use. Running many card numbers against a live endpoint to see which ones authorize is card testing fraud, and processors treat it as an attack. A proper CVV test checklist stays inside sandbox credentials or the merchant's own test account, and it never asks a tester to verify a real customer's code.

Common failures the checklist catches

The most frequent defects are a code stored in a debug log, a client-side-only validation rule that a crafted request bypasses, a decline message that reveals the verification result to a fraudster, and a cached confirmation page that still holds the value after a refresh. Each of these is cheap to fix before launch and expensive to explain afterward.

Record the results

Keep the signed checklist with the release notes so the next audit or processor review can see when each control was last verified. A dated CVV test checklist converts a vague promise about payment security into evidence.