朱家棟

0 引言

目前第三方支付行業(yè)，以B/S架構(gòu)為主的電子支付方案已經(jīng)為大部分企業(yè)和個(gè)人所接受。B/S主要的特點(diǎn)就是方便、快捷、對(duì)終端的依賴性小。隨著第三方支付行業(yè)的發(fā)展，網(wǎng)絡(luò)安全、數(shù)據(jù)加密方面技術(shù)的成熟，B/S模式的穩(wěn)定性和安全性也比以前有了更高的飛躍。相對(duì)而言，C/S模式更多的用于一些專業(yè)化的內(nèi)部系統(tǒng)。需要比較統(tǒng)一化的終端，以及相對(duì)安全的運(yùn)行環(huán)境。然而，C/S模式的優(yōu)點(diǎn)在于專業(yè)化和集成化，在資源有效的情況下，可以將數(shù)據(jù)挖掘、數(shù)據(jù)分析等一系列功能整合在客戶端，提供統(tǒng)一化的操作界面給使用者。因而，對(duì)于需要高效率的行業(yè)來(lái)說(shuō)，是比較有優(yōu)勢(shì)的。

1 客戶端模式支付方案的應(yīng)用范圍

以客戶端為產(chǎn)品的支付方案主要包括這樣幾種模式，1.純客戶端與網(wǎng)站前臺(tái)服務(wù)器?？蛻舳丝梢詮牟煌W(wǎng)站上主動(dòng)獲取所需要的數(shù)據(jù)信息，整合在統(tǒng)一界面上展示給用戶，支付的時(shí)候，客戶端實(shí)際上是模擬瀏覽器發(fā)送Http/Https請(qǐng)求給服務(wù)器。根據(jù)返回的數(shù)據(jù)報(bào)內(nèi)容，進(jìn)行網(wǎng)頁(yè)的跳轉(zhuǎn)與響應(yīng)。為了信息的安全，客戶端不保存任何用戶的數(shù)據(jù)，所有的數(shù)據(jù)在會(huì)話結(jié)束以后自動(dòng)消失。2.局域網(wǎng)內(nèi)部署用于支付中間服務(wù)器，這類方案由客戶端搜集網(wǎng)站數(shù)據(jù)，當(dāng)用戶操作完成以后將交易信息發(fā)送到局域網(wǎng)內(nèi)統(tǒng)一某個(gè)服務(wù)器，再由該服務(wù)器向接收交易請(qǐng)求的服務(wù)器發(fā)送數(shù)據(jù)。這種方案的優(yōu)點(diǎn)在于局域網(wǎng)服務(wù)端可以保存一些歷史數(shù)據(jù)，供單位/商家進(jìn)行交易的追蹤，并且可以為之后的自動(dòng)對(duì)帳提供必要的數(shù)據(jù)。3.一些大規(guī)模的運(yùn)營(yíng)商，有自己的內(nèi)部站點(diǎn)，相當(dāng)于將原來(lái)客戶端收集數(shù)據(jù)的功能和支付組件集成到內(nèi)部站點(diǎn)服務(wù)器，這樣，用戶只要在他們公司自己的站點(diǎn)上操作就可以了。這種方案可以對(duì)內(nèi)和對(duì)外兩方面保護(hù)公司的隱私，并且統(tǒng)一進(jìn)行數(shù)據(jù)的分析和安全管理。缺點(diǎn)是必須要對(duì)特定的公司進(jìn)行定制，沒(méi)有通用性。本文主要研究的是針對(duì)于第三種方案，如何與現(xiàn)存的公司內(nèi)部平臺(tái)制定統(tǒng)一接口，根據(jù)公司運(yùn)作模式和資金鏈流向，提供整套解決方案的架構(gòu)與實(shí)現(xiàn)。

1.1 自動(dòng)支付項(xiàng)目

