CN115983845A - 基于用户身份的支付方法及装置 - Google Patents

Abstract

本说明书实施例提供了基于用户身份的支付方法及装置，其中，一种基于用户身份的支付方法包括：获取商家系统发送的支付用户的支付请求；所述支付请求携带有提交所述支付请求的支付通道对应的身份类型；检测所述支付用户是否进行所述身份类型的身份验证授权；若是，验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配；若匹配，确定商家签约配置中与所述身份类型对应的支付策略，并按照所述支付策略进行所述支付请求的支付处理。

Description

基于用户身份的支付方法及装置

技术领域

本文件涉及数据处理技术领域，尤其涉及一种基于用户身份的支付方法及装置。

背景技术

随着电子商务的发展和普及，用户使用线上支付方式的频率越来越高，网络支付系统得到越来越广泛地应用，同时也为用户日常生活带来了很大便利。并且随着用户生活水平的提高，线上支付渠道也在不断拓展，不同用户对线上支付方式的要求也越来越多样化，这也对线上支付的提供方提出了更高的考验。

发明内容

本说明书一个或多个实施例提供了一种基于用户身份的支付方法，包括：获取商家系统发送的支付用户的支付请求。所述支付请求携带有提交所述支付请求的支付通道对应的身份类型。检测所述支付用户是否进行所述身份类型的身份验证授权；若是，验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配；若匹配，确定商家签约配置中与所述身份类型对应的支付策略，并按照所述支付策略进行所述支付请求的支付处理。

本说明书一个或多个实施例提供了另一种基于用户身份的支付方法，包括：根据用户通过商家应用选择的支付通道，向商家系统提交携带所述支付通道对应的身份类型的支付请求。接收支付平台返回的所述身份类型的验证授权页面，并向所述支付平台提交授权指令以进行身份验证授权。获取并展示所述支付平台对所述支付请求进行支付处理的支付结果。所述支付处理在基于所述身份验证授权获取的用户身份信息与所述身份类型匹配的情况下，按照商家签约配置中与所述身份类型对应的支付策略进行。

本说明书一个或多个实施例提供了一种基于用户身份的支付装置，包括：支付请求获取模块，被配置为获取商家系统发送的支付用户的支付请求。所述支付请求携带有提交所述支付请求的支付通道对应的身份类型。授权检测模块，被配置为检测所述支付用户是否进行所述身份类型的身份验证授权；若是，运行身份类型验证模块。所述身份类型验证模块，被配置为验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配；若匹配，运行支付处理模块。所述支付处理模块，被配置为确定商家签约配置中与所述身份类型对应的支付策略，并按照所述支付策略进行所述支付请求的支付处理。

本说明书一个或多个实施例提供了另一种基于用户身份的支付装置，包括：支付请求提交模块，被配置为根据用户通过商家应用选择的支付通道，向商家系统提交携带所述支付通道对应的身份类型的支付请求。授权页面接收模块，被配置为接收支付平台返回的所述身份类型的验证授权页面，并向所述支付平台提交授权指令以进行身份验证授权。支付结果获取模块，被配置为获取并展示所述支付平台对所述支付请求进行支付处理的支付结果。所述支付处理在基于所述身份验证授权获取的用户身份信息与所述身份类型匹配的情况下，按照商家签约配置中与所述身份类型对应的支付策略进行。

本说明书一个或多个实施例提供了一种基于用户身份的支付设备，包括：处理器；以及，被配置为存储计算机可执行指令的存储器，所述计算机可执行指令在被执行时使所述处理器：获取商家系统发送的支付用户的支付请求。所述支付请求携带有提交所述支付请求的支付通道对应的身份类型。检测所述支付用户是否进行所述身份类型的身份验证授权；若是，验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配；若匹配，确定商家签约配置中与所述身份类型对应的支付策略，并按照所述支付策略进行所述支付请求的支付处理。

本说明书一个或多个实施例提供了另一种基于用户身份的支付设备，包括：处理器；以及，被配置为存储计算机可执行指令的存储器，所述计算机可执行指令在被执行时使所述处理器：根据用户通过商家应用选择的支付通道，向商家系统提交携带所述支付通道对应的身份类型的支付请求。接收支付平台返回的所述身份类型的验证授权页面，并向所述支付平台提交授权指令以进行身份验证授权。获取并展示所述支付平台对所述支付请求进行支付处理的支付结果。所述支付处理在基于所述身份验证授权获取的用户身份信息与所述身份类型匹配的情况下，按照商家签约配置中与所述身份类型对应的支付策略进行。

本说明书一个或多个实施例提供了一种存储介质，用于存储计算机可执行指令，所述计算机可执行指令在被处理器执行时实现以下流程：获取商家系统发送的支付用户的支付请求。所述支付请求携带有提交所述支付请求的支付通道对应的身份类型。检测所述支付用户是否进行所述身份类型的身份验证授权；若是，验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配；若匹配，确定商家签约配置中与所述身份类型对应的支付策略，并按照所述支付策略进行所述支付请求的支付处理。

本说明书一个或多个实施例提供了另一种存储介质，用于存储计算机可执行指令，所述计算机可执行指令在被处理器执行时实现以下流程：根据用户通过商家应用选择的支付通道，向商家系统提交携带所述支付通道对应的身份类型的支付请求。接收支付平台返回的所述身份类型的验证授权页面，并向所述支付平台提交授权指令以进行身份验证授权。获取并展示所述支付平台对所述支付请求进行支付处理的支付结果。所述支付处理在基于所述身份验证授权获取的用户身份信息与所述身份类型匹配的情况下，按照商家签约配置中与所述身份类型对应的支付策略进行。

附图说明

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

图1为本说明书一个或多个实施例提供的一种基于用户身份的支付方法处理流程图；

图2为本说明书一个或多个实施例提供的一种支付提交页面的示意图；

图3为本说明书一个或多个实施例提供的一种授权提醒页面的示意图；

图4为本说明书一个或多个实施例提供的一种验证授权页面的示意图；

图5为本说明书一个或多个实施例提供的一种应用于线上支付场景的基于用户身份的支付方法处理流程图；

图6为本说明书一个或多个实施例提供的一种应用于线下支付场景的基于用户身份的支付方法处理流程图；

图7为本说明书一个或多个实施例提供的另一种基于用户身份的支付方法处理流程图；

图8为本说明书一个或多个实施例提供的一种基于用户身份的支付装置示意图；

图9为本说明书一个或多个实施例提供的另一种基于用户身份的支付装置示意图；

图10为本说明书一个或多个实施例提供的一种基于用户身份的支付设备的结构示意图；

图11为本说明书一个或多个实施例提供的另一种基于用户身份的支付设备的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本说明书一个或多个实施例中的技术方案，下面将结合本说明书一个或多个实施例中的附图，对本说明书一个或多个实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书一个或多个实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本文件的保护范围。

本说明书提供的一种基于用户身份的支付方法实施例：

