9F26 里，而标签 9F27（密文信息数据，CID）告诉你手里这份是三种中的哪一种。它也是解开 EMV 里最让人迷惑的一类拒绝的钥匙：发卡方明明批准了，交易却还是失败了。
应用密文是卡片用只有它和发卡方共享的密钥，对交易数据算出来的一段 MAC。它证明两件事：真卡在场、金额没被改过。三种密文的区别不在算法，而在密文承载的决定：
| 类型 | 全称 | 含义 |
|---|---|---|
ARQC | Authorisation Request Cryptogram 授权请求密文 | 卡片自己定不了 —— 送去联机，让发卡方验证并决定 |
TC | Transaction Certificate 交易证书 | 批准 —— 或是脱机直接批，或是发卡方点头之后批。进清算记录的就是它 |
AAC | Application Authentication Cryptogram 应用认证密文 | 卡片自己拒绝 |
注意主语是谁。DE39 的拒绝码是发卡方说不行；AAC 是卡片说不行。两者可以不一致 —— 这正是本文后半篇要讲的事。
CID 只有一个字节。密文类型放在最高两位，所以你到处见到的三个值就是 80、40、00：
| 位 | 含义 |
|---|---|
b8 b7 | 密文类型：00 = AAC · 01 = TC · 10 = ARQC · 11 = RFU（早期 EMV 定义过 AAR，后来撤掉了） |
b6 b5 | RFU 保留 —— 应当为 0 |
b4 | 需要 advice —— 即使这笔没走联机，卡片也希望终端把情况通知发卡方 |
b3–b1 | advice / 原因码，三位合起来当一个数读：0 = 无说明，1 = 服务不允许，2 = PIN 尝试次数超限，3 = 发卡行认证失败 |
照这个拆：80 是 1000 0000，b8 b7 = 10，纯 ARQC；40 是 0100 0000，一个干净的 TC，普通批准；00 就是 AAC。低位在拒绝时才有戏：0B 是 0000 1011 —— AAC + 需要 advice + 原因 3「发卡行认证失败」。一笔纯脱机被卡片拒掉的交易，就是靠 advice 位让发卡方事后知情的。
终端用 GENERATE AC 命令向卡片要密文，并在命令里声明自己希望要哪种。卡片可以照给，也可以给一个更保守的：终端要 TC，卡片可以回 ARQC（先联机）或 AAC（不行）；终端要 ARQC，卡片仍然可以回 AAC。卡片永远有权向下改判，从不向上。
联机交易里这条命令要跑两次。第一次 GENERATE AC 产出 ARQC，装进 DE55 送往发卡方。应答回来后，终端发起第二次 GENERATE AC，把发卡方的回答交给卡片 —— 其中包括 ARPC，发卡方自己算的密文，装在标签 91 里（路上遇到不认识的标签，随手丢进 EMV 标签查询）。卡片校验 ARPC，验过了才签最终判决：认可就给 TC，不认可就给 AAC。
用真实值把第一段读一遍：卡片对第一次 GENERATE AC 回了 9F27 = 80 —— 丢进 CID 解析器，读出来是「ARQC —— 请求联机授权」。此刻既没批也没拒，卡片只是把决定权递给了发卡方。
坑就在这里。你翻授权日志，找到 0110 应答，DE39 = 00，结论是这笔批了。持卡人却咬定收银台上明明失败了。两边说的都对。
DE39 = 00 记录的是发卡方主机的决定，但交易此时还没走完：第二次 GENERATE AC 还没跑，而卡片要在那一步校验拿到的发卡方认证数据。如果 ARPC 验不过 —— 密钥版本不对、主机或 HSM 派生 ARPC 有错、应答在链路上被改动、中间某个网关把标签 91 剥掉或截断 —— 在卡片看来这份「批准」就是没凭据的。按发卡方预置在卡里的规则，它返回 AAC，终端只好拒绝一笔发卡方几秒前刚批准的交易。
这类问题的证据组合非常有辨识度：
00，一笔正常批准。00 —— CID 解析器读出来是「AAC —— 卡片拒绝交易」。该找谁，取决于 ARPC 坏在哪一段。某个卡产品下所有卡都失败，先怀疑发卡方的密钥配置或最近的 HSM 变更；只有某条收单路径失败，先怀疑发卡方和终端之间动过 DE55 的那个环节。卡片几乎从来不是元凶 —— 它只是那个报告「账算不上」的信使。
芯片交易结果对不上时，先把密文链读完再看别的：
40 说明脱机直接批了，压根不存在授权记录，别再翻授权日志。40 TC = 成了；00 AAC = 卡片推翻了前面的一切。00 AAC、01 TC、10 ARQC。一笔交易可以有两份判决，每次 GENERATE AC 一份。DE39 是发卡方的一票，最后那个 9F27 才是结果；两者相左时，以卡片为准。