具体实施方式

为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围，而是仅仅表示本公开的选定实施例。基于本公开的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

本文中术语“和/或”，仅仅是描述一种关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合，例如，包括A、B、C中的至少一种，可以表示包括从A、B和C构成的集合中选择的任意一个或多个元素。

经研究发现，在进行人脸支付的过程中，往往需要接入具有刷脸支付功能的支付设备，在这一支付设备中展示人脸以进行支付操作。由于支付本身的严谨性，需要经过比较复杂的验证，目前市面上的支付设备大都采用云端识别的方式，也就是在支付终端进行人脸采集，然后送至云端进行识别并支付。

然而，在支付终端比较多的情况下，上述方式会导致云端的识别压力比较大，将造成比较长的支付延迟，降低服务质量。

基于上述研究，本公开提供了一种支付方法、系统、电子设备及存储介质，以提升支付效率。

为便于对本实施例进行理解，首先对本公开实施例所公开的一种支付方法进行详细介绍，本公开实施例所提供的支付方法的执行主体一般为具有一定计算能力的计算机设备，该计算机设备例如包括：终端设备或其它处理设备，终端设备可以为用户设备(UserEquipment，UE)、移动设备、用户终端、终端、蜂窝电话、无绳电话、个人数字助理(PersonalDigital Assistant，PDA)、手持设备、计算设备、车载设备、可穿戴设备等。在一些可能的实现方式中，该支付方法可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。

参见图1所示，为本公开实施例提供的支付方法的流程图，方法包括步骤S101～S104，其中：

S101：响应支付请求，获取待支付用户的待识别人脸图片，并提取待识别人脸图片的待识别人脸特征；

S102：读取本地人脸特征库中各个合法用户的预存人脸特征；合法用户包括在本地终端设备的支付行为第一满足预设条件的用户；

S103：将预存人脸特征与待识别人脸特征进行比对，确定比对结果；

S104：将比对结果发送至服务器，其中，服务器用于根据比对结果进行支付。

这里，为了便于理解本公开实施例提供的支付方法，接下来首先对该支付方法的应用场景进行简单说明。上述支付方法主要可以应用于各种支付场景中，且主要可以是应用于人脸支付中，例如，可以应用于无人超市场景中。

在进行人脸支付的过程中，往往需要接入具有刷脸功能的终端设备。在终端设备进行人脸采集后，可以送到云端进行身份验证，并能够在身份验证通过后进行支付。然而，在支付设备比较多的情况下，上述方式会导致云端的识别压力比较大，将造成比较长的支付延迟，降低服务质量。

正是为了解决上述问题，本公开实施例才提供了一种支付方法、系统、电子设备及存储介质，以提升支付效率。

这里，可以基于获取的待识别人脸图片提取出待识别人脸特征，并能够读取本地人脸特征库中各个合法用户的预存人脸特征，这样，在将预存人脸特征与待识别人脸特征进行比对之后，可以将比对结果发送至服务器以使服务器基于比对结果完成支付过程。

其中，待识别人脸图片可以是利用本地终端设备上设置的摄像头采集的，也即，在具有支付请求的情况下，摄像头可以启动采集操作对待支付用户的人脸进行捕捉。不同的应用场景所对应的待支付用户也不同，在此不再赘述。

在本地终端设备捕捉到人脸的情况下，可以提取待识别人脸图片的待识别人脸特征，并将待识别人脸特征与本地人脸特征库中各个合法用户的预存人脸特征进行比对。这里，可以基于每两个特征之间的相似度来确定待支付用户是否为合法用户，并能够在确定待支付用户为合法用户的情况下，将这一比对结果通知给服务器以便于服务器完成后续的支付过程，还能够在确定待支付用户为非法用户的情况下，直接将待识别人脸图片发送给服务器以便于服务器再次进行身份比对，并能够在身份比对成功的情况下，完成后续的支付过程。

可知的是，本公开实施例提供的支付方法首选在本地终端设备侧完成身份比对，这样，即使本地终端设备比较多，也不会导致因为需要在服务器侧排队进行身份比对所带来的耗时问题，显著提升了后续的支付效率。

