一种支付方法、装置及系统

技术领域

本公开涉及金融科技技术领域，具体涉及一种支付方法、装置及系统。

背景技术

在原有技术背景下，由于企业线上支付需要企业持U盾人(一般为企业财务)插盾验签，随着企业经营和采购线上化转型，原有技术局限下的支付方式对企业经办线上化采购造成了障碍，尤其是财务制度健全的大中型企业，采购经办在线上支付时面临支付流程中断或员工垫款的问题，有些企业将U盾交由采购经办使用，容易出现对公账户资金安全风险。

发明内容

(一)要解决的技术问题

针对上述问题，本公开提供了一种支付方法、装置及系统，用于至少部分解决传统支付方法容易出现支付流程中断、资金安全风险高等技术问题。

(二)技术方案

本公开一方面提供了一种支付方法，包括：向财务客户端发送非财务用户的注册信息，以使财务客户端生成针对该注册信息的认证信息，该认证信息存储于银行服务器；向银行服务器发送支付请求，以使银行服务器根据支付请求及认证信息进行支付处理。

进一步地，向银行服务器发送支付请求包括：调取支付凭证，支付凭证为银行进行支付结算的凭证；向银行服务器发送支付请求，支付请求包括支付凭证和交易信息，以使银行服务器进行支付处理。

进一步地，向财务客户端发送非财务用户的注册信息包括：向银行服务器提交注册信息，以使银行服务器对该注册信息进行身份识别；识别通过后，银行服务器将注册信息发送给财务客户端。

本公开另一方面提供了一种支付方法，包括：获取非财务客户端发送的注册信息，生成针对该注册信息的认证信息，该认证信息存储于银行服务器；依据认证信息以使银行服务器收到非财务用户的支付请求时进行支付处理。

进一步地，获取非财务客户端发送的注册信息包括：获取非财务客户端发送的注册信息，进行认证，绑定与非财务用户的关系。

进一步地，获取非财务客户端发送的注册信息之后还包括：为非财务用户下发支付权限或者审批非财务用户申请的支付权限。

本公开还有一方面提供了一种支付方法，包括：存储认证信息，认证信息为财务客户端依据非财务客户端发送的注册信息而生成；获取非财务用户发送的支付请求，根据支付请求及认证信息进行支付处理。

进一步地，存储认证信息包括：获取非财务客户端发送的注册信息，对该注册信息进行身份识别；将注册信息发送给财务客户端，该财务客户端生成针对该注册信息的认证信息；获取、存储认证信息。

进一步地，获取非财务用户发送的支付请求包括：获取非财务客户端发送的支付请求，验证非财务用户的身份信息；获取支付凭证信息和交易信息，验证非财务用户的支付权限。

进一步地，支付请求及认证信息进行支付处理包括：根据支付请求及认证信息扣划资金，并根据支付请求将资金汇出至指定的账户。

本公开还有一方面提供了一种支付装置，包括：非财务客户端，用于向财务客户端发送非财务用户的注册信息，以使财务客户端生成针对该注册信息的认证信息，该认证信息存储于银行服务器；向银行服务器发送支付请求，以使银行服务器根据支付请求及认证信息进行支付处理；财务客户端，用于获取非财务客户端发送的注册信息；银行服务器，用于存储认证信息；用于获取非财务用户发送的支付请求并进行支付处理。

本公开还有一方面提供了一种支付系统，包括：用户管理模块，用于接收非财务用户的注册信息，并发送给财务客户端，以使财务客户端生成针对该注册信息的认证信息；支付授权模块，用于非财务用户申请支付权限，用于财务客户端为非财务用户下发支付权限；支付鉴权模块，用于验证非财务用户的身份信息和支付权限；交易接收模块，用于识别交易信息；账务处理模块，用于根据支付请求及认证信息扣划资金，并根据支付请求将资金汇出至指定的账户。

本公开还有一方面提供了一种电子设备，包括：处理器；存储器，其存储有计算机可执行程序，该程序在被处理器执行时，使得处理器执行如前述支付方法。

本公开还有一方面提供了一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如前述支付方法。

(三)有益效果