本申请提供的基于用户身份的支付方法，通过选择与支付用户的身份类型对应的支付通道提交支付请求，在对商家系统发送的支付请求进行处理的过程中，首先检测支付用户是否针对当前身份类型进行身份验证授权，如果支付用户已对当前身份类型进行身份验证授权，则可基于支付用户的授权获取支付用户的用户身份信息，进一步验证用户身份信息与所述身份类型与当前身份类型是否匹配，来验证支付用户的身份是否满足使用支付通道的条件，并在匹配的情况下确定商家签约配置中与当前身份类型对应的支付策略，最后按照当前身份类型对应的支付策略对支付用户的支付请求进行支付处理，以此实现从支付用户的身份类型出发的身份支付，在完善商家支付场景的同时提升了用户的支付体验；以及，在支付过程中进行支付用户的身份验证和身份支付，无需商家针对身份验证和身份支付进行系统改进，避免了商家的系统改进带来的成本；同时，在支付侧进行支付用户的身份验证和身份支付，避免用户身份信息透出给商家侧，提升了用户身份信息的数据安全性。

步骤S102，获取商家系统发送的支付用户的支付请求。

本实施例所述商家系统，是指在交易场景中进行订单处理并配合支付平台进行订单支付的处理系统，比如针对用户通过线上渠道或者线下渠道发起的交易生成交易订单的后台系统。具体在处理过程中，首先由支付用户针对商品或者服务提交相应的支付请求，支付请求被提交至商家系统后，商家系统通过向支付平台发送支付请求的方式，进行支付用户的订单支付，此处，获取商家系统发送的支付用户的支付请求。

可选的，所述支付请求携带有提交所述支付请求的支付通道对应的身份类型。所述身份类型，是指用户所具有的特定身份类型，具体的，身份类型可以是按照职业进行划分获得的职业身份类型，比如教师类型、医生类型等；或者，身份类型可以是按照社交角色进行划分获得的社交身份类型，比如幼儿类型、学生类型、公司职员类型、老年人类型等；再或者，身份类型还可以是按照用户经历进行划分获得的经历身份类型，比如退休人员类型、退伍人员类型等。

所述支付通道，是指针对特定的身份类型的配置的支付访问接口，比如在购票过程中针对学生类型的用户配置的学生支付接口，再比如在特定餐饮机构进行就餐过程中针对老年人类型的用户配置的用于进行就餐补贴的老年人支付接口。

可选的，所述支付通道，包括线上支付通道；所述支付请求由所述支付用户通过所述线上支付通道向所述商家系统提交。所述线上支付通道，是指支付用户通过线上访问场景针对特定的身份类型进行支付请求提交的支付通道，或者，支付用户在线上交易场景中针对特定的身份类型进行支付请求提交的支付通道。

其中，所述线上支付通道，包括下述至少一项：商家应用程序中配置的对应所述身份类型的支付接口，商家子程序中配置的对应所述身份类型的支付接口，商家网页中配置的对应所述身份类型的支付接口。其中，子程序包括搭载于宿主应用(应用程序)的程序功能模块或者应用组件，或者，由宿主应用加载安装的程序功能模块或者应用组件，比如应用程序内的小程序。从服务的角度来讲，所述子程序具有独立提供自闭环服务的能力，比如运行在应用程序内的提供票务服务的自闭环能力的小程序。

例如，用户在商家小程序中购买景区门票时，如果用户的身份类型为学生，可选择学生购票通道进行购票，进入图2所示的支付提交页面，在该页面选择前往景区的游玩日期，并在确认购票用户信息后点击“支付”按钮进行支付提交，该“支付”按钮也即是学生身份类型这一类型的支付接口，用户通过触发该接口向商家系统提交按照学生身份类型进行购票支付的支付请求，此处向商家系统提交的支付请求携带学生身份类型。

除上述提供的线上支付通道之外，所述支付通道还包括线下支付渠道，所述线下支付通道，是指支付用户通过线下访问场景针对特定的身份类型进行支付请求提交的支付通道，或者，支付用户在线下交易场景中针对特定的身份类型进行支付请求提交的支付渠道。

可选的，所述线下支付通道，包括下述至少一项：商家收银系统配置的与所述身份类型对应的收银接口，商家终端配置的适配所述身份类型的采集单元；

相应的，所述支付请求，通过调用所述收银接口扫描所述支付用户的支付码后提交，或者，通过所述采集单元采集所述支付用户的生物特征并进行生物特征识别后提交。

例如，用户在线下场景进行支付的过程中，收银人员根据用户的需求在收银终端选择特定身份类型进行支付，并通过点击收银指令调用收银接口扫描用户的支付二维码，此后，收银终端的后台系统会将携带特定身份类型的支付请求向支付平台发送；

或者，用户在线下场景进行支付的过程中，商家终端针对特定身份类型配置对应的人脸采集组件或者指纹采集组件，用户在支付过程中如果想采用特定身份类型进行支付，则可在特定身份类型对应的人脸采集组件或者指纹采集组件进行人脸图像或者指纹特征采集，采集的人脸图像或者指纹特征被商家终端上传至后台系统之后，后台系统会向支付平台发送携带特定身份类型的支付请求。

步骤S104，检测所述支付用户是否进行所述身份类型的身份验证授权。

本实施例中，在支付过程中提供基于支付用户的身份类型的支付，即：身份支付，上述获取到所述携带提交支付请求的支付通道对应的身份类型的支付请求之后，表明支付用户的支付请求是基于身份支付的支付请求，具体的身份支付过程中，需要验证支付用户进行身份支付提交或者选择的身份类型是否与支付用户真实的身份类型相符，而验证身份类型相符与否的过程中，则需要获取支付用户的用户身份信息，因此，需检测支付用户是否进行身份类型的身份验证授权，在支付用户进行身份类型的身份验证授权的前提下，能够从支付用户的用户身份信息出发验证支付用户进行身份支付提交或者选择的身份类型是否与支付用户真实的身份类型相符，进而实现身份支付的处理过程。

具体实施时，检测所述支付用户是否进行所述身份类型的身份验证授权；若是，表明支付用户已经完成当前身份类型在身份支付处理过程中的授权，执行下述步骤S106，验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配；

若否，表明支付用户尚未完成当前身份类型在身份支付处理过程中的授权，这种情况下，可向支付用户的用户终端返回支付失败的支付提醒，或者，还可向支付用户的用户终端返回身份类型未进行授权的授权提醒。

此外，在检测所述支付用户是否进行所述身份类型的身份验证授权的检测结果为否的情况下，也即是支付用户尚未完成当前身份类型在身份支付处理过程中的授权的情况下，为了避免支付用户的支付流程因身份验证授权被打断，本实施例提供的一种可选方式中，提供在身份支付过程中进行的授权处理过程，具体包括：向所述支付用户的用户终端返回所述身份类型的验证授权页面，接收所述用户终端提交的授权指令，并基于所述授权指令跳转至下述步骤S106进行执行，验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配。以此，通过在身份支付的处理中引入授权处理过程，保障支付用户的支付过程中能够顺利进行，来提升支付用户的支付成功率，进而来提升支付用户的支付体验。

沿用上例，用户在购买景区门票时，通过点击支付提交页面设置的“支付”按钮向商家系统提交携带学生身份类型的支付请求后，由商家系统将携带学生身份类型的支付请求发送至支付平台，支付平台接收到该支付请求后，检测用户是否进行学生身份类型的身份验证授权，如果未进行学生身份类型的身份验证授权，则支付平台无法在用户未授权的情况下，无法验证用户的真实的身份类型是否与学生身份类型相符，因此需要用户进行授权；

