游戏订单生成方法、游戏订单支付方法、装置和设备

技术领域

本申请涉及云游戏技术领域，具体而言，本申请涉及一种游戏订单生成方法、游戏订单支付方法、装置和设备。

背景技术

云游戏是将原本运行在用户端(即本地)的游戏实例移到云游戏服务端上运行，用户端只是通过网络将用户端的操作实时传输到运行于云游戏服务端的游戏服务组件(GameService，GS)，GS与对应的游戏实例处于相同的系统环境，例如，同一云游戏服务端环境中有多台云手机，GS和对应的游戏实例需要处于同一云手机的系统环境中。进而GS可基于接收到的用户操作相应地操控游戏实例，使得游戏实例响应于用户操作，GS同时捕获游戏实例的运行结果并将游戏的运行结果以视音频流的方式实时地传输至用户端，在用户端上呈现出游戏的画面和声音。也即，在云游戏过程中，基于用户端与GS实时地网络通讯，用户可以基于GS实现对运行于云游戏服务端的游戏实例的操控，在网络满足的前提下(通常4G网络可以满足)，上述操控近似于用户直接操作运行于本地的游戏客户端时的效果。

由于在云游戏中，原本运行于本地的游戏实例移到云游戏服务端上运行，而目前的支付应用仍然运行于本地，以致游戏实例不能调用支付应用以获得用户的支付确认，进而不能完成游戏订单的支付。

此外，云游戏为了保证用户端与GS之间的网络通讯的实时效果，云游戏服务端需要基于用户端的网络运营商、地域等信息选择合适的GS和游戏实例为用户端提供良好的服务。也即，用户在不同地点通过用户端使用云游戏时，云游戏服务端会调度相应地点的GS和游戏实例，为用户提供云游戏的服务。即使将支付应用也移至云游戏服务端运行，可以解决游戏实例不能调用支付应用的问题，但也需要选择与游戏实例相应地点的相同云游戏服务端环境来运行支付应用(只有这样，在用户支付确认时，支付应用才能被游戏实例调用)，不可避免地让用户在不同地点使用支付应用为云游戏进行支付确认时，需要重新登录支付应用的账号(因为不同云游戏服务端环境下运行的支付应用，实际上就是支付应用的不同实例，所以需要用户重新登录支付应用的账号)，这样会造成用户使用云游戏进行支付时的诸多不便、用户使用习惯的改变、以及账号信息因此存在于多个云游戏服务端环境带来的同步难度和安全隐患。

发明内容

本申请的目的旨在至少能解决上述的技术缺陷之一，特提出以下技术方案：

第一方面，本申请的至少一个实施例提供了一种游戏订单生成方法，应用于游戏后端服务器，所述方法包括：

获取物品购买请求，所述物品购买请求包括物品清单、请求端所属的渠道标识；

确定与所述渠道标识对应的中心服务端；

向所述中心服务端发送订单号获取请求；

接收所述中心服务端发送的订单号；

基于所述订单号和所述物品清单，生成订单信息。

在一些实施例中，所述请求端基于游戏服务组件操控游戏实例，所述操控包括物品选择操作及购买操作；

所述物品购买请求为所述游戏实例响应所述购买操作而生成的请求；

所述物品清单为所述游戏实例基于所述物品选择操作而确定的清单。

在一些实施例中，所述物品清单包括：

一个或多个物品标识、每个所述物品标识对应的物品数量和物品单价。

在一些实施例中，所述物品购买请求还包括游戏实例标识；

所述方法还包括：将所述订单信息、所述游戏实例标识、所述游戏实例标识已登录的游戏账号标识进行关联。

在一些实施例中，所述订单号为所述中心服务端基于所述订单号获取请求生成的订单号。

在一些实施例中，所述物品购买请求还包括游戏实例所属的游戏标识；

所述订单号获取请求包括所述游戏标识；

所述中心服务端生成所述订单号并将所述订单号保存至所述游戏标识对应的游戏信息表中。

在一些实施例中，所述订单信息包括所述订单号、所述物品清单中每个物品标识对应的物品信息、所述物品清单中所有物品的总价。

在一些实施例中，所述物品购买请求为游戏实例生成的请求；所述方法还包括：

响应所述物品购买请求而反馈物品购买响应给所述游戏实例，所述物品购买响应包括所述订单信息。

第二方面，本申请的至少一个实施例提供了一种游戏订单支付方法，应用于请求端，所述方法包括：

获取游戏订单支付请求，所述游戏订单支付请求包括订单信息；所述订单信息为游戏后端服务器基于第一方面所述游戏订单生成方法任一实施例生成的订单信息；

响应所述游戏订单支付请求而调用本地的支付应用，由所述支付应用对应的支付服务端完成订单支付。

在一些实施例中，所述游戏订单支付请求为游戏实例基于所述订单信息而生成，所述订单信息由所述游戏后端服务器发送给所述游戏实例，且所述游戏实例基于游戏服务组件向所述请求端发送所述游戏订单支付请求。