本公开实施例提供的一种支付方法、装置及系统，一方面通过将现有的线上动账权限进行拆分再授权，在企业非财务用户进行线上交易和采购时能够直接使用企业结算账户资金完成支付，解决了非财务用户传统支付方法中清算路径长的问题，有效地提升了支付效率；另一方面通过使非财务用户进行实名化注册，与企业关系进行绑定，再通过支付授权的方式，从系统层面控制企业支付过程中存在的资金安全风险，提升了支付结算业务过程中的安全性。

附图说明

图1示意性示出了根据本公开实施例支付方法的示例性系统架构；

图2示意性示出了根据本公开实施例支付方法的流程图；

图3示意性示出了根据本公开实施例中客户端与银行服务器的交互过程图；

图4示意性示出了根据本公开另一实施例支付方法的流程图；

图5示意性示出了根据本公开又一实施例支付方法的流程图；

图6示意性示出了根据本公开实施例中银行服务器根据支付请求进行支付的流程图；

图7示意性示出了根据本公开实施例企业支付系统中各个模块的结构框图；

图8示意性示出了根据本公开实施例用户管理模块的单元结构图；

图9示意性示出了根据本公开实施例支付授权模块的单元结构图；

图10示意性示出了根据本公开实施例支付鉴权模块的单元结构图；

图11示意性示出了根据本公开实施例交易接收模块的单元结构图；

图12示意性示出了根据本公开实施例账务处理模块的单元结构图；

图13示意性示出了根据本公开实施例企业线上支付处理方法的完整流程图；

图14示意性示出了根据本公开实施例的计算机系统的框图。

具体实施方式

为使本公开的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本公开进一步详细说明。

本公开的实施例提供了一种企业线上支付处理方法及系统，通过绑定用户与企业关系，企业财务为用户设置支付权限，提供了一种将企业全量员工体系化管理、完整授权、安全支付的线上企业支付解决方案，有效解决了采购经办和财务在线下传递原始凭证、经办人员垫款、支付流程长、账户资金不安全的痛点，从系统层面控制了企业支付过程中存在的资金安全风险。

图1示意性示出了根据本公开实施例的支付方法的示例性系统架构100。需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图1所示，根据该实施例的系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对用户利用终端设备101、102、103所浏览的网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的用户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。

需要说明的是，本公开实施例所提供的支付方法一般可以由服务器105执行。相应地，本公开实施例所提供的用于支付的系统一般可以设置于服务器105中。本公开实施例所提供的支付方法也可以由不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群执行。相应地，本公开实施例所提供的用于支付的系统也可以设置于不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

图2示意性示出了根据本公开实施例支付方法的流程图。

S11，向财务客户端发送非财务用户的注册信息，以使财务客户端生成针对该注册信息的认证信息，该认证信息存储于银行服务器。

在步骤S11中，企业内部直接使用企业账户资金进行线上支付的通常为财务人员，这里的非财务用户为企业内部有支付需求的非财务人员，例如采购经办。采购经办传统的采购流程包括申请、经办人员垫款、传递原始凭证、审核、财务支付等流程，耗费时间长；有些企业将U盾交由采购经办使用，容易出现对公账户资金安全风险。据此，本公开提出了一种将现有企业线上动账权限进行拆分再授权的方法，使得有支付需求的非财务人员也享有部分的支付权限，在进行线上交易和采购时能够直接使用企业结算账户资金完成支付。

首先，企业需要在银行支付客户端上注册，获取企业的唯一ID或者是申请U盾后的唯一U盾ID；其次，非财务用户也需要在银行相应客户端上注册，并进行实名认证，再通过企业ID、U盾ID或者是企业基本定位与企业相关联，递交申请信息。客户端收到申请信息后将该信息发送给企业财务的客户端进行认证，企业财务确认后完成后绑定非财务用户与企业关系。企业财务可进一步为用户下发支付权限，或者是审批非财务用户申请的支付权限，这里支付权限不仅包括付款金额，还可以包括有效期限、付款范围等信息，用户即获得相应的支付权限。

S12，向银行服务器发送支付请求，以使银行服务器根据支付请求及认证信息进行支付处理。

