CN110335098A - 在产品支付中心服务端的订单识别方法及设备 - Google Patents

Abstract

本发明的目的是提供一种订单识别方法及设备，通过对支付流程中支付订单的请求和支付完成发货之前的两个可控环节分别进行异常判断，业务可在不同环节采取措施，可以在较大程度上避免损失，一些常规的刷单方式基本可以被发现并规避；另外，本发明结合用户历史的行为，对于已知的以及部分潜在的刷单风险，进行了多层过滤识别，有效的识别并降低了如苹果支付平台等的退款率。本发明可以通过设立指定黑名单，在名单内相关用户\设备等充值行为均受到拦截。

Description

在产品支付中心服务端的订单识别方法及设备

技术领域

本发明涉及计算机领域，尤其涉及一种订单识别方法及设备。

背景技术

现有的移动设备操作系统如苹果的应用内置购买(IAP)政策规定，在APP内需要付费使用的产品功能或虚拟商品及服务，如游戏道具、电子书、音乐等，必须使用IAP购买支付，不允许使用支付宝、微信支付等其他支付方式，也不允许以任何方式(如跳出APP、提示文案等)引导用户通过应用外部渠道购买。

于此同时，现有的移动设备操作系统如苹果为了保护用户的权益，如果用户对购买商品不满意，可以申请退款，苹果在审核后会给用户发起退款。另外，现有的移动设备操作系统如苹果出于对消费者隐私的保护，拒绝向开发者提供用户退款的资料。所以，部分用户在退款成功后，由于开发者并不了解用户是否退款，用户可以继续使用开发者的产品。

目前，现有的移动设备操作系统如苹果的退款政策已经被相关组织和个人恶意利用，已经形成了黑色的产业链。特别是在游戏行业非常普遍，据传有些游戏的坏账率超过80％，这给开发者造成巨大的经济损失。

在相关的公开资料和文献中，有一些关于现有的移动设备操作系统如苹果支付刷单的的解决方案。主要从程序漏洞、规则漏洞和线下打击三个方面进行。

开发者程序完善

1.破解IAP付款

对于游戏而言，用户的主要充值流程中，客户端请求购买，AppStore(应用商店)处理扣款，如果成功会返回Receipt_data(小票数据)至客户端，相对安全的流程是将这段数据发送至服务端，由产品支付中心服务端发起请求，并向苹果统一支付服务端的验单接口来验证Receipt_data的有效性。

而对于某些游戏，会直接在客户端发起苹果验单接口的调用，甚至未设定产品支付中心服务端请求Receipt_data验证的流程，而此时非法用户可以利用插件，如iAPCracker在客户端请求扣款后，模拟返回扣款成功，而得到的结果有可能是经过篡改的。

2.重复使用Receipt_data

这种问题的发生主要是因为虽然已经用安全的方式检查Receipt_data的有效性，但并未检查Receipt_data的唯一性。

在产品支付中心服务端向苹果统一支付服务端验证Receipt_data有效性时，苹果会返回状态告知是否有效，当并未判断是否使用过。如果收到有效的结果即向用户进行游戏发货，则容易被不法用户利用，如用户真实进行一笔小额充值，然后获取真实有效的Receipt_data，然后在后续大额支付中使用已经获取到的Receipt_data骗过服务端验证。

苹果充值政策漏洞

1.利用信用卡黑卡

利用黑卡是常用的刷单的方法，因为信用卡已经无效，因此银行不会给到苹果结算，自然开发者不会得到分成。

实现这种刷单方式的场景主要是用户在交易网站寻找代充，商家收取远低于正常价格的金额，商家也有可能招募用户充值后申请退款，并进行分成后相互获利。

2.利用外币卡赚取差价

这种刷单的手段需要根据苹果的正常，如苹果支付会对新兴的市场给出一定的折扣优惠，如果用户使用有折扣的货币进行充值，赚取差价获利。

3.小额不验证规则

