區(qū)錦榮，徐駿善

(南京理工大學(xué)機(jī)械工程學(xué)院，江蘇 南京 210094)

0 引 言

在當(dāng)前智能手機(jī)和4G移動(dòng)網(wǎng)絡(luò)廣泛普及的背景下，以智能手機(jī)為載體的移動(dòng)支付得到了空前的發(fā)展,成為各方搶占金融創(chuàng)新能力和服務(wù)水平制高點(diǎn)的競(jìng)爭(zhēng)領(lǐng)域,同時(shí)也成為金融便民、利民的重要途徑[1]。移動(dòng)支付，是一種依靠短信、HTTP、WAP或NFC(近場(chǎng)通信技術(shù))等無(wú)線方式完成支付行為的新型支付方式[2]。據(jù)央行發(fā)布的2017年支付體系運(yùn)行總體情況，銀行業(yè)金融機(jī)構(gòu)共處理電子支付業(yè)務(wù)1525.80億筆，金額2419.20萬(wàn)億元。其中，移動(dòng)支付業(yè)務(wù)375.52億筆，金額202.93萬(wàn)億元，同比分別增長(zhǎng)46.06%和28.80%[3]。此外，中國(guó)的移動(dòng)支付普及率高達(dá)77%，以支付寶、微信支付、京東支付為代表的移動(dòng)支付成為人們支付方式的首選[4]。由此可見(jiàn)，移動(dòng)支付已經(jīng)成為了國(guó)內(nèi)人們?nèi)粘Ｉ畹闹匾Ц斗绞?，并將逐漸替代現(xiàn)金在日常交易中的位置。

自動(dòng)售檢票(Auto Fare Collection, AFC)系統(tǒng)是城市地鐵中一個(gè)關(guān)鍵的子系統(tǒng)，集結(jié)了機(jī)電一體化技術(shù)、信息技術(shù)等高科技技術(shù)，實(shí)現(xiàn)集售票、檢票、票務(wù)管理工作于一體的綜合系統(tǒng)[5]。經(jīng)過(guò)多年來(lái)的研究發(fā)展，自動(dòng)售檢票系統(tǒng)已經(jīng)從原來(lái)的國(guó)外引進(jìn)逐漸實(shí)現(xiàn)了國(guó)產(chǎn)化，運(yùn)用在全國(guó)各地的城市地鐵中[6]。而為了適應(yīng)人們的支付習(xí)慣，方便人們出行，促進(jìn)無(wú)現(xiàn)金社會(huì)的發(fā)展，把移動(dòng)支付技術(shù)引入自動(dòng)售檢票系統(tǒng)中具有一定的必要性。

自2015年末廣州地鐵“云購(gòu)票機(jī)”上線以來(lái)[7]，鄭州地鐵和杭州地鐵的自助取票機(jī)也先后于2016年上線[8-9]。此后，全國(guó)各地地鐵自動(dòng)售票機(jī)也開(kāi)始逐漸支持移動(dòng)支付購(gòu)票功能。目前國(guó)內(nèi)支持移動(dòng)支付的自動(dòng)售票機(jī)主要有2種購(gòu)票方式，一種為直接在售票機(jī)上進(jìn)行目的車站與車票數(shù)量選擇，然后通過(guò)手機(jī)支付購(gòu)票；另一種為在手機(jī)APP上選擇目的車站與車票數(shù)量并付款，然后通過(guò)APP提供的二維碼憑據(jù)到取票機(jī)上進(jìn)行掃碼取票[7]。而反觀國(guó)外，由于消費(fèi)習(xí)慣為信用卡支付，移動(dòng)支付發(fā)展相對(duì)落后，地鐵自動(dòng)售票機(jī)依然只支持傳統(tǒng)的現(xiàn)金、IC充值卡和銀行卡購(gòu)票。

1 互聯(lián)網(wǎng)售票機(jī)系統(tǒng)

