CN101388096A - 一种多平台的数据标准化处理方法及系统 - Google Patents

Abstract

本发明公开了一种多平台的数据标准化处理方法，包括：第一交互平台根据用户的交互请求提取请求参数，并发送至第二交互平台；所述第二交互平台按照预置格式封装成订单信息，并记录所述订单信息唯一的订单标识；如果所述订单信息封装成功，则通知所述第一交互平台调整其内部交互规则，并判断是否满足交互要求；如果满足，则通知所述第二交互平台基于所述订单信息生成支付信息；第二交互平台接收用户提交的支付请求，并连接第三交互平台，由所述第三交互平台基于所述支付信息生成交易信息。本发明通过对数据交互规则的标准化处理，可以满足在不同交易平台下交易订单的生成，并且可以有效降低买家用户进行网上交易的复杂性。

Description

一种多平台的数据标准化处理方法及系统

技术领域

本发明涉及基于网络的联机数据交互领域，特别是涉及一种多平台的数据标准化处理方法、一种多平台的数据标准化处理系统以及一种标准化处理平台。

背景技术

近年来，电子商务逐渐成为互联网经济发展的主要潮流，依托于互联网等信息技术的电子商务应用，目前在全世界范围内以惊人的速度普及与发展。事实上，电子商务正逐渐成为整个社会经济活动中的一个越来越重要的组成部分。现有的网上交易大多属于多用户单交易平台联机数据交互的范畴，即由客户端处理数据的输入输出和基本预处理，服务器进行具体的数据处理，客户端和服务器之间进行数据的交互需要通过交易平台实现。目前，现有的交易平台通常是基于B2C(Business ToCustomer)模式的网络平台，具体而言，B2C是电子商务按交易对象分类中的一种，即表示商业机构对消费者的电子商务。这种形式的电子商务一般以网络零售业为主，主要借助于Internet开展在线销售活动。B2C即企业通过互联网为消费者提供一个新型的购物环境——网上商店，消费者通过网络在网上购物、在网上支付。采用这种模式可以节省客户和企业的时间和空间，大大提高交易效率。

例如，基于现有的B2C交易平台进行网上购物的过程通常包括：

A1、买方用户访问A购物网站，向A购物网站提交购买订单；

A2、A购物网站确认该订单；

A3、买方用户在线下或通过网银完成支付。

或者，

B1、买方用户访问B购物网站，向B购物网站提交购买订单；

B2、B购物网站确认该订单；

B3、买方用户在线下或通过网银完成支付。

显然，由于A购物网站与B购物网站是不同的交易平台，则相应生成的订单信息及交易规则等也有所不同，那么，用户在不同的交易平台下，则只能分别按照其相应的交易规则等进行操作，对于用户而言，则需要多次重复操作才可能在不同的交易平台下完成多次购物操作。例如，在资金控制环节，用户需要针对不同的交易平台分别提交多次支付，无法实现与传统收银台相似的统一开票、统一缴款的操作，操作复杂，用户体验较差。

总之，随着电子商务的飞速发展，迫切需要发展出一种操作简单、用户体验较好的多平台的数据标准化处理方法及系统。

发明内容

本发明所要解决的技术问题是提供一种多平台的数据标准化处理方法，以满足不同交易平台中各类交互订单数据的标准化处理，以解决现有技术中用户操作复杂，体验较差的问题。

本发明的另一个目的是将上述方法应用于实际中，提供一种保基于多平台的数据标准化处理系统以及一种标准化处理平台，用以保证上述方法的实现和应用。

为解决上述技术问题，本发明的实施例提供了一种多平台的数据标准化处理方法，所述数据处理涉及第一交互平台、第二交互平台及第三交互平台，所述方法包括：

第一交互平台根据用户的交互请求提取请求参数，并发送至第二交互平台；

所述第二交互平台按照预置格式将所述请求参数封装成订单信息，并记录所述订单信息唯一的订单标识；

如果所述订单信息封装成功，则通知所述第一交互平台根据所述请求参数调整其内部交互规则，并判断是否满足交互要求；

