CN103034941A - 网络支付方法及系统 - Google Patents

Abstract

本发明公开了一种网络支付方法及系统，该方法包括：接收来自客户端的第一支付请求，第一支付请求包括目标对象信息和用户信息，目标对象适于由用户进行操作并适于在一个或者多个服务器上提供，目标对象信息包括提供该目标对象的服务器信息；以及根据预先存储的用户关联信息，对第一支付请求进行验证，并根据验证结果确定是否允许进行网络支付；其中，用户关联信息包括用户的用户信息以及与该用户相关联的服务器列表，对第一支付请求进行验证包括确定目标对象信息中的服务器信息是否包含在用户关联信息中的服务器列表中，从而能够在支付前对用户输入的第一支付请求中的目标对象信息和用户信息进行相关性验证，以避免支付失败。

Description

网络支付方法及系统

技术领域

本发明涉及网络支付领域，具体涉及一种网络支付方法及系统。

背景技术

目前，随着计算机技术的快速发展，网络支付得到了越来越广泛的应用。例如，以网络游戏之类的网络应用为例，用户可以选择通过网络支付为网络游戏中的一些高级功能（如增值服务）支付费用。

在目前的支付过程中，如果用户希望为某一游戏增值服务支付费用，在支付之前，需要用户选择该游戏增值服务所对应的游戏以及该游戏所在的游戏服务器，即游戏区服。通常情况下，用户一般是为自己的帐号进行充值而没有考虑游戏区服等问题，而只有当用户自己的帐号已经注册了相应的游戏及区服时才能够成功充值，如果用户选择了自己的游戏帐号没有注册的游戏或区服，则无法成功地为自己的帐号充值。

但是，由于目前网络游戏的种类繁多（例如成百上千款）、游戏区服的数量庞大，导致用户在选择游戏和区服时，需要从众多的候选项中挑选自己需要的内容，一不留神就很容易选择错误，而一旦有一个选项选择错误，就会导致用户充值失败，最终只能申请退款或联系官方补偿，为用户造成了不必要的困扰。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的网络支付方法及系统。

依据本发明的一个方面，提供了一种网络支付方法，包括：接收来自客户端的第一支付请求，第一支付请求包括目标对象信息和用户信息，目标对象适于由用户进行操作并适于在一个或者多个服务器上提供，目标对象信息包括提供该目标对象的服务器信息；以及根据预先存储的用户关联信息，对第一支付请求进行验证，并根据验证结果确定是否允许进行网络支付；其中，用户关联信息包括用户的用户信息以及与该用户相关联的服务器列表，以及对第一支付请求进行验证包括确定目标对象信息中的服务器信息是否包含在用户关联信息中的与该用户相关联的服务器列表中。

可选地，该方法还包括：在对第一支付请求验证通过时，通过预设的校验算法对用户信息以及目标对象信息进行校验，得到第一校验值，并将用户信息、目标对象信息以及第一校验值发送给客户端；接收从客户端发送的第二支付请求，第二支付请求中包含用户信息、目标对象信息、第一校验值以及支付金额，通过预设的校验算法对第二支付请求中包含的用户信息以及目标对象信息进行校验，得到第二校验值；比较第二校验值与第一校验值，当确定第二校验值与第一校验值相同时，则验证通过，允许以支付金额进行充值。

可选地，该方法还包括：当确定第二校验值与第一校验值不相同时，向客户端返回错误提示信息。

可选地，预设的校验算法包括：md5算法和数字签名算法。

可选地，用户在每个相关联的服务器中具有相应的用户身份，用户关联信息还包括用户在每个相关联的服务器上的用户身份，以及支付包括为用户身份进行充值。