这种刷单的方式是利用苹果对信用卡的小额消费不做验证的规则实现。用户发起购买后，苹果不确认购买即会向客户端返回扣款成功的信息，而在此后进行相应的扣款操作，则会出现无法扣款的情形。而对于开发者而言，得到的Receipt_data也会通过苹果服务器的验证，但最终可能会得不到相关的分成。

发明内容

本发明的一个目的是提供一种在产品支付中心服务端的订单识别方法及设备。

根据本发明的一个方面，提供了一种在产品支付中心服务端的订单识别方法，该方法包括：

从客户端接收支付订单的请求；

根据预设规则判断所述支付订单的请求是否异常，

若异常，则向所述客户端反馈拒绝生成支付订单的信息；

若正常，则基于所述请求生成对应的支付订单并发送给所述客户端。

进一步的，上述方法中，基于所述请求生成对应的支付订单并发送给所述客户端之后，还包括：

从客户端接收支付结果信息，其中，所述支付结果信息由统一支付服务端根据所述客户端基于所述支付订单发送的支付请求生成；

将所述支付结果信息发送至所述统一支付服务端进行校验；

若校验通过，从所述统一支付服务端接收校验通过的信息；

接收到所述校验通过的信息后，根据预设规则判断所述支付结果信息是否异常，

若异常，则向所述客户端发送拦截给用户发送对应产品的信息；

若正常，则向所述客户端给用户发送对应产品的信息。

进一步的，上述方法中，根据预设规则判断所述支付订单的请求是否异常，或根据预设规则判断所述支付结果信息是否异常，包括：

从所述支付订单的请求或支付结果信息中提取用户帐号和设备号；

从提取到的用户帐号对应的历史支付行为和/或历史登陆行为中获取对应的设备号；

从提取到的设备号对应的历史支付行为和/或历史登陆行为中获取对应的用户帐号；

若获取到的同一用户帐号对应的设备号超过预设阈值区间，或者，若获取到的同一设备号对应的用户帐号超过预设阈值区间，则判断所述支付订单的请求为异常，或判断所述支付结果信息为异常；

否则，判断所述支付订单的请求为正常，或判断所述支付结果信息为正常。

进一步的，上述方法中，根据预设规则判断所述支付订单的请求是否异常，或根据预设规则判断所述支付结果信息是否异常，包括：

从所述支付订单的请求或支付结果信息中提取用户帐号；

从提取到的用户帐号对应的历史支付行为中获取金额小于第一预设阈值的支付订单数量；

若获取到的同一用户帐号对应的金额小于第一预设阈值的支付订单数量大于第二预设阈值，则判断所述支付订单的请求为异常，或判断所述支付结果信息为异常；

否则，判断所述支付订单的请求为正常，或判断所述支付结果信息为正常。

进一步的，上述方法中，根据预设规则判断所述支付结果信息是否异常，包括：

从所述支付结果信息中提取支付耗费时长；

若所述支付耗费时长大于第三阈值，则判断所述支付结果信息为异常；

否则，判断所述支付结果信息为正常。

根据本发明的另一方面，还提供了一种在产品支付中心服务端的订单识别设备，该设备包括：

第一装置，用于从客户端接收支付订单的请求；

第二装置，用于根据预设规则判断所述支付订单的请求是否异常，

第三装置，用于若异常，则向所述客户端反馈拒绝生成支付订单的信息；若正常，则基于所述请求生成对应的支付订单并发送给所述客户端。

进一步的，上述设备中，还包括：

第四装置，用于从客户端接收支付结果信息，其中，所述支付结果信息由统一支付服务端根据所述客户端基于所述支付订单发送的支付请求生成；

第五装置，用于将所述支付结果信息发送至所述统一支付服务端进行校验；

第六装置，用于若校验通过，从所述统一支付服务端接收校验通过的信息；

第七装置，用于接收到所述校验通过的信息后，根据预设规则判断所述支付结果信息是否异常，

第八装置，用于若异常，则向所述客户端发送拦截给用户发送对应产品的信息；若正常，则向所述客户端给用户发送对应产品的信息。