傳統(tǒng)自動(dòng)售票機(jī)(Ticket Vending Machine, TVM)是自動(dòng)售檢票系統(tǒng)中的重要組成部分，主要功能為售賣車票、收取票款、硬幣找零、后臺(tái)維護(hù)、數(shù)據(jù)管理等功能[10]。而互聯(lián)網(wǎng)售票機(jī)(ITVM)相對(duì)于傳統(tǒng)TVM增加了二維碼支付購(gòu)票功能，不支持現(xiàn)金購(gòu)票，所以在硬件和軟件層面需要移除紙幣收款模塊、硬幣收款模塊和硬幣找零模塊等設(shè)備和對(duì)應(yīng)的軟件代碼。

ITVM系統(tǒng)軟件開(kāi)發(fā)采用分層設(shè)計(jì)的方式。分層技術(shù)可以在一定程度上擴(kuò)展計(jì)算機(jī)軟件,更進(jìn)一步地分解計(jì)算機(jī)軟件開(kāi)發(fā)中的復(fù)雜系統(tǒng)[11]。采用面向接口編程的思維，能有效地降低組件提供者和組件使用者之間的耦合性,使得兩者之間僅通過(guò)接口來(lái)實(shí)現(xiàn)通信[12]。只要接口不變，一方的修改就不會(huì)影響另一方的實(shí)現(xiàn),大大減輕了軟件開(kāi)發(fā)的復(fù)雜度,并且易于實(shí)現(xiàn)軟件模塊的互換,軟件升級(jí)時(shí)可以只部署發(fā)生變化的部分，而不會(huì)影響其他部分[13]。如圖1所示，互聯(lián)網(wǎng)售票機(jī)軟件的總體架構(gòu)分為5層，分別為表示層、業(yè)務(wù)層、基礎(chǔ)業(yè)務(wù)層、設(shè)備控制層與通信層[14]。要使ITVM系統(tǒng)具備移動(dòng)支付功能，只需在業(yè)務(wù)層添加移動(dòng)支付的相關(guān)代碼模塊。

圖1 ITVM系統(tǒng)框架

2 互聯(lián)網(wǎng)售票機(jī)移動(dòng)支付功能設(shè)計(jì)

2.1 移動(dòng)支付與TVM的結(jié)合形式

目前國(guó)內(nèi)正在使用的傳統(tǒng)TVM性能已經(jīng)十分成熟穩(wěn)定，要在此基礎(chǔ)上集成移動(dòng)支付功能，需要在原來(lái)的基礎(chǔ)上接上互聯(lián)網(wǎng)，與支付寶、微信支付等支付系統(tǒng)進(jìn)行對(duì)接。由于移動(dòng)支付依賴于網(wǎng)絡(luò)，而TVM系統(tǒng)所處的網(wǎng)絡(luò)環(huán)境相對(duì)較差，網(wǎng)絡(luò)延遲與丟失是不可避免的，因此在交易過(guò)程中，TVM會(huì)有一定幾率出現(xiàn)收不到第三方支付系統(tǒng)發(fā)來(lái)的訂單交易情況，追蹤不到實(shí)際的交易支付情況，丟失相應(yīng)的交易數(shù)據(jù)，給AFC系統(tǒng)的日結(jié)清算帶來(lái)麻煩。此外，與第三方支付系統(tǒng)的對(duì)接存在網(wǎng)絡(luò)安全問(wèn)題，TVM一旦接入外網(wǎng)，將會(huì)面臨病毒、木馬、黑客攻擊等網(wǎng)絡(luò)威脅，而線上的TVM設(shè)備性能有限，AFC系統(tǒng)難以對(duì)每臺(tái)TVM設(shè)備實(shí)施安全管控[15]。為了應(yīng)對(duì)上述情況，自動(dòng)售票機(jī)系統(tǒng)應(yīng)當(dāng)把移動(dòng)支付功能委托給服務(wù)器平臺(tái)，以確保每一筆移動(dòng)支付交易數(shù)據(jù)記錄到平臺(tái)數(shù)據(jù)庫(kù)中，并集中處理網(wǎng)絡(luò)安全問(wèn)題。移動(dòng)支付系統(tǒng)基本結(jié)構(gòu)如圖2所示。