在一些实施例中，所述完成订单支付后，所述方法还包括：

所述游戏后端服务器接收中心服务端发送的支付结果，所述支付结果包括订单号；所述支付结果为所述支付服务端向所述中心服务端发送的支付结果。

在一些实施例中，所述方法还包括：

所述游戏后端服务器基于所述订单号确定订单信息、游戏实例标识和游戏账号标识；

所述游戏后端服务器将所述订单信息中购买的各物品信息更新至所述游戏账号标识对应的游戏账号信息中；

所述游戏后端服务器向所述游戏实例标识对应的游戏实例发送发货通知，所述发货通知包括所述订单信息中购买的各物品信息。

第三方面，本申请的至少一个实施例提供了一种游戏订单生成装置，应用于游戏后端服务器，所述装置包括：

获取单元，用于获取物品购买请求，所述物品购买请求包括物品清单、请求端所属的渠道标识；

确定单元，用于确定与所述渠道标识对应的中心服务端；

发送单元，用于向所述中心服务端发送订单号获取请求；

接收单元，用于接收所述中心服务端发送的订单号；

生成单元，用于基于所述订单号和所述物品清单，生成订单信息。

第四方面，本申请的至少一个实施例提供了一种游戏订单支付装置，应用于请求端，所述装置包括：

获取单元，用于获取游戏订单支付请求，所述游戏订单支付请求包括订单信息；所述订单信息为游戏后端服务器基于权利要求1至8任一项所述方法生成的订单信息；

调用单元，用于响应所述游戏订单支付请求而调用本地的支付应用，由所述支付应用对应的支付服务端完成订单支付。

第五方面，本申请的至少一个实施例提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述的游戏订单生成方法或游戏订单支付方法中的任一实施例。

第四方面，本申请的至少一个实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述的游戏订单生成方法或游戏订单支付方法中的任一实施例。

本申请的至少一个实施例中，游戏后端服务器通过获取物品购买请求，得到物品购买请求包括的物品清单和请求端所属的渠道标识，进而可确定与渠道标识对应的中心服务端，从而可向中心服务端发送订单号获取请求，在接收到中心服务端发送的订单号获取响应后，可得到订单号获取响应包括的订单号，从而基于订单号和物品清单，生成订单信息，这样，游戏实例可基于游戏服务组件向请求端发送包括订单信息的游戏订单支付请求，以使请求端响应游戏订单支付请求而调用本地的支付应用，以获得用户的支付确认，进而由支付应用对应的支付服务端完成订单支付。既解决了游戏实例不能调用运行于本地的支付应用的问题，又避免了将支付应用移到云游戏服务端上运行而造成的诸多不便、用户使用习惯的改变、以及账号信息因此存在于多个云游戏服务端环境带来的同步难度和安全隐患。

本申请附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本申请实施例提供的一种应用场景的示意图；

图2为本申请实施例提供的一种游戏订单生成装置的框图；

图3为本申请实施例提供的一种游戏订单支付装置的框图；

图4为本申请实施例提供的一种游戏订单生成及支付过程中的多端交互图；

图5为本申请实施例提供的一种电子设备的框图；

图6为本申请实施例提供的一种游戏订单生成方法的流程图；

图7为本申请实施例提供的一种游戏订单支付方法的流程图。

具体实施方式

下面详细描述本申请的实施例，实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本申请的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。这里使用的诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。为使本申请的目的、技术方案和优点更加清楚，下面将结合附图，对本申请的实施例进行描述。

本申请的至少一个实施例中，基于用户端与游戏服务组件(Game Service，GS)实时地网络通讯，游戏实例可基于GS向请求端发送包括订单信息的游戏订单支付请求，以使请求端响应游戏订单支付请求而调用本地的支付应用，以获得用户的支付确认，从而由支付应用对应的支付服务端完成订单支付。既解决了游戏实例不能调用运行于本地的支付应用的问题，又避免了将支付应用移到云游戏服务端上运行而造成的诸多不便、用户使用习惯的改变、以及账号信息因此存在于多个云游戏服务端环境带来的同步难度和安全隐患。

本申请的至少一个实施例中，游戏后端服务器通过获取物品购买请求，得到物品购买请求包括的物品清单和请求端所属的渠道标识，进而可确定与渠道标识对应的中心服务端(Business Service，BS)，从而可向中心服务端发送订单号获取请求，在接收到中心服务端发送的订单号获取响应后，可得到订单号获取响应包括的订单号，从而基于订单号和物品清单，生成订单信息，这样，游戏实例可基于GS向请求端发送包括订单信息的游戏订单支付请求，以使请求端响应游戏订单支付请求而调用本地的支付应用，以获得用户的支付确认，由支付应用对应的支付服务端完成订单支付。

