CN111709730A - 虚拟商品的支付方法、装置、服务器及存储介质 - Google Patents

Abstract

本申请涉及一种虚拟商品的支付方法、装置、服务器及存储介质，方法包括：获取所述虚拟商品支付单据的参数，所述参数中包括支付参数、商品参数和用户账户参数；分析所述参数，判断是否满足拒绝支付条件；若满足所述拒绝支付条件，拒绝所述虚拟商品的支付；若不满足所述拒绝支付条件，允许所述虚拟商品的支付。本申请实施例用以解决虚拟商品的支付过程中风险无法有效识别的问题。

Description

虚拟商品的支付方法、装置、服务器及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种虚拟商品的支付方法、装置、服务器及存储介质。

背景技术

某终端提供商开发的iOS系统和硬件设备(如平板、手机)等组成了一个相对封闭的生态系统。在这个生态系统中，应用软件开发者的一种商业模式为消耗者可以免费下载应用软件客户端(APP)，但需要通过iOS应用内支付(简称为IAP)解锁APP内的收费内容。根据应用软件开发者(简称开发者)是否具有服务端，可以将IAP分为两种方案：

方案一

没有服务端的APP，只能通过APP发送HTTPS请求访问该终端提供商的服务器来验证IAP票据，验证通过后就认为用户已成功支付，并为该用户解锁对应内容。由于HTTPS请求容易被劫持，该方案破解难度低，容易被用户绕过，从而给开发者造成损失。

方案二

有服务端的APP，采用服务端验证IAP票据，典型的验证流程如下：用户点击APP内的商品，到开发者服务器请求创建订单；该开发者服务器检验创建订单的请求信息，校验通过后生成订单信息发给APP；APP连接该终端提供商的服务器，发起应用内支付流程；该终端提供商的服务器根据用户终端账号内设置的支付方式进行扣费，如果扣费成功，把IAP票据发送给APP；APP收到IAP票据后，把完整的票据发到开发者服务器进行验证；开发者服务器访问该终端提供商的服务器，验证IAP票据的真实性，验证通过后再解锁APP内的付费内容；由于网络波动等原因，用户在支付成功后，APP可能无法获取到IAP票据，用户可以在切换网络后点击APP内的恢复购买按钮，APP再次尝试获取IAP票据，并发给开发者服务器进行验证。

发明人在实现本发明的过程中发现，在发起IAP支付时，终端会按照用户提供的支付方式进行扣款，但是扣款到账需要一段相对较长的时间，因此在扣款到账前，该终端提供商的服务器会生成合法的IAP票据发送给APP。即使该终端提供商后来检测到用户的支付方式存在问题，并将这笔交易取消，也不会无效之前针对该笔交易生成的IAP票据，也就是之前生成的IAP票据还是有效的。因此即使IAP票据通过了该终端提供商的服务器的验证，开发者也无法确定该票据背后的交易是否有效。

更为重要的是，对于非订阅类的商品，该终端提供商的服务器不会把取消的交易通知给开发者，因此，对于非订阅类商品，开发者无法将合法的IAP订单和无效的订单区分开来，也就无法取消对应订单解锁的APP权益。

由于IAP缺陷的存在，不法分子通过非法渠道获取到低价的礼品卡或者盗刷信用卡，通过IAP大量购买APP内的虚拟商品，再通过越狱设备截获IAP票据，待APP的实际用户需要使用APP内付费内容时，再把之前囤积的IAP票据发给APP开发者，开发者验证IAP票据成功后，为用户解锁付费内容。通过以上的代充手段，用户可以用比官方售价更低的价格获取到APP权益，不法分子可以获得代充的收益，使APP开发者的利益受损。

除此之外，用户还可以利用该终端提供商的退款政策，联系该终端提供商的客服要求退款，只需理由被客服采纳，最长可以退三个月内的IAP订单，且每个用户终端账号的首次退款成功率较高。对于这些无效的订单，开发者往往无法可靠且实时进行检测，只能被动承受损失。

发明内容

本申请提供了一种虚拟商品的支付方法、装置、服务器及存储介质，用以解决虚拟商品的支付过程中风险无法有效识别的问题。

第一方面，本申请实施例提供了一种虚拟商品的支付方法，包括：

获取所述虚拟商品支付单据的参数，所述参数中包括支付参数、商品参数和用户账户参数；

分析所述参数，判断是否满足拒绝支付条件；

若满足所述拒绝支付条件，拒绝所述虚拟商品的支付；

若不满足所述拒绝支付条件，允许所述虚拟商品的支付。

可选地，所述支付单据包括：由具有支付功能的第一服务器产生的票据，所述票据由所述虚拟商品提供方的第二服务器进行验证。

可选地，所述支付单据还包括：由请求购买所述虚拟商品的用户账户在应用软件客户端发起的订单，所述订单由所述虚拟商品提供方的第二服务器生成并进行验证。