除此之外，本公开实施例还能够在本地终端设备比对失败的情况下，利用服务器再次进行身份比对，这主要是考虑到服务器往往具有更强的算力和更丰富的数据资源，从而可以提升比对成功率，确保支付的安全性。

这里的本地人脸特征库收集的可以是各个合法用户的预存人脸特征，合法用户则可以包括在本地终端设备的行为满足预设条件的用户。例如，可以是预先在本地终端设备进行注册的用户，还可以是经常在本地终端设备上进行支付的用户等，还可以是其它满足预设条件的用户，本公开实施例在此不做具体的限制。

本公开实施例提供的支付方法，在确定比对结果指示比对失败的情况下，可以将比对结果以及获取的待识别人脸图片发送至服务器。

在具体应用中，可以在本地终端设备比对失败的情况下，向服务器发送携带有待识别人脸图片的特征比对请求。服务器在接收到特征比对请求的情况下，可以基于待识别人脸图片进行比对成功的情况下，触发服务器完成支付过程。

需要说明的是，随着比对结果指示比对失败的信息的发送，不仅可以同时发送的是待识别人脸图片，还可以同时发送的是从待识别人脸图片中提取的人脸框图，该人脸框图对应待支付用户的人脸区域。

在同时发送待识别人脸图片的情况下，可以在服务器侧进行人脸框图提取，人脸特征提取，特征比对等一系列操作进而完成支付过程，在同时发送的是人脸框图的情况下，可以直接进行人脸特征提取，特征比对等一系列操作。

本公开实施例提供的支付方法，在确定比对结果指示比对失败的情况下，还可以在本地终端设备获取待支付用户的账户信息，并将比对结果以及账户信息发送至服务器。

这里的账户信息可以是与待支付用户的待扣款账户的相关信息，例如，可以是银行卡号信息，第三方支付平台的用户名信息等，这样，服务器通过本地终端设备发送的账户信息可以向相应的扣款平台发起扣款指令，并执行最终的扣款动作，完成支付过程。

在实际应用中，考虑到图像背景信息对人脸真伪性判断的关键作用，可以是直接将待识别人脸图片发送至服务器以使服务器完成一系列的身份比对以及支付操作，进一步确保支付的安全性。

除此之外，本公开实施例在比对结果指示比对成功的情况下，还可以从获取的待识别人脸图片中提取人脸框图，并将提取的人脸框图发送至服务器进行存档。这主要是考虑到在实际的业务场景中，支付操作涉及用户财产，一旦出现问题，往往需要及时的回溯出现支付问题的原因，而小图(即人脸框图)的存档，可以帮助支付结果的核对，且小图经由本地终端设备传输到服务器，也不会占用过大的网络带宽。

需要说明的是，在实际应用中，不仅可以利用人脸框图存档，也可以直接利用待识别人脸图片进行存档。

本公开实施例中的本地人脸特征库包括的各个预存人脸特征，可以是相关用户在本地终端设备进行注册后确定的，也可以是服务器基于相关用户的支付行为确定的，接下来可以进一步进行说明。

本公开实施例提供的支付方法可以按照如下步骤构建本地人脸特征库：

步骤一、接收在本地终端设备上发起的第一用户的注册请求；

步骤二、响应注册请求，获取第一用户的多张第一人脸图片；

步骤三、将多张第一人脸图片输入至人脸质量检测模型，获得人脸质量检测结果；

步骤四、根据人脸质量检测结果，从多张第一人脸图片中，确定质量分数最高的目标人脸图片，并从目标人脸图片中提取第一人脸特征；

步骤五、根据第一人脸特征，创建本地人脸特征库，其中，预存人脸特征包括第一人脸特征。

这里，可以响应第一用户的注册请求，获取第一人脸图片，在从第一人脸图片中提取出人脸特征的情况下，可以将第一人脸特征存储在本地人脸特征库。

