CN111222944B - 一种订单处理方法、系统及装置 - Google Patents

Abstract

本申请实施例公开了一种订单处理方法、系统及装置。该方法应用于移动终端，该移动终端安装有第一应用和第二应用。该方法包括：移动终端通过第一应用请求第二应用对第一订单进行支付，并通过第一应用获得第一订单的第一支付结果；当第一支付结果指示支付未成功时，移动终端通过第一应用向软件开发工具包SDK服务器查询第一订单的第二支付结果；第二支付结果由SDK服务器从第二应用获取；当第二支付结果指示支付成功时，移动终端通过第一应用根据第二支付结果对第一订单进行处理。实施本申请实施例，可以减少用户通过支付应用付款成功但游戏客户端未下发游戏道具的情况，提高用户的游戏体验感。

Description

一种订单处理方法、系统及装置

技术领域

本申请涉及移动终端应用技术领域，尤其涉及一种订单处理方法、系统及装置。

背景技术

软件开发工具包(software development kit，SDK)可以用于实现软件产品某项功能的工具包。例如，移动终端中的游戏应用可以通过SDK客户端实现登录和购买游戏道具等功能。其中，游戏应用可包含游戏客户端和SDK客户端。游戏客户端可以通过SDK客户端与支付应用，例如，微信和支付宝等进行通信，以确认用户购买游戏道具的订单的支付结果是否支付成功。若接收到来自SDK客户端的支付成功消息，游戏客户端可以下发游戏道具。

但是，SDK客户端与支付应用通信并确认订单的支付结果的过程可能占用时间较长。SDK客户端在限定时间内未接收到支付结果，就默认订单的支付结果为支付未成功，并将支付未成功的支付结果发送给游戏客户端。这就导致用户通过支付应用付款成功但游戏客户端未下发游戏道具，降低了用户的游戏体验感。

发明内容

本申请实施例提供了一种订单处理方法、系统及装置，可用于减少用户通过支付应用付款成功但游戏客户端未下发游戏道具的情况，提高用户的游戏体验感。

第一方面，本申请实施例提供了一种订单处理方法，所述方法应用于移动终端，所述移动终端安装有第一应用和第二应用；其中：

所述移动终端通过所述第一应用请求所述第二应用对第一订单进行支付，并通过所述第一应用获得所述第一订单的第一支付结果；

当所述第一支付结果指示支付未成功时，所述移动终端通过所述第一应用向软件开发工具包SDK服务器查询所述第一订单的第二支付结果；所述第二支付结果由所述SDK服务器从所述第二应用获取；

当所述第二支付结果指示支付成功时，所述移动终端通过所述第一应用根据所述第二支付结果对所述第一订单进行处理。

在一种可能的实现方式中，当所述移动终端通过所述第一应用在预设的限定时间T内未接收到所述第二应用发送的支付结果时，所述移动终端通过所述第一应用确定所述第一支付结果指示支付未成功；所述预设的限定时间T为正数。

或者，

所述移动终端通过所述第一应用在所述预设的限定时间T内接收所述第二应用发送第一支付结果。

在一种可能的实现方式中，所述移动终端通过所述第一应用请求所述第二应用对第一订单进行支付，并通过所述第一应用获得所述第一订单的第一支付结果之后，当所述第一支付结果指示支付成功时，所述移动终端通过所述第一应用根据所述第一支付结果对所述第一订单进行处理；

所述移动终端通过所述第一应用通知所述SDK服务器对所述第一订单进行标记；被标记的所述第一订单指示所述第一订单已经完成处理。

在另一种可能的实现方式中，当重新启动所述第一应用时，所述移动终端通过所述第一应用向所述SDK服务器获取预设时间内未被标记的第二订单的支付结果；

当所述第二订单的支付结果指示支付成功时，所述移动终端通过所述第一应用根据所述第二订单的支付结果对所述第二订单进行处理。

若所述第一应用是游戏应用，当所述第二支付结果指示支付成功时，所述第一应用根据所述第二支付结果下发游戏道具。

所述移动终端通过所述第一应用向所述SDK服务器查询所述第一订单的次数小于或等于预设次数M。当所述第二支付结果指示支付未成功，其所述移动终端通过所述第一应用向所述SDK服务器查询所述第一订单的次数等于预设次数M时，所述移动终端通过所述第一应用根据所述第二支付结果对所述第一订单进行处理；所述预设次数M为正整数。

第二方面，本申请实施例提供了一种订单处理装置，所述订单处理装置安装有第一应用和第二应用，所述装置包括获取单元、确认单元和处理单元。

所述获取单元，用于通过所述第一应用请求所述第二应用对第一订单进行支付，并通过所述第一应用获得所述第一订单的第一支付结果；

所述确认单元，用于当所述第一支付结果指示支付未成功时，通过所述第一应用向软件开发工具包SDK服务器查询所述第一订单的第二支付结果；所述第二支付结果由所述SDK服务器从所述第二应用获取；

所述处理单元，用于当所述第二支付结果指示支付成功时，通过所述第一应用根据所述第二支付结果对所述第一订单进行处理。

第三方面，本申请实施例还提供了一种订单处理装置，包括：

处理器、通信接口和存储器，所述存储器用于存储计算机程序，所述通信接口、所述存储器分别通过总线与所述处理器耦合；

其中，所述处理器用于调用所述计算机程序，使得所述装置执行上述第一方面的订单处理方法。

