CN109447758B - 应用内购买的方法和相关装置 - Google Patents

Abstract

本发明实施例提供应用内购买的方法和相关装置，以实现简化程序流程的目的。在本发明实施例中，通用的内购模块为主程序模块提供的是统一的处理接口，不再区分购买接口和验证接口。主程序模块只需要通过处理接口输入商品标识和回调函数等，内购模块即可进行相应的交易处理，最终调用回调函数向主程序模块返回交易处理结果，在此过程中，主程序模块不再需要判断交易状态，从而简化了主程序模块的执行流程。同时，上述通用的内购模块是已经设计好的，不需要程序员进行开发。程序员只需要关注主程序模块的设计，并且在设计主程序模块时，不需要考虑虚拟商品的交易状态，从而简化了设计难度，避免出现因考虑交易状态不周而带来的错误。

Description

应用内购买的方法和相关装置

技术领域

本发明涉及计算机领域，特别涉及应用内购买的方法和相关装置。

背景技术

很多应用程序都支持应用内购买商品。内购商品的购买界面出现在应用程序内，用户点击后应用程序会通过应用商店提供的接口向应用商店请求购买，在收到来自应用商店已购买虚拟商品的消息(包含收据)后，应用程序还需要对收据(receipt)发起验证，当验证完成后才能决定是否应该对用户提供相应的功能。

然而，验证过程是异步的网络操作，若出现网络请求失败、验证过程中应用程序异常退出等情况，应用程序需要在后续的使用中再次进行验证。在后续的验证过程中，应用程序需要对原交易的状态进行判断从而选择“购买”或“验证”接口，以发起不同的请求。这就要求程序员在设计应用程序时，需要涉及虚拟商品当前的交易状态的判断，从而容易出现错误。

发明内容

有鉴于此，本发明实施例提供应用内购买的方法和相关装置，以实现简化程序流程的目的。

为实现上述目的，本发明实施例提供如下技术方案：

一种应用内购买的方法，所述应用的客户端包括主程序模块和通用的内购模块，所述方法包括：

所述内购模块通过统一的处理接口接收来自所述主程序模块的交易处理请求；所述交易处理请求至少包括商品标识和回调函数；所述交易处理请求中的商品标识为目标商品标识；

所述内购模块在本地查找所述目标商品标识对应的交易记录；任一交易记录包括商品标识及其对应的自定义交易状态；

若在本地查找到交易记录，所述内购模块根据查找到的交易记录进行交易处理，得到交易处理结果；

若在本地未查找到交易记录，所述内购模块与应用商店接口通信，查询所述应用商店接口中所述目标商品标识对应的交易及交易状态；

若从所述应用商店接口查询到所述目标商品标识的交易状态，所述内购模块将查询到的交易状态转化为自定义交易状态，根据转化后得到的自定义交易状态进行交易处理，得到交易处理结果；

所述内购模块调用所述回调函数，并向所述回调函数输入所述交易处理结果，以向所述主程序模块返回所述交易处理结果。

可选的，所述自定义交易状态具体为：未购买、购买中、已购待验证、验证中或已验证；所述交易处理请求还包括所述目标商品标识对应的商品类型，所述商品类型为消耗型、非消耗型或订阅型；任一交易记录还包括商品标识对应的商品类型；所述根据查找到的交易记录进行交易处理包括：若在本地数据表中查询到所述目标商品标识的自定义交易状态为“已验证”且商品可用，生成表征交易成功的交易处理结果，进入调用所述回调函数的步骤；若在本地数据表中查询到所述目标商品标识的自定义交易状态为“已购待验证”，向内部服务器发送验证请求；所述验证请求携带有所述目标商品标识的收据；所述内部服务器用于将所述验证请求转发至应用商店；将所述目标商品标识在内存中的自定义交易状态标记为“验证中”；接收验证结果，所述验证结果表征验证成功或失败；根据所述验证结果和所述目标商品标识的商品类型进行交易结束处理，得到交易处理结果。

可选的，所述根据查找到的交易记录进行交易处理还包括：若满足购买条件，则发起购买；将所述目标商品标识在内存中的自定义交易状态标记为“购买中”；监听购买结束事件，获取购买结果；若所述购买结果表征购买成功，在所述本地数据表中将所述目标商品标识对应的交易记录中的自定义交易状态标记为“已购买待验证”，进入所述向内部服务器发送验证请求的步骤；若所述购买结果表征购买失败、延迟交易或取消，生成表征交易失败的交易处理结果，进入调用所述回调函数的步骤；所述购买条件包括：所述内存中所述目标商品标识对应的自定义交易状态为“未购买”，或者，在所述本地数据表中所述目标商品标识对应的自定义交易状态为“已验证”，但所述目标商品标识对应的商品类型为订阅型且根据本地数据表中记录的过期时间判定该商品已失效。

