移动支付应用于公共交通近场支付的一种新型方案

叶飞

DOI：10.16644/j.cnki.cn33-1094/tp.2016.09.004

摘 要： 针对现行的移动支付在公共交通领域近场支付的方案和产品的不足，提出了一种全新的基于小额扩展应用额度的思路和解决方案，详细地说明了业务流程和技术实现的要点。该方案具有通用性强，技术成熟，用户体验佳等特点，具有很高的市场推广价值。

关键词： 移动支付； 近场支付； 小额支付； NFC

中图分类号：TP399 文献标志码：A 文章编号：1006-8228（2016）09-13-05

A new solution of mobile proximity payment applied to public transportation

Ye Fei

（China Unionpay Co.， Ltd， Shanghai 200135， China）

Abstract： In order to solve the drawbacks of current mobile proximity payment solutions applied in public transportation， this article proposes a new idea based on contactless low-value payment application including the detailed business scenarios and technical solution. The new solution is technically simple and more practicable with good user experience and will be more acceptable by all business parties involved.

Key words： mobile payment； proximity payment； low-value payment； NFC

0 引言

移动支付[1]一直是金融和互联网行业发展的一个热点和重点。移动支付已经逐渐渗入百姓的日常生活，出门只带一部手机是金融支付行业的一个愿景，也正逐渐成为现实。将移动支付方式应用于公共交通领域一直是一个研究的热点，市场上也有一些此类的产品和方案，但这些产品和方案尚没有得到市场的认可，普遍处于试验阶段[2]。本文试图提出一种新的思路和应用方案，以解决当前应用中的一些短板和问题。

1 电子现金方案及其局限性

当前将移动支付应用于公共交通近场支付主要是通过基于PBOC标准的电子现金应用实现。将PBOC应用下载、安装到移动终端的安全域中并进行个人化，移动终端就变成一张交通卡，用户使用具有NFC[3]通信功能的手机在地铁闸机或者公交读卡器上通过非接触的方式“刷”手机，就可以进出闸机和完成付款。中国银联联合中国移动和商业银行在上海、宁波、合肥、湖南等地推出了此类产品。

由于此类产品是基于电子现金应用，所以电子现金的缺点也成为此类产品的局限，主要有两点。

一是闪卡。所谓闪卡是指，用户在受理终端上通过非接触式进行脱机消费时，电子现金已经完成扣款，而受理终端还没有完成交易，无法打单，造成用户短款。对于闪卡，目前的处理流程是要求持卡人前往发卡银行的网点，将发生闪卡问题的银行卡交给银行，银行将该卡留存到发生闪卡问题之后的20天，核对这20天当中上送的脱机交易后确认是否发生闪卡，如银行确认，银行进行调账并通知用户，用户再次前往银行网点取回银行卡。这里所说的20天是业务规则所定，原则上要求受理电子现金的商户必须在20天以内将所有电子现金的交易上送。这个解决流程是比较复杂的，用户需前往发卡机构营业厅两次，并将银行卡留给银行处理。在移动支付中，这个业务流程实际上是不具备可操作性的。由于银行卡数据存储在手机的安全域中，用户必须将手机留给银行处理，而绝大多数用户不愿将手机留给银行，以致闪卡问题难以解决。

二是余额处理难。电子现金不同于银行借贷记账户的脱机账户，电子现金余额是写在银行卡片中的。电子现金的余额只有通过圈提才能返回银行主账户，但根据银行的业务规则规定，圈提只能在电子现金销户时进行，而且很多银行规定必须到柜面操作。这实际上增加了处理门槛，给用户带来不便。

2 基于小额扩展应用额度的方案

基于小额扩展应用额度的方案是根据小额扩展应用技术规范，复用电子现金余额（标记为9F79）作为交易额度（如果支持押金抵扣和分段计费，需要同时支持DF62和DF63，即分段扣费抵扣限额和分段扣费已抵扣金额），但是取消电子现金脱机账户，取消用户电子现金账户圈存过程。采用额度进行风险控制，每日清算直接从用户联机主账户扣款。

2.1 业务流程

以乘坐地铁为业务场景，其流程如图1、图2和图3所示。

2.1.1 开通业务

⑴ 用户在手机上向发卡行发起业务申请，要求开通乘坐地铁等业务；

⑵ 发卡行审核后批准用户申请并下发开通指令；

⑶ 用户手机接收到业务开通指令后，对手机安全域中的银行卡个人数据（TAG9F79，即电子现金余额）进行更新，设置此业务可用的额度金额，比如50元。