由于SDK客户端与支付应用通信并确认支付结果的过程可能占用时间较长，SDK客户端发送给游戏客户端的支付结果可能不准确。在本申请实施例中，在接收到SDK客户端发送的支付未成功的支付结果时，游戏客户端可向可信度更高的SDK服务器发送支付结果查询请求，来对支付结果进行确认。并且，游戏客户端向SDK服务器查询支付结果的次数可以为多次。上述游戏客户端向SDK服务器查询支付结果的操作，可以减少已付款成功但游戏客户端未下发游戏道具的情况，提高订单处理的准确性，从而提高用户的游戏体验感。

由于可能出现支付应用向SDK服务器发送支付结果的过程占用时间特别长的情况，游戏客户端在启动游戏时，向SDK服务器获取最近N天内未下发游戏道具的订单号，可以再次向SDK服务器确认这些订单号的支付情况。从而进一步减少已付款成功但游戏客户端未下发游戏道具的情况，以进一步提高订单处理的准确性。

附图说明

下面对本申请实施例用到的附图进行介绍。

图1是本申请实施例提供的一种订单处理系统的结构示意图；

图2是本申请实施例提供的一种订单处理方法的流程图；

图3是本申请实施例提供的一种游戏的游戏界面示意图；

图4是本申请实施例提供的一种游戏的支付界面示意图；

图5是本申请实施例提供的另一种游戏的支付界面示意图；

图6是本申请实施例提供的另一种游戏的游戏界面示意图；

图7是本申请实施例提供的另一种订单处理方法的流程图；

图8是本申请实施例提供的一种订单处理装置的结构示意图；

图9是本申请实施例提供的另一种订单处理装置的结构示意图。

具体实施方式

下面结合本申请实施例中的附图对本申请实施例进行描述。本申请实施例的实施方式部分使用的术语仅用于对本申请的具体实施例进行解释，而非旨在限定本申请。

请参阅图1，图1是本申请实施例提供的一种订单处理系统的结构示意图。如图1所示，订单处理系统包括移动终端100、SDK服务器200和支付服务器300。其中：

移动终端100可以为手机、平板电脑等设备。移动终端100可安装游戏应用110和支付应用120。本申请实施例中，游戏应用110和支付应用120执行的各个步骤，即是指移动终端100在运行各应用时所执行的步骤。游戏应用110可以包含游戏客户端111和SDK客户端112。

其中，游戏客户端111可用于为用户提供游戏服务，例如，在移动终端100上显示游戏界面和下发游戏道具等。游戏客户端111可以向SDK客户端112发送支付请求，通过SDK客户端112获得订单号和支付结果，并根据支付结果来确定是否下发游戏道具。游戏客户端111可以保存上述订单号，并在支付未成功的情况下利用该订单号向SDK服务器200查询与该订单号对应的支付结果。

上述支付请求中可以包含订单中的游戏道具种类、数量以及订单的金额等数据，本申请实施例对此不进行限定。

上述支付未成功的情况可包括用户付款成功但游戏客户端111未下发游戏道具和用户取消支付游戏客户端111未下发游戏道具等情况。本申请实施例对此不进行限定，由于其他原因导致游戏客户端111未下发游戏道具的情况，均可以被认为是支付未成功的情况。

SDK客户端112可用于将游戏客户端112的支付请求转发给SDK服务器200，并将由SDK服务器200生成的订单号返回给游戏客户端111。SDK客户端112中可包含调用支付应用的接口。通过上述调用支付应用的接口，SDK客户端112可调用支付应用120，并将来自支付应用120的支付结果返回给游戏客户端100。

支付应用120可以为支付宝和微信支付等应用，本申请实施例对此不进行限定。

在一种可能的实现方式中，当接收到SDK客户端112的调用请求，支付应用120可以在移动终端100上显示支付界面，接收用户的支付密码。支付应用120可以根据待支付金额和用户的支付密码向支付服务器300确认支付结果。当接收到来自支付服务器300的支付结果，支付应用120可以将支付结果发送给SDK客户端112和SDK服务器200。

SDK服务器200可用于接收SDK客户端112的支付请求，创建订单号，并将上述订单号经过SDK客户端112返回给游戏客户端111。SDK服务器200还可以用于接收支付应用120发送的支付结果，并将上述支付结果与对应的订单号进行对应保存。另外，SDK服务器200还可用于接收游戏客户端111的支付结果查询请求，并将对应订单号的支付结果发送给游戏客户端111。上述订单号可以为唯一标识上述支付请求的编号，即SDK服务器200可以创建不同的编号以标识不同的支付请求。

支付服务器300可用于对用户在支付应用中的账号进行扣款操作。当接收到支付应用120发送的待支付金额和用户的支付密码，支付服务器300可以校验上述用户的支付密码的准确性，并对用户在支付应用中的账号进行扣款操作，得到支付结果。支付服务器300可以将上述支付结果发送给支付应用120。

这里对本申请实施例中的游戏道具进行具体说明。

游戏道具：游戏道具可以是游戏应用的应用界面中具有特定功能的虚拟物品。例如，在游戏应用“梦幻家园”中，游戏道具可以包含游戏应用中的炸弹、火箭、彩虹球和纸飞机等虚拟道具。上述游戏道具有利于用户在游戏应用中成功通过关卡。另外，游戏道具还可以包含游戏应用中的虚拟金币等其他物品。上述虚拟金币可通过闯关或者充值等方式获取。虚拟金币可以用于置换上述炸弹、火箭、彩虹球和纸飞机等道具。

在单机游戏中，当接收到支付结果，游戏客户端111可以根据与支付结果对应的订单号下发游戏道具，而无需由游戏服务器通知游戏客户端111来下发游戏道具。例如，游戏客户端111发送的支付请求中包含的游戏道具种类和数量可以为两个炸弹和两个彩虹球，游戏客户端111中保存有唯一标识该支付请求的订单号。当接收到该订单号的支付结果为支付成功，游戏客户端111可以下发游戏道具，即为当前账号增加游戏道具两个炸弹和两个彩虹球。