可选的，所述根据查找到的交易记录进行相应的交易处理还包括：若所述目标商品标识在本地数据表中对应的自定义交易状态为“验证中”或者所述目标商品标识在内存中对应的自定义交易状态为“购买中”，通知所述主程序模块进行了重复操作。

可选的，所述将查询到的交易状态转化为自定义交易状态，根据转化后得到的自定义交易状态进行交易处理包括：若所述查询到的交易状态为“失败”或“已恢复”，关闭所述应用商店接口所存储的交易，在所述内存中标记所述目标商品标识的自定义交易状态为“未购买”，进入所述发起购买的步骤；若所述查询到的交易状态为“延迟”，在内存中建立所述目标商品标识对应的交易记录，在所述交易记录中标记所述目标商品标识的自定义交易状态为“购买中”，进入所述监听购买结果的步骤；若所述查询到的交易状态为“已购买”，在内存中建立所述目标商品标识对应的交易记录，在所述交易记录中标记所述目标商品标识的自定义交易状态为“已购买待验证”，进入所述向内部服务器发送验证请求的步骤；若所述查询到的交易状态为其他状态，在内存中建立所述目标商品标识对应的交易记录，在所述交易记录中标记所述目标商品标识的自定义交易状态为“未购买”，进入所述发起购买的步骤。

可选的，还包括：若未从所述应用商店接口查询到所述目标商品标识对应的交易，在内存中建立所述目标商品标识对应的交易记录，在所述交易记录中标记所述目标商品标识的自定义交易状态为“未购买”，进入所述发起购买的步骤。

可选的，若所述验证结果表征验证成功，所述根据验证结果和所述目标商品标识的商品类型进行交易结束处理包括：若所述目标商品标识的商品类型为消耗型，删除所述目标商品标识在所述本地数据表和内存中的交易记录，并关闭所述应用商店的交易；若所述目标商品标识的商品类型为非消耗型，将所述目标商品标识在所述本地数据表中的自定义交易状态标记为“已验证”；以及，若所述应用商店为苹果商店则关闭交易，若所述应用商店为谷歌商店则不关闭交易；若所述目标商品标识的商品类型为订阅型，将所述目标商品标识在所述本地数据表中的自定义交易状态标记为“已验证”，并记录过期时间；以及，若所述应用商店为苹果商店则关闭交易，若所述应用商店为谷歌商店则不关闭交易。

可选的，所述内部服务器还用于保存所述验证请求中的收据，以及所述本地数据表中的交易记录。

一种客户端，包括主程序模块和通用的内购模块；

所述主程序模块用于向所述内购模块发送交易处理请求；所述交易处理请求至少包括商品标识和回调函数；所述交易处理请求中的商品标识为目标商品标识；

所述内购模块用于：

通过统一的处理接口接收来自所述主程序模块的交易处理请求；

在本地查找所述目标商品标识对应的交易记录；任一交易记录包括商品标识及其对应的自定义交易状态；

若在本地查找到交易记录，根据查找到的交易记录进行交易处理，得到交易处理结果；

若在本地未查找到交易记录，与应用商店接口通信，查询所述应用商店接口中所述目标商品标识对应的交易及交易状态；

若从所述应用商店接口查询到所述目标商品标识的交易状态，将查询到的交易状态转化为自定义交易状态，根据转化后得到的自定义交易状态进行交易处理，得到交易处理结果；

调用所述回调函数，并向所述回调函数输入所述交易处理结果，以向所述主程序模块返回所述交易处理结果。

一种内购模块，包括：

处理接口，用于接收来自所述主程序模块的交易处理请求；所述交易处理请求至少包括商品标识和回调函数；所述交易处理请求中的商品标识为目标商品标识；

处理单元，用于：

通过统一的处理接口接收来自所述主程序模块的交易处理请求；

在本地查找所述目标商品标识对应的交易记录；任一交易记录包括商品标识及其对应的自定义交易状态；

若在本地查找到交易记录，根据查找到的交易记录进行交易处理，得到交易处理结果；

若在本地未查找到交易记录，与应用商店接口通信，查询所述应用商店接口中所述目标商品标识对应的交易及交易状态；

若从所述应用商店接口查询到所述目标商品标识的交易状态，将查询到的交易状态转化为自定义交易状态，根据转化后得到的自定义交易状态进行交易处理，得到交易处理结果；

调用所述回调函数，并向所述回调函数输入所述交易处理结果，以向所述主程序模块返回所述交易处理结果。