进一步的，上述设备中，所述第二装置，用于从所述支付订单的请求中提取用户帐号和设备号；从提取到的用户帐号对应的历史支付行为和/或历史登陆行为中获取对应的设备号；从提取到的设备号对应的历史支付行为和/或历史登陆行为中获取对应的用户帐号；若获取到的同一用户帐号对应的设备号超过预设阈值区间，或者，若获取到的同一设备号对应的用户帐号超过预设阈值区间，则判断所述支付订单的请求为异常；否则，判断所述支付订单的请求为正常；

所述第七装置，用于从所述支付结果信息中提取用户帐号和设备号；从提取到的用户帐号对应的历史支付行为和/或历史登陆行为中获取对应的设备号；从提取到的设备号对应的历史支付行为和/或历史登陆行为中获取对应的用户帐号；若获取到的同一用户帐号对应的设备号超过预设阈值区间，或者，若获取到的同一设备号对应的用户帐号超过预设阈值区间，则判断所述支付结果信息为异常；否则，判断所述支付结果信息为正常。

进一步的，上述设备中，所述第二装置，用于从所述支付订单的请求中提取用户帐号；从提取到的用户帐号对应的历史支付行为中获取金额小于第一预设阈值的支付订单数量；若获取到的同一用户帐号对应的金额小于第一预设阈值的支付订单数量大于第二预设阈值，则判断所述支付订单的请求为异常；否则，判断所述支付订单的请求为正常；

所述第七装置，用于从所述支付结果信息中提取用户帐号；从提取到的用户帐号对应的历史支付行为中获取金额小于第一预设阈值的支付订单数量；若获取到的同一用户帐号对应的金额小于第一预设阈值的支付订单数量大于第二预设阈值，则判断所述支付结果信息为异常；否则，判断所述支付结果信息为正常。

进一步的，上述设备中，所述第七装置，用于从所述支付结果信息中提取支付耗费时长；若所述支付耗费时长大于第三阈值，则判断所述支付结果信息为异常；否则，判断所述支付结果信息为正常。

根据本发明的另一方面，还提供了一种基于计算的设备，其中，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：

从客户端接收支付订单的请求；

根据预设规则判断所述支付订单的请求是否异常，

若异常，则向所述客户端反馈拒绝生成支付订单的信息；

若正常，则基于所述请求生成对应的支付订单并发送给所述客户端。

根据本发明的另一方面，还提供了一种计算机可读存储介质，其上存储有计算机可执行指令，其中，该计算机可执行指令被处理器执行时使得该处理器：

从客户端接收支付订单的请求；

根据预设规则判断所述支付订单的请求是否异常，

若异常，则向所述客户端反馈拒绝生成支付订单的信息；

若正常，则基于所述请求生成对应的支付订单并发送给所述客户端。

与现有技术相比，本发明通过对支付流程中支付订单的请求和支付完成发货之前的两个可控环节分别进行异常判断，业务可在不同环节采取措施，可以在较大程度上避免损失，一些常规的刷单方式基本可以被发现并规避；另外，本发明结合用户历史的行为，对于已知的以及部分潜在的刷单风险，进行了多层过滤识别，有效的识别并降低了如苹果支付平台等的退款率。本发明可以通过设立指定黑名单，在名单内相关用户\设备等充值行为均受到拦截。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1示出本发明一实施例的在产品支付中心服务端的订单识别方法的原理图；

图2示出本发明一实施例的在产品支付中心服务端的订单识别方法的总体流程图。

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本发明作进一步详细描述。

在本申请一个典型的配置中，终端、服务网络的设备和可信方均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

如图1所示，本发明提供一种在产品支付中心服务端的订单识别方法，所述方法包括：

步骤S1，从客户端接收支付订单的请求；

在此，如图1所示，用户在如苹果公司的功能、应用的购买的实际支付过程中，主要为涉及客户端、支付中心(产品支付中心服务端)和苹果支付(统一支付服务端)；

步骤S2，根据预设规则判断所述支付订单的请求是否异常，

步骤S3，若异常，则向所述客户端反馈拒绝生成支付订单的信息；

