信用介质的持有者信息验证方法、装置、设备及存储介质与流程

1.本公开涉及金融信息服务技术领域，尤其涉及一种信用介质的持有者信息验证方法、装置、设备及存储介质。

背景技术：

2.随着信用消费的普及和出国留学、旅游、工作频率越来越高，在的信用卡消费频率也快速增长，因此，支付消费的身份验证的便捷性与安全性十分重要。
3.相关技术中，通常将信用卡绑定手机号码，在检测到待对持有者进行信息验证时，向该手机号码发送验证短信，以基于验证短信的方式进行身份验证，确定信用卡持有者身份。
4.这种方式下，在对信用卡持有者进行身份验证时，容易产生验证短信接收延迟、无法接收验证短信等情况产生，验证稳定性不足，影响信用卡持有者身份验证的成功率，且验证安全性较低，验证方式较为单一。

技术实现要素：

5.本公开提供一种信用介质的持有者信息验证方法、装置、设备及存储介质，用以解决相关技术中持有者信息验证稳定性不足，身份验证效率较差，且验证安全性较低，验证方式较为单一的问题。
6.第一方面，本公开提供一种信用介质的持有者信息验证方法，被第一电子设备执行，包括：获取第二电子设备发送的验证请求，其中，验证请求包括：信用介质信息；根据信用介质信息确定持有者的风险评估值；如果根据风险评估值确定待对持有者进行目标验证，则基于目标验证方式和信用介质信息对持有者信息进行验证处理；其中，目标验证方式是第一验证方式、第二验证方式，以及第三验证方式之中的至少一种，其中，第一验证方式、第二验证方式，以及第三验证方式不相同。
7.第二方面，本公开提供一种信用介质的持有者信息验证装置，被第一电子设备执行，包括：第一获取模块，用于获取第二电子设备发送的验证请求，其中，验证请求包括：信用介质信息；第一确定模块，用于根据信用介质信息确定持有者的风险评估值；第一处理模块，用于在根据风险评估值确定待对持有者进行目标验证时，基于目标验证方式和信用介质信息对持有者信息进行验证处理；其中，目标验证方式是第一验证方式、第二验证方式，以及第三验证方式之中的至少一种，其中，第一验证方式、第二验证方式，以及第三验证方式不相同。
8.第三方面，本公开提供一种信用介质的持有者信息验证装置，被第二电子设备执行，包括：第二获取模块，用于获取信用介质信息；生成模块，用于根据信用介质信息生成验证请求；第二发送模块，用于向第一电子设备发送验证请求。
9.本公开第四方面实施例提出了一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，处理器被配置为执行指令，以实现显示方法。
10.本公开第五方面实施例提出了一种计算机可读存储介质，当计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行显示方法。
11.本公开第六方面实施例提出了一种计算机程序产品，包括计算机程序，其特征在于，计算机程序被处理器执行显示方法。
12.本公开第一方面实施例提供的信用介质的持有者信息验证方法，通过获取第二电子设备发送的验证请求，其中，验证请求包括：信用介质信息，而后根据信用介质信息确定持有者的风险评估值，如果根据风险评估值确定待对持有者进行目标验证，则基于目标验证方式和信用介质信息对持有者信息进行验证处理；其中，目标验证方式是第一验证方式、第二验证方式，以及第三验证方式之中的至少一种，其中，第一验证方式、第二验证方式，以及第三验证方式不相同。由于是在基于目标验证方式和信用介质信息对持有者信息进行验证处理，且目标验证方式是第一验证方式、第二验证方式，以及第三验证方式之中的至少一种。因此，能够使用多种验证方式对信用介质的持有者进行信息验证，提升信息验证方式的多样性，在增强验证方式的可选择性的同时，有效提升持有者信息验证效率与验证准确性，进而增强持有者信息验证的安全性，使得验证场景更加多元化。
附图说明
13.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
14.图1是根据本公开第一实施例示出的信用介质的持有者信息验证方法的流程示意图；
15.图2是根据本公开第一实施例提出的风险评估流程示意图；
16.图3是根据本公开第二实施例示出的信用介质的持有者信息验证方法的流程示意图；
17.图4是根据本公开另一实施例提出的目标验证方式选择流程示意图；
18.图5是根据本公开第三实施例示出的信用介质的持有者信息验证方法的流程示意图；
19.图6是根据本公开第四实施例示出的信用介质的持有者信息验证方法的流程示意图；
20.图7是根据本公开第五实施例示出的信用介质的持有者信息验证方法的流程示意图；
21.图8是根据本公开第六实施例示出的信用介质的持有者信息验证方法的流程示意图；
22.图9是根据本公开第六实施例示出的基于小程序的验证方式流程示意图；
23.图10是根据本公开第六实施例示出的基于业务系统的验证方式流程示意图；
24.图11是本公开一实施例提供的信用介质的持有者信息验证装置的结构示意图；
25.图12是本公开另一实施例提供的信用介质的持有者信息验证装置的结构示意图；
26.图13是本公开一实施例提供的信用介质的持有者信息验证装置的结构示意图；
27.图14是本公开另一实施例提供的信用介质的持有者信息验证装置的结构示意图；
28.图15为本公开实施例提供的电子设备的结构示意图。
29.通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。
具体实施方式
30.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
31.需要说明的是，本公开技术方案中对数据的获取、存储、使用、处理等，其过程均符合国家法律法规的相关规定，且不违背公序良俗。
32.图1是根据本公开第一实施例示出的信用介质的持有者信息验证方法的流程示意图。如图1所示，该信用介质的持有者信息验证方法，被第一电子设备执行，包括：
33.s101：获取第二电子设备发送的验证请求，其中，验证请求包括：信用介质信息。
34.其中，第一电子设备，是信息验证端的电子设备，第一电子设备可以是虚拟设备，或者，也可以为物理设备。
35.本公开实施例中，可以将用于实现持有者信息验证的验证系统与数据处理平台等作为第一电子设备，第一电子设备可以例如为网络银行、云端数据平台、数据服务器等能够执行持有者信息验证的设备，对此不做限制。
36.其中，第二电子设备，是持有者侧用于进行信息录入与展示的电子设备，第二电子设备可以具体例如是智能手机、智能手表等可穿戴设备，或者，也可以是销售点情报管理(point of sales，pos)机、自动取款机(automated teller machine，atm)等能够录入持有者信息的设备，对此不做限制。
37.其中，用于请求进行持有者信息验证的指令信息，可以被称为验证请求，验证请求可以是第二电子设备在获取持有者的交易操作之后，响应于持有者的交易操作生成的请求信息，验证请求中包含信用介质信息。
38.其中，与信用介质相关的数据信息可以被称为信用介质信息，信用介质信息可以具体例如为信用卡号、信用卡编号(card verification value，cvv)有效期、手机号、持有者姓名等信息。
39.也即是说，本公开实施例一种具体的应用场景为，持有者在进行信用介质消费或转账等交易时，在第二电子设备中输入信用介质信息，由第二电子设备基于该信用介质信息生成验证请求，并向第一电子设备发送该验证请求，第一电子设备根据该验证请求内包含的信用介质信息，对持有者进行风险评估、身份验证以及交易授权，本公开实施例下述的描述说明将以该应用场景为例进行具体的解释说明，当然，本公开实施例描述的信用介质的持有者信息验证方法也可以应用于其他任意可能的持有者信息验证场景中，对此不做限制。
40.s102：根据信用介质信息确定持有者的风险评估值。
41.其中，用于表示持有者交易风险的评估量化值，可以被称为风险评估值，该风险评估值可以是具体的数值，或者，也可以是表示风险程度的等级数据，该等级数据可以例如为
低风险、中风险、高风险等风险等级，对此不做限制。
42.本公开的一些实施例中，可以预设风险评估系统，以基于该风险评估系统，根据信用介质信息对持有者进行风险评估，得到风险评估值。
43.举例而言，如图2所示，图2是根据本公开第一实施例提出的风险评估流程示意图，在持有者输入信用介质信息之后，由第一电子设备获取信用介质信息，并将信用介质信息发送至风险评估系统，由风险评估系统根据信用介质信息对持有者进行风险评估处理，生成评估结果，并将评估结果发送至第一电子设备，由第一电子设备根据风险评估结果做出相应处理，若风险评估结果为高风险、中风险、低风险中的任一项，则可以设置风险评估结果为高风险时拒绝交易，在风险评估结果为中风险时待进一步进行验证，在风险评估结果为低风险时直接进行交易，对此不做限制。
44.本公开实施例中，第一电子设备可以解析验证请求，获得信用介质信息，并将信用介质信息发送至预设的风险评估系统中，风险评估系统根据信用介质信息对持有者本次交易进行风险评估，生成风险评估值。
45.另一些实施例中，也可以直接根据验证请求中的信用介质信息，确认该持有者的风险评估值，例如使用人工的风险评估方式，或者使用基于云数据管理的风险评估方式，对此不做限制。
46.也即是说，第一电子设备可以根据信用介质信息确定持有者的风险评估值，而后，基于持有者的风险评估值执行后续对持有者的信息验证步骤，具体可参见后续实施例。
47.s103：如果根据风险评估值确定待对持有者进行目标验证，则基于目标验证方式和信用介质信息对持有者信息进行验证处理；其中，目标验证方式是第一验证方式、第二验证方式，以及第三验证方式之中的至少一种，其中，第一验证方式、第二验证方式，以及第三验证方式不相同。
48.其中，对持有者进行信息验证的方式，可以被称为目标验证方式，目标验证方式包括第一验证方式、第二验证方式，以及第三验证方式之中的至少一种。
49.可以理解的是，为了满足不同场景的验证需求，本公开实施例配置多种目标验证方式，以便于根据多种目标验证方式中选择至少一种进行目标验证处理，以扩大对持有者进行目标验证适用场景范围，进而提升信息验证的准确率，增强信息验证的安全性。
50.优选地，本公开实施例以第一验证方式是基于短消息的验证方式，第二验证方式是基于小程序的验证方式，第三验证方式是基于业务系统的验证方式进行示例。
51.其中，第一验证方式可以是基于短消息的验证方式，该短消息，可以例如为手机短信、手机彩信，或者，也可以是电话语音短消息的验证方式。
52.举例而言，第一电子设备根据信用介质信息中包含的手机号码，向该手机号码的持有人发送手机短信进行验证。
53.其中，第二验证方式可以是基于小程序的验证方式，该小程序可以具体例如为、，以及服务号等，对此不做限制。
54.其中，第三验证方式可以是基于业务系统的验证方式，业务系统可以具体例如为在第二电子设备中安装的业务系统，如手机银行应用程序，或者，电脑端的网页业务系统等，对此不做限制。
55.当然，在本公开的另一些实施例中，第一验证方式、第二验证方式，以及第三验证
方式也可以根据实际情况动态设置，对此不做限制。
56.本公开实施例中，在根据风险评估值确定待对持有者进行目标验证时，可以在第一验证方式、第二验证方式，以及第三验证方式之中，确定目标验证方式，并基于目标验证方式和信用介质信息对持有者信息进行验证处理。
57.可选地，本公开的一些实施例中，根据风险评估值确定待对持有者进行目标验证，可以是获取风险评估相关的第一风险度阈值和第二风险度阈值，其中，第二风险度阈值大于第一风险度阈值，如果风险评估值大于第一风险度阈值，且小于第二风险度阈值，则确定待对持有者进行目标验证，由于是设置第一风险度阈值和第二风险度阈值，在风险评估值大于第一风险度阈值，且小于第二风险度阈值时，确定待对持有者进行目标验证，能够根据风险评估值有效确定信用介质信息所对应的风险情况，并根据风险情况做出相应的处理，保证风险评估管理的系统性，提升持有者的风险评估的准确性，同时有效筛选待进行目标验证的情况，保证信息验证的效率。
58.其中，第一风险度阈值和第二风险度阈值均为预设的风险评估值的门限值，第二风险度阈值大于第一风险度阈值。
59.在风险评估值不大于第一风险度阈值时，也即可以表示持有者的交易风险较低，交易安全性较高，则可以免除验证直接授权后续交易环节。
60.在风险评估值大于或等于第二风险度阈值时，也即可以表示持有者的交易风险较高，交易安全性较低，则可以直接关闭交易。
61.在风险评估值大于第一风险度阈值，且小于第二风险度阈值时，则可以表示持有者的交易风险中等，交易安全性待进一步确定，因此，可以进一步对持有者进行目标验证，以保证交易的安全性与可靠性。
62.本公开的另一些实施例中，根据风险评估值确定待对持有者进行目标验证，也可以是设置多种风险等级，如设置“严重风险”、“高风险”、“中等风险”、“低风险”、“无风险”等多种风险等级，并为风险等级匹配对应的验证方式，在输入风险评估值时，根据风险评估值确定所对应的风险等级，并根据所对应的风险等级确定是否待对持有者进行目标验证。
63.举例而言，在风险等级为严重风险时禁止交易，在风险等级为高风险时要求第一验证方式与第二验证方式均验证成功，在风险等级为中等风险时要求第一验证方式或第二验证方式中的任一项验证成功。在输入风险评估值，确定为中等风险时，可以确定从第一验证方式与第二验证方式中任选一项进行验证。
64.当然，本公开实施例还支持使用多种其他任意可能的实现方式根据风险评估值确定待对持有者进行目标验证，对此不做限制。
65.本实施例中，通过获取第二电子设备发送的验证请求，其中，验证请求包括：信用介质信息，而后根据信用介质信息确定持有者的风险评估值，如果根据风险评估值确定待对持有者进行目标验证，则基于目标验证方式和信用介质信息对持有者信息进行验证处理；其中，目标验证方式是第一验证方式、第二验证方式，以及第三验证方式之中的至少一种，其中，第一验证方式、第二验证方式，以及第三验证方式不相同。由于是在基于目标验证方式和信用介质信息对持有者信息进行验证处理，且目标验证方式是第一验证方式、第二验证方式，以及第三验证方式之中的至少一种。因此，能够使用多种验证方式对信用介质的持有者进行信息验证，提升信息验证方式的多样性，在增强验证方式的可选择性的同时，有
效提升持有者信息验证效率与验证准确性，进而增强持有者信息验证的安全性，使得验证场景更加多元化。
66.图3是根据本公开第二实施例示出的信用介质的持有者信息验证方法的流程示意图。如图3所示，该信用介质的持有者信息验证方法，被第一电子设备执行，包括：
67.s301：获取第二电子设备发送的验证请求，其中，验证请求包括：信用介质信息。
68.s302：根据信用介质信息确定持有者的风险评估值。
69.s301-s302的具体描述可以参见上述实施例，在此不作赘述。
70.s303：如果根据风险评估值确定待对持有者进行目标验证，则确定目标验证方式。
71.本公开实施例中，可以获取持有者操作第二电子设备所生成的操作指令，以根据该操作指令确定目标验证方式，或者，也可以向第二电子设备发送目标验证方式的选择信息，经由持有者对该选择信息的指示，确定目标验证方式，或者，还可以是基于信用介质信息中的相关内容，确定目标验证方式，如持有者的电话号码、持有者的注册信息等，对此不做限制。
72.可选地，本公开的一些实施例中，举例而言，如图4所示，图4是根据本公开另一实施例提出的目标验证方式选择流程示意图，确定目标验证方式，可以是在确定待对持有者进行目标验证之后，查询持有者基于业务系统的注册信息，而后根据持有者信息，确定是否存在持有者基于业务系统的注册信息；如果不存在持有者基于业务系统的注册信息，则从第一验证方式和第二验证方式中选择一种验证方式作为目标验证方式；如果存在持有者基于业务系统的注册信息，则从第一验证方式、第二验证方式，以及第三验证方式中选择一种验证方式作为目标验证方式，由于是基于业务系统的注册信息确定是否将第三验证方式作为目标验证方式的备选项，能够有效提升目标验证方式确认的灵活性，有效避免因未注册业务系统而选择第三验证方式，进而导致的验证失败情况，提升目标验证方式选择的合理性，进而提升验证效果。
73.其中，注册信息，为持有者在业务系统的注册情况，该注册信息可以包括是否注册、注册时间及注册等级等信息，对此不做限制。
74.举例而言，若业务系统为手机银行，则可以查询持有者的信用介质信息中，电话号码是否在手机银行进行登陆注册，则该登陆注册的相关信息，可以被称为注册信息。
75.本公开实施例中，可以预先设置第三验证方式的满足条件，以根据该满足条件确定第三验证方式是否可以作为备选项。
76.一些实施例中，在注册信息指示满足第三验证方式的满足条件(如已完成注册，或者注册时间、注册内容等注册信息达到要求等)时，可以将第三验证方式作为目标验证方式的备选项，从第一验证方式、第二验证方式，以及第三验证方式中选择一种验证方式作为目标验证方式。
77.另一些实施例中，在注册信息指示不满足第三验证方式的满足条件(如未完成注册，或者注册时间、注册内容等注册信息未达到要求等)时，第三验证方式无法作为备选项，则可以直接从第一验证方式与第二验证方式中选择一种验证方式作为目标验证方式。
78.s304：根据信用介质信息，生成待验证订单信息。
79.其中，信用介质持有者的信息验证任务可以被称为待验证订单，可以由第一电子设备生成待验证订单，待验证订单中包含的信息，可以被称为待验证订单信息。
80.待验证订单信息中可以包含信用介质号、cvv有效期、手机号、持有者姓名等信用介质信息，也可以包含对持有者进行信息验证所需信息，如持有者的短消息验证的信息、业务系统中包含的验证相关信息等信息，对此不做限制。
81.本公开实施例中，可以根据目标验证方式结合信用介质信息，生成待验证订单信息。举例而言，在目标验证方式为基于短消息的验证方式时，可以由第二电子设备向第一电子设备发送验证的短消息，并将该短消息中所具有的相关信息与信用介质信息结合生成待验证订单信息。
82.在待验证订单信息中，还可以包含验证等待时间、验证回复信息等信息，以便于对验证过程进行管理，提升验证过程的安全性与稳定性。
83.s305：根据目标验证方式，确定与待验证订单信息所对应发送方式。
84.本公开实施例中，待验证订单所对应的发送方式可以与目标验证方式相对应，例如在目标验证方式为基于短消息的验证方式时，发送方式可以选择基于短消息的发送方式，对此不做限制。
85.s306：根据所对应发送方式将待验证订单信息发送至第二电子设备，其中，待验证订单信息用于对持有者信息进行验证处理。
86.本公开实施例中，可以根据验证方式，将待验证订单信息发送至第二电子设备，而后根据第二电子设备回复的持有者信息，对待验证订单信息进行验证处理。
87.其中，持有者信息，为第二电子设备在信息验证过程中获取的持有者相关的信息，如持有者的验证码信息、指纹信息、密码信息、面部识别信息等，可以理解的是，本公开实施例在获取持有者信息与信用介质信息等相关信息时，均是在经由持有者同意后获取，其获取过程符合相关法律法规，且不违背公序良俗。
88.本公开实施例中，可以将持有者信息与第一电子设备实时生成的相关信息进行对比处理，以完成对持有者的信息验证，生成验证结果。
89.举例而言，第一电子设备发送验证码(该验证码为实时生成的，具有一定的有效期限)至持有者的电话号码，则在接收持有者信息时解析得到的验证码，并与第一电子设备所发送验证码进行比较，如果相同，则表示验证成功，否则验证失败。
90.还可以例如，在检测到持有者的指纹信息、面部信息、密码信息等信息之后，与第一电子设备中预存的相关信息进行比较，以完成对持有者的信息验证，生成验证结果。
91.本实施例中，由于是在基于目标验证方式和信用介质信息对持有者信息进行验证处理，且目标验证方式是第一验证方式、第二验证方式，以及第三验证方式之中的至少一种。因此，能够使用多种验证方式对信用介质的持有者进行信息验证，提升信息验证方式的多样性，在增强验证方式的可选择性的同时，有效提升持有者信息验证效率与验证准确性，进而增强持有者信息验证的安全性，使得验证场景更加多元化。由于是基于业务系统的注册信息确定是否将第三验证方式作为目标验证方式的备选项，能够有效提升目标验证方式确认的灵活性，有效避免因未注册业务系统而选择第三验证方式，进而导致的验证失败情况，提升目标验证方式选择的合理性，进而提升验证效果。由于是根据所对应发送方式将待验证订单信息发送至第二电子设备，以用于对持有者信息进行验证处理，能够选择合适的发送方式向持有者提醒验证，并准确获取持有者的持有者信息，以便于根据持有者信息生成验证结果，从而有效提升验证结果生成的便捷性与准确性。
92.图5是根据本公开第三实施例示出的信用介质的持有者信息验证方法的流程示意图。如图5所示，该信用介质的持有者信息验证方法，被第一电子设备执行，包括：
93.s501：获取第二电子设备发送的验证请求，其中，验证请求包括：信用介质信息。
94.s502：根据信用介质信息确定持有者的风险评估值。
95.s503：如果根据风险评估值确定待对持有者进行目标验证，则确定目标验证方式。
96.s504：根据信用介质信息，生成待验证订单信息。
97.s505：根据目标验证方式，确定与待验证订单信息所对应发送方式。
98.s506：根据所对应发送方式将待验证订单信息发送至第二电子设备，其中，待验证订单信息用于对持有者信息进行验证处理。
99.s501-s506的具体描述可以参见上述实施例，在此不作赘述。
100.s507：接收第二电子设备发送的验证数据信息，其中，验证数据信息是第二电子设备基于待验证订单所获取的数据信息。
101.其中，第二电子设备基于待验证订单所收集的，用于进行信息验证的数据信息，可以被称为验证数据信息。
102.本公开实施例中的验证数据信息可以为第二电子设备收集到的持有者的操作信息，如持有者对第二电子设备按键操作生成的验证码信息、密码信息等，或者，还可以例如为持有者面对第二电子设备摄像头时做出的动作信息、持有者的指纹信息等信息，均可以被称为验证数据信息，对此不做限制。
103.本公开实施例中，可以接收第二电子设备发送的验证数据信息，以便于后续对验证数据信息的处理。
104.s508：根据验证数据信息，确定持有者信息。
105.一些实施例中，可以对验证数据信息进行数据解析处理，以从验证数据信息中提取得到持有者信息。
106.另一些实施例中，还可以设置数据提取模型，输入验证数据信息，使用关键词识别的方式进行数据提取，确定持有者信息。
107.当然，本公开实施例还支持使用多种给其他任意可能的实现方式根据验证数据信息，确定持有者信息，如对验证数据信息进行数据预处理，对此不做限制。
108.s509：基于目标验证方式指示的验证检测方式，对持有者信息进行验证处理，得到验证结果。
109.其中，验证结果，可以具体例如为“验证成功”与“验证失败”等表示验证状态的信息，或者，还可以对验证结果进行量化处理，并将量化后的结果信息作为验证结果，或者，还可以使用文档、图表等多种形式记录信息验证情况，并将其作为验证结果，对此不做限制。
110.一些实施例中，在目标验证方式为第一验证方式时，目标验证方式所指示的验证检测方式可以为基于短消息的验证方式，也即可以使用短消息对持有者信息进行验证处理，得到验证结果。
111.另一些实施例中，在目标验证方式为第二验证方式时，目标验证方式所指示的验证检测方式可以为基于小程序的验证方式，也即可以使用小程序、等对持有者信息进行验证处理，得到验证结果。
112.另一些实施例中，在目标验证方式为第三验证方式时，目标验证方式所指示的验
证检测方式可以为基于业务系统的验证方式，也即可以对输入至业务系统的持有者信息进行验证处理，得到验证结果。
113.s510：将待验证订单信息由处于第一状态切换至处于第二状态，其中，第一状态与第二状态不相同。
114.其中，第一状态与第二状态均为待验证订单信息的状态，第一状态可以用于表示待验证订单信息未处理，或者待处理的状态，第二状态可以用于表示待验证订单信息已处理的状态，对此不做限制。
115.本公开实施例中，在对持有者信息进行验证处理之后，可以切换待验证订单信息的状态，将待验证订单信息由处于第一状态切换至处于第二状态，以便于在面对多个待验证订单时，能够有效保证处理的条理性，避免重复验证，以提升验证效率。
116.s511：将验证结果发送至第二电子设备。
117.本公开实施例中，在生成验证结果之后，可以将验证结果直接发送至第二电子设备，在发送至第二电子设备的过程中，可以直接基于目标验证方式发送至第二电子设备，或者，也可以查询第二电子设备所生成的发送指令，以基于该发送指令选择发送方式，对此不做限制。
118.本实施例中，由于是在基于目标验证方式和信用介质信息对持有者信息进行验证处理，且目标验证方式是第一验证方式、第二验证方式，以及第三验证方式之中的至少一种。因此，能够使用多种验证方式对信用介质的持有者进行信息验证，提升信息验证方式的多样性，在增强验证方式的可选择性的同时，有效提升持有者信息验证效率与验证准确性，进而增强持有者信息验证的安全性，使得验证场景更加多元化。由于是基于业务系统的注册信息确定是否将第三验证方式作为目标验证方式的备选项，能够有效提升目标验证方式确认的灵活性，有效避免因未注册业务系统而选择第三验证方式，进而导致的验证失败情况，提升目标验证方式选择的合理性，进而提升验证效果。由于是根据所对应发送方式将待验证订单信息发送至第二电子设备，以用于对持有者信息进行验证处理，能够选择合适的发送方式向持有者提醒验证，并准确获取持有者的持有者信息，以便于根据持有者信息生成验证结果，从而有效提升验证结果生成的便捷性与准确性。由于是基于目标验证方式指示的验证检测方式，对持有者信息进行验证处理，得到验证结果；并将验证结果发送至第二电子设备，能够保证验证结果获取的准确性，增强验证效果。由于是将待验证订单信息由处于第一状态切换至处于第二状态，能够有效保证信息验证处理的条理性，避免重复验证，以提升验证效率。
119.图6是根据本公开第四实施例示出的信用介质的持有者信息验证方法的流程示意图。如图6所示，该信用介质的持有者信息验证方法，被第二电子设备执行，包括：
120.s601：获取信用介质信息。
121.本公开实施例中，可以响应于持有者对第二电子设备的操作，获取信用介质信息。一些实施例中，信用介质信息可以预先保存在云端存储装置中，第二电子设备响用于持有者的操作，从云端存储装置中获取信用介质信息。
122.另一些实施例中，也可以获取由持有者直接编辑生成的信用介质信息，当然，本公开还支持使用多种其他任意可能的实现方式获取信用介质信息，对此不做限制。
123.举例而言，在检测到持有者进行交易时，在第二电子设备的交易界面中弹出信用
介质信息的获取指令，并由持有者根据该指令向第二电子设备输入信用介质信息。
124.s602：根据信用介质信息生成验证请求。
125.在获取信用介质信息之后，第二电子设备可以对信用介质信息中的数据进行解析，生成验证请求，如可以解析信用介质信息，得到信用介质号、手机号、cvv有效期等信息，以根据信用介质信息，得到信用介质号、手机号、cvv有效期等信息，生成验证请求。
126.举例而言，可以根据信用介质号及持有者姓名生成“持有者xxx请求对信用介质号为123456的信用介质进行信息验证”的请求信息，则该条请求信息可以作为验证请求。
127.s603：向第一电子设备发送验证请求。
128.本公开实施例中，在确定验证请求之后，可以使用多种方式向第一电子设备发送验证请求。
129.一些实施例中，第一电子设备与第二电子设备之间可以搭建信息传输接口，以基于该信息传输接口直接传输验证请求。
130.另一些实施例中，也可以设置管理平台从第二电子设备中获取验证请求，在管理平台中对验证请求进行整理，并将整理后的验证请求发送至第一电子设备。
131.另一些实施例中，也可以由第一电子设备向第二电子设备发送验证请求获取指令，第二电子设备响应于该验证请求获取指令，生成验证请求，向第一电子设备发送验证请求。
132.当然，本公开还支持使用多种其他任意可能的实现方式向第一电子设备发送验证请求，如基于短消息发送验证请求，或者基于业务系统发送验证请求等，对此不做限制。
133.本实施例中，通过获取信用介质信息，根据信用介质信息生成验证请求，向第一电子设备发送验证请求，由于是使用验证请求的方式向第一电子设备请求进行目标验证，该验证请求可以基于多种方式发送至第一电子设备，能够有效提升验证请求的处理效率，增强验证请求处理的可靠性，进而增强信息验证的效率与效果。
134.图7是根据本公开第五实施例示出的信用介质的持有者信息验证方法的流程示意图。如图7所示，该信用介质的持有者信息验证方法，被第二电子设备执行，包括：
135.s701：获取信用介质信息。
136.s702：根据信用介质信息生成验证请求。
137.s703：向第一电子设备发送验证请求。
138.s701-s703的具体描述可以参见上述实施例，在此不作赘述。
139.s704：接收第一电子设备发送的待验证订单信息，其中，待验证订单信息用于对持有者信息进行验证处理。
140.本公开实施例中，在经过第一电子设备确认待对持有者进行目标验证之后，第一电子设备可以生成待验证订单信息，并发送至第二电子设备，第二电子设备接收第一电子设备发送的待验证订单信息。
141.本公开实施例中，第二电子设备可以根据目标验证方式接收第一电子设备发送的待验证订单信息，如目标验证方式为基于短消息的验证方式时，则第二电子设备可以从短消息中接收待验证订单信息，还可以例如目标验证方式为基于业务系统的验证方式，则第二电子设备可以从业务系统中接收待验证订单信息，对此不做限制。
142.s705：根据待验证订单信息，获取验证数据信息。
143.本公开实施例中，可以直接将待验证订单信息通过第二电子设备展示至持有者，以获取持有者基于待验证订单信息输入的验证数据信息。
144.由于第二电子设备可以基于多种方式接收待验证订单信息，则验证数据信息也可以基于对应的方式获取。
145.举例而言，如果第二电子设备从短消息中接收待验证订单信息，则可以设置持有者直接通过短消息编辑验证数据信息，以实现获取验证数据信息。
146.s706：将验证数据信息发送至第一电子设备。
147.本公开实施例中，可以使用目标验证方式将验证数据信息发送至第一电子设备，举例而言，若目标验证方式为基于业务系统的验证方式，则可以根据业务系统(如手机银行)将验证数据信息发送至第一电子设备，如果目标验证方式为基于小程序的验证方式，则可以根据小程序获取验证数据信息，并将验证数据信息发送至第一电子设备，对此不做限制。
148.s707：接收第一电子设备发送的验证结果。
149.本公开实施例中，在第一电子设备生成验证结果之后，会将验证结果发送至第二电子设备，则第二电子设备可以根据第一电子设备对验证结果的发送方式，接收第一电子设备发送的验证结果。
150.一些实施例中，第一电子设备可以使用目标验证方式发送验证结果，则第二电子设备也可以基于目标验证方式接收验证结果。
151.另一些实施例中，也可以确认持有者对验证结果发送方式的选择指令，以基于该选择指令确定验证结果的发送方式，并进一步确定第二电子设备接收验证结果的方式，对此不做限制。
152.s708：展示验证结果。
153.本公开实施例中，可以根据目标验证方式展示验证结果，如目标验证方式为基于短消息的验证方式时，可以由第一电子设备向第二电子设备发送包含验证结果的短消息，在目标验证方式为基于小程序的验证方式时，可以由第二电子设备中的小程序展示含有验证结果的界面，在目标验证方式为基于业务系统的验证方式时，可以由业务系统展示验证结果，对此不做限制。
154.举例而言，若目标验证方式为基于业务系统的验证方式时，该业务系统为手机银行时，可以在手机银行中设置验证结果查询界面，持有者可以在该界面中查询验证结果，或者，也可以在第二电子设备获取验证结果之后，由手机银行在第二电子设备中自动弹出包含验证结果的界面，对此不做限制。
155.本实施例中，由于是使用验证请求的方式向第一电子设备请求进行目标验证，该验证请求可以基于多种方式发送至第一电子设备，能够有效提升验证请求的处理效率，增强验证请求处理的可靠性，进而增强信息验证的效率与效果。由于是接收第一电子设备发送的待验证订单信息，能够及时获取待验证订单信息，保证第二电子设备能够更为快捷地接收待验证订单信息，提升信息验证效率。由于是根据待验证订单信息，及时获取验证数据信息，并及时将验证数据信息发送至第一电子设备，能够快速对待验证订单进行处理，并在获取验证数据信息有效发送至第一电子设备，提升待验证订单的处理效率。由于是接收第一电子设备发送的验证结果，并展示验证结果，能够在第一电子设备中及时向持有者展示
验证结果，以便于持有者及时获取验证结果，并及时根据验证结果进行后续操作，实现信息验证的便捷展示。
156.图8是根据本公开第六实施例示出的信用介质的持有者信息验证方法的流程示意图，如图8所示，在获取持有者输入的信用介质信息之后，对持有者进行风险评估，以确定是否对持有者进行目标验证，如果是，则确定目标验证方式，并基于第一验证方式、第二验证方式，以及第三验证方式之中的至少一种对持有者信息进行验证处理，得到验证结果，并根据验证结果进行后续授权交易或者交易失败的操作，如果否，则直接根据风险评估值进行后续授权交易或者交易失败的操作。
157.图9是根据本公开第六实施例示出的基于小程序的验证方式流程示意图，如图9所示，在确定待对持有者进行目标验证，并确定持有者选择使用小程序进行目标验证之后，可以由第一电子设备生成待验证订单信息，并将待验证订单信息发送至小程序，而后小程序将待验证订单信息推送至第二电子设备，持有者在第二电子设备中登录小程序，并在小程序中对待验证订单信息进行处理，生成验证数据信息，并将验证数据信息发送至第一电子设备，而后第一电子设备根据验证数据信息得到验证结果，并将验证结果反馈至持有者，持有者在得知验证结果之后，进行后续操作。
158.图10是根据本公开第六实施例示出的基于业务系统的验证方式流程示意图，如图10所示，在确定待对持有者进行目标验证，并确定持有者选择使用业务系统进行目标验证之后，可以由第一电子设备生成待验证订单信息，并将待验证订单信息发送至业务系统，而后在业务系统中展示待验证订单信息，持有者在第二电子设备中登录业务系统，并在业务系统中查询待验证订单信息，对待验证订单信息进行处理，生成验证数据信息，并将验证数据信息发送至第一电子设备，而后第一电子设备根据验证数据信息得到验证结果，并将验证结果反馈至持有者，持有者在得知验证结果之后，进行后续操作。
159.本实施例中，由于是使用基于第一验证方式、第二验证方式，以及第三验证方式之中的至少一种对持有者信息进行验证处理，能够有效提升验证请求的处理效率，增强验证请求处理的可靠性，进而增强信息验证的效率与效果。
160.图11是本公开一实施例提供的信用介质的持有者信息验证装置的结构示意图。如图11所示，该信用介质的持有者信息验证装置110，被第一电子设备执行，包括：
161.第一获取模块1101，用于获取第二电子设备发送的验证请求，其中，验证请求包括：信用介质信息；
162.第一确定模块1102，用于根据信用介质信息确定持有者的风险评估值；
163.第一处理模块1103，用于在根据风险评估值确定待对持有者进行目标验证时，基于目标验证方式和信用介质信息对持有者信息进行验证处理；其中，目标验证方式是第一验证方式、第二验证方式，以及第三验证方式之中的至少一种，其中，第一验证方式、第二验证方式，以及第三验证方式不相同。
164.在本公开的一些实施例中，如图12所示，图12是本公开另一实施例提供的信用介质的持有者信息验证装置的结构示意图，其中，第一验证方式是基于短消息的验证方式，第二验证方式是基于小程序的验证方式，第三验证方式是基于业务系统的验证方式。
165.在本公开的一些实施例中，如图12所示，第一处理模块1103，具体用于：
166.根据信用介质信息，生成待验证订单信息；
167.根据目标验证方式，确定与待验证订单信息所对应发送方式；
168.根据所对应发送方式将待验证订单信息发送至第二电子设备，其中，待验证订单信息用于对持有者信息进行验证处理。
169.在本公开的一些实施例中，如图12所示，还包括：
170.第二确定模块1104，用于在基于目标验证方式和信用介质信息对持有者信息进行验证处理之前，确定目标验证方式。
171.在本公开的一些实施例中，如图12所示，第二确定模块1104，具体用于：
172.根据持有者信息，确定是否存在持有者基于业务系统的注册信息；
173.在不存在持有者基于业务系统的注册信息时，从第一验证方式和第二验证方式中选择一种验证方式作为目标验证方式；
174.在存在持有者基于业务系统的注册信息时，从第一验证方式、第二验证方式，以及第三验证方式中选择一种验证方式作为目标验证方式。
175.在本公开的一些实施例中，如图12所示，还包括：
176.第一接收模块1105，用于在根据所对应发送方式将待验证订单信息发送至第二电子设备之后，接收第二电子设备发送的验证数据信息，其中，验证数据信息是第二电子设备基于待验证订单所获取的数据信息；
177.第三确定模块1106，用于根据验证数据信息，确定持有者信息；
178.第二处理模块1107，用于基于目标验证方式指示的验证检测方式，对持有者信息进行验证处理，得到验证结果；
179.第一发送模块1108，用于将验证结果发送至第二电子设备。
180.在本公开的一些实施例中，如图12所示，待验证订单信息处于第一状态，还包括：
181.切换模块1109，用于在基于目标验证方式指示的验证检测方式，对持有者信息进行验证处理，得到验证结果之后，将待验证订单信息由处于第一状态切换至处于第二状态，其中，第一状态与第二状态不相同。
182.在本公开的一些实施例中，如图12所示，第一处理模块1103，具体用于：
183.获取风险评估相关的第一风险度阈值和第二风险度阈值，其中，第二风险度阈值大于第一风险度阈值；
184.在风险评估值大于第一风险度阈值，且小于第二风险度阈值时，确定待对持有者进行目标验证。
185.本实施例中，通过获取第二电子设备发送的验证请求，其中，验证请求包括：信用介质信息，而后根据信用介质信息确定持有者的风险评估值，如果根据风险评估值确定待对持有者进行目标验证，则基于目标验证方式和信用介质信息对持有者信息进行验证处理；其中，目标验证方式是第一验证方式、第二验证方式，以及第三验证方式之中的至少一种，其中，第一验证方式、第二验证方式，以及第三验证方式不相同。由于是在基于目标验证方式和信用介质信息对持有者信息进行验证处理，且目标验证方式是第一验证方式、第二验证方式，以及第三验证方式之中的至少一种。因此，能够使用多种验证方式对信用介质的持有者进行信息验证，提升信息验证方式的多样性，在增强验证方式的可选择性的同时，有效提升持有者信息验证效率与验证准确性，进而增强持有者信息验证的安全性，使得验证场景更加多元化。
186.图13是本公开一实施例提供的信用介质的持有者信息验证装置的结构示意图。如图13所示，该信用介质的持有者信息验证装置130，被第二电子设备执行，包括：
187.第二获取模块1301，用于获取信用介质信息；
188.生成模块1302，用于根据信用介质信息生成验证请求；
189.第二发送模块1303，用于向第一电子设备发送验证请求。
190.在本公开的一些实施例中，如图14所示，图14是本公开另一实施例提供的信用介质的持有者信息验证装置的结构示意图，装置还包括：
191.第二接收模块1304，用于接收第一电子设备发送的待验证订单信息，其中，待验证订单信息用于对持有者信息进行验证处理。
192.在本公开的一些实施例中，如图14所示，还包括：
193.第三获取模块1305，用于在接收第一电子设备发送的待验证订单信息之后，根据待验证订单信息，获取验证数据信息；
194.第三发送模块，用于将验证数据信息发送至第一电子设备。
195.在本公开的一些实施例中，如图14所示，还包括：
196.第三接收模块1306，用于接收第一电子设备发送的验证结果；
197.展示模块1307，用于展示验证结果。
198.本实施例中，通过获取信用介质信息，根据信用介质信息生成验证请求，向第一电子设备发送验证请求，由于是使用验证请求的方式向第一电子设备请求进行目标验证，该验证请求可以基于多种方式发送至第一电子设备，能够有效提升验证请求的处理效率，增强验证请求处理的可靠性，进而增强信息验证的效率与效果。
199.需要说明的是，应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。例如，第一处理模块1103可以为单独设立的处理元件，也可以集成在上述装置的某一个芯片中实现，此外，也可以以程序代码的形式存储于上述装置的存储器中，由上述装置的某一个处理元件调用并执行以上第一处理模块1103的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。
200.图15为本公开实施例提供的电子设备的结构示意图。如图15所示，该电子设备可以包括：收发器151、处理器152、存储器153。
201.处理器152执行存储器存储的计算机执行指令，使得处理器152执行上述实施例中的方案。处理器152可以是通用处理器，包括中央处理器cpu、网络处理器(network processor，np)等；还可以是数字信号处理器dsp、专用集成电路asic、现场可编程门阵列fpga或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
202.存储器153通过系统总线与处理器152连接并完成相互间的通信，存储器153用于存储计算机程序指令。
203.收发器151可以用于获取待运行任务和待运行任务的配置信息。
204.系统总线可以是外设部件互连标准(peripheral component interconnect，pci)总线或扩展工业标准结构(extended industry standard architecture，eisa)总线等。系统总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。收发器用于实现数据库访问装置与其他计算机(例如客户端、读写库和只读库)之间的通信。存储器可能包含随机存取存储器(random access memory，ram)，也可能还包括非易失性存储器(non-volatile memory)。
205.本公开实施例提供的电子设备，可以是上述实施例的终端设备。
206.本公开实施例还提供一种运行指令的芯片，该芯片用于执行上述实施例中信用介质的持有者信息验证方法的技术方案。
207.本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当该计算机指令在计算机上运行时，使得计算机执行上述实施例信用介质的持有者信息验证方法的技术方案。
208.本公开实施例还提供一种计算机程序产品，该计算机程序产品包括计算机程序，其存储在计算机可读存储介质中，至少一个处理器可以从计算机可读存储介质读取计算机程序，至少一个处理器执行计算机程序时可实现上述实施例中信用介质的持有者信息验证方法的技术方案。
209.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求书指出。
210.应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求书来限制。

