订单处理方法、装置、系统、设备及存储介质

技术领域

本发明涉及游戏技术领域，尤其是涉及一种订单处理方法、装置、系统、设备及存储介质。

背景技术

随着智能终端的普及，与智能终端匹配的各种应用程序也再不断的开发和发布，而在应用程序中增加购物功能也越来越多，尤其是对于游戏场景来说，玩家为了提高游戏体验，通常会购买一些装备来武装游戏角色。

对此，为了便于游戏玩家的操作，在智能终端的应用市场中设置了支付系统，该支付系统连接游戏APP和供应商服务器，当游戏接入IAP功能后，玩家就可以在应用内购买商品。通常游戏APP由SDK和支付系统服务端组成，在下单后，SDK、服务端和支付系统之间会多次交互，直到商品付款成功并到账。在此过程中，客户端上的SDK设置一个透传参数存放游戏支付系统生成的订单号，并通过该参数将游戏订单与供应商订单关联。然而，如果网络波动或供应商支付服务端故障等异常情况发生时，可能会导致返回的透传参数为空，这时导致客户端匹配订单的难度增大，从而影响客户端对游戏APP的运行使用和游戏体验。

发明内容

有鉴于此，本发明的目的在于提供一种订单处理方法、装置、系统、设备及存储介质，通过服务器来实现游戏应用内的订单支付匹配操作，以减少客户端对游戏应用的数据处理量，提高用户对游戏应用的使用体验。

第一方面，本发明实施例提供了一种订单处理方法，应用于游戏支付服务端，该方法包括：

接收客户端上游戏应用产生的下单请求；

根据所述下单请求生成目标商品的订单号，并通过所述客户端将所述订单号添入预设的透传参数中发送至供应商服务器；

接收所述客户端通过回调接口回调所述供应商服务器返回的支付信息；

根据所述支付信息进行商品订单的匹配，并将匹配的结果返回至所述游戏应用和供应商服务器。

第二方面，本发明实施例提供了一种订单处理方法，所述方法包括：

响应针对客户端上游戏应用的购买操作，基于所述购买操作生成下单请求，其中在所述游戏应用上显示有供应商服务器提供的商品购买界面；

根据所述下单请求生成目标商品的订单号；

将所述订单号添入预设的透传参数，并请求支付操作；

接收通过回调接口回调的基于所述支付操作产生的支付信息；

根据所述支付信息进行商品订单的匹配，并将匹配的结果返回至所述游戏应用和所述供应商服务器。

第三方面，本发明实施例提供了一种订单处理装置，所述装置包括：

接收模块，用于接收客户端上游戏应用产生的下单请求；

生成模块，用于根据所述下单请求生成目标商品的订单号，并通过所述客户端将所述订单号添入预设的透传参数中发送至供应商服务器；

回调模块，用于接收所述客户端通过回调接口回调所述供应商服务器返回的支付信息；

匹配模块，用于根据所述支付信息进行商品订单的匹配，并将匹配的结果返回至所述游戏应用和供应商服务器。

第四方面，本发明实施例提供了一种订单处理系统，所述系统包括：安装有游戏应用的客户端，支付装置和供应商服务器；其中，在所述游戏应用上显示有供应商服务器提供的商品购买界面；

所述客户端响应针对游戏应用的购买操作，基于所述购买操作生成下单请求；

所述支付装置根据所述下单请求生成目标商品的订单号；

所述客户端将所述订单号添入预设的透传参数，并向所述供应商服务器请求支付操作；

所述支付装置接收通过回调接口回调的所述供应商服务器基于所述支付操作产生的支付信息；

所述支付装置根据所述支付信息进行商品订单的匹配，并将匹配的结果返回至所述游戏应用和所述供应商服务器。

第五方面，本发明实施例提供了一种电子设备，包括处理器和存储器，存储器存储有能够被处理器执行的计算机可执行指令，处理器执行计算机可执行指令以实现第一方面任一项的订单处理方法，或者实现第二方面任一项的订单处理方法。

