CN112200634A - 订单处理方法、装置、电子设备及存储介质 - Google Patents

Abstract

本发明涉及数据处理，公开一种订单处理方法、装置、电子设备及存储介质，方法包括：向应用服务器和应用平台发起内购请求并生成相应订单；接收应用服务器返回的平台订单号，以及应用平台返回的交易订单号并进行关联，调用所述内购框架，在应用平台端完成内购请求的支付操作；确定接收到应用平台返回的支付收据，基于平台订单号、交易订单号和收据生成订单信息，保存订单信息，并将订单的订单状态设置为待同步状态；当检测到对应于内购请求的应用程序启动时，将处于待同步状态的订单的订单信息同步至应用服务器，以令应用服务器基于订单信息发放与订单对应的虚拟商品。本发明可以防止掉单、漏单现象，提高用户的使用体验。

Description

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

技术领域

本发明涉及数据处理领域，尤其涉及一种订单处理方法、装置及计算机可读存储介质。

背景技术

随着移动互联网的快速发展，越来越多的应用上架到应用平台(为手机、平板电脑等提供免费、收费游戏、软件应用下载服务的平台)，并衍生出大量的虚拟商品，这些应用可能是免费的，但是有些应用里面会有一些虚拟商品是收费的，需要进行支付，比如游戏应用内的虚拟道具、社交应用内的虚拟礼物等。这样在应用内部收费的支付模式，称之为内购。

目前内购是在应用中内嵌内购框架，应用使用内购框架与应用平台进行数据传输。以苹果公司为例，为保护用户隐私，苹果公司不给商品提供商出具用户内购信息，也不追踪商品提供商是否发放商品。一旦用户内购的虚拟商品没有到账，与应用提供商出现分歧时，很难查询到用户是否真正内购了此虚拟商品，以苹果手机为例，IOS(苹果手机专用操作系统)内购的流程框架如图1所示，其内购的步骤流程如下：

应用通过StoreKit(内购框架)连接到应用平台，以提示并安全地处理付款；

应用平台通过StoreKit将用户内购的商品的相关信息返回到应用；

应用通过应用服务器验证支付凭证。

对于自动订阅的商品，苹果会通知到应用服务器，但对于非自动订阅的商品，订单状态的同步则依赖于应用。发明人发现，当用户出现弱网或断网或退出应用等操作时，应用与应用服务器断开连接，订单状态无法及时同步，出现用户支付成功而商品发放不成功的情况。从而出现掉单、漏单的情况，发明人意识到，这在给客户带来经济损失的同时也给公司带来了不良影响。

发明内容

本发明提供一种订单处理方法、装置、电子设备及存储介质，其主要目的在于防止了内购时掉单、漏单现象。

为实现上述目的，本发明提供的一种订单处理方法，包括：

终端向应用服务器和应用平台发起内购请求并生成相应订单，其中，利用内置的内购框架向所述应用平台发起所述内购请求；

接收所述应用服务器返回的平台订单号，以及所述应用平台返回的交易订单号，将所述平台订单号和所述交易订单号进行关联，并调用所述内购框架，在所述应用平台端完成所述内购请求的支付操作；

确定接收到所述应用平台返回的支付收据，基于所述平台订单号、所述交易订单号和所述收据生成订单信息，保存所述订单信息，并将所述订单的订单状态设置为待同步状态；

当检测到对应于所述内购请求的应用程序启动时，将处于待同步状态的订单的订单信息同步至应用服务器，以令所述应用服务器基于所述订单信息发放与所述订单对应的虚拟商品。

本发明还提供一种订单处理装置，所述装置包括：

内购请求模块，用于向应用服务器和应用平台发起内购请求并生成相应订单，其中，利用内置的内购框架向所述应用平台发起所述内购请求；

订单关联模块，用于接收所述应用服务器返回的平台订单号，以及所述应用平台返回的交易订单号，将所述平台订单号和所述交易订单号进行关联，并调用所述内购框架，在所述应用平台端完成所述内购请求的支付操作；

订单信息生成模块，用于确定接收到所述应用平台返回的支付收据，基于所述平台订单号、所述交易订单号和所述收据生成订单信息，保存所述订单信息，并将所述订单的订单状态设置为待同步状态；

订单信息同步模块，用于当检测到对应于所述内购请求的应用程序启动时，将处于待同步状态的订单的订单信息同步至应用服务器，以令所述应用服务器基于所述订单信息发放与所述订单对应的虚拟商品。