可选地，所述支付参数包括：支付使用的支付方式；

所述拒绝支付条件包括：支付使用的支付方式不属于允许支付方式集合。

可选地，所述商品参数包括：所述虚拟商品的商品类型以及所述虚拟商品的历史购买记录；

所述拒绝支付条件包括：所述虚拟商品的商品类型为非消耗品，且存在所述虚拟商品的历史购买记录。

可选地，所述用户账户参数包括：支付使用的所述应用软件客户端的系统版本；

所述拒绝支付条件包括：支付使用的所述应用软件客户端的系统版本低于预设版本。

可选地，所述用户账户参数包括：发起所述支付单据时的终端以及在应用软件客户端注册所述用户账户时使用的终端；

所述拒绝支付条件包括：发起所述支付单据时的终端，与在所述应用软件客户端注册所述用户账户时使用的终端，不相同。

可选地，所述用户账户参数包括：发起所述支付单据时所述用户账户所属的地区；

所述拒绝支付条件包括：发起所述支付单据时所述用户账户所属的地区，不属于允许购买地区的集合。

可选地，所述用户账户参数包括：

发起所述支付单据之前所述用户账户持续登录应用软件客户端的时长，以及持续登录时间段内的进度数据；

所述拒绝支付条件包括：发起所述支付单据之前所述用户账户持续登录所述应用软件客户端的时长，不超过设定时长；或者，未获得所述持续登录时间段内的进度数据。

可选地，所述支付参数包括：所述订单的下单时间和所述票据的支付时间；

所述拒绝支付条件包括：所述下单时间和所述支付时间之间的差值超过设定值。

可选地，所述支付参数包括：所述订单中记录的下单时使用的第一终端标识字符串，和，所述票据中记录的支付时使用的第二终端标识字符串；

所述拒绝支付条件包括：所述第一终端标识字符串与所述第二终端标识字符串不一致。

可选地，所述满足所述拒绝支付条件之后，所述拒绝所述虚拟商品的支付之前，所述方法还包括：

向所述应用软件客户端提供文件的上传入口以及提示信息，所述提示信息用于提示上传支付凭证；

通过所述上传入口获取上传的支付凭证，并验证所述支付凭证无效。

可选地，所述满足所述拒绝支付条件之后，所述拒绝所述虚拟商品的支付之前，所述方法还包括：

向所述应用软件客户端发送恢复购买所述虚拟商品的指示，所述应用软件客户端根据所述指示，向所述第一服务器发送恢复购买请求，并获得所述第一服务器根据所述恢复购买请求重新生成的所述票据；

从所述应用软件客户端获取重新生成的所述票据，并确定重新生成的所述票据不包含所述虚拟商品。

可选地，所述满足所述拒绝支付条件之后，所述拒绝所述虚拟商品的支付之前，所述方法还包括：

每间隔设定时长向所述第一服务器发送对所述票据的刷新请求，并从所述第一服务器获得刷新后的票据，并确定所述刷新后的票据中包含取消时间。

可选地，所述允许所述虚拟商品的支付之后，所述方法还包括：

为所述用户账户解锁所述虚拟商品的使用权限；

拒绝所述虚拟商品的支付之后，所述方法还包括：

为所述用户账户取消所述虚拟商品的使用权限。

可选地，所述应用软件客户端安装于iOS系统内；

所述票据为IAP票据。

第二方面，本申请实施例提供了一种虚拟商品的支付装置，包括：

获取模块，用于获取所述虚拟商品支付单据的参数，所述参数中包括支付参数、商品参数和用户账户参数；

分析模块，用于分析所述参数，判断是否满足拒绝支付条件；

拒绝模块，用于若满足所述拒绝支付条件，拒绝所述虚拟商品的支付；

允许模块，用于若不满足所述拒绝支付条件，允许所述虚拟商品的支付。

第三方面，本申请实施例提供了一种电子设备，包括：存储器、处理器；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如第一方面所述的虚拟商品的支付方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时实现第一方面所述的虚拟商品的支付方法。

本申请实施例提供的上述技术方案与现有技术相比具有如下优点：本申请实施例提供的方法，通过设置拒绝支付条件，在获取虚拟商品支付单据的参数后，分析该参数中包括的支付参数、商品参数和用户账户参数，判断是否满足拒绝支付条件，对于不满足该拒绝支付条件的支付单据，拒绝支付，从而能够识别出有风险的支付并及时拒绝，降低了支付风险以及降低了对提供该虚拟商品的商家的损失。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

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

图1为本申请实施例中虚拟商品的支付方法流程示意图；

图2为本申请实施例中支付单据为订单时虚拟商品支付方法流程示意图；

图3为本申请实施例中支付单据为订单和票据时虚拟商品支付方法流程示意图；

