CVM Results Decoder
Paste CVM Results (tag 9F34) and see which method the terminal performed, under which condition, and whether it succeeded.
Runs entirely in your browser. Nothing you paste is uploaded, logged or stored.
Cardholder Verification Method Results (tag 9F34)
Which CVM the terminal actually performed, under what condition, and whether it worked. Byte 3 is the one people want: 02 means the CVM succeeded.
Cardholder Verification Method Results bit table (tag 9F34)
3 bytes, 6 hex characters. Byte 1 is the leftmost, and b8 is the most significant bit of each byte.
Byte 1: CVM Performed
| Value | Meaning |
|---|---|
| 41 | Plaintext PIN verification by ICC (apply succeeding rule if it fails) |
| 42 | Enciphered PIN verified online (apply succeeding rule if it fails) |
| 44 | Enciphered PIN verification by ICC (apply succeeding rule if it fails) |
| 00 | Fail CVM processing |
| 01 | Plaintext PIN verification performed by ICC |
| 02 | Enciphered PIN verified online |
| 03 | Plaintext PIN verification performed by ICC and signature (paper) |
| 04 | Enciphered PIN verification performed by ICC |
| 05 | Enciphered PIN verification performed by ICC and signature (paper) |
| 1E | Signature (paper) |
| 1F | No CVM required |
| 3F | No CVM performed |
| 5E | Signature (paper) (apply succeeding rule if it fails) |
| 5F | No CVM required (apply succeeding rule if it fails) |
Byte 2: CVM Condition
| Value | Meaning |
|---|---|
| 00 | Always |
| 01 | If unattended cash |
| 02 | If not unattended cash and not manual cash and not purchase with cashback |
| 03 | If terminal supports the CVM |
| 04 | If manual cash |
| 05 | If purchase with cashback |
| 06 | If transaction is in the application currency and is under X value |
| 07 | If transaction is in the application currency and is over X value |
| 08 | If transaction is in the application currency and is under Y value |
| 09 | If transaction is in the application currency and is over Y value |
Byte 3: CVM Result
| Value | Meaning |
|---|---|
| 00 | Unknown |
| 01 | Failed |
| 02 | Successful |
Other fields: TVR decoder , TSI decoder , AIP decoder , 9F33 decoder , TTQ decoder , and the rest (AUC, CID, 9F40, 9F35, CTQ) in the bit field decoder .
Three bytes, read separately
CVM Results is tag 9F34. It is not a bitmap: each byte is a code. Byte 1 is the
method the terminal performed, byte 2 is the condition attached to the rule it used, and byte
3 is the result. Bytes 1 and 2 are copied from the rule in the card's CVM List that the
terminal applied, which is why the same codes appear in the
CVM list parser.
Byte 3 has three values
02 is successful and 01 is failed. 00 is unknown, and
it is a normal answer. An online PIN is checked by the issuer, so at the moment the terminal
writes this field it cannot know the result. A signature is checked by a person after the
receipt prints. Both are recorded with byte 3 as 00.
So 020000, online PIN with an unknown result, is what a healthy online PIN
transaction looks like. Reading the 00 as a failure is the commonest mistake made
with this field.
The high bits of byte 1
In byte 1, b7 means "apply the succeeding CVM rule if this one is unsuccessful". It changes
what happens after a failure and nothing about the method. 01 and
41 are both plaintext PIN verified by the card, 02 and
42 are both online PIN, and 1E and 5E are both
signature.
1F and 3F look alike and are not. 1F is "no CVM
required", a rule the card listed and the terminal applied, and it is recorded as successful:
1F0002. 3F is "no CVM performed", the value the terminal writes when
no rule in the list could be applied, and it usually comes with the
TVR bit "cardholder verification was not successful".
Values you will see often
410302: plaintext offline PIN, the terminal supported it, and the card verified
it. 440302 is the same with an enciphered offline PIN. 420300:
online PIN, sent to the issuer. 1E0300: signature. 1F0002: no CVM
required, typical of a low-value transaction. 3F0000: no CVM performed.
Check it against the rest
The method in byte 1 has to be one the terminal claims in byte 2 of Terminal Capabilities, and one the card's list contains. When it is not, the usual cause is a value captured from a different transaction, or a contactless tap, where the kernel decides the CVM by its own rules and may fill this field differently from the contact flow.
More EMV chip tools
All EMV chip toolsTLV parser
Paste BER-TLV hex and get a decoded tag tree with EMV names, formats and nested templates.
Bit fields
Decode TVR, TSI, AIP, AUC, CID, CVM Results, Terminal Capabilities and the contactless qualifiers.
TVR decoder
Paste a TVR (tag 95) and see which of its 40 bits are set, with the full bit table underneath.
TSI decoder
Paste a TSI (tag 9B) and see which processing steps the terminal says it performed.
AIP decoder
Paste an AIP (tag 82) and see what the card supports: SDA, DDA, CDA, cardholder verification and issuer authentication.
9F33 decoder
Paste Terminal Capabilities (tag 9F33) and see how the terminal reads cards, which CVMs it offers and which offline authentication it supports.
TTQ decoder
Paste a TTQ (tag 9F66) and see what the contactless reader told the card about its capabilities and requirements.
IAC vs TVR
Compare a TVR against the Issuer Action Codes to see exactly which bit forced the decline or the go-online.
CVM list
Break tag 8E into its X and Y amounts and the cardholder verification rules, in priority order.
Status words
What 9000, 6A82, 6985 and the rest of SW1SW2 actually mean.
AID lookup
Application identifiers to scheme and product: A0000000031010 and friends.
EMVCo QR
Decode a merchant-presented QR payload and verify its CRC.