| Name | On the card | In the ISO 8583 message | Verified by |
|---|---|---|---|
| CVV / CVC (track CVV, "CVV1") | Encoded in the magstripe, inside the track's discretionary data | DE 35 (Track 2 Data) / DE 45 (Track 1 Data) | Issuer |
| CVV2 / CVC2 (Amex: CID) | Printed on the card β 3 digits on the back (Amex: 4 on the front). Not encoded in any track. | A scheme-defined subfield of an additional data element. Which element and which subfield differ per network β check your endpoint's interface spec. | Issuer |
| iCVV | In the chip, inside Track 2 Equivalent Data (EMV tag 57) | Usually inside DE 55 (ICC / EMV Data), as tag 57 | Issuer |
| dCVV (Mastercard: CVC3) | Nowhere β computed fresh by the card for each tap in contactless magstripe mode (MSD, largely legacy) | Rides in the track 2 data of the tap, so it arrives where a swipe would: DE 35 β but the value changes every transaction | Issuer |
Note what the last column has in common: only the issuer can verify any of them. Acquirers, gateways and switches just carry the value to the right place in the message. That is why most CVV-related production issues turn out to be transport problems β the value ended up in the wrong field, or in a transaction type that should not carry it at all.
The chip's Track 2 Equivalent Data (tag 57) looks almost identical to the magstripe's track 2: same PAN, same expiry, same service code. The check value inside the discretionary data, however, is a different number β the iCVV β and that is deliberate.
If someone dumps tag 57 from a chip and writes it onto a blank magstripe card, the counterfeit swipe presents an iCVV where the issuer expects a track CVV. The check fails and the transaction declines. One value per channel means data stolen from one channel cannot be replayed on another β this is a core piece of EMV's defense against chip-to-magstripe cloning.
A chip transaction can contain track-2-shaped data twice: in DE 35 (Track 2 Data) and inside DE 55 as tag 57 (Track 2 Equivalent Data). PAN and expiry match; the discretionary data at the end does not. That is not corruption and not a terminal bug β it is the previous section in action: one carries a track CVV, the other carries an iCVV, and they are supposed to differ.
To see it yourself, paste the DE 55 hex into the EMV TLV parser and compare tag 57 against DE 35, or drop the whole message into the main parser. The field guide covers DE 35 / DE 45 / DE 55 formats in detail, and the message examples show them in full messages.
A classic ticket: the receipt or host log shows a CVV2 verification failure, the cardholder insists the printed code was entered exactly. Before assuming a mistyped code, walk this list:
PCI DSS forbids storing the card verification code after authorization β not "encrypt it carefully": do not retain it at all, in any form. That includes request logs, database columns, crash dumps and screenshots pasted into tickets. CVV2 exists purely to prove possession at the moment of the transaction; there is no legitimate reason to persist it.
The same rule covers full track data β DE 35, DE 45, and the chip's tag 57 β which is sensitive authentication data too. In practice the database schema is rarely the problem; unredacted request/response logging is. Check that masking happens before the message hits your log pipeline.
Which leaves the awkward part: to confirm the masking works, someone has to look at an unmasked line at least once. Everything on this site parses in your browser and nothing is uploaded β but that is not something you can demonstrate to a security reviewer from inside a browser tab, so what happens instead is people retype fields off a screenshot. The offline edition is the same parser as a file on your disk, for when that is the difference that matters.
π Related: ISO 8583 field guide (DE 35 / 45 / 55), EMV tag reference (tag 57).