基于WAP的手機(jī)支付中間平臺(tái)設(shè)計(jì)研究

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

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

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

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

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

    平臺(tái)構(gòu)建策略　　

    2.1可擴(kuò)展性策略

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

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

    2.3安全性策略

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

    平臺(tái)支付協(xié)議設(shè)計(jì)

    3.1平臺(tái)與移動(dòng)BOSS的支付協(xié)議 

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

    (1)包頭格式。

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

    (2)包體格式。

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

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

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