转载请注明出处

作者:小旭

前面终端执行完终端行为分析后，如果在GAC1的时候，卡片返回ARQC，那么终端就需要进行联机交易流程的处理，这一部分我们主要讨论一下联机交易的处理过程。

在终端获取到卡片返回ARQC后，终端先发起8583报文请求，然后接收到后台返回的报文，提取相关的IC卡数据域。

插个例子，看看某个发卡行返回的55域

91 0A E3 44 EE 82 E0 0C A8 76 30 30 72 12 
86 10 04 DA 9F 79 0A 00 00 00 02 00 00 B3 
AB A7 E8 00 

第一步：

处理ARPC（如果不包含，则跳过；如果包含并且AIP特性标志不支持发卡行认证，则跳过）

收到联机返回报文后，获取tag“91”，即ARPC，通过外部认证指令将ARPC发给卡片，如果卡片响应9000，说明ARPC校验通过，否则发起冲正。

第二步：

处理发卡行脚本

再看tag72（或71，在圈存交易时，不允许出现两个脚本），这个是发卡行返回脚本采用tag72作为标签，72后面还是一个TLV，解析tag86（发卡行脚本命令），获取到

04 DA 9F 79 0A 00 00 00 02 00 00 B3 AB A7 E8 00

再通过指令将这个命令给到卡片，整个数据就是一个指令，不需要再添加内容，实际操作如下：

send:15
04 DA 9F 79 0A 00 00 00 02 00 00 B3 AB A7 E8 
rec:3
90 00 

终端并不关心这个脚本命令是要做什么，终端也确实不知道这个脚本命令要干啥，终端的任务就是发脚本给卡片，剩下的内容就有卡片自己处理。

第三步：

第二次GAC，第一次GAC发送GAC指令时组织数据采用的是CDOL1，第二次GAC组织命令时用的是CDOL2，CDOL2也是在读记录时候获取到的。

 

Send:40
80 AE 40 00 22 30 30 00 00 00 00 01 00 30 30 30 
30 30 30 01 56 00 00 04 00 00 01 56 11 03 30 00 
1C 22 24 13 11 41 45 00 

REC:35
80 1E 40 06 A0 8B 35 9C A6 4B CC 4F 06 07 02 
01 03 60 00 02 01 0A 01 00 00 00 07 00 A1 38 E4 
BB 90 00 

这里发送的命令第三个字节为40（01000000），明显这个第二次GAC，终端请求的是TC。

上述例子卡片也是成功返回了TC，卡片成功返回TC后交易结束。

前面所讨论的依然还是不考虑存在CDA的情况，CDA情况比较复杂，先规避一下，完了再专门以一篇研究一下。

 

上述是一个标准的联机交易的流程，但是还有一个情况，假如卡片返回ARQC，但是终端执行联机交易失败。

下面主要研究一下这种情况。

卡片请求ARQC，但是终端无法联机，并不是代表这个交易终止了，终端和卡片还有最后一次尝试，就是所谓的脱机转联机，联机失败再转脱机。

这就好像买东西一样，先去第一家店看了看，觉得东西还行，但是先不买，然后再去第二家店，结果发现第二家店的东西又贵又不好，那再回去第一家店看看，价格能不能商量一下，如果能谈妥，OK，那么就交易。

这个时候首先又需要检查IAC-缺省和TAC缺省执行终端行为分析（这部分在之前终端行为分析中有表详细的描述），并且根绝结果发送第二次GAC指令。

如果第二次GAC指令能够成功返回TC，那么脱机交易批准，如果返回ACC，则交易拒绝，，这个时候不可能再返回ARQC了。

如果脱机成功则响应码为Y3，但是，如果终端在第一次GAC就获取TC批准脱机交易的话，响应码是Y1，所以通过Y1和Y3就可以知道是哪一种脱机批准。

到此为止，整个借贷记交易和电子现金的交易就已经全部处理完了。

 

阅读更多

更多精彩内容