本发明还提供一种电子设备，所述电子设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如上所述的订单处理方法。

本发明还提供一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的订单处理方法。

本发明实施例通过在支付前先将平台订单号与应用平台发送的交易订单号进行关联，当订单信息同步至应用服务器的过程中发生中断时，用户再次打开应用程序，应用程序将订单信息发送给应用服务器，应用服务器根据交易订单号关联的平台订单号判断交易订单号是否属于该应用程序的当前登录用户账号，从而避免因断网导致向应用程序发放商品错误的情况，防止掉单、漏单现象，提高用户的使用体验。

附图说明

图1为现有技术中内购的流程框架示意图；

图2为本发明提供的订单处理方法一实施例的流程示意图；

图3为本发明提供的订单处理装置一实施例的模块示意图；

图4为本发明提供的实现订单处理方法的电子设备一实施例的结构示意图；

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明提供一种订单处理方法，用于对内购的订单状态进行同步处理，以防止出现出现掉单、漏单的情况。

参照图2所示，为本发明一实施例提供的订单处理方法的流程示意图。该方法可以由一个装置执行，该装置可以由软件和/或硬件实现。

在本实施例中，订单处理方法包括：

S1、终端向应用服务器和应用平台发起内购请求并生成相应订单，其中，利用内置的内购框架向所述应用平台发起所述内购请求；

详细的，例如，用户通过智能终端进入到某一应用程序中，通过触发其中某一虚拟商品的购买选项，则触发了终端上该虚拟商品的内购请求，此时，终端即可向应用服务器发送该内购请求，应用服务器会响应该内购请求生成相应的平台订单号，并将生成的平台订单号反馈回应用程序。在本实施例中，应用服务器生成平台订单号时，可将此平台订单号与该内购订单的应用程序的用户账号关联起来。同时，终端会通过内置的内购框架(StoreKit)向应用平台发送该内购请求，应用平台会通过StoreKit返回给应用程序一个交易订单号(transactionIdentifier)，其包含发送计算机的标识符(前16位)，后跟4个字节的事务序列号。

进一步地，步骤S1中，发送内购请求之前，需要先获得商品信息，获得商品信息的过程是通过请求(Request)对象来实现的。具体的说，对应每个商品都具有商品标识符，应用程序从应用服务器下载包含商品标识符的商品列表。具体说，是应用服务器中保存有包含商品列表的JSON文件，应用服务器将JSON文件返回给应用程序，应用程序从中提取包含商品标识符的商品列表。商品标识符的形式可以是例如com.公司名.商品名.道具名。应用程序使用Request对象根据所需的商品标识符向应用平台发送请求，请求得到对应的商品的信息，应用平台返回商品信息给应用程序，应用程序把返回的商品信息显示给用户，用户选择想要内购的商品。

其中，向应用平台发送请求时，应用程序通过创建并初始化一个Request对象，并为其附加委托(delegate)方法来实现。Request对象中包含有商品标识的列表。delegate方法为Request对象添加一个或多个实现应用平台处理请求结果的事件处理程序，例如请求成功，请求失败对应的处理程序。启动请求后，商品标识会被传送到应用平台，并异步调用Request对象的delegate方法，以获得请求的结果。应用平台将会返回给应用程序本地化信息，以IOS为例，本地化信息指在iTunes Connect中设置的关于商品的商品名称、性能、类型、型号等信息，应用程序接收到这些信息后，即可将这些信息展示在应用程序。

S2、接收所述应用服务器返回的平台订单号，以及所述应用平台返回的交易订单号，将所述平台订单号和所述交易订单号进行关联，并调用所述内购框架，在所述应用平台端完成所述内购请求的支付操作；

本实施例中，所述平台订单号是与应用程序的用户账号关联的字符串，所述交易订单号是唯一地标识一次成功交易的字符串。

其中，调用内购框架发起支付包括创建包含了商品标识符和内购数量的商品支付(SKPayment)对象，并将SKPayment对象放入支付队列，并创建包含当前交易状态信息的商品支付交易(SKPaymentTransaction)对象以供应用平台监听支付，以使得应用平台在监听到支付成功后生成当前内购订单的收据。

S3、确定接收到所述应用平台返回的支付收据，基于所述平台订单号、所述交易订单号和所述收据生成订单信息，保存所述订单信息，并将所述订单的订单状态设置为待同步状态；