以航空公司機(jī)票代理業(yè)務(wù)為例，一般消費(fèi)者在網(wǎng)站上定了一張機(jī)票以后，代理人會(huì)到航空公司網(wǎng)站上查詢機(jī)票的價(jià)格，根據(jù)折扣與返點(diǎn)，選取對(duì)自己而言利潤(rùn)率最高的機(jī)票產(chǎn)品。隨著機(jī)票代理行業(yè)的發(fā)展，代理人通過(guò)各種渠道可以獲得更加優(yōu)惠的機(jī)票價(jià)格，所以，一些代理人去向另外的代理提供機(jī)票，這種現(xiàn)象越來(lái)越多的發(fā)生，導(dǎo)致競(jìng)價(jià)平臺(tái)的出現(xiàn)。競(jìng)價(jià)平臺(tái)一般是由一些大的代理或者第三方來(lái)提供的。每個(gè)代理會(huì)將自己比較優(yōu)勢(shì)的機(jī)票發(fā)布在平臺(tái)上供其他代理購(gòu)買。于是，一般代理的運(yùn)作方式是這樣的，接到客戶購(gòu)買機(jī)票的請(qǐng)求以后，去競(jìng)價(jià)平臺(tái)上查詢最佳的機(jī)票種類，根據(jù)該機(jī)票的占位號(hào)，到航空公司網(wǎng)站上進(jìn)行支付。去除代理人付給其他代理人的傭金，以及中間由第三方提供的信用支付的部分，簡(jiǎn)單而言，資金的流向是由機(jī)票購(gòu)買者到代理人再到航空公司。為了提供代理人更加高效，準(zhǔn)確地支付方案，滿足代理人從受理到出票整個(gè)過(guò)程中的自動(dòng)化。除了實(shí)現(xiàn)了代理人客戶端模式，我們可以進(jìn)一步擴(kuò)充客戶端的功能，與當(dāng)前的競(jìng)價(jià)平臺(tái)相結(jié)合，為競(jìng)價(jià)平臺(tái)的供應(yīng)商用戶提供定制化的自動(dòng)出票服務(wù)。平臺(tái)商模式基于代理人客戶端模式，在代理人客戶端模式的基礎(chǔ)上多添加和競(jìng)價(jià)平臺(tái)的接口。這個(gè)功能支持供應(yīng)商在競(jìng)價(jià)平臺(tái)上支付的訂單。

1.2 平臺(tái)模式的具體實(shí)施過(guò)程

首先，為了實(shí)現(xiàn)供應(yīng)商在競(jìng)價(jià)平臺(tái)的自動(dòng)出票，需要競(jìng)價(jià)平臺(tái)至少提供3個(gè)接口：A. 供應(yīng)商用戶驗(yàn)證接口；

B. 提供訂單查詢接口，可以聯(lián)機(jī)查詢到指定供應(yīng)商應(yīng)出的B2B票訂單信息；

C. 出票確認(rèn)接口，在出票完成之后，向競(jìng)價(jià)平臺(tái)發(fā)送確認(rèn)請(qǐng)求，并提交票號(hào)等信息。

另外，該模式下的客戶端仍然運(yùn)行在供應(yīng)商某臺(tái)或多臺(tái)PC機(jī)上，而且在打開(kāi)客戶端之后，需要由代理人的操作人員分別登錄到各航空公司系統(tǒng)中，并由客戶端保持在線狀態(tài)。然后，客戶端便可執(zhí)行如下所示的自動(dòng)出票流程，如圖1所示：

圖1 自動(dòng)出票流程圖

具體說(shuō)明：

1) 通過(guò)競(jìng)價(jià)平臺(tái)提供的接口，查詢指定供應(yīng)商的B2B訂單信息。

2) 客戶端根據(jù)機(jī)票編號(hào)大編號(hào)調(diào)用相關(guān)航空公司組件，查詢相應(yīng)運(yùn)價(jià)信息。

3) 根據(jù)代理人的預(yù)先配置，判斷航空公司的政策信息是否滿足要求，只有滿足要求的訂單才能繼續(xù)下一步操作。

