一种用户请求处理方法和设备与流程

本发明涉及通信技术领域，特别涉及一种用户请求处理方法和设备。

背景技术：

随着网络技术的不断发展，人们通过互联网完成的交易过程越来越多。基于网络实现的交易过程极大地方便了人们的工作、生活以及学习的各个方面，但是同时也存在着风险交易和虚假交易等诸多安全隐患。在目前的网络交易过程中，用户终端通过与服务端的风险防控系统之间进行交互来判断交易过程是否存在风险。

在现有技术中，风险防控系统的风险规则和交易数据采用关系数据库存放并部署在不同的服务器上，采用数据库触发器、消息队列事件等方案进行事件触发。风险防控系统通过对运营业务交易的实时分析、事中和事后分析、跟踪和处理实现欺诈风险预警的自动化，其目的在于通过对交易的监测，识别高风险交易，以及预判欺诈行为，并及时采取防范措施来降低交易带来的损失。

随着线下O2O业务的发展，扫码支付已逐步发展成为主流的支付方式，为了解决线下O2O的支付成功率，扫码支付采用的是离线支付的解决方案。

在实现本申请的过程中，发明人发现现有技术至少存在如下问题：

(1)用户终端在弱网或无网的环境下需进行离线支付，用户终端无法与服务端的风险防控系统之间通过在线交互来判断交易过程中是否存在风险，给交易过程带来了安全隐患；

(2)传统的在线支付场景下，用户终端在与服务端的风险防控系统之间交互判断过程中，用户终端需要等待一定的同步时间，这一过程通常需要持续500ms左右，使得用户的使用体验下降；

(3)风险判断过程需要在服务端集中式的进行计算，在海量的支付交易系统中，需要投入大量的硬件资源来做服务端的风险计算，特别是在有营销活动的场景下，为了支撑瞬间的交易支付的风险判断，往往需要进行大量的风控系统的扩容。另外，在用户终端数量不断增长的过程中，服务端的风险防控系统也需要不断扩容以适应用户终端数量地增长，这些均会使得风险防控的成本增加。

因此，现有技术在针对例如O2O支付、线下支付这一类需要快速处理反应的请求时，无法在保证安全的前提下快速完成请求处理，处理效率和时效存在延迟，降低了用户的使用体验。

技术实现要素：

本发明提供了一种用户请求处理方法，通过将风险控制规则以及用户数据预设于终端设备中的方式，解决了保证安全和快速完成请求处理二者不可兼顾的问题。

该方法应用于预设风险控制规则以及用户数据的终端设备，该方法包括：

所述终端设备接收用户发送的第一请求；

所述终端设备基于所述风险控制规则以及所述用户数据确定所述第一请求是否存在风险；

若所述第一请求存在风险，所述终端设备拒绝所述第一请求，或根据预设的风险请求处理策略对所述第一请求进行处理；

若所述第一请求不存在风险，所述终端设备执行所述第一请求。

优选地，所述终端设备根据预设的风险请求处理策略对所述第一请求进行处理，具体为：

所述终端设备将所述第一请求发送至为预先指定的服务器，并根据所述服务器返回的处理结果拒绝或执行所述第一请求；

或，所述终端设备提示所述用户输入验证信息，并在将所述验证信息携带在第二请求中发送至所述服务器后，根据所述服务器返回的处理结果拒绝或执行所述第二请求。

优选地，所述终端设备基于所述预设风险控制规则以及用户数据判断所述第一请求是否存在风险，具体为：

所述终端设备读取所述风险控制规则；

所述终端设备根据所述风险控制规则判断所述第一请求中携带的用户信息是否与所述用户数据匹配；

若匹配，所述终端设备判断所述第一请求存在风险；若不匹配，所述终端设备判断所述第一请求不存在风险。

优选地，在所述终端设备执行所述第一请求之后，还包括：

