支付请求处理方法、装置、设备以及存储介质与流程

本申请涉及信息处理技术领域，特别是涉及一种支付请求处理方法、装置、设备及存储介质。

背景技术：

目前所采用的支付方式包括了挂账、现金支付、线上转账支付等方式。其中，挂账是指赊账，一般分为企业赊账和个人赊账。其中，企业赊账是指：当事用户(进行消费行为的用户)不进行支付，而将订单转给与自己有关的第三方(即企业)进行支付的行为。在企业赊账的情况下，第三方可以将订单挂起，在结算时间来临时再进行结算，例如，第三方在一个月的最后一天对挂起的所有订单进行统一支付。目前，企业赊账的结算方式，在餐饮企业、办公用品企业等诸多商家中较为流行。

相关技术中，为了确保挂账的安全性，避免对作为卖方的商家造成损失，商家一般会要求需要第三方赊账的用户在账单上进行手写签名，通过手写签名确定当次消费的用户的身份，以便商家向相关第三方收回欠账。

但是，在通过手写签名进行挂账的过程中，也遇到了一些问题。例如，在要求第三方结算时，对于一些账目需要核实对应的用户的真实身份，而由于手写签名的真伪度难辨，一般需要专业的字迹鉴定才能确定当时消费的用户的真实身份，费时费力且准确度较低，从而造成了挂账安全性低、效率不高的问题。

技术实现要素：

为了解决上述问题，本申请提供了一种支付请求处理方法、装置、设备及存储介质，旨在提高挂账的安全性和效率。

本申请实施例的第一方面，提供了一种支付请求处理方法，所述方法包括：

接收用户终端发送的针对待支付订单的第三方代付请求；

采集所述用户终端的用户的身份特征信息；

根据所述身份特征信息，验证所述用户终端的用户是否具有第三方代支付权限；

根据验证结果，对所述第三方代付请求进行处理。

可选地，根据所述身份特征信息，验证所述用户终端的用户是否具有第三方代付权限，包括：

将所述身份特征信息发送给第三方平台，所述第三方平台存储有多个用户各自的身份特征信息和预先为所述多个用户分别配置的第三方代付权限；

接收所述第三方平台返回的验证结果，所述验证结果表征所述第三方平台是否查询到为所述身份特征信息对应的用户预先配置的第三方代付权限。

可选地，所述方法还包括：

读取并存储第三方平台中的多个用户各自的身份特征信息和预先为所述多个用户分别配置的权限信息；

根据所述身份特征信息，验证所述用户终端的用户是否具有第三方代付权限，包括：

从存储的多个用户各自的身份特征信息和预先为所述多个用户分别配置的权限信息中，查询是否存在为所述身份特征信息对应的用户预先配置的权限信息，以验证所述用户终端的用户是否具有所述第三方代支付权限。

可选地，根据验证结果，对所述第三方代付请求进行处理，包括：

在所述验证结果表明所述用户终端的用户具有第三方代付权限的情况下，向第三方平台发送支付请求，以通过所述第三方平台的账号对所述待支付订单进行支付；

在所述验证结果表明所述用户终端的用户不具有第三方代付权限的情况下，输出支付失败提示。

可选地，在所述验证结果表明所述用户终端的用户具有第三方代付权限的情况下，向第三方平台发送支付请求，包括：

在所述验证结果表明所述用户终端的用户具有第三方代付权限的情况下，确定为所述身份特征信息对应的用户预先配置的附加权限信息，所述附加权限信息包括以下至少一者：单次支付额度金额、总支付额度金额、代支付类型；

验证所述待支付订单的待支付金额是否符合所述附加权限信息；

在所述待支付订单的待支付金额符合所述附加权限信息的情况下，向所述第三方平台发送支付请求。

可选地，采集所述用户终端的用户的身份特征信息，包括：

启动信息采集设备，以对所述用户终端的用户的身份特征信息进行采集，所述身份特征信息包括以下至少一者：人脸特征信息、虹膜特征信息、指纹特征信息、声纹特征信息、工卡特征信息。

本发明实施例的第二方面，提供了一种支付请求处理装置，包括：

请求接收模块，用于接收用户终端发送的针对待支付订单的第三方代付请求；

信息采集模块，用于采集所述用户终端的用户的身份特征信息；

验证模块，用于根据所述身份特征信息，验证所述用户终端的用户是否具有第三方代支付权限；