需要说明的是，此处所述置为待同步状态是指不调用应用平台提供的结束交易的接口(finishTransaction(_:))，因为应用平台内购的机制是对于当前的交易，只要不调用应用平台提供的结束交易的接口(finishTransaction(_:))，则会一直收到应用平台的支付成功回调，并在收到回调时，调用应用服务器接口同步订单的状态。

S4、当检测到对应于所述内购请求的应用程序启动时，将处于待同步状态的订单的订单信息同步至应用服务器，以令所述应用服务器基于所述订单信息发放与所述订单对应的虚拟商品。

在将所述订单的订单信息同步至所述应用服务器的过程中发生中断的情况下，在应用程序再次启动后(指用户在网络恢复后再次点击打开应用程序)，终端检测到应用程序启动，则进一步检测是否有待同步的订单，若有则将所述平台订单号、所述交易订单号以及对应的收据发送给所述应用服务器，以使所述应用服务器根据所述交易订单号关联的所述平台订单号判断所述交易订单号是否属于所述应用程序当前登录的用户账号。进一步地，如果是，则调用应用平台的验证凭证接口校验收据的有效性，若是验证通过，则应用服务器根据与交易订单号关联的平台订单号确定内购的商品，向应用程序发放商品。并且，应用服务器修改订单状态为同步完成，应用程序将本地保存的订单信息删除。

其中，交易成功的信息包含交易订单号(transactionIdentifier)和交易收据(transactionReceipt)的属性。其中，transactionReceipt属性包含了一个经过签名的收据，其中记录了支付的详细信息，用于对支付的跟踪、验证。

交易信息的一些键，以及其对应的属性可如下表所示：

其中，在进行校验收据时，应用服务器对收据进行base64编码，并将base64编码后的收据发送给应用平台进行验证。Base64编码是网络上用于传输8Bit字节码的编码方式之一，可用于在HTTP环境下传递较长的标识信息。采用Base64编码具有不可读性，需要解码后才能阅读。

详细的，应用服务器将收据发送给应用平台的过程如下：

应用服务器从SKPaymentTransaction对象的transactionReceipt属性中得到收据的数据，并以base64方式编码，应用服务器创建JSON对象，有一个键值对，键名为"receipt-data"，值为base64编码后的收据的数据。形式如下：

{

"receipt-data":"Base64编码"

}

应用平台也以JSON的格式返回数据。

然后应用服务器发送HTTP POST的请求，将数据发送到应用平台。

应用平台将解密的收据与其存储的收据比对，若其存储有该收据，则验证通过，若没有，则验证不通过。应用平台将验证结果返回给应用服务器。其中，receipt是base64编码后的收据，status的值表示该收据信息是否有效。

应用平台给应用服务器的返回结果也是一个JSON格式的对象，被包含在SKPaymentTransaction对象(支付交易对象)的transactionReceipt属性(交易收据属性)中，包含两个键值对status和receipt，其形式如下：

如果status的值为0，就说明该receipt为有效的，否则就是无效的。

下面说明一下将平台订单号与交易订单号关联的作用。由于在支付之前将平台订单号与交易订单号关联起来可以使得当前登录的应用程序的用户账号的平台订单号与交易订单号唯一绑定。因为StoreKit不会区分是应用程序的哪个用户账号进行了商品支付，对于StoreKit来说，只会区分应用程序所绑定的在应用平台的用户系统账号，例如在IOS系统下用户注册的AppleID。在支付成功后进行验证的时候，收据是应用程序通过StoreKit的API获取的，返回的是同一个应用平台的用户系统账号下内购的商品。对于应用程序不同的用户账号，只要应用程序登录的是同一个应用平台的用户系统账号，那么都会获取到交易的收据。在这种情况下，如果交易订单号与平台订单号不是绑定的，则不能获得与内购此商品的用户账号的关联。如果刚好在此时切换了应用程序登录的用户账号，这里称由第一用户账号切换到第二用户账号，则应用服务器并不知道是哪个账号触发的内购，而会将上一个应用程序用户账号的内购商品发放到新登录的这个应用程序用户账号，这显然会造成错误的商品发放。