根据本发明的另一方面，提供了一种网络支付系统，包括：存储器，适于预先存储用户关联信息，用户关联信息包括用户的用户信息以及与该用户相关联的服务器列表；交互接口，适于接收来自客户端的第一支付请求，第一支付请求包括目标对象信息和用户信息，目标对象适于由用户进行操作并适于在一个或者多个服务器上提供，目标对象信息包括提供该目标对象的服务器信息；第一验证器，适于根据存储器上存储的用户关联信息，对第一支付请求进行验证，并根据验证结果确定是否允许进行网络支付，其中，第一验证器对第一支付请求进行验证包括确定目标对象信息中的服务器信息是否包含在用户关联信息中的与该用户相关联的服务器列表中。

可选地，该系统还包括：第二验证器，适于在第一验证器对第一支付请求验证通过时，通过预设的校验算法对用户信息以及目标对象信息进行校验，得到第一校验值，并将用户信息、目标对象信息以及第一校验值通过交互接口发送给客户端；交互接口还适于接收从客户端发送的第二支付请求，第二支付请求中包含用户信息、目标对象信息、第一校验值以及支付金额；第二验证器还适于通过预设的校验算法对第二支付请求中包含的用户信息以及目标对象信息进行校验，得到第二校验值；比较第二校验值与第一校验值，当确定第二校验值与第一校验值相同时，则验证通过，允许以支付金额进行充值。

可选地，第二验证器进一步适于：当确定第二校验值与第一校验值不相同时，通过交互接口向客户端返回错误提示信息。

可选地，预设的校验算法包括：md5算法和数字签名算法。

可选地，用户在每个相关联的服务器中具有相应的用户身份，存储器中存储的用户关联信息还包括用户在每个相关联的服务器上的用户身份，以及支付包括为用户身份进行充值。

根据本发明的网络支付方法及系统，通过预先存储用户关联信息，并确定第一支付请求所包含的目标对象信息中的服务器信息是否包含在用户关联信息中的与该用户相关联的服务器列表中，由此确定第一支付请求中的目标对象信息和用户信息是否相关，由此解决了因目标对象信息和用户信息不相关（例如游戏帐号没有注册相应的游戏及区服）而导致支付失败的问题，实现了能够在支付前对用户输入的第一支付请求中的目标对象信息和用户信息进行相关性验证，以避免支付失败的有益效果。

另外，根据本发明的网络支付方法和系统，在预先确定了第一支付请求恰当之后，利用在返回给客户端的信息中嵌入验证信息、并在进行支付之前根据验证信息是否一致来确定原先验证过的第一支付请求中的相关信息是否被篡改了，从而可以进一步确保支付的安全性。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本发明一个实施例的网络支付方法的方法流程图；

图2示出了根据本发明一个实施例中当确定第一支付请求中包含的目标对象信息没有包含在与该用户相关联的服务器列表中时显示的提示窗口的界面示意图；

图3示出了根据本发明一个实施例中当确定第二校验值与第一校验值相同时显示的充值界面的界面示意图；以及

图4示出了根据本发明一个实施例的网络支付系统的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

图1示出了本发明实施例提供的网络支付方法的流程图。如图1所示，该方法始于步骤S110，在步骤S110中，接收来自客户端的第一支付请求，该第一支付请求包括目标对象信息和用户信息。其中，目标对象适于由用户进行操作并适于在一个或者多个服务器上提供，目标对象信息包括提供该目标对象的服务器信息。

在该实施例中，以目标对象为网络游戏为例进行说明。例如，在第一支付请求中，要充值的目标对象为用户要玩的游戏，以GKEY来表示，目标对象信息包括提供该目标对象的服务器信息，即该游戏所对应的区服，以SKEY来表示。除了目标对象信息外，第一支付请求中还包含用户信息，该用户信息主要是指用户的游戏帐号，也叫游戏ID，以QID来表示。也就是说，在步骤S110所接收到的第一支付请求中包含GKEY、SKEY以及QID三个参数。

第一支付请求可通过多种方式发送，例如，可以由用户登录目标对象所在的官方网站，在官方网站上选择相应的充值接口的方式来发送。或者，也可以由用户访问类似如下形式的一个URL来发送，该URL形如http://pay.wan.360.cn/order.html?gkey=玩家所玩的游戏名&skey=玩家所以的区服&sqid=玩家的QID。接收到该URL之后，通过下述代码即可获得上述的目标对象信息（gkey、skey）和用户信息(sqid)：

