CN105719140A - 一种用户信息的验证方法和装置 - Google Patents

Abstract

本申请公开了一种用户信息的验证方法和装置，用以解决用户通过第三方支付平台完成业务时经常出现的业务不能成功完成的问题。该方法为，接收终端发起的基于第一账户的业务处理请求，业务处理请求中携带有目标账户的标识；确定业务处理请求的业务类型，并判断业务类型对应的历史操作数据中是否对应所述目标账户的标识保存有目标账户的属性信息；若是，则基于所述历史操作数据对目标账户的属性信息进行验证；否则，调用目标账户所归属的业务系统对目标账户的属性信息进行验证，这样提升了业务完成的成功率和准确率，进一步降低业务受理的过程中由于业务数据不符导致的资损风险。

Description

一种用户信息的验证方法和装置

技术领域

本申请涉及互联网领域，尤其涉及一种用户信息的验证方法和装置。

背景技术

随着互联网的广泛应用，通过第三方支付平台实现的业务越来越频繁，现阶段的第三方支付平台为用户提供了很多的金融服务，比如：信用卡还款、转账到卡、缴费服务等业务。在通过第三方支付平台实现金融服务的过程中，经常会发生用户输错目标账户的情况，如，输错目标账户的卡号，或者，输错目标账户的ID。而与目标账户的管理方在这种情况下通常不会对用户输入的目标账户进行校验，因此，经常会出现不能准确完成用户所指定的业务这种情形。

例如，用户通过第三方支付平台对目标账户进行转账时，若输入的目标账户的卡号错误且该卡号在目标账户的业务系统中不存在时，则用户无法完成针对目标账户的转账这一业务，影响业务完成的成功率。

又例如，用户通过第三方支付平台对目标账户进行转账时，若输入的目标账户的卡号错误，但是该卡号为存在于目标账户的业务系统中的另一账户时，导致用户无法正确完成针对目标账户的转账这一业务(即转错卡)，既影响业务完成的准确率，还降低了系统的安全性。

由此可知，现阶段的第三方支付平台完全信赖用户输入的业务信息，实现各种金融业务。由于业务信息在用户输入过程中可能会有业务信息不符或目标账户异常的情况出现，导致不能成功完成用户指定的业务，影响用业务完成的准确率和成功率，而且使系统安全性降低。

申请内容

本申请的目的是提供一种用户信息的验证方法和装置，以提升用户通过第三方支付平台完成业务的成功率与准确率。

本申请的目的是通过以下技术方案实现的：

一种用户信息的验证方法，应用在后台服务器，包括：

接收终端发起的基于第一账户的业务处理请求，所述业务处理请求中携带有目标账户的标识；

确定所述业务处理请求的业务类型，并判断所述业务类型对应的历史操作数据中是否对应所述目标账户的标识保存有所述目标账户的属性信息；

若是，则基于所述历史操作数据对所述目标账户的属性信息进行验证；

否则，调用目标账户所归属的业务系统对所述目标账户的属性信息进行验证。

这样通对过用户输入的目标账户的属性信息中的各项参数进行预校验，保证按照用户预期进行业务的实现，提升业务完成的成功率和准确率，进一步降低业务受理的过程中由于业务数据不符导致的资损风险，而且从原来强依赖合作方的服务内容转变为弱依赖，能够降低成本消耗。

可选的，目标账户的属性信息至少包括目标账户的标识、类型、业务状态，目标账户所属用户的身份标识和名称。

可选的，基于所述历史操作数据对所述目标账户的属性信息进行验证，包括：

获取对应所述第一账户保存的历史操作数据，基于获得的历史操作数据对所述目标账户的属性信息进行验证；

或者，

获取对应所述第一账户保存的历史操作数据，以及获取对应指定的其他用户保存的历史操作数据，基于获得的历史操作数据对所述目标账户的属性信息进行验证；

或者，

获取当前系统中对应所有账户保存的历史操作数据，基于获得的历史操作数据对所述目标账户的属性信息进行验证。