如果满足，则通知所述第二交互平台根据所述订单标识查找对应的订单信息，并基于所述订单信息生成支付信息；

第二交互平台接收用户提交的支付请求、并连接第三交互平台，由所述第三交互平台基于所述支付信息生成交易信息。

优选的是，所述第一交互平台为交易平台，第二交互平台为标准化处理平台，第三交互平台为支付平台；所述请求参数包括买方ID、卖方ID、商品名称、商品单价和购买数量。

优选的是，所述交易平台通过以下步骤调整其内部交互规则：

获取所述商品名称对应的库存数量；

从所述库存数量中减去所述购买数量，更新所述库存数量。

优选的是，所述交易平台通过以下步骤判断是否满足交互要求：

判断所述更新后的库存数量是否大于或等于0，如果是，则确定满足交互要求。

优选的是，所述的方法，还包括：

如果所述更新后的库存数量小于0，则向客户端返回交易失败信息。

优选的是，所述的方法，还包括：

在客户端展示所述支付信息。

优选的是，所述第一交互平台为一个或多个。

优选的是，所述的方法，还包括：

所述第一交互平台对所述请求参数进行签名；

所述第二交互平台使用相应的公钥进行校验。

本发明的实施例还提供了一种多平台的数据标准化处理系统，包括：

第一交互平台，包括提取单元、通讯单元和处理单元，所述提取单元用于根据用户的交互请求提取请求参数；所述通讯单元用于与第二交互平台连接进行通讯；所述处理单元用于根据所述请求参数调整其内部交互规则，并判断是否满足交互要求；

第二交互平台，包括转换单元、记录单元、通知单元、生成单元和接口单元，所述转换单元用于按照预置格式将所述请求参数封装成订单信息；所述记录单元用于记录所述订单信息唯一的订单标识；所述通知单元用于向第一交互平台和第三交互平台发送通知信息；所述生成单元用于根据所述订单标识查找对应的订单信息，并基于所述订单信息生成支付信息；所述接口单元用于接收用户提交的支付请求、并连接第三交互平台；

第三交互平台，包括创建单元，用于基于所述支付信息生成交易信息。

优选的是，所述第一交互平台为交易平台，第二交互平台为标准化处理平台，第三交互平台为支付平台；所述请求参数包括买方ID、卖方ID、商品名称、商品单价和购买数量。

优选的是，所述第一交互平台为一个或多个。

优选的是，所述第一交互平台还包括签名加密单元，用于对所述请求参数进行签名；所述第二交互平台还包括校验单元，用于使用相应的公钥进行校验。

本发明的实施例还提供了一种标准化处理平台，所述标准化处理平台连接交易平台和支付平台，所述标准化处理平台包括：

转换单元，用于按照预置格式将所述请求参数封装成订单信息；

记录单元，用于记录所述订单信息唯一的订单标识；

通知单元，用于向交易平台和支付平台发送通知信息；

生成单元，用于根据所述订单标识查找对应的订单信息，并基于所述订单信息生成支付信息；

所述接口单元，用于接收用户提交的支付请求、并连接第三交互平台。

与现有技术相比，本发明具有以下优点：

首先，本发明通过在第一交互平台与第三交互平台之间设置第二交互平台，用以对在第一交互平台与第三交互平台中传输的数据进行标准化处理，即对于不同交易平台数据处理的一致性处理，从而简化用户在不同商业交易平台上的交易操作，使用户获得更好体验。

其次，本发明采用签名校验机制，对参数传递进行签名，并采用相应的公钥进行校验，从而保证传输过程中数据的安全性以及数据的稳定性。

再者，本发明采用通知机制在所述第一、第二和第三交互平台之间进行通讯，从而保证处理过程的有效性及安全性；

最后，本发明对于服务提供商来说，技术实现简单，无技术障碍，无特殊保密算法，成本和风险较低。

附图说明

图1是本发明的一种多平台的数据标准化处理方法实施例的流程图；

图2是应用图1所示的方法实施例进行多平台数据标准化处理的流程图；

图3是本发明的一种多平台的数据标准化处理系统实施例的结构框图；