$gkey=FilterParam::htmlSpecil($request->get(“gkey”));

$skey=FilterParam::htmlSpecil($request->get(“skey”));

$gqid FilterParam::htmlSpecil($request->get(“sqid”))。

获取到上述的目标对象信息和用户信息之后，在步骤S120中，根据预先存储的用户关联信息，对第一支付请求进行验证，并根据验证结果确定是否允许进行网络支付。用户关联信息包括用户的用户信息以及与该用户相关联的服务器列表。具体地，对第一支付请求进行验证包括确定目标对象信息中的服务器信息是否包含在该用户关联信息中的与该用户相关联的服务器列表中。

在介绍步骤S120中的具体验证过程之前，先介绍一下预先存储的用户关联信息的具体内容。

依然以目标对象为网络游戏为例进行说明。在网络游戏领域，一般会为每个用户分配一个唯一的游戏ID（即QID），由于游戏ID与用户之间具有一一对应的关系，因此，通过游戏ID就可以唯一地标识一个用户。一般情况下，一个用户可能喜欢玩多款游戏，每当用户在玩一款新游戏之前，都需要先通过该用户的游戏ID对该款游戏进行注册。

例如，当一个用户通过自身的游戏ID（例如QID=1）注册了一款“仙剑情”游戏（即GKEY=SJQ）之后，游戏提供方会分配一台服务器（例如服务器C）作为游戏区服（即SKEY=C），为该用户提供该款仙剑情游戏。当该用户完成上述注册过程后，该用户在该游戏区服（即服务器C）中就具有了相应的用户身份，该用户身份可以是仙剑情游戏中的一个人物角色等。用户可以通过本发明实施例提供的网络支付方法为该用户身份进行充值，以便在该款游戏中享有更多的功能。

同理，当该用户通过自身的游戏ID（例如QID=1）注册了另一款“神仙道”游戏（即GKEY=SXD）之后，游戏提供方会分配一台服务器（例如服务器D）作为游戏区服（即SKEY=D），为该用户提供该款神仙道游戏。当该用户完成上述注册过程后，该用户在该游戏区服（即服务器D）中就具有了相应的用户身份，该用户身份可以是神仙道游戏中的一个人物角色等，用户可以通过本发明实施例提供的网络支付方法为该用户身份进行充值。

当用户通过本发明实施例提供的网络支付方法为用户身份进行充值时，只有当用户要充值的用户身份在相应的游戏区服中有记录时，即用户注册了该款游戏时才能充值成功。例如，假设上面描述的QID=1的用户只注册了上述的“仙剑情”和“神仙道”两款游戏，即只在这两款游戏对应的游戏区服中具有相应的用户身份，因此，如果用户在充值时选择了另外的游戏或区服，由于用户在该游戏中不具有相应的用户身份则无法充值成功。

为了避免上述因用户选错游戏或区服而导致充值失败的情况，需要事先存储用户关联信息。该用户关联信息包括用户信息以及与该用户相关联的服务器列表。例如，在上述情况中，用户关联信息所存储的一项内容中的用户信息为QID=1，与该QID=1的用户相关联的服务器列表为服务器C和服务器D。

在步骤S120中，根据预先存储的用户关联信息，对第一支付请求进行验证时，主要是确定目标对象信息中的服务器信息是否包含在该用户关联信息中的与该用户相关联的服务器列表中。

