电子钱包:EP

电子现金:EC,在PBOC规范中的13部分定义了《基于借贷记应用的小额支付规范中》

QPBOC:在PBOC规范的12部分中定义了《费接触式IC卡支付规范》

PBOC1.0中只定义了电子钱包(EP)和电子存在(ED)应用

而PBOC2.0中增加了借贷记应用,以及基于借贷记应用的电子现金(EC)和QPBOC.

自从PBOC2.0发布后,相对于原来只定义了电子钱包和电子存折应用的PBOC1.0而言,增加了借贷记应用,以及基于借贷记应用的电子现金和qPBOC。而且随着芯片卡在小额支付领域的优先试点使用,使得“电子钱包”、“电子现金”、“小额支付”、“非接小额”、“qPBOC”、 “闪付”、“QuickPass”、“UPCash”……等各种名词概念充斥芯片卡支付应用领域,多数情况下,厂商和客户之间、持卡人和发卡机构之间都在用自己的定义进行彼此之间的交流,常常出现鸡同鸭讲的情形,沟通难度有时超乎想象。

一、关于电子钱包
PBOC电子钱包应用脱胎于EMV96,钱包的金额存储在卡片里,支持圈存、圈提和消费交易,在上述三种交易过程中钱包的余额同步变化。在圈存(充值)或者圈提的时候按照规范要求需要联机,而在进行脱机消费时,是通过卡片、POS终端、PSAM之间的一系列数据交互实现的,消费交易的密钥存储在PSAM里(消费密钥存储在PSAM卡里)。每笔交易都会记录交易明细并且卡片至少会保存最近十笔的交易日志,如果卡片在交易过程中脱离POS终端造成交易中断,可以通过获取卡片交易凭证的方式来检查上次交易是否完成,从而保证每一笔交易的完整。
电子钱包的交易过程依靠各种不同的应用密钥(很多密钥,比如圈存,圈提,消费都有密钥),通过对称算法来保证交易的安全性。所以严格来讲无论是圈存、圈提、消费,只要终端在和卡片进行数据交互的过程中能够使用正确的密钥计算出正确的验证数据(MAC),那么交易都可以完成,因此并没有一个强制的限定说哪种交易必须联机或者脱机。如果在POS的PSAM中装载了圈存和圈提的密钥,那么也可以实现脱机的圈存和圈提;同样如果后台系统配置了消费密钥,也可以实现联机消费。卡片本身始终处于被动状态,无论是联机和脱机卡片都一视同仁,不会主动发起任何联机请求。
电子钱包也可以实现一卡支持多个金融应用,但是所谓的多应用仅仅是叠加了多个钱包而已,每个钱包的功能完全雷同。

卡片本身对于交易金额没有限制,只要钱包里有足够的余额,就可以完成消费;同样充值的时候,只要钱包余额字段不溢出就可以任意充值不受限制(当然发卡方可以在系统中进行限制设定,但是这些限制不在规范约定的范围内)。
电子钱包交易的命令简单而固定,通常只有两个步骤:初始化交易和完成交易

电子钱包的金额存储在卡片里,支持三个功能:圈存,圈提和消费,并且在交易过程中钱包中的余额同步变化。在圈存(重置)和圈提(取现)时需要联机,在消费时可以脱机。

二、关于借贷记应用
之所以要先说一下借贷记应用,是因为电子现金和qPBOC都是依托于借贷记的(电子现金(EC)和QPBOC都是基于借贷记的,建立在借贷记的基础上),它们不能脱离借贷记应用而独立存在。
PBOC借贷记应用脱胎于EMV2000,通过PKI数字证书的形式,利用‘公私钥对’实现的非对称算法(QPBOC采用的非对称加密算法,因为这是借贷记采用的加密算法),采取静态数据认证(SDA)和动态数据认证(DDA),依据卡片和终端不同的参数配置,实现卡片在POS终端上的脱机消费、联机消费和ATM终端上的取现交易。其中静态数据认证可以确保卡片上的数据没有被篡改,但不能保证卡片的真伪;而动态数据认证可以判断卡片的真伪。对于仅做静态数据认证的卡片不需要支持RSA算法,做动态数据认证的卡片则要支持RSA算法。借贷记应用中不再使用PSAM卡作为POS端安全认证的实现手段。

(QPBOC中静态数据认证保证卡片上的数据不被篡改,但不能识别卡片的真伪,而动态数据认证则要支持RSA算法,因此可以保证卡片的真伪性。)

