移动支付在地铁互联网售票机系统中的应用

区锦荣，徐骏善

(南京理工大学机械工程学院，江苏 南京 210094)

0 引 言

在当前智能手机和4G移动网络广泛普及的背景下，以智能手机为载体的移动支付得到了空前的发展,成为各方抢占金融创新能力和服务水平制高点的竞争领域,同时也成为金融便民、利民的重要途径[1]。移动支付，是一种依靠短信、HTTP、WAP或NFC(近场通信技术)等无线方式完成支付行为的新型支付方式[2]。据央行发布的2017年支付体系运行总体情况，银行业金融机构共处理电子支付业务1525.80亿笔，金额2419.20万亿元。其中，移动支付业务375.52亿笔，金额202.93万亿元，同比分别增长46.06%和28.80%[3]。此外，中国的移动支付普及率高达77%，以支付宝、微信支付、京东支付为代表的移动支付成为人们支付方式的首选[4]。由此可见，移动支付已经成为了国内人们日常生活的重要支付方式，并将逐渐替代现金在日常交易中的位置。

自动售检票(Auto Fare Collection, AFC)系统是城市地铁中一个关键的子系统，集结了机电一体化技术、信息技术等高科技技术，实现集售票、检票、票务管理工作于一体的综合系统[5]。经过多年来的研究发展，自动售检票系统已经从原来的国外引进逐渐实现了国产化，运用在全国各地的城市地铁中[6]。而为了适应人们的支付习惯，方便人们出行，促进无现金社会的发展，把移动支付技术引入自动售检票系统中具有一定的必要性。

自2015年末广州地铁“云购票机”上线以来[7]，郑州地铁和杭州地铁的自助取票机也先后于2016年上线[8-9]。此后，全国各地地铁自动售票机也开始逐渐支持移动支付购票功能。目前国内支持移动支付的自动售票机主要有2种购票方式，一种为直接在售票机上进行目的车站与车票数量选择，然后通过手机支付购票；另一种为在手机APP上选择目的车站与车票数量并付款，然后通过APP提供的二维码凭据到取票机上进行扫码取票[7]。而反观国外，由于消费习惯为信用卡支付，移动支付发展相对落后，地铁自动售票机依然只支持传统的现金、IC充值卡和银行卡购票。

1 互联网售票机系统

传统自动售票机(Ticket Vending Machine, TVM)是自动售检票系统中的重要组成部分，主要功能为售卖车票、收取票款、硬币找零、后台维护、数据管理等功能[10]。而互联网售票机(ITVM)相对于传统TVM增加了二维码支付购票功能，不支持现金购票，所以在硬件和软件层面需要移除纸币收款模块、硬币收款模块和硬币找零模块等设备和对应的软件代码。

ITVM系统软件开发采用分层设计的方式。分层技术可以在一定程度上扩展计算机软件,更进一步地分解计算机软件开发中的复杂系统[11]。采用面向接口编程的思维，能有效地降低组件提供者和组件使用者之间的耦合性,使得两者之间仅通过接口来实现通信[12]。只要接口不变，一方的修改就不会影响另一方的实现,大大减轻了软件开发的复杂度,并且易于实现软件模块的互换,软件升级时可以只部署发生变化的部分，而不会影响其他部分[13]。如图1所示，互联网售票机软件的总体架构分为5层，分别为表示层、业务层、基础业务层、设备控制层与通信层[14]。要使ITVM系统具备移动支付功能，只需在业务层添加移动支付的相关代码模块。

图1 ITVM系统框架

2 互联网售票机移动支付功能设计

2.1 移动支付与TVM的结合形式

目前国内正在使用的传统TVM性能已经十分成熟稳定，要在此基础上集成移动支付功能，需要在原来的基础上接上互联网，与支付宝、微信支付等支付系统进行对接。由于移动支付依赖于网络，而TVM系统所处的网络环境相对较差，网络延迟与丢失是不可避免的，因此在交易过程中，TVM会有一定几率出现收不到第三方支付系统发来的订单交易情况，追踪不到实际的交易支付情况，丢失相应的交易数据，给AFC系统的日结清算带来麻烦。此外，与第三方支付系统的对接存在网络安全问题，TVM一旦接入外网，将会面临病毒、木马、黑客攻击等网络威胁，而线上的TVM设备性能有限，AFC系统难以对每台TVM设备实施安全管控[15]。为了应对上述情况，自动售票机系统应当把移动支付功能委托给服务器平台，以确保每一笔移动支付交易数据记录到平台数据库中，并集中处理网络安全问题。移动支付系统基本结构如图2所示。

图2 ITVM移动支付系统

