The short code printed on a payment card is the field people hesitate over when they read a card aloud, and that hesitation is the whole point. A CVV is a separate secret that lives only on the plastic, not in the number, not in the expiry date, and not in anything a thief could reconstruct from a receipt. It was added because card-not-present payments needed some evidence that the person typing the details actually had the card in hand.
This article explains what the code is, why its length changes between networks, why payment rules forbid keeping it, and what to watch for when you build or test a form that asks for one.
What the security code is and where it is printed
For most networks the code is three digits printed on the back of the card, either inside the signature strip or immediately beside it. American Express puts four digits on the front, above the last group of the card number.
The value is generated by the issuer when the card is produced. It is not derived from the card number, it is not a checksum, and it cannot be calculated from anything else printed on the card. If you lose the code you cannot recover it by arithmetic; the issuer has to reissue.
Documentation uses several names for it, and the numbering in those names is meaningful rather than decorative. The plain term describes data encoded in the magnetic stripe or the chip, while the version numbered two is the printed value a customer reads out. A test of a card-present terminal and a test of a checkout page are therefore touching different fields, even though the names sound interchangeable.
| Network family | Code length | Where it is printed |
|---|---|---|
| Visa, Mastercard, Discover, UnionPay | Three digits | Back of the card |
| American Express | Four digits | Front of the card |
Why is the code three digits on some cards and four on others?
The difference comes from the numbering plan each network chose, not from a security distinction. A four-digit code is not stronger than a three-digit code in any meaningful sense; both are short enough that guessing is not the threat model. The length is simply part of the network’s specification, in the same way that its card numbers use a different number of digits.
For anyone building a form, that single fact generates most of the bugs in this area. A field hard-coded to three characters truncates an American Express code without telling the user, and a validator that insists on three digits rejects a legitimate card. The pragmatic approach is to ask the user for the brand first, or detect it from the number, and size the field accordingly — with an upper bound that still refuses absurd input.
What does the code prove, and what does it not prove?
In a card-not-present transaction the merchant cannot see the card, so the payment system asks for something a person holding it can read off. The number and expiry could have been copied from an old invoice or a leaked database; the printed code could not, because it was never written down anywhere else.
That makes it a modest but real obstacle to casual fraud, and it is why the field is not decorative. Networks treat the code as evidence that a transaction met a higher verification bar, and merchants who collect it properly are handled differently from those who do not when fraud is disputed. The precise terms of that liability shift belong to the networks; the practical takeaway for anyone building a form is simply that the field must be collected, not simulated.
What the code does not prove is that the card is genuine or that the account is in good standing. A guessed value in the right shape passes any client-side check instantly, because a form has no way to verify a secret it cannot see. Only an authorisation request against the issuer can answer that question.
Why do card rules forbid storing the code?
This is the rule that surprises engineering teams most. Under the card industry’s data security standard, the security code is classified as sensitive authentication data. It may be used to authorise a transaction, and it must not be retained after authorisation — not in a database column, not in a log file, not in a spreadsheet, not in a message on a queue that a worker consumes ten seconds later.
The reasoning is straightforward. A stored code is a stored payment credential. If a breach exposes card numbers, the attacker still needs something more to use them online; if it exposes the codes alongside, the numbers become immediately usable.
In review, the failures rarely look like deliberate choices:
- A column added to the orders table for one debugging session and never dropped.
- Request logging middleware that records the whole submitted body, code included, into an aggregator with weaker access controls than the payment system.
- An error reporter that attaches the failing form payload to every exception.
- A retry queue that keeps the original charge request intact so it can be replayed.
Each is a compliance failure, and none of them looks like one at the time it is written.
Filling in a security code field without mistakes
Most of the difficulty here is typing rather than security, and the awkward cases are predictable enough to design for:
- A code longer than the field. Someone pastes four digits into a three-character box. Either truncate quietly or show a message, but pick one behaviour and apply it consistently.
- Non-numeric input. Letters, a space, a hyphen from a copied block. The field should refuse them without clearing what the user has already typed.
- Leading zeros. A code beginning with zero is legal and must not be normalised away by parsing the value as a number.
- Masking. Concealing the digits as they are typed looks reassuring, but check that it does not break autofill or make the browser treat the whole checkout as a login screen.
- Mobile keyboards. A numeric keypad is faster to use, which matters on a field people type while holding a card in the other hand.
For developers: keeping the code out of logs and storage
The engineering discipline here is subtraction. The safest handling of sensitive authentication data is not to have it in a system at any point other than the moment of authorisation.
Start by reviewing what your logging layer actually captures. A framework that logs request bodies by default will record the code, and the log destination is often a third-party service with different access rules. If the code never reaches your server at all — because a hosted payment field collects it directly — the problem disappears, and that is the strongest option available.
Where you do handle the value, treat it as transient. Do not add it to a model object that gets serialised into an audit row, do not include it in a retry payload, and do not let an exception handler attach it to a report. Write a test that searches your log output after a run and fails if a code-shaped value appears; that single check catches the majority of accidental retention.
Then look at your test data. Anything that fills the field automatically should come from synthetic values, reviewed with the same care as any other payment fixture. The PCI DSS notes cover the wider rules about what may live in a test environment, and the payment form checklist places this field in the sequence of flows worth exercising before launch.
Test cards and their placeholder codes
A generated card needs a code to fill the field, and that value is a placeholder in the same way the rest of the card is. It has the right length and the right character set, and it corresponds to no secret held by any issuer.
That is the accurate way to describe everything the generator on this site returns: structurally valid data that was never issued. A placeholder code makes a demo or a staging test look complete, and it will not authorise anything anywhere.
Next steps
Check one form you own for three things in order: whether the field adapts to the network’s code length, whether the value ends up in any log or table, and whether the error messages distinguish a wrong length from an unsupported character. For a number to pair with the field, use the card number generator, and for the date that sits beside it, the expiry date guide covers the boundary rules.