首頁>>>技術(shù)>>>Wap

基于WAP的手機支付中間平臺的設(shè)計研究

2009/07/08

　　摘要：移動終端的不斷發(fā)展，使得利用移動終端進行商務(wù)活動成為了可能，提出了一種基于WAP并利用手機預(yù)存話費進行小額支付的中間平臺的設(shè)計理念，從可擴展性、性能優(yōu)化及安全性三方面給出了中間平臺的構(gòu)建策略。并對平臺支付協(xié)議進行了設(shè)計，為移動商務(wù)的發(fā)展提出了一個較好的解決方案。　　

　　模塊結(jié)構(gòu)及支付流程　　

　　手機支付通常有兩種形式：銀行卡支付和預(yù)存話費支付，銀行卡支付是將手機號碼與銀行卡綁定，客戶通過手機號實現(xiàn)銀行賬戶的查詢、賬單支付、商品購買等功能，預(yù)存話費支付是客戶直接利用現(xiàn)有的預(yù)存話費賬戶，通過話費代收的方式實現(xiàn)賬單支付、商品購買等功能，本文主要討論基于預(yù)存話費方式的手機支付中間平臺的實現(xiàn)。

　　該手機支付中間平臺包括三大功能模塊。WAP前臺界面是直接面向用戶的操作界面，主要包括手機支付登錄、手機支付注冊、用戶信息維護及跳轉(zhuǎn)到不同的商戶SP(服務(wù)提供商)進行相應(yīng)業(yè)務(wù)的繳費操作等功能。WEB后臺管理系統(tǒng)是面向管理員和各個商戶SP的操作界面，主要包括信息發(fā)布，訂單查詢、用戶管理和其它等功能。其中，信息發(fā)布是指管理員發(fā)布WAP前臺頁面所要展示的動態(tài)信息，支付中間平臺會為每個商戶的每個繳費請求記錄相應(yīng)的訂單信息，商戶SP可以登錄WEB后臺管理系統(tǒng)進行查詢及統(tǒng)計操作，用戶管理主要是指管理員對商戶SP基本信息的管理以及商戶SP對自己相關(guān)信息的管理。接口模塊是平臺的核心部分，主要是實現(xiàn)商戶SP與支付中間平臺、支付中間平臺與移動BOSS之間的底層通信，橫向上可以分為支付中間平臺與商戶SP的接口和與移動BOSS的接口。

　　整個支付流程用戶必須先在WAP前臺界面進行注冊，注冊成功后便可進行相應(yīng)的支付活動，無需登錄，登錄操作僅提供一些基本信息查詢與修改功能，如：查詢余額、查詢歷史交易記錄、充值卡充值、支付密碼修改等，注冊成功后，首先用戶需要登錄到WAP前臺頁面，選擇遇購買商品或繳費項目超鏈接，并進入相應(yīng)的商戶SP系統(tǒng)，商戶SF系統(tǒng)調(diào)用支付中間平臺接口，發(fā)送余額查詢請求，支付中間平臺收到請求后調(diào)用移動BOSS接口。查詢該用戶的可劃轉(zhuǎn)話費余額，并將查詢結(jié)果返回給支付平臺，支付中間平臺以應(yīng)答方式發(fā)送給商戶SP。如果余額充足，用戶確認(rèn)購買，商戶SP系統(tǒng)將發(fā)送繳費信息給支付中間平臺，支付中間平臺得到請求后將繳費信息發(fā)送給移動BOSS接口進行繳費，繳費完成后，移動BOSS將會把成功信息發(fā)送給支付中間平臺，支付中間平臺再將該信息傳遞給商戶SP系統(tǒng)，商戶SP系統(tǒng)提示用戶繳費成功，如用戶不確認(rèn)購買，則返回WAP前臺頁面繼續(xù)其它操作，如果余額不足，商戶SP系統(tǒng)將會提示用戶充值，用戶確認(rèn)充值后，商戶SP系統(tǒng)將發(fā)送充值請求給支付中間平臺，支付中間平臺將調(diào)用移動BOSS充值卡充值接口，進行充值，完成后即可進行支付。如放棄充值，則返回WAP前臺頁面繼續(xù)其它操作。　　

　　平臺構(gòu)建策略　　

　　2.1可擴展性策略