第六方面，本发明实施例提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机可执行指令，计算机可执行指令在被处理器调用和执行时，计算机可执行指令促使处理器实现第一方面任一项的订单处理方法，或者实现第二方面任一项的订单处理方法。

本发明实施例带来了以下有益效果：

本发明提供了一种订单处理方法、装置、系统、设备及存储介质，通过接收客户端上游戏应用产生的下单请求；根据下单请求生成目标商品的订单号，并通过客户端将订单号添入预设的透传参数中发送至供应商服务器；接收客户端通过回调接口回调供应商服务器返回的支付信息；根据支付信息进行商品订单的匹配，并将匹配的结果返回至游戏应用和供应商服务器。该方式中，通过将客户端定义为转发节点，将支付相关的操作流程在游戏支付服务端执行，以减少了客户端的数据处理量，保证客户端对游戏应用的运行，并且设置了回调接口以保证支付信息的轮询，避免了支付过程中信息的丢失。

本发明的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种订单处理方法的第一种流程图；

图2为本发明实施例提供的商品购买界面的示意图；

图3为本发明实施例提供的一种订单处理方法的第二种流程图；

图4为本发明实施例提供的一种订单处理方法的第三种流程图；

图5为本发明实施例提供的商品订单匹配的流程图；

图6为本发明实施例提供的一种订单处理装置的结构示意图；

图7为本发明实施例提供的一种订单处理系统的结构示意图；

图8为本发明实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

目前的玩家需要购买装备或者是其他游戏效果时，主要是基于客户端、游戏应用、支付服务器和供应商服务器的交互来实现，例如苹果手机，苹果手机上的游戏应用通过苹果官方的应用商店下载安装，对此，通过应用商店下载安装的所有应用，若需要付费时，都需要经过苹果服务器(即是供应商服务器)与游戏的支付系统进行交互，而在该交互的过程中，支付的主要操作和数据处理流程均是由客户端来完成，这就导致了客户端在运行游戏应用的同时还需要兼顾游戏中玩家角色的装备购买和与第三方服务器的交互，这就占用了客户端的CPU或者是GPU的资源，减低游戏应用的运行，影响游戏体验。基于此，本发明实施例提供的一种订单处理方法、装置、系统、设备及存储介质，该技术可以应用于手机、计算机、平板电脑、笔记本等设备。

为便于对本实施例进行理解，首先对本发明实施例所公开的一种订单处理方法进行详细介绍，该方法中涉及的客户端实际上是基于供应商服务器下载游戏应用后，在游戏应用运行过程中，由于玩家需要对玩家角色进行装备或者是特效的购买，这时会在游戏应用的界面中调取出装备或者特效的商品购买界面，该商品购买界面是通过请求供应商服务器来获取得到，玩家通过在该商品购买界面上操作以触发后续的支付、订单生成和匹配等操作。如图1所示，该方法包括如下步骤：

步骤S101，接收客户端上游戏应用产生的下单请求。

上述下单请求是客户端基于用户在游戏应用中触发的购买操作所产生的请求，如图2所示，用户在使用客户端登录游戏应用后，在游戏操作的过程中调出商品购买界面，在该商品购买界面中显示有不同的游戏角色配件，如装备、特效等，用户通过在商品购买界面中选择需要购买的目标商品，如通过在界面的图标区域上进行长按、双击、多指滑动、滑动指定形状或图案等操作，以选定目标商品，然后提取目标商品的相关信息以生成下单请求发送至游戏支付服务端。该下单请求中至少包括目标商品的相关信息、客户端的相关信息和用户信息，用户信息可以是玩家的账号信息和对应的角色信息，客户端的相关信息包括客户端自身的设备标识和由游戏支付服务端给的分配标识，该分配标识为唯一的不可修改的标识，用于后续在更换客户端时的订单匹配操作。

在本实施例中，对于客户端的分配标识具体是通过获取客户端通过标识接口发送的标识获取请求；

基于所述标识获取请求，利用标识生成的开源包生成所述客户端的分配标识，并返回给所述客户端缓存。