图1为本申请实施例提供的一种应用场景的示意图。在图1中，请求端11与GS实时地网络通讯，请求端11可基于GS操控云端(即云游戏服务端)的游戏实例12，其中，游戏实例12与GS的对应关系可以基于现有云游戏调度方法实现对应。用户使用(游玩)云游戏的过程中，可以基于请求端11随时通过GS操控云端的游戏实例12来挑选想购买的游戏内物品、并确认购买。游戏实例12可通过网络与游戏后端服务器13进行数据交互；游戏后端服务器可通过网络与中心服务端14进行数据交互。其中，中心服务端14即业务服务组件(BusinessService，BS)，属于云游戏服务端的一部分，可以理解为云游戏服务端的服务资源调度过程中的全局调度服务端，其对应于云游戏的整体云端服务资源，至少用于提供云游戏服务端的外部访问入口。

请求端

请求端11可以是任一可以安装游戏客户端软件的电子设备。例如，请求端11可以为运维页面、运维服务端自身、用户端(User Agent，UA)等。其中，运维服务端对游戏进行运行维护，例如可以更新游戏、测试游戏等。用户端是能够访问云游戏服务端的任意设备，例如，用户端可以是安装有用于访问云游戏服务端的软件的任意设备，其中，用于访问云游戏服务端的软件也可以理解为用户端的软件实现。

在一些实施例中，用户端可包括但不限于：瘦客户端、通用计算机、专用计算机、游戏控制台、个人计算机、膝上型计算机、平板计算设备、移动计算设备、便携式游戏设备、蜂窝电话、智能手机、笔记本电脑、头戴式显示器、智能可穿戴设备、机顶盒、流媒体接口/设备、智能电视或联网显示器等。

在一些实施例中，用户端至少用于访问云游戏服务端的云游戏，接收用户输入的游戏操作，并生成相应的操作指令，进而将操作指令实时传输到运行于云游戏服务端的游戏服务组件(Game Service，GS)。用户可通过用户端访问云游戏服务端的云游戏列表，选择云游戏。在一些实施例中，当有多个云游戏服务端时，多个云游戏服务端可分布于不同地区，用户通过用户端访问用户所在地区对应的云游戏服务端。

在一些实施例中，云游戏服务端可以是能够运行云游戏程序的任意设备，例如可以是安装有云游戏程序以及提供云游戏服务的软件的任意设备，这里的提供云游戏服务的软件也可以理解为云游戏服务端的软件实现。

在一些实例中，云游戏服务端可以是单个服务器，也可以是服务器集群，服务器群组可以为集中式的，也可以为分布式的。在一些实施例中，云游戏服务端可以是远程服务器、虚拟计算机、云游戏服务器、云应用服务器、远程应用服务器、数字媒体服务器、用于提供游戏开发者/游戏赞助商店面(storefront)的服务器、网站服务器、终端服务器、控制台服务器等。

在一些实施例中，云游戏服务商可以将云游戏部署在云游戏服务集群中，云游戏服务集群的节点服务器上可以运行有云游戏程序，多个云游戏服务端属于云游戏服务器集群。本实施例中，用户可以通过用户端访问云游戏服务端，并由其为用户端调度用户所在地区对应的节点服务器登录云游戏，以及用户在用户端上进行游戏操作，从而用户端可以将相应的操作指令上传到节点服务器。之后，节点服务器可以基于云游戏程序的执行逻辑，结合操作指令计算并生成游戏画面，然后将游戏画面反馈给用户端进行显示。

游戏实例

游戏实例可以理解为游戏客户端运行时的实例，在游戏实例启动后将产生相应的音画信息。具体来说，云端的游戏实例可以是将游戏客户端进行云端化并运行于云端而得到，图1中的游戏实例12即为云端的游戏实例。为了明确区分本地的和云端的游戏实例，在本文中，将运行于云端的游戏实例统称为游戏实例，将运行于本地的游戏实例统称为游戏客户端。

因此，游戏客户端是直接安装、运行在本地用户终端设备(属于请求端11的一种)上的，用户启动游戏后，用户可以直接获取到本地的游戏客户端运行产生的音画信息。而要使用户能通过用户终端设备获取到云端的游戏实例12运行产生的音画信息，则需要游戏服务组件(Game Service，GS)将对应的云端游戏实例产生的音画信息转发给用户终端设备。具体来说，GS主动捕获对应的云端游戏实例产生的音画信息，并对捕获到的音画信息按预设方式进行编码后转发给用户终端设备，用户终端设备对接收到音画信息进行同步播放。

游戏服务组件

游戏服务组件(Game Service，GS)，运行于云游戏服务端，也即GS属于云游戏服务端的一部分。GS用于控制游戏实例12，为用户端提供云游戏服务，例如用户端可基于GS操控游戏实例12。在一些实施例中，GS会在启动前(通过运维系统或人员)配置其支持的渠道的渠道标识、其所属区域的区域信息和其对应的运营商信息、以及其支持的游戏标识列表。