具体在授权过程中，在检测到用户未进行学生身份类型的身份验证授权的情况下，支付平台可通过用户终端的安装的支付应用返回授权提醒，如图3所示的授权提醒页面展示的授权提醒，在用户点击“去验证”按钮确认进行学生身份类型的身份验证授权后，可通过支付应用返回验证授权页面，如图4所示，如果用户点击“同意授权并验证身份”按钮，则可针对用户进行学生身份类型的身份验证授权。

实际应用中，在身份支付的处理中引入授权处理过程中，还存在出现身份信息缺失等导致授权处理过程无法进行的可能性，针对于此，为提升身份支付的有效性，上述提供的向所述支付用户的用户终端返回所述身份类型的验证授权页面，接收所述用户终端提交的授权指令，并基于所述授权指令跳转至下述步骤S106进行执行这一处理过程，还可被替换为：向所述支付用户的用户终端返回所述身份类型的验证授权页面，接收所述用户终端提交的授权指令，若接收所述授权指令后基于所述支付用户的身份信息进行所述身份验证的授权处理成功，则跳转至下述步骤S106进行执行；

另一方面，若接收所述授权指令后基于所述支付用户的身份信息进行所述身份验证的授权处理失败，为了进一步降低支付用户的支付流程因身份验证授权被打断的概率，提升支付用户的支付成功率，本实施例提供的一种可选实施方式中，若接收所述授权指令后基于所述支付用户的身份信息进行所述身份验证的授权处理失败，则生成所述身份验证的信息补充提醒并向所述授权子程序返回，根据所述身份信息和所述授权子程序提交的补充身份信息，进行所述身份验证的授权处理。

如上所述，提交携带的身份类型的支付请求的支付通道包括线上支付通道和/或线下支付通道，实际场景中支付用户在不同时间的交易场景可能覆盖线下交易场景和线下交易场景，而在线下交易场景的身份支付过程中进行授权处理可能会多有不便，因此，为了提升线下交易场景的支付体验，在当前提交携带身份类型的支付请求的支付通道为线下支付通道时，检测到的支付用户进行的身份类型的身份验证授权，可以是支付用户之前在线上交易场景进行身份类型的身份验证授权，可选的，在所述支付请求携带线下支付通道对应的身份类型的情况下，所述身份类型的身份验证授权，在针对所述支付用户通过线上支付通道提交的携带所述身份类型的历史支付请求进行的支付处理过程中进行。

与之对应的，在当前提交携带身份类型的支付请求的支付通道为线上支付通道时，检测到的支付用户进行的身份类型的身份验证授权，可以是支付用户之前在线下交易场景进行身份类型的身份验证授权，可选的，在所述支付请求携带线上支付通道对应的身份类型的情况下，所述身份类型的身份验证授权，在针对所述支付用户通过线下支付通道提交的携带所述身份类型的历史支付请求进行的支付处理过程中进行。

此外，在具体实施时，为增强支付用户的身份类型的身份验证授权的灵活性，本实施例还提供通过授权子程序进行身份验证授权的实现方式；需要说明的是，通过授权子程序进行身份验证授权可以是支付用户在支付之前进行，也可以在对支付用户的支付请求进行身份支付的过程中，检测到支付用户未进行身份类型的身份验证授权的情况下调用授权子程序进行。

具体的，本实施例提供的一种可选实施方式中，所述身份类型的身份验证授权，采用如下方式实现：

获取所述支付用户通过授权子程序提交的进行所述身份类型的身份验证的授权请求，并向所述授权子程序返回验证授权页面；

基于所述授权子程序提交的身份信息和授权指令，针对所述支付用户进行所述身份验证的授权处理。

具体的，在针对支付用户进行身份验证的授权处理的过程中，如果当前身份类型的身份验证授权在支付之前执行，在针对支付用户进行身份验证的授权处理的授权成功后，通过授权子程序展示授权成功提醒或者不做处理即可；

另一方面，在针对支付用户进行身份验证的授权处理的授权失败后，为进一步完善身份验证授权的处理逻辑，提升身份验证授权的成功率，本实施例提供的一种可选实施方式中，生成所述身份验证的信息补充提醒并向所述授权子程序返回，根据所述身份信息和所述授权子程序提交的补充身份信息，进行所述身份验证的授权处理。

如果当前身份类型的身份验证授权在对支付用户的支付请求进行身份支付的过程中进行，则在针对支付用户进行身份验证的授权处理的授权成功后，跳转至下述步骤S106进行执行；另一方面，在针对支付用户进行身份验证的授权处理的授权失败后，同样为了完善身份验证授权的处理逻辑，提升身份验证授权的成功率，本实施例提供的一种可选实施方式中，生成所述身份验证的信息补充提醒并向所述授权子程序返回，根据所述身份信息和所述授权子程序提交的补充身份信息，进行所述身份验证的授权处理。

步骤S106，验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配。

如上所述，本实施例在支付过程中提供基于支付用户的身份类型的支付，即：身份支付，上述获取到所述携带提交支付请求的支付通道对应的身份类型的支付请求之后，表明支付用户的支付请求是基于身份支付的支付请求，具体的身份支付过程中，需要验证支付用户进行身份支付提交或者选择的身份类型是否与支付用户真实的身份类型相符，本步骤中，通过验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配，实现支付用户进行身份支付提交或者选择的身份类型与支付用户真实的身份类型是否相符的验证。

具体实施时，验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配的过程中，若验证结果为匹配，表明支付用户的用户身份信息与当前进行身份支付的身份类型相符，可以针对支付用户的支付请求进行身份支付，执行步骤S108，确定商家签约配置中与所述身份类型对应的支付策略，并按照所述支付策略进行所述支付请求的支付处理。

此外，若基于所述身份验证授权获取的用户身份信息与所述身份类型不匹配，为确保支付用户的支付请求能够被处理，以此来保障支付流程能够进行，本实施例提供的一种可选实施方式中，按照商家签约配置中与非特定身份类型对应的支付方式进行所述支付请求的支付处理。

本实施例所述商家签约配置，是指商家预先针对商家与用户的交易支付配置的支付相关信息，商家签约配置可由针对特定身份类型的支付用户配置的支付策略组成；此外，商家签约配置中还可包含针对非特定身份类型的支付用户配置的支付方式；非特定身份类型的支付用户，可包括不具有特定身份类型的支付用户或者身份类型为空的支付用户。商家在配置支付相关信息的过程中，可通过与支付平台签约的方式进行配置，支付相关信息也可写入商家与支付平台签署的协议中。

需要说明的是，实际中如果基于身份验证授权获取的用户身份信息不够完整或者存在关键信息缺失，则有一定可能会导致用户身份信息与所述身份类型不匹配的情形出现，即：导致验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配的验证结果为不匹配，针对于此，在基于所述身份验证授权获取的用户身份信息与所述身份类型不匹配的情况下，本实施例提供的一种可选实施方式中，采用如下方式进行二次验证处理：

生成所述身份类型的身份验证的信息补充提醒并向所述支付用户的用户终端返回，并获取所述用户终端提交的补充身份信息；

验证基于所述用户身份信息和所述补充身份信息与所述身份类型是否匹配，若是，跳转至步骤S108执行；若否，向所述用户终端返回支付失败结果，或者，按照商家签约配置中非准入身份类型的支付配置进行所述支付请求的支付处理。

本实施例提供的第一种可选实施方式中，所述用户身份信息，采用如下方式进行获取：

检测所述身份类型是否为域内身份类型；