在实际应用中，玩家通过客户端登录游戏应用并触发装备或者特效等商品的购买时，游戏程序会通过客户端上的SDK给游戏支付端发送设备标识，而游戏支付服务端在获取到设备标识后基于开源包来生成一个不可修改的分配标识，同时该分配标识同步回给客户端，即是同步至SDK。

在另一种实施方式中，该分配标识还可以是直接由SDK来生成，即是SDK为开源的软件开发工具包，通过该软件开发工具包直接读取客户端的移动设备号，然后通过调用get_gb_deviceid接口，成功后就把gb_deviceid存起来。gb_deviceid是用github.com/google/uuid开源包生成的，并且支付系统会保证gb_deviceid唯一性，其中，每个客户端只会调用一次get_gb_deviceid接口。

步骤S102，根据下单请求生成目标商品的订单号，并通过客户端将订单号添入预设的透传参数中发送至供应商服务器。

上述下单请求中至少包括所述客户端的设备标识和分配标识，以及目标商品信息和玩家信息。通过解析下单请求中携带的目标商品信息生成订单上的商品字段，从而创建出订单，并提取订单中的订单号返回给客户端，即是返回给SDK进行转发支付和/或存储记录。

进一步的，游戏支付服务端还将订单和订单号与设备标识、分配标识和玩家信息进行关联，得到一条订单记录。

在本实施例中，在客户端接收到游戏支付服务端返回的订单号后，解析预设的透传参数，并将订单号写入至透传参数中对应的字段上，得到带有订单信息的透传参数，然后转发给供应商服务器。

上述转发给供应商服务器，具体是通过调起供应商服务器的支付流程，然后将透传参数发送给供应商服务器，供应商服务器并针对该支付流程对支付确认，并在确认后或者是在启动支付确认若干时间后，向客户端返回支付信息。

步骤S103，接收客户端通过回调接口回调供应商服务器返回的支付信息。

本实施例中，客户端在接收到供应商服务器回调的支付响应后，解析支付响应反馈的支付信息，然后调起回调接口将支付信息轮询给游戏支付服务端，而游戏支付服务端在接收到回调接口发送的支付信息后，基于支付信息进行订单的匹配。

在实际应用中，客户端除了通过回调接口同步支付信息之外，还可以通过现有的交互协议同步透传参数，游戏支付服务端接收到该透传参数后执行订单匹配操作，其中该透传参数为客户端接收到支付信息后将其与支付信息中的支付凭证一起通过交互协议发送给游戏支付服务端。

步骤S104，根据支付信息进行商品订单的匹配，并将匹配的结果返回至游戏应用和供应商服务器。

上述支付信息包括但不局限于支付凭证、设备标识和/或分配标识。

本实施例中，游戏支付服务端在接收到支付信息后，启动订单匹配流程，解析支付信息中的支付凭证、所述设备标识和/或所述分配标识，然后选择所述设备标识和所述分配标识中与预设的匹配策略中优先级匹配的一个标识进行订单匹配，最后基于匹配的结果向游戏应用和供应商服务器返回购买的信息，其中，返回游戏应用具体是返回给SDK。

在实际应用中，在执行所述设备标识和所述分配标识的匹配之前，先利用透传参数进行订单匹配，在匹配失败后，执行所述设备标识和所述分配标识进行订单匹配。

本发明实施例提供了一种订单处理方法，接收客户端上游戏应用产生的下单请求；根据下单请求生成目标商品的订单号，并通过客户端将订单号添入预设的透传参数中发送至供应商服务器；接收客户端通过回调接口回调供应商服务器返回的支付信息；根据支付信息进行商品订单的匹配，并将匹配的结果返回至游戏应用和供应商服务器。该方式中，通过服务器来实现游戏应用内的订单支付匹配操作，以减少客户端对游戏应用的数据处理量，提高用户对游戏应用的使用体验，并且设置了回调接口以保证支付信息的轮询，避免了支付过程中信息的丢失。