非财务用户可登录银行支付客户端查询享有的支付权限范围，登录时客户端会进行登录信息与注册信息的比对，进行登录鉴权。非财务用户在支付权限内可通过银行转账、扫码支付或者是出示付款码支付等方式递交付款申请至银行支付系统，系统判断付款申请信息与预先设置的非财务用户支付权限范围是否相符，进行支付鉴权；若相符，则进行支付转账，并更新支付权限范围的信息，完成整个支付流程，客户端与银行服务器的交互过程图请参见图3。本公开的方法解决了采购经办在线上支付时面临支付流程中断或员工垫款的问题，以及降低了对公账户资金的安全风险。

在上述实施例的基础上，向银行服务器发送支付请求包括：调取支付凭证，支付凭证为银行进行支付结算的凭证；向银行服务器发送支付请求，支付请求包括支付凭证和交易信息，以使银行服务器进行支付处理。

这里的支付凭证为银行进行支付结算的凭证，具有可结算的功能。非财务用户凭借该支付凭证即可直接使用企业结算账户资金完成支付，解决了传统方式审批流程复杂、申请周期长的支付问题。银行服务器根据该支付凭证以及交易信息，即可进行资金的划扣与入账。

在上述实施例的基础上，向财务客户端发送非财务用户的注册信息包括：向银行服务器提交注册信息，以使银行服务器对该注册信息进行身份识别；识别通过后，银行服务器将注册信息发送给财务客户端。

非财务用户进行注册、实名认证的过程包括：用户进入客户端，客户端与服务器建立连接，打开socket文件，建立后连接成功。客户端通过socket向服务器提交注册请求，提交手机号、姓名、证件类型、证件号码、有效期等个人信息。客户端提交请求后，通过HTTP协议传送给服务器。服务器进行事务处理，并将处理结果传回给客户端。非财务用户将信息填入发回客户端，服务器调用公安联网核查对客户实名信息进行核查认证，认证通过后，客户端将信息写入数据库，注册成功。

非财务用户注册成功后，银行服务器将注册信息发送给财务客户端，企业财务人员可登录专用客户端，通过服务器查看注册人员信息，操作并绑定用户与企业信息。

图4示意性示出了根据本公开另一实施例支付方法的流程图。

S21，获取非财务客户端发送的注册信息，生成针对该注册信息的认证信息，该认证信息存储于银行服务器；S22，依据认证信息以使银行服务器收到非财务用户的支付请求时进行支付处理。

财务人员登录专用客户端，通过服务器查看注册人员信息，操作并绑定用户与企业信息。在接收到非财务用户发送的实名注册后，登记相关身份认证和管理实体，记录用户身份详情，并将实名用户的企业认证申请信息发送至企业进行认证，认证通过后，将实名用户与企业进行绑定，存储于银行服务器，为后续授权、鉴权模块进行交易处理提供身份安全认证基础。

在上述实施例的基础上，获取非财务客户端发送的注册信息包括：获取非财务客户端发送的注册信息，进行认证，绑定与非财务用户的关系。

财务人员登录客户端，接收到服务器发送的用户事务申请，并申请访问用户人员的身份等相关信息，服务器发送信息至财务人员客户端后财务人员然后做出决定，是否绑定与该非财务用户的关系，将反馈信息发送回服务器，服务器再将反馈信息发送给非财务用户人员客户端上。

在上述实施例的基础上，获取非财务客户端发送的注册信息之后还包括：为非财务用户下发支付权限或者审批非财务用户申请的支付权限。

这里支付权限可以是根据非财务用户岗位角色的不同设置不同的支付权限范围，例如根据不同岗位涉及的支付金额大小设置支付金额权限，原材料采购主要为大额支付，其支付金额权限相应地比较大，行政采购主要为小额支付，其支付金额权限相应地比较小；还可以为非财务用户设置其支付对象范围，例如原材料采购的支付对象为原材料供应商，行政采购的支付对象为淘宝、京东等购物网站；还可以为非财务用户设置其支付有效期限，例如可以是临时的一个月有效支付期限，还可以是长期的一年有效支付期限，超过有效支付期限，系统会自动识别，中止交易，无法完成支付。