若是，基于所述身份验证授权在域内数据库查询所述支付用户的身份凭证和/或职业凭证；

若否，通过接口调用向所述身份类型对应的数据平台发送携带所述身份验证授权的授权记录的查询请求；接收所述第三方数据平台返回的所述支付用户在所述身份类型下的身份信息。

所述域内身份类型，是指支付用户的身份类型由与支付平台同属一个数据域的处理平台进行确定，或者，可以是根据与支付平台所属的数据域内的支付用户的身份相关信息确定的身份类型。其中，数据域可以从是否需要跨数据网关进行数据传输或者获取的角度来划分。

本实施例提供的第二种可选实施方式中，所述用户身份信息，采用如下方式进行获取：

通过接口调用向所述身份类型对应的数据平台发送携带所述身份验证授权的授权记录的查询请求；

接收所述第三方数据平台返回的所述支付用户在所述身份类型下的身份信息。

除上述提供的两种可选实施方式之外，为提升获取的用户身份信息的完整性和准确性，还可结合上述提供的两种可选实施方式进行用户身份信息的获取，比如基于所述身份验证授权在域内数据库查询所述支付用户的身份凭证和/或职业凭证，以及，通过接口调用向所述身份类型对应的数据平台发送携带所述身份验证授权的授权记录的查询请求，并接收所述第三方数据平台返回的所述支付用户在所述身份类型下的身份信息，将所述身份信息与所述身份凭证和/或所述职业凭证作为所述用户身份信息。

步骤S108，确定商家签约配置中与所述身份类型对应的支付策略，并按照所述支付策略进行所述支付请求的支付处理。

本实施例所述商家签约配置，是指商家预先针对商家与用户的交易支付配置的支付相关信息，商家签约配置可由针对特定身份类型的支付用户配置的支付策略组成；此外，商家签约配置中还可包含针对非特定身份类型的支付用户配置的支付方式；非特定身份类型的支付用户，可包括不具有特定身份类型的支付用户或者身份类型为空的支付用户。商家在配置支付相关信息的过程中，可通过与支付平台签约的方式进行配置，支付相关信息也可写入商家与支付平台签署的协议中。

所述身份类型对应的支付策略，包括身份类型对应的支付权益。所述支付权益包括下属至少一项：优惠支付，折扣支付，支付后发放优惠，开通特定资源兑换(积分兑换)的支付。

本实施例提供的一种可选实施方式中，确定商家签约配置中与所述身份类型对应的支付策略，并按照所述支付策略进行所述支付请求的支付处理，包括：

确定商家签约配置中与所述身份类型对应的支付权益；

按照所述支付权益计算所述支付请求的实际支付金额并向所述支付用户的用户终端返回，并根据所述用户终端提交的支付确认指令进行所述支付请求的支付处理。

此外，实际应用中部分商家涉及的交易场景范围可能会很广，为了避免针对全局所有的交易场景范围配置统一的商家签约配置导致配置太多复杂，也为了提升确定商家签约配置中与支付用户的身份类型对应的支付权益这一过程的响应效率，进而降低身份支付的耗时，还可针对不同支付类型的支付请求设置不同的商家签约配置，针对于此，确定商家签约配置中与所述身份类型对应的支付策略，并按照所述支付策略进行所述支付请求的支付处理，包括：在所述支付请求所属的支付类型对应的商家签约配置中，确定与所述身份类型对应的支付权益；按照所述支付权益进行所述支付请求的支付处理。

具体的，在按照所述支付权益进行所述支付请求的支付处理的过程中，同样可采用上述提供的按照所述支付权益计算所述支付请求的实际支付金额并向所述支付用户的用户终端返回，并根据所述用户终端提交的支付确认指令进行所述支付请求的支付处理这一处理方式进行支付处理。

实际中，许多支付场景会与线下或者线上场景的营销活动进行关联或者绑定，以此来提升用户支付积极性，针对这种场景，本实施例提供的一种可选实施方式中，在按照所述支付权益进行所述支付请求的支付处理之后，执行如下操作：

根据所述支付通道的通道类别，确定所述商家签约配置与所述通道类型对应的附加权益；

生成通过线下通道向所述支付用户发放所述附加权益的权益发放任务，和/或，向所述支付用户开通所述附加权益对应的服务权限。

综上所述，本实施例提供的基于用户身份的支付方法，在对商家系统发送的携带身份类型的支付请求进行支付处理过程中，从支付用户的身份类型出发进行身份支付，由执行基于用户身份的支付方法的支付平台进行身份验证以及从身份类型出发的支付处理过程，无需商家系统进行复杂的身份验证授权检测和身份类型验证处理，降低了商家系统在基于支付用户的身份类型进行的身份支付处理过程中的实现难度和系统改造成本，同时，商家系统不进行身份验证授权检测和身份类型验证处理过程，避免了支付用户的身份信息透出给商家系统，提升了支付用户的身份信息的安全性；

并且，在身份支付过程中通过检测支付用户是否进行身份类型的身份验证授权，在身份支付过程中针对未进行身份验证授权的支付用户提供身份类型的验证授权逻辑，从而通过在身份支付的处理中引入授权处理过程，保障支付用户的支付过程中能够顺利进行，降低支付用户的支付流程因身份验证授权被打断的概率，提升支付用户的支付成功率，进而提升支付用户的支付体验；

进一步，在验证基于身份验证授权获取的用户身份信息与身份类型是否匹配的过程中，还提供身份信息补充实现方式，避免因基于身份验证授权获取的用户身份信息不够完整或者存在关键信息缺失导致身份支付被中断，进一步优化身份支付处理过程提升支付成功率。

上述提供的一种基于用户身份的支付方法的实现过程，可由支付平台执行，下述方法实施例提供的另一种基于用户身份的支付方法的实现过程，可由用户终端执行，二者在执行过程中可相互配合，因此，阅读上述实现过程可参照下述方法实施例的对应内容，相应的，阅读下述实现过程也可参照上述方法实施例的对应内容。

下述以本实施例提供的一种基于用户身份的支付方法在线上支付场景的应用为例，结合图5，对本实施例提供的基于用户身份的支付方法进行进一步说明，参见图5，应用于线上支付场景的基于用户身份的支付方法，具体包括下述步骤。

步骤S504，接收商家系统发送的携带线上支付通道对应的身份类型的支付请求。

步骤S506，检测支付请求对应的支付用户是否进行身份类型的身份验证授权；

若是，执行步骤S516；

若否，执行步骤S508至步骤S512；

步骤S508，向用户终端返回身份类型的验证授权页面。

步骤S514，接收用户终端提交的授权指令。

若接收授权指令后基于支付用户的身份信息进行身份验证的授权处理成功，执行步骤S516。

步骤S516，验证基于身份验证授权获取的用户身份信息与身份类型是否匹配；

若是，执行步骤S518至步骤S522；

若否，按照商家签约配置中与非特定身份类型对应的支付方式进行支付请求的支付处理。

步骤S518，确定商家签约配置中与身份类型对应的支付权益。

步骤S520，按照支付权益计算支付请求的实际支付金额并向支付用户的用户终端返回，并根据用户终端提交的支付确认指令进行支付处理。

步骤S522，向用户终端返回支付处理的支付结果。