在本发明实施例中，通用的内购模块为主程序模块提供的是统一的处理接口，不再区分购买接口和验证接口。主程序模块只需要通过处理接口输入商品标识和回调函数等，内购模块即可进行相应的交易处理，最终调用回调函数向主程序模块返回交易处理结果，在此过程中，主程序模块不再需要判断交易状态，从而简化了主程序模块的执行流程。

上述通用的内购模块是已经设计好的，不需要程序员进行开发。程序员只需要关注主程序模块的设计，并且在设计主程序模块时，不需要考虑虚拟商品的交易状态，从而简化了设计难度，避免出现因考虑交易状态不周而带来的错误。

附图说明

图1为本发明实施例提供的应用内购买的方法示例性流程图；

图2为本发明实施例提供的应用内购买的方法另一示例性流程图；

图3为本发明实施例提供的应用内购买的方法又一示例性流程图；

图4为本发明实施例提供的客户端的示例性结构图；

图5为本发明实施例提供的内购模块的示例性结构图。

具体实施方式

本发明提供应用内购买的方法和相关装置(客户端、内购模块、内部服务器)，以实现简化程序行流程的目的。

上述应用可为任意需要有内购功能的应用，例如游戏应用、图书阅读应用、购物应用等。

应用的客户端包括主程序模块和内购模块。主程序模块的逻辑与内购模块的逻辑是相对独立的。用户下载的客户端程序包含主程序模块的逻辑和内购模块的逻辑。

从代码角度来看，用户下载的客户端程序代码包含主程序模块的代码和内购模块的代码。

需要说明的是，内购模块是通用的，不需要程序员进行开发。程序员只需要关注主程序模块的设计。

在一个示例中，内购模块针对不同的系统有不同的版本，其中，安卓版本对接谷歌商店，iOS版本对接苹果商店。为安卓系统开发的内购模块，可为不同安卓应用(例如游戏应用、图书阅读应用、购物应用)的主程序模块提供购买和验证服务。同理，为苹果系统开发的内购模块，可为不同的苹果应用(例如游戏应用、图书阅读应用、购物应用)的主程序模块提供购买和验证服务。

请参见图1，上述应用内购买的方法示例性的可包括如下步骤：

S1：内购模块通过统一的处理接口接收来自主程序模块的交易处理请求。

其中，上述交易处理请求至少可包括商品标识和回调函数。可将交易处理请求中的商品标识称为目标商品标识。

在本发明中，内购模块向主程序模块提供统一的处理接口，主程序模块可通过处理接口输入商品标识和回调函数等，内购模块会暂时保存回调函数，在必要的时机对其调用。而主程序模块发起交易(发送交易处理请求)之后，就不再直接控制交易，通过上述回调函数接收内购模块反馈的交易处理结果。

当然，从底层而言，是主程序模块的代码调用了内购模块的代码。

以游戏应用为例，主程序模块在如下场景下会调用内购模块：

购买场景：假定用户意欲购买游戏中的金币或道具，点击了购买控件，则用户接口调用主程序模块有关购买的那部分代码，该部分代码将调用内购模块的代码。

其他场景：客户端启动，根据内购模块记录的自定义交易状态发现有未验证完成的商品(这种情况可能是验证时死机或验证时断网造成的)，客户端可向用户提示是否继续验证，如果用户确认继续验证，则客户端会调用内购模块的代码。

S2：内购模块在本地查找目标商品标识对应的交易记录。

任一交易记录至少包括商品标识及其对应的自定义交易状态。具体的，自定义交易状态可包括：未购买、购买中、已购待验证、验证中或已验证。

S3：若在本地查找到交易记录，上述内购模块根据查找到的交易记录进行交易处理，得到交易处理结果，进入S7。

本文后续将基于各自定义交易状态对内购模块如何进行交易处理进行详细介绍。

S4：若在本地未查找到交易记录，内购模块与应用商店接口通信，查询应用商店接口中目标商品标识对应的交易及交易状态。

应用商店接口存在目标商品标识对应的交易的情况一般发生在：主程序模块通过其他内购模块进行购买或验证，但又未购买或验证成功。

S5：若从上述应用商店接口查询到上述目标商品标识的交易状态，内购模块将查询到的交易状态转化为自定义交易状态。

应用商店接口所存储的交易状态可为：“失败”、“已恢复”、“延迟”或“已购买”等。

本文后续将详细介绍如何进行转化。

S6：内购模块根据转化后得到的自定义交易状态进行交易处理，得到交易处理结果。

S6与S3是相类似的，都是基于自定义交易状态进行交易处理，得到交易处理结果。

S7：内购模块调用回调函数，并向回调函数输入交易处理结果。

这样，主程序模块将得到交易处理结果。

可见，在本发明实施例中，通用的内购模块为主程序模块提供的是统一的处理接口，不再区分购买接口和验证接口。主程序模块只需要通过处理接口输入商品标识和回调函数等，内购模块即可进行相应的交易处理，最终调用回调函数向主程序模块返回交易处理结果，在此过程中，主程序模块不再需要判断交易状态，从而简化了主程序模块的执行流程。