可选的，基于所述历史操作数据，对所述目标账户的属性信息进行验证，包括：

从历史操作数据中获取对应所述目标账户保存的属性信息；

根据终端指示，将获得的目标账户的属性信息包含的全部参数或者部分参数发往终端，并根据终端的响应判断所述目标账户的属性信息是否通过验证。

可选的，调用目标账户所归属的业务系统对所述目标账户的属性信息进行验证，包括：

向目标账户所归属的业务系统发送鉴权请求信息，接收到目标账户所归属的业务系统发送的鉴权码后，进行身份鉴权；

待身份鉴权通过后，从目标账户所归属的业务系统中获取对应所述目标账户保存的属性信息；

将获得的目标账户的属性信息包含的全部参数或者部分参数发往终端，并根据终端的响应判断所述目标账户的属性信息是否通过验证。

可选的，调用目标账户所归属的业务系统对所述目标账户的属性信息进行验证后，进一步包括：

若根据终端的响应确定所述目标账户的属性信息通过验证，则将验证通过的目标账户的属性信息同步到所述业务类型对应的历史操作数据中；

若根据终端的响应确定所述目标账户的属性信息验证失败，判断失败原因，以及依据失败原因更新历史操作数据中相应目标账户的属性信息。

可选的，对所述目标账户的属性信息进行验证后，进一步包括：

将所述业务处理请求提交到目标账户所归属的业务系统，令所述业务系统基于所述业务处理请求对所述目标账户的属性信息进行再次验证；

若根据所述业务系统返回的响应获知验证通过，则确定所述目标账户的属性信息最终通过验证，并将验证通过的目标账户的属性信息更新到所述业务类型对应的历史操作数据中；

若根据所述业务系统返回的响应获知验证失败，则确定所述目标账户的属性信息最终未通过验证，并判断失败原因，依据失败原因更新历史操作数据中相应目标账户的属性信息。

这样，能够及时更新本地用户数据的数据，形成其他业务的校验基础。

一种用户信息的验证装置，应用在后台服务器，包括：

接收单元，用于接收终端发起的基于第一账户的业务处理请求，所述业务处理请求中携带有目标账户的标识；

判断单元，用于确定所述业务处理请求的业务类型，并判断所述业务类型对应的历史操作数据中是否对应所述目标账户的标识保存有所述目标账户的属性信息；

第一处理单元，用于基于所述历史操作数据对所述目标账户的属性信息进行验证；

第二处理单元，用于调用目标账户所归属的业务系统对所述目标账户的属性信息进行验证。

这样通对过用户输入的目标账户的属性信息中的各项参数进行预校验，保证按照用户预期进行业务的实现，提升业务完成的成功率和准确率，进一步降低业务受理的过程中由于业务数据不符导致的资损风险，而且从原来强依赖合作方的服务内容转变为弱依赖，能够降低成本消耗。

可选的，目标账户的属性信息至少包括目标账户的标识、类型、业务状态，目标账户所属用户的身份标识和名称。

可选的，基于所述历史操作数据对所述目标账户的属性信息进行验证时，所述第一处理单元用于：

获取对应所述第一账户保存的历史操作数据，基于获得的历史操作数据对所述目标账户的属性信息进行验证；

或者，

获取对应所述第一账户保存的历史操作数据，以及获取对应指定的其他用户保存的历史操作数据，基于获得的历史操作数据对所述目标账户的属性信息进行验证；

或者，

获取当前系统中对应所有账户保存的历史操作数据，基于获得的历史操作数据对所述目标账户的属性信息进行验证。

可选的，基于所述历史操作数据，对所述目标账户的属性信息进行验证时，所述第一处理单元用于：

从历史操作数据中获取对应所述目标账户保存的属性信息；

根据终端指示，将获得的目标账户的属性信息包含的全部参数或者部分参数发往终端，并根据终端的响应判断所述目标账户的属性信息是否通过验证。