步骤S4，若正常，则基于所述请求生成对应的支付订单并发送给所述客户端。

在此，如图1所示，支付订单的请求的流程1结束后，支付中心会请求识别接口会对支付订单的请求进行识别判断，但在基于所述请求生成对应的支付订单的流程2之前，根据预设规则判断所述支付订单的请求是否异常，若异常，则向所述客户端反馈拒绝生成支付订单的信息，若正常，则基于所述请求生成对应的支付订单并发送给所述客户端。

在识别的返回结果中，将标识了正常的订单，标识为如图2所示的白名单，后续不进行相关处理；异常订单中标识了灰名单(有相对较轻的刷单嫌疑)、黑名单(有较为明细的刷单嫌疑)、小额订单和超时订单，便于在后续统计及投诉处理中进行快速识别、判断和决策。

本实施例通过用户通过客户端向产品支付中心服务端请求订单时，如根据预设规则判断所述支付订单的请求异常，可拒绝生成支付订单，用户会无法进行支付，实现实时刷单风险识别判断，避免如iOS中的恶意刷单行为给公司造成不可控的经济损失。

本发明的在产品支付中心服务端的订单识别方法一实施例中，步骤S4，若正常，则基于所述请求生成对应的支付订单并发送给所述客户端之后，还包括：

步骤S5，从客户端接收支付结果信息，其中，所述支付结果信息由统一支付服务端根据所述客户端基于所述支付订单发送的支付请求生成；

步骤S6，将所述支付结果信息发送至所述统一支付服务端进行校验；

步骤S7，若校验通过，从所述统一支付服务端接收校验通过的信息；

步骤S8，接收到所述校验通过的信息后，根据预设规则判断所述支付结果信息是否异常，

步骤S9，若异常，则向所述客户端发送拦截给用户发送对应产品的信息；

步骤S10，若正常，则向所述客户端给用户发送对应产品的信息。

在此，如图1所示，在返回校验结果的流程7结束后，支付中心会根据预设规则判断所述获取支付结果信息是否异常，然后会实时返回结果，然后根据不同结果决定通知客户端发货端流程8是否继续进行，其中，若异常，则向所述客户端发送拦截给用户发送对应产品的信息，若正常，则向所述客户端给用户发送对应产品的信息。

本实施例在用户通过客户端向统一支付服务端完成订单的支付时，如判断支付结果信息为异常，产品支付中心服务端可通知客户端拦截给用户发货，进一步实现实时刷单风险识别的可靠判断，避免如iOS中的恶意刷单行为给公司造成不可控的经济损失。

本发明的在产品支付中心服务端的订单识别方法一实施例中，步骤S2，根据预设规则判断所述支付订单的请求是否异常，或步骤S8，接收到所述校验通过的信息后，根据预设规则判断所述支付结果信息是否异常，包括：

从所述支付订单的请求或支付结果信息中提取用户帐号和设备号；

从提取到的用户帐号对应的历史支付行为和/或历史登陆行为中获取对应的设备号；

从提取到的设备号对应的历史支付行为和/或历史登陆行为中获取对应的用户帐号；

若获取到的同一用户帐号对应的设备号超过预设阈值区间，或者，若获取到的同一设备号对应的用户帐号超过预设阈值区间，则判断所述支付订单的请求为异常，或判断所述支付结果信息为异常；

否则，判断所述支付订单的请求为正常，或判断所述支付结果信息为正常。

在此，考虑到普通用户帐号通常会在1～2个设备上进行游戏相关操作并进行充值，如果一个用户帐号(uid)的历史充值行为中使用多个设备号(IDFA)进行充值，或者某个设备上对多个用户进行充值，则可判断为异常用户或设备。并根据不同数据的阈值进行分级标注，而针对这些用户或者设备后续产生的订单可标识不同的异常，并拦截发货预警。

苹果的设备标识(IDFA)存在用户关闭广告追踪获取不到或者重置变化的情况，我们在SDK初次启动时获取对应设备的IDFA放至钥匙串中(如果IDFA获取不到，则SDK会自行生成设备标识放置钥匙串中)，并在每次需要获取IDFA时获取钥匙串中的IDFA并进行上报，如此可保证用户设备号的有效性和一致性。

