TTQ Decoder
Decode the Terminal Transaction Qualifiers (tag 9F66) — the 4-byte bitmap a contactless reader sends to the card declaring what it supports and requires. Tag 9F66 is kernel-specific: pick Visa (K3), Discover (K6) or UnionPay (K7). Mastercard, Amex and JCB do not use this tag.
Tag 9F66 is kernel-specific — the same bytes mean different things per kernel. Visa contactless (Kernel 3) qVSDC layout. Mastercard/Amex/JCB do not use 9F66.
What the Terminal Transaction Qualifiers (9F66) tell the card
The Terminal Transaction Qualifiers (TTQ), EMV tag 9F66, is a 4-byte bitmap a contactless reader hands to the card at the very start of a tap. It is the terminal's opening statement: which interfaces and transaction modes the reader supports (mag-stripe, qVSDC/EMV, contact chip), whether it can go online, and which cardholder verification methods — online PIN, signature, or consumer-device CVM — it is prepared to honour. The card reads these bits and decides how to respond, so a single wrong bit can change the entire authorisation path.
In a Visa qVSDC tap the TTQ travels in the PDOL requested by the card during GPO, and the card may return an updated TTQ in tag 9F66 inside the response. That is why you will often see two TTQ values in a trace — the one the terminal offered and the one the card settled on.
Why this tag is kernel-specific
Unlike most EMV tags, 9F66 does not have one universal layout. The same four bytes are interpreted differently depending on the contactless kernel:
- Visa, Kernel 3 (VCPS / qVSDC) — the original and most common layout.
- Discover, Kernel 6 (D-PAS) — adds Fast Mode and transit-profile bits.
- UnionPay, Kernel 7 (QuickPass) — uses byte 4 for fDDA support.
Mastercard (Kernel 2), American Express (Kernel 4) and JCB (Kernel 5) do not use the TTQ at all — they carry equivalent capability flags in their own kernel data. Decoding a Mastercard tap against the Visa layout is one of the most common analysis mistakes, which is why this decoder asks you to pick the kernel first.
How to read the breakdown
Each byte is shown with its set (●) and cleared flags. Byte 1 is mostly about reader capability — what the terminal can do — while byte 2 carries requirements that force a behaviour, such as "Online cryptogram required" or "CVM required". If byte 2 demands an online cryptogram, an offline-only card will decline; if it demands CVM, the card must present a verification method the terminal supports. Reading bytes 1 and 2 together usually explains why a tap went online, fell back, or asked for a PIN.
Common questions
A tap went online unexpectedly — where do I look?
Check byte 2 bit 8 ("Online cryptogram required"). When the reader sets it, the card is obliged to request an online authorisation regardless of offline limits.
Why did the terminal ask for online PIN on a low-value tap?
Byte 1 bit 2 ("Online PIN supported") combined with byte 2 bit 6 ("CVM required") tells the card the reader both wants and can collect a PIN. The card's risk parameters then decide whether to invoke it.
Is a value of 00000000 valid?
It is well-formed but means "no capabilities indicated", which no real reader sends. In a trace it usually points to a terminal-configuration or PDOL-population bug.
Bit definitions follow EMVCo Book C-3 (Visa/Kernel 3), Book C-6 (Discover/Kernel 6) and Book C-7 v2.11 (UnionPay/Kernel 7). All decoding happens locally in your browser — nothing you paste here is transmitted or stored.