　　以往，用戶需要記住商戶SP的平臺地址，登錄后進行相應(yīng)的繳費操作，商戶SP接收到繳費請求后會直接調(diào)用移動BOSS接口來實現(xiàn)相應(yīng)的繳費等操作，現(xiàn)在，支付中間平臺會統(tǒng)一管理商戶SP的基本信息，用戶只需記住支付中間平臺的地址，就可以很輕松的訪問到其它商戶SP的支付系統(tǒng)，商戶SP在設(shè)計自己的支付系統(tǒng)時，只需將原有直接調(diào)用移動BOSS接口的部分改為調(diào)用支付中間平臺接口，其它部分不需要做任何的改動，支付中間平臺的設(shè)計思想不但解決了每個商戶SP各自為政，自己獨立開發(fā)支付系統(tǒng)，需要讓用戶分別記住每個服務(wù)提供商的平臺地址并進行相應(yīng)的支付操作的問題，同時還使得每個新商戶SP的接人變得非常的簡單，增強了支付中間平臺對商戶SP支付系統(tǒng)的可擴展性。每個新接人的商戶SP只要按照相關(guān)的協(xié)議規(guī)定，調(diào)用支付中間平臺的公共接口，并把基本信息告訴支付中間平臺，就可以實現(xiàn)接人。

　　2.2性能優(yōu)化策略

　　為了提高支付中間平臺的性能，采用異步長連接的方式來實現(xiàn)與商戶SP及移動BOSS之間的連接，如圖3。所謂異步長連接就是客戶端與服務(wù)端建立連接后，保持連接狀態(tài)，請求方在沒有收到響應(yīng)的情況下，可以發(fā)起多個請求，處理方可以并行處理，按任意順序返回給請求方處理結(jié)果。同時，為了提高支付中間平臺在接人商戶SP時的可擴展性，采用分層收發(fā)請求策略。這樣可以為每一個首次建立連接的商戶SP建立一個屬于商戶SP自己專有的發(fā)送隊列及接收隊列，所有的發(fā)送請求首先要加入發(fā)送隊列，這是第一層。第二層是一個所有商戶SP公共的發(fā)送及接收隊列，來存放接收自不同商戶發(fā)送隊列的信息，并統(tǒng)一將請求發(fā)送給移動BOSS。當(dāng)移動BOSS處理完請求并返回結(jié)果時，返回的信息將首先存放到第二層公共的接收隊列里，接收隊列收到信息會根據(jù)一定的標(biāo)識策略分發(fā)給所屬商戶SP的接收隊列，然后商戶SP接收隊列再將信息發(fā)送給相應(yīng)的商戶SP。為了進一步實現(xiàn)并發(fā)控制，并提高支付中間平臺與移動BOSS之間的系統(tǒng)資源利用率，更進一步的提升系統(tǒng)性能，支付中間平臺在與移動BOSS建立連接時會同時創(chuàng)建多個異步長連接實例，這樣一來，不管是在時間、空間，還是在系統(tǒng)資源利用率方面都可以做到最大程度的利用，大大提高系統(tǒng)自身及系統(tǒng)之間的性能，優(yōu)化整套系統(tǒng)的體系結(jié)構(gòu)。

　　 2.3安全性策略

　　為了確保數(shù)據(jù)傳遞的安全性，對整個支付流程采用如下安全策略：第一、支付中間平臺在數(shù)據(jù)傳輸方式上選擇基于TCP/IP的Socket進行系統(tǒng)及平臺之間的互聯(lián)互通，在一定程度上可提高系統(tǒng)自身數(shù)據(jù)傳輸?shù)陌踩�，而且平臺會對不同的IP地址請求做出相應(yīng)的安全策略，增加部分鑒權(quán)機制，最大程度地降低支付中間平臺所存在的安全隱患。第二、商戶SP與支付中間平臺之間通過公網(wǎng)進行數(shù)據(jù)傳輸。這樣可增加支付中間平臺的可擴展性，商戶的接人將不受空間和時間的限制。但這樣做存在著許多安全隱患，為了確保數(shù)據(jù)傳輸?shù)恼_性，在傳輸前對某些協(xié)議規(guī)定的信息進行MD5或RSA加密，另外，引入超時處理機制，以確保數(shù)據(jù)傳輸過程中的實時性，避免在整個傳輸過程中因某些不可預(yù)測因素而造成的數(shù)據(jù)包丟失。數(shù)據(jù)包在傳遞過程中如果發(fā)生超時，將根據(jù)協(xié)議規(guī)定的超時策略進行處理，第三、支付中間平臺與移動BOSS之間通過專線進行數(shù)據(jù)傳輸，以避免數(shù)據(jù)傳輸過程中遇到的許多安全隱患，如數(shù)據(jù)被惡意截獲、篡改等，同樣，為了確保數(shù)據(jù)傳輸過程的實時性，避免整個傳輸過程中因某些不可預(yù)測因素造成的數(shù)據(jù)包丟失，在這里也對數(shù)據(jù)包請求超時做相應(yīng)的處理�！　�

　　平臺支付協(xié)議設(shè)計