技术特征：

1.一种信用介质的持有者信息验证方法，其特征在于，被第一电子设备执行，所述方法包括：获取第二电子设备发送的验证请求，其中，所述验证请求包括：信用介质信息；根据所述信用介质信息确定持有者的风险评估值；如果根据所述风险评估值确定待对所述持有者进行目标验证，则基于目标验证方式和所述信用介质信息对持有者信息进行验证处理；其中，所述目标验证方式是第一验证方式、第二验证方式，以及第三验证方式之中的至少一种，其中，所述第一验证方式、所述第二验证方式，以及所述第三验证方式不相同。2.如权利要求1所述的方法，其特征在于，所述第一验证方式是基于短消息的验证方式，所述第二验证方式是基于小程序的验证方式，所述第三验证方式是基于业务系统的验证方式。3.如权利要求2所述的方法，其特征在于，所述基于目标验证方式和所述信用介质信息对持有者信息进行验证处理，包括：根据所述信用介质信息，生成待验证订单信息；根据所述目标验证方式，确定与所述待验证订单信息所对应发送方式；根据所述所对应发送方式将所述待验证订单信息发送至所述第二电子设备，其中，所述待验证订单信息用于对所述持有者信息进行验证处理。4.如权利要求3所述的方法，其特征在于，在所述基于目标验证方式和所述信用介质信息对持有者信息进行验证处理之前，还包括：确定所述目标验证方式。5.如权利要求4所述的方法，其特征在于，所述确定所述目标验证方式，包括：根据所述持有者信息，确定是否存在所述持有者基于所述业务系统的注册信息；如果不存在所述持有者基于所述业务系统的注册信息，则从所述第一验证方式和所述第二验证方式中选择一种验证方式作为所述目标验证方式；如果存在所述持有者基于所述业务系统的注册信息，则从所述第一验证方式、所述第二验证方式，以及所述第三验证方式中选择一种验证方式作为所述目标验证方式。6.如权利要求3所述的方法，其特征在于，在所述根据所述所对应发送方式将所述待验证订单信息发送至所述第二电子设备之后，所述方法还包括：接收所述第二电子设备发送的验证数据信息，其中，所述验证数据信息是第二电子设备基于所述待验证订单所获取的数据信息；根据所述验证数据信息，确定所述持有者信息；基于所述目标验证方式指示的验证检测方式，对所述持有者信息进行验证处理，得到验证结果；将所述验证结果发送至所述第二电子设备。7.如权利要求6所述的方法，其特征在于，所述待验证订单信息处于第一状态，在所述基于所述目标验证方式指示的验证检测方式，对所述持有者信息进行验证处理，得到验证结果之后，还包括：将所述待验证订单信息由处于第一状态切换至处于第二状态，其中，所述第一状态与所述第二状态不相同。
8.如权利要求1所述的方法，其特征在于，所述根据所述风险评估值确定待对所述持有者进行目标验证，包括：获取风险评估相关的第一风险度阈值和第二风险度阈值，其中，所述第二风险度阈值大于所述第一风险度阈值；如果所述风险评估值大于所述第一风险度阈值，且小于所述第二风险度阈值，则确定待对所述持有者进行目标验证。9.一种信用介质的持有者信息验证装置，其特征在于，被第一电子设备执行，所述装置包括：第一获取模块，用于获取第二电子设备发送的验证请求，其中，所述验证请求包括：信用介质信息；第一确定模块，用于根据所述信用介质信息确定持有者的风险评估值；第一处理模块，用于在根据所述风险评估值确定待对所述持有者进行目标验证时，基于目标验证方式和所述信用介质信息对持有者信息进行验证处理；其中，所述目标验证方式是第一验证方式、第二验证方式，以及第三验证方式之中的至少一种，其中，所述第一验证方式、所述第二验证方式，以及所述第三验证方式不相同。10.如权利要求9所述的装置，其特征在于，所述第一验证方式是基于短消息的验证方式，所述第二验证方式是基于小程序的验证方式，所述第三验证方式是基于业务系统的验证方式。11.如权利要求10所述的装置，其特征在于，所述第一处理模块，具体用于：根据所述信用介质信息，生成待验证订单信息；根据所述目标验证方式，确定与所述待验证订单信息所对应发送方式；根据所述所对应发送方式将所述待验证订单信息发送至所述第二电子设备，其中，所述待验证订单信息用于对所述持有者信息进行验证处理。12.如权利要求11所述的装置，其特征在于，还包括：第二确定模块，用于在所述基于目标验证方式和所述信用介质信息对持有者信息进行验证处理之前，确定所述目标验证方式。13.如权利要求12所述的装置，其特征在于，所述第二确定模块，具体用于：根据所述持有者信息，确定是否存在所述持有者基于所述业务系统的注册信息；在不存在所述持有者基于所述业务系统的注册信息时，从所述第一验证方式和所述第二验证方式中选择一种验证方式作为所述目标验证方式；在存在所述持有者基于所述业务系统的注册信息时，从所述第一验证方式、所述第二验证方式，以及所述第三验证方式中选择一种验证方式作为所述目标验证方式。14.如权利要求11所述的装置，其特征在于，还包括：第一接收模块，用于在所述根据所述所对应发送方式将所述待验证订单信息发送至所述第二电子设备之后，接收所述第二电子设备发送的验证数据信息，其中，所述验证数据信息是第二电子设备基于所述待验证订单所获取的数据信息；第三确定模块，用于根据所述验证数据信息，确定所述持有者信息；第二处理模块，用于基于所述目标验证方式指示的验证检测方式，对所述持有者信息进行验证处理，得到验证结果；
第一发送模块，用于将所述验证结果发送至所述第二电子设备。15.如权利要求14所述的装置，其特征在于，所述待验证订单信息处于第一状态，还包括：切换模块，用于在所述基于所述目标验证方式指示的验证检测方式，对所述持有者信息进行验证处理，得到验证结果之后，将所述待验证订单信息由处于第一状态切换至处于第二状态，其中，所述第一状态与所述第二状态不相同。16.如权利要求10所述的装置，其特征在于，所述第一处理模块，具体用于：获取风险评估相关的第一风险度阈值和第二风险度阈值，其中，所述第二风险度阈值大于所述第一风险度阈值；在所述风险评估值大于所述第一风险度阈值，且小于所述第二风险度阈值时，确定待对所述持有者进行目标验证。17.一种电子设备，其特征在于，包括：处理器，以及与所述处理器通信连接的存储器；所述存储器存储计算机执行指令；所述处理器执行所述存储器存储的计算机执行指令，以实现如权利要求1-8中任一项所述的方法。18.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1-8中任一项所述的方法。19.一种计算机程序产品，其特征在于，包括计算机程序，该计算机程序被处理器执行时实现如权利要求1-8中任一项所述的方法。

技术总结

本公开提供一种信用介质的持有者信息验证方法、装置、设备及存储介质。涉及金融信息服务技术领域。该方法包括：获取第二电子设备发送的验证请求，其中，验证请求包括：信用介质信息；根据信用介质信息确定持有者的风险评估值；如果根据风险评估值确定待对持有者进行目标验证，则基于目标验证方式和信用介质信息对持有者信息进行验证处理；其中，目标验证方式是第一验证方式、第二验证方式，以及第三验证方式之中的至少一种，其中，第一验证方式、第二验证方式，以及第三验证方式不相同。本公开能够提升信息验证方式的多样性，提升持有者信息验证效率与验证准确性，增强持有者信息验证的安全性。安全性。安全性。