具体地，结合上述例子来说，假设步骤S110中接收到的第一支付请求中包含的QID=1、GKEY=SJQ，SKEY=C，通过查找用户关联信息发现，与QID=1的用户信息相关联的服务器列表为服务器C（SKEY=C）和服务器D（SKEY=D）。因此，第一支付请求中包含的目标对象信息（SKEY=C）包含在了与该用户相关联的服务器列表中。其中，查找用户关联信息时，可通过代码“$results=GPayClient::ins()->is_active($gkey,$skey,$qid，$otherparmas)”来调用预先设置的is_active接口，由该接口来查找用户关联信息，从而根据返回的结果results来判断第一支付请求中包含的目标对象信息（SKEY=C）是否包含在了与该用户相关联的服务器列表中。

当确定第一支付请求中包含的目标对象信息包含在了与该用户相关联的服务器列表中时，表明第一支付请求中包含的用户信息和目标对象信息是相关的。其中，用户信息和目标对象信息相关表明用户的游戏帐号注册了相应的游戏及区服。因此，可以允许进行网络支付。

当确定第一支付请求中包含的目标对象信息没有包含在与该用户相关联的服务器列表中时，表明第一支付请求中包含的用户信息和目标对象信息是不相关的。其中，用户信息和目标对象信息不相关表明用户的游戏帐号没有注册相应的游戏及区服。因此，不允许进行网络支付，这时，可以通过向用户弹出验证失败的提示窗口的方式来提示用户无法进行充值，例如，为用户显示图2所示的提示内容。

另外，可选地，在预先存储的用户关联信息中，除了包含用户的用户信息以及与该用户相关联的服务器列表之外，还可以进一步包含与该用户相关联的目标对象，即该用户所注册的游戏信息，例如，上述的GKEY=XJQ及GKEY=SXD信息。相应地，在步骤S120中对第一支付请求进行验证时，除了验证第一支付请求中的目标对象信息中的服务器信息是否包含在用户关联信息中的与该用户相关联的服务器列表中之外，还需要验证第一支付请求中的目标对象是否包含在用户关联信息中的与该用户相关联的目标对象中，当服务器信息和目标对象都包含在用户关联信息中时，才允许进行支付，从而进一步提高支付的准确性，以避免由于服务器相同，目标对象不同所导致的支付错误。而且，用户关联信息还可以包括用户在每个相关联的服务器上的用户身份，相应地，该支付包括为该用户身份进行充值。

其中，当允许进行网络支付时，可以通过如下两种方式进行支付：

第一种支付方式为，直接在第一支付请求中进一步包含支付金额，以便于根据该支付金额进行支付。

第二种支付方式为，在对第一支付请求验证通过时，进一步接收来自该客户端的第二支付请求，在该第二支付请求中包含支付金额，以便于根据该支付金额进行支付。

上述的第一种方式简便易行，但是，在实际情况中，出于网页结构设计等多方面的考虑，往往会采用第二种方式进行支付。当采用第二种方式进行支付时，由于需要接收两次支付请求，一般情况下，当客户端输入第一支付请求之后，客户端上所显示的网页会发生跳转，然后用户在跳转后的页面上输入第二支付请求。当页面跳转的时候为了防止信息被恶意篡改，可选地，该方法还可以进一步包括下述的步骤S130-S170。

在步骤S130中，在对第一支付请求验证通过后，通过预设的校验算法对用户信息以及目标对象信息进行校验，得到第一校验值，并将用户信息、目标对象信息以及第一校验值发送给客户端。

以上述例子来说，第一支付请求中的用户信息为QID，目标对象为GKEY，目标对象信息为SKEY。预设的校验算法可以是md5算法、数字签名算法或其他加解密算法。当采用md5算法作为校验算法时，在步骤S130中通过md5算法对QID、GKEY和SKEY这三个参数以及系统保留的私钥进行MD5运算，得到第一校验值SIGN1。例如，通过代码“$xcontext->gsign=md5($gkey.$skey.$qid.$key)”来加密。然后，将QID、GKEY、SKEY和SIGN1这四个参数发送给客户端。

然后，在步骤S140中，接收从客户端发送的第二支付请求，该第二支付请求中包含用户信息、目标对象信息、第一校验值以及支付金额，通过预设的校验算法，如md5算法，对该第二支付请求中包含的用户信息以及目标对象信息进行校验，得到第二校验值。

