应用选择：
1.ADF、DDF、AEF、EF、DF有什么区别
ADF、DDF、AEF就是PBOC规范里面的名词了，ADF和DDF其实就是DF的一个映射，AEF就是EF的映射，我们不能直接操作DF和EF，只能操作ADF和DDF以及AEF，就相当于内存管理里面物理地址和虚拟地址一样，程序不能直接使用物理地址，只能使用虚拟地址，而内存管理的单元回去实现虚拟地址到物理地址的映射。
2.既然ADF和DDF都是DF的映射，那他们两个有啥区别呢？
DDF还是一个目录，这个目录下面可能有ADF，也可能还是有DDF的。
ADF也是一个目录，但是这个目录已经是aid的目录了，这个目录的名称就是AID了。
再根据ADF名称去选择ADF，ADF下面都是AEF，也就是这个AID多对应的有用数据文件，终端在GPO时候根据返回的AFL，再去读取对应的文件。
3.目录选择法在选择完PSE后是如何获得AID的
选择完PSE之后，PSE目录会返回SFI（tag 88），然后终端根据SFI，再执行READ RECORD命令读取记录，读记录根据SFI循环读取，直到卡片返回6A83为止，这个时候终端已经获取到卡片支持的AID（tag 4F）。
4.当卡片和终端有多个应用支持时，终端是根据什么判断是否需要持卡人选择应用的
根据应用优先级指示器的bit8来判断是否需要提示持卡人选择应用。
5.选择应用时如果在未读到记录之前或者读记录后检查数据非法等情况怎么办？
如果遇到上述情况，则均可认为是目录选择法失败，这时候就需要改用AID选择法。
6.Qpboc和借贷记应用的在选择应用部分的区别
Q选择的是PPSE，借贷记选择的是PSE；Q不支持持卡人选择应用和AID列表选择法，Q的流程相对精简。
Q在选择完PPSE之后已经可以获取到AID（可能是多个）、应用优先级、应用指示器，Q不支持持卡人选择应用，所以如果有多个AID的时候，需要根据应用优先级选择优先级最高的AID，再根据AID选择ADF，就可以获取到PDOL（关键数据）、发行卡代码等数据。
借贷记需要根据选择PSE返回的SFI读记录获取AID，再根据AID去选择ADF，再去读数据；Q在选择PPSE之后就可以获取到AID，直接选择ADF了。
应用初始化&&读应用数据
1.GPO命令是怎么组的？
应用选择完成后，终端获取到了PDOL数据，GPO根据PDOL中的TAG组数据域传送给卡片
2.终端一定会有PDOL吗，没有PDOL哪些交易不能进行？
卡片可以不给终端提供PDOL，如果终端没有获取到PDOL，则GPO数据域直接传递8300，如果卡片不提供PDOL的话，后续这张卡是不能做电子现金和Q的交易
3.GPO命令后的读记录命令是根据什么读的，怎么知道哪些记录用于数据认证
读记录命令是根据AFL读的，其包含终端将要读取用来交易处理的卡片数据文件的SFI和记录范围。每个要读取的文件在AFL中对应四个字节，含义如下：
字节1：短文件标识符
字节2：文件中要读取的第1个记录的记录号
字节3：文件中要读取的最后一个记录的记录号
字节4：从第1个记录开始的用于脱机数据认证的连续记录数
4.根据什么知道终端要执行哪些过程？
后续的过程根据终端性能和卡片的支持能力决定哪些步骤要执行，支持哪种数据认证，是否支持持卡人认证，是否支持发卡行认证等，但风险管理是强制执行的不依据AIP里的值
5.QPBOC联机和QPBOC脱机的GPO响应数据有比较大的区别？
qPBOC联机交易或拒绝交易的GPO响应数据中是不返回AFL的，而QPBOC脱机的GPO响应数据中返回AFL
6.如何判断非接中到底是走QPBOC流程还是走非接触借贷记流程？
——如果卡片响应GPO命令的状态字为“9000”，假设终端仅支持一种非接触选项（qPBOC或非接触式借记/贷记应用），则终端应按此选项继续处理，不必判断AIP；
——如果卡片响应GPO命令的状态字为“9000”，并且AIP第2字节第8位置‘0’，假设终端支持qPBOC，并且应用密文（标签“9F26”）在GPO命令响应中出现，则终端应按照qPBOC处理交易。如果标签为“9F26”的数据项不出现，则终端应按照非接触式借记/贷记应用处理交易。
7.QPBOC的GPO数据返回数据量为什么比较大？
为了提高交互速度，减少终端与卡片交互次数，为此提高了单次交互的数据量，所以Q的GPO返回的数据量比较大，除了AIP和AFL之外，还有应用密文，交易计数器，发卡行应用数据，二磁道数据等多个数据。
8.SFI文件范围1-10,11-20,21-30的区别？
1－10：EMV数据文件；
11－20：支付系统数据文件；
21－30：发卡行数据文件；
9.在读应用数据中,终端出现哪几种情况会终止交易?
(1)卡片在一条或多条记录中返回同一个标签两次及两次以上；
(2)卡片在某条记录中返回了卡片已经在GPO响应中返回的标签；
(3)卡片中缺少必须有的数据；
(4)数据格式错；
(5)READ RECORD 命令返回状态字不是“9000“。
脱机数据认证：
1.终端根据什么来决定执行哪种脱机数据认证方式？
取决于两个要素AIP和终端性能。
2.应用开发工程师在分析IC卡交易失败的时候要看什么做判断？
交易没走步都要首先分析AIP和终端性能的各个位的情况，而交易每执行完一步都要对TVR和TSI进行置位或者清零。
在分析IC卡失败交易的第一步应该是看TVR和TSI，看看终端做过什么，终端哪一步失败了，然后在分析某个步骤失败的原因。
3.对于参与脱机数据认证的SFI有明确分类，分为SFI从1-10以及11-30两类，这两类在参与认证上有什么区别？
1-10的SFI在参与脱机数据认证的时候，其文件标志“70”和记录长度不参与脱机数据认证，而SFI为11-30的，则70和记录长度也要参与脱机数据认证。
4.静态数据认证SDA是如何认证的？
三步走：一步获取认证中心公钥，二步恢复发卡行公钥，三步进行数据认证
一步获取认证中心公钥：首先通过公钥下载将服务端的公钥挨个下载到终端，在获取认证中心公钥的时候要做两个判一个判断是选择AID的5个字节为RID，另一个判断是需要用到度记录时获取到的发卡行公钥索引（8F），通过RID和索引可以选择到唯一的一组公钥，选择完成后，获取中心公钥即成功
二步恢复发卡行公钥：首先读记录的时候已经获取到发卡行90（签名处理过的发卡行公钥，92（发卡行公钥余项），9F32（发卡行公钥指数），所以这个时候可以用CA公钥利用RSA算法对90的数据解密。解密后的数据为一个比较复杂的数据格式，需要对数据的头尾，以及中间数据做判断，其中对后续才做有用的数据是“哈希值”，执行完这一步，终端已经获取到了卡片计算出的哈希值，执行完这一步，终端已经获取到了卡片计算出的哈希值，卡片计算哈希值的方法和终端的一样，故只要知道这里获取到了发卡行公钥或者发卡行公钥最左边的部分以及获取到了哈希值就OK了。
卡片已经返回了哈希值，终端自然也要计算一个哈希值，计算方法：
首先组织一长串数据，格式：证书格式 +发卡行标识(主账号最左面的3 -8个数字) +证书失效日期 +证书序列号 +哈希算法标识 +发卡行公钥算法标识 +发卡行公钥长度 +发卡行公钥指数长度 +发卡行公钥模数的完整数据 128个字节+发卡行公钥指数
特别说明：发卡行公钥模数的完整数据一部分是在还原发行卡公钥数据过程中获取的，还有另外一部分是在卡片读记录的时候通过92tag获取到的。除此之外，其他数据都为卡片返回原始数据，或者是一些固定写死的值。
然后用组好的数据进行哈希值计算，计算出的哈希值和我们在恢复发卡行公钥中获取到的哈希值一样，至此恢复发卡行公钥的步骤已完成，其中任何一步失败都会认为是静态数据认证失败。
第三步验证签名数据：用发卡行公钥来恢复签名的静态数据（过程与第二步雷同），恢复中有一部分是终端用来计算哈希值（将表5中的第二个到第五个数据元素（即从签名数据格式直到填充字节）从左到右连接，再把本规范第三册的第II部分中指明的需认证的静态数据加在后面。如果静态数据认证标签列表存在，并且其包含非‘82’的标签，那么静态数据认证失败），组织签名数据首先按照之前描述的sfi的规则获取脱机认证数据，还有个特别的地方，如果存在9F4A的话，需要将AIP作为签名数据,不需要包含tag和L，只要V就可以。最后对组织好的数据，进行sha1运算，获得hash值，然后和恢复签名数据时获取的哈希值比较，如果相等则SDA成功，然后将计算出的hash保存在9F45的标签中。SDA流程就算是结束了。
5.9F4A静态数据认证标签列表只存在在静态数据认证过程中吗？
不是，SDA和DDA中都存在这个要素。DDA中主要用这个来做发卡行公钥恢复和IC卡公钥恢复，所以这个标签的作用主要是用来组建一组静态数据用于脱机数据认证。切不要以为因为它的名字叫做“静态数据认证标签列表”而忽略了在DDA中的应用。
6.动态数据认证DDA是如何认证的？
首先需要恢复出发卡行公钥，这个和SDA的步骤一样，就不讨论了。
恢复出发卡行公钥后，DDA中还需要恢复IC卡公钥，这个步骤中，和恢复发卡行公钥类似，恢复出IC卡公钥以后也需要利用恢复后得到的数据再加上用于脱机数据认证的数据（SFI那边获得的）进行HASH值的计算，计算结果与恢复出的结果一致，则恢复出的IC卡公钥合法可用。
前面的内容SDA和DDA大同小异，没什么差别，但是DDA从恢复完IC卡公钥后和SDA就有很大区别了，下面我们一步一步讨论。
第一步，动态签名的生成
读记录的时候，需要一个关键数据DDOL（9F49），这个数据是卡片告诉终端（如果卡片没有返回，终端也需要有默认值，如果都没有则交易终止；如果DDOL中不含有9F37不可预知数，则交易终止）卡片需要终端的哪些数据来做动态签名。
终端组织好DDOL的数据之后，通过内部认证命令将数据提供给卡片，卡片会返回签名后的动态数据。卡片返回的数据时签名后的动态认证数据（tag为80时和tag为77时不一样的处理，与GPO是返回数据的处理类似），需要终端再利用IC卡公钥进行还原。还原后的数据中会有HASH。然后终端利用还原后得到的数据，再加上DDOL构成一个规范要求的数据串，然后在做SHA1运算获得HASH值，对比卡片返回的hash值和终端计算的是否一致，如果一致，证明DDA成功，再将HASH值保存到9F4C，则DDA已经结束了。
从分析来看，DDA其实是包含了SDA的过程，并且有了内部认证的处理，使得其安全性大于SDA，所以现在目前国内发行的卡基本上都是采用DDA作为脱机数据认证方式。
7.CDA认证
之前脱机数据认证，包括后面的GAC都忽略了CDA的存在，现在专门讨论一下CDA。
先从脱机数据认证开始，第一次遇到CDA。
CDA的前面三个步骤（获取ca公钥、恢复发卡行公钥、恢复IC卡公钥）和DDA一样，DDA是通过内部认证指令获取签名动态数据，CDA是通过GAC指令来获取的。
终端行为分析过程中正好有一次GAC，所以采用脱机数据认证的时候，前面只完成还原IC卡公钥就行了，CDA后续的部分放在终端行为分析GAC之后。
但是CDA的GAC和请求应用密文的GAC指令不一样，控制参数不一样，所以请求得到的结果也不一样。
CDA是用GAC指令请求，对于GAC指令请求，返回为格式2，也就是之前提到的77开头的格式，需要解析TLV，解析到9F4B签名动态应用数据。
这一步完成后，CDA比DDA多了一个步骤，终端首先将将恢复的密文数据和GAC返回的密文数据比较。
比较完成后终端需要将一些在GAC中返回的数据等一起组织起来，计算hash值，与恢复出的哈希值是否一致进行比较，如果一致则认为CDA到目前为止还是成功的。
然后还需要将GAC恢复数据得到的IC卡动态数据在进行处理，IC卡动态数据中也有一个hash值，还需要终端再按要求计算一个hash值，然后再和IC卡动态数据中的HASH值比较。
可以看得出是两层数据套在了一起，先解析外层，再解析内层，一层一层还原，最终
如果这个时候卡片返回的是TC，那么脱机交易就OK了，如果返回是ARQC的话，就发起联机。
联机过程忽略不谈，联机处理过程CDA和DDA一样，没什么区别。
如果联机失败，这个时候又要进行卡片行为分析。而且由于第一次GAC指令要求执行CDA，那么第二次GAC指令也要执行CDA。
对比CDA和DDA，可以看得出CDA复杂了很多，首先CDA将应用密文也加入到签名数据，其次CDA在响应GAC指令的时候对于密文的数有进行了一次加密封装，进而更加增强了安全性。
CDA的卡现在太少了，除了专业测试的，其他几乎没有银行发行CDA卡的，所以这块没有办法取到数据，只能通过代码和文档进行理解和分析。
8.动态数据认证有哪几种原因？
1.DDOL中不包含随机数（“9F37”）
2.在获取CA公钥，发卡行公钥，IC卡公钥任何一个公钥缺失都会导致失败。
3.CA公钥恢复发卡行公钥过程中恢复出的数据头尾格式和公钥格式和公钥指示符不合法。
4.恢复出的哈希值不等于计算出的哈希值。
5.发卡方ID号不等于PAN的前几位。
6.发卡行公钥证书过期
7.内部认证命令返回状态字不是“9000“。
8.签名动态应用数据和IC卡公钥模长度不一致
处理限制：
1.应用用途控制的作用即及判断
卡片会返回一个AUC（9F07），通过判断这个数据域来允许或者拒绝交易。
判断的逻辑也很清晰，比如一个pos终端，判断AUC的标志位给出ATM有效，除ATM外的终端无效，那POS终端肯定要拒绝这个交易了。或者就是根据终端的国家代码和卡片的国家代码是否一致来判断为国际交易还是国内交易。AUC的各个位又明确给出了国际交易和国内交易的允许情况，终端根据当前交易的状态，以及这些位来判断交易允许或者拒绝
2.应用日期有什么限制？应用过期怎么办？
应用生效日期要早与当前日期，应用失效日期要晚于当前日期。若应用过期，则在TVR中将相应位设置为‘1‘。
持卡人认证：
1.持卡人认证这块EMV和PBOC的区别
EMV流程和PBOC流程差别在于对于CVM的支持有差异，即EMV支持脱机密文PIN验证，不支持持卡人证件验证，而PBOC不支持脱机密文PIN验证，支持持卡人证件验证。
2.解释一下CVM，CVM对于验证是怎么处理的
一个CVM含2个主要元素：
(1)两个金额，X金额和Y金额。
(2)持卡人验证方法条目（可能含有多个）
a.持卡人验证方法，即第9字节的bit7，用来表明持卡人验证失败后的操作。
b..持卡人验证方法类型，即第9字节的bit6--bit1，用来表明采用什么样的方法做持卡人验证。
c.持卡人验证方法条件，即第10字节，用来表明在什么情况下做持卡人验证。
3.结合实例谈谈对cvm的理解
这是一个标准的cvm列表，X金额为0，Y金额为0，后续每两个字节表示一个持卡人验证方法条目，5E的二进制位01 011110这表明如果持卡人验证失败则使用后续的CVM，CVM验证方法为签名，03表示“如果终端支持这个CVM”。
这样估计还是比较抽象，我用语言再描述一下。
首先5E的bit8 bit7为01，这表明如果这个cvm失败，那就要用到后面的1F 00作为持卡人验证方法。
再看5E的bit6到bit1，这个规范上说的很明确，现在的6个数字就是代表使用签名。
再看03，03的含义是“如果终端支持这个CVM”，这个怎么理解呢？终端有一个很重要的数据，终端性能，终端性能中明确指出了终端所支持的验证方法，所以03的意思就是如果终端支持持卡人签名验证，那么这个交易就使用签名作为验证方法。当持卡人验证条件为03时，内核对于终端性能的判断也是直接影响持卡人验证成功与失败的关键要素。
后面的1F00就不做分析了，分析方法同理。
程序分析完CVM列表后，再根据分析结果提示持卡人进行操作，然后就相当于持卡人认证已经完成。
4.脱机PIN加密过程
(1) 终端把用户输入的明文PIN按照一定的格式补位对齐, 然后用get challenge命令从卡片中取一个8字节的随机数.
(2) 终端自己产生一组长度为N-17的随机数(N为PIN加密公钥的长度), 然后把补位后的PIN,卡片中取的随机数以及终端产生的随机数拼接在一起, 与PIN加密公钥做RSA运算.
(3)把上一步运算的结果通过verify命令发给IC卡.
(4) 卡片用PIN加密私钥解密数据, 首先检查解出来的8字节随机数是否与自己产生的一致，然后卡片检查恢复的数据头字节是否有效, 最后一步是验证PIN是否合法. 只有所有的条件都满足，脱机加密PIN才算成功.
终端风险管理：
1.为什么要进行最低限额检查？如何进行？
最低限额检查用于控制交易当前交易金额或同一张卡片连续几笔交易累积金额超过某个数值时则要求联机授权。
如果终端不支持交易日志，则终端直接比较授权金额和最低限额。如果交易授权金额大于或等于最低限额，终端将TVR中的“交易超过最低限额”位设为‘1’。即使最低限额为0，终端也进行同样检查，这种情况会导致所有交易的TVR中的“交易超过最低限额”位都设为‘1’。
如果终端支持交易日志，则终端在交易日志中寻找与当前交易的PAN和PAN序列号（如果终端交易日志和卡片中都存在）相同的一个交易记录，将其对应的累计交易金额与当前交易的授权金额相加，如果和大于或等于最低限额，则TVR中的“交易超过最低限额”位设为‘1’。
特别说明：终端风险管理，没有联机能力的终端可以不做后续的内容，直接跳过后面的步骤，进入终端行为分析。简而言之，电子现金交易，这一流程的后续两步可以直接跳过。
2.随机选中交易实例理解
终端风险管理参数示例
参数 值
终端最低限额 100 （AID参数下发）
终端随机数 25 （终端随机生成）
偏置随机选择的阈值 40 （AID参数下发）
随机选择目标百分比 20％ （AID参数下发）
偏置随机选择的最大目标百分比 50％（AID参数下发）
情形1：
交易金额是20。因为交易金额小于偏置随机选择阈值，因此执行随机选择。
比较终端随机数与目标百分数。因为随机数（25）大于目标百分数（20），所以交易不被选中作联机处理。
情形2：
交易金额是60。这个金额大于偏置随机选择的阈值，但小于终端最低限额。因此应用偏置随机选择。
交易金额比阈值高20，该差值是终端最低限额与阈值差值（100－40＝60）的1/3。因此将最大目标百分数与目标百分数的差值的1/3（50％－20％＝30％×1/3＝10％）加到目标百分数上，得到交易目标百分数为30％（20％＋10％＝30％）。
终端随机数为25，小于交易目标百分数（30），所以交易被选中进行联机处理。
情形3：
交易金额为150。因该金额大于终端最低限额，因此交易不进行随机选择。而是进行最低限额检查而联机处理。
3.频度检查执行条件
如果连续脱机交易次数下限LCOL(标签‘9F14’)与连续脱机交易次数上限UCOL(标签‘9F23’)都存在，则执行，否则不执行。
如果执行，终端需要先GET DATA获取9F36和9F13，然后再和UCOL和LCOL比较，判断满足交易频度检查条件。
如果获取到的9F13为0，则将该卡标志位新卡。新卡是不允许脱机交易的，IC卡cos会对这个有要求，主要是安全考虑，因为新卡做脱机交易不可控。
终端行为分析：
1.终端行为分析需要用到哪些重要数据？
发卡行行为代码（IAC） 发卡行行为代码，来自读记录文件卡片返回
发卡行行为代码有三个数据元，即发卡行行为代码-拒绝、发卡行行为代码-联机、发卡行行为代码-缺省。每个发卡行行为代码由一组与终端验证结果（TVR）中的位相对应的位
组成
IAC－拒绝位设置为“1”反映了交易被脱机拒绝的终端验证结果条件
IAC－联机位设置为“1”代表需要联机授权条件
IAC－缺省位设置为“1”是当联机处理不可行时脱机拒绝所需的条件
终端行为代码(TAC) TAC有三个数据元，它们都是由一系列的位组成的，这些位对应于TVR中的数据位。终端行为代码来自emv参数下载交易。
TAC－拒绝 收单行设置的能够导致交易脱机拒绝的TVR条件位
TAC－联机 收单行设置的能够导致交易联机的TVR条件位
TAC－缺省 收单行设置的在交易联机无法进行的情况下能够导致脱机拒绝的TVR条件位
这6个代码的查看方法和TVR查看方式一样，使用时也是配合TVR进行使用。
2.终端是如何判断其行为的？
检查过程完全由终端利用先前从卡片获取的IAC数据和终端保存的TAC数据进行，无需与其它设备进行交互处理。
在处理过程中，终端比较IAC和TAC中与终端验证结果（TVR）对应的位。如果TVR和IAC或TAC中相应的位都被设置为“1”，则采纳对应的IAC或TAC。示例如下：
终端的处理步骤如下：
步骤 1：终端比较 IAC－拒绝和 TVR。如果不存在 IAC－拒绝，则采用缺省值‘0000000000’。如果IAC－拒绝和 TVR 的任何对应位同时设为‘1’，终端必须：
—— 把授权响应码置为‘Z1’(脱机拒绝)；
—— 把 GENERATE AC（产生应用密文）命令的 P1参数设为请求应用认证密文（AAC）；
—— 进行请求应用密文步骤。
步骤 2：终端对 TAC－拒绝和 TVR进行类似的比较。如果不存在 TAC－拒绝，则采用缺省值‘0000000000’。如果 TAC－拒绝和 TVR的任何对应位同时设为‘1’，终端必须采取与 IAC－拒绝相同的处理。
步骤 3：如果终端具有联机处理能力（仅联机的终端除外），则它应该使用 IAC－联机和TAC－联机与TVR比较。如果 IAC－联机不存在，则使用缺省值‘FFFFFFFFFF’，如果 TAC－联机不存在，则使用缺省值‘0000000000’。如果 IAC－联机和 TVR的任何对应位同时置为‘1’，则终端：
—— 把产生应用密文（GENERATE AC）命令的 P1参数设为授权请求密文（ARQC），以进行联机授权请求；
—— 进行生成应用密文步骤。
对于仅联机的终端，如果在步骤 1和步骤 2中未决定脱机拒绝，则终端不必进行 IAC－联机和 TAC－联机与 TVR的比较，而直接按照 IAC－联机或 TAC－联机和 TVR的任何对应位同时置为‘1’的情况来处理，通过请求联机来继续进行交易。
步骤 4：如果终端是仅脱机终端或者当有联机处理能力的终端出于某种原因不能联机时，则使用 IAC——缺省和 TAC——缺省与 TVR 比较。如果没有 IAC－缺省，则使用缺省值‘FFFFFFFFFF’，如果 TAC——缺省不存在，则使用缺省值‘0000000000’。如果比较结果的任何对应位同时为‘1’，则终端：
—— 把授权响应码置为‘Z3’（不能联机，脱机拒绝），仅脱机终端授权响应码置为‘Z1’；
—— 把产生应用密文（GENERATE AC）命令的的 P1参数设置为请求 AAC；
—— 进行生成应用密文步骤。
对于仅联机的终端，当无法进行联机时，它可以选择正常的处理TAC/IAC－缺省，也可以选择跳过TAC/IAC——缺省的处理。对于跳过TAC/IAC——缺省处理的终端应该直接按照TAC/IAC——缺省与TVR匹配进行处理，并且在第2个GENERATE AC请求AAC。对于正常处理TAC/IAC——缺省的终端，应该根据TAC/IAC——缺省与TVR匹配的结果生成应用密文，这时仅联机的终端可能脱机完成交易。
步骤 5：如果在以上的比较中没有出现对应位同时为‘1’的情况，则终端：
—— 把授权响应码置为‘Y1’（脱机批准）；
—— 把 GENERATE AC（请求应用密文）命令的 P1参数设置为请求交易证书（TC）；
—— 进行请求应用密文步骤。
这里的GENERATE AC就是我们所说的第一次GAC，如果脱机批准了，获取到的TC值需要在上送交易明细时上送到后台。如果卡片返回ARQC，那么在联机交易结束后，还需要再做第二次GAC，这个内容后续再讨论。
联机处理&&交易结束
1.联机交易处理流程
第一步：
处理ARPC（如果不包含，则跳过；如果包含并且AIP特性标志不支持发卡行认证，则跳过）
收到联机返回报文后，获取tag“91”，即ARPC，通过外部认证指令将ARPC发给卡片，如果卡片响应9000，说明ARPC校验通过，否则发起冲正。
第二步：
处理发卡行脚本
再看tag72（或71，在圈存交易时，不允许出现两个脚本），这个是发卡行返回脚本采用tag72作为标签，72后面还是一个TLV，解析tag86（发卡行脚本命令），获取到。再通过指令将这个命令给到卡片，整个数据就是一个指令，不需要再添加内容
第三步：
第二次GAC，第一次GAC发送GAC指令时组织数据采用的是CDOL1，第二次GAC组织命令时用的是CDOL2，CDOL2也是在读记录时候获取到的。
2.假如卡片请求ARQC。但终端执行联机交易失败怎么办？
卡片请求ARQC，但是终端无法联机，并不是代表这个交易终止了，终端和卡片还有最后一次尝试，就是所谓的脱机转联机，联机失败再转脱机。
这就好像买东西一样，先去第一家店看了看，觉得东西还行，但是先不买，然后再去第二家店，结果发现第二家店的东西又贵又不好，那再回去第一家店看看，价格能不能商量一下，如果能谈妥，OK，那么就交易。
这个时候首先又需要检查IAC-缺省和TAC缺省执行终端行为分析（这部分在之前终端行为分析中有表详细的描述），并且根绝结果发送第二次GAC指令。
如果第二次GAC指令能够成功返回TC，那么脱机交易批准，如果返回ACC，则交易拒绝，，这个时候不可能再返回ARQC了。
如果脱机成功则响应码为Y3，但是，如果终端在第一次GAC就获取TC批准脱机交易的话，响应码是Y1，所以通过Y1和Y3就可以知道是哪一种脱机批准。
到此为止，整个借贷记交易和电子现金的交易就已经全部处理完了。
QPBOC和借记贷记对比
1.QPBOC和EMV在PDOL中有什么区别？
非接中的GPO对于PDOL的要求是必须含有9F66（借贷记的GPO是可以支持没有PDOL的，终端在GPO只要发送8300就行），如果没有，终端直接拒绝交易。
2.QPBOC的持卡人认证
QPBOC的持卡人认证和借贷记电子现金不同，QPBOC的持卡人认证结果只有2种情况：签名，联机。通过判断卡片交易属性（9F6C）和终端交易属性（9F66）来判断采用哪种持卡人验证方式。
3.QPBOC的处理限制与借贷记流程的有什么区别？
QPBOC的处理限制只做一件事，就是判断卡有效期，相当于借贷记流程中的一个小步骤。
4.QPBOC的脱机数据认证与借贷记流程的有什么区别？
因为卡片不会再和终端有指令交互，所以数据认证使用的QPBOC自己定义的一种FDDA。FDDA的执行同样需要根据AIP的情况作出判断。FDDA签名的动态数据通过9F4B在读记录时返回，借贷记是通过内部认证获取到的。这个动态数据的获得，也是区分FDDA版本为01还是00.所以缺少了DDA的内部认证指令，所以叫做FDDA。而用来参于组织签名数据的是通过一个固定数据域组织的，借贷记是通过DDOL获取的。
特别说明:PB0C3.新增了一个9F69的标签，需要在版本01的FDDA中加入到签名数据域。
交易限额
终端最低限额（9F1B）、终端电子现金交易限额（9F7B）、非解最低限额（DF19）、非解交易限额（DF20）、CVM限额（DF21）
9F1B，就是所谓的Floorlimt，这个参数主要用在终端风险管理终端中的第一个步骤-------最低限额检查。
9F7B，当交易金额小于9F7B的时候，终端可以执行电子现金脱机交易。
特别说明：我一直觉得这个限额只应该对接触式电子现金交易有效，但是现在不管是客户还是同事，很多人都认为这个限额应该对Qpboc也要做判断。虽然目前代码是这么做的，但是我还是觉得这个限额应该只是对电子现金有效。
DF19、DF20、DF21三个TAG值都是连续的限额，就是针对于QPBOC的三个限额，这三个限额主要是在QPBOC预处理阶段进行判断。
DF19，交易金额必须大于DF19，才允许做非解交易。
DF20，交易金额不能大于DF20，否则交易拒绝，提示持卡人采用别的方式交易。
DF21，超过该限额，终端应该在交易属性9F66中置位“要求CVM”，进而在GPO的时候告诉卡片终端需要CVM。但是这个值实际有什么意义也不清楚。Q的持卡人验证只有签名和联机两种方式，卡片返回的9F6C再加上终端交易属性已经可以决定持卡人验证方式了。CVM在这个时候确实没啥用了。
还有一个额度不得不提，就是卡片余额，当交易金额大于卡片余额，但是不满足上面任何一种拒绝交易的情况时，终端会选择脱机转联机交易。
当然了，如果交易金额没有超过卡片余额，但是却大于上述的DF20，终端就直接拒绝交易。