SDK客户端112在限定时间内接收到支付结果，可将支付结果发送给游戏客户端111。超过该限定时间，SDK客户端112可以默认支付结果为支付未成功，并将支付未成功的支付结果发送给游戏客户端111。若在将默认支付未成功的支付结果发送给游戏客户端111之后，SDK客户端112接收到支付应用120发送的支付结果，SDK客户端112不再向游戏客户端111发送接收到的支付结果。或者，SDK客户端112将接收到的支付结果发送给游戏客户端111，但游戏客户端111不再接收该支付结果。

SDK客户端112接收到来自支付应用120的支付结果的过程可能占用时间较长，例如，由于网络延时、支付应用繁忙或者支付应用与支付服务器确认支付结果出现延时等原因，支付应用120经过较长时间才将支付结果发送给SDK客户端112。若在限定时间内未接收到支付结果，SDK客户端112可以默认支付结果为支付未成功，并将支付未成功的支付结果发送给游戏客户端111。

其中，在上述限定时间之后，若SDK客户端112接收到来自支付应用120的支付结果为支付成功，即支付服务器扣款成功，SDK客户端112可不再将接收到的支付成功的支付结果发送给游戏客户端111。或者，SDK客户端112可将支付结果发送给游戏客户端111，但游戏客户端已经接收过支付未成功的支付结果，可以认为SDK客户端112再次发送的支付结果可信度较低，而不接收该支付成功的支付结果。这就导致已付款成功，而游戏客户端未下发道具，降低了用户的游戏体验感。

其中，SDK客户端112包含于移动终端100，SDK客户端112向游戏客户端111发送的支付结果可能被篡改。因此出于安全考虑，游戏客户端111可以不对SDK客户端112再次发送的支付结果进行响应，即不再接收该支付结果。

例如，由于SDK客户端112不能无期限地一直等待支付应用120发送的支付结果，SDK客户端112可以将限定时间预设为5秒。即SDK客户端112在5秒内未接收到支付应用120发送的支付结果，则默认支付结果为支付未成功。SDK客户端112可以与支付应用120进行通信，支付应用120与支付服务器300在确认扣款成功后，可以将支付成功的支付结果发送给SDK客户端112。由于从支付应用120与支付服务器300确认扣款成功到向SDK客户端112发送支付结果的过程占用的时间较长，例如，可能占用了10秒的时间。则SDK客户端112在等待5秒后，向游戏客户端111发送支付未成功的支付结果，游戏客户端111不下发游戏道具，且可以不再接收SDK客户端在此之后发送的与该订单号对应的支付结果。这样，就出现了已付款成功但游戏客户端未下发游戏道具的情况。

为了减少已付款成功但游戏客户端111未下发游戏道具的情况，游戏客户端111可以在接收到支付未成功的支付结果时，根据订单号向SDK服务器200查询支付结果，以提高接收到的支付结果的准确性，从而减少已付款成功但是游戏客户端111未下发游戏道具的情况。SDK服务器200可以接收支付应用120发送的支付结果。当接收到支付结果，SDK服务器200可以将支付结果以及与该支付结果对应的订单号进行对应保存。相比于SDK客户端112，SDK服务器200中保存的支付结果出现被篡改的可能性较低，因而其保存的支付结果可信度更高。

请参阅图2，图2为本申请实施例提供的一种订单处理方法的流程图。该方法可基于图1所示的订单处理系统。如图2所示，该订单处理方法包括步骤S101-S113。

S101、游戏客户端经由SDK客户端向SDK服务器发起支付请求。

游戏客户端可响应于用户购买游戏道具的操作，经由SDK客户端向SDK服务器发起支付请求。上述支付请求中可以包含游戏道具种类、数量以及价格等数据，本申请实施例对此不进行限定。

例如，游戏客户端可在移动终端上显示如图3所示的游戏界面。该游戏界面可包含不同类型的商品，例如，特惠礼包431、入门套装、学徒套装和高手套装等。上述不同类型的商品可以包含不同种类和数量的游戏道具。例如，特惠礼包431中包含500个金币、1个彩虹球、1个纸飞机和1个炸弹。该游戏界面还可包含用于用户购买不同类型的商品的下单控件。例如，用于购买特惠礼包431的下单控件432。下单控件432上可以包含特惠礼包431的价格。游戏客户端可响应于作用在下单控件432上的用户操作，经由SDK客户端向SDK服务器发起支付请求。上述支付请求中可包含特惠礼包431中的游戏道具种类、数量以及价格等数据。

S102、SDK服务器创建订单号。

当接收到上述支付请求，SDK服务器可以为上述支付请求创建订单号。

S103、SDK服务器经由SDK客户端向游戏客户端发送订单号。

创建订单号之后，SDK服务器可以将上述订单号经由SDK客户端发送给游戏客户端。

S104、游戏客户端保存订单号。

接收到上述订单号之后，游戏客户端可以将上述订单号进行保存。

S105、SDK客户端调用支付应用。

SDK客户端中可包含调用支付应用的接口。通过上述调用支付应用的接口，SDK客户端可调用支付应用，例如，支付宝和微信支付等。

在一种可能的实现方式中，SDK客户端可在移动终端上显示如图4所示的支付界面。该支付界面可包含不同支付应用的选项，例如，支付宝选项和微信选项等。当检测到用户选择微信支付选项并确认进行支付，SDK客户端可调用微信支付，并将订单号和待支付金额发送给微信支付。