同时，上述通用的内购模块是已经设计好的，不需要程序员进行开发。程序员只需要关注主程序模块的设计，并且在设计主程序模块时，不需要考虑虚拟商品的交易状态，从而简化了设计难度，避免出现因考虑交易状态不周而带来的错误。

下面，将对步骤S3中，如何根据查找到的交易记录进行交易处理，得到交易处理结果进行详细介绍。请参见图2，其可包括如下步骤：

S21：内购模块通过统一的处理接口接收来自主程序模块的交易处理请求。

其中，上述交易处理请求可包括目标商品标识、商品类型和回调函数。

进一步的，商品类型可为消耗型(Consumable)、非消耗型(Non-Consumable)或订阅型(Subscriptions)。

其中，消耗型商品可多次购买；非消耗型商品仅需购买一次；订阅型商品在有效订阅期内无需多次购买，失效后可再次购买。

S21与前述S1相类似，在此不作赘述。

S22：内购模块在本地查找目标商品标识对应的交易记录。

在本实施例中，任一交易记录可包括商品标识、商品类型及自定义交易状态。

在一个示例中，交易记录可存储在本地数据表和内存中。因此，“在本地查找”可进一步包括“在本地数据表中查找”和“在内存中查找”。

自定义交易状态可包括：未购买、购买中、已购待验证、验证中或已验证。其中，本地数据表中可用于存储“已购待验证”和“已验证”，其他自定义交易状态均为运行时的状态，无需持久化，因此可存储在内存中。

S23：若在本地查找到交易记录，内购模块根据查找到的交易记录进行交易处理，得到交易处理结果，进入S218。

前述提及了交易记录中的自定义交易状态有多种，则根据不同的自定义交易状态可有如下的交易处理：

1，若在本地数据表中查询到目标商品标识的自定义交易状态为“已验证”且商品可用，生成表征交易成功的交易处理结果，进入S218。

前已述及，商品的商品类型分为消耗型、非消耗型或订阅型。其中，消耗型的在验证完成后将删除交易记录，所以不会查询到自定义交易状态；非消耗型若自定义交易状态为“已验证”，则表明其可用；至于订阅型商品，其会有过期时间，若当前时刻晚于过期时间，则可判定商品失效(即不可用)，而若当前时刻早于过期时间，则可判定商品可用。

2，若在本地数据表中查询到目标商品标识的自定义交易状态为“已购待验证”，则向内部服务器发送验证请求(即进入S213)。

3，若满足购买条件，则发起购买(即进入S28)。

其中，购买条件可包括：

内存中目标商品标识对应的自定义交易状态为“未购买”；或者，在本地数据表中该目标商品标识对应的自定义交易状态为“已验证”，但该目标商品标识对应的商品不可用。

这里的“不可用”主要是针对订阅型商品，若根据本地数据表中记录的过期时间判定该商品已失效(当前时刻晚于过期时间)，则判定该商品不可用。

4，若目标商品标识在内存中对应的自定义交易状态为“验证中”可通知主程序模块进行了重复操作(S210)，终止客户端此次的交易处理请求。由于前次的交易处理请求仍在，且为“验证中”状态，所以并不会结束验证/交易，主程序模块仍会等待接收前次交易处理请求所对应的验证结果，并在接收到验证结果后，执行下一步操作。

5，若目标商品标识在内存中对应的自定义交易状态为“购买中”，可通知主程序模块进行了重复操作(S210)，终止客户端此次的交易处理请求。由于前次的交易处理请求仍在，且为“购买中”状态，所以并不会结束交易，主程序模块仍会监听前次交易处理请求所对应的购买结束事件的到来，并在接收到购买结束事件后，执行下一步操作。

S24：若在本地未查找到交易记录，内购模块与应用商店接口通信，查询应用商店接口中目标商品标识对应的交易及交易状态。若查找到，进入S25，否则进入S27。

S24与前述的S4相类似，在此不作赘述。

S25：内购模块根据应用商店接口中存储的交易状态进行相应处理，得到处理结果，至S218。

S25的具体实现可参见前述S5和S6，在此不作赘述。

S27：在内存中建立目标商品标识对应的交易记录，进入S28。

其中，交易记录中目标商品标识的自定义交易状态为“未购买”。

由于是在本地和应用商店接口都未查询到交易记录，则可认为商品未进行购买，将其标记为“未购买”进入购买流程。购买流程包括后续的S28、S29、S211。

S28：内购模块发起购买。

具体的，内购模块可调用购买接口。购买接口是应用商店提供的，属于内购模块的内部接口，对于主程序模块是不可见的。