本实施例提供的上述步骤S504至步骤S508以及步骤S514和步骤S522，由支付平台执行，需要说明的是，支付平台执行上述步骤S504至步骤S508以及步骤S514和步骤S522的处理过程，与下述实施例用户终端执行的步骤S502、步骤S510至步骤S512、步骤S524的处理过程，在执行过程中可相互配合，因此阅读本实施例请参照下述方法实施例提供的步骤S502、步骤S510至步骤S512、步骤S524的相应内容。

下述以本实施例提供的一种基于用户身份的支付方法在线下支付场景的应用为例，结合图6，对本实施例提供的基于用户身份的支付方法进行进一步说明，参见图6，应用于线下支付场景的基于用户身份的支付方法，具体包括下述步骤。

步骤S602，获取商家系统发送的携带线下支付通道对应的身份类型的支付请求。

步骤S604，检测支付请求对应的支付用户是否进行身份类型的身份验证授权；

若是，执行步骤S606；

若否，返回支付失败提醒。

步骤S606，检测身份类型是否为域内身份类型；

若是，执行步骤S608；

若否，通过接口调用向身份类型对应的数据平台发送携带身份验证授权的授权记录的查询请求，并接收第三方数据平台返回的支付用户在身份类型下的身份信息。

步骤S608，基于身份验证授权在域内数据库查询支付用户的职业凭证。

步骤S610，验证职业凭证或者身份信息与身份类型是否匹配；

若是，执行步骤S612至步骤S614；

若否，按照商家签约配置中与非特定身份类型对应的支付方式进行支付请求的支付处理。

步骤S612，确定商家签约配置中与身份类型对应的支付权益。

步骤S614，按照支付权益计算支付请求的实际支付金额并向支付用户的用户终端返回，并根据用户终端提交的支付确认指令进行支付处理。

本说明书提供的另一种基于用户身份的支付方法实施例：

步骤S702，根据用户通过商家应用选择的支付通道，向商家系统提交携带所述支付通道对应的身份类型的支付请求。

本实施例所述商家系统，是指在交易场景中进行订单处理并配合支付平台进行订单支付的处理系统，比如针对用户通过线上渠道或者线下渠道发起的交易生成交易订单的后台系统。具体在处理过程中，首先由支付用户针对商品或者服务提交相应的支付请求，支付请求被提交至商家系统后，商家系统通过向支付平台发送支付请求的方式，进行支付用户的订单支付，此处，获取商家系统发送的支付用户的支付请求。

可选的，所述支付请求携带有提交所述支付请求的支付通道对应的身份类型。所述身份类型，是指用户所具有的特定身份类型，具体的，身份类型可以是按照职业进行划分获得的职业身份类型，比如教师类型、医生类型等；或者，身份类型可以是按照社交角色进行划分获得的社交身份类型，比如幼儿类型、学生类型、公司职员类型、老年人类型等；再或者，身份类型还可以是按照用户经历进行划分获得的经历身份类型，比如退休人员类型、退伍人员类型等。

所述支付通道，是指针对特定的身份类型的配置的支付访问接口，比如在购票过程中针对学生类型的用户配置的学生支付接口，再比如在特定餐饮机构进行就餐过程中针对老年人类型的用户配置的用于进行就餐补贴的老年人支付接口。

可选的，所述支付通道，包括线上支付通道；所述支付请求由所述支付用户通过所述线上支付通道向所述商家系统提交。所述线上支付通道，是指支付用户通过线上访问场景针对特定的身份类型进行支付请求提交的支付通道，或者，支付用户在线上交易场景中针对特定的身份类型进行支付请求提交的支付通道。

其中，所述线上支付通道，包括下述至少一项：商家应用程序中配置的对应所述身份类型的支付接口，商家子程序中配置的对应所述身份类型的支付接口，商家网页中配置的对应所述身份类型的支付接口。其中，子程序包括搭载于宿主应用(应用程序)的程序功能模块或者应用组件，或者，由宿主应用加载安装的程序功能模块或者应用组件，比如应用程序内的小程序。从服务的角度来讲，所述子程序具有独立提供自闭环服务的能力，比如运行在应用程序内的提供票务服务的自闭环能力的小程序。

例如，用户在商家小程序中购买景区门票时，如果用户的身份类型为学生，可选择学生购票通道进行购票，进入图2所示的支付提交页面，在该页面选择前往景区的游玩日期，并在确认购票用户信息后点击“支付”按钮进行支付提交，该“支付”按钮也即是学生身份类型这一类型的支付接口，用户通过触发该接口向商家系统提交按照学生身份类型进行购票支付的支付请求，此处向商家系统提交的支付请求携带学生身份类型。

步骤S704，接收支付平台返回的所述身份类型的验证授权页面，并向所述支付平台提交授权指令以进行身份验证授权。

具体实施时，上述携带支付通道对应的身份类型的支付请求由商家系统发送至支付平台之后，由支付平台基于支付用户的身份类型进行支付，即：身份支付，具体的身份支付过程中，支付平台需要验证支付用户进行身份支付提交或者选择的身份类型是否与支付用户真实的身份类型相符，而验证身份类型相符与否的过程中，则需要获取支付用户的用户身份信息，因此，需检测支付用户是否进行身份类型的身份验证授权；

如果支付用户未进行身份类型的身份验证授权，为了避免支付用户的支付流程因身份验证授权被打断，支付平台提供在身份支付过程中进行的授权处理过程，具体在授权处理过程中，向支付用户的用户终端返回身份类型的验证授权页面；本步骤中，接收支付平台返回的所述身份类型的验证授权页面，并向所述支付平台提交授权指令以进行身份验证授权。

需要说明的是，支付平台在接收到授权指令之后进行身份验证授权的过程中，还存在出现身份信息缺失等导致授权处理过程无法进行的可能性，针对于此，为了降低支付用户的支付流程因身份验证授权被打断的概率，提升支付用户的支付成功率，支付平台在身份验证授权处理过程中，若授权处理失败，可生成所述身份验证的信息补充提醒并向所述授权子程序返回，此处，接收所述支付平台返回的所述身份类型的身份验证的信息补充提醒；将所述支付用户针对所述信息补充提醒录入的补充身份信息向所述支付平台提交，以进行所述身份验证的授权处理。

步骤S706，获取并展示所述支付平台对所述支付请求进行支付处理的支付结果。

可选的，所述支付处理在基于所述身份验证授权获取的用户身份信息与所述身份类型匹配的情况下，按照商家签约配置中与所述身份类型对应的支付策略进行。

本实施例所述商家签约配置，是指商家预先针对商家与用户的交易支付配置的支付相关信息，商家签约配置可由针对特定身份类型的支付用户配置的支付策略组成；此外，商家签约配置中还可包含针对非特定身份类型的支付用户配置的支付方式；非特定身份类型的支付用户，可包括不具有特定身份类型的支付用户或者身份类型为空的支付用户。商家在配置支付相关信息的过程中，可通过与支付平台签约的方式进行配置，支付相关信息也可写入商家与支付平台签署的协议中。

所述身份类型对应的支付策略，包括身份类型对应的支付权益。所述支付权益包括下属至少一项：优惠支付，折扣支付，支付后发放优惠，开通特定资源兑换(积分兑换)的支付。

具体执行过程中，支付平台对所述支付请求进行支付处理，可采用如下方式进行：确定商家签约配置中与所述身份类型对应的支付权益；按照所述支付权益计算所述支付请求的实际支付金额并向所述支付用户的用户终端返回，并根据所述用户终端提交的支付确认指令进行所述支付请求的支付处理；