需要说明的是，这里可以是财务为非财务用户下发支付权限，也可以是非财务用户在线申请支付权限，财务进行审批。企业财务在角色授权和权限设置基础上，主动通过指定被授权人、设置收款人范围、圈定支付金额范围等支付信息，为经办下发支付权限；或者是非财务用户通过上报支付金额、收款人等信息在线申请支付权限，为后续经办角色使用支付凭证支付提供权限判断依据。企业财务审批该经办用户申请的支付权限，审批通过后，用户即可在该支付权限下进行付款流程。经办用户在支付时，系统会将支付申请信息与企业财务设定好的权限进行比对，比对成功则进入支付流程，否则终止支付。

在上述实施例的基础上，获取非财务客户端发送的注册信息包括：对非财务用户的支付权限进行修改、维护、终止操作，进行动态管理。

在接收到企业财务签发的支付权限信息后，在已有信息基础上对支付权限进行修改维护和终止废除的全生命周期管理。企业财务可根据用户的工作角色的变化对支付权限的金额、支付对象范围、支付有效期限等信息进行调整，以及随时的对支付权限终止废除等操作。即这里提前将部分支付权限下发给企业的采购经办后，采购经办能够直接使用企业结算账户资金进行支付，企业财务主要对支付权限的分权进行相应的管理维护工作。

图5示意性示出了根据本公开又一实施例支付方法的流程图。

S31，存储认证信息，认证信息为财务客户端依据非财务客户端发送的注册信息而生成。

银行服务器接收非财务用户的注册信息，待财务客户端认证通过后，存储财务客户端发送的认证信息，为后续的支付流程提供权限判断依据。

S32，获取非财务用户发送的支付请求，根据支付请求及认证信息进行支付处理。

银行服务器接收非财务用户的支付请求后，验证该支付请求是否符合预先的权限设置，若是则进行资金的扣划与汇入；若否，则终止交易。

在上述实施例的基础上，存储认证信息包括：获取非财务客户端发送的注册信息，对该注册信息进行身份识别；将注册信息发送给财务客户端，该财务客户端生成针对该注册信息的认证信息；获取、存储认证信息。

非财务用户将注册信息发送至银行服务器，服务器进行事务处理，并将处理结果传回给客户端。用户将信息填入发回客户端，服务器调用公安联网核查对客户实名信息进行核查认证，认证通过后，客户端将信息写入数据库，注册成功。服务器再将注册信息发送给财务客户端，企业财务人员登录专用客户端，通过服务器查看注册人员信息，操作并绑定用户与企业信息，并发送认证信息给银行服务器，银行服务器存储该认证信息。

在上述实施例的基础上，获取非财务用户发送的支付请求包括：获取非财务客户端发送的支付请求，验证非财务用户的身份信息；获取支付凭证信息和交易信息，验证非财务用户的支付权限。

获取非财务用户的支付，对用户进行支付鉴权，判断支付请求是否与用户的支付权限匹配；若是，则进行资金扣划与商户入账，完成线上支付；否则，终止交易，请参见图6。具体地，非财务用户通过客户端发送支付请求至服务器中，服务器接收和识别交易指令，将该用户的权限与设定好的权限进行比对，将反馈结果返回给客户端，进行支付鉴权。需要说明的是，对用户进行支付鉴权具体包括：用户登录时，确认用户的登录信息与注册信息是否相符；用户递交支付申请时，确认用户的支付申请信息与支付权限是否相符。即支付鉴权包括登陆鉴权与支付鉴权，登陆鉴权包括经办或财务登录客户端时将信息传入服务器中与数据库中的注册信息进行比对，将比对结果(正确或错误)返回至客户端中；支付鉴权包括经办用户通过客户端发送经办申请至服务器中，服务器将该用户的权限与设定好的权限进行比对，将反馈结果返回给客户端。

在上述实施例的基础上，根据支付请求及认证信息进行支付处理包括：根据支付请求及认证信息扣划资金，并根据支付请求将资金汇出至指定的账户。