S29：内购模块在内存中将目标商品标识对应的自定义交易状态标记为“购买中”。

标记为“购买中”，是为了防止发起重复购买。

S211：内购模块监听购买结束事件，获取购买结果。若购买结果表征购买成功，进入S212，否则，进入S217。

来自应用商店的购买结束的事件都有明确的状态表示交易成功或失败、取消。

应用商店会返回购买结束事件，该事件中会有明确的状态，表示交易成功、失败或取消等。

购买结束事件中的状态即为购买结果。具体的，购买结果可表征购买成功、失败、取消或延迟交易。

需要说明的是，“延迟”是苹果iOS专有的状态，主要用于家长控制——购买需要监护人在24小时内确认。

当然，若购买成功，购买结束事件中还会包含收据。在本发明实施例中，仅在购买成功后，会进入后续的验证流程，其他结果将通过回调函数返回表征交易失败的交易处理结果。

S212：在本地数据表中将目标商品标识对应的定义交易状态标记为“已购买待验证”。

当然，若之前在本地数据表中未有相应交易记录，则在本地数据表中建立目标商品标识对应的交易记录。

S213：内购模块向内部服务器发送验证请求。

验证请求携带有目标商品标识的收据。内部服务器则可将验证请求转发至应用商店进行验证。

具体的，内购模块是通过验证接口发送验证请求的。验证接口是内购模块与内部服务器之间的接口，属于内购模块的内部接口，对于主程序模块是不可见的。

上述内部服务器可为某一应用的服务器，例如，内部服务器可为某游戏应用的服务器。或者，内部服务器也可为多个应用提供验证服务。

S214:将目标商品标识在内存中的自定义交易状态标记为“验证中”。

当然，若之前在内存中未有相应的交易记录，则还要内存中建立目标商品标识对应的交易记录。

S215：内购模块接收验证结果。

具体的，内购模块是通过验证接口接收验证结果的。

在一个示例中，应用商店可返回验证结果至内部服务器，内部服务器再向内购模块返回验证结果。

上述验证结果表征验证成功或失败。

S213-S215为验证流程。

S216：内购模块根据验证结果和目标商品标识的商品类型进行交易结束处理，得到交易处理结果，至S218。

具体的，若验证结果表征验证成功，可针对不同的商品类型进行如下操作：

1，若目标商品标识的商品类型为消耗型，删除目标商品标识在本地数据表和内存中的交易记录，并关闭应用商店的交易；

2，若目标商品标识的商品类型为非消耗型，将目标商品标识在本地数据表中的自定义交易状态标记为“已验证”，删除内存中该目标商品标识的交易记录；以及，若应用商店为苹果商店则关闭交易，若应用商店为谷歌商店则不关闭交易；

这里解释下在谷歌商店为什么不关闭交易：谷歌商店对非消耗型商品交易的处理是模拟消耗型商品的处理，但与之不同的是，并不关闭交易，这样，若再次购买会提醒已购买。

3，若目标商品标识的商品类型为订阅型，将目标商品标识在本地数据表中的自定义交易状态标记为“已验证”，并记录过期时间(注：过期时间不会记录到内存中，所以在这里可不必删除内存中该目标商品标识的交易记录)；以及，若应用商店为苹果商店则关闭交易，若应用商店为谷歌商店则不关闭交易。

此外，若验证失败，可根据失败原因进行相应处理：

例如，若失败原因是收据有误，内购模块会删除目标商品标识在本地数据表和内存中的交易记录，并关闭应用商店的交易；

若失败原因是网络连接失败、客户端异常退出或内部服务器故障等其他原因，会保留本地数据表中的交易记录(此时自定义交易状态为“已购待验证”)，留待后续重试验证。

S217：生成表征交易失败的交易处理结果，至S218。

在一个示例中，若购买失败，内购模块会删除目标商品标识在内存中的交易记录，并关闭应用商店的交易。

在另一个示例中，也可根据购买失败原因进行如下处理：

若购买失败原因是网络连接失败、客户端异常退出等原因，会尝试再次发起购买。

若购买失败原因是余额不足或售磬等原因，内购模块会删除目标商品标识在内存中的交易记录，并关闭应用商店的交易。

S218：内购模块调用上述回调函数，并向上述回调函数输入交易处理结果，以向主程序模块返回交易处理结果。

下面，将对前述步骤S5和S6(也即S25)进行详细介绍。请参见图3，应用内购买的方法示例性地可包括如下步骤：

S31-S34与前述的S21-S24相类似，在此不作赘述。

S35：内购模块将查询到的交易状态转化为自定义交易状态，根据转化后得到的自定义交易状态进行交易处理，得到处理结果，至S218。