例如，用户通过第一AppleID登录的应用平台，并保持在第一AppleID的情况下用第一用户账号登录了应用程序，内购了商品，获得了交易订单号、平台订单号，但却没有将交易订单号与平台订单号关联。在其支付成功后，突然网络信号变差导致断网。在网络好转后，用户保持在第一AppleID的情况下用第二用户账号登录了应用程序，而第二用户账号并没有内购任何商品。但是StoreKit只区分AppleID，所以，其还是会把交易订单号和收据发送给应用程序。而由于交易订单号与平台订单号没有关联，则应用程序把该收据和交易订单号发往应用服务器后，应用服务器并不知道与该交易订单号对应的平台订单号不属于第二用户账号，应用服务器使用该收据去应用平台进行验证，通过后即会把商品发放给第二用户账号。这显然是不合理的。而本实施例在应用程序获得了平台订单号和交易订单号后，先将交易订单号与平台订单号关联起来，如果在断网后用户保持在第一AppleID的情况下用第二用户账号登录了应用程序，则应用服务器根据与该交易订单号对应的平台订单号可以知道该交易并不是第二用户账号进行的，则不会利用收据去应用平台验证，也就不会把商品错误的发放到第二用户账号上了。

另外，对于支付成功以及商品发放成功后，用户通过应用平台发起退款的情况，应用服务器可以定期主动查询应用平台，去校验每一笔支付成功的订单状态是否已发生改变，当发现有订单状态发生改变时，应用服务器将该订单同步，收回对应用户的商品。

进一步地，还设置有遮挡层，所述遮挡层的作用是在需要的时候遮挡住上面的视图，使其无法进行操作。例如，在应用程序向应用服务器请求商品列表时，若请求成功则用遮挡层遮挡上面的视图，防止连续点击。所述请求成功是指应用程序通过HTTP的get请求方法向向应用服务器发送请求，应用服务器通过返回给应用程序的HTTP请求的状态码来表示对get请求的响应，例如，1XX：表示信息提示，2XX：表示成功，3XX表示请求被重定向，表示要完成请求需要进一步操作。4XX表示请求可能出错。应用平台返回商品信息给应用程序。如果失败则提示用户,并移除遮挡层,用户可以再点击内购按钮，如果成功就将订单信息添加到支付队列,添加支付监听。其中，通过创建的SKpayment对象来收集支付信息，并将SKPayment对象添加到支付队列中，SKPayment对象中包含商品标识以及内购数量。使用addPayment方法将SKPayment对象添加到SKPaymentQueue(支付队列)，使用SKPaymentTransaction Observer来监听支付。

下面说明一下遮挡层的实现原理，应用程序的内购功能是通过在Xcode中加入内购框架模板(StoreKit.framework)，在其中创建有相应的类来实现内购功能。本实施例声明实现内购功能的类为控制器类，每次调用内购的时候将这个控制器设置为主控制器的子控制器，所述主控制器是应用程序的实现主要功能的类，例如，虚拟游戏的加载、虚拟游戏的动画显示等，而子控制器则用于实现内购功能，在子控制器的视图上有需要显示与用户交互的内购页面需求，通过viewController控制将遮挡层加载到当前视图上或卸载遮挡层，从而控制是否显示内购功能。

如图3所示，是本发明订单处理装置一实施例的功能模块示意图。

本发明的订单处理装置100可以安装于电子设备中。根据实现的功能，所述订单处理装置100可以包括内购请求模块101，订单关联模块102，订单信息生成模块103，订单信息同步模块104，本发明所述模块是指一种能够被电子设备处理器所执行，并且能够完成固定功能的一系列计算机程序段，其存储在电子设备的存储器中。

在本实施例中，关于各模块的功能如下：

其中，内购请求模块101用于向应用服务器和应用平台发起内购请求并生成相应订单，其中，利用内置的内购框架向所述应用平台发起所述内购请求；

详细的，例如，用户通过智能终端进入到某一应用程序中，通过触发其中某一虚拟商品的购买选项，则触发了终端上该虚拟商品的内购请求，此时，终端即可向应用服务器发送该内购请求，应用服务器会响应该内购请求生成相应的平台订单号，并将生成的平台订单号反馈回应用程序。在本实施例中，应用服务器生成平台订单号时，可将此平台订单号与该内购订单的应用程序的用户账号关联起来。同时，终端会通过内置的内购框架(StoreKit)向应用平台发送该内购请求，应用平台会通过StoreKit返回给应用程序一个交易订单号(transaction Identifier)，其包含发送计算机的标识符(前16位)，后跟4个字节的事务序列号。

进一步地，步骤S1中，发送内购请求之前，需要先获得商品信息，获得商品信息的过程是通过请求(Request)对象来实现的。具体的说，对应每个商品都具有商品标识符，应用程序从应用服务器下载包含商品标识符的商品列表。具体说，是应用服务器中保存有包含商品列表的JSON文件，应用服务器将JSON文件返回给应用程序，应用程序从中提取包含商品标识符的商品列表。商品标识符的形式可以是例如com.公司名.商品名.道具名。应用程序使用Request对象根据所需的商品标识符向应用平台发送请求，请求得到对应的商品的信息，应用平台返回商品信息给应用程序，应用程序把返回的商品信息显示给用户，用户选择想要内购的商品。