自动售票机专线网络连接到支付平台，并向支付平台发送请求，支付平台提取请求内容，按照既定的接口标准和安全规范对数据进行加密，向第三方支付系统再次发送请求，第三方支付系统进行相关交易的处理后把交易状况返回给支付平台，支付平台再返回给自动售票机。其中支付平台每次接收到自动售票机发送的请求或第三方支付系统返回的消息时都会提取出相关交易数据并保存到数据库。当自动售票机系统出现网络问题时，车站人员可以随时通过访问支付平台来获取最新的交易数据。

在互联网售票机移动支付系统中，ITVM端与支付平台端均储存着每一笔移动支付的交易数据。ITVM作为移动支付的委托方，每一笔交易数据中的实收金额、订单号等移动支付相关数据都是从支付平台获取的，并把实售票数、车票ID等实售票数据反馈到支付平台中。在正常情况下，两端的交易数据应该一致，但由于两端之间依赖网络进行数据传输，同样存在因网络问题导致的数据传输失败，使交易数据存在差异。为了应对上述情况，采用支付平台连接ACC，ITVM连接SC的方式[16]，从而使AFC系统形成闭环。对接后的AFC系统框架如图3所示。

图3 移动支付AFC系统框架

ITVM端的移动支付交易数据通过原有的AFC框架经由车站系统(SC)和线路中央系统(LC)最终传输到票务清分系统(ACC)，而支付平台端的交易数据直接传输到ACC。ACC在进行清算之前，先利用ITVM端和支付平台端的交易数据进行初步对账，找出存在差异的交易数据，对相应订单进行跟踪处理，判定问题订单的最终结果，然后再进行清算。

2.2 互联网售票机移动支付工作流程设计

在现行的多种移动支付中，扫码支付作为较为灵活方便的支付方式，是一种允许客户通过使用手机上的支付软件扫描商家展示的二维码，从而获取相应的交易信息并进行付款的支付方式[17]。由于扫码支付自身的业务特点，可以在不需要增加硬件的情况下直接集成到现有的TVM系统中，适合应用于现有地铁线路的TVM移动支付改造。本节以支付宝扫码支付为例对互联网售票机移动支付工作流程与交互进行设计。

移动支付购票的流程涉及用户、支付宝钱包APP，ITVM设备，支付平台与第三方支付系统之间的交互[18]，具体流程如图4所示。

扫码支付购票流程根据订单进度可以分为订单申请、订单查询和订单完成这3个阶段。

1)订单申请阶段。

用户选择并确定终点站与车票张数后，ITVM根据该笔交易的信息和设备信息向支付平台发起下单请求，支付平台从中提取相关信息，根据请求时间生成订单号，调用支付宝支付系统的预下单接口，并同时在数据库中创建新的交易记录。支付宝支付系统将该笔订单对应的二维码串返回到支付平台，支付平台再把二维码串和订单号返回给ITVM，最后ITVM根据二维码串生成二维码图片展示给用户。此时该笔订单已经创建完成，并且以订单号作为该笔订单的唯一标识id。

图4 ITVM移动支付交互图

2)订单查询阶段。

订单创建成功后，ITVM马上开启轮询线程，每隔一段时间向支付平台发起交易查询请求，支付平台再向支付宝支付系统发起交易查询。支付宝支付系统返回订单状态，经由支付平台传到ITVM。

在此阶段中，若在轮询时间内用户使用支付宝钱包APP扫描二维码，获取到订单信息并进行付款，付款成功后ITVM的下一次订单查询将会得知订单状态为已支付，随即退出轮询线程。此外，如果超过轮询时间或者用户点击取消按钮，轮询线程也将结束，并进入订单完成阶段。

3)订单完成阶段。

订单完成阶段分为支付失败与支付成功2种情况。当订单查询阶段中返回的结果为未支付，且支付超时时间到了，或者乘客点击取消按钮，系统将会把订单判定为支付失败。而在订单查询阶段中超时时间内查询请求的返回结果为已支付，则订单会被判定为支付成功。

在支付失败的情况下，ITVM向支付平台发起订单撤销请求，支付平台再向支付宝支付系统发起订单撤销，支付宝支付系统将把撤销结果原路返回到ITVM。在支付成功的情况下，ITVM将进行出票流程，出票完成后以实际发出的车票数与车票信息为参数调用支付平台的反馈接口，如果未收到返回，则再次调用接口，保证支付平台能接收到正确的订单最终结果，并更新到数据库中。自此，该笔订单的生命周期已经结束，ITVM随时准备开始下一笔订单。

3 互联网售票机移动支付功能实现

3.1 互联网售票机与支付平台的通信方式