4) 政策判斷無(wú)誤，向航空公司發(fā)送入庫(kù)操作，入庫(kù)成功，航空公司系統(tǒng)自動(dòng)生成支付訂單，并返回至客戶端，客戶端然后執(zhí)行如下操作：

a) 首先判斷針對(duì)該航空公司是否已經(jīng)配置了自動(dòng)出票功能；

b) 若已經(jīng)自動(dòng)出票，則獲取支付操作員號(hào)及密碼信息；

c) 根據(jù)中間賬戶系統(tǒng)預(yù)先定義的自動(dòng)扣款接口，組織支付報(bào)文，其中需要包括航空公司支付表單數(shù)據(jù)、支付操作員及密碼以及其他標(biāo)志字段，同時(shí)，系統(tǒng)使用匯付的公鑰對(duì)數(shù)據(jù)報(bào)文進(jìn)行加密；

5) 支付創(chuàng)發(fā)送支付請(qǐng)求至中間賬戶系統(tǒng)。

6) 中間賬戶系統(tǒng)判斷數(shù)據(jù)合法性，并完成相關(guān)解密及驗(yàn)簽操作，然后執(zhí)行自動(dòng)扣款及航空公司訂單支付。

7) 若自動(dòng)扣款失敗，中間賬戶系統(tǒng)向客戶端返回失敗原因；若支付成功，向航空公司返回支付結(jié)果。

8) 航空公司系統(tǒng)向客戶端返回訂單成功頁(yè)面。

9) 客戶端繼續(xù)分析后該頁(yè)面，并自動(dòng)完成后續(xù)出票操作，并獲得PNR中每張機(jī)票的票號(hào)信息。

10) 客戶端再次調(diào)用競(jìng)價(jià)平臺(tái)的出票確認(rèn)接口，將票號(hào)等信息返回至競(jìng)價(jià)平臺(tái)系統(tǒng)。

此處，需要特別說(shuō)明的是：

為實(shí)現(xiàn)自動(dòng)出票，供應(yīng)商的操作人員仍然需要預(yù)先對(duì)客戶端進(jìn)行配置（如圖1A），配置內(nèi)容主要包括：

a) 自動(dòng)出票時(shí)所用的支付用戶號(hào)和密碼信息，這個(gè)信息在每次登錄到航空公司網(wǎng)站的同時(shí)，登錄自動(dòng)出票功能；

b) 自動(dòng)出票銀行的選定（現(xiàn)金賬戶、信用支付）；

c) 每家航空公司支持的最低政策信息。

如圖 1C，為方便供應(yīng)商了解自動(dòng)出票狀況，客戶端提供交易處理界面，對(duì)于處理的每一筆訂單，將自動(dòng)顯示在該界面中，同時(shí)對(duì)于異常的交易，也可發(fā)出相關(guān)報(bào)警。

2 競(jìng)價(jià)平臺(tái)接口方案

根據(jù)以上流程說(shuō)明，為C/S結(jié)構(gòu)，客戶端為客戶端，競(jìng)價(jià)平臺(tái)為服務(wù)器端，客戶端和服務(wù)器端之間需要有3個(gè)交互接口：

? 供應(yīng)商用戶驗(yàn)證；

? 客戶端向競(jìng)價(jià)平臺(tái)獲取需要出票的機(jī)票編號(hào)及相關(guān)信息的列表，即獲取帶出票的機(jī)票編號(hào)；

? 客戶端向競(jìng)價(jià)平臺(tái)返回機(jī)票編號(hào)出票結(jié)果列表，即返回機(jī)票編號(hào)號(hào)出票結(jié)果。

這3個(gè)接口都是客戶端（機(jī)票編號(hào)客戶端）主動(dòng)向服務(wù)器（競(jìng)價(jià)平臺(tái)）發(fā)送請(qǐng)求，并獲得服務(wù)器（競(jìng)價(jià)平臺(tái)）的應(yīng)答。

