基于B/S的掃碼支付平臺(tái)的設(shè)計(jì)

汪天星 程耕國(guó)

摘 要： 針對(duì)單一的支付方式不能滿足用戶多元化的支付需求，設(shè)計(jì)一個(gè)基于B/S的掃碼支付平臺(tái)。該平臺(tái)通過(guò)采用掃碼支付模式，實(shí)現(xiàn)對(duì)支付寶和微信支付服務(wù)的整合。平臺(tái)由服務(wù)器選型、支付訂單生成和異步回調(diào)處理三個(gè)模塊組成。服務(wù)器選型模塊用于從集群服務(wù)器中選擇性能相對(duì)最佳的服務(wù)器處理整個(gè)掃碼支付流程。支付訂單生成模塊調(diào)用第三方支付下單API生成預(yù)支付訂單。異步回調(diào)處理模塊的功能是接收支付通知和更新數(shù)據(jù)庫(kù)表的數(shù)據(jù)。平臺(tái)采用四項(xiàng)措施降低了支付風(fēng)險(xiǎn)，為用戶提供了既安全又快捷的支付服務(wù)。

關(guān)鍵詞： 支付方式； 支付服務(wù)整合； 服務(wù)器選型； 異步回調(diào)處理； 掃碼支付； 支付平臺(tái)

中圖分類號(hào)： TN820.2?34； TP311 文獻(xiàn)標(biāo)識(shí)碼： A 文章編號(hào)： 1004?373X（2018）22?0049?04

Abstract： As the single payment mode cannot meet users′ diversified payment needs， a scanning?code payment platform based on B/S is designed. On the platform， the integration of Alipay and WeChat payment services is realized by adopting the scanning?code payment mode. The platform is composed of three modules of server model selection， payment order generation， and asynchronous callback processing. The server model selection module is used to select the relatively high?performance server from cluster servers to handle the whole scanning?code payment process. The payment order generation module is used to invoke the third?party payment order API to generate the prepayment order. The functions of the asynchronous callback processing module is to receive payment notifications and update the data in database tables. Four measures are taken for the platform to reduce payment risks， which can provide users with secure， rapid and convenient payment services.

Keywords： payment mode； payment service integration； server model selection； asynchronous callback processing； scanning?code payment； payment platform

0 引 言

隨著互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展，以支付寶為代表的第三方支付方式迅速在中國(guó)普及。第三方支付逐漸取代現(xiàn)金和信用卡支付，成為當(dāng)前中國(guó)最受歡迎的支付方式。然而，中國(guó)消費(fèi)者廣泛分布在線下、PC端和移動(dòng)端，消費(fèi)者的支付需求趨于多元化，支付場(chǎng)景過(guò)于碎片化。任意一種支付方式不足以應(yīng)付所有支付場(chǎng)景和滿足所有支付需求。本平臺(tái)為了滿足消費(fèi)者多元化的支付需求，基于掃碼支付模式整合支付寶和微信支付服務(wù)，為消費(fèi)者提供靈活方便、多渠道的支付服務(wù)[1]。

1 掃碼支付

1.1 支付原理

首先，平臺(tái)服務(wù)器按照第三方支付平臺(tái)（指支付寶和微信）制定的規(guī)則生成二維碼，并將它展示在PC網(wǎng)頁(yè)上。在用戶使用APP客戶端掃描二維碼之后，掃碼信息會(huì)立即被APP發(fā)送給平臺(tái)服務(wù)器，平臺(tái)服務(wù)器則根據(jù)接收到的信息識(shí)別用戶使用的APP是支付寶還是微信。然后，平臺(tái)服務(wù)器會(huì)調(diào)用相應(yīng)的下單API生成預(yù)支付訂單。最后，用戶訪問(wèn)由平臺(tái)生成的支付頁(yè)面，在該頁(yè)面上顯示著訂單詳情，用戶點(diǎn)擊支付頁(yè)面上的“立即繳費(fèi)”按鈕就可以發(fā)起支付。第三方支付服務(wù)器以同步的形式返回支付結(jié)果給APP客戶端，以異步的形式返回支付結(jié)果給平臺(tái)服務(wù)器，具體流程如圖1所示。

1.2 服務(wù)器選型