处理模块，用于根据验证结果，对所述第三方代付请求进行处理。

本申请实施例的第三方面，提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行时实现如第一方面所述的支付请求处理方法。

本申请实施例的第四方面，提供了一种非临时性计算机可读存储介质，当所述存储介质中的指令由处理器执行时，能够执行上述第一方面中任一项所述的支付请求处理方法所执行的操作。

本申请实施例中，在进行支付结算时，可以接收用户终端发送的针对待支付订单的第三方代付请求；并采集用户终端的用户的身份特征信息；根据身份特征信息，验证用户终端的用户是否具有第三方代支付权限；并根据验证结果，对第三方代付请求进行处理。

本实施例中，由于在用户发出第三方代付请求时，需要采集并验证用户的身份特征信息，以确定用户是否具有第三方代付权限。这样，达到了在结算支付时便自动验证用户的真实身份的目的，从而可以根据用户是否具有第三方代付权限的结果，确定是否允许进行第三方代付，例如，允许被挂账的用户可以进行挂账，而不允许被挂账的用户使其不能挂账。如此，从整体上提高了商家进行挂账的安全性和效率，避免给卖买双方造成不必要的损失。

附图说明

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

图1是本申请一实施例示出的一种支付请求处理方法的通信环境示意图；

图2是本申请一实施例示出的一种支付请求处理方法的步骤流程示意图；

图3是本申请一实施例示出的另一种支付请求处理方法的步骤流程示意图；

图4是本申请一实施例示出的又一种支付请求处理方法的步骤流程示意图；

图5是本申请一实施例中的一种支付请求处理装置的结构示意图。

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

相关技术中，为提高挂账的安全性和效率，避免手写签名进行挂账的方式导致了挂账安全性不高、效率低下的问题，还提供了一种挂账的验证方式：手机号码验证，即通过验证手机号的方式对申请挂账的用户进行身份验证，但是此种方式可替代性强、严谨度不够。如果不法分子窃取到第三方中的用户的手机号，便可以进行挂账，因此，仍然不能提高挂账安全性。

有鉴于此，本申请人提出了以下技术构思：在用户发起第三方代付请求时，采集用户的身份特征信息，并对身份特征信息进行验证，以确定用户是否具有第三方支付的权限，进而根据验证结果对第三方代付请求进行相应的处理。

参照图1所示，示出了本实施例中支付请求处理方法所应用的通信环境。如图1所示，包括位于商家的用户终端101和位于第三方的终端设备102，其中，本申请所指的第三方可以是企业机构，例如，工厂、公司、企事业单位等。本申请所指的商家可以是指餐饮、超市等经营商品销售或提供商品服务的商家。其中，该用户终端101配置有信息采集设备1012，该信息采集设备用于采集用户的身份特征信息。

如图1所示，在商家的用户终端101中部署有结算支付系统1011，在第三方的终端设备102中部署有第三方平台1021。结算支付系统1011与第三方平台1021之间可以进行网络通信，以进行数据的交互。

其中，结算支付系统1011可以是但是不限于：餐饮收银系统、商超收银系统，其用于对产生的待支付订单进行结算，以对用户的消费行为进行结算，其中产生的待支付订单可以是工作人员根据用户的实际消费而输入的。实际中，该结算支付系统1011可以支持多种结算方式，如：现金结算、转账结算、第三方挂账结算。

其中，第三方平台1021中存储有多个用户的用户信息，该用户信息可以至少包括用户的身份特征信息、用户的职位信息，并可以用于进行身份特征信息的比对。其中，职位信息可以包括用户所属的部门、职称等信息，其中，对身份特征信息进行比对和验证可以是指：第三方平台1021与结算支付系统相互配合，将采集的身份特征信息与存储的多个用户的身份特征信息进行比对，从而得到验证结果。

本实施例中，结算支付系统1011在接收到用户发出的需要第三方支付的第三方代付请求时，可以通过与第三方平台1021之间的数据交互，实现安全高效的挂账结算。

结合图1所示的通信环境，对本申请的支付请求处理方法进行详细介绍，参照图2所示，示出了一实施例中的支付请求处理方法的步骤流程图，如图2所示，具体可以包括以下步骤：

步骤s201：接收用户终端发送的针对待支付订单的第三方代付请求。

本实施例中，用户终端101可以是平板、电脑等智能设备，待支付订单可以是用户在商家产生的消费所对应的订单，实际中，该待支付订单可以是商家的用户终端101发送的。例如，用户在商家进行了餐饮消费，则商家可以将所产生的待支付订单输入用户终端，以使用户进行支付。