具体数值如下，历史累计充值IDFA或uid的个数的区间为[10,30]，对应的uid或IDFA标注为灰名单，历史累计充值IDFA及uid的数据区间为(30,+∞)，则对应的uid或IDFA标识为如图2所示的黑名单。具体的阈值可能会根据平台的上线时间及交叉用户的情况略有调整。

另外，与平台名单相似，区别为只判断用户在单款游戏的历史订单情况，同时也只适用于对应游戏的判断。

具体的相关数值如下，历史累计充值IDFA或uid的个数的区间为[5,10]，对应的uid或IDFA标注为灰名单，历史累计充值IDFA及uid的数据区间为(10,+∞)，则对应的uid或IDFA标识为如图2所示的黑名单。具体的阈值可能会根据游戏的上线时间略有调整。

此外，商家远程登录帮用户充值是最常见的代充场景，但商家通常不会经常玩这个游戏，所以就可以通过用户的近期行为对常用设备进行判断，来识别风险设备的充值。具体可根据最近一段时间玩家在某设备上登录及支付的次数进行判定(为避免用户较短时间内多次重复使用给结果造成误差，在计算是短时间内的多次使用只记为一次)。当用户发起支付时，可根据用户的支付订单中使用的IDFA在其常用设备中的常用度，并根据常用度的阈值判断该笔订单的不同风险级别，并根据不同风险级别进行发货的拦截预警。

具体数值如下，允许同一用户在同一游戏有3个常用设备，如用户使用的设备为第4常用设备，则对应的订单返回为如图2所示的灰名单，如设备为第5及之后的设备，则对应的订单返回为如图2所示的黑名单。另外具体的阈值可能会根据游戏的生命周期略有调整。不是常用的判断为异常。

具体的，在订单的分析中，我们发现在苹果支付成功后返回的数据中，存在Download_id这个字段，并在同一用户的订单中保持不变，因此我们怀疑此字段可以代替用户的Apple_id(用户帐号)。在经过历史数据分析以及测试人员的游戏\用户\设备\Apple_id的交叉测试中发现，同一Apple_id在相同游戏不同设备中保持一致，但在不同游戏中同一用户会不一致。因此，在同一游戏中，可以认为苹果返回信息中的Download_id可认为是用户的Apple_id。

而对于常用Download_id的识别判断，跟用户的常用IDFA类似，即根据最近历史用户支付信息计算出的常用Download_id，并在订单支付时判断该笔订单使用的Download_id的常用度，并根据阈值返回不同风险级别，并根据不同风险级别进行发货的拦截。

具体数值如下，允许同一用户在同一游戏有3个常用Download_id，如用户使用的设备为第4常用Download_id，则对应的订单返回为灰名单，如设备为第5及之后的Download_id，则对应的订单返回为如图2所示的黑名单。另外具体的阈值可能会根据游戏的生命周期略有调整。

本发明的在产品支付中心服务端的订单识别方法一实施例中，步骤S2，根据预设规则判断所述支付订单的请求是否异常，或步骤S8，接收到所述校验通过的信息后，根据预设规则判断所述支付结果信息是否异常，包括：

从所述支付订单的请求或支付结果信息中提取用户帐号；

从提取到的用户帐号对应的历史支付行为中获取金额小于第一预设阈值的支付订单数量；

若获取到的同一用户帐号对应的金额小于第一预设阈值的支付订单数量大于第二预设阈值，则判断所述支付订单的请求为异常，或判断所述支付结果信息为异常；

否则，判断所述支付订单的请求为正常，或判断所述支付结果信息为正常。

在此，针对如苹果支付平台等的小额支付漏洞，通常游戏会在客户端会在金额上进行设置，避免小额的充值订单的发生。可以也在系统里进行了相关的识别，如单日内小额支付成功的笔数达到指定阈值，则对该笔订单进行拦截发货预警。