在具体应用中，本地终端设备可以支持用户录入，例如，可以通过摄像头采集录入人脸图片。通常情况下，针对一个用户可以录入多张人脸图片。为了进一步提升后续进行特征比对的准确性，这里，可以基于预先训练好的人脸质量检测模型对第一用户对应的多张第一人脸图片进行人脸质量打分，这里，可以选取质量分数最高的一张人脸图片。

其中，上述人脸质量检测模型用于基于人脸图片的清晰度、完整度、曝光度等分析来确定与图片质量相关的特征，并基于这些特征确定图片质量得分。

在本地终端设备录入相关信息的用户默认会经常在该设备支付，成功录入人脸图片并选取出目标人脸图片的情况下，即可以将这一人脸图片的第一人脸特征加入本地人脸特征库。

与此同时，本公开实施例还支持录入其它信息，例如，通过键盘录入人员账户信息等。这里，可以将人脸图片、人脸特征以及对应的账户信息同步至服务器，以保持服务器与本地终端设备的同步，便于服务器进行多设备管理。

在实际应用中，为了进一步确保本地人脸特征库中所存储的人脸特征对应用户的合法性，在接收注册请求之后，可以利用身份标识信息对第一用户进行注册权限的验证，具体可以通过如下步骤来实现：

步骤一、获取第一用户的身份标识信息；

步骤二、基于身份标识信息，判断第一用户是否具备在本地终端设备上进行注册的权限；

步骤三、若第一用户具备在本地终端设备上进行注册的权限，确定第一用户为合法用户，并响应注册请求，获取第一用户的多张第一人脸图片。

这里，可以基于身份标识信息验证第一用户是否具备注册权限。在进行注册权限验证之前，可以预先为本地终端设备绑定具备注册权限的用户标识，这里的用户可以是本地终端设备的拥有者，也可以是本地终端设备的管理者，还可以其它具有注册权限的用户。

本公开实施例中，还可以基于用户的常住地与本地终端设备所属的地理位置之间的一致性来确定是否进行人脸特征入库操作，也即，若第一用户的常住地与本地终端设备所属的地理位置一致，一定程度上说明在本地终端设备上进行人脸特征录入的合理性，例如，对于小区便利店设置的本地终端设备而言，第一用户可以是小区住户。进而，可以根据第一人脸特征，创建本地人脸特征库，从而进一步确保了后续进行人脸核对的安全性。

本公开实施例中，可以按照如下步骤更新本地人脸特征库：

步骤一、接收服务器发送的用户特征存储指令；用户特征存储指令中包括至少一个第二用户的第二人脸特征，第二用户为在本地终端设备上的支付行为数据满足第二预设条件的用户；支付行为数据包括支付频率和/或支付次数；

步骤二、将第二人脸特征存储至本地人脸特征库。

这里的第一预设条件可以是支付频率高于预设频率、支付次数大于预设次数这一条件。也即，本公开可以是在服务器确定某些用户(即第二用户)经常在本地终端设备进行支付的情况下，自动把这些用户的人脸特征同步至该终端设备的本地人脸特征库，以提升比对速度。

在实际应用中，还需要评估本地人脸特征库当前的剩余存储量是否大于或等于待存储的第二人脸特征的数据量，若本地人脸特征库当前的剩余存储量大于或等于第二人脸特征的数据量，将第二人脸特征存储至本地人脸特征库；若本地人脸特征库当前的剩余存储量小于第二人脸特征的数据量，根据第二预设条件，从本地人脸特征库中删除部分人脸特征，并将第二人脸特征存储至本地人脸特征库。这里，可以删除支付频率比较低、支付次数比较少的用户的人脸特征。

本公开实施例中，还可以按照如下步骤更新本地人脸特征库：

步骤一、接收服务器发送的针对至少一个第三用户的特征删除指令；第三用户为支付行为数据满足第三预设条件的用户；支付行为数据包括支付频率和/或支付次数；

步骤二、从本地人脸特征库中删除第三用户的人脸特征，得到更新后的本地人脸特征库。