2.1 供應(yīng)商用戶驗(yàn)證

為了提高安全性，在打開(kāi)客戶端時(shí)，客戶端向競(jìng)價(jià)平臺(tái)發(fā)送供應(yīng)商的身份驗(yàn)證信息，這樣才能綁定客戶端的供應(yīng)商用戶與競(jìng)價(jià)平臺(tái)上的該供應(yīng)商的出票信息。

1) 發(fā)送驗(yàn)證信息

發(fā)送地址：由平臺(tái)商指定。

端口號(hào)：由平臺(tái)商指定。為了提高安全性，平臺(tái)需要維護(hù)一個(gè)端口號(hào)。

發(fā)送方式：以POST后臺(tái)方式發(fā)送請(qǐng)求，為HTTPS方式。

發(fā)送參數(shù)：ReqType、ReqDate、ReqTime、Username、

Password、ChkValue，參數(shù)之間用“&”分隔

參數(shù)說(shuō)明

1. ReqType：請(qǐng)求的類型，為固定值機(jī)票編號(hào)CheckInfo，

形如：ReqType=機(jī)票編號(hào)CheckInfo

2. ReqDate：發(fā)送請(qǐng)求的日期，格式為“YYYYMMDD”，

形如：ReqDate=20090909

3. ReqTime：發(fā)送請(qǐng)求的時(shí)間，格式為“HHNNSS”，

形如：ReqTime=100910

4. Username：供應(yīng)商在競(jìng)價(jià)平臺(tái)上的用戶名，

形如：Username=Supplier1

5. Password：供應(yīng)商在競(jìng)價(jià)平臺(tái)上的密碼，為 MD5編碼，

形如：Password=ADSAFAFASFASFFFF

6. ChkValue：驗(yàn)證碼，內(nèi)容為指定的 KEY以及以上所有鍵值相拼接，并用MD5算法編碼。

2.2 獲取待出票的機(jī)票編號(hào)

2) 發(fā)送請(qǐng)求

由客戶端主動(dòng)向競(jìng)價(jià)平臺(tái)發(fā)起請(qǐng)求，客戶端請(qǐng)求的機(jī)制如下

發(fā)送請(qǐng)求－得到結(jié)果集－出票－返回出票結(jié)果集。

每次請(qǐng)求之間有時(shí)間間隔，時(shí)間間隔定義：上一次某一航空公司大循環(huán)得到機(jī)票編號(hào)個(gè)數(shù)為0，間隔10秒；不為0，間隔1秒。

具體接口如下

發(fā)送地址：由平臺(tái)商指定。

端口號(hào)：由平臺(tái)商指定。為了提高安全性，平臺(tái)需要維護(hù)一個(gè)端口號(hào)。

發(fā)送方式：以POST后臺(tái)方式發(fā)送請(qǐng)求。

3) 應(yīng)答格式

每次客戶端向競(jìng)價(jià)平臺(tái)發(fā)送“獲取待出票的機(jī)票編號(hào)”請(qǐng)求后，競(jìng)價(jià)平臺(tái)根據(jù)查詢請(qǐng)求中的航空公司、供應(yīng)商名查詢數(shù)據(jù)庫(kù)，返回未出票的機(jī)票編號(hào)列表。返回的結(jié)果集為XML格式的文件，每次可以返回多個(gè)待出票的機(jī)票編號(hào)，一次最多返回20個(gè)機(jī)票編號(hào)。已經(jīng)被返回的機(jī)票編號(hào)，在競(jìng)價(jià)平臺(tái)的數(shù)據(jù)庫(kù)中標(biāo)識(shí)為“已被獲取”。

2.3 返回機(jī)票編號(hào)出票結(jié)果

客戶端得到請(qǐng)求的應(yīng)答，逐筆出票，每一個(gè)機(jī)票編號(hào)完成出票操作后，把出票結(jié)果返回給平臺(tái)，平臺(tái)解析返回的結(jié)果集，并且更新平臺(tái)中數(shù)據(jù)庫(kù)的機(jī)票編號(hào)記錄信息。