其中，第三方代付请求可以是指用户终端针对用户所选择的代付方式而生成的，该第三方代付请求表征着用户需要通过第三方对该待支付订单进行支付。具体实施时，待支付订单中可以携带供用户选择的多种支付方式，例如，现金结算、银行转账结算、第三方代付(即挂账)等。

步骤s202：采集所述用户终端的用户的身份特征信息。

本实施例中，在检测到用户终端101发送的是第三方代付请求时，便可以启动挂账的支付流程，先采集用户终端101的用户的身份特征信息。其中，用户终端101的用户可以是指到商家进行消费，需要通过商家的用户终端101进行订单结算的用户。身份特征信息可以用于表征用户的真实身份，可以包括但是不限于以下信息：人脸特征信息、虹膜特征信息、指纹特征信息、声纹特征信息、工卡特征信息。其中，工卡特征信息可以是指第三方为用户所配置的卡片上所集成的信息，该开卡片用于标识用户是第三方所管辖的用户。

具体实施时，可以由用户终端101采集用户的身份特征信息，然后上传至结算支付系统1011。其中，在由商家采集用户的身份特征信息时，在一种可选示例中，商家的用户终端101可以启动自身配置的信息采集设备1012，信息采集设备1012采集用户终端的用户的身份特征信息，该图像采集设备1012可以外接到用户终端101或内置在用户终端101中，本申请实施例不对其进行限制。

其中，在由商家的用户终端101采集用户的身份特征信息时，用户则必须到店验证，此种情况下，由于用户必须到商家进行验证，则可以进一步确保第三方中的用户的消费真实性，避免第三方的用户远程为其他非第三方的用户进行代验证，例如，避免第三方的用户为自己好友所产生的消费进行远程代验证，而为第三方造成损失的问题，从而进一步提高了挂账安全性。

可以理解的是，信息采集设备1012可以随着所要采集的身份特征信息的不同而不同。例如，身份特征信息是工卡特征信息时，信息采集设备可以是nfc类型的读卡器，身份特征信息是人脸特征信息、虹膜特征信息时，信息采集设备可以是照相机，身份特征信息是指纹特征信息时，信息采集设备可以是指纹采集设备。当然，实际中，信息采集设备1012可以集成多种信息采集装置，例如，集成有摄像头、指纹采集装置和读卡器。

当然，实际中，身份特征信息可以不限于上述信息，也可以是身份证信息，此种情况下，信息采集设备可以是身份证读卡器。用户可以将自己的身份证放入信息采集设备，以使信息采集设备读取身份证中集成的身份信息。

又可以理解的是，若用户终端的用户发送的并不是第三方代付请求，则无需采集用户的身份特征信息，进而，进入实时结算的支付流程，以使用户进行现场结算。例如，用户选择了银行转账支付，则可以在用户终端101中的结算支付系统1011中展示支付页面，以在支付页面中进行支付结算，或者，可以在用户终端101的结算支付系统1011中展示支付二维码，用户可以通过自身携带的智能设备扫描二维码进入支付页面，以进行即时支付结算。

步骤s203：根据所述身份特征信息，验证所述用户终端的用户是否具有第三方代支付权限。

本实施例中，可以对身份特征信息进行验证，具体实施时，可以将该身份特征信息与第三方提供的多个身份特征信息进行比对，以确定该用户是否具有第三方支付权限，该第三方支付权限可以理解为是：第三方为用户所设置的允许挂账的权限。

本实施例中，用户终端的用户是指到店进行消费的用户，也就是需要对待支付订单进行支付的用户。

步骤s204：根据验证结果，对所述第三方代付请求进行处理。

本实施例中，验证结果可以包括用户具有第三方支付权限的结果、用户(即需要对待支付订单进行支付的用户)不具有第三方支付权限的结果，则可以根据所得到的验证结果的不同，对用户终端所发送的第三方代付请求进行不同的处理。例如，验证结果是用户具有第三方支付权限的结果，则允许用户利用第三方进行代付(即挂账)。验证结果是用户不具有第三方支付权限的结果，则不允许用户利用第三方进行代付。

采用本发明实施例的技术方案，至少具有以下优点：