这里的第三预设条件可以是支付频率低于或等于预设频率、支付次数小于或等于预设次数这一条件，除此之外，还可以是距离当前时间的支付时长超过预设时长这一条件。也即，本公开可以是在服务器确定某些用户(即第三用户)长期不在该本地终端设备进行支付，并且该用户在本地人脸特征库的情况，从本地人脸特征库中删除该用户的人脸特征，以在本地维持一个相对固定的数据规模，确保本地终端设备的存储空间足够使用。

需要说明的是，在实际应用中，可以在服务器侧保留第三用户的信息，以便在有需要进行信息同步的情况下，及时的进行信息同步。

为了进一步提升人脸比对的效率，本公开实施例提供的支付方法可以基于人脸特征聚类建立特征子库，进而基于特征子库的特征比对实现快速的人脸比对。

其中，上述建库方案具体可以通过如下步骤来实现：

步骤一、确定第一用户所属的用户类型；

步骤二、根据用户类型，对第一人脸特征进行聚类，获得多个分类组；

步骤三、为每个分类组创建特征子库；

步骤四、根据多个特征子库，构建本地人脸特征库。

这里，可以基于用户类型，进行人脸特征比对，进而基于每个分类组对应的特征子库创建本地人脸特征库。

其中，上述用户类型可以是基于不同的应用场景来确定的。以无人超市这一场景为例，这里的用户类型可以是学生、家长、老人等类型，针对不同的学生类型，所对应的第一人脸特征也不相同，进而可以入库到不同的本地人脸特征库。

另外，在进行人脸特征聚类的过程中，还可以结合用户的偏好等信息进行聚类，这里可以采用K-means等聚类方法实现聚类，这里不做赘述。

基于构建有不同特征子库的本地人脸特征库而言，这里可以按照如下方法进行特征比对：

步骤一、基于待支付用户所属的用户类型，确定与待识别人脸特征对应的特征子库；

步骤二、确定待识别人脸特征与确定的特征子库中的各个预存人脸特征之间的相似度；

步骤三、在特征子库中存在相似度大于预设阈值的合法用户的情况下，确定比对成功；在特征子库中不存在相似度大于预设阈值的合法用户的情况下，确定比对失败。

这里，可以可基于用户类型锁定与待支付用户对应的特征子库，进而确定特征子库中的每个预存人脸特征与待识别人脸图片的待识别人脸特征之间的相似度，相似度越高，说明比中的可能性也越高，反之，相似度越低，说明比中的可能性也越低。这里，可以在在特征子库中存在相似度大于预设阈值的合法用户的情况下，确定比对成功，以完成身份比对，还可以在特征子库中不存在相似度大于预设阈值的合法用户的情况下，确定比对失败，并向服务器发起再次进行比对的请求以完成后续的支付过程。

这里的特征相似度可以是基于余弦公式来确定的。

在实际应用中，若从特征子库中查找到多个相似度比较高的预存人脸特征，为了便于进行后续的支付操作，这里可以结合用户画像进一步进行用户筛选以确定最终的比对人，具体可以按照如下步骤实现：

步骤一、获取多个合法用户的画像描述特征；

步骤二、基于获取的画像描述特征对多个合法用户分别构建用户画像；

步骤三、将多个合法用户分别对应的用户画像与待支付用户的用户画像进行比对，从多个合法用户中选取出用户画像匹配度最高的合法用户作为比对成功的合法用户。

这里的画像描述特征可以从更多特征维度描述各个用户，通过更全维度的描述使得特征比对结果更为针对性，提升了比对准确性。

接下来以无人超市场景为例，对本地人脸特征库的维护过程进行说明。

对于一个坐落在某小区的无人超市而言，预先可以在超市内设置的本地终端设备上录入该小区内各个业主的人脸图片以及相关个人信息，这些业主可以作为本地终端设备的常驻会员。在一定时间内，若入住了新的业主，可以将新的业主的信息录入本地终端设备，也可以在服务器确定新的业主具有频繁支付行为的情况下，自动同步人脸特征到本地终端设备以便新的业主可以快速完成本地身份比对。若有业主搬出了该小区，这里，可以在本地终端设备删除这一业主的信息，也可以在服务器确定这一业主长期不具有支付行为的情况下，向本地终端设备发起删除这一业主的信息的指令以便充分利用本地终端设备的存储空间。