图4为本申请实施例中虚拟商品的支付装置的结构示意图；

图5为本申请实施例中服务器结构示意图。

具体实施方式

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

本申请实施例中，定义具有支付功能的服务器为第一服务器，该第一服务器可以是终端提供商的服务器；

定义虚拟商品提供方的服务器为第二服务器，该第二服务器可以是应用软件客户端的后台服务器，其中，该应用软件客户端可以是安装在iOS系统内，简称为APP。

本申请实施例中，为了降低虚拟商品购买过程中的支付风险，提供了一种虚拟商品的支付方法，该方法主要应用于第二服务器中，即应用软件客户端的后台服务器中，当然，也不排除将实现该方法的软件程序，嵌入任意一种电子设备中，以实现该功能的情况。

具体地，如图1所示，第二服务器执行该虚拟商品支付方法的过程主要包括：

步骤101，获取虚拟商品支付单据的参数，该参数中包括支付参数、商品参数和用户账户参数。

其中，该支付单据包括由第一服务器产生的票据，该票据由虚拟商品提供方的第二服务器进行验证。该票据可以是应用内支付生成的票据，简称为IAP票据。

进一步地，该支付单据还包括：由请求购买虚拟商品的用户账户在应用软件客户端发起的订单，该订单由第二服务器生成并进行验证。

需要说明的是，该支付单据中也可以仅包括订单，在支付单据中同时包括票据和订单的情况下，后续拒绝支付条件的设置越全面，则识别风险的能力越强。

具体地，支付参数包括但不限于：支付使用的支付方式，例如用户终端账户绑定的支付方式所使用的币种；订单的下单时间和票据的支付时间；订单中记录的下单时使用的第一终端标识字符串，和，票据中记录的支付时使用的第二终端标识字符串。

具体地，商品参数包括但不限于：虚拟商品的商品类型以及虚拟商品的历史购买记录。

具体地，用户账户参数包括但不限于：支付使用的应用软件客户端的系统版本；发起支付单据时的终端以及在应用软件客户端注册用户账户时使用的终端；发起支付单据时用户账户所属的地区；发起支付单据之前所述用户账户持续登录应用软件客户端的时长，以及持续登录时间段内的进度数据。

步骤102，分析该参数，判断是否满足拒绝支付条件，若是，执行步骤103，否则，执行步骤104。

具体地，对应支付单据的参数，可以设置多种拒绝支付条件，包括但不限于以下几种：

第一种，在支付参数包括：支付使用的支付方式时，拒绝支付条件包括：支付使用的支付方式不属于允许支付方式集合。其中，支付使用的支付方式可以是支付所使用的币种等。

第二种，在商品参数包括：虚拟商品的商品类型以及该虚拟商品的历史购买记录时，拒绝支付条件包括：虚拟商品的商品类型为非消耗品，且存在该虚拟商品的历史购买记录。例如，第二服务器在用户账户的支付单据请求支付的虚拟商品属于非消耗品时，获取该虚拟商品的历史购买记录，如果历史购买记录中指示该用户账户已经成功购买过该虚拟商品，根据非消耗品的特性，同一用户无需多次购买，因此，直接拒绝此次的IAP支付，如果没有该虚拟商品的历史购买记录，则进行下一步验证或者允许支付。

IAP将用户可购买的商品分为四种类型，连续续期的订阅、非连续续期的订阅、非消耗品和可消耗品。连续续期的订阅会在订阅到期前自动续费，第二服务器定期刷新IAP票据，即可检测到用户的续费状态，并根据续费状态延长用户访问APP内相应付费内容的时长。

第三种，在用户账户参数包括：支付使用的应用软件客户端的系统版本时，拒绝支付条件包括：支付使用的应用软件客户端的系统版本低于预设版本。例如，如果版本低于iOS10(不含iOS10)，则直接拒绝IAP支付。设置版本低于iOS10的原因在于：正常终端使用iOS版本低于10的比例很低，禁用低于版本10的终端购买第一服务器中的虚拟商品，不会对该运营产生影响；并且，iOS代充需要越狱设备劫持iOS票据，低于iOS10版本的系统漏洞较多，容易越狱，为代充提供了便利，因此，禁止低版本的iOS系统向第一服务器购买虚拟商品，是降低代充风险的非常重要的手段。需要说明的是，此处仅以低于版本iOS10为例进行说明，这里根据实际需要也可以设置为低于其他版本，本申请的保护范围并不以此为限制。

第四种，在用户账户参数包括：发起支付单据时的终端以及在应用软件客户端注册用户账户时使用的终端时，拒绝支付条件包括：发起支付单据时的终端，与在应用软件客户端注册该用户账户时使用的终端，不相同。例如，对于单价高于设定价格的虚拟商品，重要性较高，容易受到代充的影响，对于该类虚拟商品，限制用户只能在注册用户账户时使用的终端上进行IAP购买，第二服务器如果检测到发起订单时使用的终端，与注册时使用的终端不一致，则直接拒绝IAP支付。