可选的，调用目标账户所归属的业务系统对所述目标账户的属性信息进行验证时，所述第二处理单元用于：

向目标账户所归属的业务系统发送鉴权请求信息，接收到目标账户所归属的业务系统发送的鉴权码后，进行身份鉴权；

待身份鉴权通过后，从目标账户所归属的业务系统中获取对应所述目标账户保存的属性信息；

将获得的目标账户的属性信息包含的全部参数或者部分参数发往终端，并根据终端的响应判断所述目标账户的属性信息是否通过验证。

可选的，调用目标账户所归属的业务系统对所述目标账户的属性信息进行验证后，所述第二处理单元用于进一步用于：

若根据终端的响应确定所述目标账户的属性信息通过验证，则将验证通过的目标账户的属性信息同步到所述业务类型对应的历史操作数据中；

若根据终端的响应确定所述目标账户的属性信息验证失败，判断失败原因，以及依据失败原因更新历史操作数据中相应目标账户的属性信息。

可选的，所述装置进一步包括：

第三处理单元，用于在对所述目标账户的属性信息进行验证时，将所述业务处理请求提交到目标账户所归属的业务系统，令所述业务系统基于所述业务处理请求对所述目标账户的属性信息进行再次验证，以及若根据所述业务系统返回的响应获知验证通过，则确定所述目标账户的属性信息最终通过验证，并将验证通过的目标账户的属性信息更新到所述业务类型对应的历史操作数据中，或者，若根据所述业务系统返回的响应获取知验证失败，则确定所述目标账户的属性信息最终未通过验证，并判断失败原因，依据失败原因更新历史操作数据中相应目标账户的属性信息。

这样，能够及时更新本地用户数据的数据，形成其他业务的校验基础。

附图说明

图1为本申请实施例中用户信息的验证方法流程示意图；

图2为本申请实施例中实际应用场景下用户信息的验证方法流程示意图；

图3为本申请实施例中用户信息的验证装置示意图。

具体实施方式

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

为了保证用户基于第三方支付平台的业务操作可执行且保证成功，本申请实施中提出一种用户信息的验证方法来实现各种业务。一方面通过利用第三方支付平台的其他处理成功的业务数据对当前业务所属用户的卡户关联数据以及卡状态信息进行优化学习，从而在第三方支付平台内部进行预校验，对于校验不通过的数据进行报错，引导用户进行卡号与户名以及卡状态的线下确认；另一面通过调用目标账户所归属的业务方的业务数据对当前业务所属用户的卡户关联数据以及卡状态信息进行优化学习，这样通对过用户输入的目标账户的属性信息中的各项参数进行预校验，保证按照用户预期进行业务的实现，提升业务完成的成功率和准确率，进一步降低业务受理的过程中由于业务数据不符导致的资损风险。

参阅图1所示，本申请实施例中提供一种用户信息的验证方法，应用在后台服务器，具体流程如下：

步骤100：接收终端发起的基于第一账户的业务处理请求，该业务处理请求中携带有目标账户的标识。

例如，账户A在第三方支付平台上发起一个针对目标账户B的进行转账的业务请求，这时账户A在终端的显示页面上选择转账这一业务，并在相关操作页面上输入目标账户的标识ID，转账金额，目标账户所属用户的名称等信息，将该转账业务的业务处理请求发往后台服务器。

步骤101：确定上述业务处理请求的业务类型，并判断该业务类型对应的历史操作数据中是否对应目标账户的标识保存有该目标账户的属性信息；若是，则执行步骤102，否则，执行步骤103。

例如，后台服务器接收到账户A针对目标账户B进行转账这一业务处理请求后，通过后台服务器预设的业务规则进行模型适配，确认该业务处理请求的业务类型为转账，判断转账业务类型对应的历史操作数据中是否对应目标账户B的标识ID保存有该目标账户B的属性信息，其中后台服务器针对不同业务类型设置不同的模型，例如存在转账业务模型、还款业务模型、缴费业务模型等。