参见图2所示，为本公开实施例提供的支付方法的流程图，该支付方法的执行主体可以是服务器，在具体应用中，可以是云端服务器。上述方法包括步骤S201～S202，其中：

S201：获取本地终端设备发送的比对结果；比对结果是本地终端设备将待识别人脸图片的待识别人脸特征与本地人脸特征库中各个合法用户的预存人脸特征进行比对得到的；合法用户包括在本地终端设备的支付行为满足第一预设条件的用户；

S202：基于比对结果进行支付操作。

这里的服务器可以基于本地终端设备发送的比对结果进行支付操作。上述比对结果可以是本地终端设备将待识别人脸图片的待识别人脸特征与本地人脸特征库中各个合法用户的预存人脸特征进行比对得到的。

有关待识别人脸特征与本地人脸特征库中的预存人脸特征之间的比对过程可以参照上述描述内容，在此不再赘述。有关合法用户的具体说明也可以参见上述描述，在此也不再赘述。

本公开实施例中，在确定本地终端设备身份比对失败的情况下，可以在服务器侧重新进行身份比对，并进行后续支付操作，具体可以通过如下步骤来实现：

步骤一、在比对结果指示比对失败的情况下，接收本地终端设备发送的待识别人脸图片；

步骤二、基于待识别人脸图片对待支付用户进行特征比对，得到新的比对结果；

步骤三、基于新的比对结果进行支付操作。

这里，有关服务器侧进行身份比对的过程可以是基于人脸库确定的，这里的人脸库可以包含有各种已授权用户的人脸图片以及对应的个人信息，一定程度上比本地终端设备中的本地人脸特征库的用户覆盖面更广。具体的特征比对方式类似，在此不做赘述。

本公开实施例中，在确定本地终端设备身份比对成功的情况下，本地终端设备可以连同比对结果以及账户信息一起发送至服务器以进行支付，也可以仅发送比对结果至服务器，这样，这样服务器则可以基于比对结果从预存的各个用户的账户信息中查找与待支付用户匹配的账户信息，基于查找到的待支付用户匹配的账户信息进行支付操作，可以按照如下步骤进行支付操作：

步骤一、判断待支付用户的账户信息指向的账户余额是否满足预设支付额，得到判断结果；

步骤二、基于判断结果进行支付操作。

这里，在确定待支付用户身份合法的情况下，可以向待支付用户绑定的账户发起扣款申请，这样，在确定待支付用户的账户余额大于支付额的情况下，基于之前的身份合法验证可以直接对待支付用户绑定的账户扣除相应的支付额，以成功完成支付。

在确定待支付用户的账户余额小于支付额的情况下，可以生成支付失败信息以提醒收款方需要待支付用户再次支付。除此之外，基于之前的身份合法验证还可以直接扣除待支付用户绑定的账户中的全部余额，并提醒还有部分余额未支付。

除此之外，本公开实施例在确定本地终端设备身份比对成功的情况下，还可以进行小图存档实现支付结果进行核对。也即，这里可以支付核对指令，基于从待识别人脸图片中提取的人脸框图对支付结果进行核对。有关具体的核对方法在此不再赘述，具体可以参见上述描述内容。

为了更好的服务于本地终端设备，本公开实施例中的服务器与本地终端设备之间存在信息添加和信息删除的需求，接下来可以通过如下两个方面进一步进行说明。

第一方面：本公开实施例可以按照如下步骤进行信息添加：

步骤一、获取历史支付用户在本地终端设备产生的支付行为数据；支付行为数据包括支付频率和/或支付次数；

步骤二、在支付行为数据满足第二预设条件的情况下，生成指向历史支付用户的用户特征存储指令；

步骤三、发送用户特征存储指令至本地终端设备，用户特征存储指令用于指示本地终端设备同步历史支付用户的信息。