所述终端设备根据所述第一请求中携带的用户信息对自身存储的用户数据进行更新，并在所述更新完成后将更新后的用户数据上传至所述服务器。

优选地，当到达预设的更新周期对应的时刻时，所述终端设备获取所述服务器当前存储的风险控制规则以及用户数据，并根据获取到的风险控制规则以及用户数据对自身存储的风险控制规则以及用户数据进行更新。

相应地，本申请还提出了一种终端设备，该终端设备预设有风险控制规则以及用户数据，该终端设备包括：

接收模块，接收用户发送的第一请求；

确定模块，基于所述风险控制规则以及所述用户数据确定所述第一请求是否存在风险；

处理模块，在所述第一请求存在风险，拒绝所述第一请求，或根据预设的风险请求处理策略对所述第一请求进行处理；

执行模块，在所述第一请求不存在风险，执行所述第一请求。

优选地，所述处理模块具体用于：

将所述第一请求发送至为预先指定的服务器，并根据所述服务器返回的处理结果拒绝或执行所述第一请求；

或，提示所述用户输入验证信息，并在将所述验证信息携带在第二请求中发送至所述服务器后，根据所述服务器返回的处理结果拒绝或执行所述第二请求。

优选地，所述确定模块具体用于：

读取所述风险控制规则；

根据所述风险控制规则判断所述第一请求中携带的用户信息是否与所述用户数据匹配；

若匹配，判断所述第一请求存在风险；若不匹配，判断所述第一请求不存在风险。

优选地，所述终端设备还包括：

第一更新模块，根据所述第一请求中携带的用户信息对自身存储的用户数据进行更新，并在所述更新完成后将更新后的用户数据上传至所述服务器。

优选地，所述终端设备进一步包括：

第二更新模块，当到达预设的更新周期对应的时刻时，获取所述服务器当前存储的风险控制规则以及用户数据，并根据获取到的风险控制规则以及用户数据对自身存储的风险控制规则以及用户数据进行更新。

由此可见，通过应用本申请的技术方案，通过事先在终端设备中预设风险控制规则以及用户数据，在接收到用户发送的请求时根据风险控制规则以及用户数据确定是否存在风险，并在不存在风险的情况下执行请求，存在风险的情况下拒绝请求，或根据预设的风险请求处理策略对请求进行处理。从而可以在保证安全的前提下快速完成请求处理，有效提高了处理效率，同时提升了用户的使用体验。

附图说明

图1为本申请提出的一种用户请求处理方法的流程示意图；

图2为本申请的具体实施例所提出的一种离线支付处理方法示意图；

图3为本申请的具体实施例所提出的一种在线支付处理方法示意图；

图4为本申请提出的一种终端设备的结构示意图。

具体实施方式

有鉴于现有技术中的问题，本申请提出了一种用户请求处理方法，通过事先在终端设备中预设风险控制规则以及用户数据，当在针对需要快速处理反应的请求时，终端设备可对用户请求的风险予以先行判断。由于多数用户请求在终端设备中便可完成风险判断，这样可以省去终端设备与服务器之间的交互时间，从而降低了用户请求处理的平均时间，有效提升了用户的使用体验。

其中，风险控制规则以及用户数据分别存储在其对应的私有数据存储区内，私有数据存储区包括：

a)风险规则存储区：用于存储风险判断逻辑，风险判断逻辑用于定义在满足预设逻辑条件时，做出存在风险的判断。风险判断逻辑基于风险控制的运营需求以规则的形式进行包装，管理端可以在线对风险规则进行实时调整，并通过服务端与终端设备之间的下发通道将对应数据下发到终端设备中。

b)风险数据存储区：用于存储终端设备的用户历史请求的行为数据，包括但不限于存储于终端设备上的可信的用户列表、位置列表等信息。

如图1所示，为本申请提出的用户请求处理方法的流程示意图，包括以下步骤：

S101，所述终端设备接收用户发送的第一请求。