在本发明的另一实施例中，该方法主要应用于订单处理系统，该系统包括客户端，支付装置和供应商服务器，其中客户端通过供应商服务端下载安装游戏应用，在所述游戏应用上显示有供应商服务器提供的商品购买界面，如图3所示，该方法包括以下步骤：

步骤S301，响应针对客户端上游戏应用的购买操作，基于所购买操作生成下单请求。

在上述游戏应用上显示有供应商服务器提供的商品购买界面；客户端上的SDK通过响应用户/玩家在商品购买界面上的触控操作，该触控操作可以是点击、长按或者是滑动，基于该触控操作的位置来选定对应的目标商品，基于目标商品的图标从供应商服务器上获取目标商品信息，如目标商品ID、名称等相关信息，然后写入至请求中，同时在请求还增加有客户端的设备标识udid和分配标识uudi，其中该分配标识是基于开源包生成的一个不可修改的标识。在实际应用中，对于分配标识uuid是通过调起get_gb_deviceid接口来得到。

步骤S302，根据下单请求生成目标商品的订单号。

上述下单请求包括所述客户端的设备标识和分配标识，以及目标商品信息和玩家信息。

对于生成目标商品的订单号具体是基于所述设备标识、所述分配标识、所述目标商品信息和所述玩家信息创建目标商品的订单，得到订单号。

在实际应用中，得到订单号具体是基于目标商品信息构建订单，提取订单中的订单号，然后将所述设备标识、所述分配标识和所述订单号生成目标商品订单记录，并存储于所述游戏支付服务端的缓存中。

在本实施例中，上述客户端的分配标识uuid具体是通过调用get_gb_deviceid接口，利用开源包生成，即是客户端调用一次get_gb_deviceid接口，通过该接口利用github.com/google/uuid开源包生成的gb_deviceid并存起来，同时上报给游戏支付服务端，从而保证gb_deviceid唯一性。

其中，get_gb_deviceid接口协议如下：

请求协议：

http POST

Content-Type:application/json

Accept:application/json

请求参数：

返回值：

步骤S303，将订单号添入预设的透传参数，并请求支付操作。

本实施例中，客户端中的SDK接收到游戏支付服务端回传的订单号后，将订单号写入至透传参数applicationUsername中，并基于该透传参数与供应商服务器中的支付订单进行关联，具体是基于该透传参数调起供应商服务器的支付流程，在用户确认支付后，供应商服务器通过支付回调机制向客户端返回支付信息，该支付信息至少包括支付凭证、设备标识和/或分配标识。

进一步的，客户端通过回调接口将支付信息转发至游戏支付服务端，以用于订单的匹配。

步骤S304，接收通过回调接口回调的基于支付操作产生的支付信息。

上述回调接口具体为upload_transaction接口，该接口协议如下：

请求协议：

http POST

Content-Type:application/json

Accept:application/json

请求参数：

transaction字段的参数如下：

返回值：

步骤S305，判断支付信息中是否存在支付凭证。

步骤S306，若支付信息中存在支付凭证，获取客户端的透传参数，并基于透传参数进行商品订单的匹配。

本实施例中，游戏支付服务端有专门的后台协程负责轮询支付凭证并执行匹配算法，这样就不会影响到upload_transaction接口性能。匹配算法包含了三种策略，其中优先使用透传参数applicationUsername来匹配；applicationUsername匹配失败就会使用游戏支付服务端生成的分配标识gb_deviceid和商品信息来匹配；如果还是匹配失败，则会使用设备udid和商品信息来匹配。具体执行流程如图5所示。

步骤S307，若透传参数匹配失败，则基于设备标识和分配标识进行商品订单的匹配。

本实施例中，首先基于所述分配标识进行商品订单的匹配；若匹配失败，则基于所述设备标识进行商品订单的匹配。

具体的，在基于透传参数进行订单匹配时，实际上是识别透传参数是否为空，若为空，则解析透传参数，并对透传参数中的数据格式进行校验，若校验不通过或者是透传参数不为空，则执行步骤S307，反之则执行基于透传参数中的订单号，与游戏支付服务端中缓存的订单记录中进行匹配，从而得到匹配的结果，并确定是否需要删除对应的订单记录。