这里的第二预设条件可以是支付频率高于预设频率、支付次数大于预设次数这一条件。也即，本公开可以是在服务器确定某些用户经常在本地终端设备进行支付的情况下，自动把这些用户的信息(例如人脸图片或者个人信息等)同步至该终端设备，以提升比对速度。

第二方面：本公开实施例可以按照如下步骤进行信息删除：

步骤一、在支付行为数据满足第三预设条件的情况下，生成指向历史支付用户的特征删除指令；

步骤二、发送特征删除指令至本地终端设备，特征删除指令用于指示本地终端设备删除历史支付用户的信息。

这里的第三预设条件可以是支付频率低于或等于预设频率、支付次数小于或等于预设次数这一条件，除此之外，还可以是距离当前时间的支付时长超过预设时长这一条件。也即，本公开可以是在服务器确定某些用户长期不在该本地终端设备进行支付，并且该用户在本地终端设备的情况，从本地终端设备中删除该用户的信息，以在本地维持一个相对固定的数据规模，确保本地终端设备的存储空间足够使用。

本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。

基于上述实施例提供的本地终端设备和服务器的支付方法，本公开实施例还提供了一种支付系统，如图3所示，该支付系统通过本地终端设备与服务器之间的通信连接，实现了本地终端设备的特征比对，以及服务器侧的支付，有关本地终端设备和服务器的具体实现过程参见上述描述内容，在此不再赘述。

基于同一发明构思，本公开实施例中还提供了与支付方法对应的支付装置，由于本公开实施例中的装置解决问题的原理与本公开实施例上述支付方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

参照图4所示，为本公开实施例提供的一种支付装置的示意图，装置包括：响应模块401、读取模块402、比对模块403和发送模块404；其中，

响应模块401，用于响应支付请求，获取待支付用户的待识别人脸图片，并提取待识别人脸图片的待识别人脸特征；

读取模块402，用于读取本地人脸特征库中各个合法用户的预存人脸特征；合法用户包括在本地终端设备的支付行为第一满足预设条件的用户；

比对模块403，用于将预存人脸特征与待识别人脸特征进行比对，确定比对结果；

发送模块404，用于将比对结果发送至服务器，其中，服务器用于根据比对结果进行支付。

采用上述支付装置，在响应支付请求的情况下，可以基于获取的待支付用户的待识别人脸图片提取出待识别人脸特征，这样，在读取到本地人脸特征库中各个合法用户的预存人脸特征的情况下，可以将待识别人脸特征与各个预存人脸特征进行比对，并将比对结果发送至服务器以使服务器基于比对结果完成支付过程。本公开中的本地终端设备能够利用本地人脸特征库进行特征比对，这样服务器仅需基于比对结果实现支付操作即可，特别是在本地终端设备比较多，并具有多个支付需求的情况下，各本地终端设备可以自行进行特征比对，无需在服务器排队进行比对，这将显著提升支付的效率。

在一种可能的实施方式中，上述读取模块402，还用于：

响应支付请求，获取待支付用户的待识别人脸图片之前，接收在本地终端设备上发起的第一用户的注册请求；

响应注册请求，获取第一用户的多张第一人脸图片；

将多张第一人脸图片输入至人脸质量检测模型，获得人脸质量检测结果；

根据人脸质量检测结果，从多张第一人脸图片中，确定质量分数最高的目标人脸图片，并从目标人脸图片中提取第一人脸特征；

根据第一人脸特征，创建本地人脸特征库，其中，预存人脸特征包括第一人脸特征。

在一种可能的实施方式中，上述读取模块402，还用于：

接收在本地终端设备上发起的第一用户的注册请求之后，获取第一用户的身份标识信息；

基于身份标识信息，判断第一用户是否具备在本地终端设备上进行注册的权限；

若第一用户具备在本地终端设备上进行注册的权限，确定第一用户为合法用户，并响应注册请求，获取第一用户的多张第一人脸图片；

从目标人脸图片中提取第一人脸特征之后，判断第一用户的常住地与本地终端设备所属的地理位置是否一致；