具體方案如下

1) 發(fā)送出票結(jié)果

發(fā)送地址：由平臺(tái)商指定。

端口號(hào)：由平臺(tái)商指定。為了提高安全性，平臺(tái)需要維護(hù)一個(gè)端口號(hào)。

發(fā)送方式：以POST后臺(tái)方式發(fā)送請(qǐng)求。

2.4 出票請(qǐng)求

當(dāng)平臺(tái)上有待出票的PNR號(hào)，平臺(tái)主動(dòng)向支付窗發(fā)起出票請(qǐng)求，每次請(qǐng)求只包含一個(gè)PNR號(hào)的出票請(qǐng)求。為了提高安全性，PNR支付窗綁定平臺(tái)的IP地址，以及設(shè)定端口號(hào)，只處理綁定的 IP地址及設(shè)定的端口號(hào)發(fā)送的出票請(qǐng)求。IP地址列表和端口號(hào)通過(guò)配置文件來(lái)維護(hù)

具體方案如下

接受方式：接受TCP/IP報(bào)文數(shù)據(jù)。

接受地址：支付窗出票服務(wù)器的IP地址。

接受端口號(hào)：默認(rèn)為6180。

報(bào)文格式：前4位指明報(bào)文的長(zhǎng)度，即指明后面要發(fā)送報(bào)文的長(zhǎng)度，比如報(bào)文的長(zhǎng)度為 60，那么前 4位為“0060”。后面的報(bào)文參數(shù)，按照以下順序，參數(shù)之間用“&”分隔。其中未表明可選的參數(shù)，都是為必須的參數(shù)

PNR號(hào)出票是一個(gè)比較復(fù)雜的過(guò)程，需要兩分鐘左右的時(shí)間來(lái)完成，所以PNR號(hào)的出票結(jié)果是通過(guò)異步應(yīng)答的方式來(lái)處理，此時(shí)接收到出票請(qǐng)求后，返回一個(gè)收到請(qǐng)求的標(biāo)識(shí)，即返回這個(gè)請(qǐng)求合法或者非法，非法的請(qǐng)求要說(shuō)明非法的具體的原因

1. 合法請(qǐng)求：0011QUERY_VALID

2. 非法請(qǐng)求：0021QUERY_INVALID錯(cuò)誤描述。

2.5 返回PNR號(hào)出票結(jié)果

1) 發(fā)送出票結(jié)果

支付窗得到出票請(qǐng)求的應(yīng)答，開(kāi)始出票操作，完成出票操作后，把出票結(jié)果返回給平臺(tái)，平臺(tái)解析返回的結(jié)果集，并且更新平臺(tái)中數(shù)據(jù)庫(kù)的PNR記錄信息。

具體方案如下：

發(fā)送方式：以HTTP協(xié)議。

發(fā)送地址：出票請(qǐng)求字段“RetURL”中冒號(hào)前的部分。

發(fā)送端口號(hào)：出票請(qǐng)求字段“RetURL”中冒號(hào)后的部分。

參數(shù)格式：按照以下順序，參數(shù)之間用“&”分隔。其中未表明可選的參數(shù)，都是為必須的參數(shù)。

2) 出票結(jié)果應(yīng)答

平臺(tái)接受到支付窗的出票結(jié)果，應(yīng)該向支付窗返回應(yīng)答，即返回出票結(jié)果正確或者不正確，不正確的出票結(jié)果要說(shuō)明具體原因

3. 出票結(jié)果正確：PNR號(hào)_SUCC

4. 出票結(jié)果不正確：PNR號(hào)_FAIL + 錯(cuò)誤描述

對(duì)于沒(méi)有返回應(yīng)答的請(qǐng)求，支付窗有一套重發(fā)機(jī)制，要保證支付窗的出票結(jié)果返回到平臺(tái)上。

2.6 單獨(dú)入庫(kù)請(qǐng)求

