朱家棟

0 引言

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

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

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

1.1 自動支付項目

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

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

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

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

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

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

圖1 自動出票流程圖

具體說明：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 競價平臺接口方案

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

? 供應商用戶驗證；

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

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

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

2.1 供應商用戶驗證

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

1) 發(fā)送驗證信息

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

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

發(fā)送方式：以POST后臺方式發(fā)送請求，為HTTPS方式。

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

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

參數(shù)說明

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

形如：ReqType=機票編號CheckInfo

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

形如：ReqDate=20090909

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

形如：ReqTime=100910

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

形如：Username=Supplier1

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

形如：Password=ADSAFAFASFASFFFF

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

2.2 獲取待出票的機票編號

2) 發(fā)送請求

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

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

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

具體接口如下

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

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

發(fā)送方式：以POST后臺方式發(fā)送請求。

3) 應答格式

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

2.3 返回機票編號出票結(jié)果

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

具體方案如下

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

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

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

發(fā)送方式：以POST后臺方式發(fā)送請求。

2.4 出票請求

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

具體方案如下

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

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

接受端口號：默認為6180。

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

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

1. 合法請求：0011QUERY_VALID

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

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

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

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

具體方案如下：

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

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

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

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

2) 出票結(jié)果應答

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

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

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

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

2.6 單獨入庫請求

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

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

接受端口號：默認6180。

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

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

2.7 單獨支付請求

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

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

接受端口號：默認為6180。

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

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

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

2.8 異常情況處理

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

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

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

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

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

3、 入庫失敗。

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

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

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

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

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

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

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

2.9 接口安全控制

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

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

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

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

3 結(jié)論

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

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

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

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

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

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