本发明实施例中，所述终端设备接收用户发送的请求的过程，具体包括但不限于如下方式，终端设备接收用户通过预设于终端设备的应用发送的携请求。其中，终端设备包括但不限于移动终端、个人计算机、服务器与网络设备等。

S102，所述终端设备基于所述风险控制规则以及所述用户数据确定所述第一请求是否存在风险。

为了向所述风险控制规则提供风险判断依据，本申请的所述第一请求有携带用户信息，终端设备可基于用户信息与预设的用户数据进行比对，以向所述风险控制规则提供风险判断依据。基于S101中所述第一请求携带的用户 信息，在本申请中优选的实施例中提出了对应的确定方式，具体如下：

步骤a)所述终端设备读取所述风险控制规则；

步骤b)所述终端设备根据所述风险控制规则判断所述第一请求中携带的用户信息是否与所述用户数据匹配；

步骤c)若匹配，所述终端设备判断所述第一请求存在风险；若不匹配，所述终端设备判断所述第一请求不存在风险。

具体的，当“用户数据中用户的请求位置列表包括位置A、位置B和位置C，而所述第一请求中的用户的请求位置为位置D”和“用户数据中用户的请求种类包括种类A、种类B和种类C,而所述第一请求中的用户的请求种类为种类D”同时出现时，则对应所述第一请求存在风险的概率通常较高。在本申请的具体实施例中，所述终端设备接收的所述第一请求的用户信息至少包括以下的一项或多项：用户的个人信息、用户的请求内容、用户的请求位置和用户的请求种类。

需要说明的是，以上用户信息的内容仅为本申请优选实施例提出的示例，在此基础上还可以为包括更多的内容，从而使得风险判断更为准确，这些改进都属于本发明的保护范围。

S103，若所述第一请求存在风险，所述终端设备拒绝所述第一请求，或根据预设的风险请求处理策略对所述第一请求进行处理。

本申请旨在针对用户发送的请求通过终端设备进行风险判断，并在判断存在风险时根据处理策略对请求进行处理，相应地，在本申请中优选的实施例中提出了对应的处理策略，具体如下：

所述终端设备将所述第一请求发送至为预先指定的服务器，并根据所述服务器返回的处理结果拒绝或执行所述第一请求；

或，所述终端设备提示所述用户输入验证信息，并在将所述验证信息携带在第二请求中发送至所述服务器后，根据所述服务器返回的处理结果拒绝或执行所述第二请求。

在此需要说明的是，本申请中的所述第二请求特指携带验证信息的所述 第一请求，在此基础上的其他命名方式均属于本发明的保护范围。

S104，若所述第一请求不存在风险，所述终端设备执行所述第一请求。

具体的应用场景中，多数用户请求在终端设备中便可完成风险判断，这样可以省去终端设备与服务器之间的交互时间，只存在少数用户请求需要输入验证信息进行验证或通过发送至服务器进行处理的方式进行再次判断。总体来说，降低了用户请求处理的平均时间，且无论在离线环境或还是在线环境中，均可以在保证安全风险的前提下快速完成请求处理。

在本申请的优选实施例中，所述终端设备执行所述第一请求之后，所述终端设备根据所述第一请求中携带的用户信息对自身存储的用户数据进行更新，并在所述更新完成后将更新后的用户数据上传至所述服务器。所述终端设备对自身存储的用户数据进行更新，可有效增加终端设备风险判断的准确性，将更新后的用户数据上传至所述服务器，增加了服务器风险判断的准确性，同时也降低了更新推送时间以及数据流量的消耗。

进一步地，本申请的优选实施例中还设置了针对风险控制规则以及用户数据的更新推送机制，当到达预设的更新周期对应的时刻时，所述终端设备获取所述服务器当前存储的风险控制规则以及用户数据，并根据获取到的风险控制规则以及用户数据对自身存储的风险控制规则以及用户数据进行更新。