具体的，目标账户的属性信息至少包括目标账户的标识、类型、业务状态，目标账户所属用户的身份标识和名称。

步骤102：基于上述历史操作数据对目标账户的属性信息进行验证；

例如，针对账户A向目标账户B转账这一业务，转账业务类型对应的历史操作数据中对应目标账户B的标识ID保存有该目标账户B的属性信息，则基于转账业务类型对应的历史操作数据对目标账户B的属性信息进行验证。

具体的，基于历史操作数据对目标账户的属性信息进行验证，可以通过后台服务器设置为三种情形的任意一种：

第一种情形为：获取对应第一账户保存的历史操作数据，基于获得的历史操作数据对目标账户的属性信息进行验证；

例如：针对账户A向目标账户B转账这一业务，后台服务器可以设置为根据目标账户B保存的历史操作数据对目标账户B的属性信息进行验证。

第二种情形为：获取对应第一账户保存的历史操作数据，以及获取对应指定的其他用户保存的历史操作数据，基于获得的历史操作数据对目标账户的属性信息进行验证；

例如：针对账户A向目标账户B转账这一业务，后台服务器可以将某些账户的历史操作数据设置为可信任的历史操作数据，在这些可信任的历史操作数据中对相应的目标账户的属性信息进行验证，例如，后台服务器将账户1，账户2，…账户100的历史操作数据设置为可信任的历史操作数据，这时获取账户1，账户2，…账户100的历史操作数据为根据目标账户B保存的历史操作数据对目标账户B的属性信息进行验证。

第三种情形为：获取当前系统中对应所有账户保存的历史操作数据，基于获得的历史操作数据对目标账户的属性信息进行验证。

例如，针对账户A向目标账户B转账这一业务，后台服务器可以设置为根据在第三方支付平台上注册的所有账户保存的历史操作数据对目标账户B的属性信息进行验证。

具体的，基于上述历史操作数据，对目标账户的属性信息进行验证，包括：从历史操作数据中获取对应目标账户保存的属性信息；根据终端指示，将获得的目标账户的属性信息包含的全部参数或者部分参数发往终端，并根据终端的响应判断目标账户的属性信息是否通过验证。

步骤103：调用目标账户所归属的业务系统对目标账户的属性信息进行验证。

具体的，调用目标账户所归属的业务系统对该目标账户的属性信息进行验证，包括：向目标账户所归属的业务系统发送鉴权请求信息，接收到目标账户所归属的业务系统发送的鉴权码后，进行身份鉴权；待身份鉴权通过后，从目标账户所归属的业务系统中获取对应该目标账户保存的属性信息；将获得的目标账户的属性信息包含的全部参数或者部分参数发往终端，并根据终端的响应判断该目标账户的属性信息是否通过验证。

例如，针对账户A向目标账户B转账这一业务，基于获得的历史操作数据对目标账户B的属性信息进行验证后，发现历史操作数据中不存在对应目标账户B的属性信息，这时，后台服务器向目标账户B所归属的业务系统(假设为中国银行)发送鉴权请求信息，在接收到中国银行的业务系统发送的鉴权码后，进行身份鉴权；待身份鉴权通过后，从中国银行的业务系统中获取对应目标账户B保存的属性信息；将获得的目标账户B的属性信息包含的全部参数或者部分参数发往终端，并根据终端的响应判断该目标账户B的属性信息是否通过验证。

进一步的，调用目标账户所归属的业务系统对目标账户的属性信息进行验证后，若根据终端的响应确定目标账户的属性信息通过验证，则将验证通过的目标账户的属性信息同步到该业务类型对应的历史操作数据中；若根据终端的响应确定目标账户的属性信息验证失败，判断失败原因，以及依据失败原因更新历史操作数据中相应目标账户的属性信息。