當(dāng)服務(wù)器的負(fù)載達(dá)到一定程度時(shí)，頁(yè)面加載變得很緩慢，造成非常差的用戶體驗(yàn)[2]。如何在集群服務(wù)器中選擇性能相對(duì)最優(yōu)的服務(wù)器來(lái)處理掃碼支付業(yè)務(wù)流程是當(dāng)前亟待解決的問(wèn)題。在平臺(tái)的所有業(yè)務(wù)邏輯中，只有定時(shí)任務(wù)才會(huì)顯著加大服務(wù)器的負(fù)載。相較而言，其他業(yè)務(wù)邏輯對(duì)服務(wù)器造成的負(fù)載非常小，可以忽略。此外，服務(wù)器的硬件配置也在很大程度上影響著服務(wù)器性能。所以，在選擇高性能服務(wù)器時(shí)主要考慮以下兩類因素：一類是服務(wù)器正在執(zhí)行的定時(shí)任務(wù)的復(fù)雜度；另一類是服務(wù)器的硬件配置。對(duì)于不同復(fù)雜度的定時(shí)任務(wù)分別給予不同的權(quán)值，定時(shí)任務(wù)越復(fù)雜其權(quán)值越大，該服務(wù)器負(fù)載所占的權(quán)值是所有正在執(zhí)行的定時(shí)任務(wù)的權(quán)值總和。不同配置的服務(wù)器也賦予一個(gè)權(quán)值，權(quán)值越大服務(wù)器的硬件配置越好。服務(wù)器的負(fù)載和硬件配置所占的權(quán)值之和越小，表明該服務(wù)器當(dāng)前的性能越佳[3]。

1.3 支付安全

支付領(lǐng)域最棘手的問(wèn)題是安全性問(wèn)題，如何降低支付風(fēng)險(xiǎn)是平臺(tái)十分重要的一個(gè)環(huán)節(jié)[4]。在掃碼支付流程中，可能會(huì)產(chǎn)生支付風(fēng)險(xiǎn)的情況有如下三種：一是信息未設(shè)置有效期；二是信息未加密；三是并發(fā)操作。針對(duì)以上三種情況，平臺(tái)采用四種措施降低支付風(fēng)險(xiǎn)。

1.3.1 有效期設(shè)置

如果程序沒(méi)有為二維碼設(shè)置一個(gè)有效期，則發(fā)生重復(fù)繳費(fèi)情況的概率會(huì)變大。此外，程序設(shè)置的有效期不能太長(zhǎng)，否則就會(huì)失去設(shè)置的意義。相似地，對(duì)于預(yù)支付訂單的訂單號(hào)，程序也設(shè)置了有效期來(lái)降低潛在的支付風(fēng)險(xiǎn)。平臺(tái)程序設(shè)置二維碼的有效期為5 min，當(dāng)用戶在有效期之外掃描二維碼，程序會(huì)提示用戶異常信息。除此之外，平臺(tái)程序還會(huì)在倒計(jì)時(shí)5 min后，關(guān)閉用于展示二維碼的網(wǎng)頁(yè)。

1.3.2 數(shù)據(jù)加密

為了提高數(shù)據(jù)的傳輸安全性，平臺(tái)服務(wù)器與第三方支付服務(wù)器之間互相發(fā)送的信息必須加密。平臺(tái)程序使用MD5算法對(duì)數(shù)據(jù)進(jìn)行加密[5?6]。加密步驟有兩步：第一步，程序?qū)⒃紨?shù)據(jù)中所有的參數(shù)按照參數(shù)名ASCII碼從小到大排序，使用“=”和“&”拼接成URL鍵值對(duì)格式的字符串A（如key1=value1&key2;=value2…）；第二步，程序?qū)⒌谝徊降玫降淖址瓵和商戶密鑰key拼接在一起得到新字符串B，然后程序根據(jù)MD5算法處理字符串B，最后程序?qū)⑻幚斫Y(jié)果全部轉(zhuǎn)換為大寫字符。

當(dāng)前主流的網(wǎng)絡(luò)傳輸協(xié)議有HTTP和HTTPS等。由于HTTP協(xié)議沒(méi)有加密功能， HTTP請(qǐng)求很容易被黑客偽造，因而其傳輸安全性很低[7]。HTTPS協(xié)議在HTTP基礎(chǔ)之上增加了身份驗(yàn)證和加密功能，它的傳輸安全性較高[8]。為了提高程序的安全可靠性，本平臺(tái)所有的核心接口都使用HTTPS協(xié)議。

1.3.3 樂(lè)觀鎖

當(dāng)多個(gè)用戶在同一時(shí)刻繳費(fèi)時(shí)，會(huì)有較大概率發(fā)生重復(fù)支付的情況，平臺(tái)程序通過(guò)使用樂(lè)觀鎖來(lái)避免重復(fù)支付的發(fā)生。樂(lè)觀鎖一般用于解決由并發(fā)操作引起的問(wèn)題[9]，它的核心是數(shù)據(jù)版本version的記錄機(jī)制。當(dāng)用戶訪問(wèn)訂單詳情頁(yè)面時(shí)，程序會(huì)查詢數(shù)據(jù)版本version，并將它記錄下來(lái)。當(dāng)一個(gè)用戶點(diǎn)擊支付頁(yè)面的“立即繳費(fèi)”按鈕時(shí)，程序會(huì)比較當(dāng)前數(shù)據(jù)版本version與之前查詢出的version，如果兩個(gè)version值一致，則當(dāng)前version值加一，用戶可以繼續(xù)支付；否則，用戶無(wú)法支付，提示用戶重試。平臺(tái)程序通過(guò)這套記錄機(jī)制避免了重復(fù)支付情況的發(fā)生，具體實(shí)現(xiàn)流程圖如圖2所示。