一方面，由于在用户针对待支付订单发出第三方代付请求时，商家便采集可以表征用户真实身份的身份特征信息，对该身份特征信息进行验证，以确定用户终端的用户(需要对待支付订单进行支付的用户)是否具有第三方支付权限，进而根据用户是否具有第三方支付权限的结果，对用户发送的第三方代付请求进行处理。这样，在用户进行挂账时，便即时验证了用户的真实身份，从而避免通过手写签名进行挂账时，后续进行身份验证准确率不高、效率低下的问题。

另一方面，由于利用的是用户的身份特征信息进行验证，其身份特征信息可以表征用户的真实身份，从而相比于手写签名，本申请能提高身份验证的准确度，也可以避免不法分子冒充消费的风险。

其中，如图1所示，由于对身份特征信息进行比对和验证可以是指：第三方平台1021与结算支付系统1011相互配合，将接收到的身份特征信息与存储的多个用户的身份特征信息进行比对，而得到验证结果。

因此，第三方平台1021与用户终端101的结算支付系统1011采取不同的配合方式，其对用户的身份进行验证的具体举措也可以不同。

在一种示例性实施例a中，在进行第三方代付权限的验证时，结算支付系统1011可以实时向第三方平台1021发出验证请求，以在第三方平台1021中进行第三方代付权限的验证。

在又一种示例性实施例b中，位于商家的结算支付系统1011可以同步第三方平台1021中存储的用户信息，如此，在进行第三方代付权限的验证时，结算支付系统1011可以基于自身同步的用户信息进行验证。

下面，对示例性实施例a进行说明。

参照图3所示，示出了该示例中的一种支付请求处理方法的步骤流程图，如图3所示，该支付请求处理方法可以应用于商家的结算支付系统1011中，具体可以包括以下步骤：

步骤s301：接收用户终端发送的针对待支付订单的第三方代付请求。

本实施例中，步骤s301的过程可以与步骤s201的过程类似，相关过程参见步骤s201的描述即可，在此不再赘述。

步骤s302：采集所述用户终端的用户的身份特征信息。

本实施例中，步骤s302的过程可以与步骤s202的过程类似，相关过程参见步骤s202的描述即可，在此不再赘述。

步骤s303：将所述身份特征信息发送给第三方平台1021，所述第三方平台1021存储有多个用户各自的身份特征信息和预先为所述多个用户分别配置的第三方代付权限。

本实施例中，商家的结算支付系统1011可以将所采集得到的身份特征信息发送给第三方平台1021，此种情况下，由于第三方平台1021存储有用户的用户信息，用户信息中可以包括用户的身份特征信息，则第三方平台1021可以将结算支付系统1011发送的身份特征信息与自身预存的多个用户各自的身份特征信息进行比对，以得到比对结果。

具体实施时，在进行身份特征信息的比对时，可以根据身份特征信息的类型选择相应的匹配方式进行匹配。例如，身份特征信息是人脸特征信息、指纹特征信息、虹膜特征信息时，则可以利用相应的相似度计算方法确定二者之间的相似度，从而根据相似度确定二者是否属于同一用户。其中，相似度计算方法可以为余弦相似度计算方法。

其中，第三方平台1021在确定自身存储的各身份特征信息中存在与结算支付系统1011发送的身份特征信息一致的信息时，则可以确定需要对待支付订单进行支付的用户是属于第三方中的用户。本实施例中，由于第三方平台中可以为每个用户配置代付权限，因而，在确定用户终端101的用户(需要对待支付订单进行支付的用户)是属于第三方中的用户时，第三方平台1021便可以查询到第三方为该用户所配置的第三方代付权限。

其中，第三方平台1021在确定自身存储的各身份特征信息中不存在与结算支付系统1011发送的身份特征信息一致的信息时，则可以确定用户终端101的用户(需要对待支付订单进行支付的用户)不是属于第三方中的用户，此种情况下，很显然，用户终端101的用户不能请求第三方对该待支付订单进行支付，即不具备第三方代付权限。

步骤s304：接收所述第三方平台返回的验证结果，所述验证结果表征所述第三方平台是否查询到为所述身份特征信息对应的用户预先配置的第三方代付权限。

实际中，无论用户终端101的用户(需要对待支付订单进行支付的用户)是否是属于第三方的用户，第三方平台1021都可以将验证结果返回给结算支付系统1011。其中，验证结果中可以携带所查询到的第三方为用户终端的用户预先配置的第三方代付权限的结果。例如，“0”表示未查询到用户终端的用户(需要对待支付订单进行支付的用户)被第三方预先配置有第三方代付权限；“1”表示查询到用户终端的用户(需要对待支付订单进行支付的用户)被第三方预先配置有第三方代付权限。