例如，针对账户A向目标账户B转账这一业务，调用目标账户B所归属的业务系统即中国银行对目标账户B的属性信息进行验证后，若根据终端的响应确定目标账户B的属性信息通过验证，目标账户B的属性信息包括目标账户B的标识(62157850111111111111)，目标账户B的类型(信用卡)、目标账户B的业务状态(正常)，目标账户B所属用户的身份标识(132125198908888888)和名称(张某)，则将验证通过的目标账户B的所有属性信息同步到该业务类型对应的历史操作数据中；若根据终端的响应确定目标账户B的属性信息验证失败，判断失败原因，以及依据失败原因更新历史操作数据中相应目标账户的属性信息，假设调用目标账户B所归属的业务系统即中国银行对目标账户B的属性信息进行验证，验证结果为验证失败，失败原因为目标账户B的业务状态即卡的状态异常但是其他的卡户校验通过，即目标账户B所属用户的身份标识(132125198908888888)和名称(张某)与目标账户B的标识即卡号为62157850111111111111的中国银行卡的关联关系是正确的，此时将卡户的关联信息同步到该业务类型(即转账)对应的历史操作数据中，将目标账户B的业务状态即(异常)以黑名单方式保存到历史操作数据中。

进一步的，对目标账户的属性信息进行验证，包括：将业务处理请求提交到目标账户所归属的业务系统，令该业务系统基于该业务处理请求对目标账户的属性信息进行再次验证；若根据该业务系统返回的响应获知验证通过，则确定目标账户的属性信息最终通过验证；若根据该业务系统返回的响应获取验证失败，则确定目标账户的属性信息最终未通过验证，并判断失败原因，依据失败原因更新历史操作数据中相应目标账户的属性信息。

例如，针对账户A向目标账户B转账这一业务，终端将该业务处理请求提交到目标账户B所归属的业务系统即中国银行，此时中国银行的业务系统基于该转账业务处理请求对目标账户B的属性信息进行再次验证；若根据中国银行的业务系统返回的响应获知验证通过，则确定目标账户B的属性信息最终通过验证；若根据中国银行的业务系统返回的响应获取验证失败，则确定目标账户B的属性信息最终未通过验证，并判断失败原因，依据失败原因更新历史操作数据中相应目标账户的属性信息。假设，目标账户B通过中国银行验证后，验证结果为失败，失败原因为卡户校验不通过卡状态为正常，此时检查目标账户的B的业务状态在历史操作数据中的记录是否为正常，若正常则不变，否则更新为正常，并将目标账户的卡户关联信息以黑名单方式保存到本地的历史操作数据中，若任何其他账户包括账户A在此向目标账户B转账时，若输入相同的卡户信息，则直接对此业务请求进行查询和拦截。

参阅图2所示，通过一个具体的应用场景进行上述方法的说明，具体流程如下：

步骤200：接收用户通过终端发起针对目标账户的业务处理请求；

步骤201：后台服务器的自处理系统接收到业务处理请求，针对该业务处理请求进行业务类型适配；

步骤202：判定该业务类型的目标账户在第三方支付平台中是否是存在，若是，则执行步骤206，否则，执行步骤203；

步骤203：进入自学习处理模块，调用目标账户所归属的业务方数据库，对当前业务请求的目标账户进行验证，判断验证是否通过，若是，执行步骤204，否则，执行步骤205；

步骤204：将验证通过的目标账户的属性信息同步到该业务类型对应的历史操作数据中，接着执行步骤207；

步骤205：判断失败原因，依据失败原因更新历史操作数据中相应目标账户的属性信息，接着执行步骤207；

例如，将验证的属性信息按照规则进行过滤，判断失败的原因，若失败原因为卡状态正常并且其他校验失败，则将卡状态正常这一属性信息更新到历史操作数据中，校验失败的属性信息以黑名单方式保存到历史操作数据中；若失败类型为卡户校验通过并且卡状态异常，则将卡状态异常这一属性信息更新到历史操作数据中，并且将目标账户属性信息中的相关卡户信息也更新到历史操作数据中；若失败类型为卡户校验不通过且卡状态异常，则卡状异常这一属性信息更新到历史操作数据中，校验失败的卡户信息以黑名单方式保存到历史操作数据中；根据校验的失败原因，更新失败原因中涉及的目标账户的属性信息到该业务类型对应的历史操作数据中。