在一些实施例中，GS用于控制游戏实例12，为用户端提供云端服务资源来执行云游戏、编码云游戏的视频帧音频帧以及将编码的视频帧音频帧流式传输到游戏客户端以用于渲染和用户交互。在一些实施例中，GS至少用于获取游戏客户端上传的操作指令，并基于云游戏程序的执行逻辑，结合操作指令计算并生成游戏画面，然后将游戏画面反馈给用户端进行显示。在一些实施例中，云游戏服务端可以为软件装置、硬件装置或者软硬件结合的装置。

在一些实施例中，GS与游戏实例12处于相同的系统环境，也即GS与游戏实例12被部署和运行于同一台云端设备上，该云端设备可以是虚机(比如云手机，即1台物理服务器中虚拟出的多台云手机中的1台)、也可以是物理服务器。

游戏后端服务器

游戏后端服务器13是与游戏客户端对应的同款游戏的服务端。需要说明的是，游戏前端原本指网页页面，现在也可以泛指用户侧的应用界面和逻辑，也能涵盖游戏客户端。后端多指业务接口、代码、数据库等。

云游戏行业里目前还没有关于“前端服务器”的标准定义，但是通过虚拟化技术来运行游戏客户端的服务器，可以看作是“前端服务器”的一种，所以运行GS和游戏实例的服务器，可以看作是“游戏前端服务器”，因此，与游戏客户端对应的同款游戏的服务端可以看作是“游戏后端服务器”。

图2为本申请实施例提供的一种游戏订单生成装置20的框图。在一些实施例中，游戏订单生成装置20可以实现为图1中的游戏后端服务器13或者游戏后端服务器13的一部分。如图2所示，游戏订单生成装置20可包括但不限于以下单元：获取单元21、确定单元22、发送单元23、接收单元24和生成单元25。各单元具体描述如下：

获取单元

获取单元21，用于获取物品购买请求，物品购买请求包括物品清单、请求端所属的渠道标识。其中，物品购买请求是图1所示的游戏实例12生成的请求，获取单元21可以接收游戏实例12发送的物品购买请求。

在一些实施例中，图1中请求端11基于游戏服务组件(Game Service，GS)操控游戏实例12，操控可以包括物品选择操作，这样，游戏实例12可以基于物品选择操作而确定物品清单。其中，物品清单可以包括但不限于：一个或多个物品标识(例如物品ID)、每个物品标识对应的物品数量和物品单价。其中，物品单价与物品ID的对应关系可以预设于游戏后端服务器13中。

在一些实施例中，图1中请求端11基于GS操控游戏实例12，操控还可以包括购买操作，这样，游戏实例12可以响应购买操作而生成物品购买请求，且生成的物品购买请求可以包括但不限于：物品清单和请求端11所属的渠道标识。需要说明的是，图1中游戏实例12可由中心服务端14通过现有调度方法进行调度，相应地，中心服务端14通过现有调度方法调度游戏实例12时，可以将请求端11所属的渠道标识传递给游戏实例12，以便游戏实例12生成物品购买请求时将请求端11所属的渠道标识包括在物品购买请求中。

在一些实施例中，物品购买请求还可以包括游戏实例标识，例如图1中游戏实例12本身的ID。图1中游戏实例12可由中心服务端14通过现有调度方法进行调度，相应地，中心服务端14通过现有调度方法调度游戏实例12时对应生成游戏实例12本身的ID，以便游戏实例12生成物品购买请求时将游戏实例12本身的ID包括在物品购买请求中。

在一些实施例中，物品购买请求还可以包括游戏实例所属的游戏标识，例如图1中游戏实例12所属游戏的游戏ID。图1中游戏实例12可由中心服务端14通过现有调度方法进行调度，相应地，中心服务端14通过现有调度方法调度游戏实例12时，可以将游戏ID传递给游戏实例12，以便游戏实例12生成物品购买请求时将游戏ID包括在物品购买请求中。

需要说明的是，游戏实例是某一个游戏的运行实例，所以每个游戏实例只对应一个游戏ID，每个游戏ID可以同时有多个游戏实例与之对应。

确定单元、发送单元和接收单元

确定单元22，用于确定与物品购买请求中的渠道标识对应的中心服务端(Business Service，BS)。其中，中心服务端维护的信息至少包括一个或多个渠道标识，这样，确定单元22可以基于物品购买请求包括的请求端11所属的渠道标识，确定与请求端11所属的渠道标识对应的中心服务端。其中，渠道标识是能够唯一表征一个渠道的信息，渠道是用以区分用户获取和使用云游戏的不同途径，例如请求端所属出厂商(如不同手机品牌商等)就可以是或属于某一渠道。在一些实施例中，确定单元22若确定不存在与物品购买请求中的渠道标识对应的中心服务端，则将购买失败消息作为物品购买请求的响应反馈至游戏实例。