图4是应用图3所示的优选系统实施例进行多平台数据标准化处理的流程图；

图5是本发明的一种标准化处理平台实施例的结构框图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

本发明的核心构思之一在于，在现有的网上交互平台的基础上，引入“前置机”的概念，采用一种接受外部请求的接口及主动通知外部系统的接口，将不同语言版本，数据格式转化为能被“前置机”识别的标准化数据格式，从而简化用户的网上交易操作。具体而言，就是在现有交易平台与支付平台的基础上，设置连接一个或多个交易平台以及支付平台的标准化处理平台，用以对所述一个或多个交易平台的交互数据进行标准化处理，以及，采用所述标准化数据与支付平台进行数据交互，以简化用户在不同商业交易平台上的交易操作，使用户获得更好体验。

参考图1，示出了本发明的一种多平台的数据标准化处理方法实施例的流程图，所述数据处理涉及第一交互平台、第二交互平台及第三交互平台，所述方法实施例具体可以包括以下步骤：

步骤101、第一交互平台根据用户的交互请求提取请求参数，并发送至第二交互平台；

步骤102、所述第二交互平台按照预置格式将所述请求参数封装成订单信息，并记录所述订单信息唯一的订单标识；

步骤103、如果所述订单信息封装成功，则通知所述第一交互平台根据所述请求参数调整其内部交互规则，并判断是否满足交互要求；

步骤104、如果满足，则通知所述第二交互平台根据所述订单标识查找对应的订单信息，并基于所述订单信息生成支付信息；

步骤105、第二交互平台接收用户提交的支付请求，并连接第三交互平台，由所述第三交互平台基于所述支付信息生成交易信息。

在实际中，所述第一交互平台可以为一个或多个，为便于用户在众多网上交易平台的操作，在本实施例中，主要适用于多个第一交互平台的情形。

为了确保数据传输过程中的数据真实性和完整性，在本实施例中，还可以包括以下步骤：

所述第一交互平台对所述请求参数进行签名；

所述第二交互平台使用相应的公钥进行校验。

可以理解的是，上述步骤为一种采用非对称加密的公钥体系来进行加密的方法。具体而言，非对称式加密的加密和解密所使用的不是同一个密钥，通常需要两个密钥：公钥(public key)和私钥(private key)。公钥与私钥是一对，私钥由加密方保存，公钥向所有用户公开，这种公开公钥的方式解决了密钥交换过程中的安全问题。如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。当加密方使用自己的私钥进行数据加密，相当于在数据上做数字签名，解密方用公钥解密数据，由于私钥只有加密方才有，如果解密方能够正常解密，则表明数据一定来自加密方，加密方不能否认，并且保证了数据并非假冒和没有在传输过程中被修改。这种方式比对称加密算法的具有更好安全性。

为使本领域技术人员更好地理解本发明，以下以在实际中的多平台具体交互过程为例详细说明本发明。

参考图2，示出了应用图1所示的方法实施例进行多平台数据标准化处理的流程图，具体可以包括以下步骤：

步骤201、交易平台根据用户的交易请求提取交易请求参数，并发送至标准化处理平台；

网上交易所需的基本要素包括：买方用户与卖方用户的信息、商品信息、商品单价以及买方的购买数量，因而，所述交易请求参数可以包括买方ID、卖方ID、商品名称、商品单价和购买数量，当然，本领域技术人员根据实际情况具体另外设置任一种请求参数都是可行的，例如，交易模式、返回地址URL或商品地址URL等，本发明对此不作限制。

为了确保数据传输过程中的数据真实性和完整性，还可以在本例中应用签名检验机制，即交易平台对交易请求参数进行签名后再发送至标准化处理平台，相应地，标准化处理平台在收到所述参数时，则采用交易平台提供的公钥进行校验，从而有效保证数据传输的安全性与稳定性。

在实际中，一种对所述请求参数加密的方法为：根据用户在客户端发起的HTTP请求，将请求中传递的所有参数(除sign和sign_type以外的参数)按照参数名称字符升序串联(如：p1＝v1&p2＝v2&p3＝v3)，以构成待签名数据。然后，按照sign_type指定的方式对待签名数据进行签名加密。