其中，在查询到用户终端101的用户(需要对待支付订单进行支付的用户)被第三方预先配置有第三方代付权限时，则可以转步骤s305进行处理；在未查询到用户终端的用户(需要对待支付订单进行支付的用户)被第三方预先配置有第三方代付权限时，则可以转步骤s306进行处理。

步骤s305：在所述验证结果表明所述用户终端的用户具有第三方代付权限的情况下，向第三方平台发送支付请求，以通过所述第三方平台的账号对所述待支付订单进行支付。

本实施例中，商家的结算支付系统1011可以向第三方平台1021发送支付请求，该支付请求中可以携带待支付订单，其中，待支付订单中可以包括消费明细和结算额度。

其中，在一种具体示例中，第三方平台1021针对支付请求，可以将待支付订单进行存储，以方便在后续的结算时间，通过自身的账号对待支付订单进行支付。此种情况下，第三方平台1021可以在存储待支付订单后，向结算支付系统1011反馈挂账信息，则结算支付系统1011可以根据反馈的挂账信息，将待支付订单标记为挂账订单，以表征该待支付订单是等待第三方支付的订单。当然，在第三方平台1021在结算时间支付完成待支付订单的支付后，也可以向结算支付系统1011反馈支付已完成的信息，这样，结算支付系统1011可以根据支付已完成的信息，将标记为挂账订单的待支付订单变更为已支付订单。

其中，在又一种具体示例中，第三方平台1021针对支付请求，可以即时通过自身的账号对该待支付订单进行支付。此种情况下，第三方平台1021可以在支付完成后，向用户终端101的结算支付系统1011反馈支付信息，则结算支付系统1011可以根据反馈的支付信息，将待支付订单标记为已支付订单，以表征该待支付订单已经由第三方完成支付。

实际中，第三方可以包括众多用户，但是，并不是每个用户都可以挂账，且随着用户的职位的不同，其允许挂账的金额额度也可以不同。因此，第三方还可以为每个用户设置一个附加权限信息，在第三方平台1021中便可以将该附加权限信息与每个用户的身份特征信息进行关联存储。

相应地，在一种可选示例中，在所述验证结果表明所述用户终端的用户，即需要对待支付订单进行支付的用户具有第三方代付权限的情况下，还可以进一步确定为所述身份特征信息对应的用户预先配置的附加权限信息，所述附加权限信息包括以下至少一者：单次支付额度金额、总支付额度金额、代支付类型；并验证所述待支付订单的待支付金额是否符合所述附加权限信息；在所述待支付订单的待支付金额符合所述附加权限信息的情况下，向所述第三方平台发送支付请求。

本可选示例中，附加权限信息主要用于约束用户进行第三方代付的范围，包括了单次支付额度金额、总支付额度金额、代支付类型。其中，待支付类型可以是指：所消费的商品的类型，例如，餐饮类型、办公耗材类型、家用用品类型等。单次支付额度金额可以是指单次的订单所针对的金额上限、总支付额度金额可以是指用户总共所具有的代付金额上限。例如，用户的总支付额度金额为1万，则用户一年之内只能挂账1万的金额。

此种可选示例中，待支付订单中便可以携带该订单的消费金额、商品类型。其中，第三方平台1021可以将待支付订单中的消费金额、商品类型分别与附加权限信息中的单次支付额度金额、支付类型相比较，以确定该待支付订单是否符合第三方为用户设置的附加权限。具体而言，只有在待支付订单中的消费金额小于单次支付额度金额，且商品类型与支付类型一致时，确定用户终端的用户符合附加权限信息。

其中，第三方平台1021还可以将待支付订单中的消费金额、商品类型分别与附加权限信息中的单次支付额度金额、支付类型、总支付额度金额相比较，以确定该待支付订单是否符合第三方为用户设置的附加权限。具体而言，第三方平台1021可以调取用户在历史时段内所挂账的总历史消费金额，这样，只有在待支付订单中的消费金额小于单次支付额度金额、商品类型与支付类型一致、且总历史消费金额与待支付订单中的消费金额之和小于总支付额度金额时，确定用户终端的用户，即需要对待支付订单进行支付的用户符合附加权限信息。

采用此种可选示例的技术方案时，第三方可以限定用户的代付权限的范围，这样，可以避免给第三方或者商家造成不必要的经济损失。