S106、支付应用显示支付界面，接收支付密码。

当接收到SDK客户端的调用请求，支付应用可以显示支付界面，接收用户输入的支付密码。上述支付界面可包含待支付金额和支付密码输入框等内容，本申请实施例对此不进行限定。

S107、支付应用与支付服务器进行支付结果确认。

当接收到用户输入的支付密码，支付应用可以根据上述待支付金额和上述支付密码，与支付服务器进行支付结果确认

在一种可能的实现方式中，支付应用可以将上述待支付金额和上述支付密码发送给支付服务器。支付服务器可以校验上述支付密码的准确性，并根据上述待支付金额对用户在该支付应用的账号进行扣款操作，得到支付结果。若支付服务器对用户在该支付应用的账号扣款成功，则支付结果为支付成功。若支付服务器对用户在该支付应用的账号扣款失败，则支付结果为支付未成功。

S108、支付应用向游戏客户端发送支付结果。

当支付应用与支付服务器完成支付结果确认，支付应用可以在移动终端上显示如图5所示的支付界面，并将上述支付结果经SDK客户端发送给游戏客户端。如图5所示的支付界面可以包含支付结果提示。上述支付结果提示可用于支付应用提示用户支付结果是否成功。

例如，若支付结果为支付成功，上述支付结果提示可以为“支付成功”以及支付的金额。

S109、支付应用向SDK服务器发送支付结果。

在一种可能的实现方式中，当接收到支付结果，支付应用还可将上述支付结果发送给SDK服务器。由SDK服务器将订单号及其对应的支付结果进行对应保存。SDK服务器接收到的支付结果还可以由支付服务器发送，本申请实施例对此不进行限定。

SDK服务器保存支付结果和对应的订单号，即是对上述支付结果及其对应的订单号进行数据备份。当订单出现问题时，游戏客户端可以根据SDK服务器中保存的支付结果和对应的订单号核对该订单的支付结果。

S110、若支付结果为支付成功，游戏客户端下发游戏道具。

若接收到SDK客户端发送的支付结果为支付成功，游戏客户端可以根据订单号下发游戏道具。

其中，当SDK客户端调用支付应用显示支付界面时，游戏客户端暂时停止运行游戏。而当接收到用户返回游戏的操作时，游戏客户端显示游戏界面，继续运行游戏。当游戏客户端接收到支付成功的支付结果，响应于用户作用在如图5所述的返回游戏控件570的操作，游戏客户端可以根据订单号下发游戏道具，并将游戏道具的种类和数量显示在游戏界面上，以提醒用户游戏道具已成功下发。

在一种可能的实现方式中，游戏客户端在根据订单号下发游戏道具之后，可以通知SDK服务器上述订单号已经下发游戏道具。响应于游戏客户端的通知，SDK服务器可以将上述订单号进行标记。例如，SDK服务器可以给上述订单号增加标签，标签值可以为1。上述标签值为1的订单号可以表示已经下发游戏道具的订单号。本申请实施例对SDK服务器标记订单号的方式不进行限定。被标记过的订单号可以表示已经下发游戏道具的订单号。SDK客户端可以将已经下发游戏道具的订单号和还为下发游戏道具的订单号进行区分。

S111、若支付结果为支付未成功，游戏客户端根据保存的订单号，向SDK服务器发送支付结果查询请求。

若支付结果为支付未成功，游戏客户端可以根据步骤S104保存的订单号向SDK服务器查询支付结果。

响应于用户作用在如图5所述的返回游戏控件570的操作，游戏客户端可以在显示游戏界面，并向SDK服务器发送支付结果查询请求。

在一种可能的实现方式中，当接收到SDK客户端发送支付结果为支付未成功，游戏客户端可以在显示游戏界面时提示用户“支付结果确认中，请等待！”等提示语。本申请实施例对游戏客户端收到支付未成功的支付结果时在游戏界面上是否显示提示语以及提示语的内容均不进行限定。

上述支付未成功的情况可包括已付款成功但游戏客户端并未下发游戏道具和支付被取消游戏客户端未下发游戏道具等情况，即无论是用户付款成功但游戏客户端未下发游戏道具，还是支付被取消游戏客户端未下发游戏道具，游戏客户端均可以向SDK服务器发送支付结果查询请求。

S112、SDK服务器向游戏客户端发送支付结果。

在一种可能的实现方式中，在接收到游戏客户端发送的支付结果查询请求时，SDK服务器已经接收并保存了游戏客户端要查询的订单号的支付结果。SDK服务器可以将游戏客户端要查询的订单号的支付结果发送给游戏客户端。

在另一种可能的实现方式中，在接收到游戏客户端发送的支付结果查询请求时，SDK服务器还未接收到游戏客户端要查询的订单号的支付结果。则SDK服务器可以认为支付结果为支付未成功，并将支付未成功的支付结果发送给游戏客户端。

S113、游戏客户端重复上述步骤S110-S112，当游戏客户端向SDK服务器查询支付结果的次数超过预设查询次数，则停止向SDK服务器查询。

游戏客户端根据步骤S112中SDK服务器发送的支付结果，重复上述步骤S110-S112。

其中，当支付结果为支付成功，游戏客户端进行的操作可以参考步骤S110，这里不再进行赘述。

需要进行说明的是，游戏客户端可以预设间隔时间，例如，3秒或4秒等等。上述预设间隔时间为从游戏客户端接收到SDK服务器发送支付未成功的支付结果到游戏客户端再次向SDK服务器发送支付请求经过的时间。从游戏客户端接收到SDK服务器发送支付未成功的支付结果开始，经过上述间隔时间，游戏客户端可以根据订单号再次向SDK服务器发送支付结果查询请求，以确认支付结果是否为支付未成功。

