PBOC/EMV之电子现金应用

文章出处：http://www.nexussmartsolutions.com 作者： 人气： 发表时间：2012年03月11日

    最近在做一个基于PBOC电子现金卡的终端应用, 项目还没有完成, 但电子现金部分的处理模块已完成，剩下的基本是UI和调试的事情了. 想把对PBOC电子现金理解整理成一篇文章.

    电子现金的概念是在PBOC规范的第十三部分<<基于借记/贷记应用的小额支付规范 >>里提出的。 可以这样理解，电子现金是PBOC里的一个应用,它基于借贷记. 这个应用被提出的目的就是实现我们经常听说的一个功能, 小额支付功能.

    基于电子现金的卡目前来讲，一般有如下几个特点:

    1 是由银行发行, 这个是必须的,否则就不会叫金融IC卡了.

    2 卡里只有一个应用，也就是一个AID，因为目前国内推行PBOC的卡都是先从单应用开始做试点. 从卡片的角度来讲，实现多应用不成问题，但是, 如果卡片支持多应用, 还需要终端(包括圈存终端和消费终端)以及银行后台的相应配合, 这部分的工程量就很大了, 所以暂时以单应用为主.

    3 一般用这张卡做小额支付,并且非实名制，消费无需密码，且是脱机消费.

    4 这种卡一般只在银行内部或企业内部使用(企业内部也是与银行合作), 目前很难推广到一些大的公共事业中(比如交通), 因为这些行业是国家建设部管的, 这里面有很多非技术的原因导致银行这种金融机构与建设部难以坐在一起协商.

    电子现金的应用, 主要做两种类型的交易，一是圈存交易，一是消费交易. 我这里以终端圈存交易为例，简单描述一下PBOC的交易流程.

    所谓电子现金圈存, 是指把用户在银行帐户里的钱转到这张电子现金的卡上. 说白了就是从你的银行卡上转钱到电子现金的IC卡上. 由于目前还没有实现PBOC卡的多应用，整个圈存过程实际上需要两张卡，终端先读取银行卡信息(包括卡号，密码以及充值金额等信息), 扣费成功后下一步才是走PBOC交易流程，对电子现金卡写卡. 而推广PBOC的终极目标就是实现一卡多应用, 也就是说，未来的某个时候，就可以用一张卡完成圈存,只是不同的应用.

    我这里简单通俗的介绍一下电子现金充值PBOC的流程. 更详细的内容可以直接看PBOC 2.0规范.

    前面说到，电子现金应用是基于借贷记的, 所以它兼容借贷记应用，可以说是精简版的借贷记应用. 每一笔交易，所执行的PBOC流程就是简化版的借贷记流程.

    第一步, 选择应用, 所用命令是select, 传的参数是 应用AID号. 这里跟标准的PBOC交易流程并不一样, 因为标准流程里面, 前面还有两步, 就是读取支付系统目录, 建立应用列表.为什么可以省掉这两步, 因为前面说到，卡里一般只有一个应用AID，目前还没有实现多应用, 这个AID号应该在卡片个人化时就已经固定好，只要你知道了该AID号，直接跳过前两步选择该应用可以了. 卡里只有一个应用，就无所谓应用列表了. 当然，一个好的程序设计建议还是走标准流程，这样，以后卡片实现了多应用, 你的终端程序也可以通吃.

    应用选择后，卡片返回一串信息, 这串信息里面有个很重要的数据叫PDOL, 这是一个列表，卡片通过这个列表告诉终端，它需要哪些数据, 这些数据用来给卡片做应用初始化. 举个列子，比如卡片可能会需要授权金额(就是圈存的金额), 货币代码等数据. 终端程序解析PDOL，按照一定的规则拼接数据,进入第二步.

    第二步, 应用初始化. 命令是GPO, 参数就是前一步根据PDOL所组的数据包. 该步表示终端通知卡片交易开始了. 卡片会返回AIP和AFL两个数据. AIP告诉终端卡片支持的功能, 比如卡片是否支持脱机数据认证, 是否支持发卡行认证等. AFL是要告诉终端, 如果要完成这笔交易，你终端该从卡上读什么数据。AFL里就包含了这些数据的位置和名称. 举个例子，这些数据可能有当前的交易序号，该张卡片的卡号(PBOC里叫PAN,应用主帐号)等.

    第三步，读数据. 命令是read record. 参数是前一步得到的终端所需卡片数据的位置和名称. 终端要把AFL指定的所有数据读出，并保存到终端供下面的流程所用. 每次读到的数据是包含在卡片的返回信息中的, 终端解析返回信息，提取相关的数据.

    第四步, 产生应用密文. 命令是GAC. 参数是密文类型和产生密文所需的数据. 密文类型有三种，分别是交易证书(TC), 应用认证密文(AAC),授权请求密文(ARQC). 因为这一步是为下一步联机处理做准备，所以终端应用请求卡片产生的密文类型应该是ARQC，查看卡片是否允许联机处理. 卡片收到产生密文类型后，返回的信息有两个重要的数据, 第一个就是密文类型，该数据指示卡片是否愿意做联机处理，如果愿意，返回的是ARQC，与终端一致，否则返回AAC，表示拒绝联机. 终端判断卡片返回的是否是ARQC，如果是，终端要读取卡片返回的另一个重要的数据，应用密文(AC), 该密文是卡片用存放在卡里的密钥，对终端发过来的明文数据，用3DES算法生成的.

    第五步, 联机验证卡片. 这一步，卡片本身没有操作. 终端把前一步得到的应用密文，产生应用密文的一些数据，还有其它的信息(比如交易日期，交易时间等),打包发送到发卡行PBOC后台, 通信方式一般是用TCP/IP。 后台通过验证ARQC密文来认证卡片, 如果认证成功会返回授权响应密文(ARPC), 这个ARPC是后台通过3DES算法，对ARQC密文和二个字节的授权响应码加密生成的.

    第六步，第五步的目的是发卡行验证卡片的合法的性，这一步是卡片验证发卡行是否是一个有效的发卡行. 命令是External Authentication, 叫外部认证. 参数是上一步联机处理响应的ARPC和授权响应码. 卡片收到命令后，会用自己的密钥，对ARQC和授权响应码生成ARPC，然后与终端传来的ARPC比较，两都相同，就认为此ARPC是来自一个有效的发卡行后台.

    第七步, 联机圈存报文, 验证了卡片和发卡行的合法性之后，终端向发卡行后台请求圈存，上传的数据包括充值金额，卡内原来的余额等信息, 发卡行后台返回一个写卡的脚本命令, 终端解析这个脚本，直接发给卡片即可. 到这里，卡片充值成功.

    第八步，这一步要发送第二请求密文命令(GAC2), 它的作用说白了就是告诉卡片交易结束。与第四步的GAC1不同的是，GAC2的参数里面多了授权响应码，并且请求的密文类型是TC,也就是希望卡片接受交易。如果卡片返回的也是TC，表示接受交易.

    第九步, 读交易日志，在整个流程执行的过程中，卡片会以一定的格式读录当前这笔交易的信息，比如授权金额，卡号，交易时间，终端只需通过一个命令就可以把些信息读出，然后提取出有用的信息，以便日后结算.