实际中，当用户终端的用户，即需要对待支付订单进行支付的用户符合附加权限信息时，表征用户终端的用户具有第三方代付权限，结算支付系统1011则可以向第三方平台1021发送支付请求，以使第三方平台1021对待支付订单进行支付。

步骤s306：在所述验证结果表明所述用户终端的用户不具有第三方代付权限的情况下，输出支付失败提示。

本实施例中，在用户终端的用户，即需要对待支付订单进行支付的用户不具有第三方代付权限的情况下，结算支付系统1011可以输出支付失败提示，以提示工作人员此待支付订单不允许第三方代付。

其中，在输出支付失败提示时，也可以跳转到即时支付页面，以便即时对待支付订单进行支付。其中，即时支付页面可以支持用户进行银行转账支付、现金支付、扫描二维码支付等。

需要说明的是，在用户完成支付时，结算支付系统1011可以根据结算成功的结果将待支付订单标记为已结算订单。

下面，对示例性实施例b进行说明。

参照图4所示，示出了该实施例的一种支付请求处理方法的步骤流程图，如图4所示，支付请求处理方法可以应用于结算支付系统1011，具体可以包括以下步骤：

步骤s401：读取并存储第三方平台中的多个用户各自的身份特征信息和预先为所述多个用户分别配置的权限信息。

本实施例中，结算支付系统1011可以定时同步第三方平台1021上存储的多个用户各自的身份特征信息和相应的权限信息。其中，权限信息可以表征相应的用户是否拥有第三方代付权限。当然，实际中，第三方平台1021也可以在检测到自身的用户的身份特征信息发生变更或者权限信息发生变更时，向结算支付系统1011同步变更后的用户的身份特征信息和相应的权限信息。

步骤s402：接收用户终端发送的针对待支付订单的第三方代付请求。

本实施例中，步骤s402的过程可以与步骤s201的过程类似，相关过程参见步骤s201的描述即可，在此不再赘述。

步骤s403：采集所述用户终端的用户的身份特征信息。

本实施例中，步骤s403的过程可以与步骤s202的过程类似，相关过程参见步骤s202的描述即可，在此不再赘述。

步骤s404：从存储的多个用户各自的身份特征信息和预先为所述多个用户分别配置的权限信息中，查询是否存在为所述身份特征信息对应的用户预先配置的权限信息，以验证所述用户终端的用户，即需要对待支付订单进行支付的用户是否具有所述第三方代支付权限。

本实施例中，结算支付系统1011可以直接从本地获取到第三方所提供的多个用户的身份特征信息和相应的权限信息，并将采集到的身份特征信息与多个用户的身份特征信息进行比对，进而根据比对结果和相应的权限信息，得到用户终端的用户是否具有第三方代付权限的验证结果。

具体实施时，结算支付系统1011可以从用户终端101的本地存储中查询是否存在与采集到的身份特征信息相一致的身份特征信息，若不存在，则获得用户终端的用户不具有第三方代付权限的验证结果。若存在，则进一步获取所匹配成功的身份特征信息对应的权限信息，根据该权限信息中的权限设置确定用户终端的用户，即需要对待支付订单进行支付的用户是否具有第三方代付权限。例如，权限设置表征用户具有第三方代付权限，则获得验证通过的结果，若权限设置表征用户不具有第三方代付权限，则获得验证不通过的结果。

可选地，权限信息中也可以包括附加权限信息，具体地，该附加权限信息的相关描述可以参照上述步骤s305中相关过程所述，在此不再赘述。如此，结算支付系统1011可以确定待支付订单中的待支付金额、商品类型是否附加权限信息，若是，则获得用户具有第三方代付权限的验证结果，若否，则获得用户不具有第三方代付权限的验证结果。

步骤s405：根据验证结果，对所述第三方代付请求进行处理。

本实施例中，在验证结果为确定用户终端的用户具有第三方代付权限时，便允许待支付订单进行第三方代付，从而可以向第三方平台1021发送支付请求，以使第三方平台1021对该待支付订单进行支付。其中，第三方平台1021对待支付订单的支付过程可以参照步骤s305中的相关描述即可，在此不再赘述。

当然，在验证结果为确定用户终端的用户，即需要对待支付订单进行支付的用户不具有第三方代付权限时，便可以进行即时支付，即现场支付待支付订单。