这里，客户端发送的第二支付请求中除了包含用户输入的支付金额外，还包含步骤S130中接收到的QID、GKEY、SKEY和SIGN1这四个参数。这时，对第二支付请求中包含的QID、GKEY和SKEY这三个参数以及系统保留的私钥进行加密，得到第二校验值SIGN2。

然后，在步骤S150中，比较得到的第二校验值SIGN2与第二支付请求中的第一校验值SIGN1是否相同。例如，可通过如下代码段中的validate_token函数来验证第二校验值与第一校验值是否相同：

如果第二校验值与第一校验值相同，则执行步骤S160；如果第二校验值与第一校验值不相同，则执行步骤S170。

当确定第二校验值与第一校验值相同时，表示验证通过，执行步骤S160，允许以该支付金额进行充值，这时，可以通过将页面跳转到图3所示的页面的方式提示完成充值。当确定第二校验值与第一校验值不相同时，表示验证未通过，执行步骤S170，向客户端返回错误提示信息。

上述验证方式的原理在于，正常情况下，如果第一支付请求中包含的QID、GKEY、SKEY参数信息没有被篡改，那么第二支付请求中包含的QID、GKEY、SKEY的参数值应该与第一支付请求中包含的参数值相同，因此，采用相同的加密算法md5算法加密后所产生的第一校验值和第二校验值应该相等，如果不相等，则表示第二支付请求中包含的信息被篡改了，因此，为了避免错误，将不进行支付并向客户端返回错误提示信息。

通过步骤S130-S170中的验证操作，可以进一步确保网络支付的安全，防止因网络故障或黑客攻击等原因所导致的充值错误的情况。

在本实施例中，是以目标对象为网络游戏为例进行说明的，目标对象信息主要是指为该网络游戏提供服务的服务器信息，即游戏区服。其中，在一个网络游戏中，为某一用户提供服务的游戏区服可能不只一个，这时需要在用户关联信息中对所有与该用户相关联的游戏区服都进行存储。

本发明实施例提供的网络支付方法，可以在进行网络支付之前对目标对象进行验证，以确保目标对象和用户信息相关联，从而避免了因用户输入错误导致目标对象和用户信息不关联而引起的支付失败的情形。因此，采用本发明实施例提供的网络支付方法，用户不必再担心因选错游戏信息而导致充值不到帐或充错帐号的情况，既维护了用户的切身利益，又减轻了系统维护的成本，客服人员不用再处理大量的失败订单。

另外，在本实施例中，主要是以目标对象为网络游戏为例进行说明的，本领域技术人员能够理解的是，除了网络游戏之外，其他的各种网络应用，例如：付费电视、论坛积分、淘宝购物等，都可以采用本发明提供的网络支付方法进行支付，只要预先存储有关该网络应用的用户关联信息即可。

图4示出了本发明实施例提供的网络支付系统的结构图。如图4所示，该网络支付系统400包括：交互接口41、第一验证器42以及存储器43。一个或多个客户端200通过各种有线或无线连接方式与该网络支付系统400中的交互接口41连接。

交互接口41接收来自客户端200的第一支付请求，该第一支付请求包括目标对象信息和用户信息，目标对象适于由用户进行操作并适于在一个或者多个服务器上提供，所述目标对象信息包括提供该目标对象的服务器信息。

在该实施例中，以目标对象为网络游戏为例进行说明。例如，在第一支付请求中，要充值的目标对象为用户要玩的游戏，以GKEY来表示，目标对象信息包括提供该目标对象的服务器信息，即该游戏所对应的区服，以SKEY来表示。除了目标对象信息外，第一支付请求中还包含用户信息，该用户信息主要是指用户的游戏帐号，也叫游戏ID，以QID来表示。也就是说，交互接口41所接收到的第一支付请求中包含GKEY、SKEY以及QID三个参数。