相应的，本实施例提供的一种可选实施方式中，通过执行如下操作配合支付平台对所述支付请求进行支付处理：接收所述支付平台返回的实际支付金额并展示；所述实际支付金额按照商家约配置中与所述身份类型对应的支付权益计算获得；向所述支付平台提交所述支付用户针对所述实际支付金额输入的支付确认指令。

需要说明的是，许多支付场景会与线下或者线上场景的营销活动进行关联或者绑定，以此来提升用户支付积极性，针对这种场景，支付平台对所述支付请求进行支付处理的过程中，在根据所述用户终端提交的支付确认指令进行所述支付请求的支付处理之后，还可执行如下操作：根据所述支付通道的通道类别，确定所述商家签约配置与所述通道类型对应的附加权益；生成通过线下通道向所述支付用户发放所述附加权益的权益发放任务，和/或，向所述支付用户开通所述附加权益对应的服务权限。

本实施例提供的第一种可选实施方式中，所述用户身份信息，采用如下方式进行获取：

检测所述身份类型是否为域内身份类型；

若是，基于所述身份验证授权在域内数据库查询所述支付用户的身份凭证和/或职业凭证；

若否，通过接口调用向所述身份类型对应的数据平台发送携带所述身份验证授权的授权记录的查询请求；接收所述第三方数据平台返回的所述支付用户在所述身份类型下的身份信息。

所述域内身份类型，是指支付用户的身份类型由与支付平台同属一个数据域的处理平台进行确定，或者，可以是根据与支付平台所属的数据域内的支付用户的身份相关信息确定的身份类型。其中，数据域可以从是否需要跨数据网关进行数据传输或者获取的角度来划分。

本实施例提供的第二种可选实施方式中，所述用户身份信息，采用如下方式进行获取：

通过接口调用向所述身份类型对应的数据平台发送携带所述身份验证授权的授权记录的查询请求；

接收所述第三方数据平台返回的所述支付用户在所述身份类型下的身份信息。

除上述提供的两种可选实施方式之外，为提升获取的用户身份信息的完整性和准确性，还可结合上述提供的两种可选实施方式进行用户身份信息的获取，比如基于所述身份验证授权在域内数据库查询所述支付用户的身份凭证和/或职业凭证，以及，通过接口调用向所述身份类型对应的数据平台发送携带所述身份验证授权的授权记录的查询请求，并接收所述第三方数据平台返回的所述支付用户在所述身份类型下的身份信息，将所述身份信息与所述身份凭证和/或所述职业凭证作为所述用户身份信息。

下述以本实施例提供的一种基于用户身份的支付方法在线上支付场景的应用为例，结合图5，对本实施例提供的基于用户身份的支付方法进行进一步说明，参见图5，应用于线上支付场景的基于用户身份的支付方法，具体包括下述步骤。

步骤S502，根据用户通过商家应用选择的线上支付通道，向商家系统提交携带支付通道对应的身份类型的支付请求。

支付请求提交至商家系统后，由商家系统将支付请求发送至支付平台。

步骤S510，接收支付平台返回的身份类型的验证授权页面并展示。

步骤S512，向支付平台提交授权指令以进行身份验证授权。

步骤S524，接收并展示支付平台返回的支付请求的支付结果。

本说明书提供的一种基于用户身份的支付装置实施例如下：

在上述的实施例中，提供了一种基于用户身份的支付方法，与之相对应的，还提供了一种基于用户身份的支付装置，下面结合附图进行说明。

参照图8，其示出了本实施例提供的一种基于用户身份的支付装置示意图。

由于装置实施例对应于方法实施例，所以描述得比较简单，相关的部分请参见上述提供的方法实施例的对应说明即可。下述描述的装置实施例仅仅是示意性的。

本实施例提供一种基于用户身份的支付装置，包括：

支付请求获取模块802，被配置为获取商家系统发送的支付用户的支付请求；所述支付请求携带有提交所述支付请求的支付通道对应的身份类型；

授权检测模块804，被配置为检测所述支付用户是否进行所述身份类型的身份验证授权；

若是，运行身份类型验证模块806；所述身份类型验证模块806，被配置为验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配；

若匹配，运行支付处理模块808；所述支付处理模块808，被配置为确定商家签约配置中与所述身份类型对应的支付策略，并按照所述支付策略进行所述支付请求的支付处理。

本说明书提供的另一种基于用户身份的支付装置实施例如下：

在上述的实施例中，提供了另一种基于用户身份的支付方法，与之相对应的，还提供了另一种基于用户身份的支付装置，下面结合附图进行说明。

参照图9，其示出了本实施例提供的一种基于用户身份的支付装置示意图。

由于装置实施例对应于方法实施例，所以描述得比较简单，相关的部分请参见上述提供的方法实施例的对应说明即可。下述描述的装置实施例仅仅是示意性的。

本实施例提供一种基于用户身份的支付装置，包括：

支付请求提交模块902，被配置为根据用户通过商家应用选择的支付通道，向商家系统提交携带所述支付通道对应的身份类型的支付请求；

授权页面接收模块904，被配置为接收支付平台返回的所述身份类型的验证授权页面，并向所述支付平台提交授权指令以进行身份验证授权；

支付结果获取模块906，被配置为获取并展示所述支付平台对所述支付请求进行支付处理的支付结果；所述支付处理在基于所述身份验证授权获取的用户身份信息与所述身份类型匹配的情况下，按照商家签约配置中与所述身份类型对应的支付策略进行。

本说明书提供的一种基于用户身份的支付设备实施例如下：

对应上述描述的一种基于用户身份的支付方法，基于相同的技术构思，本说明书一个或多个实施例还提供一种基于用户身份的支付设备，该基于用户身份的支付设备用于执行上述提供的基于用户身份的支付方法，图10为本说明书一个或多个实施例提供的一种基于用户身份的支付设备的结构示意图。

本实施例提供的一种基于用户身份的支付设备，包括：

如图10所示，基于用户身份的支付设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上的处理器1001和存储器1002，存储器1002中可以存储有一个或一个以上存储应用程序或数据。其中，存储器1002可以是短暂存储或持久存储。存储在存储器1002的应用程序可以包括一个或一个以上模块(图示未示出)，每个模块可以包括基于用户身份的支付设备中的一系列计算机可执行指令。更进一步地，处理器1001可以设置为与存储器1002通信，在基于用户身份的支付设备上执行存储器1002中的一系列计算机可执行指令。基于用户身份的支付设备还可以包括一个或一个以上电源1003，一个或一个以上有线或无线网络接口1004，一个或一个以上输入/输出接口1005，一个或一个以上键盘1006等。

在一个具体的实施例中，基于用户身份的支付设备包括有存储器，以及一个或一个以上的程序，其中一个或者一个以上程序存储于存储器中，且一个或者一个以上程序可以包括一个或一个以上模块，且每个模块可以包括对基于用户身份的支付设备中的一系列计算机可执行指令，且经配置以由一个或者一个以上处理器执行该一个或者一个以上程序包含用于进行以下计算机可执行指令：

获取商家系统发送的支付用户的支付请求；所述支付请求携带有提交所述支付请求的支付通道对应的身份类型；

检测所述支付用户是否进行所述身份类型的身份验证授权；

若是，验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配；

若匹配，确定商家签约配置中与所述身份类型对应的支付策略，并按照所述支付策略进行所述支付请求的支付处理。

