移動支付在地鐵互聯(lián)網(wǎng)售票機系統(tǒng)中的應(yīng)用

區(qū)錦榮，徐駿善

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

0 引 言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1)訂單申請階段。

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

圖4 ITVM移動支付交互圖

2)訂單查詢階段。

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

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

3)訂單完成階段。

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

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

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

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

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

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

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

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

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

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

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

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

curl_easy_setopt(curl,CURLOPT_SSL_VERIFYPEER,0L);//不驗證對等證書

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

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

curl_easy_setopt(curl,CURLOPT_URL,url);//傳入請求的目標URL地址

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

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

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

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

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

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

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

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

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

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

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

表1 購票時間測試

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

5 結(jié)束語

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