步骤206：通过调用本地用户数据库，对当前业务请求的目标账户进行验证，接着执行步骤207；

步骤207：向用户反馈验证结果信息；

步骤208：将上述业务处理请求提交到目标账户的业务系统中；

步骤209：目标账户的业务系统对目标账户的属性信息进行验证，判断验证是否通过，若是，执行步骤210，否则，执行步骤211；

步骤210：将验证通过的目标账户的属性信息更新到历史操作数据；

步骤211：判断失败原因，依据失败原因再次更新历史操作数据中相应目标账户的属性信息。

基于上述技术方案，参阅图3所示，本发明实施例中还提供一种用户信息的验证装置，应用在后台服务器，包括接收单元30，判断单元31，第一处理单元32，第二处理单元33，第三处理单元34，其中：

接收单元30，用于接收终端发起的基于第一账户的业务处理请求，该业务处理请求中携带有目标账户的标识；

判断单元31，用于确定该业务处理请求的业务类型，并判断该业务类型对应的历史操作数据中是否对应该目标账户的标识保存有该目标账户的属性信息；

第一处理单元32，用于基于该历史操作数据对该目标账户的属性信息进行验证；

第二处理单元33，用于调用目标账户所归属的业务系统对该目标账户的属性信息进行验证。

可选的，目标账户的属性信息至少包括目标账户的标识、类型、业务状态，目标账户所属用户的身份标识和名称。

可选的，基于该历史操作数据对该目标账户的属性信息进行验证时，该第一处理单元32用于：

获取对应该第一账户保存的历史操作数据，基于获得的历史操作数据对该目标账户的属性信息进行验证；

或者，

获取对应该第一账户保存的历史操作数据，以及获取对应指定的其他用户保存的历史操作数据，基于获得的历史操作数据对该目标账户的属性信息进行验证；

或者，

获取当前系统中对应所有账户保存的历史操作数据，基于获得的历史操作数据对该目标账户的属性信息进行验证。

可选的，基于该历史操作数据，对该目标账户的属性信息进行验证时，该第一处理单元32用于：

从历史操作数据中获取对应该目标账户保存的属性信息；

根据终端指示，将获得的目标账户的属性信息包含的全部参数或者部分参数发往终端，并根据终端的响应判断该目标账户的属性信息是否通过验证。

可选的，调用目标账户所归属的业务系统对该目标账户的属性信息进行验证时，该第二处理单元33用于：

向目标账户所归属的业务系统发送鉴权请求信息，接收到目标账户所归属的业务系统发送的鉴权码后，进行身份鉴权；

待身份鉴权通过后，从目标账户所归属的业务系统中获取对应该目标账户保存的属性信息；

将获得的目标账户的属性信息包含的全部参数或者部分参数发往终端，并根据终端的响应判断该目标账户的属性信息是否通过验证。

可选的，调用目标账户所归属的业务系统对该目标账户的属性信息进行验证后，该第二处理单元33用于进一步用于：

若根据终端的响应确定该目标账户的属性信息通过验证，则将验证通过的目标账户的属性信息同步到该业务类型对应的历史操作数据中；

若根据终端的响应确定该目标账户的属性信息验证失败，判断失败原因，以及依据失败原因更新历史操作数据中相应目标账户的属性信息。

可选的，该装置进一步包括：

第三处理单元34，用于在对目标账户的属性信息进行验证时，将业务处理请求提交到目标账户所归属的业务系统，令业务系统基于该业务处理请求对该目标账户的属性信息进行再次验证，以及若根据业务系统返回的响应获知验证通过，则确定目标账户的属性信息最终通过验证，并将验证通过的目标账户的属性信息更新到该业务类型对应的历史操作数据中，或者，若根据业务系统返回的响应获取知验证失败，则确定该目标账户的属性信息最终未通过验证，并判断失败原因，依据失败原因更新历史操作数据中相应目标账户的属性信息。