若第一用户的常住地与本地终端设备所属的地理位置一致，根据第一人脸特征，创建本地人脸特征库。

在一种可能的实施方式中，上述读取模块402，还用于：

接收服务器发送的用户特征存储指令；用户特征存储指令中包括至少一个第二用户的第二人脸特征，第二用户为在本地终端设备上的支付行为数据满足第二预设条件的用户；支付行为数据包括支付频率和/或支付次数；

将第二人脸特征存储至本地人脸特征库。

在一种可能的实施方式中，上述读取模块402，还用于：

接收服务器发送的用户特征存储指令之后，判断本地人脸特征库当前的剩余存储量是否大于或等于第二人脸特征的数据量；

若本地人脸特征库当前的剩余存储量大于或等于第二人脸特征的数据量，将第二人脸特征存储至本地人脸特征库；或，

若本地人脸特征库当前的剩余存储量小于第二人脸特征的数据量，根据第二预设条件，从本地人脸特征库中删除部分人脸特征，并将第二人脸特征存储至本地人脸特征库。

在一种可能的实施方式中，上述读取模块402用于按照以下步骤根据第一人脸特征，创建本地人脸特征库：

确定第一用户所属的用户类型；

根据用户类型，对第一人脸特征进行聚类，获得多个分类组；

为每个分类组创建特征子库；

根据多个特征子库，构建本地人脸特征库。

在一种可能的实施方式中，上述比对模块403用于按照以下步骤将预存人脸特征与待识别人脸特征进行比对，确定比对结果：

基于待支付用户所属的用户类型，确定与待识别人脸特征对应的特征子库；

确定待识别人脸特征与确定的特征子库中的各个预存人脸特征之间的相似度；

在特征子库中存在相似度大于预设阈值的合法用户的情况下，确定比对成功；在特征子库中不存在相似度大于预设阈值的合法用户的情况下，确定比对失败。

在一种可能的实施方式中，在特征子库中存在相似度大于预设阈值的合法用户为多个情况下；上述比对模块403，还用于：

获取多个合法用户的画像描述特征；

基于获取的画像描述特征对多个合法用户分别构建用户画像；

将多个合法用户分别对应的用户画像与待支付用户的用户画像进行比对，从多个合法用户中选取出用户画像匹配度最高的合法用户作为比对成功的合法用户。

在一种可能的实施方式中，上述读取模块402，还用于：

接收服务器发送的针对至少一个第三用户的特征删除指令；第三用户为支付行为数据满足第三预设条件的用户；支付行为数据包括支付频率和/或支付次数；

从本地人脸特征库中删除第三用户的人脸特征，得到更新后的本地人脸特征库。

在一种可能的实施方式中，上述发送模块404，还用于：

在比对结果指示比对成功的情况下，获取待支付用户的账户信息，以及待识别人脸图片对应的人脸框图；

将比对结果、账户信息以及人脸框图发送至服务器；服务器用于基于比对结果和账户信息进行支付，以及用于基于人脸框图对支付结果进行核对。

在一种可能的实施方式中，上述发送模块404，还用于：

在比对结果指示比对失败的情况下，向服务器发送携带有待识别人脸图片的特征比对请求，其中，特征比对请求用于请求服务器基于待识别人脸图片进行特征比对，并在服务器比对成功的情况下触发服务器进行支付操作；

接收服务器在支付操作完成后返回的支付成功信息。

参照图5所示，为本公开实施例提供的另一种支付装置的示意图，装置包括：获取模块501、支付模块502；其中，

获取模块501，用于获取本地终端设备发送的比对结果；比对结果是本地终端设备将待识别人脸图片的待识别人脸特征与本地人脸特征库中各个合法用户的预存人脸特征进行比对得到的；合法用户包括在本地终端设备的支付行为满足第一预设条件的用户；

支付模块502，用于基于比对结果进行支付操作。

采用上述支付装置，可以基于本地终端设备发送的比对结果进行支付操作，这里的本地终端设备能够利用本地人脸特征库进行特征比对，这样服务器仅需基于比对结果实现支付操作即可，特别是在本地终端设备比较多，并具有多个支付需求的情况下，各本地终端设备可以自行进行特征比对，无需在服务器排队进行比对，这将显著提升支付的效率。