第五种，在用户账户参数包括：发起支付单据时用户账户所属的地区时，拒绝支付条件包括：发起该支付单据时该用户账户所属的地区，不属于允许购买地区的集合。其中，支付单据是用户账户所属的地区可以通过用户账户登录的终端的IP地址确定。

第六种，在用户账户参数包括：发起支付单据之前用户账户持续登录应用软件客户端的时长，以及持续登录时间段内的进度数据时，拒绝支付条件包括：发起支付单据之前该用户账户持续登录应用软件客户端的时长，不超过设定时长；或者，未获得持续登录时间段内的进度数据。例如，对于单价高于设定价格的虚拟商品，重要性较高，容易受到代充的影响，对于该类虚拟商品，限制用户在发起购买流程之前持续登录APP达到设定时长，且能够获取到持续登录时间段内的进度数据，如果不满足，则直接拒绝该支付。

第六种可以和第四种结合使用，在同时满足发起订单时使用的终端与注册时使用的终端一致，以及满足发起购买流程之前持续登录APP达到设定时长，且能够获取到持续登录时间段内的进度数据的情况下，通过该条件的验证，进行下一步验证或者允许支付。

第七种，在支付参数包括：订单的下单时间和票据的支付时间时，拒绝支付条件包括：下单时间和支付时间之间的差值超过设定值。具体地，在IAP支付虚拟商品得到IAP票据后，提取该IAP票据中记录的该虚拟商品的支付时间，并提取该虚拟商品的订单中记录的下单时间，如果支付时间和下单时间相差过大，如超过6小时，则认为本次支付有风险，拒绝本次支付或者进一步验证。

其中，设定值可以根据虚拟商品的商品类型和价格进行配置，对于单价越高的虚拟商品，设置的该设定值取值越小，对于低单价的虚拟商品，可适当放宽该设定值的要求。例如，设定商品类型与该设定值之间的对应关系，根据票据中的商品类型获取对应的设定值，在将票据中的购买时间与订单信息中的下单时间比较时，采用该商品的类型对应的设定值作为比较门限值。又例如，设定商品的价格与该设定值之间的对应关系，根据票据中商品的价格获取对应的设定值，在将票据中的购买时间与订单信息中的下单时间比较时，采用该商品的价格对应的设定值作为比较门限值。其中，商品的价格与设定值呈反比例，即商品的价格越高，则设定值的取值越小。也就是说，高单价的商品允许的时间差要小，低单价的商品允许的时间差要大。

第八种，在支付参数包括：订单中记录的下单时使用的第一终端标识字符串，和，票据中记录的支付时使用的第二终端标识字符串时，拒绝支付条件包括：第一终端标识字符串与第二终端标识字符串不一致。

该终端标识字符串即IDFV，IDFV是iOS系统用于标记终端的一种字符串，不同的终端在安装同一个APP后，APP获取到的IDFV不相同。

具体地，APP在从第一服务器获取IAP票据时，尽量获取到iOS6格式和iOS7格式的票据，将两种格式的票据发给第二服务器进行校验。由于iOS6格式的票据中包含IDFV，iOS7格式的票据中不包含IDFV，第二服务器从iOS6格式的票据中提取IDFV，并将订单中的IDFV与票据中提取的IDFV进行比较，若两者不一致，则直接拒绝本次支付，若一致，则进行下一步验证。

iOS6格式的票据中包含了用户一次购买的虚拟商品的信息，而iOS7格式的票据中包含用户在APP内购买的多件虚拟商品的信息。也就是说，iOS6格式的票据对应一个订单，iOS7格式的票据对应一个或多个订单。

其中，第一种至第六种验证，可以是在APP向第一服务器发起应用内支付之前，通过设置拒绝支付条件，对可疑订单进行识别，以避免APP对可疑订单发起IAP支付。当然，第一种至第六种验证，也可以是在得到支付生成的票据后进行验证，本实施例并不限制这些验证方式具体启用的时间段。

具体地，APP根据用户操作发起购买流程时，会向第二服务器上报购买请求，第二服务器根据该购买请求创建订单，并获得订单的参数，其中，该参数中的用户账户参数中包括用户账户(APP账号)、用户终端账号(即登录第一服务器使用的账号)、用户终端账号绑定的支付所用的币种、用户终端账号所属的地区以及IP地址、请求购买的虚拟商品的商品类型、用户账户登录的应用软件客户端的系统版本、用户账户注册时使用的终端及用户账户请求购买时使用的终端、用户账户持续登录APP的时长以及持续登录时间段内的进度数据等。第二服务器在生成订单后，将订单返回给APP，同时在本地保存。