进一步的，执行步骤S307时，具体是applicationUsername匹配失败就会使用支付系统生成的gb_deviceid和商品信息来匹配；如果还是匹配失败，则会使用设备udid和商品信息来匹配。

步骤S308，将匹配的结果返回至游戏应用和供应商服务器。

本实施例中，在客户端进行支付的操作过程中，由于网络或者是客户端的问题需要更换新的客户端时，在供应商服务器会不断地重试回调支付信息，识别玩家更换设备前有没有调用upload_transaction，如果调用了upload_transaction，则支付系统就能够用gb_deviceid匹配到订单，并给玩家发货；如果没有调用，那么玩家会在新设备调用upload_transaction，用gb_deviceid就匹配不到了，这种情况下，只能用applicationUsername来匹配，如果applicationUsername也为空，就匹配不到订单了。

下面结合具体是订单处理系统对上述提供的订单处理方法进行说明，如图4所示，游戏支付服务端掉用户get_gb_deviceid接口，并利用github.com/google/uuid开源包生成的分配标识gb_deviceid，并将gb_deviceid返回给客户端缓存，客户端SDK实时从苹果服务器中获取商品信息，并显示在客户端的游戏应用的商品购买界面，基于用户的购买操作确定目标商品后，苹果服务器返回商品信息的数组，客户端SDK基于返回的数组请求下单，并将目标商品信息、udid、gb_deviceid和用户信息请求游戏支付服务端创建订单，游戏支付服务端创建订单，跌倒订单号后，客户端SDK获取到订单号并将其写入至透传参数applicationUsername中，调起苹果支付流程，在用户确认后，返回支付信息，游戏支付服务端通过调用upload_transaction接口回调支付信息，并执行订单匹配流程，在匹配成功后，存储支付凭证，并返回支付完成的信息给SDK和苹果服务器。

为了解决玩家更换客户端而丢失支付信息的问题，增加了get_gb_deviceid接口和upload_transaction接口，依靠苹果服务器的支付回调重试机制，可以保证游戏支付系统一定会收到支付凭证。原理是，苹果在收到finishTransaction调用前，会一直重试，即使玩家换设备，SDK也能够收到苹果回调，并上传凭证到游戏支付系统。游戏支付系统匹配订单成功，就能给玩家发货。

而新增凭证上传接口upload_transaction，用于将苹果支付所产生的相关参数都尽可能地发送给服务器，为了支持苹果重复回调，upload_transaction接口也具备幂等性。

综上，通过对上述方法的实施，接收客户端上游戏应用产生的下单请求；根据下单请求生成目标商品的订单号，并通过客户端将订单号添入预设的透传参数中发送至供应商服务器；接收客户端通过回调接口回调供应商服务器返回的支付信息；根据支付信息进行商品订单的匹配，并将匹配的结果返回至游戏应用和供应商服务器。这样的方法，要服务端升级，订单匹配逻辑就可以立即生效，三种匹配算法同时工作，提高了苹果支付的稳定性，降低了丢单率。同时服务端也能够知道客户端支付时发生的异常情况，更方便对这些异常数据作系统地分析然后反哺到优化整个支付系统上，形成一个良性循环并且减少公司在处理这种逻辑上的人力成本。

对应上述方法实施例，本发明实施例提供了一种订单处理装置，如图6所示，该装置包括：

接收模块601，用于接收客户端上游戏应用产生的下单请求；

生成模块602，用于根据所述下单请求生成目标商品的订单号，并通过所述客户端将所述订单号添入预设的透传参数中发送至供应商服务器；

回调模块603，用于接收所述客户端通过回调接口回调所述供应商服务器返回的支付信息；

匹配模块604，用于根据所述支付信息进行商品订单的匹配，并将匹配的结果返回至所述游戏应用和供应商服务器。

