网站数据挖掘与自动支付方案的研究

朱家栋

0 引言

目前第三方支付行业，以B/S架构为主的电子支付方案已经为大部分企业和个人所接受。B/S主要的特点就是方便、快捷、对终端的依赖性小。随着第三方支付行业的发展，网络安全、数据加密方面技术的成熟，B/S模式的稳定性和安全性也比以前有了更高的飞跃。相对而言，C/S模式更多的用于一些专业化的内部系统。需要比较统一化的终端，以及相对安全的运行环境。然而，C/S模式的优点在于专业化和集成化，在资源有效的情况下，可以将数据挖掘、数据分析等一系列功能整合在客户端，提供统一化的操作界面给使用者。因而，对于需要高效率的行业来说，是比较有优势的。

1 客户端模式支付方案的应用范围

以客户端为产品的支付方案主要包括这样几种模式，1.纯客户端与网站前台服务器。客户端可以从不同网站上主动获取所需要的数据信息，整合在统一界面上展示给用户，支付的时候，客户端实际上是模拟浏览器发送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