本发明实施例中，服务器将风险控制规则以及用户数据定期更新推送至终端设备主要基于以下两个原因：

(1)随着终端设备处理用户请求次数的增多，携带在请求上的用户信息的数量随之增多，而用户信息作为终端设备判断用户请求是否存在风险的重要依据，其数据的完整性对此后用户请求的风险判断准确性有着决定性的影响，故需要将用户数据更新推送至终端设备；

(2)随着风险种类的多元化，服务器也需通过管理端对风险控制规则进行调整，将风险控制规则定期更新推送至终端设备，有利于提高终端设备判断风险的准确性。

由此可见，通过应用以上技术方案，应用于预设风险控制规则以及用户数据的终端设备，通过将风险控制规则以及用户数据预设于终端设备中，当在针对需要快速处理反应的请求时，终端设备可对用户请求的风险予以先行判断。由于多数用户请求在终端设备中便可完成风险判断，这样可以省去终端设备与服务器之间的交互时间，从而降低了用户请求处理的平均时间，且无论在离线环境或还是在线环境中，均可以在保证安全风险的前提下快速完成请求处理，有效提升了用户的使用体验。另外，由于多数用户请求在终端设备中便可完成风险判断，降低了对服务器端硬件资源以及容量的需求，节约了成本。

为了进一步阐述本申请的技术思想，现结合图3所示的具体的应用场景，对本申请的技术方案进行说明。

在此具体的应用场景中，由于网络条件的限制，采用离线支付的方式。终端设备中运行手机钱包，当手机钱包接收到支付请求时，进入扫码支付模式，同时终端设备根据用户信息判断出支付请求是否存在风险。

如果支付请求不存在风险，终端设备通过手机钱包执行支付请求，具体的，手机钱包生成并显示支付码，收款方扫描支付码的同时获取用户账号及授权码，通过请求协议完成用户扣款，终端设备对扣款状态进行显示。

如果支付请求存在风险，可通过以下两种方式进行处理：

a)终端设备通过手机钱包直接拒绝支付请求。

b)终端设备通过手机钱包提示所述用户输入验证信息，并在将验证信息携带在第二请求中发送至服务器后，根据服务器返回的处理结果拒绝或执行支付请求。具体的，若服务器返回的处理结果确定支付请求存在风险，则终止支付请求；若服务器返回的处理结果确定支付请求不存在风险，终端设备通过手机钱包执行支付请求，具体的，手机钱包生成并显示支付码，收款方扫描支付码的同时获取用户账号及授权码，通过请求协议完成用户扣款，终端设备对扣款状态进行显示。

在传统的离线支付中，终端设备无法与服务器之间通过在线交互的方式来对支付请求是否存在风险进行判断，故在离线支付过程中会面临多种安全隐患。而在本应用场景中，通过将风险控制规则以及用户数据预设于终端设备中，当在针对需要快速处理反应的请求时，终端设备可对用户请求的风险予以判断，保证了支付过程中的安全。同时，本应用场景中针对支付请求存在风险的情况下还提供了其他处理方式以保证支付过程的顺畅。

为了进一步阐述本申请的技术思想，现结合图4所示的具体的应用场景，对本申请的技术方案进行说明。

本应用场景针对传统在线支付的支付请求的处理方式做出改进。

终端设备中运行手机钱包，当手机钱包接收到支付请求时，进入扫码支付模式，同时终端设备根据用户信息判断出支付请求是否存在风险。

如果支付请求不存在风险，终端设备通过手机钱包执行支付请求，具体的，手机钱包生成并显示支付码，收款方扫描支付码的同时获取用户账号及授权码，通过请求协议完成用户扣款，终端设备对扣款状态进行显示。

如果支付请求存在风险，可通过以下两种方式进行处理：

a)终端设备通过手机钱包直接拒绝支付请求。