其中，向应用平台发送请求时，应用程序通过创建并初始化一个Request对象，并为其附加委托(delegate)方法来实现。Request对象中包含有商品标识的列表。delegate方法为Request对象添加一个或多个实现应用平台处理请求结果的事件处理程序，例如请求成功，请求失败对应的处理程序。启动请求后，商品标识会被传送到应用平台，并异步调用Request对象的delegate方法，以获得请求的结果。应用平台将会返回给应用程序本地化信息，以IOS为例，本地化信息指在iTunes Connect中设置的关于商品的商品名称、性能、类型、型号等信息，应用程序接收到这些信息后，即可将这些信息展示在应用程序。

订单关联模块102用于接收所述应用服务器返回的平台订单号，以及所述应用平台返回的交易订单号，将所述平台订单号和所述交易订单号进行关联，并调用所述内购框架，在所述应用平台端完成所述内购请求的支付操作；本实施例中，所述平台订单号是与应用程序的用户账号关联的字符串，所述交易订单号是唯一地标识一次成功交易的字符串。

其中，调用内购框架发起支付包括创建包含了商品标识符和内购数量的商品支付(SKPayment)对象，并将SKPayment对象放入支付队列，并创建包含当前交易状态信息的商品支付交易(SKPaymentTransaction)对象以供应用平台监听支付，以使得应用平台在监听到支付成功后生成当前内购订单的收据。

订单信息生成模块103用于确定接收到所述应用平台返回的支付收据，基于所述平台订单号、所述交易订单号和所述收据生成订单信息，保存所述订单信息，并将所述订单的订单状态设置为待同步状态；

需要说明的是，此处所述置为待同步状态是指不调用应用平台提供的结束交易的接口(finishTransaction(_:))，因为应用平台内购的机制是对于当前的交易，只要不调用应用平台提供的结束交易的接口(finishTransaction(_:))，则会一直收到应用平台的支付成功回调，并在收到回调时，调用应用服务器接口同步订单的状态。

订单信息同步模块104用于当检测到对应于所述内购请求的应用程序启动时，将处于待同步状态的订单的订单信息同步至应用服务器，以令所述应用服务器基于所述订单信息发放与所述订单对应的虚拟商品。

在将所述订单的订单信息同步至所述应用服务器的过程中发生中断的情况下，在应用程序再次启动后(指用户在网络恢复后再次点击打开应用程序)，终端检测到应用程序启动，则进一步检测是否有待同步的订单，若有则将所述平台订单号、所述交易订单号以及对应的收据发送给所述应用服务器，以使所述应用服务器根据所述交易订单号关联的所述平台订单号判断所述交易订单号是否属于所述应用程序当前登录的用户账号。进一步地，如果是，则调用应用平台的验证凭证接口校验收据的有效性，若是验证通过，则应用服务器根据与交易订单号关联的平台订单号确定内购的商品，向应用程序发放商品。并且，应用服务器修改订单状态为同步完成，应用程序将本地保存的订单信息删除。

其中，交易成功的信息包含交易订单号(transactionIdentifier)和交易收据(transactionReceipt)的属性。其中，transactionReceipt属性包含了一个经过签名的收据，其中记录了支付的详细信息，用于对支付的跟踪、验证。

交易信息的一些键，以及其对应的属性可如下表所示：

其中，在进行校验收据时，应用服务器对收据进行base64编码，并将base64编码后的收据发送给应用平台进行验证。Base64编码是网络上用于传输8Bit字节码的编码方式之一，可用于在HTTP环境下传递较长的标识信息。采用Base64编码具有不可读性，需要解码后才能阅读。

详细的，应用服务器将收据发送给应用平台的过程如下：

应用服务器从SKPaymentTransaction对象的transactionReceipt属性中得到收据的数据，并以base64方式编码，应用服务器创建JSON对象，有一个键值对，键名为"receipt-data"，值为base64编码后的收据的数据。形式如下：

{

"receipt-data":"Base64编码"

}

应用平台也以JSON的格式返回数据。

然后应用服务器发送HTTP POST的请求，将数据发送到应用平台。