本发明实施例提供了一种订单处理装置，通过接收客户端上游戏应用产生的下单请求；根据下单请求生成目标商品的订单号，并通过客户端将订单号添入预设的透传参数中发送至供应商服务器；接收客户端通过回调接口回调供应商服务器返回的支付信息；根据支付信息进行商品订单的匹配，并将匹配的结果返回至游戏应用和供应商服务器。该方式中，通过将客户端定义为转发节点，将支付相关的操作流程在游戏支付服务端执行，以减少了客户端的数据处理量，保证客户端对游戏应用的运行，并且设置了回调接口以保证支付信息的轮询，避免了支付过程中信息的丢失。

上述订单处理装置还包括：标识生成模块605，用于：

获取客户端通过标识接口发送的标识获取请求；

基于所述标识获取请求，利用标识生成的开源包生成所述客户端的分配标识，并返回给所述客户端缓存。

上述下单请求中至少包括所述客户端的设备标识和分配标识，以及目标商品信息和玩家信息。

上述生成模块602具体用于：

基于所述设备标识、所述分配标识、所述目标商品信息和所述玩家信息创建目标商品的订单，得到订单号。

上述订单处理装置还包括：存储模块606，用于：

将所述设备标识、所述分配标识和所述订单号生成目标商品订单记录，并存储于所述游戏支付服务端的缓存中。

上述支付信息至少包括支付凭证、设备标识和/或分配标识。

上述匹配模块604具体用于：

若所述支付信息中存在所述支付凭证，获取所述客户端的透传参数，并基于所述透传参数进行商品订单的匹配，并将匹配的结果返回至所述游戏应用和供应商服务器。

上述匹配模块604还用于：

若所述透传参数匹配失败，则基于所述设备标识和所述分配标识进行商品订单的匹配。

上述匹配模块604具体用于：

基于所述分配标识进行商品订单的匹配；

若匹配失败，则基于所述设备标识进行商品订单的匹配。

本发明实施例提供的订单处理装置，与上述实施例提供的订单处理方法具有相同的技术特征，所以也能解决相同的技术问题，达到相同的技术效果。

对应上述方法实施例，本发明实施例提供了一种订单处理系统，如图7所示，该系统包括：

安装有游戏应用的客户端701，支付装置702和供应商服务器703；其中，在所述游戏应用上显示有供应商服务器提供的商品购买界面；

所述客户端701响应针对游戏应用的购买操作，基于所述购买操作生成下单请求；

所述支付装置702根据所述下单请求生成目标商品的订单号；

所述客户端701将所述订单号添入预设的透传参数，并向所述供应商服务器请求支付操作；

所述支付装置702接收通过回调接口回调的所述供应商服务器703基于所述支付操作产生的支付信息；

所述支付装置702根据所述支付信息进行商品订单的匹配，并将匹配的结果返回至所述游戏应用和所述供应商服务器703。

上述客户端701具体用于：

响应针对游戏应用上的商品购买界面触控操作，确定目标商品信息；

根基所述目标商品信息、客户端的设备标识和分配标识和玩家信息，构建下单请求；其中，所述客户端的分配标识基于标识生成的开源包生成，所述设备标识为自身的设备号。

综上，该订单处理系统通过接收客户端上游戏应用产生的下单请求；根据下单请求生成目标商品的订单号，并通过客户端将订单号添入预设的透传参数中发送至供应商服务器；接收客户端通过回调接口回调供应商服务器返回的支付信息；根据支付信息进行商品订单的匹配，并将匹配的结果返回至游戏应用和供应商服务器。该方式中，通过将客户端定义为转发节点，将支付相关的操作流程在游戏支付服务端执行，以减少了客户端的数据处理量，保证客户端对游戏应用的运行，并且设置了回调接口以保证支付信息的轮询，避免了支付过程中信息的丢失。

本实施例还提供一种电子设备，包括处理器和存储器，存储器存储有能够被处理器执行的机器可执行指令，处理器执行机器可执行指令以实现上述订单处理方法。该电子设备可以是服务器，也可以是终端设备。

