網站數據挖掘與自動支付方案的研究

朱家棟

0 引言

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

1 客戶端模式支付方案的應用范圍

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

1.1 自動支付項目

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

1.2 平臺模式的具體實施過程

首先，為了實現供應商在競價平臺的自動出票，需要競價平臺至少提供3個接口：A. 供應商用戶驗證接口；

B. 提供訂單查詢接口，可以聯機查詢到指定供應商應出的B2B票訂單信息；

C. 出票確認接口，在出票完成之后，向競價平臺發送確認請求，并提交票號等信息。

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

圖1 自動出票流程圖

具體說明：

1) 通過競價平臺提供的接口，查詢指定供應商的B2B訂單信息。

2) 客戶端根據機票編號大編號調用相關航空公司組件，查詢相應運價信息。

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

4) 政策判斷無誤，向航空公司發送入庫操作，入庫成功，航空公司系統自動生成支付訂單，并返回至客戶端，客戶端然后執行如下操作：

a) 首先判斷針對該航空公司是否已經配置了自動出票功能；

b) 若已經自動出票，則獲取支付操作員號及密碼信息；

c) 根據中間賬戶系統預先定義的自動扣款接口，組織支付報文，其中需要包括航空公司支付表單數據、支付操作員及密碼以及其他標志字段，同時，系統使用匯付的公鑰對數據報文進行加密；

5) 支付創發送支付請求至中間賬戶系統。

6) 中間賬戶系統判斷數據合法性，并完成相關解密及驗簽操作，然后執行自動扣款及航空公司訂單支付。

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

8) 航空公司系統向客戶端返回訂單成功頁面。

9) 客戶端繼續分析后該頁面，并自動完成后續出票操作，并獲得PNR中每張機票的票號信息。

10) 客戶端再次調用競價平臺的出票確認接口，將票號等信息返回至競價平臺系統。

此處，需要特別說明的是：

為實現自動出票，供應商的操作人員仍然需要預先對客戶端進行配置（如圖1A），配置內容主要包括：

a) 自動出票時所用的支付用戶號和密碼信息，這個信息在每次登錄到航空公司網站的同時，登錄自動出票功能；

b) 自動出票銀行的選定（現金賬戶、信用支付）；

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

如圖 1C，為方便供應商了解自動出票狀況，客戶端提供交易處理界面，對于處理的每一筆訂單，將自動顯示在該界面中，同時對于異常的交易，也可發出相關報警。

2 競價平臺接口方案

根據以上流程說明，為C/S結構，客戶端為客戶端，競價平臺為服務器端，客戶端和服務器端之間需要有3個交互接口：

? 供應商用戶驗證；

? 客戶端向競價平臺獲取需要出票的機票編號及相關信息的列表，即獲取帶出票的機票編號；

? 客戶端向競價平臺返回機票編號出票結果列表，即返回機票編號號出票結果。

這3個接口都是客戶端（機票編號客戶端）主動向服務器（競價平臺）發送請求，并獲得服務器（競價平臺）的應答。

2.1 供應商用戶驗證

為了提高安全性，在打開客戶端時，客戶端向競價平臺發送供應商的身份驗證信息，這樣才能綁定客戶端的供應商用戶與競價平臺上的該供應商的出票信息。

1) 發送驗證信息

發送地址：由平臺商指定。

端口號：由平臺商指定。為了提高安全性，平臺需要維護一個端口號。

發送方式：以POST后臺方式發送請求，為HTTPS方式。

發送參數：ReqType、ReqDate、ReqTime、Username、

Password、ChkValue，參數之間用“&”分隔

參數說明

1. ReqType：請求的類型，為固定值機票編號CheckInfo，

形如：ReqType=機票編號CheckInfo

2. ReqDate：發送請求的日期，格式為“YYYYMMDD”，

形如：ReqDate=20090909

3. ReqTime：發送請求的時間，格式為“HHNNSS”，

形如：ReqTime=100910

4. Username：供應商在競價平臺上的用戶名，

形如：Username=Supplier1

5. Password：供應商在競價平臺上的密碼，為 MD5編碼，

形如：Password=ADSAFAFASFASFFFF

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

2.2 獲取待出票的機票編號

2) 發送請求

由客戶端主動向競價平臺發起請求，客戶端請求的機制如下

發送請求－得到結果集－出票－返回出票結果集。

每次請求之間有時間間隔，時間間隔定義：上一次某一航空公司大循環得到機票編號個數為0，間隔10秒；不為0，間隔1秒。

具體接口如下

發送地址：由平臺商指定。

端口號：由平臺商指定。為了提高安全性，平臺需要維護一個端口號。

發送方式：以POST后臺方式發送請求。

3) 應答格式

每次客戶端向競價平臺發送“獲取待出票的機票編號”請求后，競價平臺根據查詢請求中的航空公司、供應商名查詢數據庫，返回未出票的機票編號列表。返回的結果集為XML格式的文件，每次可以返回多個待出票的機票編號，一次最多返回20個機票編號。已經被返回的機票編號，在競價平臺的數據庫中標識為“已被獲取”。

2.3 返回機票編號出票結果

客戶端得到請求的應答，逐筆出票，每一個機票編號完成出票操作后，把出票結果返回給平臺，平臺解析返回的結果集，并且更新平臺中數據庫的機票編號記錄信息。

具體方案如下

1) 發送出票結果

發送地址：由平臺商指定。