　　3.1平臺與移動BOSS的支付協(xié)議

　　該部分的支付協(xié)議中，設(shè)BOSS的監(jiān)聽端口為6666，移動BOSS作為SOCKET服務(wù)端，支付中間平臺作為SOCK-ET客戶端，雙方通過握手報文保持連接，握手間隔1分鐘。數(shù)據(jù)包采用包頭＋包體的格式。

　　(1)包頭格式。

　　包頭為定長包頭，如占40個字節(jié)，包含乎臺代碼、包長、功能碼、加密標(biāo)志、交易時間、業(yè)務(wù)返回碼、序列號和后續(xù)包標(biāo)志等信息。其中，平臺代碼固定填寫“PAY”。功能碼包括注冊申請，注銷申請、用戶鑒權(quán)、話費繳費、退貨接口、充值卡繳費、話費繳費沖正、可劃轉(zhuǎn)余額查詢等8種，每種功能都有相應(yīng)的4位ACSII碼值，如話費繳費為0201。它們的業(yè)務(wù)超時時間都設(shè)定為30秒，即支付平臺發(fā)起請求后超過30秒就認(rèn)為業(yè)務(wù)失敗，加密標(biāo)志中，0為不加密，1為加密。交易過程中，支付平臺發(fā)送交易請求包時，填寫請求時間；BOSS發(fā)送交易應(yīng)答包時，填寫響應(yīng)時間，業(yè)務(wù)返回碼中，應(yīng)答報文100表示成功，其他失敗，請求報文填寫000。序列號是異步連接過程中該條請求信息在整個支付活動中的唯一標(biāo)識，對于后續(xù)包標(biāo)志，只在交易數(shù)據(jù)超過1024字節(jié)時使用，進行分包傳輸，循環(huán)發(fā)送與接受，發(fā)送方除最后一個包的后續(xù)包標(biāo)志置0外，前面所有包的后續(xù)包標(biāo)志置1；接收方循環(huán)接收并發(fā)送應(yīng)答，直至收到的交易包的后續(xù)包標(biāo)志為0時為止，循環(huán)過程結(jié)束，接收方的應(yīng)答包是僅有包頭的空包。

　　(2)包體格式。

　　包體為變長包體，在以上8種功能中，針對不同的功能請求，其請求包與應(yīng)答包包體的格式有所不同，其中，除了可劃轉(zhuǎn)余額查詢功能的應(yīng)答包包體包含用戶可用余額和可劃轉(zhuǎn)余額兩項內(nèi)容外，其余功能的應(yīng)答包包體均為空，另外，可根據(jù)應(yīng)答包包頭的“業(yè)務(wù)返回碼”來判定業(yè)務(wù)是否辦理成功，現(xiàn)以話費繳費(0201)為例加以說明：話費繳費功能的請求包包體包括手機號碼、劃轉(zhuǎn)請求金額、訂單編號等信息，訂單編號不可重復(fù)，其格式為：YYMMDD＋順序增長ID(YYMMDD和ID間補零湊足12字節(jié))，例如：090106000001。所有涉及到金額的地方全部以分為單位，該功能的應(yīng)答包中，應(yīng)答包包頭返回碼為100時，判定業(yè)務(wù)辦理成功；為999時，判定業(yè)務(wù)辦理失敗，為404時，判定業(yè)務(wù)辦理超時。應(yīng)答包包體為空。　　

　　3.2與商戶SP的支付協(xié)議

　　該部分的支付協(xié)議中，設(shè)支付平臺監(jiān)聽端口為9999，網(wǎng)絡(luò)超時時間為60秒。支付平臺作為服務(wù)端，商戶系統(tǒng)作為客戶端，所有交易都由客戶端發(fā)起請求，服務(wù)端應(yīng)答。客戶端啟動后發(fā)送登錄請求報文，在收到服務(wù)端的登錄成功應(yīng)答報文后可以進行話費繳費、沖正、退貨等交易，客戶端退出前發(fā)送注銷請求并在接收到服務(wù)端應(yīng)答后退出，其數(shù)據(jù)包也采用包頭＋包體的格式，其包頭與第一部分支付協(xié)議中的格式相同。包體格式只是在內(nèi)容上有所不同。

中國B2B研究中心


相關(guān)鏈接:
M2M無線移動直連POS系統(tǒng)設(shè)計 2009-07-08
APP Store（應(yīng)用下載商店）模式發(fā)展面臨的困境 2009-07-06
嵌入式語音技術(shù)應(yīng)用 未來將實現(xiàn)爆發(fā)式增長 2009-07-02
未來報警新模式:從短信報警到"3G視頻報警" 2009-07-01
3G時代下國內(nèi)M2M無線通信模塊 2009-06-29