接受方式：接受TCP/IP報(bào)文數(shù)據(jù)；

接受地址：支付窗出票服務(wù)器的IP地址；

接受端口號(hào)：默認(rèn)6180。

報(bào)文格式：前4位指明報(bào)文的長(zhǎng)度，即指明后面要發(fā)送報(bào)文的長(zhǎng)度，比如報(bào)文的長(zhǎng)度為60，那么前4位為“0060”。后面的報(bào)文參數(shù)，按照以下順序，參數(shù)之間用“&”分隔。其中未表明可選的參數(shù)，都是為必須的參數(shù)

應(yīng)答：同步返回入庫(kù)的結(jié)果，前4位指明報(bào)文的長(zhǎng)度，報(bào)文為XML格式。

2.7 單獨(dú)支付請(qǐng)求

接受方式：接受TCP/IP報(bào)文數(shù)據(jù)。

接受地址：支付窗出票服務(wù)器的IP地址。

接受端口號(hào)：默認(rèn)為6180。

報(bào)文格式：前4位指明報(bào)文的長(zhǎng)度，即指明后面要發(fā)送報(bào)文的長(zhǎng)度，比如報(bào)文的長(zhǎng)度為60，那么前4位為“0060”。后面的報(bào)文參數(shù)，按照以下順序，參數(shù)之間用“&”分隔。其中未表明可選的參數(shù)，都是為必須的參數(shù)

應(yīng)答：同步返回支付的結(jié)果，前4位指明報(bào)文的長(zhǎng)度，報(bào)文為XML格式。

Respone 為“000000”表示成功查詢；非“000000”表示查詢失敗，message中顯示失敗原因。

2.8 異常情況處理

出票過(guò)程中需要處理的異常情況有：

1、 平臺(tái)發(fā)出“出票請(qǐng)求”，而支付窗沒(méi)有接收到。

處理方法：平臺(tái)在一定時(shí)間內(nèi)沒(méi)有得到應(yīng)答，重復(fù)發(fā)送出票請(qǐng)求。

2、 平臺(tái)發(fā)出“出票請(qǐng)求”，支付窗給出接收應(yīng)答，而平臺(tái)沒(méi)有接收到支付窗的應(yīng)答。

處理方法：平臺(tái)在一定時(shí)間內(nèi)沒(méi)有得到應(yīng)答，重復(fù)發(fā)送出票請(qǐng)求，支付窗接收新的請(qǐng)求，首先查找本地?cái)?shù)據(jù)庫(kù)，查看這個(gè)出票請(qǐng)求是否存在，若不存在插入數(shù)據(jù)庫(kù)；若存在，判斷是否為出票異常狀態(tài)（包括“入庫(kù)失敗”、“支付失敗”、“出票失敗”等狀態(tài)），若是，更新數(shù)據(jù)庫(kù)；否則不作操作。同時(shí)都要返回成功的接收應(yīng)答給平臺(tái)。

3、 入庫(kù)失敗。

處理方法：支付窗返回出票結(jié)果給平臺(tái)，平臺(tái)根據(jù)支付窗返回的入庫(kù)錯(cuò)誤信息修改PNR號(hào)，再重新發(fā)送出票請(qǐng)求到支付窗，支付窗會(huì)根據(jù)唯一碼查詢數(shù)據(jù)庫(kù)，并且根據(jù)其出票狀態(tài)給出正確的操作。

4、 入庫(kù)成功，支付失敗。

處理方法：支付窗返回出票結(jié)果給平臺(tái)，平臺(tái)根據(jù)支付窗返回的支付錯(cuò)誤原因修改PNR號(hào)，再重新發(fā)送出票請(qǐng)求到支付窗，支付窗會(huì)根據(jù)唯一碼查詢數(shù)據(jù)庫(kù)，并且根據(jù)其出票狀態(tài)給出正確的操作。

5、 支付成功，出票失敗。