发送单元23，用于向中心服务端发送订单号获取请求。发送单元23在确定单元22确定中心服务端后，可以生成订单号获取请求。在一些实施例中，发送单元23基于物品购买请求包括的游戏实例所属的游戏标识，生成包括该游戏标识的订单号获取请求。在一些实施例中，发送单元23生成的订单号获取请求还可以包括游戏后端服务器的信息，例如游戏后端服务器的ID。在一些实施例中，游戏后端服务器的信息也可以通过中心服务端的现有方法接口，预设在中心服务端的与游戏ID对应的游戏信息表中，其中，游戏后端服务器的信息与游戏ID均对应于同款游戏。

接收单元24，用于接收中心服务端发送的订单号获取响应，其中，订单号获取响应可以包括但不限于订单号。在一些实施例中，订单号为中心服务端基于订单号获取请求生成的订单号。中心服务端在接收到订单号获取请求后，可以基于订单号获取请求的请求标识(例如请求ID)生成请求标识对应的订单号。在一些实施例中，中心服务端在生成订单号后，可以将订单号保存至订单号获取请求包括的游戏标识所对应的游戏信息表中。在一些实施例中，若订单号获取请求还包括游戏后端服务器的信息，则中心服务端在生成订单号后，可以将订单号和游戏后端服务器的信息保存至订单号获取请求包括的游戏标识所对应的游戏信息表中。在一些实施例中，中心服务端在将订单号(和游戏后端服务器的信息)保存至游戏信息表后，将包括订单号的订单号获取响应发送给接收单元24。

生成单元

生成单元25，用于基于订单号和物品清单，生成订单信息。

订单号为接收单元24接收到的订单号获取响应包括的订单号。订单信息可以包括但不限于：订单号、物品清单中每个物品标识(即物品ID)对应的物品信息和物品清单中所有物品的总价。其中，物品信息可以包括但不限于：物品ID、物品数量、物品单价、物品描述、物品各属性及其描述等。总价等于各物品的单价与其数量相乘结果的总和。

物品清单为获取单元21获取的物品购买请求包括的物品清单。其中，物品购买请求是图1所示的游戏实例12生成的请求。在一些实施例中，生成单元25生成订单信息后，可以响应物品购买请求而反馈物品购买响应给游戏实例，物品购买响应可以包括但不限于订单信息。

在一些实施例中，生成单元25生成订单信息后，将生成的订单信息、物品购买请求包括的游戏实例标识以及该游戏实例标识已登录的游戏账号标识(未登录则此项可以为空)进行关联并保存。在一些实施例中，生成单元25在完成上述关联并保存后，可以响应物品购买请求而反馈物品购买响应给游戏实例，物品购买响应可以包括但不限于订单信息。

基于以上各实施例的描述，生成单元25生成订单信息后，可以将订单信息发送给游戏实例。这样，在图1中，游戏实例12可基于游戏服务组件(Game Service，GS)向请求端11发送包括订单信息的游戏订单支付请求，以使请求端11响应游戏订单支付请求而调用本地的支付应用，以获得用户的支付确认，进而由支付应用对应的支付服务端完成订单支付。既解决了游戏实例12不能调用运行于本地的支付应用的问题，又避免了将支付应用移到云游戏服务端上运行而造成的诸多不便、用户使用习惯的改变、以及账号信息因此存在于多个云游戏服务端环境带来的同步难度和安全隐患。

在一些实施例中，游戏订单生成装置20中各单元的划分仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如游戏订单生成装置20中的至少两个单元可以实现为一个单元；游戏订单生成装置20中的各单元也可以划分为多个子单元。可以理解的是，各单元或子单元能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能。

图3为本申请实施例提供的一种游戏订单支付装置30的框图。在一些实施例中，游戏订单支付装置30可以实现为图1中的请求端11或者请求端11的一部分。如图3所示，游戏订单支付装置30可包括但不限于以下单元：获取单元31和调用单元32。各单元具体描述如下：

获取单元

获取单元31，用于获取游戏订单支付请求，游戏订单支付请求包括订单信息。订单信息可以包括但不限于：订单号、物品清单中每个物品标识(即物品ID)对应的物品信息和物品清单中所有物品的总价。其中，物品信息可以包括但不限于：物品ID、物品数量、物品单价、物品描述、物品各属性及其描述等。总价等于各物品的单价与其数量相乘结果的总和。

订单信息为游戏后端服务器生成的订单信息，具体的生成过程参考图2所示的游戏订单生成装置20相关各实施例的描述，不再赘述。

游戏订单支付请求为游戏实例基于订单信息而生成，其中，订单信息由游戏后端服务器生成并发送给游戏实例。游戏实例在生成游戏订单支付请求后，基于对应的游戏服务组件(Game Service，GS)向获取单元31发送游戏订单支付请求。

调用单元

调用单元32，用于响应游戏订单支付请求而调用本地的支付应用，由支付应用对应的支付服务端完成订单支付。其中，本地的支付应用可以是网银、支付宝、微信支付等各类支付应用。