若符合条件，则记录交易详情，进行资金扣划再将资金处理信息传送回服务器中，客户端接收到资金扣划单元的信息后，发送汇出指令传输给服务器进行资金传输，完成线上支付；若不符合支付条件，则终止交易，并回传支付失败的信息。这里进行资金扣划与商户入账具体包括：交易处理完成后，扣划企业账户资金金额，并根据支付计划将资金金额汇出至交易指令中指定的商户账户。即客户端接收到交易处理单元指令后，进行资金扣划再将资金处理信息传送回服务器中；客户端接收到服务器传输的交易处理单元指令后，并接收到资金扣划单元的信息后，发送汇出指令传输给服务器进行资金传输。

获取非财务用户发送的支付请求还包括获取交易指令：识别交易指令，将符合条件的交易指令进行交易处理；其中，交易处理包括记录交易详情、识别和制定支付计划。服务器接收平台合作方传输的交易指令并将该指令保留传送给交易处理单元，交易处理单元接收到交易识别指令后，在服务器中进行记录交易详情，识别和制定支付计划，并发送给客户端。

本公开的另一实施例提供了支付装置，包括：非财务客户端，用于向财务客户端发送非财务用户的注册信息，以使财务客户端生成针对该注册信息的认证信息，该认证信息存储于银行服务器；向银行服务器发送支付请求，以使银行服务器根据支付请求及认证信息进行支付处理；财务客户端，用于获取非财务客户端发送的注册信息；银行服务器，用于存储认证信息；用于获取非财务用户发送的支付请求并进行支付处理。

客户端与银行服务器的交互过程图请参见图3，详细过程在支付方法中已具体说明，此处不再赘述。

本公开的另一实施例提供了一种支付系统，请参见图7，包括：用户管理模块1，用于接收非财务用户的注册信息，并发送给财务客户端，以使财务客户端生成针对该注册信息的认证信息；支付授权模块2，用于非财务用户申请支付权限，用于财务客户端为非财务用户下发支付权限；支付鉴权模块3，用于验证非财务用户的身份信息和支付权限；交易接收模块4，用于识别交易信息；账务处理模块5，用于根据支付请求及认证信息扣划资金，并根据支付请求将资金汇出至指定的账户。

图7为示意性示出了支付系统中各个模块的结构框图，本公开采用了一种新型的企业线上支付用户、授权、认证模式。在线上采购交易发生前，通过开发化实名注册机制，将用户与企业关系进行绑定；并通过用户角色和权限设置完全契合企业经营和授权管理规则；在发生线上采购行为时，采购经办可使用财务预先审批通过的支付额度完成支付，还可通过人脸&指纹+静态密码等方式便捷地完成支付认证。

用户管理模块1，用于接收非财务用户的注册信息，并发送给财务客户端，以使财务客户端生成针对该注册信息的认证信息。用户管理模块1由用户注册单元11、企业认证单元12与角色授权单元13组成，请参见图8。

1)用户注册单元11

用户注册单元11的主要作用为接收用户注册和实名认证，建立企业移动支付用户身份识别认证体系基础，并存储用户注册信息，将实名认证后的用户信息传送至企业认证单元12进行下一步处理。

2)企业认证单元12

企业认证单元12的主要作用为在接收到用户注册单元11发送的用户实名注册后，登记相关身份认证和管理实体，记录用户身份详情，并将实名用户的企业认证申请信息发送至企业进行认证，认证通过后，将实名用户与企业进行绑定，为后续授权、鉴权模块进行交易处理提供身份安全认证基础。

3)角色授权单元13

角色授权单元13的主要作用为在接收到企业认证单元12实名用户和企业绑定认证后，为实名用户设置角色权限，为后续支付和交易鉴权提供依据。

支付授权模块2，用于非财务用户申请支付权限，用于财务客户端为非财务用户下发支付权限；用户在线申请支付权限，其包括收款人信息、支付金额信息，为企业财务为用户设置支付权限提供权限判断依据；企业财务为用户设置支付信息，其包括收款人范围、支付金额范围，下发支付权限。支付授权模块2由财务授权单元21、经办申请单元22与权限管理单元23组成，请参见图9。

1)财务授权单元21