2.1.2 支付和清算

⑴ 用户在地铁入站闸机口刷手机；

⑵ 闸机验证额度之后，允许用户进站；

⑶ 用户在地铁出站闸机口刷手机；

⑷ 闸机完成对手机上可用额度的扣减，允许用户出站；

⑸ 地铁系统在在T日上将脱机交易文件上送银联转接清算网络；

⑹ 银联在T+1工作日进行轧差清算，将消费金额结算给地铁运营方；

⑺ 银联转接清算网络的发卡行发送清算文件，清算文件包含每笔交易信息；

⑻ 银行根据银联发送的清算文件，对该用户的银行账户进行扣款。

2.1.3 额度恢复

⑴ 发卡行根据银联转接网络发送的交易，对用户的可用额度进行监控，当可用额度低于某一个阈值时，比如5元，向用户手机发送指令，进行额度恢复；

⑵ 用户手机根据指令对手机安全域中的银行卡数据进行更新，恢复可用额度；

⑶ 用户手机恢复可用额度后回复发卡行。

2.2.1 Applet支持小额支付扩展应用交易

Applet应该支持小额扩展应用交易并符合如下要求：

⑴ 应允许闸机在选择应用后直接使用00B2指令读取SFI为0x1E的循环记录文件，以便发生争议读取客户进出站交易记录；

⑵ 应支持扩展应用Get Trans Prove指令，以便闸机在“闪卡”时重取交易凭证；

⑶ 应允许直接将电子现金余额（9F79）和分段扣费抵扣限额（DF62）个人化成非0值。

由于本方案中的额度只用于乘坐地铁等特定业务，不能用于其他行业，所以需要防止开通了小额支付扩展应用和复用了标签9F79后，电子现金在一般商户终端可以使用的风险，Applet通过如下方式进行控制防止电子现金交易在普通POS终端上被使用。

卡片收到GPO指令后，应按以下逻辑进行判断：

如果卡片返回的PDOL中不包含终端支持的扩展应用交易类型（DF60），那么表示卡片不支持扩展应用。此时，无论电子现金余额（9F79）是否为0，均不执行脱机消费流程，卡片默认按返回联机ARQC流程处理。如果卡片返回的PDOL中包含DF60，那么首先判断终端在GPO指令中送给卡片的DF60取值，如果取值为0，表示终端不支持扩展应用。此时，无论电子现金余额（9F79）是否为0，均不执行脱机消费流程，卡片默认按返回联机ARQC流程处理。如果取值为1，表示终端支持扩展应用。此时，新增卡片判别GPO之前是否有收到READ CAPP DATA指令。如果没有收到，那么卡片GPO之后拒绝交易，以避免终端错误设置DF60的情况发生。如果已收到，那么卡片执行小额支付扩展应用脱机消费流程。如图4所示。

行业终端与卡片交互处理流程如图5所示。

2.2.2 发卡行主动推送脚本修改卡片数据[4]

按现有规范流程，如果要修改卡片数据，就需要前台先执行选择应用、GPO、Read Record、Gen AC并将交易数据联机上送后台之后，后台才能下发发卡行脚本来修改卡片数据。本方案中额度恢复由银行后台进行判断是否低于额度阈值，当低于阈值时，银行将主动推送脚本更新卡片中的交易额度。

该后台推送脚本机制，无须前台预先执行相应操作，即可通过后台直接向卡片推送发卡行脚本来修改卡片数据。

该脚本推送机制：①卡片应能够认证发卡行，以防止非授权第三方修改卡片数据；②应防止使用同一个发卡行脚本对卡片进行重放攻击。

2.2.2.1 Push Put Data

卡片中的专有基本数据对象允许使用设置数据（PUT DATA）命令修改，远程额度更新复用PUT DATA指令。目前只有9F79、9F6B等基本数据对象才允许使用此命令修改。

⑴ 定义及范围

[编码＼&值＼&CLA＼&“04”＼&INS＼&“DA”＼&P1 P2＼&“00”（使用00，标准PUT DATA指令P1P2取值不会出现00。）＼&Lc＼&数据域字节数＼&数据域＼&Push ATC（2个字节）、修改的数据对象的新值（TLV结构）和MAC数据＼&Le＼&不存在＼&]

命令数据域中包括的是要修改的数据对象的TLV结构数值，后面加一个4到8字节的MAC。MAC算法所使用的过程密钥由卡片MAC子密钥经Push ATC分散得到，计算MAC的数据源由CLA、INS、P1、P2、Lc、Push ATC、数据对象的新值依次拼接得到。