其中，第一支付请求可通过多种方式发送，例如，可以由用户登录目标对象所在的官方网站，在官方网站上选择相应的充值接口的方式来发送。或者，也可以由用户访问类似如下形式的一个URL来发送，该URL形如http://pay.wan.360.cn/order.html?gkey=玩家所玩的游戏名&skey=玩家所以的区服&sqid=玩家的QID。接收到该URL之后，通过下述代码即可获得上述的目标对象信息（gkey、skey）和用户信息(sqid)：

$gkey＝FilterParam::htmlSpecil($request->get(“gkey”));

$skey=FilterParam::htmlSpecil($request->get(“skey”));

$gqid FilterParam::htmlSpecil($request->get(“sqid”))。

第一验证器42根据存储器43上预先存储的用户关联信息，对第一支付请求进行验证，并根据验证结果确定是否允许进行网络支付。用户关联信息包括用户的用户信息以及与该用户相关联的服务器列表。具体地，第一验证器42对第一支付请求进行验证包括确定目标对象信息中的服务器信息是否包含在该用户关联信息中的与该用户相关联的服务器列表中。

其中，预先存储的用户关联信息存储在存储器43中，关于用户关联信息的具体内容可参照方法实施例相应部分的描述，此处不再赘述。

第一验证器42根据预先存储的用户关联信息，对第一支付请求进行验证时，主要是确定目标对象信息中的服务器信息是否包含在该用户关联信息中的与该用户相关联的服务器列表中。

具体地，结合上述例子来说，假设交互接口41接收到的第一支付请求中包含的QID=1、GKEY=SJQ，SKEY=C，通过查找用户关联信息发现，与QID=1的用户信息相关联的服务器列表为服务器C（SKEY=C）和服务器D（SKEY=D）。因此，第一支付请求中包含的目标对象信息（SKEY=C）包含在了与该用户相关联的服务器列表中。其中，查找用户关联信息时，可通过代码“$results=GPayClient::ins()->is_active($gkey,$skey,$qid，$otherparmas)”来调用预先设置的is_active接口，由该接口来查找用户关联信息，从而根据返回的结果results来判断第一支付请求中包含的目标对象信息（SKEY=C）包含在了与该用户相关联的服务器列表中。

当第一验证器42确定第一支付请求中包含的目标对象信息包含在了与该用户相关联的服务器列表中时，表明第一支付请求中包含的用户信息和目标对象信息是相关的。用户信息和目标对象信息相关表明用户的游戏帐号注册了相应的游戏及区服。因此，可以允许进行网络支付。

当第一验证器42确定第一支付请求中包含的目标对象信息没有包含在与该用户相关联的服务器列表中时，表明第一支付请求中包含的用户信息和目标对象信息是不相关的。其中，用户信息和目标对象信息不相关表明用户的游戏帐号没有注册相应的游戏及区服。因此，不允许进行网络支付，这时，可以通过向用户弹出验证失败的提示窗口的方式来提示用户无法进行充值，例如，为用户显示图2所示的提示内容。

另外，可选地，在预先存储的用户关联信息中，除了包含用户的用户信息以及与该用户相关联的服务器列表之外，还可以进一步包含与该用户相关联的目标对象，即该用户所注册的游戏信息，例如，上述的GKEY=XJQ及GKEY=SXD信息。相应地，在第一验证器42对第一支付请求进行验证时，除了验证第一支付请求中的目标对象信息中的服务器信息是否包含在用户关联信息中的与该用户相关联的服务器列表中之外，还需要验证第一支付请求中的目标对象是否包含在用户关联信息中的与该用户相关联的目标对象中，当服务器信息和目标对象都包含在用户关联信息中时，才允许进行支付，从而进一步提高支付的准确性，以避免由于服务器相同，目标对象不同所导致的支付错误。

其中，当第一验证器42允许进行网络支付时，可以通过如下两种方式进行支付：

第一种支付方式为，直接在第一支付请求中进一步包含支付金额，以便于根据该支付金额进行支付。