财务授权单元21的主要作用为在角色管理单元13的角色和权限设置基础上，财务管理权限的用户主动通过指定被授权人、设置收款人范围、圈定支付金额范围等支付信息，为经办下发支付权限。或审批经办用户申请的支付权限，为后续经办角色使用支付凭证支付提供权限判断依据。

2)经办申请单元22

经办申请单元22的主要作用为在在角色管理单元13的角色和权限设置基础上，经办权限用户通过上报支付金额、收款人等信息在线申请支付权限，为后续经办角色使用支付凭证支付提供权限判断依据。

3)权限管理单元23

权限管理单元23的主要作用为在接收到财务授权单元21签发的支付凭证权限信息后，服务器将财务授权单元最终反馈信息可发送给财务人员客户端进行修改，在已有信息基础上对支付权限进行修改维护和终止废除的全生命周期管理。

支付鉴权模块3，用于验证非财务用户的身份信息和支付权限。用户登录时，用于确认用户的登录信息与注册信息是否相符；用户递交支付申请时，用于确认用户的支付申请信息与支付权限是否相符。

支付鉴权模块3由登陆鉴权单元31与支付鉴权单元32组成，请参见图10。

1)登陆鉴权单元31

登陆鉴权单元31的主要作用为在财务管理权限角色或经办权限角色登陆时识别和认证其身份，利用用户注册单元的用户身份数据使其登陆至系统进行相关操作。

2)支付鉴权单元32

支付鉴权单元32的主要作用为在角色授权单元13基础上，经办权限用户在权限范围内使用支付凭证进行付款，该单位验证用户的身份和支付申请是否符合企业预先设置的权限范围。

采购经办可使用财务预先审批通过的支付额度完成支付，并通过人脸&指纹+静态密码等方式便捷地完成支付认证，根据实际支付金额使用对应的支付认证方式完成支付鉴权，见表1：

表1

交易接收模块4，，用于识别交易信息，包括识别交易指令，将符合条件的交易指令进行交易处理；其中，交易处理包括记录交易详情、识别和制定支付计划。

交易接收模块4由交易识别单元41与交易处理单元42组成，请参见图11。

1)交易识别单元41

交易识别单元41的主要作用为接收和识别平台合作方传输的交易指令，并将符合条件的保留支付指令传送至交易处理单元42进行下一步处理。

2)交易处理单元42

交易处理单元42的主要作用为在接收到交易识别单元41发送的交易指令后，登记相关交易实体，记录交易详情，识别和制定支付计划，为后续账户处理模块进行交易处理提供索引指导。

账务处理模块，用于根据支付请求及认证信息扣划资金，并根据支付请求将资金汇出至指定的账户。账务处理模块5由资金扣划单元51与商户入账单元52组成，请参见图12。

1)资金扣划单元51

资金扣划单元51的主要作用为在接收到交易处理单元42的指令后，通过主机完成对公结算账户定位与资金的扣划，并将资金处理状态信息返传至交易处理单元42。

2)商户入账单元52

商户入账单元52的主要作用为在接收到交易处理单元42的确认支付指令后，与资金扣划单元51完成信息交互确认资金已从付方结算账户扣划，并根据交易处理单元42发起的资金汇划指令将款项汇出至指令中指定的商户账户。

图13为本公开企业线上支付方法的一个具体实施例，示意性示出了本公开设计的企业移动支付授权、鉴权、支付工作流程图。具体流程说明如下：

步骤701：用户注册登录信息，进行公安人脸实名认证，存储和记录客户的登陆用户名和绑定手机号。

步骤702：用户注册实名信息进入企业认证单元进行处理，并将实名用户信息与企业进行绑定。

步骤703：角色授权单元处理和存储用户的角色和权限信息。

步骤704：对于企业财务管理权限用户，进入步骤705通过支付授权模块，财务授权单元对某一经办权限用户进行支付额度授权和权限管理；对于非企业财务管理权限用户，进入步骤711通过登陆鉴权单元进入系统使用其权限内的支付凭证。

步骤705：通过财务授权单元对某一经办权限用户进行支付额度授权和权限管理，或通过经办申请单元申请为登录用户申请支付额度授权。