综上所述，本发明实施例中，接收终端发起的基于第一账户的业务处理请求，业务处理请求中携带有目标账户的标识；确定业务处理请求的业务类型，并判断业务类型对应的历史操作数据中是否对应所述目标账户的标识保存有目标账户的属性信息；若是，则基于所述历史操作数据对目标账户的属性信息进行验证；否则，调用目标账户所归属的业务系统对目标账户的属性信息进行验证，这样通对过用户输入的目标账户的属性信息中的各项参数进行预校验，保证按照用户预期进行业务的实现，提升业务完成的成功率和准确率，进一步降低业务受理的过程中由于业务数据不符导致的资损风险，而且从原来强依赖合作方的服务内容转变为弱依赖，能够降低成本消耗。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

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

Claims (14)

1.一种用户信息的验证方法，应用在后台服务器，其特征在于，包括：

接收终端发起的基于第一账户的业务处理请求，所述业务处理请求中携带有目标账户的标识；

确定所述业务处理请求的业务类型，并判断所述业务类型对应的历史操作数据中是否对应所述目标账户的标识保存有所述目标账户的属性信息；

若是，则基于所述历史操作数据对所述目标账户的属性信息进行验证；

否则，调用目标账户所归属的业务系统对所述目标账户的属性信息进行验证。

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

目标账户的属性信息至少包括目标账户的标识、类型、业务状态，目标账户所属用户的身份标识和名称。

3.如权利要求1所述的方法，其特征在于，基于所述历史操作数据对所述目标账户的属性信息进行验证，包括：

获取对应所述第一账户保存的历史操作数据，基于获得的历史操作数据对所述目标账户的属性信息进行验证；

或者，

获取对应所述第一账户保存的历史操作数据，以及获取对应指定的其他用户保存的历史操作数据，基于获得的历史操作数据对所述目标账户的属性信息进行验证；

或者，

获取当前系统中对应所有账户保存的历史操作数据，基于获得的历史操作数据对所述目标账户的属性信息进行验证。

4.如权利要求1、2或3所述的方法，其特征在于，基于所述历史操作数据，对所述目标账户的属性信息进行验证，包括：

从历史操作数据中获取对应所述目标账户保存的属性信息；

根据终端指示，将获得的目标账户的属性信息包含的全部参数或者部分参数发往终端，并根据终端的响应判断所述目标账户的属性信息是否通过验证。

5.如权利要求1、2或3所述的方法，其特征在于，调用目标账户所归属的业务系统对所述目标账户的属性信息进行验证，包括：

向目标账户所归属的业务系统发送鉴权请求信息，接收到目标账户所归属的业务系统发送的鉴权码后，进行身份鉴权；

待身份鉴权通过后，从目标账户所归属的业务系统中获取对应所述目标账户保存的属性信息；

将获得的目标账户的属性信息包含的全部参数或者部分参数发往终端，并根据终端的响应判断所述目标账户的属性信息是否通过验证。

6.如权利要求4或5所述的方法，其特征在于，调用目标账户所归属的业务系统对所述目标账户的属性信息进行验证后，进一步包括：

若根据终端的响应确定所述目标账户的属性信息通过验证，则将验证通过的目标账户的属性信息同步到所述业务类型对应的历史操作数据中；

若根据终端的响应确定所述目标账户的属性信息验证失败，判断失败原因，以及依据失败原因更新历史操作数据中相应目标账户的属性信息。

7.如权利要求4或5所述的方法，其特征在于，对所述目标账户的属性信息进行验证后，进一步包括：

将所述业务处理请求提交到目标账户所归属的业务系统，令所述业务系统基于所述业务处理请求对所述目标账户的属性信息进行再次验证；