部分参数是第二服务器从用户的购买请求中直接获得，部分参数可以是第二服务器根据购买请求中携带的参数从本地保存的参数中提取得到。

需要说明的是，以上第一至第八种验证，可以独立设置，也可以任意组合设置，在组合设置的情况下，在每种验证都为不满足拒绝支付条件的情况下，才能够执行步骤104，只有组合中有一种满足拒绝支付条件，则执行步骤103。

其中，第二服务器获得票据的过程为：第二服务器根据APP提交的创建订单请求创建订单后，生成订单，并将该订单返回给该APP，该APP根据该订单向第一服务器发起应用内支付，并获得该第一服务器针对该应用内支付生成并返回的票据。该APP将该票据提供给第二服务器。

步骤103，满足拒绝支付条件，拒绝虚拟商品的支付。

具体地，在判定满足拒绝支付条件后，可以进一步验证该虚拟商品的支付是否存在风险，根据进一步验证的结果判断是否拒绝该虚拟商品的支付。具体地，进一步验证的方式包括但不限于以下几种：

第一种，向应用软件客户端提供文件的上传入口以及提示信息，该提示信息用于提示上传支付凭证；通过该上传入口获取上传的支付凭证，并验证该支付凭证是否有效，若验证该支付凭证无效，则拒绝该虚拟商品的支付。

具体地，在满足拒绝支付条件时，被判定为存在风险，第二服务器可以提供上传入口和提示信息，以要求用户提供更多的支付凭证，该支付凭证包括但不限于银行卡扣费短信、第三方支付平台的交易记录、第一服务器发送的确认支付成功的邮件等，将支付凭证提交给客服人员进行审核，若审核通过，则同意支付，并为用户账户解锁该虚拟商品的使用权限，若审核不通过，则拒绝支付，并取消该用户账户使用给虚拟商品的权限。当然，也可以采用第二服务器审核支付凭证文件的方式，只需要在开发者服务器上设置支付凭证文件的识别方式以及审核规则即可。

第二种，向应用软件客户端发送恢复购买虚拟商品的指示，该应用软件客户端根据该指示，向第一服务器发送恢复购买请求，并获得该第一服务器根据该恢复购买请求重新生成的票据；从该应用软件客户端获取重新生成的票据，并验证重新生成的票据是否包含该虚拟商品，若不包含，则拒绝该虚拟商品的支付，确定之前获得的票据无效。

例如，第二服务器在根据票据中所记录的购买时间，确定第一服务器所允许的退款时间段，在该允许退款的时间段内，向该票据对应用户的APP发送恢复购买指令，该恢复购买指令用于指示恢复购买该票据中的商品。APP在获取到该恢复购买指令后，向第一服务器发送给恢复购买指令。第一服务器收到该恢复购买指令后，生成新的票据，例如iOS7格式的票据，并将该新的票据返回给该APP。该APP转发该新的票据给第二服务器。第二服务器根据该新的票据判断用户是否退款，即如果新的票据仍然包含之前票据中商品的购买记录，则确定该商品的购买记录真实有效，如果新的票据不包含之前票据中的购买记录，则确定该商品的购买记录无效，已被取消，第二服务器取消该用户APP内的相应权益。

其中，第二服务器可以是对退款时间段存在重合的多个票据发起恢复购买。

第三种，每间隔设定时长向第一服务器发送对票据的刷新请求，并从第一服务器获得刷新后的票据，并验证该刷新后的票据中是否包含取消时间，若包含，则拒绝该虚拟商品的支付。

例如，对于非消耗型的商品，第二服务器向第一服务器发送对iOS7格式的票据的刷新请求，在获得刷新后的iOS7格式的票据后，如果确定刷新后的票据中包含了取消时间这一字段，则确定用户向第一服务器申请了退款，则获取该票据对应用户的终端账号，将该终端账号APP内的相应权益取消。

已经消耗掉的可消耗品，在刷新后的票据中不会出现，非可消耗品、连续续期的订阅和非连续续期的订阅在刷新后还会保留在票据内，一旦取消会标注取消时间。

具体地，在拒绝该虚拟商品的支付之后，为该用户账户取消该虚拟商品的使用权限。

步骤104，不满足拒绝支付条件，允许虚拟商品的支付。

具体地，在允许该虚拟商品的支付之后，为该用户账户解锁该虚拟商品的使用权限。

本申请实施例提供的方法，通过设置拒绝支付条件，在获取虚拟商品支付单据的参数后，分析该参数中包括的支付参数、商品参数和用户账户参数，判断是否满足拒绝支付条件，对于不满足该拒绝支付条件的支付单据，拒绝支付，从而能够识别出有风险的支付并及时拒绝，降低了支付风险以及降低了对提供该虚拟商品的商家的损失。