在本申请实施例中，游戏客户端向SDK服务器查询支付结果的次数可以是多次。游戏客户端可向SDK服务器查询支付结果直到查询的支付结果为支付成功，或者查询的次数达到上述预设查询次数为止。

SDK服务器在接收到游戏客户端的支付结果查询请求时执行的操作，可以参考步骤S112，这里不再进行赘述。

本申请实施例对上述间隔时间不进行具体限定。

游戏客户端多向SDK服务器发送一次支付结果查询请求，都会多增加SDK服务器的负荷。如果游戏客户端在多次向SDK服务器发送支付结果查询请求得到的支付结果均为支付失败，则很有可能是用户取消支付或者支付应用并未扣款成功等情况。出于上述考虑，游戏客户端不应没有次数限制地向SDK服务器查询支付结果，这样会极大地增加SDK服务器的负荷。

另外，由于支付应用向SDK服务器发送支付结果的过程中也可能占用时间较长，游戏客户端不应在向SDK服务器查询一次得到支付结果为支付未成功，就确认支付结果为支付未成功。

在平衡上述查询次数过多导致SDK服务器负荷过大的问题和查询次数太少导致查询结果不准确的问题时，游戏客户端可以对每一个订单号预设查询次数，例如，3次或者4次等。当游戏客户端根据一个订单号向SDK服务器发送支付结果查询请求的次数超过上述查询次数时，游戏客户端不再根据上述一个订单号向SDK服务器发送支付结果查询请求。其中，上述一个订单号的支付结果为游戏客户端最后一次向SDK服务器发送支付结果查询请求得到的支付结果。

本申请实施例对上述查询次数不进行限定。

由于SDK客户端在与支付应用通信并确认支付结果的过程可能占用时间较长，SDK客户端发送给游戏客户端的支付结果可能不准确。在本申请实施例中，在接收到SDK客户端发送的支付未成功的支付结果时，游戏客户端可向可信度更高的SDK服务器发送支付结果查询请求，来对支付结果进行确认。并且，游戏客户端向SDK服务器查询支付结果的次数可以为多次。上述游戏客户端向SDK服务器查询支付结果的操作，可以减少已付款成功但游戏客户端未下发游戏道具的情况，提高订单处理的准确性，从而提高用户的游戏体验感。

请参阅图3，图3是本申请实施例提供的一种游戏的游戏界面示意图。该游戏界面为游戏道具购买界面。如图3所示，该游戏界面可包含当前金币数量410、关闭控件420和商品选项430。其中：

当前金币数量410可表示当前登录账号拥有的金币数量。例如，在图3所示的游戏界面中，当前登录账户拥有1900个金币。

关闭控件420可用于关闭图3所示的游戏界面。当检测到作用于关闭控件420的用户操作，游戏客户端可关闭该游戏界面。

商品选项430中可包含不同类型的商品，例如，特惠礼包431、入门套装、学徒套装和高手套装等。上述不同类型的商品可以包含不同种类和数量的游戏道具。例如，特惠礼包431中包含500个金币、1个彩虹球、1个纸飞机和1个炸弹。该游戏界面还可包含用于用户购买不同类型的商品的下单控件。例如，用于购买特惠礼包的下单控件432。下单控件431可以包含特惠礼包的价格，例如，6元。当接收到作用在下单控件431的用户操作时，游戏客户端可以向SDK客户端发起支付请求。上述支付请求中可以包含特惠礼包431中的游戏道具种类、数量以及价格等数据。

下面介绍游戏客户端通过SDK客户端调用支付应用进行支付时可能在移动终端上显示的支付界面。

请参阅图4，图4是本申请实施例提供的一种游戏的支付界面示意图。当接收到用户作用在如图3所示游戏界面中下单控件431的操作，游戏客户端向SDK客户端发送支付请求。SDK客户端可在移动终端上显示如图4所示的支付界面500。

如图4所示，支付界面500中包含返回控件510、订单信息520、支付应用选项530和确认支付按钮540。其中：

返回控件510用于返回游戏。

在一种可能的实现方式中，响应于用户作用在返回控件510上的用户操作，SDK客户端可以在支付界面500上显示取消支付确认选项。上述取消支付确认选项可用于询问用户是否要取消支付。当接收到用户确认取消支付的操作时，游戏客户端可以运行游戏，在移动终端上显示游戏界面。

订单信息520可包含于游戏客户端发送的支付请求中。订单信息520可以包含商品名称521、商品金额522、优惠券523和待支付金额524。其中，商品名称521可用于提示用户订单中商品的内容。例如，商品名称可以为“特惠礼包”或者其他商品的名称等。商品金额522可用于提示用户商品的价格。优惠券523可用于提示用户选择可用的优惠券，若没有优惠券，则SDK客户端可以在支付界面上显示无可用。待支付金额524可用于提示用户实际需要支付的金额，即商品金额522减去优惠券523可以优惠的金额后的金额。

支付应用选项530可用于用户选择支付的方式，可以包含支付宝选项531和微信支付选项532。本申请实施例对支付应用选项的内容不进行限定，除了可以为支付宝选项和微信支付选项，还可以为其它选项的支付方式。

确认支付按钮540可用于SDK客户端调用支付应用显示支付界面，供用户输入支付密码。例如，当支付应用选项530中微信支付选项532被选择时，SDK客户端接收到作用于确认支付按钮540的用户操作，SDK客户端可以调用微信支付的支付界面，还可以将上述商品名称521和待支付金额524等信息发送给微信支付。微信支付可以接收用户输入的支付密码，并向与微信支付对应的支付服务器进行支付结果确认。