在一些实施例中，调用单元32调用本地的支付应用时，基于支付应用提供的现有接口向支付应用传入如下参数：AppID(应用程序标识)、App对应的Token(令牌)、订单信息中的订单号、请求端对应的中心服务端的回调URL(Uniform Resource Locator，统一资源定位)地址等。其中，App为可以直接调用支付应用的应用程序，App可以为请求端，也可以为本地的游戏客户端。App在调用支付应用之前，在支付应用提供的开发者平台注册和登录开发者账号，利用开发者账号申请获得AppID和App对应的Token，AppID和App对应的Token都是由支付应用后台生成。

在一些实施例中，调用单元32调用本地的支付应用后，支付应用可以显示订单待支付的界面，界面包括订单号、订单信息、确认支付的按钮等，支付应用可以基于订单号和上述的回调URL地址向请求端对应的中心服务端获取该订单信息，以便用户确认物品信息和总价后确认支付。

在一些实施例中，调用单元32调用本地的支付应用后，用户可以通过支付应用确认支付，支付服务端接收到支付应用发送的确认支付的消息后，完成订单支付，订单支付的过程可沿用现有技术，不再赘述。

在一些实施例中，在支付服务端完成订单支付后，支付服务端可以向中心服务端发送支付结果，支付结果包括订单号。例如，支付服务端可以基于上述回调URL地址向请求端对应的中心服务端发送支付结果。

在一些实施例中，中心服务端接收到支付结果后，由于中心服务端在订单号生成过程中，将订单号和游戏后端服务器的信息保存至游戏标识所对应的游戏信息表中，因此中心服务端可以基于支付结果中的订单号确定该订单号对应的游戏标识及该游戏标识对应的游戏后端服务器，从而将支付结果发送至支付结果中的订单号所对应的游戏后端服务器。

图1中的游戏后端服务器13可以接收中心服务端14发送的支付结果。这样，由于游戏后端服务器13在生成订单信息后，可以将生成的订单信息、游戏实例标识以及该游戏实例标识已登录的游戏账号标识进行关联并保存，因此游戏后端服务器13可以基于支付结果中的订单号确定订单信息、游戏实例标识和游戏账号标识。另外，由于游戏实例登录游戏账号时，已将游戏账号标识和游戏账号信息进行关联和记录，因此游戏后端服务器13可以将订单信息中购买的各物品信息更新至游戏账号标识对应的游戏账号信息中。从而，游戏后端服务器13可以向游戏实例标识对应的游戏实例发送发货通知，发货通知包括订单信息中购买的各物品信息。

在一些实施例中，游戏后端服务器13还可以向中心服务端14发送发货通知，发货通知包括订单号。中心服务端14收到发货通知后，可以向支付服务端发送“支付结果已被确认”的消息，以便支付服务端可以完成后续支付扣款等操作。

在一些实施例中，游戏实例12收到游戏后端服务器13发送的发货通知(包括订单信息中购买的各物品信息)后，显示购买的各物品信息，以便用户可以随时通过请求端11了解游戏实例12中显示的购买结果(GS主动捕获游戏实例12的运行结果并以视音频流的方式实时地传输至请求端11，在请求端11上呈现出游戏实例12中的画面和声音)。

基于以上各实施例的描述，在图1中，游戏实例12可基于游戏服务组件(GameService，GS)向请求端11发送包括订单信息的游戏订单支付请求，以使请求端11响应游戏订单支付请求而调用本地的支付应用，以获得用户的支付确认，进而由支付应用对应的支付服务端完成订单支付。既解决了游戏实例12不能调用运行于本地的支付应用的问题，又避免了将支付应用移到云游戏服务端上运行而造成的诸多不便、用户使用习惯的改变、以及账号信息因此存在于多个云游戏服务端环境带来的同步难度和安全隐患。

在一些实施例中，游戏订单支付装置30中各单元的划分仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如游戏订单支付装置30中的至少两个单元可以实现为一个单元；游戏订单支付装置30中的各单元也可以划分为多个子单元。可以理解的是，各单元或子单元能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能。

图4为本申请实施例提供的一种游戏订单生成及支付过程中的多端交互图，如图4所示，游戏订单生成及支付的流程包括如下步骤401至420：

在步骤401中，请求端基于游戏服务组件(Game Service，GS)操控GS对应的游戏实例，操控包括但不限于：物品选择操作和购买操作。

在步骤402中，游戏实例可以基于物品选择操作而确定物品清单。其中，物品清单可以包括但不限于：一个或多个物品标识、每个物品标识对应的物品数量和物品单价。

在步骤403中，游戏实例确定物品清单后，可以响应购买操作而生成物品购买请求，且生成的物品购买请求可以包括但不限于：物品清单、游戏实例ID、游戏ID和请求端的渠道ID。进而，游戏实例可以将物品购买请求发送给游戏ID对应的游戏后端服务器。