圖2 ITVM移動(dòng)支付系統(tǒng)

自動(dòng)售票機(jī)專線網(wǎng)絡(luò)連接到支付平臺(tái)，并向支付平臺(tái)發(fā)送請(qǐng)求，支付平臺(tái)提取請(qǐng)求內(nèi)容，按照既定的接口標(biāo)準(zhǔn)和安全規(guī)范對(duì)數(shù)據(jù)進(jìn)行加密，向第三方支付系統(tǒng)再次發(fā)送請(qǐng)求，第三方支付系統(tǒng)進(jìn)行相關(guān)交易的處理后把交易狀況返回給支付平臺(tái)，支付平臺(tái)再返回給自動(dòng)售票機(jī)。其中支付平臺(tái)每次接收到自動(dòng)售票機(jī)發(fā)送的請(qǐng)求或第三方支付系統(tǒng)返回的消息時(shí)都會(huì)提取出相關(guān)交易數(shù)據(jù)并保存到數(shù)據(jù)庫(kù)。當(dāng)自動(dòng)售票機(jī)系統(tǒng)出現(xiàn)網(wǎng)絡(luò)問(wèn)題時(shí)，車站人員可以隨時(shí)通過(guò)訪問(wèn)支付平臺(tái)來(lái)獲取最新的交易數(shù)據(jù)。

在互聯(lián)網(wǎng)售票機(jī)移動(dòng)支付系統(tǒng)中，ITVM端與支付平臺(tái)端均儲(chǔ)存著每一筆移動(dòng)支付的交易數(shù)據(jù)。ITVM作為移動(dòng)支付的委托方，每一筆交易數(shù)據(jù)中的實(shí)收金額、訂單號(hào)等移動(dòng)支付相關(guān)數(shù)據(jù)都是從支付平臺(tái)獲取的，并把實(shí)售票數(shù)、車票ID等實(shí)售票數(shù)據(jù)反饋到支付平臺(tái)中。在正常情況下，兩端的交易數(shù)據(jù)應(yīng)該一致，但由于兩端之間依賴網(wǎng)絡(luò)進(jìn)行數(shù)據(jù)傳輸，同樣存在因網(wǎng)絡(luò)問(wèn)題導(dǎo)致的數(shù)據(jù)傳輸失敗，使交易數(shù)據(jù)存在差異。為了應(yīng)對(duì)上述情況，采用支付平臺(tái)連接ACC，ITVM連接SC的方式[16]，從而使AFC系統(tǒng)形成閉環(huán)。對(duì)接后的AFC系統(tǒng)框架如圖3所示。

圖3 移動(dòng)支付AFC系統(tǒng)框架

ITVM端的移動(dòng)支付交易數(shù)據(jù)通過(guò)原有的AFC框架經(jīng)由車站系統(tǒng)(SC)和線路中央系統(tǒng)(LC)最終傳輸?shù)狡眲?wù)清分系統(tǒng)(ACC)，而支付平臺(tái)端的交易數(shù)據(jù)直接傳輸?shù)紸CC。ACC在進(jìn)行清算之前，先利用ITVM端和支付平臺(tái)端的交易數(shù)據(jù)進(jìn)行初步對(duì)賬，找出存在差異的交易數(shù)據(jù)，對(duì)相應(yīng)訂單進(jìn)行跟蹤處理，判定問(wèn)題訂單的最終結(jié)果，然后再進(jìn)行清算。

2.2 互聯(lián)網(wǎng)售票機(jī)移動(dòng)支付工作流程設(shè)計(jì)

在現(xiàn)行的多種移動(dòng)支付中，掃碼支付作為較為靈活方便的支付方式，是一種允許客戶通過(guò)使用手機(jī)上的支付軟件掃描商家展示的二維碼，從而獲取相應(yīng)的交易信息并進(jìn)行付款的支付方式[17]。由于掃碼支付自身的業(yè)務(wù)特點(diǎn)，可以在不需要增加硬件的情況下直接集成到現(xiàn)有的TVM系統(tǒng)中，適合應(yīng)用于現(xiàn)有地鐵線路的TVM移動(dòng)支付改造。本節(jié)以支付寶掃碼支付為例對(duì)互聯(lián)網(wǎng)售票機(jī)移動(dòng)支付工作流程與交互進(jìn)行設(shè)計(jì)。