第二种支付方式为，在对第一支付请求验证通过时，进一步接收来自该客户端的第二支付请求，在该第二支付请求中包含支付金额，以便于根据该支付金额进行支付。

上述的第一种方式简便易行，但是，在实际情况中，出于网页结构设计等多方面的考虑，往往会采用第二种方式进行支付。当采用第二种方式进行支付时，由于需要接收两次支付请求，一般情况下，当客户端输入第一支付请求之后，客户端上所显示的网页会发生跳转，然后用户在跳转后的页面上输入第二支付请求。当页面跳转的时候为了防止信息被恶意篡改，可选地，该系统还可以进一步包括第二验证器44。

在第一验证器42对第一支付请求验证通过后，第二验证器44通过预设的校验算法对用户信息以及目标对象信息进行校验，得到第一校验值，并将用户信息、目标对象信息以及第一校验值通过交互接口41发送给客户端200。

以上述例子来说，第一支付请求中的用户信息为QID，目标对象为GKEY，目标对象信息为SKEY。预设的校验算法可以是md5算法、数字签名算法或其他加解密算法。当采用md5算法作为校验算法时，第二验证器44通过md5算法对QID、GKEY和SKEY这三个参数以及系统保留的私钥进行MD5运算，得到第一校验值SIGN1。例如，通过代码“$xcontext->gsign=md5($gkey.$skey.$qid.$key)”来加密。然后，由交互接口41将QID、GKEY、SKEY和SIGN1这四个参数发送给客户端200。

然后，交互接口41接收从客户端发送的第二支付请求，该第二支付请求中包含用户信息、目标对象信息、第一校验值以及支付金额，第二验证器44通过预设的校验算法，如md5算法，对该第二支付请求中包含的用户信息以及目标对象信息进行校验，得到第二校验值。

这里，客户端200发送的第二支付请求中除了包含用户输入的支付金额外，还包含客户端200接收到的QID、GKEY、SKEY和SIGN1这四个参数。这时，第二验证器44对第二支付请求中包含的QID、GKEY和SKEY这三个参数以及系统保留的私钥进行MD5运算，得到第二校验值SIGN2。

然后，第二验证器44比较得到的第二校验值SIGN2与第二支付请求中的第一校验值SIGN1是否相同。如果第二校验值与第一校验值相同，则验证通过，允许以该支付金额进行充值。当第二验证器44确定第二校验值与第一校验值不相同时，表示验证未通过，通过交互接口41向客户端返回错误提示信息。

通过第二验证器44，可以进一步确保网络支付的安全，防止因网络故障或黑客攻击等原因所导致的充值错误的情况。

在本实施例中，是以目标对象为网络游戏为例进行说明的，目标对象信息主要是指为该网络游戏提供服务的服务器信息，即游戏区服。其中，在一个网络游戏中，为某一用户提供服务的游戏区服可能不只一个，这时需要在用户关联信息中对所有与该用户相关联的游戏区服都进行存储。

本发明实施例提供的网络支付系统，可以在进行网络支付之前对目标对象进行验证，以确保目标对象和用户信息相关联，从而避免了因用户输入错误导致目标对象和用户信息不关联而引起的支付失败的情形。因此，采用本发明实施例提供的网络支付方法，用户不必再担心因选错游戏信息而导致充值不到帐或充错帐号的情况，既维护了用户的切身利益，又减轻了系统维护的成本，客服人员不用再处理大量的失败订单。

另外，在本实施例中，主要是以目标对象为网络游戏为例进行说明的，本领域技术人员能够理解的是，除了网络游戏之外，其他的各种网络应用，例如：付费电视、论坛积分、淘宝购物等，都可以采用本发明提供的网络支付系统进行支付，只要预先存储有关该网络应用的用户关联信息即可。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书（包括伴随的权利要求、摘要和附图）中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书（包括伴随的权利要求、摘要和附图）中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器（DSP）来实现根据本发明实施例的网络支付系统中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序（例如，计算机程序和计算机程序产品）。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (10)