例如，假设调用某接口需要以下参数：

service＝user_query；

partner＝2088006300000000；

email＝test＠msn.com，

则依据上述按照参数名称字符升序串联生成的待签名数据为：email＝test＠msn.com&partner＝2088006300000000&service＝user_query。

进一步地，将该待签名数据和预置的安全校验码的MD5(Message-Digest Algorithm 5信息-摘要算法)摘要作为签名。在这种情况下，如果安全校验码是mysecurityCode，是本例中的待签名数据就是：email＝test＠msn.com&partner＝2088006300000000&service＝user_querymysecurityCode。

公知的是，MD5的典型应用是对一段信息(Message)产生信息摘要(Message-Digest)，以防止被篡改。比如，在UNIX下有很多软件在下载的时候都有一个文件名相同，文件扩展名为.md5的文件，在这个文件中通常只有一行文本，大致结构如：

MD5(tanajiya.tar.gz)＝0ca175b9c0f726a831d895e269332461，

以上就是tanajiya.tar.gz文件的数字签名。MD5将整个文件当作一个大文本信息，通过其不可逆的字符串变换算法，产生了这个唯一的MD5信息摘要。如果在以后传播这个文件的过程中，无论文件的内容发生了任何形式的改变(包括人为修改或者下载过程中线路不稳定引起的传输错误等)，只要对这个文件重新计算MD5时，就会发现信息摘要不相同，由此可以确定得到的只是一个不正确的文件。如果还存在一个第三方的认证机构，用MD5还可以防止文件作者的＂抵赖＂，这就是所谓的数字签名应用。

具体而言，当交易平台向标准化处理平台发送请求参数时，使用自己的密钥对待签名数据采用DSA(数字签名算法)进行签名，则标准化处理平台使用交易平台提供的公钥进行校验。作为另一实施例，当标准化处理平台返回数据时，也可以使用其密钥对相应的待签名数据采用DSA(数字签名算法)进行签名，在这种情况下，则由所述交易平台使用标准化处理平台的公钥进行校验。更进一步地，所述DSA公、私钥可以使用OpenSSL生成，如：生成DSA参数：openssl dsaparam-outdsa_param.pem 1024；生成私钥：openssl gendsa-out dsa_private_key.pemdsa_param.pem；生成公钥：openssl dsa-in dsa_private_key.pem-pubout-outdsa_public_key.pem。其中，所述OpenSSL是一种开放源码的SSL实现，用来实现网络通信的高强度加密，适用于各种网络应用程序中。

当然，上述具体算法仅仅用于举例，本领域技术人员可以采用其它方式或算法对所述交易请求参数进行签名校验或其它加/解密处理，本发明对此无需加以限制。

步骤202、所述标准化处理平台按照预置格式将所述交易请求参数封装成订单信息，并记录所述订单信息唯一的订单标识；

其中，所述订单信息可以包括卖方ID、商品名称、商品单价和购买数量等参数。当然，本领域技术人员根据实际情况在所述订单信息中设置其它参数都是可行的，本发明对此不需要进行限定。

对于用户在多个交易平台提出的交易请求，由于其相应的请求可能对应不同的数据格式，因而在本实施例中，所述标准化处理平台需要进一步对其进行标准化处理，即将这些不同的数据格式按照预置格式进行封装，以生成标准化的订单信息。

优选的是，所述标准化处理可以通过设置参数编码字符集实现，即对应不同数据格式的参数，标准化处理平台采用该参数编码字符集中相应的字符集对该参数进行编码封装，以生成标准格式的订单信息。需要说明的是，所述标准格式为由本领域技术人员根据实际情况预先设定的标准格式。

当然，本领域技术人员采用现有技术中的任一种方法进行所述标准化处理也是可行的，例如，采用XML解析器来封装，本发明对此不需要进行限定。