在一种可能的实现方式中，当检测到用户提交了支付密码，支付应用可以将上述支付密码和待支付金额发送给支付服务器。支付服务器可以校验上述支付密码的准确性，并进行扣款操作。当扣款成功，支付应用可以接收到支付服务器发送的支付成功的支付结果。支付应用可以将支付成功的支付结果发送给SDK客户端，并显示如图5所示的支付界面500。

请参阅图5，图5是本申请实施例提供的另一种游戏的支付界面示意图。该支付界面500可包含支付结果提示560、返回游戏按钮570和查看订单按钮580。其中：

支付结果提示560可用于提示用户支付结果。若支付服务器扣款成功，支付应用可在支付界面上提示用户支付成功以及支付金额。若支付服务器扣款未成功，支付应用可在支付界面上提示用户支付未成功。

返回游戏按钮570用于游戏客户端显示游戏界面。

查看订单按钮580用于显示订单信息，例如，订单号、商品名称、支付金额和收款方等信息。本申请实施例对订单信息中包含的内容不进行具体限定。

当检测到作用在如图5所示的支付界面500中返回游戏按钮570的用户操作，游戏客户端可在移动终端上显示游戏界面。若支付应用在SDK客户端预设的限定时间内将支付成功的支付结果发送给SDK客户端，而SDK客户端将接收到的支付成功的支付结果发送游戏客户端，游戏客户端可以在移动终端上显示如图6所示的游戏界面400。

请参阅图6，图6是本申请实施例提供的另一种单机游戏的游戏界面示意图。游戏界面400包含游戏道具下发提示440和点击继续按钮450。其中：

游戏道具下发提示440可以包含用户购买的游戏道具的种类和数量，用于提示用户游戏道具已下发。

点击继续按钮450可用于游戏客户端继续运行游戏，以便于用户继续游戏。

考虑到当支付应用向SDK服务器发送支付结果的过程占用时间特别长，可能出现游戏客户端因向SDK服务器查询的次数已经达到预设的查询次数而不再查询之后，SDK服务器才接收到支付应用发送的支付结果。

为了进一步减少上述由于支付应用向SDK服务器发送支付结果的过程占用时间特别长而带来的问题，游戏客户端可以在每一次启动游戏时向SDK服务器获取最近多天还未处理的订单号，然后根据上述还未处理的订单号依次向SDK服务器发送支付结果查询请求，再根据各订单号对应的支付结果进行相应的操作。上述还未处理的订单号即为SDK服务器中未被标记的订单号。由于在接收到订单号的支付结果为支付成功时，游戏客户端可以下发游戏道具，并向SDK服务器发送订单处理消息，SDK服务器可以将已经下发游戏道具对应的订单号进行标记。则SDK服务器中未被标记的订单号即为支付未成功的订单号，其中可以包含已付款成功但游戏客户端未下发游戏道具的订单号和支付被取消游戏客户端未下发游戏道具的订单号。

上述最近多天可以为最近三天、最近四天等等，本申请实施例对此不进行限定。

游戏客户端在启动游戏时向SDK服务器查询上述未被标记的订单号的支付情况，可以再次确认订单号的支付结果，减少出现已付款成功但游戏客户端未下发游戏道具的情况。另外，当出现已付款成功但游戏客户端未下发游戏道具的情况，用户找客服人员解决时，客服人员可以先让用户重新启动游戏。这样，可以缩短客服人员处理单机游戏支付问题的时间。

请参阅图7，图7是本申请实施例提供的另一种订单处理方法的流程图。如图7所示的订单处理方法可用于减少因延时特别严重而出现的已付款成功但游戏客户端未下发游戏道具的情况。如图7所示，该方法包括步骤S201-S206。

S201、游戏客户端启动游戏。

游戏客户端启动游戏的操作，可以为当移动终端未运行游戏应用时，响应于用户作用在游戏应用图标上的操作，移动终端开始运行游戏应用。上述移动终端未运行游戏应用可以包含移动终端未在前台运行游戏应用和移动终端未在后台运行游戏应用等情况。

S202、游戏客户端向SDK服务器获取最近N天还未处理的订单号。

当接收到启动游戏的用户操作时，游戏客户端向SDK服务器获取最近N天还未处理的订单号。上述还未处理的订单号即为SDK服务器中未被标记的订单号。由于在接收到订单号的支付结果为支付成功时，游戏客户端可以下发游戏道具，并向SDK服务器发送订单处理消息，SDK服务器可以将已经下发游戏道具对应的订单号进行标记。则SDK服务器中未被标记的订单号即为支付未成功的订单号，其中可以包含已付款成功但游戏客户端未下发游戏道具的订单号和支付被取消游戏客户端未下发游戏道具的订单号。上述N为正整数。

不限于上述获取最近N天还未处理的订单号，还可以为获取最近一段时间内还未处理的订单号，例如，1小时、5小时等等。本申请实施例对此不进行限定。

S203、SDK服务器向游戏客户端返回最近N天还未处理的订单号。

当接收到游戏客户端发送的获取最近N天还未处理的订单号的请求，SDK服务器向游戏客户端返回最近N天还未处理的订单号。

S204、游戏客户端根据还未处理的订单号，依次向SDK服务器发送支付结果查询请求。

S205、SDK服务器向游戏客户端依次返回各订单号的支付结果。

当接收到游戏客户端发送的订单号的支付结果查询请求，SDK服务器将对应对订单号的支付结果返回给游戏客户端。

S206、若支付结果为支付成功，游戏客户端下发游戏道具。