b)终端设备通过手机钱包将支付请求发送至为预先指定的服务器，服务器基于服务器端的风险控制规则以及用户数据对支付请求的风险进行判断，根据所述服务器返回的处理结果拒绝或执行支付请求。具体的，若服务器返回的处理结果确定支付请求存在风险，则终止支付请求；若服务器返回的处理结果确定支付请求不存在风险，终端设备通过手机钱包执行支付请求，具体的，手机钱包生成并显示支付码，收款方扫描支付码的同时获取用户账号及授权码，通过请求协议完成用户扣款，终端设备对扣款状态进行显示。

在传统的在线支付中，终端设备在与服务端的风险防控系统之间进行交互判断过程中，需要等待较长的处理同步时间，使得用户的使用体验下降。而在本应用场景中，通过将风险控制规则以及用户数据预设于终端设备中，当在针对需要快速处理反应的请求时，终端设备可对用户请求的风险予以先 行判断。由于多数用户请求在终端设备中便可完成风险判断，这样可以省去终端设备与服务器之间的交互时间，从而降低了用户请求处理的平均时间，在保证安全风险的前提下快速完成请求处理，同时有效提升了用户的使用体验。

由此可见，通过应用以上技术方案，应用于预设风险控制规则以及用户数据的终端设备，通过将风险控制规则以及用户数据预设于终端设备中，当在针对需要快速处理反应的请求时，终端设备可对用户请求的风险予以先行判断。由于多数用户请求在终端设备中便可完成风险判断，这样可以省去终端设备与服务器之间的交互时间，从而降低了用户请求处理的平均时间，且无论在离线环境或还是在线环境中，均可以在保证安全风险的前提下快速完成请求处理，有效提升了用户的使用体验。另外，由于多数用户请求在终端设备中便可完成风险判断，降低了对服务器端硬件资源以及容量的需求，节约了成本。

在此需要说明的是，以上具体的应用场景的内容仅为本申请优选实施例提出的示例，在此基础上还可以包括更多的应用领域，从而使得本技术方案具有更广泛的应用，这些改进都属于本发明的保护范围。

为达到以上技术目的，本申请还提出了一种终端设备，如图4所示，该终端设备包含风险控制规则以及用户数据，该终端设备包括：

接收模块210，接收用户发送的第一请求；

确定模块220，基于所述风险控制规则以及所述用户数据确定所述第一请求是否存在风险；

处理模块230，在所述第一请求存在风险，拒绝所述第一请求，或根据预设的风险请求处理策略对所述第一请求进行处理；

执行模块240，在所述第一请求不存在风险，执行所述第一请求。

优选地，所述处理模块具体用于：

将所述第一请求发送至为预先指定的服务器，并根据所述服务器返回的处理结果拒绝或执行所述第一请求；

或，提示所述用户输入验证信息，并在将所述验证信息携带在第二请求中发送至所述服务器后，根据所述服务器返回的处理结果拒绝或执行所述第二请求。

在具体的应用场景中，所述确定模块具体用于：

读取所述风险控制规则；

根据所述风险控制规则判断所述第一请求中携带的用户信息是否与所述用户数据匹配；

若匹配，判断所述第一请求存在风险；若不匹配，判断所述第一请求不存在风险。

在具体的应用场景中，所述终端设备还包括：

第一更新模块，根据所述第一请求中携带的用户信息对自身存储的用户数据进行更新，并在所述更新完成后将更新后的用户数据上传至所述服务器。

在具体的应用场景中，所述终端设备进一步包括：

第二更新模块，当到达预设的更新周期对应的时刻时，获取所述服务器当前存储的风险控制规则以及用户数据，并根据获取到的风险控制规则以及用户数据对自身存储的风险控制规则以及用户数据进行更新。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本发明的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施场景所述的方法。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本发明所必须的。

本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可 以进一步拆分成多个子模块。

上述本发明序号仅仅为了描述，不代表实施场景的优劣。

以上公开的仅为本发明的几个具体实施场景，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。