端口號：由平臺商指定。為了提高安全性，平臺需要維護一個端口號。

發送方式：以POST后臺方式發送請求。

2.4 出票請求

當平臺上有待出票的PNR號，平臺主動向支付窗發起出票請求，每次請求只包含一個PNR號的出票請求。為了提高安全性，PNR支付窗綁定平臺的IP地址，以及設定端口號，只處理綁定的 IP地址及設定的端口號發送的出票請求。IP地址列表和端口號通過配置文件來維護

具體方案如下

接受方式：接受TCP/IP報文數據。

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

接受端口號：默認為6180。

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

PNR號出票是一個比較復雜的過程，需要兩分鐘左右的時間來完成，所以PNR號的出票結果是通過異步應答的方式來處理，此時接收到出票請求后，返回一個收到請求的標識，即返回這個請求合法或者非法，非法的請求要說明非法的具體的原因

1. 合法請求：0011QUERY_VALID

2. 非法請求：0021QUERY_INVALID錯誤描述。

2.5 返回PNR號出票結果

1) 發送出票結果

支付窗得到出票請求的應答，開始出票操作，完成出票操作后，把出票結果返回給平臺，平臺解析返回的結果集，并且更新平臺中數據庫的PNR記錄信息。

具體方案如下：

發送方式：以HTTP協議。

發送地址：出票請求字段“RetURL”中冒號前的部分。

發送端口號：出票請求字段“RetURL”中冒號后的部分。

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

2) 出票結果應答

平臺接受到支付窗的出票結果，應該向支付窗返回應答，即返回出票結果正確或者不正確，不正確的出票結果要說明具體原因

3. 出票結果正確：PNR號_SUCC

4. 出票結果不正確：PNR號_FAIL + 錯誤描述

對于沒有返回應答的請求，支付窗有一套重發機制，要保證支付窗的出票結果返回到平臺上。

2.6 單獨入庫請求

接受方式：接受TCP/IP報文數據；

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

接受端口號：默認6180。

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

應答：同步返回入庫的結果，前4位指明報文的長度，報文為XML格式。

2.7 單獨支付請求

接受方式：接受TCP/IP報文數據。

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

接受端口號：默認為6180。

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

應答：同步返回支付的結果，前4位指明報文的長度，報文為XML格式。

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

2.8 異常情況處理

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

1、 平臺發出“出票請求”，而支付窗沒有接收到。

處理方法：平臺在一定時間內沒有得到應答，重復發送出票請求。

2、 平臺發出“出票請求”，支付窗給出接收應答，而平臺沒有接收到支付窗的應答。

處理方法：平臺在一定時間內沒有得到應答，重復發送出票請求，支付窗接收新的請求，首先查找本地數據庫，查看這個出票請求是否存在，若不存在插入數據庫；若存在，判斷是否為出票異常狀態（包括“入庫失敗”、“支付失敗”、“出票失敗”等狀態），若是，更新數據庫；否則不作操作。同時都要返回成功的接收應答給平臺。

3、 入庫失敗。

處理方法：支付窗返回出票結果給平臺，平臺根據支付窗返回的入庫錯誤信息修改PNR號，再重新發送出票請求到支付窗，支付窗會根據唯一碼查詢數據庫，并且根據其出票狀態給出正確的操作。

4、 入庫成功，支付失敗。

處理方法：支付窗返回出票結果給平臺，平臺根據支付窗返回的支付錯誤原因修改PNR號，再重新發送出票請求到支付窗，支付窗會根據唯一碼查詢數據庫，并且根據其出票狀態給出正確的操作。

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

處理方法：支付成功后，支付窗會出發出票操作，若出票操作失敗，支付傳會重試5次，直到成功為止；若果5次以后還不成功，支付窗返回出票結果給平臺，平臺根據支付窗返回的出票錯誤原因修改PNR號，再重新發送出票請求到支付窗，支付窗會根據唯一碼查詢數據庫，并且根據其出票狀態給出正確的操作。

6、 支付窗返回出票結果給平臺，但沒有接收到平臺的應答。

處理方法：支付窗返回出票結果給平臺，在規定的時間內沒有接收到平臺的應答，支付窗會連續的重發10次，時間間隔為5秒鐘；如果一直都沒有應答將報警，可以由人工干預，并且可以人工重發。

2.9 接口安全控制

1）供應商賬戶登錄，這樣可以確保某一個供應商只能拿到自己的數據和避免自己的數據泄露。

2）由于客戶端客戶端與競價平臺之間沒有交互任何敏感信息的交互，相對來說安全方面不存在重要的問題，但是我們也要防止模擬發送的數據，我們采取每次的請求中都包含一個驗簽的的字段CheckValue，這個驗簽字段的內容為：

其中，“請求的數據”中都包含日期和時間，即時間戳，供競價平臺的進一步使用；KEY需要客戶端和競價平臺共同維護。

3）平臺只接受特定的端口號的請求。

3 結論

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

[1]中國電子商務協會，第三方電子支付探索與實踐，[M]中國標準出版社，2008.4.1

[2]屈武江，電子商務安全與支付技術，[M]中國人民大學出版社，2006.9.1

[3]電子商務基礎, 陳永東，[M]中國科學技術出版社，2006

[4]Pang-Ning Tan, Michael Steinbach等著，數據挖掘導論，[M]人民郵電出版社，2006

[5]Jiawei Han、Micheline Kamber，數據挖掘：概念與技術，[M]機械工業出版社，2001