移動(dòng)支付購(gòu)票的流程涉及用戶、支付寶錢包APP，ITVM設(shè)備，支付平臺(tái)與第三方支付系統(tǒng)之間的交互[18]，具體流程如圖4所示。

掃碼支付購(gòu)票流程根據(jù)訂單進(jìn)度可以分為訂單申請(qǐng)、訂單查詢和訂單完成這3個(gè)階段。

1)訂單申請(qǐng)階段。

用戶選擇并確定終點(diǎn)站與車票張數(shù)后，ITVM根據(jù)該筆交易的信息和設(shè)備信息向支付平臺(tái)發(fā)起下單請(qǐng)求，支付平臺(tái)從中提取相關(guān)信息，根據(jù)請(qǐng)求時(shí)間生成訂單號(hào)，調(diào)用支付寶支付系統(tǒng)的預(yù)下單接口，并同時(shí)在數(shù)據(jù)庫(kù)中創(chuàng)建新的交易記錄。支付寶支付系統(tǒng)將該筆訂單對(duì)應(yīng)的二維碼串返回到支付平臺(tái)，支付平臺(tái)再把二維碼串和訂單號(hào)返回給ITVM，最后ITVM根據(jù)二維碼串生成二維碼圖片展示給用戶。此時(shí)該筆訂單已經(jīng)創(chuàng)建完成，并且以訂單號(hào)作為該筆訂單的唯一標(biāo)識(shí)id。

圖4 ITVM移動(dòng)支付交互圖

2)訂單查詢階段。

訂單創(chuàng)建成功后，ITVM馬上開(kāi)啟輪詢線程，每隔一段時(shí)間向支付平臺(tái)發(fā)起交易查詢請(qǐng)求，支付平臺(tái)再向支付寶支付系統(tǒng)發(fā)起交易查詢。支付寶支付系統(tǒng)返回訂單狀態(tài)，經(jīng)由支付平臺(tái)傳到ITVM。

在此階段中，若在輪詢時(shí)間內(nèi)用戶使用支付寶錢包APP掃描二維碼，獲取到訂單信息并進(jìn)行付款，付款成功后ITVM的下一次訂單查詢將會(huì)得知訂單狀態(tài)為已支付，隨即退出輪詢線程。此外，如果超過(guò)輪詢時(shí)間或者用戶點(diǎn)擊取消按鈕，輪詢線程也將結(jié)束，并進(jìn)入訂單完成階段。

3)訂單完成階段。

訂單完成階段分為支付失敗與支付成功2種情況。當(dāng)訂單查詢階段中返回的結(jié)果為未支付，且支付超時(shí)時(shí)間到了，或者乘客點(diǎn)擊取消按鈕，系統(tǒng)將會(huì)把訂單判定為支付失敗。而在訂單查詢階段中超時(shí)時(shí)間內(nèi)查詢請(qǐng)求的返回結(jié)果為已支付，則訂單會(huì)被判定為支付成功。

在支付失敗的情況下，ITVM向支付平臺(tái)發(fā)起訂單撤銷請(qǐng)求，支付平臺(tái)再向支付寶支付系統(tǒng)發(fā)起訂單撤銷，支付寶支付系統(tǒng)將把撤銷結(jié)果原路返回到ITVM。在支付成功的情況下，ITVM將進(jìn)行出票流程，出票完成后以實(shí)際發(fā)出的車票數(shù)與車票信息為參數(shù)調(diào)用支付平臺(tái)的反饋接口，如果未收到返回，則再次調(diào)用接口，保證支付平臺(tái)能接收到正確的訂單最終結(jié)果，并更新到數(shù)據(jù)庫(kù)中。自此，該筆訂單的生命周期已經(jīng)結(jié)束，ITVM隨時(shí)準(zhǔn)備開(kāi)始下一筆訂單。