⑵ 功能及实现

卡片新增数据对象Last Push ATC（卡片内部数据），长度为两字节，初始值为0。

Push ATC由发卡行后台维护，发卡行应保证每次Push Data指令所使用的Push ATC大于之前Push Data指令中所使用的值。

执行该指令时，卡片按以下逻辑进行判断：①检查指令中Push ATC是否大于卡片内部数据Last Push ATC，如果Push ATC值小于或等于Last Push ATC，表示可能是重放攻击，卡片返回失败（错误码6982）。②校验MAC，如果失败则返回错误（MAC算法所使用的过程密钥由卡片MAC子密钥经Push ATC分散得到，计算MAC的数据源由CLA、INS、P1、P2、Lc、Push ATC、数据对象的新值依次拼接得到）。

将P1、P2指定数据对象设置成新值，同时将Last Push ATC修改成指令中的Push ATC，返回成功9000。

⑶ 响应报文返回的处理状态

“9000”编码表示命令成功执行。

[SW1＼&SW2＼&含义＼&62＼&00＼&没有信息返回＼&62＼&81＼&数据可能被破坏＼&64＼&00＼&没有准确诊断＼&65＼&81＼&内存失败＼&67＼&00＼&长度错误＼&68＼&82＼&不支持安全报文＼&69＼&82＼&安全状态不满足＼&69＼&86＼&命令不允许＼&69＼&87＼&安全报文数据对象丢失＼&69＼&88＼&安全报文数据对象不正确＼&6A＼&80＼&错误的参数＼&6A＼&81＼&功能不支持＼&6A＼&84＼&文件中没有足够空间＼&6A＼&85＼&Lc 和 TLV TLV结构不一致＼&]

2.2.2.2 Push Put Data前建立安全通道

Push Put Data指令前需要建立安全通道，基于现有Put PendingCommand接口提出如下解决方案：

⑴ 发卡银行发送额度恢复请求；

⑵ 发卡银行向前端用户客户端推送SELECT指令，客户端向发卡银行返回应答；

⑶ 客户端向移动终端中的安全芯片发送SELECT指令，安全芯片执行SELECT命令后向客户端返回处理结果，客户端将返回结果发送给银行，银行解析得到sc，组SELECT+INIT_UPDATE+EXT_AUTH+PUTDATA指令，推送给客户端；

⑷ 客户端根据发卡银行指令要求不断地向安全芯片发送指令，安全芯片执行指令后向银行返回额度恢复操作结果通知。

3 优缺点分析

基于小额扩展应用额度的方案突破了传统电子现金的局限，优点十分明显，一是规避了电子现金圈存的问题，用户无须事先圈存就可以使用；二是由于采用可用额度，如果出现闪卡，只是扣减了额度，不影响用户账户的资金，用户不必进行任何处理；三是由于使用前没有圈存，所以也不涉及用户电子现金资金余额，用户无需处理余额；四是依然采用脱机交易，交易速度快，用户体验好。

本方案也有缺点，其也在于额度，发卡银行在收到交易请求后再对个人银行账户进行扣款。如果账户已经失效或者账户里没有足够的资金，则发卡银行存在一定的资金风险。针对这个风险，建议在信用卡上开展此业务，将该业务可用额度作为信用卡额度的一部分。

4 结束语

针对移动支付在公共交通近场支付的应用场景，本文提出了一种全新的方案，该方案既保留了现有产品的优点，同时有效地解决了现有产品的缺点，具有较高的应用价值。此方案虽然以公共交通行业作为应用的切入点，但实际上此方案具备普遍适用性，不仅适用于公共交通行业，也可应用于其他行业或领域。 此方案也利用了移动终端具有的计算和网络传输的能力，而传统的实体卡片由于不具备此能力，所以不能简单应用，必须结合其他终端（比如自助终端、读卡器等）进行使用，由于实体卡片有更多的使用人群，因此，将此方案延展到实体卡片将成为后续进一步研究的方向[5]。

参考文献（References）：

[1] 王永红.银行卡与移动支付发展路径[J].中国金融，2016.1：

76-78

[2] 陈元志，陈劲.移动支付产业的商业模式研究[J].企业经济，

2012.8：99-104

[3] 孙坚.基于NFC技术的移动支付应用探索[J].移动信息，

2016.4：64-64

[4] JR/T 0025.14.中国金融集成电路（IC）卡规范[S]. [国际、国

家标准]

[5] 刘健.NFC技术应用于城市一卡通的前景研究[J].企业科技

与发展，2014.6：24-25