本说明书提供的另一种基于用户身份的支付设备实施例如下：

对应上述描述的另一种基于用户身份的支付方法，基于相同的技术构思，本说明书一个或多个实施例还提供另一种基于用户身份的支付设备，该基于用户身份的支付设备用于执行上述提供的基于用户身份的支付方法，图11为本说明书一个或多个实施例提供的另一种基于用户身份的支付设备的结构示意图。

本实施例提供的一种基于用户身份的支付设备，包括：

如图11所示，基于用户身份的支付设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上的处理器1101和存储器1102，存储器1102中可以存储有一个或一个以上存储应用程序或数据。其中，存储器1102可以是短暂存储或持久存储。存储在存储器1102的应用程序可以包括一个或一个以上模块(图示未示出)，每个模块可以包括基于用户身份的支付设备中的一系列计算机可执行指令。更进一步地，处理器1101可以设置为与存储器1102通信，在基于用户身份的支付设备上执行存储器1102中的一系列计算机可执行指令。基于用户身份的支付设备还可以包括一个或一个以上电源1103，一个或一个以上有线或无线网络接口1104，一个或一个以上输入/输出接口1105，一个或一个以上键盘1106等。

在一个具体的实施例中，基于用户身份的支付设备包括有存储器，以及一个或一个以上的程序，其中一个或者一个以上程序存储于存储器中，且一个或者一个以上程序可以包括一个或一个以上模块，且每个模块可以包括对基于用户身份的支付设备中的一系列计算机可执行指令，且经配置以由一个或者一个以上处理器执行该一个或者一个以上程序包含用于进行以下计算机可执行指令：

根据用户通过商家应用选择的支付通道，向商家系统提交携带所述支付通道对应的身份类型的支付请求；

接收支付平台返回的所述身份类型的验证授权页面，并向所述支付平台提交授权指令以进行身份验证授权；

获取并展示所述支付平台对所述支付请求进行支付处理的支付结果；所述支付处理在基于所述身份验证授权获取的用户身份信息与所述身份类型匹配的情况下，按照商家签约配置中与所述身份类型对应的支付策略进行。

本说明书提供的一种存储介质实施例如下：

对应上述描述的一种基于用户身份的支付方法，基于相同的技术构思，本说明书一个或多个实施例还提供一种存储介质。

本实施例提供的存储介质，用于存储计算机可执行指令，所述计算机可执行指令在被处理器执行时实现以下流程：

获取商家系统发送的支付用户的支付请求；所述支付请求携带有提交所述支付请求的支付通道对应的身份类型；

检测所述支付用户是否进行所述身份类型的身份验证授权；

若是，验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配；

若匹配，确定商家签约配置中与所述身份类型对应的支付策略，并按照所述支付策略进行所述支付请求的支付处理。

需要说明的是，本说明书中关于一种存储介质的实施例与本说明书中一种基于用户身份的支付方法的实施例基于同一发明构思，因此该实施例的具体实施可以参见前述对应方法的实施，重复之处不再赘述。

本说明书提供的另一种存储介质实施例如下：

对应上述描述的另一种基于用户身份的支付方法，基于相同的技术构思，本说明书一个或多个实施例还提供另一种存储介质。

本实施例提供的存储介质，用于存储计算机可执行指令，所述计算机可执行指令在被处理器执行时实现以下流程：

根据用户通过商家应用选择的支付通道，向商家系统提交携带所述支付通道对应的身份类型的支付请求；

接收支付平台返回的所述身份类型的验证授权页面，并向所述支付平台提交授权指令以进行身份验证授权；

获取并展示所述支付平台对所述支付请求进行支付处理的支付结果；所述支付处理在基于所述身份验证授权获取的用户身份信息与所述身份类型匹配的情况下，按照商家签约配置中与所述身份类型对应的支付策略进行。

需要说明的是，本说明书中关于另一种存储介质的实施例与本说明书中另一种基于用户身份的支付方法的实施例基于同一发明构思，因此该实施例的具体实施可以参见前述对应方法的实施，重复之处不再赘述。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在20世纪30年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device，PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书实施例时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

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

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

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

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

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

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

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

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书的一个或多个实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本文件的实施例而已，并不用于限制本文件。对于本领域技术人员来说，本文件可以有各种更改和变化。凡在本文件的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本文件的权利要求范围之内。

Claims (23)

1.一种基于用户身份的支付方法，包括：

获取商家系统发送的支付用户的支付请求；所述支付请求携带有提交所述支付请求的支付通道对应的身份类型；

检测所述支付用户是否进行所述身份类型的身份验证授权；

若是，验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配；

若匹配，确定商家签约配置中与所述身份类型对应的支付策略，并按照所述支付策略进行所述支付请求的支付处理。

2.根据权利要求1所述的基于用户身份的支付方法，若所述检测所述支付用户是否进行所述身份类型的身份验证授权步骤执行之后的执行结果为否，执行如下操作：

向所述支付用户的用户终端返回所述身份类型的验证授权页面，并接收所述用户终端提交的授权指令；

基于所述授权指令跳转至所述验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配步骤执行。

3.根据权利要求1所述的基于用户身份的支付方法，所述确定商家签约配置中与所述身份类型对应的支付策略，并按照所述支付策略进行所述支付请求的支付处理，包括：

确定商家签约配置中与所述身份类型对应的支付权益；

按照所述支付权益计算所述支付请求的实际支付金额并向所述支付用户的用户终端返回，并根据所述用户终端提交的支付确认指令进行所述支付请求的支付处理。

4.根据权利要求1所述的基于用户身份的支付方法，所述支付通道，包括线上支付通道；所述支付请求由所述支付用户通过所述线上支付通道向所述商家系统提交；

其中，所述线上支付通道，包括下述至少一项：商家应用程序中配置的对应所述身份类型的支付接口，商家子程序中配置的对应所述身份类型的支付接口，商家网页中配置的对应所述身份类型的支付接口。

5.根据权利要求1所述的基于用户身份的支付方法，所述支付通道，包括线下支付通道；

所述线下支付通道，包括下述至少一项：商家收银系统配置的与所述身份类型对应的收银接口，商家终端配置的适配所述身份类型的采集单元；

相应的，所述支付请求，通过调用所述收银接口扫描所述支付用户的支付码后提交，或者，通过所述采集单元采集所述支付用户的生物特征并进行生物特征识别后提交。

6.根据权利要求5所述的基于用户身份的支付方法，所述身份类型的身份验证授权，在针对所述支付用户通过线上支付通道提交的携带所述身份类型的历史支付请求进行的支付处理过程中进行。

7.根据权利要求1所述的基于用户身份的支付方法，所述身份类型的身份验证授权，采用如下方式实现：

获取所述支付用户通过授权子程序提交的进行所述身份类型的身份验证的授权请求，并向所述授权子程序返回验证授权页面；

基于所述授权子程序提交的身份信息和授权指令，针对所述支付用户进行所述身份验证的授权处理。

8.根据权利要求7所述的基于用户身份的支付方法，所述基于所述授权子程序提交的身份授权信息，针对所述支付用户进行所述身份验证的授权处理骤执行之后，还包括：

若授权处理失败，生成所述身份验证的信息补充提醒并向所述授权子程序返回；

根据所述身份信息和所述授权子程序提交的补充身份信息，进行所述身份验证的授权处理。

