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

文章出處：http://xianjuhong.com 作者：方盈芝   人氣： 發(fā)表時間：2011年09月28日

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

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

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

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

    平臺構(gòu)建策略　　

    2.1可擴展性策略

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

    為了提高支付中間平臺的性能，采用異步長連接的方式來實現(xiàn)與商戶SP及移動BOSS之間的連接，如圖3。所謂異步長連接就是客戶端與服務端建立連接后，保持連接狀態(tài)，請求方在沒有收到響應的情況下，可以發(fā)起多個請求，處理方可以并行處理，按任意順序返回給請求方處理結(jié)果。同時，為了提高支付中間平臺在接人商戶SP時的可擴展性，采用分層收發(fā)請求策略。這樣可以為每一個首次建立連接的商戶SP建立一個屬于商戶SP自己專有的發(fā)送隊列及接收隊列，所有的發(fā)送請求首先要加入發(fā)送隊列，這是第一層。第二層是一個所有商戶SP公共的發(fā)送及接收隊列，來存放接收自不同商戶發(fā)送隊列的信息，并統(tǒng)一將請求發(fā)送給移動BOSS。當移動BOSS處理完請求并返回結(jié)果時，返回的信息將首先存放到第二層公共的接收隊列里，接收隊列收到信息會根據(jù)一定的標識策略分發(fā)給所屬商戶SP的接收隊列，然后商戶SP接收隊列再將信息發(fā)送給相應的商戶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地址請求做出相應的安全策略，增加部分鑒權(quán)機制，最大程度地降低支付中間平臺所存在的安全隱患。第二、商戶SP與支付中間平臺之間通過公網(wǎng)進行數(shù)據(jù)傳輸。這樣可增加支付中間平臺的可擴展性，商戶的接人將不受空間和時間的限制。但這樣做存在著許多安全隱患，為了確保數(shù)據(jù)傳輸?shù)恼_性，在傳輸前對某些協(xié)議規(guī)定的信息進行MD5或RSA加密，另外，引入超時處理機制，以確保數(shù)據(jù)傳輸過程中的實時性，避免在整個傳輸過程中因某些不可預測因素而造成的數(shù)據(jù)包丟失。數(shù)據(jù)包在傳遞過程中如果發(fā)生超時，將根據(jù)協(xié)議規(guī)定的超時策略進行處理，第三、支付中間平臺與移動BOSS之間通過專線進行數(shù)據(jù)傳輸，以避免數(shù)據(jù)傳輸過程中遇到的許多安全隱患，如數(shù)據(jù)被惡意截獲、篡改等，同樣，為了確保數(shù)據(jù)傳輸過程的實時性，避免整個傳輸過程中因某些不可預測因素造成的數(shù)據(jù)包丟失，在這里也對數(shù)據(jù)包請求超時做相應的處理。　　

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

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

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

    (1)包頭格式。

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

    (2)包體格式。

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

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

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