优选的是，在生成所述订单信息的同时，标准化处理平台还可以针对所述订单信息记录可唯一识别的订单标识，用以方便查找相应的订单信息，并且，在后续处理过程中，还可以将其作为用户在支付时使用的支付代码，以唯一识别并确定该笔交易。

步骤203、如果所述订单信息封装成功，则通知所述交易平台根据所述交易请求参数调整其内部交易规则，并判断是否满足交易要求；

具体而言，所述交易平台可以通过以下子步骤调整其内部交易规则：

子步骤A1、获取所述商品名称对应的库存数量；

子步骤A2、从所述库存数量中减去所述购买数量，更新所述库存数量。

例如，标准化处理平台将订单信息封装成功的消息通知交易平台，交易平台收到该通知后，调用请求参数中的商品名称和购买数量项，通过确定该商品名称所对应的库存数量，如50件，然后从该库存数据量减去该购买数量，如10件，则调整后该交易平台的交易规则中的库存数量为40件。

当然，对于交易规则中库存数量的调整只是网上交易中相应的调整，在实际中，本领域技术人员相应设置其它调整项都是可行的，例如，在团购式交易中，调整价格规则；或者，在拍卖式交易中，根据用户的出价增加出价列表等；即相应规则的设置及调整可以任意设置，本发明对此不需要进行限定。

在这种情况下，所述交易平台还可以通过以下子步骤判断是否满足交易要求：

子步骤A3、判断所述更新后的库存数量是否大于或等于0，如果是，则确定满足交易要求。

假设某个商品A的库存数量为20件，而用户提交请求中的购买数量为30件，则确定该商品A不能满足此次交易的要求。

因而，本实施例还可以包括以下子步骤：

子步骤A4、如果所述更新后的库存数量小于0，则向客户端返回交易失败信息。

当然，所述判断交易满足要求的规则也可由本领域技术人员根据实际情况任意设置，本发明对此无需加以限制。

在这种情况下，所述交易平台可以获得满足要求或不满足要求的结果信息，并通知标准化处理平台，由所述标准化处理平台根据满足要求的信息进行下一步操作，或者，根据不满足要求的信息向客户端返回交易失败的信息。

在本步骤中，可以看出，本发明的又一核心构思在于，在平台之间采用通知机制进行通讯。即在标准化处理平台上提供基于HTTP协议的主动向交易平台发送有关用户、交易等状态同步通知的基础服务。其工作的具体流程为：

1、标准化处理平台向交易平台发出通知，具体可以通过访问交易平台提供的通知接收地址URL实现；

2、交易平台接收通知请求，通过通知id(标准化处理平台通知流水号，可以通过这个流水号确定该条通知的合法性)询问标准化处理平台这个通知的真实性；

3、标准化处理平台判断通知的真实性，如果是则返回true信息，如果否则返回false信息；

4、交易平台根据标准化处理平台返回的true信息，对该通知进行处理。处理完毕后，将处理结果返回给标准化处理平台；

5、标准化处理平台处理交易平台返回的处理结果。

在本发明中，所述通知机制还可以用于标准化处理平台与支付平台的交互中，对于其具体实现方式可以参考上述步骤，本发明对此不再赘述。

此外，如果获得所述订单信息封装不成功的消息，在本实施例，可以由交易平台再次向标准化处理平台重新发送请求参数，或者，由交易平台直接向客户端返回处理失败的信息，本发明对此不作限制。

步骤204、如果满足，则通知所述标准化处理平台根据所述订单标识查找对应的订单信息，并基于所述订单信息生成支付信息；

由于所述支付信息是方便用户进行支付时需要的信息，因而，在本实施例中，所述支付信息可以包括卖方ID、商品名称、商品单价、实际可购数量和支付方式等参数，当然，本领域技术人员根据具体情况设置其它参数，例如，支付时间信息、支付限制信息等都是可行的。

优选的是，本实施例还可以包括步骤：

在客户端展示所述支付信息，用以方便用户可以根据相应的支付信息提交支付请求。

步骤205、所述标准化处理平台接收用户提交的支付请求，并通知支付平台，由所述支付平台基于所述支付信息生成交易信息。

