區(qū)錦榮,徐駿善
(南京理工大學(xué)機械工程學(xué)院,江蘇 南京 210094)
在當前智能手機和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)粘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充值卡和銀行卡購票。
傳統(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)框架
目前國內(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é)果,然后再進行清算。
在現(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隨時準備開始下一筆訂單。
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。
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ù)流程。
為確保軟件的正常運作,發(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耗時更短,效率更高。
本文在原有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]。