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

文章出處：http://hz-huyue.com 作者：方盈芝   人氣： 發表時間：2011年09月28日

    模塊結構及支付流程　　

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

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

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

    平臺構建策略　　

    2.1可擴展性策略

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

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

    2.3安全性策略

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

    平臺支付協議設計

    3.1平臺與移動BOSS的支付協議 

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

    (1)包頭格式。

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

    (2)包體格式。

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

    3.2與商戶SP的支付協議 

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