一个具体实施例中，如图2所示，对支付单据为订单的情况下，虚拟商品的支付过程进行具体说明：

步骤201，判断发起创建订单请求的APP所在的iOS系统版本，是否高于预设版本，若否，执行步骤202，若是，执行步骤203；

步骤202，向该APP返回拒绝订单创建的响应；

步骤203，判断创建订单请求所请求购买的商品类型是否为非消耗品，若是，执行步骤204，若否，执行步骤205；

步骤204，判断历史订单记录中是否存在发起创建订单请求的设备标识购买同一商品的记录，若是，执行步骤202，若否，执行步骤205；

步骤205，判断发起创建订单请求时的用户行为是否符合约定条件，若否，执行步骤202，若是，执行步骤206；

步骤206，判断发起创建订单请求的用户终端账号是否属于允许购买地区，若否，执行步骤202，若是，执行步骤207；

步骤207，判断订单创建请求所使用的支付方式是否属于允许的支付方式，若否，执行步骤202，若是，执行步骤208；

步骤208，向APP返回订单创建成功后生成的订单信息。

需要说明的是，该具体实施例中各条件的先后判断顺序可以根据需要调整，不必须按照该具体实施例给出的判断顺序进行。其中，约定条件为：在下单之前该用户持续登录APP的时长超过设定时长，且已获得持续登录时间段内的进度数据。

该具体实施例中，在获取到创建订单请求后，判断该创建订单请请求是否符合预设的iOS应用内支付条件，对于不符合条件的创建订单请求，直接拒绝，从而能够在应用软件客户端发起iOS应用内支付之前识别出有代充风险的订单，拒绝该应用软件客户端对该有代充风险的订单发起iOS应用内支付，降低代充风险，降低应用软件客户端开发者的损失。

另一个具体实施例中，如图3所示，在支付单据为订单和票据的情况，进行虚拟商品支付的过程进行说明。

步骤301，APP发送IAP票据到第二服务器；

步骤302，第二服务器访问第一服务器，将该IAP票据发送给第一服务器，以验证IAP票据的合法性；

步骤303，第一服务器判断该IAP票据是否合法，若是，执行步骤304，否则，执行步骤310；

步骤304，第二服务器获取第一服务器返回的IAP票据合法的信息后，判断IAP票据中的购买时间与下单时间相差是否超过设定值，若是，执行步骤305，否则，执行步骤307；

步骤305，第二服务器通知APP联系客服，并提供更多支付凭证到第二服务器；

步骤306，客服验证APP上传到第二服务器的支付凭证是否有效，若是，执行步骤311，否则，执行步骤310；

步骤307，判断IAP票据中的IDFV和下单时获取到的终端的IDFV是否相同，若是，执行步骤311，否则，执行步骤308；

步骤308，第二服务器将该IAP票据作为可疑票据，定期发送到第一服务器进行验证；

步骤309，第二服务器在验证后，确定该IAP票据对应的交易被取消，执行步骤312；

步骤310，第二服务器确定该IAP票据无效，不解锁该APP内相应付费内容；

步骤311，第二服务器确定该IAP票据有效，解锁该APP内相应付费内容；

步骤312，第二服务器取消APP内该IAP票据对应的付费内容的使用权限。

该具体实施例中，对于订阅类型的商品，第一服务器会给第二服务器发送订阅状态改变的通知，该通知中包括用户退款的信息。第二服务器在检测到用户退款的信息后，获取该用户的信息，并将该用户APP内的该订阅类型的商品的权益取消。

该具体实施例中，在获取第一服务器返回的iOS应用内支付的票据后，比对该票据和该票据对应的订单中的参数，以识别该票据是否存在风险，从而避免直接以第一服务器对该票据的验证结果为准，导致存在高风险的应用内支付无法被识别的情况发生，能够显著降低应用内支付的代充比例，降低APP运营者的损失。

基于相同的构思，本申请实施例中提供了一种虚拟商品的支付装置，该装置的具体实施可参见第一实施例部分的描述，重复之处不再赘述，如图4所示，该装置主要包括：

获取模块401，用于获取所述虚拟商品支付单据的参数，所述参数中包括支付参数、商品参数和用户账户参数；

分析模块402，用于分析所述参数，判断是否满足拒绝支付条件；

拒绝模块403，用于若满足所述拒绝支付条件，拒绝所述虚拟商品的支付；

允许模块404，用于若不满足所述拒绝支付条件，允许所述虚拟商品的支付。

基于相同的构思，本申请实施例中还提供了一种电子设备，如图5所示，该电子设备主要包括：存储器501、处理器502；其中，存储器501上存储有可执行代码，当可执行代码被处理器502执行时，使处理器502执行如下步骤：获取所述虚拟商品支付单据的参数，所述参数中包括支付参数、商品参数和用户账户参数；分析所述参数，判断是否满足拒绝支付条件；若满足所述拒绝支付条件，拒绝所述虚拟商品的支付；若不满足所述拒绝支付条件，允许所述虚拟商品的支付。

