CVV validation is the step where a merchant sends the card verification value to the payment processor inside the authorization request and reads back whether the issuing bank matched it. The approach that holds up in production: pass the value once, never write it to a database, cache, or log, and combine the CVC result with address verification before deciding to ship. Three criteria drive that recommendation: payment card industry scope, how much detail your processor returns, and what you do with a mismatch.
What the check actually compares
The verification value is not part of the card number. Visa prints CVV2 as three digits on the back, Mastercard prints CVC2 the same way, and American Express uses a four-digit code on the front. The issuer generates it at account opening, and it is not encoded on the magnetic stripe or the chip. In a card-not-present transaction the processor forwards the value to the issuing bank, which compares it against what it has on file and returns a short result.
Because the issuer runs the comparison, a merchant never needs to see the value after the authorization call. That design is deliberate, and it is what keeps the data out of your environment.
Never store the verification value
PCI DSS classifies the verification value, full track data, and the PIN block as sensitive authentication data. A system that retains it after authorization falls out of compliance, even when the storage is encrypted and even when retention lasts minutes. Plenty of breaches began as a log file that captured a full request body.
- Strip the value from application logs, error traces, and monitoring tools before they leave the process.
- Reject it at the edge of any queue or cache. A retry queue holding a raw authorization payload holds the value too.
- Keep it out of support tickets, screenshots, and customer emails.
How the result comes back
Processors return a status rather than a true or false. Stripe reports cvc_check as pass, fail, or unavailable on the card object attached to a charge. Unavailable means the issuer did not take part or did not answer, and that is not the same as a failure. Collapsing three states into two is one of the most common integration bugs, and it produces fraud rules that fire on cards which were never actually checked.
Pair it with AVS and 3-D Secure
The verification value checks possession of the physical card. AVS checks the billing address. Neither proves the person at the keyboard is the account holder. Run both, and step up to 3-D Secure when a risk rule triggers. A pass with a street address mismatch carries a different risk profile than a pass with a full match, and your rules should see the difference.
Map each result to a specific action
- No match: the digits were wrong or the card was cloned. Ask for a retry once, then route to manual review.
- Not processed: the issuer skipped the check, so the result carries no signal. Fall back to AVS and velocity rules.
- Unavailable: the issuer does not support the check for that card type. Do not treat it as a decline on its own.
- Invalid: the value failed format checks before it ever reached the network. This is a front-end bug, not a fraud signal.
Log the code you received. Without that field you cannot measure how often checks are skipped, and you cannot tune anything later.
Test in a sandbox, never against a live store
Every major processor publishes test card numbers that return a chosen CVC outcome, so you can confirm your handling of pass, fail, and unavailable without touching a live account. Never run validity probes against a store you do not control. Card testing is the reason merchants see bursts of small authorization attempts, and there are cheaper ways to validate your own integration.
Network tokens change the payload
When a card is tokenized, the primary account number is replaced by a token and the transaction is authenticated with a cryptogram. In that flow you no longer transmit the verification value at all. Keep the response handling you already built, because the authorization still returns a status you need to read.
Recommendation
For a standard ecommerce build, use a processor-hosted card field, keep the value out of every system you own, and write a fraud rule that reads the CVC result next to AVS and 3-D Secure. That pairing keeps your compliance scope small, gives you the signal you actually need, and avoids the problem that comes with holding data you were never meant to keep.