在步骤404中，游戏后端服务器在接收到物品购买请求后，可基于请求端的渠道ID确定中心服务端。其中，中心服务端维护的信息至少包括一个或多个渠道ID，这样，游戏后端服务器可以基于物品购买请求包括的请求端的渠道ID，确定与请求端的渠道ID对应的中心服务端。

在步骤405中，游戏后端服务器在确定中心服务端后，可以生成订单号获取请求，订单号获取请求包括物品购买请求中的游戏ID。进而，游戏后端服务器可以将订单号获取请求发送给中心服务端。

在步骤406中，中心服务端接收到订单号获取请求后，基于订单号获取请求的请求标识(例如请求ID)生成请求标识对应的订单号。

在步骤407中，中心服务端在生成订单号后，可以将生成的订单号保存至订单号获取请求包括的游戏ID所对应的游戏信息表中。在一些实施例中，若订单号获取请求还包括游戏后端服务器的信息，则中心服务端在生成订单号后，可以将订单号和游戏后端服务器的信息保存至订单号获取请求包括的游戏ID所对应的游戏信息表中。

在步骤408中，中心服务端在步骤406生成订单号后或步骤407保存订单号后，向游戏后端服务器发送订单号获取响应，订单号获取响应包括订单号。

在步骤409中，游戏后端服务器在收到订单号获取响应后，基于订单号获取响应中的订单号和物品购买请求中的物品清单，生成订单信息。订单信息可以包括但不限于：订单号、物品清单中每个物品标识对应的物品信息和物品清单中所有物品的总价。

在步骤410中，游戏后端服务器可以将生成的订单信息、物品购买请求包括的游戏实例ID以及该游戏实例ID已登录的游戏账号ID(未登录则此项可以为空)进行关联并保存。

在步骤411中，游戏后端服务器在完成上述关联并保存后，生成物品购买响应，物品购买响应可以包括但不限于订单信息。进而，游戏后端服务器向游戏实例发送物品购买响应。

在步骤412中，游戏实例收到物品购买响应后，可以基于物品购买响应中的订单信息生产订单支付请求，订单支付请求包括订单信息。进而，游戏实例可以基于GS向请求端发送订单支付请求。

在步骤413中，请求端收到订单支付请求后，响应游戏订单支付请求而调用本地支付应用，支付应用可以显示订单待支付的界面，界面包括订单号、订单信息、确认支付的按钮等，支付应用可以基于订单号和上述的回调URL地址向请求端对应的中心服务端获取该订单信息，以便用户确认物品信息和总价后确认支付。

在步骤414中，支付服务端收到用户通过本地支付应用确定支付的消息后，完成订单支付。

在步骤415中，支付服务端完成订单支付后，可以将支付结果发送给中心服务端。其中，支付结果包括订单号。

在步骤416中，中心服务端收到支付结果后，由于中心服务端在步骤407中将生成的订单号保存至游戏ID所对应的游戏信息表中，因此中心服务端可以基于支付结果中的订单号确定订单号对应的游戏ID和游戏ID对应的游戏后端服务器。

在步骤417中，中心服务端在确定游戏后端服务器后，将支付结果发送给游戏后端服务器。其中，支付结果包括订单号。

在步骤418中，游戏后端服务器收到支付结果后，由于游戏后端服务器在步骤410中将生成的订单信息、游戏实例ID以及该游戏实例ID已登录的游戏账号ID进行关联并保存，因此游戏后端服务器可以基于支付结果中的订单号确定订单信息、游戏实例ID和游戏账号ID。

在步骤419中，由于游戏实例登录游戏账号时，已将游戏账号ID和游戏账号信息进行关联和记录，因此游戏后端服务器可以将订单信息中购买的各物品信息更新至游戏账号ID对应的游戏账号信息中。

在步骤420中，游戏后端服务器可以向游戏实例发送发货通知，发货通知包括订单信息中购买的各物品信息。

这样，游戏实例收到游戏后端服务器发送的发货通知(包括订单信息中购买的各物品信息)后，显示购买的各物品信息，以便用户可以随时通过请求端了解游戏实例中显示的购买结果(GS主动捕获游戏实例的运行结果并以视音频流的方式实时地传输至请求端，在请求端上呈现出游戏实例中的画面和声音)。

基于以上各步骤的描述可见，游戏后端服务器通过获取物品购买请求，得到物品购买请求包括的物品清单和请求端所属的渠道ID，进而可确定与渠道ID对应的中心服务端，从而可向中心服务端发送订单号获取请求，在接收到中心服务端发送的订单号获取响应后，可得到订单号获取响应包括的订单号，从而基于订单号和物品清单，生成订单信息，这样，游戏实例可基于GS向请求端发送包括订单信息的游戏订单支付请求，以使请求端响应游戏订单支付请求而调用本地的支付应用，以获得用户的支付确认，进而由支付服务端完成订单支付。既解决了游戏实例不能调用运行于本地的支付应用的问题，又避免了将支付应用移到云游戏服务端上运行而造成的诸多不便、用户使用习惯的改变、以及账号信息因此存在于多个云游戏服务端环境带来的同步难度和安全隐患。