由于所述交易信息主要用于与所述支付平台连接的帐务模块进行交互，例如，与网银接口完成支付业务，因而，在本实施例中，所述交易信息可以包括买方ID、卖方ID、商品名称、商品单价、购买数量和交易类型等参数，当然，本领域技术人员根据具体情况设置其它参数，例如，交易时间规则，都是可行的，本发明对此不需要进行限定。

在本步骤中，即实现了交易的创建，在现有的网上交易环境中，用户可以根据该交易信息选择自主支付或委托代扣的方式完成交易，对于用户具体支付行为的实现，由于偏离于本发明的核心构思，在此不赘述。

可以看出，本发明通过对数据交互规则的标准化处理，可以满足在不同交易平台下交易订单的生成，并且，通过这种标准化处理可以简化用户在不同商业交易平台上的交易操作，使用户获得更好体验。

参考图3，示出了本发明的一种多平台的数据标准化处理系统实施例的结构框图，具体可以包括以下单元：

第一交互平台31，包括提取单元311、通讯单元312和处理单元313，所述提取单元311用于根据用户的交互请求提取请求参数；所述通讯单元312用于与第二交互平台连接进行通讯；所述处理单元313用于根据所述请求参数调整其内部交互规则，并判断是否满足交互要求；

第二交互平台32，包括转换单元321、记录单元322、通知单元323、生成单元324和接口单元325，所述转换单元321用于按照预置格式将所述请求参数封装成订单信息；所述记录单元322用于记录所述订单信息唯一的订单标识；所述通知单元323用于向第一交互平台和第三交互平台发送通知信息；所述生成单元324用于根据所述订单标识查找对应的订单信息，并基于所述订单信息生成支付信息；所述接口单元325用于接收用户自客户端34提交的支付请求、并连接第三交互平台33。

第三交互平台33，包括创建单元331，用于基于所述支付信息生成交易信息。

客户端34，用于展示将所述支付信息。

优选的是，所述第一交互平台为交易平台，第二交互平台为标准化处理平台，第三交互平台为支付平台；所述请求参数包括买方ID、卖方ID、商品名称、商品单价和购买数量；所述订单信息包括卖方ID、商品名称、商品单价和购买数量；所述支付信息包括卖方ID、商品名称、商品单价、实际可购数量和支付方式；所述交易信息包括买方ID、卖方ID、商品名称、商品单价、购买数量和交易类型。

在实际中，所述交易平台可以为一个或多个。

为保证数据传输的安全性，优选的是，所述第一交互平台还可以包括签名加密单元，用于对所述请求参数进行签名；所述第二交互平台还可以包括校验单元，用于使用相应的公钥进行校验。

参考图4，示出了应用图3所示的优选系统实施例进行多平台数据标准化处理的流程图，具体可以包括以下步骤：

步骤401、第一交互平台的提取单元根据用户的交互请求提取请求参数，并由通讯单元发送至第二交互平台；

优选的是，所述第一交互平台的签名加密单元将请求参数进行签名后，再由通讯单元发送至第二交互平台。

步骤402、所述第二交互平台的转换单元按照预置格式将所述请求参数封装成订单信息，记录单元记录所述订单信息唯一的订单标识；

如果第二交互单元接收的请求参数进行签名处理，则第二交互单元的校验单元会采用上述签名加密单元提供的相应公钥来进行校验，以确保数据的真实性。

步骤403、如果所述订单信息封装成功，则第二交互平台的通知单元通知所述第一交互平台，第一交互平台的处理单元根据所述请求参数调整其内部交互规则，并判断是否满足交互要求；

具体而言，所述处理单元可以通过以下子步骤调整其内部交易规则：

子步骤A1、获取所述商品名称对应的库存数量；

子步骤A2、从所述库存数量中减去所述购买数量，更新所述库存数量。

例如，第二交互平台的通知单元将订单信息封装成功的消息通知第一交互平台，第一交互平台的处理单元根据该通知调用请求参数中的商品名称和购买数量项，通过确定该商品名称所对应的库存数量，如，50件，然后从该库存数据量减去该购买数量，如，10件，则调整后该第一交互平台的交易规则中的库存数量为40件。