应用平台将解密的收据与其存储的收据比对，若其存储有该收据，则验证通过，若没有，则验证不通过。应用平台将验证结果返回给应用服务器。其中，receipt是base64编码后的收据，status的值表示该收据信息是否有效。

应用平台给应用服务器的返回结果也是一个JSON格式的对象，被包含在SKPaymentTransaction对象(支付交易对象)的transactionReceipt属性(交易收据属性)中，包含两个键值对status和receipt，其形式如下：

如果status的值为0，就说明该receipt为有效的，否则就是无效的。

下面说明一下将平台订单号与交易订单号关联的作用。由于在支付之前将平台订单号与交易订单号关联起来可以使得当前登录的应用程序的用户账号的平台订单号与交易订单号唯一绑定。因为StoreKit不会区分是应用程序的哪个用户账号进行了商品支付，对于StoreKit来说，只会区分应用程序所绑定的在应用平台的用户系统账号，例如在IOS系统下用户注册的AppleID。在支付成功后进行验证的时候，收据是应用程序通过StoreKit的API获取的，返回的是同一个应用平台的用户系统账号下内购的商品。对于应用程序不同的应用程序的用户账号，只要应用程序登录的是同一个应用平台的用户系统账号，那么都会获取到交易的收据。在这种情况下，如果交易订单号与平台订单号不是绑定的，则不能获得与内购此商品的用户账号的关联。如果刚好在此时切换了应用程序登录的用户账号，这里称由第一用户账号切换到第二用户账号，则应用服务器并不知道是哪个账号触发的内购，而会将上一个应用程序用户账号的内购商品发放到新登录的这个应用程序用户账号，这显然会造成错误的商品发放。

例如，用户通过第一AppleID登录的应用平台，并保持在第一AppleID的情况下用第一用户账号登录了应用程序，内购了商品，获得了交易订单号、平台订单号，但却没有将交易订单号与平台订单号关联。在其支付成功后，突然网络信号变差导致断网。在网络好转后，用户保持在第一AppleID的情况下用第二用户账号登录了应用程序，而第二用户账号并没有内购任何商品。但是StoreKit只区分AppleID，所以，其还是会把交易订单号和收据发送给应用程序。而由于交易订单号与平台订单号没有关联，则应用程序把该收据和交易订单号发往应用服务器后，应用服务器并不知道与该交易订单号对应的平台订单号不属于第二用户账号，应用服务器使用该收据去应用平台进行验证，通过后即会把商品发放给第二用户账号。这显然是不合理的。而本实施例在应用程序获得了平台订单号和交易订单号后，先将交易订单号与平台订单号关联起来，如果在断网后用户保持在第一AppleID的情况下用第二用户账号登录了应用程序，则应用服务器根据与该交易订单号对应的平台订单号可以知道该交易并不是第二用户账号进行的，则不会利用收据去应用平台验证，也就不会把商品错误的发放到第二用户账号上了。

另外，对于支付成功以及商品发放成功后，用户通过应用平台发起退款的情况，应用服务器可以定期主动查询应用平台，去校验每一笔支付成功的订单状态是否已发生改变，当发现有订单状态发生改变时，应用服务器将该订单同步，收回对应用户的商品。

进一步地，还设置有遮挡层设置模块105，用于使得所述遮挡层的作用是在需要的时候遮挡住上面的视图，使其无法进行操作。例如，在应用程序向应用服务器请求商品列表时，若请求成功则用遮挡层遮挡上面的视图，防止连续点击。所述请求成功是指应用程序通过HTTP的get请求方法向向应用服务器发送请求，应用服务器通过返回给应用程序的HTTP请求的状态码来表示对get请求的响应，例如，1XX：表示信息提示，2XX：表示成功，3XX表示请求被重定向，表示要完成请求需要进一步操作。4XX表示请求可能出错。应用平台返回商品信息给应用程序。如果失败则提示用户,并移除遮挡层,用户可以再点击内购按钮，如果成功就将订单信息添加到支付队列,添加支付监听。其中，通过创建的SKpayment对象来收集支付信息，并将SKPayment对象添加到支付队列中，SKPayment对象中包含商品标识以及内购数量。使用addPayment方法将SKPayment对象添加到SKPaymentQueue(支付队列)，使用SKPaymentTransaction Observer来监听支付。