借贷记交易的安全性依靠卡片和终端不同的脱机处理参数配置来实现,比如单笔脱机交易限额,累计脱机交易限额,累计脱机交易次数,上次交易成功或者失败的标记、持卡人凭借签名或者密码,强制联机触发条件等。卡片和终端要根据这些参数进行不同的风险管理和行为分析。
借贷记交易在初始化交易之后没有一个固定的流程,而是根据不同的卡片配置选项,走不同的交易路径,有太多的参数需要判断,有太多的跳转可能性。这点完全不同于电子钱包交易过程的简单明了,对于原来熟悉电子钱包的人员来说,一时可能转不过弯来,初看借贷记应用规范一定会感到茫然无措。(可见借贷记交易要比电子钱包交易流程更复杂多变

在联机交易过程中,发卡行可能会向卡片发送一些脚本命令,进行参数的调整和修改卡片的状态。比如更改累计脱机交易限额等脱机处理参数,锁定应用或者卡片,修改PIN等。发卡行可以根据不同持卡人的具体情况时时灵活地调整脱机处理参数,这点在标准的电子钱包交易流程中是不可能实现的。(借贷记可以通过向卡片发送脚本进行灵活的调整参数
借贷记应用也会在卡片中保存不少于十笔的最近交易日志,但是在卡片上没有终端可以读取的交易凭证。所以在交易过程中如果卡片脱离终端会出现终端认为交易未完成而卡片交易处理实际已完成的差错,电子现金和qPBOC同样继承了这个问题(因为他两都是基于借贷记的应用)。虽然可以把卡片上保存的交易日志作为判断依据,但是并不严谨,况且对于qPBOC而言还没有交易日志。

借贷记的卡片上没有余额的概念(借贷记卡没有余额的概念?),虽然单笔脱机交易限额以及累计脱机交易限额和钱包余额的概念有些类似。但是即使交易金额超过了这些限额,仍然可以通过卡片主动申请联机的方式完成交易(当然需要后台主帐户有足够的余额),而不会出现像电子钱包那样因为余额不足造成的交易失败(电子钱包因为是脱机消费交易,因此如果余额不足,则会造成交易失败)。后台主帐户中有余额的概念,这个余额可能是借记卡中的预存金额,也可能是贷记卡中的可用信用额度。
如果把借贷记应用做成多金融应用卡,那么这些金融应用之间可以通过不同的参数配置而变得五彩缤纷,而不是像电子钱包那样的简单叠加。比如可以配置成:仅支持联机消费的借记卡应用,仅支持联机取现的ATM卡应用,既支持联机也支持脱机的贷记卡应用等。另外借贷记应用本身还支持不同币种,这也是电子钱包应用不具备的。

通常借记卡是不支持脱机交易的(标准的借记卡是不支持脱机交易的),但是可以冻结一部分资金用于脱机交易(借记卡冻结一小部分钱),同样也可以在贷记卡帐户(信用卡中预付一部分钱)中通过预付或者预授权的方式划出一部分资金用于简化风险管理的脱机交易(把这部分的冻结的钱或者信用卡中预付的一小部分钱,用于简化风险管理的脱机交易,这就是小额的(一小部分钱)脱机(不需要联机)的电子现金),于是就派生出了适用于小额脱机交易的电子现金;另外为了加快在非接触交易场景中的交易速度(Q的意思就是快速,在非接的场景下应用自然速度才会快),在借贷记应用的基础上进行改进又派生出了qPBOC。

三、关于电子现金和UPCash

PBOC规范中关于电子现金(EC)的概念在第十三部分《基于借贷记应用的小额支付规范》中进行了定义。该应用从持卡人角度看类似于电子钱包,也是一种可以用于脱机交易的小额支付应用。

在原来借贷记应用的基础上增加了电子现金余额电子现金余额上限电子现金单笔交易限额电子现金重置阈值等数据元来完成小额的电子现金脱机支付交易。电子现金的交易流程和借贷记应用类似(电子现金的交易流程和借贷记交易差不多),并且在后台有一个专门的小额支付帐户来支持电子现金脱机消费交易(有专门的后台账户来支持电子现金的脱机交易)。在卡片初始化之后,后台的电子现金帐户余额和卡片上的电子现金余额是一致的(一开始后台的电子现金账户余额和卡片上的电子现金余额是一样的)。但是在完成脱机消费交易后,只有把该笔交易和后台电子现金帐户进行清算才能使后台电子现金帐户余额和卡片电子现金余额重新保持一致,所以卡片的电子现金余额和后台电子现金帐户的余额存在一个数据不一致的时间窗
发卡商还可以通过电子现金重置阈值实现对余额不足的卡片通过主帐户进行自动充值,当然持卡人也可以使用现金充值,充值后的电子现金余额不能超过电子现金余额上限。这些充值的交易需要通过标准的借贷记应用流程,利用发卡行脚本的方式来实现。

电子现金交易和标准借贷记一样也要记录交易日志

UPCash是银联定义的用于脱机小额支付的IC卡交易,实际上对于小额支付的电子现金和电子钱包交易都可以称作是UPCash。

四、关于qPBOC和闪付

qPBOC是在PBOC规范的第十二部分《非接触式IC卡支付规范》(包括三部分的内容)中进行描述的,实际上这部分规范除了描述qPBOC之外还描述了基于非接触界面的PBOC标准借贷记应用,以及通过非接触界面利用磁条数据信息实现交易的MSD。并且约定了如何根据卡片和终端对这三种应用模式的支持情况进行具体的应用选择。对于纯非接触卡而言标准的PBOC借贷记应用是必选的,也就是说这三种应用需要同时存在;对于双界面卡而言可以不支持非接触的标准借贷记应用,但是需要在在接触界面中支持。

qPBOC中的脱机处理参数结合了针对标准借贷记的累积脱机交易限额以及针对小额支付的电子现金余额,根据脱机处理参数的配置情况,在每次脱机交易时可以选择检查小额、检查小额和累积脱机限额、检查小额或累计脱机限额的不同组合。但是在交易流程处理加密算法实现认证数据选择方面,qPBOC和标准借贷记应用以及基于标准借贷记的小额支付电子现金应用存在很大差异,主要是进行了流程的简化以便加快非接触界面的交易处理速度(QPBOC自然要简化交易流程以提高非接触界面的交易速度)。所以可以概括地说qPBOC是在非接触界面下优化改进了交易速度的PBOC借贷记应用与电子现金小额支付应用的结合体

根据规范qPBOC一定是在非接触界面下进行的,在接触界面下不应该走qPBOC交易通道。(QPBOC一定是在非接场景下的,因为在接触界面下不走QPBOC通道
因为在接触界面下体现不了QPBOC的快速效果
“闪付QuickPass”是银联为PBOC2.0非接触支付定义的一个品牌,从银联网站给出的定义看并没有限定这个非接触支付究竟是什么应用,所以按照目前的定义在非接触界面下实现的标准借贷记、qPBOC、MSD,甚至非接触的电子钱包应用都可以被称作“闪付QuickPass”。

五、应用场景示例

对于像公交、地铁、ETC这样的公共交通领域,目前普遍采用的是非接触的电子钱包,因为需要分段计费(分段计费的场景大多使用了电子钱包应用),大多使用了电子钱包复合交易的扩展应用功能。部分银行和一些城市通卡公司合作联合发卡,卡片的芯片中则既有电子钱包应用,也有标准的借贷记或者qPBOC应用。

对于一次性的储值卡和预付费卡应用,可以采取仅支持电子现金交易的接触卡或者仅支持qPBOC小额交易的非接触卡。对于可以循环充值的储值卡或者预付费卡,可以采用接触式标准借贷记+小额电子现金应用,或者接触式标准借贷记+非接触qPBOC的双界面卡,或者非接触标准借贷记+qPBOC的纯非接触卡。

对于多帐户或者多附属卡的情形,可以采取标准借贷记的主卡+支持电子现金或者qPBOC应用的附属卡形式,使附属卡的后台电子现金帐户与主卡的主帐户进行关联。

对于一卡多金融应用而言,各种借记、贷记、电子现金、qPBOC等应用都可以集中整合在一起,不同帐户之间的转账、充值、还款都可以自由约定。(一卡中有多种应用的场景,各账户之间可以灵活转账,充值,还款

PBOC电子钱包与电子现金及QPBOC的更多相关文章

  1. 电子现金、电子钱包、qPBOC、闪付、UPCash

    一.关于金融IC卡领域的规范 由Europay.Mastercard.Visa三大国际信用卡组织联合制定的金融集成电路(IC)卡金融支付标准,称为EMV规范,其目的是为金融IC卡.金融终端.支付系统以 ...

  2. PBOC协议中对于所有电子存折/电子钱包应用的预处理

    下图给出了PBOC协议中规定的对电子存折/电子钱包应用的所有交易类型共有的预处理流程 图1 1.1 插入卡片 终端应具有检测IC卡是否已经插入读卡器的功能.如果IC卡已经插入,终端将继续执行1.2的应 ...

  3. 基于PBOC电子钱包的圈存过程详解

    基于pboc的电子钱包的圈存过程,供智能卡行业的开发人员参考 一. 圈存 首先终端和卡片有一个共同的密钥叫做圈存密钥:LoadKey   (Load即圈存的意思,unLoad,是圈提的意思) 假设Lo ...

  4. 基于PBOC电子钱包的消费过程详解

    智能卡金融行业应用电子钱包的消费交易流程,开发人员可参考 首先终端和卡片有一个共同的密钥叫做消费密钥:PurchKey (针对每种特定的交易,比如,圈存,消费,都有特定的密钥与之对应) 假设Purch ...

  5. PBOC2.0协议中电子存折/电子钱包中圈存交易流程

    通过圈存交易,持卡人可将其在银行相应账户上的资金划入电子存折或电子钱包中.这种交易必须在金融终端上联机进行并要求提交个人识别码(PIN)(无论电子存折还是电子钱包应用). 交易流程图如下: 1.1 发 ...

  6. 与电子钱包相关的APDU指令

    CLS:命令报文的类别字节,class byte(类别字节) of command message(命令报文) UranusPay ED/EP: UranusPay是HB公司开发的COS,而ED是电子 ...

  7. [Apple开发者帐户帮助]六、配置应用服务(6)创建电子钱包标识符和证书

    电子钱包提供称为通行证的信息的数字表示- 例如优惠券,演出门票或登机牌 - 允许用户兑换真实世界的产品或服务.您可以通过多种方式使用电子钱包: 选项1:请求,分发和更新通行证 首先注册通行证类型标识符 ...

  8. PBOC~PPT-补充A(转)

    qPBOC简介PBOC 3.0非接交易包括:非接PBOC和qPBOC.非接PBOC流程与接触式无异,仅命令交互方式改变,故不再赘述. qPBOC - 快速借记/贷记,交易特点:目录选择PPSE使用“2 ...

  9. PBOC

    http://blog.sina.com.cn/s/blog_64cc82620100rcgu.html 最近在做一个基于PBOC电子现金卡的终端应用, 项目还没有完成, 但电子现金部分的处理模块已完 ...

随机推荐

  1. Completely change MACE timestamps?

    Hi, One of my friends Sandy asked me about the possibility of completely change MACE timestamps. As ...

  2. MyBatis学习系列二——增删改查

    目录 MyBatis学习系列一之环境搭建 MyBatis学习系列二——增删改查 MyBatis学习系列三——结合Spring 数据库的经典操作:增删改查. 在这一章我们主要说明一下简单的查询和增删改, ...

  3. 1.2Android系统移植的主要工作

    1.Android移植分为两部分:应用移植和系统移植: 2.应用移植:指将第四层的应用程序一直到某一特定硬件平台上. (1)为保证应用程序能在新的平台上正常运行,需要对源代码就行一些修改,因为硬件平台 ...

  4. Mir2源码详解之服务端-选择(角色)网关(SelGate)

    其实,SelGate也就是 LoginGate,其源码实现完全相同.不必怀疑,市面上的都是这么做~!这里单独写这篇文章,就是为了说明这点!

  5. MVC5使用SignalR进行双向通信(1)

    MVC5使用SignalR进行双向通信 (1) 配置Signal 在NuGet中通过 install-package Microsoft.AspNet.SignalR 命令进行安装 在Scripts文 ...

  6. Mysql的cmake编译与安装

    Mysql的cmake编译与安装 实验准备环境: 我的操作系统是centos6.6 编译安装MariaDB之前,我们需要准备一些需要的环境 1.开发包组套件 [root@node19 ~]# yum ...

  7. [leetcode]_Minimum Depth of Binary Tree

    第五道树题,10分钟之内一遍AC.做树题越来越有feel~ 题目:求一棵树从root结点到叶子结点的最短路径. 思路:仍然是递归.如果一个结点的左右子树任意一边为Null,该子树的minDepth应为 ...

  8. mysql 格式化时间

    SELECT phone,chang, msg, linkid, DATE_FORMAT(mo_time, '%Y%m%d%H%i%s') FROM mo http://www.w3school.co ...

  9. TextView字符串波浪式跳动--第三方开源---JumpingBeans

    在github上有一个开源项目:JumpingBeans,其项目主页是:https://github.com/frakbot/JumpingBeans JumpingBeans将一个普通的Androi ...

  10. 通过API函数来控制SQLite数据库增删改查

    person类属性有Intenger id,String name,Intenger  age,相应的构造方法和set get方法. package com.xh.tx.dao; import and ...