CVV vs CVC vs CID: card security codes explained

Every card-not-present checkout asks for the same short code, but the label changes with the card: Visa says CVV, Mastercard says CVC, American Express says CID. Developers then have to decide how long the field should be, what to validate and what may be logged. The answers are simpler than the alphabet soup suggests.

What a card security code is for

The card security code is a short value printed on the card but not contained in the card number. When a customer types it into an online checkout, the issuer can compare it with the value it expects for that card. A match is evidence that the payer has the physical card — or at least saw it — rather than just a list of card numbers.

That evidence matters most for card-not-present payments: e-commerce, apps and phone orders, where nobody can inspect the card. It is one layer of fraud prevention alongside address verification (AVS) and 3-D Secure, not a complete defense: a phishing page can steal the code together with the number.

The names used by each network

Every network gives the code its own name, but the function is the same. Generic terms you will also see are CSC (card security code) and CVD (card verification data).

In your UI, a neutral label such as “Security code” plus a small hint (“3 digits on the back, 4 on the front for Amex”) works for every brand. Switch the hint once you have detected the brand from the card number’s prefix — the card number format page lists the prefixes.

CVV1, CVV2, iCVV and dynamic codes

The “2” in CVV2 and CVC2 is there because there is also a version 1. Several related values exist, and each is used in a different channel:

The printed code and the stripe value are calculated with different inputs, which is why reading a magnetic stripe does not reveal the code you type online. With dynamic CVV, some issuers no longer print a fixed code at all; the cardholder gets a fresh one in their banking app. For a checkout this changes nothing — you still collect three or four digits and pass them to the gateway.

How issuers generate the code

The code is not computed from the card number with a public formula the way the Luhn check digit is. The issuer derives it cryptographically from the card number, the expiry date and a service code, using secret keys kept in hardware security modules. Different service codes produce the stripe value, the printed value and the chip value from the same card data.

Two practical consequences follow:

• A merchant cannot tell whether a code is correct. Only the issuer, holding the keys, can verify it during authorization.
• A random code that a card generator produces is just three or four random digits. It fits the field and nothing more.

With only 1,000 possible three-digit values, the protection depends on issuers and merchants limiting repeated attempts. That is why guessing security codes is a hallmark of card-testing attacks, and why velocity limits belong next to every payment form.

Validating the security code in a form

Client-side validation can only check the shape of the value. Keep it simple and brand-aware:

• Digits only, as a string. Codes can start with zero (042), so never convert them to a number.
• Length by brand. Four digits for American Express, three for Visa, Mastercard, Discover, JCB, Diners Club and UnionPay. Before the brand is known, accept three or four.
• Correct input hints. Use inputmode="numeric" for a numeric keypad and autocomplete="cc-csc" so browsers and password managers can fill it.
• Don’t mask it as a password field. Customers mistype hidden digits; a plain text field with a short length is enough on the payment page.

<label for="cc-csc">Security code</label>
<input id="cc-csc" name="cc-csc" inputmode="numeric" autocomplete="cc-csc"
       maxlength="4" pattern="[0-9]{3,4}" required>

<script>
  // brand comes from your card-number detection: 'amex', 'visa', 'mastercard', ...
  function cscError(value, brand) {
    const len = brand === 'amex' ? 4 : brand ? 3 : null;
    if (!/^[0-9]+$/.test(value)) return 'Use digits only';
    if (len && value.length !== len) return `Enter the ${len}-digit security code`;
    if (!len && (value.length < 3 || value.length > 4)) return 'Enter 3 or 4 digits';
    return null;   // well formed; the issuer decides whether it matches
  }
</script>

If you use a hosted payment field from your gateway (Stripe Elements, Braintree Hosted Fields, Adyen Components and similar), the code never touches your page’s JavaScript or your servers. That is the simplest way to keep it out of your systems entirely.

Storage: the PCI DSS rule

The card verification code is sensitive authentication data under PCI DSS. The PCI Security Standards Council states that merchants may request it from cardholders, but PCI DSS Requirement 3.3.1.2 strictly prohibits storing it after authorization — even if it is encrypted.

What that means in practice

• Collect it only for an authorization and discard it as soon as the authorization completes.
• Not for card-on-file or recurring payments. The Council’s FAQ says codes are not needed for those transactions and storage for these purposes is prohibited. A customer’s permission does not change this.
• Watch logs and tooling. Request-body logging, error trackers, analytics, support tickets and database backups are the usual places a code ends up by accident. Filter cvc, cvv and csc fields before anything is written.
• No “temporary” storage. A process that claims to delete the code but can still retrieve it for later authorizations is storage.

For the wider picture — why real card data, including codes, should never be in development and test systems — see Test data and PCI DSS.

What the issuer’s answer looks like

When you send a code, the issuer returns a separate result for it alongside the approve-or-decline decision. Gateways normalize that result; Stripe, for instance, reports cvc_check as pass, fail, unavailable or unchecked. Depending on the issuer and your gateway settings, a mismatched code can produce an outright decline, or an approval with a failed check that your own rules then reject.

• Mismatch: ask the customer to check the code, and count the attempt towards your velocity limits.
• Unavailable: the issuer did not check it. Decide whether to accept based on other signals.
• Not sent: the check is skipped. Stripe notes that if you omit the code, the check cannot fail — so require the field if your fraud rules depend on it.

Testing security code failures in a sandbox

Most sandboxes accept any code of the correct length, so the happy path is easy. To test the failure path, each gateway documents a specific card or trigger. These come from the official documentation listed on our test card numbers pages:

Check that your UI shows a clear message (“The security code doesn’t match. Please check the card.”), that the attempt is logged without the code itself, and that repeated failures trigger your rate limits.

Common mistakes

• Fixed three-digit fields. They lock out American Express customers. Size the field for four digits and validate per brand.
• Converting to an integer. 042 becomes 42 and fails at the issuer.
• Optional field without a reason. If you don’t send a code, you lose the issuer’s check entirely.
• Leaking it into logs. The most common way codes end up stored against PCI DSS rules.
• Treating a match as proof of identity. A matching code proves knowledge of the code, not that the payer is the cardholder. Combine it with AVS, 3-D Secure and behavior signals.