下面说明一下遮挡层的实现原理，应用程序的内购功能是通过在Xcode中加入内购框架模板(StoreKit.framework)，在其中创建有相应的类来实现内购功能。本实施例声明实现内购功能的类为控制器类，每次调用内购的时候将这个控制器设置为主控制器的子控制器，所述主控制器是应用程序的实现主要功能的类，例如，虚拟游戏的加载、虚拟游戏的动画显示等，而子控制器则用于实现内购功能，在子控制器的视图上有需要显示与用户交互的内购页面需求，通过viewController控制将遮挡层加载到当前视图上或卸载遮挡层，从而控制是否显示内购功能。

如图4所示，是本发明实现订单处理方法的电子设备一实施例的结构示意图。

所述电子设备1可以包括处理器10、存储器11和总线，还可以包括存储在所述存储器11中并可在所述处理器10上运行的计算机程序，如订单处理程序12。

其中，所述存储器11至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、移动硬盘、多媒体卡、卡型存储器(例如：SD或DX存储器等)、磁性存储器、磁盘、光盘等。所述存储器11在一些实施例中可以是电子设备1的内部存储单元，例如该电子设备1的移动硬盘。所述存储器11在另一些实施例中也可以是电子设备1的外部存储设备，例如电子设备1上配备的插接式移动硬盘、智能存储卡(Smart Media Card，SMC)、安全数字(SecureDigital，SD)卡、闪存卡(Flash Card)等。进一步地，所述存储器11还可以既包括电子设备1的内部存储单元也包括外部存储设备。所述存储器11不仅可以用于存储安装于电子设备1的应用软件及各类数据，例如订单处理程序的代码等，还可以用于暂时地存储已经输出或者将要输出的数据。

所述处理器10在一些实施例中可以由集成电路组成，例如可以由单个封装的集成电路所组成，也可以是由多个相同功能或不同功能封装的集成电路所组成，包括一个或者多个中央处理器(Central Processing unit，CPU)、微处理器、数字处理芯片、图形处理器及各种控制芯片的组合等。所述处理器10是所述电子设备的控制核心(Control Unit)，利用各种接口和线路连接整个电子设备的各个部件，通过运行或执行存储在所述存储器11内的程序或者模块(例如订单处理程序等)，以及调用存储在所述存储器11内的数据，以执行电子设备1的各种功能和处理数据。

所述总线可以是外设部件互连标准(peripheral component interconnect，简称PCI)总线或扩展工业标准结构(extended industry standard architecture，简称EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。所述总线被设置为实现所述存储器11以及至少一个处理器10等之间的连接通信。

图4仅示出了具有部件的电子设备，本领域技术人员可以理解的是，图4示出的结构并不构成对所述电子设备1的限定，可以包括比图示更少或者更多的部件，或者组合某些部件，或者不同的部件布置。

例如，尽管未示出，所述电子设备1还可以包括给各个部件供电的电源(比如电池)，可选的，电源可以通过电源管理装置与所述至少一个处理器10逻辑相连，从而通过电源管理装置实现充电管理、放电管理、以及功耗管理等功能。电源还可以包括一个或一个以上的直流或交流电源、再充电装置、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。所述电子设备1还可以包括多种传感器、蓝牙模块、Wi-Fi模块等，在此不再赘述。

进一步地，所述电子设备1还可以包括网络接口，可选地，所述网络接口可以包括有线接口和/或无线接口(如WI-FI接口、蓝牙接口等)，通常用于在该电子设备1与其他电子设备之间建立通信连接。

可选地，该电子设备1还可以包括用户接口，用户接口可以是显示器(Display)、输入单元(比如键盘(Keyboard))，可选地，用户接口还可以是标准的有线接口、无线接口。可选地，在一些实施例中，显示器可以是LED显示器、液晶显示器、触控式液晶显示器以及OLED(Organic Light-Emitting Diode，有机发光二极管)触摸器等。其中，显示器也可以适当的称为显示屏或显示单元，用于显示在电子设备1中处理的信息以及用于显示可视化的用户界面。

应该了解，所述实施例仅为说明之用，在专利申请范围上并不受此结构的限制。

所述电子设备1中的所述存储器11存储的订单处理程序12是多个指令的组合，在所述处理器10中运行时，可以实现：

S1、终端向应用服务器和应用平台发起内购请求并生成相应订单，其中，利用内置的内购框架向所述应用平台发起所述内购请求；

S2、接收所述应用服务器返回的平台订单号，以及所述应用平台返回的交易订单号，将所述平台订单号和所述交易订单号进行关联，并调用所述内购框架，在所述应用平台端完成所述内购请求的支付操作；

S3、确定接收到所述应用平台返回的支付收据，基于所述平台订单号、所述交易订单号和所述收据生成订单信息，保存所述订单信息，并将所述订单的订单状态设置为待同步状态；

S4、当检测到对应于所述内购请求的应用程序启动时，将处于待同步状态的订单的订单信息同步至应用服务器，以令所述应用服务器基于所述订单信息发放与所述订单对应的虚拟商品。

具体的运行流程如图2所示的订单处理方法流程类型，具体可参见图2的订单处理方法的描述，此处不再赘述。

进一步地，所述电子设备1集成的模块如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)。