3 互聯(lián)網(wǎng)售票機(jī)移動(dòng)支付功能實(shí)現(xiàn)

3.1 互聯(lián)網(wǎng)售票機(jī)與支付平臺(tái)的通信方式

HTTP協(xié)議是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，基于這個(gè)協(xié)議的報(bào)文有2種類型：請(qǐng)求和響應(yīng)，其支持的請(qǐng)求有3種：GET、HEAD和POST[19]。GET請(qǐng)求用于返回request-URI所指出的任意信息；HEAD請(qǐng)求類似于GET請(qǐng)求，但服務(wù)器程序只返回指定文檔的首部信息，而不包含實(shí)際的文檔內(nèi)容；POST請(qǐng)求用來(lái)發(fā)送電子郵件、新聞或發(fā)送能由交互用戶填寫的表格[20]。本系統(tǒng)通過(guò)HTTP協(xié)議POST請(qǐng)求方式實(shí)現(xiàn)與支付平臺(tái)的通信。

支付平臺(tái)提供預(yù)下單請(qǐng)求、交易查詢、交易撤銷和出票結(jié)果提交4個(gè)接口，接口傳入?yún)?shù)與返回值的傳輸格式采用JSON的對(duì)象結(jié)構(gòu)。該結(jié)構(gòu)為一個(gè)無(wú)序的“名稱/值”對(duì)的集合。每個(gè)對(duì)象以“{”作為起始標(biāo)志，以“}”作為結(jié)束標(biāo)志,“名稱”用“""”括住,“值”若為字符串則也須用“""”括住，對(duì)于數(shù)字或布爾值則不需要，“名稱”與“值”之間用“:”間隔,“名稱/值”對(duì)之間則用“,”分隔[21]。以預(yù)下單請(qǐng)求接口返回信息為例，包括二維碼地址和訂單號(hào)，組成的JSON串樣例如下：

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

ITVM收到支付平臺(tái)返回的這條信息后，通過(guò)JSON語(yǔ)法規(guī)則便可解析出該JSON對(duì)象包含QRCode_url和OrderID這2個(gè)元素，對(duì)應(yīng)的值分別為https://XXX和ABC123。

3.2 基于libcurl的通信實(shí)現(xiàn)

libcurl是一個(gè)免費(fèi)開(kāi)源的客戶端URL傳輸庫(kù)，支持FTP、FTPS、TFTP、HTTP、HTTPS、GOPHER、TELNET、DICT、FILE和LDAP。本系統(tǒng)采用libcurl庫(kù)來(lái)實(shí)現(xiàn)HTTP請(qǐng)求的發(fā)送與接收，以下是用libcurl庫(kù)實(shí)現(xiàn)HTTP請(qǐng)求的部分C++代碼：

curl_global_init(CURL_GLOBAL_ALL);//初始化所有設(shè)置

curl=curl_easy_init();//創(chuàng)建CURL類型的文件描述指針

curl_easy_setopt(curl,CURLOPT_SSL_VERIFYPEER,0L);//不驗(yàn)證對(duì)等證書

curl_easy_setopt(curl,CURLOPT_SSL_VERIFYHOST,0L);//不驗(yàn)證服務(wù)器SSL證書名稱

curl_easy_setopt(curl,CURLOPT_HEADER,1);//將頭文件的信息作為數(shù)據(jù)流輸出

curl_easy_setopt(curl,CURLOPT_URL,url);//傳入請(qǐng)求的目標(biāo)URL地址

curl_easy_setopt(curl,CURLOPT_POST,1);//設(shè)置發(fā)送post請(qǐng)求

curl_easy_setopt(curl,CURLOPT_POSTFIELDS,requestEntity);//傳入post請(qǐng)求內(nèi)容

curl_easy_setopt(curl,CURLOPT_TIMEOUT,5);//允許CURL函數(shù)執(zhí)行的最長(zhǎng)秒數(shù)

curl_easy_setopt(curl,CURLOPT_CONNECTTIMEOUT,3);//設(shè)置連接超時(shí)時(shí)間