具体的，可针对不同的交易状态进行如下操作：

1，若查询到的交易状态为“失败”或“已恢复”，至S36(关闭应用商店接口所存储的交易)。此过程完成了将应用商店接口中的交易状态—“失败”或“已恢复”转化为自定义交易状态—“未购买”。

“已恢复”是在iOS上执行恢复已购项目的操作时可能出现的交易状态。

需要说明的是，该部分是针对iOS专有逻辑设计的，iOS的逻辑规定“失败”或“已恢复”应在购买或恢复操作结束时关闭交易，所以，在查询到交易状态为“失败”或“已恢复”时，会关闭应用商店接口所存储的交易。

2，若查询到的交易状态为“延迟”，在内存中建立目标商品标识对应的交易记录，至S39。此过程完成了将应用商店接口中的交易状态—“延迟”转化为自定义交易状态—“购买中”。

前述提及了，延迟是苹果iOS专有的状态，主要用于家长控制——购买需要监护人在24小时内确认。则在等待确认的过程中，将其设置为“购买中”，是比较合适的。

3，若查询到的交易状态为“已购买”，在内存中建立目标商品标识对应的交易记录，至S312。此种操作完成了将应用商店接口中的交易状态—“已购买”转化为自定义交易状态—“已购待验证”。

4，若查询到的交易状态为其他状态，在内存中建立目标商品标识对应的交易记录，至S37。此种操作完成了将应用商店接口中的其他交易状态转化为自定义交易状态—“未购买”。

S36：关闭应用商店接口所存储的交易，至S37。

S37：在内存中建立目标商品标识对应的交易记录，并在交易记录中标记目标商品标识的自定义交易状态为“未购买”，进入S38。

需要说明的是，实际中可能存在下述情况：非消耗型商品或订阅型商品会在恢复操作后成为“已恢复”，但此时并不能确定商品已验证完毕。同时，应用商店不会对已购买过的非消耗型商品或订阅型商品重复收费，因此，在应用商品接口查询到的交易状态为“失败”或“已恢复”后，可在关闭交易后，将该商品标记为未购买，走一遍购买流程和验证流程。

S38-S318与前述的S28-S218相类似，在此不作赘述。

根据前述的记载可知，在验证过程中需要使用到收据。正常情况下会先验证再关闭交易。但在异常状态下，也可能出现在验证之前关闭交易的情况，例如应用程序错误地判断了交易的状态而触发了关闭交易的操作。

而如果先关闭交易再进行验证，就无法保证在验证时一定能获取到该交易的收据，特别是在应用程序卸载再重装的情况。

而在本发明中，在内购模块由于集成了验证相关的操作，因此不会发生验证之前关闭交易的情况，所以也就不会出现在验证之前关闭交易的情况。

此外，在本发明其他实施例中，内部服务器在参与验证的过程中，也可保存交易的收据和本地数据表中的交易记录。这样，即使客户端程序在验证完成之前被删除，其相关数据仍会保留在内部服务器中，重新安装后仍然可以获取收据并完成验证。

在本发明其他实施例中，上述内购模块还可具有如下功能：

(1)未验证交易的自动验证及通知。可对该功能配置启用或禁用。

在启用后，主程序模块会在启动时或由后台转为前台时，查询内购模块中本地数据表里的交易记录，若发现存在“已购待验证”的交易，主程序模块将向内购模块发送交易处理请求，由内购模块完成验证。

(2)自动处理自动续费的交易并通知。可对该功能配置启用或禁用。该部分功能是针对订阅型商品的。

一般的，应用商店会在过期时间到达的前一天进行扣费，并向客户端返回续费事件，续费事件里包含商品标识和新收据。

内购模块监听到续费事件后，会发起针对新收据的验证。在此场景下，并不需要主程序模块发送交易处理请求。

综上，本发明中，主程序模块通过统一的接口发起交易处理请求，通用的内购模块会判断交易状态并根据不同的交易状态来进行下一步动作，直至交易完成向应用程序通知交易处理结果。在此期间，所有的服务器通讯也由内购模块接管，主程序模块无需关心通讯细节。通过这种方式，内购模块会帮助主程序模块进行交易状态的判断，从而解决程序员经验不足容易判断错误的痛点。

并且，在内购模块由于集成了验证相关的操作，因此不会发生验证之前关闭交易的情况，所以也就不会出现在验证之前关闭交易的情况。此外，内部服务器也可保存交易的收据和本地数据表中的交易记录。这样，即使客户端程序在验证完成之前被删除，其相关数据仍会保留在内部服务器中，重新安装后仍然可以获取收据并完成验证。

下面介绍客户端和内购模块。

请参见图4，客户端可包括主程序模块41和通用的内购模块42。

主程序模块41和内购模块42的具体作用可参见前述方法的介绍，在此不作赘述。

