What is a CVV, CVC or CV2?

CVV (Card Verification Value), CVC (Card Verification Code), CV2, CSC (Card Security Code) and CID (Card Identification) are all names for the same thing: a short numeric code printed on your payment card that verifies you're holding it. For Visa and Mastercard it's three digits on the back. For American Express it's four digits on the front. The code isn't on the chip or the magstripe — so a skimmer can't steal it — and PCI DSS bans merchants from storing it after authorisation, full stop.

Why so many names for the same thing?

Each card network invented its own name for the code when the concept was introduced in the 1990s. Visa called it the Card Verification Value (CVV or CVV2). Mastercard called it the Card Verification Code (CVC or CVC2). The generic industry catch-all is CV2. American Express uses Card Identification (CID). Discover uses Card Identification Number (CIN). And the umbrella term you'll see in PCI DSS documentation is Card Security Code (CSC).

In everyday conversation, "CVV" is the term most people reach for regardless of which card they're holding. If you're filling in a form that asks for the CVV and your card is a Mastercard, it still means the three-digit code on the back — just with a different name on the card.

Where is the code on your card?

For Visa, Mastercard, Discover and JCB cards, the code is the last three digits printed on the signature strip on the back of the card, after the last four digits of the card number. Some cards print only the three-digit code on its own, with the embossed card number elsewhere on the strip.

For American Express cards, the code is four digits long and printed on the front of the card, above and to the right of the main card number. This is why Amex cardholders sometimes trip up on online forms that ask for the code — the position and digit count are both different from every other card.

On debit cards, the code works identically. The name might differ — Visa debit cards use CVV, Mastercard debit cards use CVC — but the format, location and purpose are the same as on credit cards.

CVV1 vs CVV2: what's the difference?

There are actually two separate codes for most card types:

• CVV1 (or CVC1) — encoded invisibly in the card's magnetic stripe. It's read automatically when you swipe the card at a terminal and is used for in-person verification. You never see it or type it.
• CVV2 (or CVC2) — the printed code on the card's surface. This is the one you're asked for in online, phone and mail-order transactions. It exists specifically for card-not-present situations where the magnetic stripe can't be read.

When anyone refers to "the CVV" in the context of online or phone payments, they mean CVV2. The distinction is mostly invisible to cardholders, but it matters to payment processors and fraud teams because the two codes are different values, derived using different cryptographic inputs.

How the code works in a transaction

When you provide the code during a remote payment, the merchant's payment system sends it to the card issuer alongside the card number and expiry date. The issuer checks it against its records. If it matches, the transaction clears that particular check. If it doesn't, the transaction is declined or flagged for review.

The code isn't a PIN and it doesn't authenticate you as an individual. What it does is confirm that the person paying had the physical card — because the code is printed on the card but not encoded anywhere that a skimmer or data breach would capture it. In practice this raises the bar significantly for anyone trying to commit fraud using stolen card numbers alone.

PCI DSS and the prohibition on storing the code

PCI DSS treats the card security code as sensitive authentication data (SAD), and the rule about it is one of the strictest in the standard. Merchants may store other card data — the card number, expiry date, cardholder name — under encryption if there's a legitimate reason. The security code cannot be stored after authorisation under any circumstances. Not encrypted, not hashed, not tokenised. Once the payment has been authorised, it must be gone.

This prohibition covers every form of storage: databases, flat files, log files, paper notes, call recordings, screen-capture tools, and analytics systems. A business that keeps call recordings in which customers spoke their CVV aloud is storing prohibited data — even if that was never the intention.

Why telephone payments are a problem

The storage prohibition creates a real headache for contact centres. When a customer reads their security code to an agent over the phone, the code appears in at least three places simultaneously:

• The agent hears it and could write it down or memorise it
• The call recording captures it in the audio track
• Speech analytics or quality-monitoring tools may process that audio

All three are forms of storage that PCI DSS prohibits. Even if the agent does everything right, the recording system alone constitutes a violation. This is one of the most common PCI compliance failures in call centre environments, and it's often discovered only during a forensic investigation after a fraud incident.

DTMF masking is the solution. Instead of speaking the code, the customer keys it on their phone keypad. The tones are masked before they reach the agent — the agent hears a suppressed tone, not the individual digits — and the code is routed directly to the payment processor. It never appears in the call recording, never touches the agent's screen, and never enters the merchant's environment. The problem disappears.

Dynamic CVVs: the direction of travel

Static security codes have a known weakness: if someone photographs the back of a card, they have the code indefinitely. Several card issuers are now trialling dynamic CVV technology, where the code changes every 30 to 60 minutes and is displayed on a small e-ink screen built into the card. A code stolen in a data breach or photographed last week becomes useless almost immediately.

Dynamic CVVs are still rare, but they're the clearest signal that the industry recognises the static code's limitations. In the meantime, tokenisation and 3D Secure / SCA are increasingly supplementing or replacing CVV checks for online transactions. For telephone payments specifically, the security code remains the primary possession check — and the need to handle it correctly is as pressing as ever.

Common mistakes businesses make

The code trips up businesses in predictable ways:

• Recording calls that contain spoken CVVs — the most widespread violation in contact centres. The recording is the storage.
• Logging full transaction data — some payment integrations write debug logs that include every field submitted, including the security code. Check your logs.
• Storing codes for recurring payments — PCI DSS doesn't permit this. Use a payment token for repeat billing instead.
• Paper notes during calls — agents jotting card details to type up afterwards. The notepad is storage.
• Screen-capture tools during remote agent sessions — if the agent's screen shows the code while they type it, and the session is recorded, the recording captures it.