curl_easy_setopt(curl,CURLOPT_WRITEFUNCTION,write_data);//設(shè)置回調(diào)函數(shù)名，用以保存返回?cái)?shù)據(jù)

curl_easy_setopt(curl,CURLOPT_WRITEDATA,this);//配置回調(diào)函數(shù)參數(shù)

curl_easy_perform(curl);//執(zhí)行網(wǎng)絡(luò)請(qǐng)求

curl_easy_cleanup(curl);//釋放內(nèi)存

其中，curl_easy_setopt函數(shù)是用來(lái)對(duì)指定curl句柄進(jìn)行設(shè)置的函數(shù)，第一個(gè)參數(shù)是需要設(shè)置的句柄，第二個(gè)參數(shù)是需要設(shè)置的選項(xiàng)，第三個(gè)參數(shù)是設(shè)置值。由于ITVM與支付平臺(tái)之間通過(guò)專線進(jìn)行連接，具有很強(qiáng)的安全性，所以可以不進(jìn)行數(shù)據(jù)加密和證書驗(yàn)證，以簡(jiǎn)化業(yè)務(wù)流程。

4 互聯(lián)網(wǎng)售票機(jī)系統(tǒng)測(cè)試

為確保軟件的正常運(yùn)作，發(fā)現(xiàn)隱藏在軟件中的漏洞，并使軟件達(dá)到性能要求，需要對(duì)整套軟件進(jìn)行測(cè)試。本測(cè)試的環(huán)境為實(shí)驗(yàn)平臺(tái)搭建的虛擬車站，具備1臺(tái)完整的ITVM和1臺(tái)參照用的南京4號(hào)線TVM，其中南京4號(hào)線TVM為只支持紙幣、硬幣付款的傳統(tǒng)TVM，測(cè)試工具為1臺(tái)安卓智能手機(jī)、1000張單程票、50張5元人民幣、100個(gè)1元硬幣和余額充足的支付寶、微信賬號(hào)。為了得出最真實(shí)有效的測(cè)試數(shù)據(jù)，本文還原乘客的購(gòu)票操作，記錄從初始界面開(kāi)始到成功購(gòu)買1張車票的時(shí)間，同時(shí)對(duì)TVM進(jìn)行現(xiàn)金購(gòu)票測(cè)試以作對(duì)比。經(jīng)過(guò)反復(fù)測(cè)試后，計(jì)算每個(gè)測(cè)試計(jì)時(shí)的平均值。測(cè)試記錄如表1所示。

表1 購(gòu)票時(shí)間測(cè)試

在ITVM的測(cè)試中，支付寶與微信支付均采用指紋支付，并在測(cè)試前先進(jìn)入掃碼界面，而在TVM的測(cè)試中，測(cè)試人員提前準(zhǔn)備好相應(yīng)票款，以避免不必要的時(shí)間占用。從測(cè)試結(jié)果可以得出，使用ITVM移動(dòng)支付購(gòu)票比傳統(tǒng)TVM耗時(shí)更短，效率更高。

5 結(jié)束語(yǔ)

本文在原有AFC系統(tǒng)框架的基礎(chǔ)上接入移動(dòng)支付平臺(tái)，充當(dāng)整個(gè)AFC系統(tǒng)對(duì)互聯(lián)網(wǎng)的接入點(diǎn)，承擔(dān)了ITVM向第三方支付系統(tǒng)的交互，并設(shè)計(jì)了基于支付平臺(tái)的ITVM移動(dòng)支付系統(tǒng)工作流程，提出了一套移動(dòng)支付在ITVM系統(tǒng)的應(yīng)用方案。根據(jù)本方案設(shè)計(jì)的互聯(lián)網(wǎng)售票機(jī)已經(jīng)應(yīng)用到南京地鐵AFC系統(tǒng)中，經(jīng)過(guò)測(cè)試驗(yàn)收，目前已經(jīng)上線[22]?；ヂ?lián)網(wǎng)售票機(jī)當(dāng)前的功能僅限于掃碼支付購(gòu)票，有望在后續(xù)的軟件更新中增加二維碼取票功能[23]。