具体数值如下，单个用户在同一自然内充值金额小于等于30元相同金额订单如大于8笔，则对应的订单标注为小额支付订单。具体阈值可能会根据游戏内小额支付设置及游戏的生命周期略有调整。

本发明的在产品支付中心服务端的订单识别方法一实施例中，步骤S8，接收到所述校验通过的信息后，根据预设规则判断所述支付结果信息是否异常，包括：

从所述支付结果信息中提取支付耗费时长；

若所述支付耗费时长大于第三阈值，则判断所述支付结果信息为异常；

否则，判断所述支付结果信息为正常。

在此，通常情况下，用户请求支付到支付完成使用的时间会较短，经数据统计，99.9％订单会在10分钟内完成。如果用户在支付环节进行相关欺诈等，势必会使用较多的时间。因此，对订单使用时间超过10分钟的订单进行超时预警，暂时拦截发货，也可以避免风险订单的恶意处理。另外，具体的阈值(此处为10分钟)可能会根据网络等情况进行调整。

综上所述，本发明通过对支付流程中支付订单的请求和支付完成发货之前的两个可控环节分别进行异常判断，业务可在不同环节采取措施，可以在较大程度上避免损失，一些常规的刷单方式基本可以被发现并规避；另外，本发明结合用户历史的行为，对于已知的以及部分潜在的刷单风险，进行了多层过滤识别，有效的识别并降低了如苹果支付平台等的退款率。本发明可以通过设立指定黑名单，在名单内相关用户\设备等充值行为均受到拦截。

根据本发明的另一方面，还提供了一种在产品支付中心服务端的订单识别设备，该设备包括：

第一装置，用于从客户端接收支付订单的请求；

第二装置，用于根据预设规则判断所述支付订单的请求是否异常，

第三装置，用于若异常，则向所述客户端反馈拒绝生成支付订单的信息；若正常，则基于所述请求生成对应的支付订单并发送给所述客户端。

进一步的，上述设备中，还包括：

第四装置，用于从客户端接收支付结果信息，其中，所述支付结果信息由统一支付服务端根据所述客户端基于所述支付订单发送的支付请求生成；

第五装置，用于将所述支付结果信息发送至所述统一支付服务端进行校验；

第六装置，用于若校验通过，从所述统一支付服务端接收校验通过的信息；

第七装置，用于接收到所述校验通过的信息后，根据预设规则判断所述支付结果信息是否异常，

第八装置，用于若异常，则向所述客户端发送拦截给用户发送对应产品的信息；若正常，则向所述客户端给用户发送对应产品的信息。

进一步的，上述设备中，所述第二装置，用于从所述支付订单的请求中提取用户帐号和设备号；从提取到的用户帐号对应的历史支付行为和/或历史登陆行为中获取对应的设备号；从提取到的设备号对应的历史支付行为和/或历史登陆行为中获取对应的用户帐号；若获取到的同一用户帐号对应的设备号超过预设阈值区间，或者，若获取到的同一设备号对应的用户帐号超过预设阈值区间，则判断所述支付订单的请求为异常；否则，判断所述支付订单的请求为正常；

所述第七装置，用于从所述支付结果信息中提取用户帐号和设备号；从提取到的用户帐号对应的历史支付行为和/或历史登陆行为中获取对应的设备号；从提取到的设备号对应的历史支付行为和/或历史登陆行为中获取对应的用户帐号；若获取到的同一用户帐号对应的设备号超过预设阈值区间，或者，若获取到的同一设备号对应的用户帐号超过预设阈值区间，则判断所述支付结果信息为异常；否则，判断所述支付结果信息为正常。

进一步的，上述设备中，所述第二装置，用于从所述支付订单的请求中提取用户帐号；从提取到的用户帐号对应的历史支付行为中获取金额小于第一预设阈值的支付订单数量；若获取到的同一用户帐号对应的金额小于第一预设阈值的支付订单数量大于第二预设阈值，则判断所述支付订单的请求为异常；否则，判断所述支付订单的请求为正常；