9.根据权利要求1所述的基于用户身份的支付方法，若所述验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配步骤执行之后的执行结果为否，执行如下操作：

按照商家签约配置中与非特定身份类型对应的支付方式进行所述支付请求的支付处理；

或者，

生成所述身份类型的身份验证的信息补充提醒并向所述支付用户的用户终端返回，并获取所述用户终端提交的补充身份信息；

验证基于所述用户身份信息和所述补充身份信息与所述身份类型是否匹配，若是，跳转至所述确定商家签约配置中与所述身份类型对应的支付策略，并按照所述支付策略进行所述支付请求的支付处理步骤执行。

10.根据权利要求1所述的基于用户身份的支付方法，所述用户身份信息，采用如下方式进行获取：

检测所述身份类型是否为域内身份类型；

若是，基于所述身份验证授权在域内数据库查询所述支付用户的身份凭证和/或职业凭证。

11.根据权利要求1所述的基于用户身份的支付方法，所述用户身份信息，采用如下方式进行获取：

通过接口调用向所述身份类型对应的数据平台发送携带所述身份验证授权的授权记录的查询请求；

接收所述第三方数据平台返回的所述支付用户在所述身份类型下的身份信息。

12.根据权利要求1所述的基于用户身份的支付方法，所述确定商家签约配置中与所述身份类型对应的支付策略，并按照所述支付策略进行所述支付请求的支付处理，包括：

在所述支付请求所属的支付类型对应的商家签约配置中，确定与所述身份类型适配的支付权益；

按照所述支付权益进行所述支付请求的支付处理。

13.根据权利要求12所述的基于用户身份的支付方法，所述按照所述支付权益进行所述支付请求的支付处理子步骤执行之后，还包括：

根据所述支付通道的通道类别，确定所述商家签约配置与所述通道类型对应的附加权益；

生成通过线下通道向所述支付用户发放所述附加权益的权益发放任务，和/或，向所述支付用户开通所述附加权益对应的服务权限。

14.一种基于用户身份的支付方法，包括：

根据用户通过商家应用选择的支付通道，向商家系统提交携带所述支付通道对应的身份类型的支付请求；

接收支付平台返回的所述身份类型的验证授权页面，并向所述支付平台提交授权指令以进行身份验证授权；

获取并展示所述支付平台对所述支付请求进行支付处理的支付结果；所述支付处理在基于所述身份验证授权获取的用户身份信息与所述身份类型匹配的情况下，按照商家签约配置中与所述身份类型对应的支付策略进行。

15.根据权利要求14所述的基于用户身份的支付方法，所述接收支付平台返回的所述身份类型的验证授权页面，并向所述支付平台提交授权指令以进行身份验证授权步骤执行之后，且所述获取并展示所述支付平台对所述支付请求进行支付处理的支付结果步骤执行之前，还包括：

接收所述支付平台返回的实际支付金额并展示；所述实际支付金额按照商家签约配置中与所述身份类型对应的支付权益计算获得；

向所述支付平台提交所述支付用户针对所述实际支付金额输入的支付确认指令。

16.根据权利要求14所述的基于用户身份的支付方法，所述支付请求由所述支付用户通过所述线上支付通道向所述商家系统提交；

其中，所述支付通道，包括下述至少一项：

商家应用程序中配置的对应所述身份类型的支付接口，商家子程序中配置的对应所述身份类型的支付接口，商家网页中配置的对应所述身份类型的支付接口。

17.根据权利要求14所述的基于用户身份的支付方法，所述接收支付平台返回的所述身份类型的验证授权页面，并向所述支付平台提交授权指令以进行身份验证授权步骤执行之后，还包括：

接收所述支付平台返回的所述身份类型的身份验证的信息补充提醒；

将所述支付用户针对所述信息补充提醒录入的补充身份信息向所述支付平台提交，以进行所述身份验证的授权处理。

18.一种基于用户身份的支付装置，包括：

支付请求获取模块，被配置为获取商家系统发送的支付用户的支付请求；所述支付请求携带有提交所述支付请求的支付通道对应的身份类型；

授权检测模块，被配置为检测所述支付用户是否进行所述身份类型的身份验证授权；

若是，运行身份类型验证模块；所述身份类型验证模块，被配置为验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配；

若匹配，运行支付处理模块；所述支付处理模块，被配置为确定商家签约配置中与所述身份类型对应的支付策略，并按照所述支付策略进行所述支付请求的支付处理。

19.一种基于用户身份的支付装置，包括：

支付请求提交模块，被配置为根据用户通过商家应用选择的支付通道，向商家系统提交携带所述支付通道对应的身份类型的支付请求；

授权页面接收模块，被配置为接收支付平台返回的所述身份类型的验证授权页面，并向所述支付平台提交授权指令以进行身份验证授权；

支付结果获取模块，被配置为获取并展示所述支付平台对所述支付请求进行支付处理的支付结果；所述支付处理在基于所述身份验证授权获取的用户身份信息与所述身份类型匹配的情况下，按照商家签约配置中与所述身份类型对应的支付策略进行。

20.一种基于用户身份的支付设备，包括：

处理器；以及，被配置为存储计算机可执行指令的存储器，所述计算机可执行指令在被执行时使所述处理器：

获取商家系统发送的支付用户的支付请求；所述支付请求携带有提交所述支付请求的支付通道对应的身份类型；

检测所述支付用户是否进行所述身份类型的身份验证授权；

若是，验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配；

若匹配，确定商家签约配置中与所述身份类型对应的支付策略，并按照所述支付策略进行所述支付请求的支付处理。

21.一种基于用户身份的支付设备，包括：

处理器；以及，被配置为存储计算机可执行指令的存储器，所述计算机可执行指令在被执行时使所述处理器：

根据用户通过商家应用选择的支付通道，向商家系统提交携带所述支付通道对应的身份类型的支付请求；

接收支付平台返回的所述身份类型的验证授权页面，并向所述支付平台提交授权指令以进行身份验证授权；

获取并展示所述支付平台对所述支付请求进行支付处理的支付结果；所述支付处理在基于所述身份验证授权获取的用户身份信息与所述身份类型匹配的情况下，按照商家签约配置中与所述身份类型对应的支付策略进行。

22.一种存储介质，用于存储计算机可执行指令，所述计算机可执行指令在被处理器执行时实现以下流程：

获取商家系统发送的支付用户的支付请求；所述支付请求携带有提交所述支付请求的支付通道对应的身份类型；

检测所述支付用户是否进行所述身份类型的身份验证授权；

若是，验证基于所述身份验证授权获取的用户身份信息与所述身份类型是否匹配；

若匹配，确定商家签约配置中与所述身份类型对应的支付策略，并按照所述支付策略进行所述支付请求的支付处理。

23.一种存储介质，用于存储计算机可执行指令，所述计算机可执行指令在被处理器执行时实现以下流程：

根据用户通过商家应用选择的支付通道，向商家系统提交携带所述支付通道对应的身份类型的支付请求；

接收支付平台返回的所述身份类型的验证授权页面，并向所述支付平台提交授权指令以进行身份验证授权；

获取并展示所述支付平台对所述支付请求进行支付处理的支付结果；所述支付处理在基于所述身份验证授权获取的用户身份信息与所述身份类型匹配的情况下，按照商家签约配置中与所述身份类型对应的支付策略进行。

Images