HTTP协议是互联网上应用最为广泛的一种网络协议，基于这个协议的报文有2种类型：请求和响应，其支持的请求有3种：GET、HEAD和POST[19]。GET请求用于返回request-URI所指出的任意信息；HEAD请求类似于GET请求，但服务器程序只返回指定文档的首部信息，而不包含实际的文档内容；POST请求用来发送电子邮件、新闻或发送能由交互用户填写的表格[20]。本系统通过HTTP协议POST请求方式实现与支付平台的通信。

支付平台提供预下单请求、交易查询、交易撤销和出票结果提交4个接口，接口传入参数与返回值的传输格式采用JSON的对象结构。该结构为一个无序的“名称/值”对的集合。每个对象以“{”作为起始标志，以“}”作为结束标志,“名称”用“""”括住,“值”若为字符串则也须用“""”括住，对于数字或布尔值则不需要，“名称”与“值”之间用“:”间隔,“名称/值”对之间则用“,”分隔[21]。以预下单请求接口返回信息为例，包括二维码地址和订单号，组成的JSON串样例如下：

{"QRCode_url":"https://XXX","OrderID":"ABC123"}

ITVM收到支付平台返回的这条信息后，通过JSON语法规则便可解析出该JSON对象包含QRCode_url和OrderID这2个元素，对应的值分别为https://XXX和ABC123。

3.2 基于libcurl的通信实现

libcurl是一个免费开源的客户端URL传输库，支持FTP、FTPS、TFTP、HTTP、HTTPS、GOPHER、TELNET、DICT、FILE和LDAP。本系统采用libcurl库来实现HTTP请求的发送与接收，以下是用libcurl库实现HTTP请求的部分C++代码：

curl_global_init(CURL_GLOBAL_ALL);//初始化所有设置

curl=curl_easy_init();//创建CURL类型的文件描述指针

curl_easy_setopt(curl,CURLOPT_SSL_VERIFYPEER,0L);//不验证对等证书

curl_easy_setopt(curl,CURLOPT_SSL_VERIFYHOST,0L);//不验证服务器SSL证书名称

curl_easy_setopt(curl,CURLOPT_HEADER,1);//将头文件的信息作为数据流输出

curl_easy_setopt(curl,CURLOPT_URL,url);//传入请求的目标URL地址

curl_easy_setopt(curl,CURLOPT_POST,1);//设置发送post请求

curl_easy_setopt(curl,CURLOPT_POSTFIELDS,requestEntity);//传入post请求内容

curl_easy_setopt(curl,CURLOPT_TIMEOUT,5);//允许CURL函数执行的最长秒数

curl_easy_setopt(curl,CURLOPT_CONNECTTIMEOUT,3);//设置连接超时时间

curl_easy_setopt(curl,CURLOPT_WRITEFUNCTION,write_data);//设置回调函数名，用以保存返回数据

curl_easy_setopt(curl,CURLOPT_WRITEDATA,this);//配置回调函数参数

curl_easy_perform(curl);//执行网络请求

curl_easy_cleanup(curl);//释放内存

其中，curl_easy_setopt函数是用来对指定curl句柄进行设置的函数，第一个参数是需要设置的句柄，第二个参数是需要设置的选项，第三个参数是设置值。由于ITVM与支付平台之间通过专线进行连接，具有很强的安全性，所以可以不进行数据加密和证书验证，以简化业务流程。

4 互联网售票机系统测试

为确保软件的正常运作，发现隐藏在软件中的漏洞，并使软件达到性能要求，需要对整套软件进行测试。本测试的环境为实验平台搭建的虚拟车站，具备1台完整的ITVM和1台参照用的南京4号线TVM，其中南京4号线TVM为只支持纸币、硬币付款的传统TVM，测试工具为1台安卓智能手机、1000张单程票、50张5元人民币、100个1元硬币和余额充足的支付宝、微信账号。为了得出最真实有效的测试数据，本文还原乘客的购票操作，记录从初始界面开始到成功购买1张车票的时间，同时对TVM进行现金购票测试以作对比。经过反复测试后，计算每个测试计时的平均值。测试记录如表1所示。

表1 购票时间测试

在ITVM的测试中，支付宝与微信支付均采用指纹支付，并在测试前先进入扫码界面，而在TVM的测试中，测试人员提前准备好相应票款，以避免不必要的时间占用。从测试结果可以得出，使用ITVM移动支付购票比传统TVM耗时更短，效率更高。

5 结束语

本文在原有AFC系统框架的基础上接入移动支付平台，充当整个AFC系统对互联网的接入点，承担了ITVM向第三方支付系统的交互，并设计了基于支付平台的ITVM移动支付系统工作流程，提出了一套移动支付在ITVM系统的应用方案。根据本方案设计的互联网售票机已经应用到南京地铁AFC系统中，经过测试验收，目前已经上线[22]。互联网售票机当前的功能仅限于扫码支付购票，有望在后续的软件更新中增加二维码取票功能[23]。