参见图8所示，该电子设备包括处理器100和存储器101，该存储器101存储有能够被处理器100执行的机器可执行指令，该处理器100执行机器可执行指令以实现上述订单处理方法。

进一步地，图8所示的电子设备还包括总线102和通信接口103，处理器100、通信接口103和存储器101通过总线102连接。

其中，存储器101可能包含高速随机存取存储器(RAM，Random Access Memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个通信接口103(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。总线102可以是ISA总线、PCI总线或EISA总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

处理器100可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器100中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器100可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DigitalSignal Processor，简称DSP)、专用集成电路(Application Specific IntegratedCircuit，简称ASIC)、现场可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器101，处理器100读取存储器101中的信息，结合其硬件完成前述实施例的方法的步骤。

上述电子设备中的处理器，通过执行机器可执行指令，可以实现上述订单处理方法中的下述操作：

接收客户端上游戏应用产生的下单请求；

根据所述下单请求生成目标商品的订单号，并通过所述客户端将所述订单号添入预设的透传参数中发送至供应商服务器；

接收所述客户端通过回调接口回调所述供应商服务器返回的支付信息；

根据所述支付信息进行商品订单的匹配，并将匹配的结果返回至所述游戏应用和供应商服务器。

上述在接收客户端上游戏应用产生的下单请求的步骤之前，还包括：

获取客户端通过标识接口发送的标识获取请求；

基于所述标识获取请求，利用标识生成的开源包生成所述客户端的分配标识，并返回给所述客户端缓存。

上述下单请求中至少包括所述客户端的设备标识和分配标识，以及目标商品信息和玩家信息。

上述根据所述下单请求生成目标商品的订单号的步骤，包括：

基于所述设备标识、所述分配标识、所述目标商品信息和所述玩家信息创建目标商品的订单，得到订单号。

上述在基于所述设备标识、所述分配标识、所述目标商品信息和所述玩家信息创建目标商品的订单，得到订单号的步骤之后，还包括：

将所述设备标识、所述分配标识和所述订单号生成目标商品订单记录，并存储于所述游戏支付服务端的缓存中。

上述支付信息至少包括支付凭证、设备标识和/或分配标识。

上述根据所述支付信息进行商品订单的匹配，并将匹配的结果返回至所述游戏应用和供应商服务器的步骤，包括：

若所述支付信息中存在所述支付凭证，获取所述客户端的透传参数，并基于所述透传参数进行商品订单的匹配，并将匹配的结果返回至所述游戏应用和供应商服务器。

上述根据所述支付信息进行商品订单的匹配，并将匹配的结果返回至所述游戏应用和供应商服务器的步骤，还包括：

若所述透传参数匹配失败，则基于所述设备标识和所述分配标识进行商品订单的匹配。

上述基于所述设备标识和所述分配标识进行商品订单的匹配的步骤，包括：

基于所述分配标识进行商品订单的匹配；

若匹配失败，则基于所述设备标识进行商品订单的匹配。

上述电子设备中的处理器，通过执行机器可执行指令，还可以实现上述订单处理方法中的下述操作：

响应针对客户端上游戏应用的购买操作，基于所述购买操作生成下单请求，其中在所述游戏应用上显示有供应商服务器提供的商品购买界面；

根据所述下单请求生成目标商品的订单号；

将所述订单号添入预设的透传参数，并请求支付操作；

接收通过回调接口回调的基于所述支付操作产生的支付信息；

根据所述支付信息进行商品订单的匹配，并将匹配的结果返回至所述游戏应用和所述供应商服务器。

上述响应针对客户端上游戏应用的购买操作，基于所述购买操作生成下单请求的步骤，包括：

响应针对游戏应用上的商品购买界面触控操作，确定目标商品信息；

根基所述目标商品信息、客户端的设备标识和分配标识和玩家信息，构建下单请求；其中，所述客户端的分配标识基于标识生成的开源包生成，所述设备标识为自身的设备号。

该方式中，通过将客户端定义为转发节点，将支付相关的操作流程在游戏支付服务端执行，以减少了客户端的数据处理量，保证客户端对游戏应用的运行，并且设置了回调接口以保证支付信息的轮询，避免了支付过程中信息的丢失。

本实施例还提供一种机器可读存储介质，机器可读存储介质存储有机器可执行指令，机器可执行指令在被处理器调用和执行时，机器可执行指令促使处理器实现上述订单处理方法。

上述机器可读存储介质存储中的机器可执行指令，通过执行该机器可执行指令，可以实现上述订单处理方法中的下述操作：

接收客户端上游戏应用产生的下单请求；

根据所述下单请求生成目标商品的订单号，并通过所述客户端将所述订单号添入预设的透传参数中发送至供应商服务器；

接收所述客户端通过回调接口回调所述供应商服务器返回的支付信息；

根据所述支付信息进行商品订单的匹配，并将匹配的结果返回至所述游戏应用和供应商服务器。

上述在接收客户端上游戏应用产生的下单请求的步骤之前，还包括：

获取客户端通过标识接口发送的标识获取请求；

基于所述标识获取请求，利用标识生成的开源包生成所述客户端的分配标识，并返回给所述客户端缓存。

上述下单请求中至少包括所述客户端的设备标识和分配标识，以及目标商品信息和玩家信息。

上述根据所述下单请求生成目标商品的订单号的步骤，包括：

基于所述设备标识、所述分配标识、所述目标商品信息和所述玩家信息创建目标商品的订单，得到订单号。

上述在基于所述设备标识、所述分配标识、所述目标商品信息和所述玩家信息创建目标商品的订单，得到订单号的步骤之后，还包括：

将所述设备标识、所述分配标识和所述订单号生成目标商品订单记录，并存储于所述游戏支付服务端的缓存中。

上述支付信息至少包括支付凭证、设备标识和/或分配标识。

上述根据所述支付信息进行商品订单的匹配，并将匹配的结果返回至所述游戏应用和供应商服务器的步骤，包括：

若所述支付信息中存在所述支付凭证，获取所述客户端的透传参数，并基于所述透传参数进行商品订单的匹配，并将匹配的结果返回至所述游戏应用和供应商服务器。

上述根据所述支付信息进行商品订单的匹配，并将匹配的结果返回至所述游戏应用和供应商服务器的步骤，还包括：

若所述透传参数匹配失败，则基于所述设备标识和所述分配标识进行商品订单的匹配。

上述基于所述设备标识和所述分配标识进行商品订单的匹配的步骤，包括：

基于所述分配标识进行商品订单的匹配；

若匹配失败，则基于所述设备标识进行商品订单的匹配。

上述电子设备中的处理器，通过执行机器可执行指令，还可以实现上述订单处理方法中的下述操作：

响应针对客户端上游戏应用的购买操作，基于所述购买操作生成下单请求，其中在所述游戏应用上显示有供应商服务器提供的商品购买界面；

根据所述下单请求生成目标商品的订单号；

将所述订单号添入预设的透传参数，并请求支付操作；

接收通过回调接口回调的基于所述支付操作产生的支付信息；

根据所述支付信息进行商品订单的匹配，并将匹配的结果返回至所述游戏应用和所述供应商服务器。

上述响应针对客户端上游戏应用的购买操作，基于所述购买操作生成下单请求的步骤，包括：

响应针对游戏应用上的商品购买界面触控操作，确定目标商品信息；

根基所述目标商品信息、客户端的设备标识和分配标识和玩家信息，构建下单请求；其中，所述客户端的分配标识基于标识生成的开源包生成，所述设备标识为自身的设备号。

该方式中，通过将客户端定义为转发节点，将支付相关的操作流程在游戏支付服务端执行，以减少了客户端的数据处理量，保证客户端对游戏应用的运行，并且设置了回调接口以保证支付信息的轮询，避免了支付过程中信息的丢失。

本发明实施例所提供的订单处理方法、装置以及系统的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

另外，在本发明实施例的描述中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。

最后应说明的是：以上实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。