1.3.4 唯一索引

在用戶支付成功之后，第三方支付服務(wù)器會(huì)每隔一段時(shí)間發(fā)送一次支付通知來(lái)回調(diào)平臺(tái)接口，支付通知的發(fā)送間隔不固定。有較小的幾率會(huì)發(fā)生重復(fù)的支付通知在極短的時(shí)間內(nèi)多次更新業(yè)務(wù)數(shù)據(jù)的情況。通過(guò)對(duì)訂單號(hào)字段設(shè)置唯一索引，平臺(tái)程序解決了上述并發(fā)問(wèn)題。只要有一次支付通知修改了平臺(tái)的數(shù)據(jù)，程序就往數(shù)據(jù)庫(kù)表新增一條帶有訂單號(hào)的記錄，由于訂單號(hào)已經(jīng)存在數(shù)據(jù)庫(kù)中，其他后續(xù)重復(fù)的支付通知將無(wú)法更新業(yè)務(wù)數(shù)據(jù)。

2 平臺(tái)總體設(shè)計(jì)

平臺(tái)采用B/S架構(gòu)，遵循MVC開(kāi)發(fā)模式[10]。后端使用的框架有Dubbo，Spring和SpringMVC，前端主要采用的技術(shù)是EasyUI。此外，為了提高服務(wù)器的運(yùn)行速度，平臺(tái)搭建了集群服務(wù)器，其總體結(jié)構(gòu)如圖3所示。

2.1 平臺(tái)功能模塊

掃碼支付平臺(tái)主要由服務(wù)器選型、支付訂單生成和異步回調(diào)處理三個(gè)功能模塊組成，具體框圖如圖4所示。

2.2 數(shù)據(jù)庫(kù)設(shè)計(jì)

本平臺(tái)面向于收取小區(qū)物業(yè)費(fèi)，涉及到的表共有11張，分別是小區(qū)表TBAA01、樓棟表TBAA02、單元表TBAA03、樓層表TBAA04、房間表TBAA05、用戶表TBBB01、服務(wù)器表TBCC01、二維碼表TBCC02、物業(yè)費(fèi)賬單表TBDD01、訂單信息表TBDD02和繳費(fèi)記錄表TBDD03。各表之間的關(guān)系如圖5所示。

3 主要功能實(shí)現(xiàn)

3.1 服務(wù)器選型實(shí)現(xiàn)

當(dāng)集群服務(wù)器中任意一臺(tái)服務(wù)器開(kāi)始執(zhí)行定時(shí)任務(wù)時(shí)，程序會(huì)向TBCC01表新增一條記錄，同時(shí)設(shè)置字段JOB_FLAG_的值為0。當(dāng)定時(shí)任務(wù)即將結(jié)束時(shí)，程序會(huì)修改字段JOB_FLAG_的值為1。結(jié)合式（2），程序可以查詢出[Wall]的最小值Wmin。同時(shí)，程序也可以查詢出性能最佳服務(wù)器的IP地址和端口號(hào)，主要代碼如下：

在獲取性能相對(duì)最優(yōu)服務(wù)器的IP地址和端口號(hào)后，新的掃碼支付流程將完全由最優(yōu)服務(wù)器處理。新掃碼支付流程主要指從生成二維碼到處理支付通知整個(gè)階段，如圖1所示。

3.2 數(shù)據(jù)加密實(shí)現(xiàn)

MD5加密的原理是將每個(gè)字符轉(zhuǎn)化為十六進(jìn)制，原始數(shù)據(jù)在使用MD5工具方法加密前，需要轉(zhuǎn)化為URL鍵值對(duì)形式的字符串。數(shù)據(jù)加密的主要代碼如下：

3.3 支付實(shí)現(xiàn)圖

在掃碼支付流程中，只有兩個(gè)頁(yè)面展示給用戶看，它們分別是二維碼頁(yè)面和顯示著訂單詳情的支付頁(yè)面，如圖6所示。

4 結(jié) 語(yǔ)