图5示出了内购模块42的一种示例性结构，其可包括：处理接口51和处理单元52。其中：

处理接口51用于：接收来自上述主程序模块的交易处理请求。

上述交易处理请求至少包括目标商品标识和回调函数，在一些实施例中，交易处理请求还可包括商品类型。

相关介绍请参见前述方法实施例的记载，在此不作赘述。

处理单元52，用于：

通过统一的处理接口接收来自主程序模块41的交易处理请求；

在本地查找上述目标商品标识对应的交易记录；任一交易记录包括商品标识及其对应的自定义交易状态；

若在本地查找到交易记录，根据查找到的交易记录进行交易处理，得到交易处理结果；

若在本地未查找到交易记录，与应用商店接口通信，查询上述应用商店接口中上述目标商品标识对应的交易及交易状态；

若从上述应用商店接口查询到上述目标商品标识的交易状态，将查询到的交易状态转化为自定义交易状态，根据转化后得到的自定义交易状态进行交易处理，得到交易处理结果；

调用上述回调函数，并向上述回调函数输入上述交易处理结果，以向主程序模块41返回上述交易处理结果。

相关介绍请参见前述方法实施例的记载，在此不作赘述。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及模型步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或模型的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、WD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种应用内购买的方法，其特征在于，所述应用的客户端包括主程序模块和通用的内购模块，所述通用的内购模块为所述主程序模块提供统一的处理接口，所述通用的内购模块为不同的应用的主程序模块提供购买和验证服务，所述方法包括：

所述内购模块通过统一的处理接口接收来自所述主程序模块的交易处理请求；所述交易处理请求至少包括商品标识和回调函数；所述交易处理请求中的商品标识为目标商品标识；

所述内购模块在本地查找所述目标商品标识对应的交易记录；任一交易记录包括商品标识及其对应的自定义交易状态；

若在本地查找到交易记录，所述内购模块根据查找到的交易记录进行交易处理，得到交易处理结果；

若在本地未查找到交易记录，所述内购模块与应用商店接口通信，查询所述应用商店接口中所述目标商品标识对应的交易及交易状态；

若从所述应用商店接口查询到所述目标商品标识的交易状态，所述内购模块将查询到的交易状态转化为自定义交易状态，根据转化后得到的自定义交易状态进行交易处理，得到交易处理结果；

所述内购模块调用所述回调函数，并向所述回调函数输入所述交易处理结果，以向所述主程序模块返回所述交易处理结果。

2.如权利要求1所述的方法，其特征在于，

所述自定义交易状态具体为：未购买、购买中、已购待验证、验证中或已验证；

所述交易处理请求还包括所述目标商品标识对应的商品类型，所述商品类型为消耗型、非消耗型或订阅型；任一交易记录还包括商品标识对应的商品类型；

所述根据查找到的交易记录进行交易处理包括：

若在本地数据表中查询到所述目标商品标识的自定义交易状态为“已验证”且商品可用，生成表征交易成功的交易处理结果，进入调用所述回调函数的步骤；

若在本地数据表中查询到所述目标商品标识的自定义交易状态为“已购待验证”，向内部服务器发送验证请求；所述验证请求携带有所述目标商品标识的收据；所述内部服务器用于将所述验证请求转发至应用商店；

将所述目标商品标识在内存中的自定义交易状态标记为“验证中”；

接收验证结果，所述验证结果表征验证成功或失败；

根据所述验证结果和所述目标商品标识的商品类型进行交易结束处理，得到交易处理结果。

3.如权利要求2所述的方法，其特征在于，所述根据查找到的交易记录进行交易处理还包括：

若满足购买条件，则发起购买；

将所述目标商品标识在内存中的自定义交易状态标记为“购买中”；

监听购买结束事件，获取购买结果；

若所述购买结果表征购买成功，在所述本地数据表中将所述目标商品标识对应的交易记录中的自定义交易状态标记为“已购买待验证”，进入所述向内部服务器发送验证请求的步骤；

若所述购买结果表征购买失败、延迟交易或取消，生成表征交易失败的交易处理结果，进入调用所述回调函数的步骤；

所述购买条件包括：

所述内存中所述目标商品标识对应的自定义交易状态为“未购买”，或者，

在所述本地数据表中所述目标商品标识对应的自定义交易状态为“已验证”，但所述目标商品标识对应的商品类型为订阅型且根据本地数据表中记录的过期时间判定该商品已失效。

4.如权利要求3所述的方法，其特征在于，所述根据查找到的交易记录进行相应的交易处理还包括：

若所述目标商品标识在本地数据表中对应的自定义交易状态为“验证中”或者所述目标商品标识在内存中对应的自定义交易状态为“购买中”，通知所述主程序模块进行了重复操作。