采用本发明实施例的技术方案，至少具有以下优点：

一方面，由于在用户针对待支付订单发出第三方代付请求时，对所采集的用户的身份特征信息进行验证，使得可以快速、准确地获得用户的真实身份信息，从而避免通过手写签名进行挂账时，对手写签名的验证过程繁琐、准确低的问题，也避免了冒充性消费的问题。

另一方面，由于在验证用户是否具有第三方代付权限时，设置了附加权限信息的验证，通过附加权限信息可以将用户的挂账权限限制在合理的范围，使得挂账验证更为严格，从而避免了用户无节制进行第三方代付时，对商家和第三方所造成的经济损失。

再一方面，由于本申请的身份特征信息的验证既可以在商家的结算支付系统1011中进行验证，也可以在第三方平台1021中进行验证，这样，可以根据商家和企业的不同验证需求，提供更多更灵活的身份验证对接方法，使挂账消费身份验证更加准确，降低消费中存在的风险。

基于与上述实施例同一发明构思，参照图5所示，示出了本实施例的一种支付请求处理装置的结构框图，所述装置具体可以包括以下模块：

请求接收模块501，用于接收用户终端发送的针对待支付订单的第三方代付请求；

信息采集模块502，用于采集所述用户终端的用户的身份特征信息；

验证模块503，用于根据所述身份特征信息，验证所述用户终端的用户是否具有第三方代支付权限；

处理模块504，用于根据验证结果，对所述第三方代付请求进行处理。

可选地，所述验证模块503可以包括以下单元：

发送单元，用于将所述身份特征信息发送给第三方平台，所述第三方平台存储有多个用户各自的身份特征信息和预先为所述多个用户分别配置的第三方代付权限；

接收单元，用于接收所述第三方平台返回的验证结果，所述验证结果表征所述第三方平台是否查询到为所述身份特征信息对应的用户预先配置的第三方代付权限。

可选地，所述装置还可以包括以下模块：

读取模块，用于读取并存储第三方平台中的多个用户各自的身份特征信息和预先为所述多个用户分别配置的第三方代付权限；

所述验证模块503，具体可以用于从存储的多个用户各自的身份特征信息和预先为所述多个用户分别配置的权限信息中，查询是否存在为所述身份特征信息对应的用户预先配置的权限信息。

其中，在本可选示例中，根据上述方法实施例性实施例a，商家实时向第三方平台请求验证用户的第三方代付权限时，此种情况下，验证模块503可以位于第三方平台1021中。根据上述方法示例性实施例b，商家可以同步第三方平台1022中的用户信息，此种情况下，验证模块503中可以位于商家的结算支付系统1011中。

可选地，所述处理模块504，具体可以包括以下单元：

第一处理单元，用于在所述验证结果表明所述用户终端的用户具有第三方代付权限的情况下，向第三方平台发送支付请求，以通过所述第三方平台的账号对所述待支付订单进行支付；

第二处理单元，用于在所述验证结果表明所述用户终端的用户不具有第三方代付权限的情况下，输出支付失败提示。

再可选地，所述第一处理单元具体可以包括以下子单元：

确定子单元，用于在所述验证结果表明所述用户终端的用户具有第三方代付权限的情况下，确定为所述身份特征信息对应的用户预先配置的附加权限信息，所述附加权限信息包括以下至少一者：单次支付额度金额、总支付额度金额、代支付类型；

验证子单元，用于验证所述待支付订单的待支付金额是否符合所述附加权限信息；

支付发送子单元，用于在所述待支付订单的待支付金额符合所述附加权限信息的情况下，向所述第三方平台发送支付请求。

可选地，所述信息采集模块502，具体用于启动信息采集设备，以对所述用户终端的用户的身份特征信息进行采集，所述身份特征信息包括以下至少一者：人脸特征信息、虹膜特征信息、指纹特征信息、声纹特征信息、工卡特征信息。

需要说明的是，装置实施例与方法实施例相近，故描述的较为简单，相关之处参见方法实施例即可。

本申请实施例还提供了一种电子设备，该电子设备可以用于执行视频流处理方法，可以包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器被配置为执行所述的支付请求处理方法。

本申请实施例还提供了一种非临时性计算机可读存储介质，当所述存储介质中的指令由处理器执行时，使得所述处理器能够执行一种以实现本申请上述的支付请求处理方法所执行的操作。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

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

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

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

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

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

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种支付请求处理方法、装置、设备以及存储介质，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。