What is a Card Security Code?

What Is a Card Security Code?

A card security code is a three or four-digit number printed on a payment card that is used to verify the cardholder has physical possession of the card during a transaction. It goes by many names -- CVV (Card Verification Value), CVC (Card Verification Code), CV2, CSC, or simply the security code -- but they all refer to the same thing: a short numeric code that adds a layer of fraud protection to card-not-present transactions.

For Visa, Mastercard, Discover, and JCB cards, the code is three digits long and printed on the back of the card, usually on or near the signature strip. For American Express cards, it is four digits long and printed on the front of the card, above the card number.

How Card Security Codes Work

The card security code exists for one specific purpose: to prove that the person making a card-not-present transaction (online, over the phone, or by mail) has the physical card in their hand. Here is why this matters.

If a criminal steals a card number -- from a database breach, a skimmed card, or a discarded receipt -- they get the long card number and expiry date. But the security code is not stored in the magnetic stripe data, it is not embossed on the card, and under PCI DSS rules it must never be stored by merchants after authorisation. This means a stolen card number alone is not enough to complete a transaction that requires the security code.

When a customer provides their security code during a transaction, the merchant sends it to the payment processor, which forwards it to the card-issuing bank. The bank checks whether the code matches the one associated with that card. If it matches, the transaction passes that particular verification check. If it does not, the transaction is declined or flagged.

CVV1 vs CVV2

There are actually two different card verification values on most cards:

• CVV1 (or CVC1) Encoded in the magnetic stripe of the card. It is read automatically when the card is swiped at a terminal and is used for card-present verification. You never see or type this number.
• CVV2 (or CVC2) The printed code on the card's surface. This is what people mean when they talk about the "security code" for online or phone payments. It is designed specifically for card-not-present transactions where the magnetic stripe cannot be read.

When merchants ask for your "CVV" during an online or telephone payment, they are asking for the CVV2 -- the printed code.

Why Security Codes Must Never Be Stored

PCI DSS explicitly prohibits the storage of card security codes after a transaction has been authorised. This is one of the most important rules in the standard, and it exists for a critical reason: if security codes were stored alongside card numbers, a data breach would give criminals everything they need to make fraudulent card-not-present transactions.

By ensuring that security codes are only used in real time and never retained, the standard limits the usefulness of stolen card data. Even if a criminal obtains a card number and expiry date from a breached database, they still cannot complete transactions that require the security code -- unless they also have the physical card.

This prohibition applies everywhere: databases, flat files, logs, call recordings, paper notes, and any other form of storage. Businesses that store security codes -- even inadvertently in log files or call recordings -- are in violation of PCI DSS and face significant penalties.

Card Security Codes and Telephone Payments

Telephone payments create a unique challenge for card security codes. When a customer reads their security code to an agent over the phone:

• The agent hears the code and may write it down or memorise it
• Call recording systems capture the spoken code in the audio file
• The code may be visible on the agent's screen as they type it into a payment system

All of these scenarios create potential PCI DSS violations. The call recording is effectively storing the security code, which is explicitly prohibited. The agent has access to sensitive authentication data, which brings their entire workstation into PCI scope.

This is one of the strongest arguments for DTMF masking in telephone payment environments. When the customer enters their security code on their phone keypad instead of speaking it, and the tones are masked before reaching the agent, the code never enters the voice channel, never reaches the agent, and never appears in any recording. The data goes directly from the caller's keypad to the payment processor -- the only place it needs to be.

Dynamic Security Codes

Some card issuers have begun experimenting with dynamic security codes that change periodically -- every 30 to 60 minutes, for example. These are typically displayed on a small screen built into the card (known as a display card) and provide an additional layer of security because a stolen code becomes useless once it changes.

Dynamic CVVs are still relatively rare, but they represent the direction of travel for card security: making stolen data useless as quickly as possible.

Common Mistakes with Security Codes

Businesses frequently make errors with how they handle card security codes:

• Recording calls that contain security codes If agents ask customers to speak their CVV and the call is recorded, the security code is being stored -- a PCI DSS violation
• Logging security codes in payment system logs Some payment integrations accidentally log full transaction data including the CVV. Regular log reviews should check for this
• Storing codes for recurring transactions Businesses sometimes store the security code alongside the card number to use for future payments. This is prohibited. Recurring payments should use tokenisation instead
• Writing codes on paper Agents who write down card details including the security code create a physical storage risk that is easily overlooked