当然，对于交易规则中库存数量的调整只是网上交易中相应的调整，在实际中，本领域技术人员相应设置其它调整项都是可行的，例如，在团购式交易中，调整价格规则；或者，在拍卖式交易中，根据用户的出价增加出价列表等；即相应规则的设置及调整可以任意设置，本发明对此不需要进行限定。

在这种情况下，所述第一交互平台还可以通过以下子步骤判断是否满足交易要求：

子步骤A3、判断所述更新后的库存数量是否大于或等于0，如果是，则确定满足交易要求。

假设某个商品A的库存数量为20件，而用户提交请求中的购买数量为30件，则确定该商品A不能满足此次交易的要求。

因而，本实施例还可以包括以下子步骤：

子步骤A4、如果所述更新后的库存数量小于0，则向客户端返回交易失败信息。

当然，所述判断交易满足要求的规则也可由本领域技术人员根据实际情况任意设置，本发明对此无需加以限制。

在这种情况下，所述第一交互平台可以获得满足要求或不满足要求的结果信息，并连接第二交互平台进行通讯，由所述第二交互平台根据满足要求的信息进行下一步操作，或者，根据不满足要求的信息向客户端返回交易失败的信息。

步骤404、如果处理单元处理得到满足交互要求的信息，则通讯单元通知所述第二交互平台，由所述第二交互平台的生成单元根据所述订单标识查找对应的订单信息，并基于所述订单信息生成支付信息；

在客户端展示将所述支付信息，则用户可以根据所述支付信息自客户端提交相应的支付请求。

步骤405、第二交互平台的接口单元接收用户提交的支付请求、并连接第三交互平台，由所述第三交互平台的创建单元基于所述支付信息生成交易信息，以实现交易的创建。

在实际中，所述第三交互平台还可以包括与帐务模块，例如，网银等接口的接口单元，以及完成交易处理的交易处理单元，由于其具体处理方式偏离于本发明的核心构思，因而对此不赘述。

对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

对于本系统实施例而言，由于其基本相应于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

参考图5，示出了本发明的一种标准化处理平台实施例的结构框图，所述标准化处理平台50连接交易平台51和支付平台52，所述标准化处理平台包括：

转换单元501，用于按照预置格式将所述请求参数封装成订单信息；

记录单元502，用于记录所述订单信息唯一的订单标识；

通知单元503，用于向交易平台和支付平台发送通知信息；

生成单元504，用于根据所述订单标识查找对应的订单信息，并基于所述订单信息生成支付信息；

所述接口单元505，用于接收用户自客户端54提交的支付请求，并连接支付平台。

具体而言，所述接口单元的接入方式可以采用POST/GET方式，其接入类型包括系统调用和页面跳转等，其中系统调用是指为交易平台获得本平台的信息提供服务的；页面跳转通常是用户在交易平台的页面执行部分操作，然后跳转到本平台页面完成整个操作。或者，进一步需要跳回到交易平台的下一个页面，继续完成整个操作。本发明可以提供以下理结果的返回方式：

一、立即返回处理结果：即用户在本平台的页面完成操作后，本平台将处理结果立即返回给交易平台的下一步操作页面，让用户继续完成整个操作流程。在这种情况下，必须传递交易平台下一个操作页面的地址参数return_url。

二、异步返回处理结果：即用户从交易平台的页面跳转到本平台的页面后，在本平台完成最后操作，用户无需再回到交易平台页面。在这种情况下，则可以通过通知接口异步获得处理结果。如果需要异步返回结果，那么必须传递指定通知返回的地址的参数notify_url。

在实际中，所述标准化处理平台还可以提供其它接口与其它不同的平台连接，例如，提供超时监控接口，与监控时限的平台连接；或者，与现有的SP平台连接，并且，所述SP平台与电信运营商平台连接，通过解析并转发短消息的机制，实现本发明的移动终端支付行为，以使本发明更利于用户的操作。

对于本系统实施例而言，由于其基本相应于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

可以理解的是，本发明可用于众多通用或专用的计算系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