本文針對(duì)單一支付方式不能夠滿足用戶多元化的支付需求的現(xiàn)狀，設(shè)計(jì)一個(gè)基于B/S的掃碼支付平臺(tái)。該平臺(tái)基于掃碼支付模式，為用戶提供了快捷、安全的支付服務(wù)。平臺(tái)通過(guò)量化服務(wù)器負(fù)載和硬件配置實(shí)現(xiàn)了自動(dòng)獲取性能最優(yōu)的服務(wù)器，從而為用戶提供快捷的服務(wù)。平臺(tái)通過(guò)采用設(shè)置有效期、信息加密、樂(lè)觀鎖、唯一索引等方式降低了支付風(fēng)險(xiǎn)，從而為用戶提供了安全的服務(wù)。

參考文獻(xiàn)

[1] 黃曉芳，周亞建，賴欣，等.基于第三方的安全移動(dòng)支付方案[J].計(jì)算機(jī)工程，2010，36（18）：158?159.

HUANG Xiaofang， ZHOU Yajian， LAI Xin， et al. Security mobile payment scheme based on the third party [J]. Computer engineering， 2010， 36（18）： 158?159.

[2] 孫喬，鄧卜僑，王志強(qiáng)，等.一種基于分布式服務(wù)器集群的可擴(kuò)展負(fù)載均衡策略技術(shù)[J].電信科學(xué)，2017，33（9）：190?196.

SUN Qiao， DENG Buqiao， WANG Zhiqiang， et al. A scalable load balancing strategy based on distributed server cluster [J]. Telecommunications science， 2017， 33（9）： 190?196.

[3] 姜?jiǎng)潘?，楊波，繆志敏，?基于任務(wù)和用戶屬性的工作流任務(wù)分配算法[J].計(jì)算機(jī)仿真，2015，32（12）：222?225.

JIANG Jinsong， YANG Bo， MIAO Zhimin， et al. A workflow task assignment method based on the properties of task and user [J]. Computer simulation， 2015， 32（12）： 222?225.

[4] 劉亞軍.網(wǎng)上支付系統(tǒng)的安全性研究[J].現(xiàn)代電子技術(shù)，2013，36（8）：74?75.

LIU Yajun. Research on security of online payment system [J]. Modern electronics technique， 2013， 36（8）： 74?75.

[5] 譚健，周清雷，斯雪明，等.全流水架構(gòu)MD5算法在擬態(tài)計(jì)算機(jī)上的實(shí)現(xiàn)及改進(jìn)[J].小型微型計(jì)算機(jī)系統(tǒng)，2017，38（6）：1216?1220.

TAN Jian， ZHOU Qinglei， SI Xueming， et al. Implementation and improvement of full?pipeline MD5 algorithm based on mimic computer [J]. Journal of Chinese computer systems， 2017， 38 （6）： 1216?1220.

[6] 洪丹丹，羅軍峰，馮興利，等.基于RSA與MD5簽名的實(shí)名制微門戶設(shè)計(jì)[J].微電子學(xué)與計(jì)算機(jī)，2016，33（9）：36?41.

HONG Dandan， LUO Junfeng， FENG Xingli， et al. Design of a real?name WeChat portal based on RSA and MD5 signature [J]. Microelectronics & computer， 2016， 33（9）： 36?41.

[7] 王鵬，季明，梅強(qiáng)，等.交換式網(wǎng)絡(luò)下HTTP會(huì)話的劫持研究及其對(duì)策[J].計(jì)算機(jī)工程，2007，33（5）：135?137.

WANG Peng， JI Ming， MEI Qiang， et al. HTTP session hijacking on switch LAN and its countermeasures [J]. Computer engineering， 2007， 33（5）： 135?137.

[8] 祝瑞，車敏.基于HTTP協(xié)議的服務(wù)器程序分析[J].現(xiàn)代電子技術(shù)，2012，35（4）：117?119.

ZHU Rui， CHE Min. Analysis of server program based on HTTP protocol [J]. Modern electronics technique， 2012， 35（4）： 117?119.

[9] 郝娉婷，胡亮，姜靜妍，等.基于多管理節(jié)點(diǎn)的樂(lè)觀鎖協(xié)議[J].吉林大學(xué)學(xué)報(bào)（工學(xué)版），2017，47（1）：227?234.

HAO Pingting， HU Liang， JIANG Jingyan， et al. Optimistic lock protocol of multi?managed nodes [J]. Journal of Jilin University （Engineering and technology edition）， 2017， 47（1）： 227?234.

[10] 劉紅霞，陸文迪.改進(jìn)的MVC設(shè)計(jì)模式的研究與應(yīng)用[J].計(jì)算機(jī)工程與科學(xué)，2015，37（9）：1688?1691.

LIU Hongxia， LU Wendi. Research and implementation of an improved MVC design pattern [J]. Computer engineering and science， 2015， 37（9）： 1688?1691.