所述第七装置，用于从所述支付结果信息中提取用户帐号；从提取到的用户帐号对应的历史支付行为中获取金额小于第一预设阈值的支付订单数量；若获取到的同一用户帐号对应的金额小于第一预设阈值的支付订单数量大于第二预设阈值，则判断所述支付结果信息为异常；否则，判断所述支付结果信息为正常。

进一步的，上述设备中，所述第七装置，用于从所述支付结果信息中提取支付耗费时长；若所述支付耗费时长大于第三阈值，则判断所述支付结果信息为异常；否则，判断所述支付结果信息为正常。

根据本发明的另一方面，还提供了一种基于计算的设备，其中，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：

从客户端接收支付订单的请求；

根据预设规则判断所述支付订单的请求是否异常，

若异常，则向所述客户端反馈拒绝生成支付订单的信息；

若正常，则基于所述请求生成对应的支付订单并发送给所述客户端。

根据本发明的另一方面，还提供了一种计算机可读存储介质，其上存储有计算机可执行指令，其中，该计算机可执行指令被处理器执行时使得该处理器：

从客户端接收支付订单的请求；

根据预设规则判断所述支付订单的请求是否异常，

若异常，则向所述客户端反馈拒绝生成支付订单的信息；

若正常，则基于所述请求生成对应的支付订单并发送给所述客户端。

本发明的各设备和存储介质实施例的详细内容，具体可参见各方法实施例的对应部分，在此，不再赘述。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

需要注意的是，本发明可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本发明的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本发明的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本发明的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

另外，本发明的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本发明的方法和/或技术方案。而调用本发明的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本发明的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本发明的多个实施例的方法和/或技术方案。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (12)

1.一种在产品支付中心服务端的订单识别方法，其中，该方法包括：

从客户端接收支付订单的请求；

根据预设规则判断所述支付订单的请求是否异常，

若异常，则向所述客户端反馈拒绝生成支付订单的信息；

若正常，则基于所述请求生成对应的支付订单并发送给所述客户端。

2.根据权利要求1所述的方法，其中，基于所述请求生成对应的支付订单并发送给所述客户端之后，还包括：

从客户端接收支付结果信息，其中，所述支付结果信息由统一支付服务端根据所述客户端基于所述支付订单发送的支付请求生成；

将所述支付结果信息发送至所述统一支付服务端进行校验；

若校验通过，从所述统一支付服务端接收校验通过的信息；

接收到所述校验通过的信息后，根据预设规则判断所述支付结果信息是否异常，

若异常，则向所述客户端发送拦截给用户发送对应产品的信息；

若正常，则向所述客户端给用户发送对应产品的信息。

3.根据权利要求2所述的方法，其中，根据预设规则判断所述支付订单的请求是否异常，或根据预设规则判断所述支付结果信息是否异常，包括：

从所述支付订单的请求或支付结果信息中提取用户帐号和设备号；

从提取到的用户帐号对应的历史支付行为和/或历史登陆行为中获取对应的设备号；

从提取到的设备号对应的历史支付行为和/或历史登陆行为中获取对应的用户帐号；

若获取到的同一用户帐号对应的设备号超过预设阈值区间，或者，若获取到的同一设备号对应的用户帐号超过预设阈值区间，则判断所述支付订单的请求为异常，或判断所述支付结果信息为异常；

否则，判断所述支付订单的请求为正常，或判断所述支付结果信息为正常。

4.根据权利要求2所述的方法，其中，根据预设规则判断所述支付订单的请求是否异常，或根据预设规则判断所述支付结果信息是否异常，包括：

从所述支付订单的请求或支付结果信息中提取用户帐号；

从提取到的用户帐号对应的历史支付行为中获取金额小于第一预设阈值的支付订单数量；

若获取到的同一用户帐号对应的金额小于第一预设阈值的支付订单数量大于第二预设阈值，则判断所述支付订单的请求为异常，或判断所述支付结果信息为异常；

否则，判断所述支付订单的请求为正常，或判断所述支付结果信息为正常。

5.根据权利要求2所述的方法，其中，根据预设规则判断所述支付结果信息是否异常，包括：