5.如权利要求4所述的方法，其特征在于，所述将查询到的交易状态转化为自定义交易状态，根据转化后得到的自定义交易状态进行交易处理包括：

若所述查询到的交易状态为“失败”或“已恢复”，关闭所述应用商店接口所存储的交易，在所述内存中标记所述目标商品标识的自定义交易状态为“未购买”，进入所述发起购买的步骤；

若所述查询到的交易状态为“延迟”，在内存中建立所述目标商品标识对应的交易记录，在所述交易记录中标记所述目标商品标识的自定义交易状态为“购买中”，进入所述监听购买结果的步骤；

若所述查询到的交易状态为“已购买”，在内存中建立所述目标商品标识对应的交易记录，在所述交易记录中标记所述目标商品标识的自定义交易状态为“已购买待验证”，进入所述向内部服务器发送验证请求的步骤；

若所述查询到的交易状态为其他状态，在内存中建立所述目标商品标识对应的交易记录，在所述交易记录中标记所述目标商品标识的自定义交易状态为“未购买”，进入所述发起购买的步骤。

6.如权利要求5所述的方法，其特征在于，还包括：

若未从所述应用商店接口查询到所述目标商品标识对应的交易，在内存中建立所述目标商品标识对应的交易记录，在所述交易记录中标记所述目标商品标识的自定义交易状态为“未购买”，进入所述发起购买的步骤。

7.如权利要求5所述的方法，其特征在于，若所述验证结果表征验证成功，所述根据验证结果和所述目标商品标识的商品类型进行交易结束处理包括：

若所述目标商品标识的商品类型为消耗型，删除所述目标商品标识在所述本地数据表和内存中的交易记录，并关闭所述应用商店的交易；

若所述目标商品标识的商品类型为非消耗型，将所述目标商品标识在所述本地数据表中的自定义交易状态标记为“已验证”；以及，若所述应用商店为苹果商店则关闭交易，若所述应用商店为谷歌商店则不关闭交易；

若所述目标商品标识的商品类型为订阅型，将所述目标商品标识在所述本地数据表中的自定义交易状态标记为“已验证”，并记录过期时间；以及，若所述应用商店为苹果商店则关闭交易，若所述应用商店为谷歌商店则不关闭交易。

8.如权利要求2-7任一项所述的方法，其特征在于，所述内部服务器还用于保存所述验证请求中的收据，以及所述本地数据表中的交易记录。

9.一种客户端，其特征在于，包括主程序模块和通用的内购模块；所述通用的内购模块为所述主程序模块提供统一的处理接口，所述通用的内购模块为不同的应用的主程序模块提供购买和验证服务;

所述主程序模块用于向所述内购模块发送交易处理请求；所述交易处理请求至少包括商品标识和回调函数；所述交易处理请求中的商品标识为目标商品标识；

所述内购模块用于：

通过统一的处理接口接收来自所述主程序模块的交易处理请求；

在本地查找所述目标商品标识对应的交易记录；任一交易记录包括商品标识及其对应的自定义交易状态；

若在本地查找到交易记录，根据查找到的交易记录进行交易处理，得到交易处理结果；

若在本地未查找到交易记录，与应用商店接口通信，查询所述应用商店接口中所述目标商品标识对应的交易及交易状态；

若从所述应用商店接口查询到所述目标商品标识的交易状态，将查询到的交易状态转化为自定义交易状态，根据转化后得到的自定义交易状态进行交易处理，得到交易处理结果；

调用所述回调函数，并向所述回调函数输入所述交易处理结果，以向所述主程序模块返回所述交易处理结果。

10.一种应用内购买的装置，其特征在于，所述装置包括通用的内购模块，所述通用的内购模块为不同的应用的主程序模块提供购买和验证服务，包括：

处理接口，用于接收来自所述主程序模块的交易处理请求；所述交易处理请求至少包括商品标识和回调函数；所述交易处理请求中的商品标识为目标商品标识；

处理单元，用于：

通过统一的处理接口接收来自所述主程序模块的交易处理请求；

在本地查找所述目标商品标识对应的交易记录；任一交易记录包括商品标识及其对应的自定义交易状态；

若在本地查找到交易记录，根据查找到的交易记录进行交易处理，得到交易处理结果；

若在本地未查找到交易记录，与应用商店接口通信，查询所述应用商店接口中所述目标商品标识对应的交易及交易状态；

若从所述应用商店接口查询到所述目标商品标识的交易状态，将查询到的交易状态转化为自定义交易状态，根据转化后得到的自定义交易状态进行交易处理，得到交易处理结果；

调用所述回调函数，并向所述回调函数输入所述交易处理结果，以向所述主程序模块返回所述交易处理结果。

Images