处理器502和存储器501之间可以通过通信总线503完成相互间通信。通信总线503可以是外设部件互连标准(Peripheral Component Interconnect，简称PCI)总线或扩展工业标准结构(Extended Industry Standard Architecture，简称EISA)总线等。该通信总线503可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器501可以包括随机存取存储器(Random Access Memory，简称RAM)，也可以包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。可选地，存储器还可以是至少一个位于远离前述处理器502的存储装置。

上述的处理器502可以是通用处理器，包括中央处理器(Central ProcessingUnit，简称CPU)、网络处理器(Network Processor，简称NP)等，还可以是数字信号处理器(Digital Signal Processing，简称DSP)、专用集成电路(Application SpecificIntegrated Circuit，简称ASIC)、现场可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

在本申请的又一实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，当该计算机程序在计算机上运行时，使得计算机执行上述虚拟商品的支付方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机指令时，全部或部分地产生按照本申请实施例所述的流程或功能。该计算机可以时通用计算机、专用计算机、计算机网络或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、微波等)方式向另外一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如软盘、硬盘、磁带等)、光介质(例如DVD)或者半导体介质(例如固态硬盘)等。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

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

这里所寻求保护的主题的范围在所附权利要求中进行限定。本发明实施例中还包括在下列编号条款中规定的这些和其他方面：

1.一种虚拟商品的支付方法，包括：

获取所述虚拟商品支付单据的参数，所述参数中包括支付参数、商品参数和用户账户参数；

分析所述参数，判断是否满足拒绝支付条件；

若满足所述拒绝支付条件，拒绝所述虚拟商品的支付；

若不满足所述拒绝支付条件，允许所述虚拟商品的支付。

2.根据条款1所述的虚拟商品的支付方法，所述支付单据包括：由具有支付功能的第一服务器产生的票据，所述票据由所述虚拟商品提供方的第二服务器进行验证。

3.根据条款2所述的虚拟商品的支付方法，所述支付单据还包括：由请求购买所述虚拟商品的用户账户在应用软件客户端发起的订单，所述订单由所述虚拟商品提供方的第二服务器生成并进行验证。

4.根据条款3所述的虚拟商品的支付方法，所述支付参数包括：支付使用的支付方式；

所述拒绝支付条件包括：支付使用的支付方式不属于允许支付方式集合。

5.根据条款4所述的虚拟商品的支付方法，所述商品参数包括：所述虚拟商品的商品类型以及所述虚拟商品的历史购买记录；

所述拒绝支付条件包括：所述虚拟商品的商品类型为非消耗品，且存在所述虚拟商品的历史购买记录。

6.根据条款5所述的虚拟商品的支付方法，所述用户账户参数包括：支付使用的所述应用软件客户端的系统版本；

所述拒绝支付条件包括：支付使用的所述应用软件客户端的系统版本低于预设版本。

7.根据条款3所述的虚拟商品的支付方法，所述用户账户参数包括：发起所述支付单据时的终端以及在应用软件客户端注册所述用户账户时使用的终端；

所述拒绝支付条件包括：发起所述支付单据时的终端，与在所述应用软件客户端注册所述用户账户时使用的终端，不相同。

8.根据条款4所述的虚拟商品的支付方法，所述用户账户参数包括：发起所述支付单据时所述用户账户所属的地区；

所述拒绝支付条件包括：发起所述支付单据时所述用户账户所属的地区，不属于允许购买地区的集合。

9.根据条款7所述的虚拟商品的支付方法，所述用户账户参数包括：

发起所述支付单据之前所述用户账户持续登录应用软件客户端的时长，以及持续登录时间段内的进度数据；

所述拒绝支付条件包括：发起所述支付单据之前所述用户账户持续登录所述应用软件客户端的时长，不超过设定时长；或者，未获得所述持续登录时间段内的进度数据。

10.根据条款3至9任一项所述的虚拟商品的支付方法，所述支付参数包括：所述订单的下单时间和所述票据的支付时间；

所述拒绝支付条件包括：所述下单时间和所述支付时间之间的差值超过设定值。

11.根据条款3至9任一项所述的虚拟商品的支付方法，所述支付参数包括：所述订单中记录的下单时使用的第一终端标识字符串，和，所述票据中记录的支付时使用的第二终端标识字符串；

所述拒绝支付条件包括：所述第一终端标识字符串与所述第二终端标识字符串不一致。

12.根据条款3所述的虚拟商品的支付方法，所述满足所述拒绝支付条件之后，所述拒绝所述虚拟商品的支付之前，所述方法还包括：

