80
Response Message Template Format 1Response Message Template Format 1 is the older, more compact of the two ways a card can answer GET PROCESSING OPTIONS: a single primitive value with no internal tags at all, where the first two bytes are always the Application Interchange Profile (82) and everything after that is the Application File Locator (94), in that fixed order, both already covered individually in this dictionary. There's no flexibility in this format - a terminal parsing 80 doesn't read tags, it reads byte positions, which makes it fast and simple but also fragile: any card that needs to return anything beyond exactly AIP-then-AFL cannot use this format at all and has to use its more flexible sibling, Response Message Template Format 2 (77, referenced alongside it), instead. A terminal library that assumes every GPO response comes back tagged, because it only ever tested against 77-style cards, will silently mis-parse a card that legitimately answers with 80, treating its raw AIP-plus-AFL bytes as if they were TLV-structured data they never were. See EMV Contactless Book C-2.
Interactive decoder
Paste a hex value for this tag to decode it in your browser. Nothing is sent anywhere.
Binary (6): 198008010100
This tag is not a bitmap; the decoder shows a format-based interpretation.
Decoded example
Example value: 198008010100
Properties
| Tag | 80 |
|---|---|
| Name | Response Message Template Format 1 |
| Format | Binary |
| Length | variable |
| Source | Card (ICC) |
| Templates | — |
| Books | EMV Contactless Book C-2 |
Frequently asked questions
- What is EMV tag 80?
- Response Message Template Format 1 is the older, more compact of the two ways a card can answer GET PROCESSING OPTIONS: a single primitive value with no internal tags at all, where the first two bytes are always the Application Interchange Profile (82) and everything after that is the Application File Locator (94), in that fixed order, both already covered individually in this dictionary. There's no flexibility in this format - a terminal parsing 80 doesn't read tags, it reads byte positions, which makes it fast and simple but also fragile: any card that needs to return anything beyond exactly AIP-then-AFL cannot use this format at all and has to use its more flexible sibling, Response Message Template Format 2 (77, referenced alongside it), instead. A terminal library that assumes every GPO response comes back tagged, because it only ever tested against 77-style cards, will silently mis-parse a card that legitimately answers with 80, treating its raw AIP-plus-AFL bytes as if they were TLV-structured data they never were. See EMV Contactless Book C-2.
- What format and length does EMV tag 80 use?
- Tag 80 uses the Binary format and is normally variable long.
- Is tag 80 provided by the card or the terminal?
- Tag 80 (Response Message Template Format 1) is provided by the Card (ICC).
Sources
- C-2-Kernel-2-V2.11-Final-June-2023, p. 415
Receive site updates
Subscribe to receive site updates directly to your email
We won't send spam. You can unsubscribe at any time.