處理方法：支付成功后，支付窗會(huì)出發(fā)出票操作，若出票操作失敗，支付傳會(huì)重試5次，直到成功為止；若果5次以后還不成功，支付窗返回出票結(jié)果給平臺(tái)，平臺(tái)根據(jù)支付窗返回的出票錯(cuò)誤原因修改PNR號(hào)，再重新發(fā)送出票請(qǐng)求到支付窗，支付窗會(huì)根據(jù)唯一碼查詢數(shù)據(jù)庫(kù)，并且根據(jù)其出票狀態(tài)給出正確的操作。

6、 支付窗返回出票結(jié)果給平臺(tái)，但沒(méi)有接收到平臺(tái)的應(yīng)答。

處理方法：支付窗返回出票結(jié)果給平臺(tái)，在規(guī)定的時(shí)間內(nèi)沒(méi)有接收到平臺(tái)的應(yīng)答，支付窗會(huì)連續(xù)的重發(fā)10次，時(shí)間間隔為5秒鐘；如果一直都沒(méi)有應(yīng)答將報(bào)警，可以由人工干預(yù)，并且可以人工重發(fā)。

2.9 接口安全控制

1）供應(yīng)商賬戶登錄，這樣可以確保某一個(gè)供應(yīng)商只能拿到自己的數(shù)據(jù)和避免自己的數(shù)據(jù)泄露。

2）由于客戶端客戶端與競(jìng)價(jià)平臺(tái)之間沒(méi)有交互任何敏感信息的交互，相對(duì)來(lái)說(shuō)安全方面不存在重要的問(wèn)題，但是我們也要防止模擬發(fā)送的數(shù)據(jù)，我們采取每次的請(qǐng)求中都包含一個(gè)驗(yàn)簽的的字段CheckValue，這個(gè)驗(yàn)簽字段的內(nèi)容為：

其中，“請(qǐng)求的數(shù)據(jù)”中都包含日期和時(shí)間，即時(shí)間戳，供競(jìng)價(jià)平臺(tái)的進(jìn)一步使用；KEY需要客戶端和競(jìng)價(jià)平臺(tái)共同維護(hù)。

3）平臺(tái)只接受特定的端口號(hào)的請(qǐng)求。

3 結(jié)論

一個(gè)好的支付方案，除了本身設(shè)計(jì)的完整，用戶體驗(yàn)良好，還需要考慮方案本身推廣是否容易。C/S模式的支付方案在用戶需求定制化，產(chǎn)品功能多樣化有明顯的優(yōu)勢(shì),并且可以通過(guò)升級(jí),補(bǔ)丁等方式整合新的功能，提供更多的服務(wù)。另一方面，由于客戶端與服務(wù)器之間報(bào)文，協(xié)議的私密性，使支付方案的可靠性有明顯的優(yōu)勢(shì)。當(dāng)然這種方案也有一定的劣勢(shì)，技術(shù)上需要投入更多的研究，更多的人力維護(hù)成本，以及客戶端在不同操作系統(tǒng)上的可移植性等都是需要考慮的問(wèn)題，公司應(yīng)根據(jù)自身業(yè)務(wù)特性，研發(fā)條件等實(shí)際情況，選擇比較合理的方案。

[1]中國(guó)電子商務(wù)協(xié)會(huì)，第三方電子支付探索與實(shí)踐，[M]中國(guó)標(biāo)準(zhǔn)出版社，2008.4.1

[2]屈武江，電子商務(wù)安全與支付技術(shù)，[M]中國(guó)人民大學(xué)出版社，2006.9.1

[3]電子商務(wù)基礎(chǔ), 陳永東，[M]中國(guó)科學(xué)技術(shù)出版社，2006

[4]Pang-Ning Tan, Michael Steinbach等著，數(shù)據(jù)挖掘?qū)д?，[M]人民郵電出版社，2006

[5]Jiawei Han、Micheline Kamber，數(shù)據(jù)挖掘：概念與技術(shù)，[M]機(jī)械工業(yè)出版社，2001