若接收到的SDK服务器发送的支付结果为支付成功，则游戏客户端可以根据该支付结果对应的订单号下发游戏道具。另外，游戏客户端可以根据上述已下发游戏道具的订单号向SDK服务器发送订单处理消息。SDK服务器可以将上述订单处理消息对应的订单号进行标记。

需要进行说明的是，若接收到的SDK服务器发送的结果为支付未成功，游戏客户端可以不进行任何操作。对于上述支付结果仍为支付未成功的订单号，游戏客户端在从SDK客户端接收到该订单号的支付结果为支付未成功时，可以多次向SDK服务器查询支付结果。而这多次向SDK服务器查询支付结果仍然得到的是支付未成功的支付结果，即该订单号未被SDK服务器标记。游戏客户端重启游戏再次向SDK服务器查询该订单号的支付结果，得到的仍是支付未成功的支付结果。经过上述游戏客户端多次向SDK服务器查询的操作，该订单号的状态很有可能就是未支付，因而游戏客户端可以不进行任何操作。

由于可能出现支付应用向SDK服务器发送支付结果的过程占用时间特别长的情况，游戏客户端在启动游戏时，向SDK服务器获取最近N天内未下发游戏道具的订单号，可以再次向SDK服务器确认这些订单号的支付情况，从而进一步减少已付款成功但游戏客户端未下发游戏道具的情况。

在本申请实施例中，第一应用可以为上述游戏应用，第二应用可以为上述支付应用。本申请实施例对上述第一应用不进行限定，除了可以为游戏应用，还可以为其他可提供商品购买的应用。

第一订单可以与步骤S102中SDK服务器创建的订单号对应，可用于指示游戏道具的种类、数量以及金额等。

第一支付结果可以为步骤S108支付应用在预设的限定时间内发送给游戏客户端的支付结果，或者，可以为当支付应用未在预设的限定时间将支付结果发送给游戏客户端，游戏客户端接收到来自SDK客户端默认支付未成功的支付结果。

第一应用向SDK服务器查询第一订单的第二支付结果，其中，查询的次数小于或等于预设次数M。上述第二支付结果可以为第一应用第一次向SDK服务器查询得到的支付结果，也可以为第一应用第M次向SDK服务器查询得到的支付结果，还可以为第一应用第一次与第M次中间任意一次向SDK服务器查询得到的支付结果。上述SDK服务器中保存的第二支付结果，可以为上述SDK服务器从支付应用获取，还可以为上述SDK服务器从支付服务器中获取，本申请实施例对此不进行限定。

当第二支付结果指示支付成功，移动终端通过第一应用根据第二支付结果对第一订单进行处理。其中，若第一应用为游戏应用，移动终端可以通过游戏应用根据第二支付结果对第一订单下发游戏道具。

当第二支付结果指示支付未成功，且移动终端通过第一应用向SDK服务器查询第一订单的次数等于预设次数M时，移动终端通过第一应用根据第二支付结果对第一订单进行处理。其中，若第一应用为游戏应用，则游戏应用以第M次向SDK服务器查询得到的第一订单的第二支付结果作为支付结果，且不下发游戏道具。

当重新启动第一应用时，移动终端通过第一应用向SDK护额去获取预设时间内未被标记的第二订单的支付结果。其中，上述预设时间可以为最近N天，还可以为最近1小时、5小时等等。本申请实施例对此不进行限定。上述N为正数。

第一应用通知SDK服务器对第一订单号进行标记，被标记的第一订单可以指示上述第一订单已经处理完成。对于上述已经处理完成的订单，SDK服务器可以不再向上述第一应用发送上述已经处理完成的订单的订单号。或者，SDK服务器可以不再向上述第一应用发送上述已经处理完成的订单的订单号及其支付结果。

请参阅图8，图8是本申请实施例提供的一种订单处理装置的结果示意图。如图8所示，该订单处理装置安装有第一应用和第二应用。

该订单处理装置包括获取单元610、确认单元620和处理单元630。其中：

获取单元610，可用于通过上述第一应用请求上述第二应用对第一订单进行支付，并通过上述第一应用获得第一订单的第一支付结果。

确认单元620，可用于当上述第一支付结果指示支付未成功时，通过上述第一应用向SDK服务器查询上述第一订单的第二支付结果。

处理单元630，可用于当上述第二支付结果指示支付成功时，通过上述第一应用根据上述第二支付结果对上述第一订单进行处理。

本发明实施例中，获取单元610、确认单元620和处理单元630可以是图9所描述示例中的处理器710调用计算机程序实现。

请参阅图9，图9是本申请实施例提供的另一种订单处理装置的结构示意图。该订单处理装置安装有第一应用和第二应用。如图9所示，该订单处理装置包括通过总线连接的处理器710、存储器720和通信接口730。其中，存储器720可用于存储计算机程序。处理器710可用于调用上述计算机程序，使得上述装置执行以下操作：

通过第一应用请求第二应用对第一订单进行支付，并通过第一应用获得第一订单的第一支付结果。

当第一支付结果指示支付未成功时，通过第一应用向软件开发工具包SDK服务器查询第一订单的第二支付结果；第二支付结果由SDK服务器从第二应用获取。

当第二支付结果指示支付成功时，通过第一应用根据第二支付结果对第一订单进行处理。

不限于上述模块，该订单处理装置还可以包含更多或更少的模块。