步骤706：通过财务授权单元为企业经办用户签发支付凭证。

步骤707：通过权限管理单元管理和维护已签发的付款凭证。

步骤711：通过登陆鉴权单元认证登陆经办权限用户登陆权限。

步骤712：经办权限用户通过权限管理单元查询权限内可使用支付凭证。

步骤713：经办权限用户通过扫码、转账汇款等方式调用权限内支付凭证进行付款。

步骤714：交易处理单元对接收到的交易信息进行处理。

步骤715：通过支付鉴权单元对经办用户发起的交易和其支付权限进行匹配判断。

步骤716：资金汇划单元根据交易处理单元指令进行对公结算账户资金扣划，并通过商户入账单元为收款方入账。

步骤717：通过权限管理单元更新支付凭证全生命周期状态。

为便于对本公开进行理解，下面提出了企业线上支付处理方法的另一个具体实施例。

S1、经办用户实名注册并与企业进行关联绑定，财务人员为经办人员进行授权。

S101，经办用户在客户端提交个人实名信息进行用户注册，并进行公安联网核查完成实名认证，通过U盾ID或企业基本定位需关联绑定的企业，客户端程序向我行服务器上送注册信息，推送至需要绑定的企业；

S102，财务管理人员通过客户端查看已注册并确认与经办用户的绑定关系；

S103，财务管理人员用户在客户端提交财务授权，为经办用户设定付款范围、金额上限、有效期等授权信息；

S104，财务管理人员通过客户端查看已授权的信息并对授权信息进行动态管理。

S2、经办人员进行使用付款权限进行支付。

S201，经办用户登陆客户端，查询名下可用的付款权限信息；

S202，经办扫码商户二维码或出示付款二位码给商户；

S203，系统根据订单金额要求用户进行支付鉴权；

S204，鉴权通过后支付成功，系统更新付钱权限可用余额等信息。

本公开能够将现有企业线上动账权限进行拆分再授权，在企业经办进行线上交易和采购时能够直接使用企业结算账户资金完成支付，有效解决企业经办垫款痛点，从系统层面控制企业支付过程中存在的资金安全风险，理顺了企业线上交易和支付的流程。

图14示意性示出了根据本公开另一实施例的电子设备的框图。

如图14所示，电子设备800包括处理器810、计算机可读存储介质820。该电子设备800可以执行根据本公开实施例的方法。

具体地，处理器810例如可以包括通用微处理器、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器810还可以包括用于缓存用途的板载存储器。处理器810可以是用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

计算机可读存储介质820，例如可以是能够包含、存储、传送、传播或传输指令的任意介质。例如，可读存储介质可以包括但不限于电、磁、光、电磁、红外或半导体系统、装置、器件或传播介质。可读存储介质的具体示例包括：磁存储装置，如磁带或硬盘(HDD)；光存储装置，如光盘(CD-ROM)；存储器，如随机存取存储器(RAM)或闪存；和/或有线/无线通信链路。

计算机可读存储介质820可以包括计算机程序821，该计算机程序821可以包括代码/计算机可执行指令，其在由处理器810执行时使得处理器810执行根据本公开实施例的方法流程及其任何变形。

计算机程序821可被配置为具有例如包括计算机程序模块的计算机程序代码。例如，在示例实施例中，计算机程序821中的代码可以包括一个或多个程序模块，例如包括821A、模块821B、……。应当注意，模块的划分方式和个数并不是固定的，本领域技术人员可以根据实际情况使用合适的程序模块或程序模块组合，当这些程序模块组合被处理器810执行时，使得处理器810可以执行根据本公开实施例的方法流程及其任何变形。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/系统/系统中所包含的，也可以是单独存在，而未装配入该设备/系统/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

尽管已经参照本公开的特定示例性实施例示出并描述了本公开，但是本领域技术人员应该理解，在不背离所附权利要求及其等同物限定的本公开的精神和范围的情况下，可以对本公开进行形式和细节上的多种改变。因此，本公开的范围不应该限于上述实施例，而是应该不仅由所附权利要求来进行确定，还由所附权利要求的等同物来进行限定。