本申请实施例还提供了一种电子设备。如图5所示，电子设备50包括：处理器51和存储器53。其中，处理器51和存储器53相连，如通过总线52相连。进一步地，电子设备5还可以包括收发器54。需要说明的是，实际应用中收发器54不限于一个，该电子设备5的结构并不构成对本申请实施例的限定。

其中，处理器51应用于本申请实施例中，用于实现图2所示的游戏订单生成装置20或游戏订单支付装置30的功能。

处理器51可以是CPU，通用处理器，DSP，ASIC，FPGA或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器51也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线52可包括一通路，在上述组件之间传送信息。总线52可以是PCI总线或EISA总线等。总线52可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器53可以是ROM或可存储静态信息和指令的其他类型的静态存储设备，RAM或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM、CD-ROM或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

存储器53用于存储执行本申请方案的应用程序代码，并由处理器5来控制执行。处理器51用于执行存储器53中存储的应用程序代码，以实现游戏订单生成装置20或游戏订单支付装置30的功能。

本申请实施例提供的电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时，与现有技术相比，既解决了游戏实例不能调用运行于本地的支付应用的问题，又避免了将支付应用移到云游戏服务端上运行而造成的诸多不便、用户使用习惯的改变、以及账号信息因此存在于多个云游戏服务端环境带来的同步难度和安全隐患。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现游戏订单生成方法或游戏订单支付方法各实施例的步骤，为避免重复，在此不再赘述。

图6为本申请实施例提供的一种游戏订单生成方法的流程图，该方法应用于游戏后端服务器，可包括如下步骤601至605：

在步骤601中，游戏后端服务器获取物品购买请求，物品购买请求包括物品清单、请求端所属的渠道标识。在一些实施例中，物品清单包括：一个或多个物品标识、每个物品标识对应的物品数量和物品单价。

在步骤602中，游戏后端服务器确定与渠道标识对应的中心服务端。

在步骤603中，游戏后端服务器向中心服务端发送订单号获取请求。

在步骤604中，游戏后端服务器接收中心服务端发送的订单号获取响应，订单号获取响应包括订单号。其中，订单号为中心服务端基于订单号获取请求生成的订单号。

在步骤605中，游戏后端服务器基于订单号和物品清单，生成订单信息。其中，订单信息包括订单号、物品清单中每个物品标识对应的物品信息、物品清单中所有物品的总价。

在一些实施例中，请求端基于游戏服务组件操控游戏实例，操控包括物品选择操作及购买操作；物品购买请求为游戏实例响应购买操作而生成的请求；物品清单为游戏实例基于物品选择操作而确定的清单。

在一些实施例中，物品购买请求还包括游戏实例标识。游戏后端服务器在生成订单信息后，还可以将订单信息、游戏实例标识、游戏实例标识已登录的游戏账号标识进行关联并保存。

在一些实施例中，物品购买请求还包括游戏实例所属的游戏标识。订单号获取请求包括游戏标识。中心服务端生成订单号并将订单号保存至游戏标识对应的游戏信息表中。

在一些实施例中，物品购买请求为游戏实例生成的请求。游戏后端服务器还可以响应物品购买请求而反馈物品购买响应给游戏实例，物品购买响应包括订单信息。

以上游戏订单生成方法各实施例的细节可参考图2所示的游戏订单生成装置20各实施例的描述，不再赘述。

图7为本申请实施例提供的一种游戏订单支付方法的流程图，该方法应用于请求端，可包括如下步骤701和702：

在步骤701中，请求端获取游戏订单支付请求，游戏订单支付请求包括订单信息；订单信息为游戏后端服务器基于图6所示的游戏订单生成方法任一实施例生成的订单信息。

在步骤702中，请求端响应游戏订单支付请求而调用本地的支付应用，由支付应用对应的支付服务端完成订单支付。

在一些实施例中，游戏订单支付请求为游戏实例基于订单信息而生成，订单信息由游戏后端服务器发送给游戏实例，且游戏实例基于游戏服务组件向请求端发送游戏订单支付请求。

在一些实施例中，支付服务端完成订单支付后，游戏后端服务器可以接收中心服务端发送的支付结果，支付结果包括订单号；支付结果为支付服务端向中心服务端发送的支付结果。

在一些实施例中，游戏后端服务器可以基于订单号确定订单信息、游戏实例标识和游戏账号标识；进而，游戏后端服务器将订单信息中购买的各物品信息更新至游戏账号标识对应的游戏账号信息中；从而，游戏后端服务器向游戏实例标识对应的游戏实例发送发货通知，发货通知包括订单信息中购买的各物品信息。

以上游戏订单支付方法各实施例的细节可参考图3所示的游戏订单支付装置30各实施例的描述，不再赘述。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上所述仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。