向所述应用软件客户端提供文件的上传入口以及提示信息，所述提示信息用于提示上传支付凭证；

通过所述上传入口获取上传的支付凭证，并验证所述支付凭证无效。

13.根据条款3所述的虚拟商品的支付方法，所述满足所述拒绝支付条件之后，所述拒绝所述虚拟商品的支付之前，所述方法还包括：

向所述应用软件客户端发送恢复购买所述虚拟商品的指示，所述应用软件客户端根据所述指示，向所述第一服务器发送恢复购买请求，并获得所述第一服务器根据所述恢复购买请求重新生成的所述票据；

从所述应用软件客户端获取重新生成的所述票据，并确定重新生成的所述票据不包含所述虚拟商品。

14.根据条款3所述的虚拟商品的支付方法，所述满足所述拒绝支付条件之后，所述拒绝所述虚拟商品的支付之前，所述方法还包括：

每间隔设定时长向所述第一服务器发送对所述票据的刷新请求，并从所述第一服务器获得刷新后的票据，并确定所述刷新后的票据中包含取消时间。

15.根据条款3所述的虚拟商品的支付方法，所述允许所述虚拟商品的支付之后，所述方法还包括：

为所述用户账户解锁所述虚拟商品的使用权限；

拒绝所述虚拟商品的支付之后，所述方法还包括：

为所述用户账户取消所述虚拟商品的使用权限。

16.根据条款3所述的虚拟商品的支付方法，所述应用软件客户端安装于iOS系统内；

所述票据为IAP票据。

17.一种虚拟商品的支付装置，包括：

获取模块，用于获取所述虚拟商品支付单据的参数，所述参数中包括支付参数、商品参数和用户账户参数；

分析模块，用于分析所述参数，判断是否满足拒绝支付条件；

拒绝模块，用于若满足所述拒绝支付条件，拒绝所述虚拟商品的支付；

允许模块，用于若不满足所述拒绝支付条件，允许所述虚拟商品的支付。

18.一种电子设备，包括：存储器、处理器；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如条款1至16任一项所述的虚拟商品的支付方法。

19.一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时实现条款1至16任一项所述的虚拟商品的支付方法。

Claims (10)

1.一种虚拟商品的支付方法，其特征在于，包括：

获取所述虚拟商品支付单据的参数，所述参数中包括支付参数、商品参数和用户账户参数；

分析所述参数，判断是否满足拒绝支付条件；

若满足所述拒绝支付条件，拒绝所述虚拟商品的支付；

若不满足所述拒绝支付条件，允许所述虚拟商品的支付。

2.根据权利要求1所述的虚拟商品的支付方法，其特征在于，所述支付单据包括：由具有支付功能的第一服务器产生的票据，所述票据由所述虚拟商品提供方的第二服务器进行验证。

3.根据权利要求2所述的虚拟商品的支付方法，其特征在于，

所述支付单据还包括：由请求购买所述虚拟商品的用户账户在应用软件客户端发起的订单，所述订单由所述虚拟商品提供方的第二服务器生成并进行验证。

4.根据权利要求3所述的虚拟商品的支付方法，其特征在于，所述支付参数包括：支付使用的支付方式；

所述拒绝支付条件包括：支付使用的支付方式不属于允许支付方式集合。

5.根据权利要求4所述的虚拟商品的支付方法，其特征在于，所述商品参数包括：所述虚拟商品的商品类型以及所述虚拟商品的历史购买记录；

所述拒绝支付条件包括：所述虚拟商品的商品类型为非消耗品，且存在所述虚拟商品的历史购买记录。

6.根据权利要求5所述的虚拟商品的支付方法，其特征在于，所述用户账户参数包括：支付使用的所述应用软件客户端的系统版本；

所述拒绝支付条件包括：支付使用的所述应用软件客户端的系统版本低于预设版本。

7.根据权利要求3所述的虚拟商品的支付方法，其特征在于，所述用户账户参数包括：发起所述支付单据时的终端以及在应用软件客户端注册所述用户账户时使用的终端；

所述拒绝支付条件包括：发起所述支付单据时的终端，与在所述应用软件客户端注册所述用户账户时使用的终端，不相同。

8.一种虚拟商品的支付装置，其特征在于，包括：

获取模块，用于获取所述虚拟商品支付单据的参数，所述参数中包括支付参数、商品参数和用户账户参数；

分析模块，用于分析所述参数，判断是否满足拒绝支付条件；

拒绝模块，用于若满足所述拒绝支付条件，拒绝所述虚拟商品的支付；

允许模块，用于若不满足所述拒绝支付条件，允许所述虚拟商品的支付。

9.一种电子设备，其特征在于，包括：存储器、处理器；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求1至7任一项所述的虚拟商品的支付方法。

10.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7任一项所述的虚拟商品的支付方法。

Images