本发明可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本发明，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

以上对本发明所提供的一种多平台的数据标准化处理方法和系统的实施例进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (13)

1、一种多平台的数据标准化处理方法，其特征在于，所述数据处理涉及第一交互平台、第二交互平台及第三交互平台，所述方法包括：

第一交互平台根据用户的交互请求提取请求参数，并发送至第二交互平台；

所述第二交互平台按照预置格式将所述请求参数封装成订单信息，并记录所述订单信息唯一的订单标识；

如果所述订单信息封装成功，则通知所述第一交互平台根据所述请求参数调整其内部交互规则，并判断是否满足交互要求；

如果满足，则通知所述第二交互平台根据所述订单标识查找对应的订单信息，并基于所述订单信息生成支付信息；

第二交互平台接收用户提交的支付请求、并连接第三交互平台，由所述第三交互平台基于所述支付信息生成交易信息。

2、如权利要求1所述的方法，其特征在于，所述第一交互平台为交易平台，第二交互平台为标准化处理平台，第三交互平台为支付平台；所述请求参数包括买方ID、卖方ID、商品名称、商品单价和购买数量。

3、如权利要求2所述的方法，其特征在于，所述交易平台通过以下步骤调整其内部交互规则：

获取所述商品名称对应的库存数量；

从所述库存数量中减去所述购买数量，更新所述库存数量。

4、如权利要求3所述的方法，其特征在于，所述交易平台通过以下步骤判断是否满足交互要求：

判断所述更新后的库存数量是否大于或等于0，如果是，则确定满足交互要求。

5、如权利要求4所述的方法，其特征在于，还包括：

如果所述更新后的库存数量小于0，则向客户端返回交易失败信息。

6、如权利要求1或2所述的方法，其特征在于，还包括：

在客户端展示所述支付信息。

7、如权利要求1或2所述的方法，其特征在于，所述第一交互平台为一个或多个。

8、如权利要求2、3、4或5所述的方法，其特征在于，还包括：

所述第一交互平台对所述请求参数进行签名；

所述第二交互平台使用相应的公钥进行校验。

9、一种多平台的数据标准化处理系统，其特征在于，包括：

第一交互平台，包括提取单元、通讯单元和处理单元，所述提取单元用于根据用户的交互请求提取请求参数；所述通讯单元用于与第二交互平台连接进行通讯；所述处理单元用于根据所述请求参数调整其内部交互规则，并判断是否满足交互要求；

第二交互平台，包括转换单元、记录单元、通知单元、生成单元和接口单元，所述转换单元用于按照预置格式将所述请求参数封装成订单信息；所述记录单元用于记录所述订单信息唯一的订单标识；所述通知单元用于向第一交互平台和第三交互平台发送通知信息；所述生成单元用于根据所述订单标识查找对应的订单信息，并基于所述订单信息生成支付信息；所述接口单元用于接收用户提交的支付请求、并连接第三交互平台；

第三交互平台，包括创建单元，用于基于所述支付信息生成交易信息。

10、如权利要求9所述的系统，其特征在于，所述第一交互平台为交易平台，第二交互平台为标准化处理平台，第三交互平台为支付平台；所述请求参数包括买方ID、卖方ID、商品名称、商品单价和购买数量。

11、如权利要求9或10所述的系统，其特征在于，所述第一交互平台为一个或多个。

12、如权利要求9或10所述的系统，其特征在于，所述第一交互平台还包括签名加密单元，用于对所述请求参数进行签名；所述第二交互平台还包括校验单元，用于使用相应的公钥进行校验。

13、一种标准化处理平台，其特征在于，所述标准化处理平台连接交易平台和支付平台，所述标准化处理平台包括：

转换单元，用于按照预置格式将所述请求参数封装成订单信息；

记录单元，用于记录所述订单信息唯一的订单标识；

通知单元，用于向交易平台和支付平台发送通知信息；

生成单元，用于根据所述订单标识查找对应的订单信息，并基于所述订单信息生成支付信息；

所述接口单元，用于接收用户提交的支付请求、并连接第三交互平台。

Images