Card Security Guide
Card security covers CVV verification, 3D Secure, issuer fraud rules and card-not-present risk management.
By Daniel Cross, Senior Payment Systems Analyst · Last updated: 2026-10-20
The layers of card security
Card security is not one mechanism but a stack, and each layer answers a different question. The security code proves the number was read from a card. Tokenisation proves the number was stored safely on a device. Authentication proves the person making the transaction is the cardholder. Authorisation rules prove the transaction is allowed. And the issuer's risk policy decides whether to approve.
- Security code: the number came from the card, not from memory
- Tokenisation: the number was never stored on the device
- 3D Secure: the person is the cardholder
- Authorisation rules: the account and the transaction are allowed
- Network and issuer risk policy: whether to approve this particular attempt
What the security code does and does not do
The three or four digit code on a card is a fraud control, not a secret. It is printed on the card, so anyone holding the card can read it, and it is static, so it never expires. What it proves is narrow but genuinely useful: that the person transcribing the number had the physical card in front of them. That makes typing a number from a leaked database into a checkout fail, which is the case it was designed for.
- Proves the number was read from the card
- Does not authenticate the cardholder
- Never expires and changes only on reissue
- Must be scrubbed from logs, because it is cardholder data under PCI DSS
3D Secure and cardholder authentication
3D Secure, and the version 2 protocol, adds a challenge to the transaction that the cardholder has to complete, typically in a bank app. It produces a cryptographically signed result that the issuer receives alongside the authorisation, and that is what makes the liability shift meaningful. The practical effect is that a fraudster with a stolen number and a correct security code still cannot complete the transaction without the cardholder's device.
| Version | Challenge | Typical result |
|---|---|---|
| 3-D Secure 1 | A password or a one-time code | A signature over the transaction |
| 3-D Secure 2 | An in-app push, a biometric check or a one-time code | A signed authentication result with liability shift |
Tokenisation and device security
Storing a card number on a phone or a browser is the normal case now, and tokenisation is what makes it safe. When a number is provisioned, the device receives a token that stands in for it. The real number stays with the issuer, the token is bound to that device and that device only, and the token can be suspended without touching the card. A breach of a device therefore yields a token that is not useful anywhere else.
- The real account number is never stored on the device
- Tokens are device-specific and provision-scoped
- Each token can be suspended and replaced independently
- A token cannot be used on another device or at another merchant
- Device binding can be enforced at the issuer
Authorisation controls
Every transaction passes through a set of rules before the issuer approves it. The merchant and the issuer each apply their own: the merchant sets a limit on the size of the transaction it will accept without a step-up check, and the issuer applies its own risk policy, which may include a daily total, a velocity limit on repeat attempts, a rule about the country of the card versus the country of the merchant, or a block on a category.
| Control | Where it sits | What it prevents |
|---|---|---|
| Step-up authentication | Merchant or acquirer | A large transaction without a second factor |
| Velocity limit | Issuer | Repeated attempts on one account |
| Daily total limit | Issuer | More than a set amount in a period |
| Geofencing | Issuer or acquirer | A card used far from its normal location |
| Category block | Issuer or acquirer | A disallowed type of merchant |
What the merchant and the issuer each own
Responsibility is split, and the split is where most disputes come from. The merchant owns how the transaction is captured, how the security code is handled, and whether the transaction is stepped up when the amount is unusual. The issuer owns the risk decision and the liability outcome. A chargeback is a merchant losing a dispute, and the reason codes that drive it are set by the network, not by either party.
- Merchant: capture, security code handling, step-up policy, receipt evidence
- Issuer: risk decision, authorisation rules, liability outcome
- Network: the dispute reason codes and the process
- Cardholder: the dispute itself, and the first step-up challenge
Practical controls worth having on
Most of the value in card security comes from a short list of controls that are cheap to implement and that cover the overwhelming majority of attempts. The list is not exotic, and it is not a substitute for the issuer's own risk policy.
- Never log the full card number or the security code
- Always send the security code with a card-not-present transaction
- Use 3D Secure for card-not-present transactions, and treat its result as authoritative
- Tokenise rather than storing numbers
- Step up on amount, on an unusual merchant, or on a new device
- Keep evidence: the authorisation response, the AVS and CVV results, the timestamp
Frequently Asked Questions
What is card security?
The stack of controls that make a card payment safe: the security code, device tokenisation, cardholder authentication under 3D Secure, the authorisation rules, and the issuer's risk policy. Each answers a different question.
Does a CVV match mean a transaction is safe?
No. It proves the number was read from the card. It says nothing about whether the cardholder is present, whether the account is good, or whether the transaction is wanted.
What does 3D Secure actually protect against?
It proves the person making the transaction is the cardholder, which is what a stolen number cannot do. It is the control that makes a stolen card with a valid security code unusable.
Is storing a card number on my phone safe?
It is, if you tokenise. The real number stays with the issuer and the device holds a token that is bound to that device and can be revoked on its own.
Who decides whether a transaction is approved?
The issuer, on its own risk policy and the rules the network sets. The merchant and the acquirer can add controls that stop a transaction before it is sent, but they do not make the final decision.
What should a merchant never do with a security code?
Store it, log it, or accept it from the cardholder. It is cardholder data under PCI DSS, it must be scrubbed from logs and databases, and accepting it from the customer removes the only thing the check was for.
What is a chargeback?
A dispute raised by the cardholder and processed through the network's rules. The reason code is set by the network, and the outcome decides whether the merchant bears the loss.