在一种可能的实施方式中，支付模块502，用于按照以下步骤基于比对结果进行支付操作：

在比对结果指示比对失败的情况下，接收本地终端设备发送的待识别人脸图片；

基于待识别人脸图片对待支付用户进行特征比对，得到新的比对结果；

基于新的比对结果进行支付操作。

在一种可能的实施方式中，上述装置还包括：

同步模块503，用于获取历史支付用户在本地终端设备产生的支付行为数据；支付行为数据包括支付频率和/或支付次数；在支付行为数据满足第二预设条件的情况下，生成指向历史支付用户的用户特征存储指令；发送用户特征存储指令至本地终端设备，用户特征存储指令用于指示本地终端设备同步历史支付用户的信息。

在一种可能的实施方式中，上述装置还包括：

删除模块504，用于在支付行为数据满足第三预设条件的情况下，生成指向历史支付用户的特征删除指令；发送特征删除指令至本地终端设备，特征删除指令用于指示本地终端设备删除历史支付用户的信息。

在一种可能的实施方式中，获取模块501，还用于：

接收本地终端设备发送的人脸框图；人脸框图是本地终端设备在比对结果指示比对成功的情况下，待识别人脸图片中对应指示待支付用户的人脸部分的图像；

响应支付核对指令，基于人脸框图对支付结果进行核对。

在一种可能的实施方式中，支付模块502，用于按照以下步骤基于比对结果进行支付操作：

在比对结果指示比对成功的情况下，基于比对结果从预存的各个用户的账户信息中查找与待支付用户匹配的账户信息；

基于查找到的待支付用户匹配的账户信息进行支付操作。

关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明，这里不再详述。

本公开实施例还提供了一种电子设备，如图6所示，为本公开实施例提供的电子设备结构示意图，包括：处理器601、存储器602、和总线603。存储器602存储有处理器601可执行的机器可读指令(比如，图4中的装置中响应模块401、读取模块402、比对模块403、发送模块404对应的执行指令等)，当电子设备运行时，处理器601与存储器602之间通过总线603通信，机器可读指令被处理器601执行时执行如下处理：

响应支付请求，获取待支付用户的待识别人脸图片，并提取待识别人脸图片的待识别人脸特征；

读取本地人脸特征库中各个合法用户的预存人脸特征；合法用户包括在本地终端设备的支付行为满足第一预设条件的用户；

将预存人脸特征与待识别人脸特征进行比对，确定比对结果；

将比对结果发送至服务器，其中，服务器用于根据比对结果进行支付。

本公开实施例还提供了一种电子设备，如图7所示，为本公开实施例提供的电子设备结构示意图，包括：处理器701、存储器702、和总线703。存储器702存储有处理器701可执行的机器可读指令(比如，图5中的装置中获取模块501、支付模块502对应的执行指令等)，当电子设备运行时，处理器701与存储器702之间通过总线703通信，机器可读指令被处理器701执行时执行如下处理：

获取本地终端设备发送的比对结果；比对结果是本地终端设备将待识别人脸图片的待识别人脸特征与本地人脸特征库中各个合法用户的预存人脸特征进行比对得到的；合法用户包括在本地终端设备的支付行为满足第一预设条件的用户；

基于比对结果进行支付操作。

本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法实施例中所述的支付方法的步骤。其中，该存储介质可以是易失性或非易失的计算机可读取存储介质。

本公开实施例还提供一种计算机程序产品，该计算机程序产品承载有程序代码，所述程序代码包括的指令可用于执行上述方法实施例中所述的支付方法的步骤，具体可参见上述方法实施例，在此不再赘述。

其中，上述计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一个可选实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(Software Development Kit，SDK)等等。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本公开所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本公开的具体实施方式，用以说明本公开的技术方案，而非对其限制，本公开的保护范围并不局限于此，尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应所述以权利要求的保护范围为准。