1.一种网络支付方法，包括：

接收来自客户端的第一支付请求，所述第一支付请求包括目标对象信息和用户信息，所述目标对象适于由用户进行操作并适于在一个或者多个服务器上提供，所述目标对象信息包括提供该目标对象的服务器信息；以及

根据预先存储的用户关联信息，对第一支付请求进行验证，并根据验证结果确定是否允许进行网络支付；

其中，所述用户关联信息包括用户的用户信息以及与该用户相关联的服务器列表，

以及对第一支付请求进行验证包括确定所述目标对象信息中的服务器信息是否包含在所述用户关联信息中的与该用户相关联的服务器列表中。

2.如权利要求1所述的方法，还包括：

在对第一支付请求验证通过时，通过预设的校验算法对所述用户信息以及目标对象信息进行校验，得到第一校验值，并将所述用户信息、目标对象信息以及第一校验值发送给所述客户端；

接收从所述客户端发送的第二支付请求，所述第二支付请求中包含用户信息、目标对象信息、第一校验值以及支付金额，通过所述预设的校验算法对所述第二支付请求中包含的所述用户信息以及目标对象信息进行校验，得到第二校验值；

比较第二校验值与所述第一校验值，当确定第二校验值与所述第一校验值相同时，则验证通过，允许以所述支付金额进行充值。

3.如权利要求2所述的方法，还包括：

当确定第二校验值与第一校验值不相同时，向所述客户端返回错误提示信息。

4.如权利要求2或3所述的方法，所述预设的校验算法包括：md5算法和数字签名算法。

5.如权利要求1-4中任何一个所述的方法，所述用户在每个相关联的服务器中具有相应的用户身份，所述用户关联信息还包括用户在每个相关联的服务器上的用户身份，以及所述支付包括为所述用户身份进行充值。

6.一种网络支付系统，包括：

存储器，适于预先存储用户关联信息，所述用户关联信息包括用户的用户信息以及与该用户相关联的服务器列表；

交互接口，适于接收来自客户端的第一支付请求，所述第一支付请求包括目标对象信息和用户信息，所述目标对象适于由用户进行操作并适于在一个或者多个服务器上提供，所述目标对象信息包括提供该目标对象的服务器信息；

第一验证器，适于根据所述存储器上存储的用户关联信息，对第一支付请求进行验证，并根据验证结果确定是否允许进行网络支付，其中，第一验证器对第一支付请求进行验证包括确定所述目标对象信息中的服务器信息是否包含在所述用户关联信息中的与该用户相关联的服务器列表中。

7.如权利要求6所述的系统，还包括：

第二验证器，适于在所述第一验证器对第一支付请求验证通过时，通过预设的校验算法对所述用户信息以及目标对象信息进行校验，得到第一校验值，并将所述用户信息、目标对象信息以及第一校验值通过所述交互接口发送给所述客户端；

所述交互接口还适于接收从所述客户端发送的第二支付请求，所述第二支付请求中包含用户信息、目标对象信息、第一校验值以及支付金额；

所述第二验证器还适于通过所述预设的校验算法对所述第二支付请求中包含的所述用户信息以及目标对象信息进行校验，得到第二校验值；比较第二校验值与所述第一校验值，当确定第二校验值与所述第一校验值相同时，则验证通过，允许以所述支付金额进行充值。

8.如权利要求6所述的系统，所述第二验证器进一步适于：当确定第二校验值与第一校验值不相同时，通过所述交互接口向所述客户端返回错误提示信息。

9.如权利要求7或8所述的系统，所述预设的校验算法包括：md5算法和数字签名算法。

10.如权利要求6-9中任何一个所述的系统，所述用户在每个相关联的服务器中具有相应的用户身份，所述存储器中存储的用户关联信息还包括用户在每个相关联的服务器上的用户身份，以及所述支付包括为所述用户身份进行充值。

Images