在本发明所提供的几个实施例中，应该理解到，所揭露的设备、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能模块的形式实现。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。

因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本发明内。不应将权利要求中的任何附关联图标记视为限制所涉及的权利要求。

最后应说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或等同替换，而不脱离本发明技术方案的精神和范围。

Claims (10)

1.一种订单处理方法，其特征在于，包括：

终端向应用服务器和应用平台发起内购请求并生成相应订单，其中，利用内置的内购框架向所述应用平台发起所述内购请求；

接收所述应用服务器返回的平台订单号，以及所述应用平台返回的交易订单号，将所述平台订单号和所述交易订单号进行关联，并调用所述内购框架，在所述应用平台端完成所述内购请求的支付操作；

确定接收到所述应用平台返回的支付收据，基于所述平台订单号、所述交易订单号和所述收据生成订单信息，保存所述订单信息，并将所述订单的订单状态设置为待同步状态；

当检测到对应于所述内购请求的应用程序启动时，将处于待同步状态的订单的订单信息同步至应用服务器，以令所述应用服务器基于所述订单信息发放与所述订单对应的虚拟商品。

2.根据权利要求1所述的一种订单处理方法，其特征在于，在所述将处于待同步状态的订单的订单信息同步至应用服务器之后，还包括：

删除存储的所述订单信息。

3.根据权利要求1所述的一种订单处理方法，其特征在于，

所述平台订单号是与应用程序的用户账号关联的字符串。

4.根据权利要求1所述的一种订单处理方法，其特征在于，

所述交易订单号是唯一地标识一次成功交易的字符串。

5.根据权利要求1所述的一种订单处理方法，其特征在于，终端向应用服务器和应用平台发起内购请求之前，还包括：

创建并初始化请求对象，并为其附加委托方法；

从应用服务器下载包含商品标识符的商品列表，根据所需的商品标识符，使用所述请求对象向应用平台发送得到对应商品信息的请求，其中，所述委托方法为所述请求对象添加实现应用平台处理请求结果的事件处理程序。

6.根据权利要求1所述的订单处理方法，其特征在于，

所述调用所述内购框架，在所述应用平台端完成所述内购请求的支付操作，包括：

创建包含商品标识符和内购数量的商品支付对象，并将所述商品支付对象放入支付队列；

创建包含当前交易状态信息的商品支付交易对象以供所述应用平台监听所述支付操作，以使得所述应用平台在监听到所述支付操作完成后生成所述内购订单的收据。

7.一种订单处理装置，其特征在于，所述装置包括：

内购请求模块，用于向应用服务器和应用平台发起内购请求并生成相应订单，其中，利用内置的内购框架向所述应用平台发起所述内购请求；

订单关联模块，用于接收所述应用服务器返回的平台订单号，以及所述应用平台返回的交易订单号，将所述平台订单号和所述交易订单号进行关联，并调用所述内购框架，在所述应用平台端完成所述内购请求的支付操作；

订单信息生成模块，用于确定接收到所述应用平台返回的支付收据，基于所述平台订单号、所述交易订单号和所述收据生成订单信息，保存所述订单信息，并将所述订单的订单状态设置为待同步状态；

订单信息同步模块，用于当检测到对应于所述内购请求的应用程序启动时，将处于待同步状态的订单的订单信息同步至应用服务器，以令所述应用服务器基于所述订单信息发放与所述订单对应的虚拟商品。

8.根据权利要求7所述的订单处理装置，其特征在于，所述订单处理装置还包括：

支付模块，用于创建包含商品标识符和内购数量的商品支付对象，并将所述商品支付对象放入支付队列；并创建包含当前交易状态信息的商品支付交易对象以供所述应用平台监听所述支付操作，以使得所述应用平台在监听到所述支付操作完成后生成所述内购订单的收据。

9.一种电子设备，其特征在于，所述电子设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至6中任一所述的订单处理方法。

10.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至6中任一所述的订单处理方法。

Images