由于SDK客户端与支付应用通信并确认支付结果的过程可能占用时间较长，SDK客户端发送给游戏客户端的支付结果可能不准确。在本申请实施例中，在接收到SDK客户端发送的支付未成功的支付结果时，游戏客户端可向可信度更高的SDK服务器发送支付结果查询请求，来对支付结果进行确认。并且，游戏客户端向SDK服务器查询支付结果的次数可以为多次。上述游戏客户端向SDK服务器查询支付结果的操作，可以减少已付款成功但游戏客户端未下发游戏道具的情况，提高订单处理的准确性，从而提高用户的游戏体验感。

由于可能出现支付应用向SDK服务器发送支付结果的过程占用时间特别长的情况，游戏客户端在启动游戏时，向SDK服务器获取最近N天内未下发游戏道具的订单号，可以再次向SDK服务器确认这些订单号的支付情况。从而进一步减少已付款成功但游戏客户端未下发游戏道具的情况，以进一步提高订单处理的准确性。

本申请实施例还提供一种计算机可读存储介质，上述计算机可读存储介质存储有计算机程序，上述计算机程序包括程序指令，上述程序指令当被处理器执行时使上述处理器执行图2所描述的方法中所描述的实现方式。

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

以上所述，仅为本申请实施例的具体实施方式，但本申请实施例的保护范围并不局限于此，任何在本申请实施例揭露的技术范围内的变化或替换，都应涵盖在本申请实施例的保护范围之内。因此，本申请实施例的保护范围应以所述权利要求的保护范围为准。

Claims (9)

1.一种订单处理方法，其特征在于，所述方法应用于移动终端，所述移动终端安装有第一应用和第二应用，所述方法包括：

所述移动终端通过所述第一应用请求所述第二应用对第一订单进行支付，并通过所述第一应用获得所述第一订单的第一支付结果；所述第一应用为游戏应用，所述第二应用为支付应用，所述第一订单为所述第一应用中购买游戏道具的订单；

当所述第一支付结果指示支付未成功时，所述移动终端通过所述第一应用向软件开发工具包SDK服务器查询所述第一订单的第二支付结果；所述第二支付结果由所述SDK服务器从所述第二应用获取；

当所述第二支付结果指示支付成功时，所述移动终端通过所述第一应用根据所述第二支付结果下发所述第一订单对应的游戏道具。

2.根据权利要求1所述的方法，其特征在于，所述通过所述第一应用获得所述第一订单的第一支付结果，包括：

当所述移动终端通过所述第一应用在预设的限定时间T内未接收到所述第二应用发送的支付结果时，所述移动终端通过所述第一应用确定所述第一支付结果指示支付未成功；所述预设的限定时间T为正数。

3.根据权利要求1所述的方法，其特征在于，所述通过所述第一应用获得所述第一订单的第一支付结果，包括：

所述移动终端通过所述第一应用在预设的限定时间T内接收所述第二应用发送第一支付结果。

4.根据权利要求2所述的方法，其特征在于，所述移动终端通过所述第一应用请求所述第二应用对第一订单进行支付，并通过所述第一应用获得所述第一订单的第一支付结果之后，所述方法还包括：

当所述第一支付结果指示支付成功时，所述移动终端通过所述第一应用根据所述第一支付结果下发所述第一订单对应的游戏道具；

所述移动终端通过所述第一应用通知所述SDK服务器对所述第一订单进行标记；被标记的所述第一订单指示所述第一订单已经完成处理。

5.根据权利要求4所述的方法，其特征在于，所述移动终端通过所述第一应用请求所述第二应用对第一订单进行支付，并通过所述第一应用获得所述第一订单的第一支付结果之后，所述方法还包括：

当重新启动所述第一应用时，所述移动终端通过所述第一应用向所述SDK服务器获取预设时间内未被标记的第二订单的支付结果，所述第二订单为所述第一应用中购买游戏道具的订单；

当所述第二订单的支付结果指示支付成功时，所述移动终端通过所述第一应用根据所述第二订单的支付结果下发所述第二订单对应的游戏道具。

6.根据权利要求1-5中任一项所述的方法，其特征在于，所述移动终端通过所述第一应用向SDK服务器查询所述第一订单的次数小于或等于预设次数M，所述当所述第一支付结果指示支付未成功时，所述移动终端通过所述第一应用向软件开发工具包SDK服务器查询所述第一订单的第二支付结果之后，所述方法还包括：

当所述第二支付结果指示支付未成功，且所述移动终端通过所述第一应用向所述SDK服务器查询所述第一订单的次数等于预设次数M时，所述移动终端停止向所述SDK服务器查询所述第一订单的支付结果；所述预设次数M为正整数。

7.一种订单处理装置，其特征在于，所述订单处理装置安装有第一应用和第二应用，所述装置包括：

获取单元，用于通过所述第一应用请求所述第二应用对第一订单进行支付，并通过所述第一应用获得所述第一订单的第一支付结果；所述第一应用为游戏应用，所述第二应用为支付应用，所述第一订单为所述第一应用中购买游戏道具的订单；

确认单元，用于当所述第一支付结果指示支付未成功时，通过所述第一应用向软件开发工具包SDK服务器查询所述第一订单的第二支付结果；所述第二支付结果由所述SDK服务器从所述第二应用获取；

处理单元，用于当所述第二支付结果指示支付成功时，通过所述第一应用根据所述第二支付结果下发所述第一订单对应的游戏道具。

8.一种游戏订单处理装置，其特征在于，包括：

处理器、通信接口和存储器，所述存储器用于存储计算机程序，所述通信接口、所述存储器分别通过总线与所述处理器耦合；

其中，所述处理器用于调用所述计算机程序，使得所述装置执行如权利要求1至6任一项所述的订单处理方法。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储计算机程序，所述计算机程序被处理器执行，以实现权利要求1至6任一项所述的方法。