从所述支付结果信息中提取支付耗费时长；

若所述支付耗费时长大于第三阈值，则判断所述支付结果信息为异常；

否则，判断所述支付结果信息为正常。

6.一种在产品支付中心服务端的订单识别设备，其中，该设备包括：

第一装置，用于从客户端接收支付订单的请求；

第二装置，用于根据预设规则判断所述支付订单的请求是否异常，

第三装置，用于若异常，则向所述客户端反馈拒绝生成支付订单的信息；若正常，则基于所述请求生成对应的支付订单并发送给所述客户端。

7.根据权利要求6所述的设备，其中，还包括：

第四装置，用于从客户端接收支付结果信息，其中，所述支付结果信息由统一支付服务端根据所述客户端基于所述支付订单发送的支付请求生成；

第五装置，用于将所述支付结果信息发送至所述统一支付服务端进行校验；

第六装置，用于若校验通过，从所述统一支付服务端接收校验通过的信息；

第七装置，用于接收到所述校验通过的信息后，根据预设规则判断所述支付结果信息是否异常，

第八装置，用于若异常，则向所述客户端发送拦截给用户发送对应产品的信息；若正常，则向所述客户端给用户发送对应产品的信息。

8.根据权利要求7所述的设备，其中，所述第二装置，用于从所述支付订单的请求中提取用户帐号和设备号；从提取到的用户帐号对应的历史支付行为和/或历史登陆行为中获取对应的设备号；从提取到的设备号对应的历史支付行为和/或历史登陆行为中获取对应的用户帐号；若获取到的同一用户帐号对应的设备号超过预设阈值区间，或者，若获取到的同一设备号对应的用户帐号超过预设阈值区间，则判断所述支付订单的请求为异常；否则，判断所述支付订单的请求为正常；

所述第七装置，用于从所述支付结果信息中提取用户帐号和设备号；从提取到的用户帐号对应的历史支付行为和/或历史登陆行为中获取对应的设备号；从提取到的设备号对应的历史支付行为和/或历史登陆行为中获取对应的用户帐号；若获取到的同一用户帐号对应的设备号超过预设阈值区间，或者，若获取到的同一设备号对应的用户帐号超过预设阈值区间，则判断所述支付结果信息为异常；否则，判断所述支付结果信息为正常。

9.根据权利要求7所述的设备，其中，所述第二装置，用于从所述支付订单的请求中提取用户帐号；从提取到的用户帐号对应的历史支付行为中获取金额小于第一预设阈值的支付订单数量；若获取到的同一用户帐号对应的金额小于第一预设阈值的支付订单数量大于第二预设阈值，则判断所述支付订单的请求为异常；否则，判断所述支付订单的请求为正常；

所述第七装置，用于从所述支付结果信息中提取用户帐号；从提取到的用户帐号对应的历史支付行为中获取金额小于第一预设阈值的支付订单数量；若获取到的同一用户帐号对应的金额小于第一预设阈值的支付订单数量大于第二预设阈值，则判断所述支付结果信息为异常；否则，判断所述支付结果信息为正常。

10.根据权利要求7所述的设备，其中，所述第七装置，用于从所述支付结果信息中提取支付耗费时长；若所述支付耗费时长大于第三阈值，则判断所述支付结果信息为异常；否则，判断所述支付结果信息为正常。

11.一种基于计算的设备，其中，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：

从客户端接收支付订单的请求；

根据预设规则判断所述支付订单的请求是否异常，

若异常，则向所述客户端反馈拒绝生成支付订单的信息；

若正常，则基于所述请求生成对应的支付订单并发送给所述客户端。

12.一种计算机可读存储介质，其上存储有计算机可执行指令，其中，该计算机可执行指令被处理器执行时使得该处理器：

从客户端接收支付订单的请求；

根据预设规则判断所述支付订单的请求是否异常，

若异常，则向所述客户端反馈拒绝生成支付订单的信息；

若正常，则基于所述请求生成对应的支付订单并发送给所述客户端。