若根据所述业务系统返回的响应获知验证通过，则确定所述目标账户的属性信息最终通过验证，并将验证通过的目标账户的属性信息更新到所述业务类型对应的历史操作数据中；

若根据所述业务系统返回的响应获知验证失败，则确定所述目标账户的属性信息最终未通过验证，并判断失败原因，依据失败原因更新历史操作数据中相应目标账户的属性信息。

8.一种用户信息的验证装置，应用在后台服务器，其特征在于，包括：

接收单元，用于接收终端发起的基于第一账户的业务处理请求，所述业务处理请求中携带有目标账户的标识；

判断单元，用于确定所述业务处理请求的业务类型，并判断所述业务类型对应的历史操作数据中是否对应所述目标账户的标识保存有所述目标账户的属性信息；

第一处理单元，用于基于所述历史操作数据对所述目标账户的属性信息进行验证；

第二处理单元，用于调用目标账户所归属的业务系统对所述目标账户的属性信息进行验证。

9.如权利要求8所述的装置，其特征在于，包括：

目标账户的属性信息至少包括目标账户的标识、类型、业务状态，目标账户所属用户的身份标识和名称。

10.如权利要求8所述的装置，其特征在于，基于所述历史操作数据对所述目标账户的属性信息进行验证时，所述第一处理单元用于：

获取对应所述第一账户保存的历史操作数据，基于获得的历史操作数据对所述目标账户的属性信息进行验证；

或者，

获取对应所述第一账户保存的历史操作数据，以及获取对应指定的其他用户保存的历史操作数据，基于获得的历史操作数据对所述目标账户的属性信息进行验证；

或者，

获取当前系统中对应所有账户保存的历史操作数据，基于获得的历史操作数据对所述目标账户的属性信息进行验证。

11.如权利要求8、9或10所述的装置，其特征在于，基于所述历史操作数据，对所述目标账户的属性信息进行验证时，所述第一处理单元用于：

从历史操作数据中获取对应所述目标账户保存的属性信息；

根据终端指示，将获得的目标账户的属性信息包含的全部参数或者部分参数发往终端，并根据终端的响应判断所述目标账户的属性信息是否通过验证。

12.如权利要求8、9或10所述的装置，其特征在于，调用目标账户所归属的业务系统对所述目标账户的属性信息进行验证时，所述第二处理单元用于：

向目标账户所归属的业务系统发送鉴权请求信息，接收到目标账户所归属的业务系统发送的鉴权码后，进行身份鉴权；

待身份鉴权通过后，从目标账户所归属的业务系统中获取对应所述目标账户保存的属性信息；

将获得的目标账户的属性信息包含的全部参数或者部分参数发往终端，并根据终端的响应判断所述目标账户的属性信息是否通过验证。

13.如权利要求11或12所述的装置，其特征在于，调用目标账户所归属的业务系统对所述目标账户的属性信息进行验证后，所述第二处理单元用于进一步用于：

若根据终端的响应确定所述目标账户的属性信息通过验证，则将验证通过的目标账户的属性信息同步到所述业务类型对应的历史操作数据中；

若根据终端的响应确定所述目标账户的属性信息验证失败，判断失败原因，以及依据失败原因更新历史操作数据中相应目标账户的属性信息。

14.如权利要求11或12所述的装置，其特征在于，进一步包括：

第三处理单元，用于在对所述目标账户的属性信息进行验证时，将所述业务处理请求提交到目标账户所归属的业务系统，令所述业务系统基于所述业务处理请求对所述目标账户的属性信息进行再次验证，以及若根据所述业务系统返回的响应获知验证通过，则确定所述目标账户的属性信息最终通过验证，并将验证通过的目标账户的属性信息更新到所述业务类型对应的历史操作数据中，或者，若根据所述业务系统返回的响应获取知验证失败，则确定所述目标账户的属性信息最终未通过验证，并判断失败原因，依据失败原因更新历史操作数据中相应目标账户的属性信息。