支付方法、装置、终端及存储介质与流程

本发明涉及金融技术领域，尤其涉及一种支付方法、装置、终端及存储介质。

背景技术：

随着大众生活水平的提高，移动支付逐渐成为一种主流的支付方式。

现实生活中，用户单个的支付账号(如支付宝账号、微信账号)往往绑定有多个用于支付的存管账户。但一般情况下，用户在使用支付账号进行支付时，若当前需要支付的商品价格超出了用户当前选择的存管账户余额，移动终端就会显示支付失败的提示并建议用户更换余额充足的存管账户进行付款，若用户其他的存管账户的余额均不够本次付款时，用户就只能选择付现或花费大量时间进行账户转账，将资金转移到一个存管账户中，然后再进行支付，这样的付款方式都会导致用户的支付体验不佳。

上述内容仅用于辅助理解本发明的技术方案，并不代表承认上述内容是现有技术。

技术实现要素：

本发明的主要目的在于提供一种支付方法、装置、终端及存储介质，旨在解决现有支付方式在用户付款账户的余额不足时，无法有效为用户完成支付的技术问题。

为实现上述目的，本发明提供了一种支付方法，所述支付方法包括以下步骤:

接收用户发送的支付请求，根据所述支付请求获取与所述用户相关联的若干个可用存管账户；

检测所述若干个可用存管账户中是否存在有效付款账户；

在所述若干个可用存管账户中不存在有效付款账户时，将所述若干个可用存管账户作为共同支付账户进行付款。

优选地，所述检测所述若干个可用存管账户中是否存在有效付款账户的步骤，包括：

确定所述支付请求对应的应付金额，并分别查询各可用存管账户的可用余额；

分别将所述可用余额与所述应付金额进行比较，在所述可用余额大于或等于所述应付金额时，判定所述可用存管付款账户为有效付款账户；

在所述可用余额小于所述应付金额时，判定所述可用存管付款账户为无效付款账户。

优选地，所述接收用户发送的支付请求，根据所述支付请求获取与所述用户相关联的若干个可用存管账户的步骤，包括：

接收用户发送的支付请求，提取所述支付请求中携带的用户标识信息；

在映射关系中查找与所述用户标识信息对应的若干个可用存管账户，所述映射关系中存放有用户标识信息和可用存管账户之间的对应关系。

优选地，所述在所述若干个可用存管账户中不存在有效付款账户时，将所述若干个可用存管账户作为共同支付账户进行付款的步骤，包括：

在所述若干个可用存管账户中不存在有效付款账户时，从所述若干个可用存管账户中选取一个存管账户作为主账户；

从剩余的可用存管账户中选取任意数量的可用存管账户与所述主账户进行组合，获得若干个组合账户；

分别获取各组合账户对应的可付款金额，并将所述可付款金额大于或等于所述应付金额的组合账户作为共同支付账户进行付款。

优选地，所述分别获取各组合账户对应的可付款金额，并将所述可付款金额大于或等于所述应付金额的组合账户作为共同支付账户进行付款的步骤，包括：

分别获取各组合账户对应的可付款金额，将所述可付款金额大于或等于所述应付金额的组合账户作为待选账户；

获取各待选账户完成本次支付的支付费用，以及对应的支付时耗；

根据所述支付费用和所述支付时耗，分别确定各待选账户的优先级系数；

对各待选账户的优先级系数进行排序，根据排序结果从所述待选账户中选取出目标账户，并通过所述目标账户进行付款。

优选地，所述根据所述支付费用和所述支付时耗，分别确定各待选账户的优先级系数，包括：

根据所述支付费用和所述支付时耗，通过下式分别确定各待选账户的优先级系数；

p＝αh+βs

其中，p为优先级系数，h为支付时耗，s为支付费用，α为预设时耗权重系数，β为预设费用权重系数。

优选地，所述检测所述若干个可用存管账户中是否存在有效付款账户之后，所述支付方法还包括：

在所述若干个可用存管账户中存在有效付款账户时，生成相应的支付提示信息，并将所述支付提示信息推送至用户；

在接收到用户输入的确认付款指令时，通过所述有效付款账户进行付款。

此外，为实现上述目的，本发明还提出一种支付装置，所述支付装置包括：请求响应模块、账户检测模块以及账户组合模块；

其中，所述请求响应模块，用于接收用户发送的支付请求，根据所述支付请求获取与所述用户相关联的若干个可用存管账户；

所述账户检测模块，用于检测所述若干个可用存管账户中是否存在有效付款账户；

所述账户组合模块，用于在所述若干个可用存管账户中不存在有效付款账户时，将所述若干个可用存管账户作为共同支付账户进行付款。

此外，为实现上述目的，本发明还提出一种支付终端，所述支付终端包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的支付程序，所述支付程序配置为实现如上文所述的支付方法的步骤。

此外，为实现上述目的，本发明还提出一种存储介质，所述存储介质上存储有支付程序，所述支付程序被处理器执行时实现如上文所述的支付方法的步骤。

本发明通过接收用户发送的支付请求，根据支付请求获取与用户相关联的若干个可用存管账户；检测若干个可用存管账户中是否存在有效付款账户；在若干个可用存管账户中不存在有效付款账户时，将若干个可用存管账户作为共同支付账户进行付款，完成本次支付，由于是根据支付请求获取与用户相关联的若干个可用存管账户，然后再检测这些可用存管账户中是否存在能完成本次支付的账户，在不存在时，将可用存管账户作为共同支付账户进行付款，从而避免了用户因单个账户资金不足导致付款失败时，只能使用现金进行支付的不便，提高了用户的支付体验。

附图说明

图1是本发明实施例方案涉及的硬件运行环境的支付终端的结构示意图；

图2为本发明支付方法第一实施例的流程示意图；

图3为本发明支付方法第二实施例的流程示意图；

图4为本发明支付方法第三实施例的流程示意图；

图5为本发明支付方法第四实施例的流程示意图；

图6为本发明支付装置第一实施例的结构框图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

参照图1，图1为本发明实施例方案涉及的硬件运行环境的支付终端结构示意图。

如图1所示，该支付终端可以包括：处理器1001，例如中央处理器(centralprocessingunit，cpu)，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(display)、输入单元比如键盘(keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如无线保真(wireless-fidelity，wi-fi)接口)。存储器1005可以是高速的随机存取存储器(randomaccessmemory，ram)存储器，也可以是稳定的非易失性存储器(non-volatilememory，nvm)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的结构并不构成对支付终端的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种存储介质的存储器1005中可以包括操作系统、数据存储模块、网络通信模块、用户接口模块以及支付程序。

在图1所示的支付终端中，网络接口1004主要用于进行网络通信；用户接口1003主要用于与用户进行数据交互；本发明支付终端中的处理器1001、存储器1005可以设置在支付终端中，所述支付终端通过处理器1001调用存储器1005中存储的支付程序，并执行本发明实施例提供的支付方法。

本发明实施例提供了一种支付方法，参照图2，图2为本发明支付方法第一实施例的流程示意图。

本实施例中，所述支付方法包括以下步骤：

步骤s10：接收用户发送的支付请求，根据所述支付请求获取与所述用户相关联的若干个可用存管账户；

需要说明的是，本实施例方法的执行主体可以是银行、保险等金融系统中的能够进行网络通信、数字运算以及程序运行的服务器，或具有类似功能的其它设备。所述支付请求可以是用户通过手机、平板电脑、笔记本电脑等移动设备发送的付款请求。本实施例及下述各实施例以服务器为执行主体进行说明。

可理解的是，当前用户可以通过安装在上述移动设备上的应用程序(application，app)，例如，支付宝、微信、平安财富宝等来向对应的服务器发起所述支付请求，当服务器接收到该支付请求后，根据所述支付请求携带的数据信息确定获取与所述用户相关联的若干个可用存管账户，并检测这些账户是否为有效付款账户，其中所述数据信息可包括用户标识信息、付款账户信息(银行卡信息)、应付金额、支付密钥等。

在具体实现中，服务器可通过支付请求中携带的数据信息确定发送所述支付请求的用户账户(即当前登录app的用户账户)，然后确定该用户账户相关联(已绑定)的若干个其它的可用存管账户。

步骤s20：检测所述若干个可用存管账户中是否存在有效付款账户；

具体的，服务器可根据所述支付请求确定出本次支付对应的应付金额，并分别查询各可用存管账户的可用余额；然后再分别将可用余额与应付金额进行比较，在可用余额大于或等于应付金额时，判定可用存管付款账户为有效付款账户；在可用余额小于应付金额时，判定可用存管付款账户为无效付款账户。

步骤s30：在所述若干个可用存管账户中不存在有效付款账户时，将所述若干个可用存管账户作为共同支付账户进行付款。

当服务器在检测到当前用户相关联的若干个其它可用存管账户中不存在有效付款账户时，将所述若干个可用存管账户作为共同支付账户进行付款，以完成本次支付。

此处结合具体例子对本实施例进行说明。例如，用户a通过淘宝购买的当前商品价格为200元，当服务器在接收到用户通过淘宝提交的支付请求后，可根据用户a登录的淘宝账号查找出该淘宝账号相关联(已绑定)的所有银行的借记卡或信用卡(即可用存管账户)。

若查找到的可用存管账户为借记卡1、借记卡2和信用卡3(以下简称，卡1、卡2、卡3)，则服务器检测到这三张银行卡的可用余额(若卡1为100元，卡2为102元，卡3为98元)，则这三张卡中并不存在可用余额≥200的单张银行卡，此时，服务器可随机选取一张银行卡作为“主卡”，从剩余的银行卡中选取一个作为“副卡”组成一个“共同”的账户进行本次支付，如服务器可选择“卡1+卡2”或“卡2+卡3”的组合中的任何一个来付款。

此外，需要说明的是，本实施例中，银行卡的组合并不局限于“1+1”式的两两组合，也可以是类似于“1+1+1”式的多张银行卡之间的组合。当然，在可选组合较多的情况下，为了提高支付效率，银行卡的组合方式优选为两两组合。

进一步地，若服务器在检测到所述若干个可用存管账户中存在有效付款账户时，则生成相应的支付提示信息，并将所述支付提示信息推送至用户的移动设备进行展示；并在接收到用户输入的确认付款指令时，通过所述有效付款账户进行付款，完成支付。

本实施例通过接收用户发送的支付请求，根据支付请求获取与用户相关联的若干个可用存管账户；检测若干个可用存管账户中是否存在有效付款账户；在若干个可用存管账户中不存在有效付款账户时，将若干个可用存管账户作为共同支付账户进行付款，完成本次支付，由于是根据支付请求获取与用户相关联的若干个可用存管账户，然后再检测这些可用存管账户中是否存在能完成本次支付的账户，在不存在时，将可用存管账户作为共同支付账户进行付款，从而避免了用户因单个账户资金不足导致付款失败时，只能使用现金进行支付的不便，提高了用户的支付体验。

参考图3，图3为本发明支付方法第二实施例的流程示意图。

基于上述第一实施例，在本实施例提出的支付方法中，所述步骤s10，可具体包括：

步骤s201：接收用户发送的支付请求，提取所述支付请求中携带的用户标识信息；

可理解的是，用户在通过移动设备发送支付请求时，该支付请求携带的数据信息中一般会包括用于将当前用户与其他用户进行区分的唯一的标识信息，即所述用户标识信息，以便于服务器根据该标识信息确定是哪一个用户发送的请求。本实施例中，所述用户标识信息可以是当前登录的用户账户的账户id、绑定的手机号或用户名等，本实施例对此不作具体限制。

在具体实现中，服务器接收用户发送的支付请求，提取所述支付请求中携带的用户标识信息。

步骤s202：在映射关系中查找与所述用户标识信息对应的若干个可用存管账户，所述映射关系中存放有用户标识信息和可用存管账户之间的对应关系；

需要说明的是，为了实现对当前用户相关联的可用存管账户的快速查找，在执行本步骤之前，可预先在服务器侧建立一个用户标识信息和可用存管账户之间的对应关系，即所述映射关系，以使服务器在提取到所述用户标识信息时，通过所述映射关系快速、准确地获取到与该用户标识信息对应的若干个可用存管账户。在所述映射关系中，映射端源为用户标识信息，目标端源为用户标识信息对应的可用存管账户。

在具体实现中，服务器在映射关系中查找与所述用户标识信息对应的若干个可用存管账户，并根据查找结果确定当前用户的可用存管账户。

本实施例通过提取支付请求中携带的用户标识信息；在映射关系中查找与用户标识信息对应的若干个可用存管账户，能够在为当前用户准确查询可用存管账户，提高支付效率。

参考图4，图4为本发明支付方法第三实施例的流程示意图。

基于上述各实施例，本实施例提出的支付方法中，所述步骤s30具体包括以下步骤：

步骤s301：在所述若干个可用存管账户中不存在有效付款账户时，从所述若干个可用存管账户中选取一个存管账户作为主账户；

在具体实现中，服务器检测到当前用户的若干个存管账户中不存在有效付款账户时，可从若干个可用存管账户中选取一个存管账户作为主账户，然后从剩余的若干个可用存管账户中选取一个或多个存管账户与主账户进行组合，以确保能够完成本次支付。

步骤s302：从剩余的可用存管账户中选取任意数量的可用存管账户与所述主账户进行组合，获得若干个组合账户；

可理解的是，服务器在确定本次付款的主账户后，可根据查找出的可用存管账户来进行账户组合，具体的组合方式可以是主账户与剩余可用存管账户随机组合的方式，以剩余的可用存管账户“卡1、卡2、卡3”为例，本实施例中账户组合可以是如“主账户+卡1”、“主账户+卡2”、“主账户+卡3”、“主账户+卡1+卡2”、“主账户+卡1+卡3”、“主账户+卡2+卡3”等组合方式。

步骤s303：分别获取各组合账户对应的可付款金额，并将所述可付款金额大于或等于所述应付金额的组合账户作为共同支付账户进行付款。

在具体实现中，服务器在确定出若干个组合账户后，可分别获取各组合账户对应的可付款金额，然后将这些可付款金额与应付金额进行比较，根据比较结果，将可付款金额大于或等于应付金额的组合账户中的任意一个组合账户作为共同支付账户进行付款。

本实施例在若干个可用存管账户中不存在有效付款账户时，从若干个可用存管账户中选取一个存管账户作为主账户；从剩余的可用存管账户中选取任意数量的可用存管账户与主账户进行组合，获得若干个组合账户；分别获取各组合账户对应的可付款金额，并将可付款金额大于或等于应付金额的组合账户作为共同支付账户进行付款，从而能够有效解决因单个资金账户交易不可用，进而导致支付失败情况的发生，提高了用户体验。

参考图5，图5为本发明支付方法第四实施例的流程示意图。

基于上述各实施例，本实施例提供的支付方法中，所述步骤s303可具体包括：

步骤s3031：分别获取各组合账户对应的可付款金额，将所述可付款金额大于或等于所述应付金额的组合账户作为待选账户；

在具体实现中，服务器在完成账户组合得到若干个组合账户后，可继续查询计算各组合账户对应的共同可用余额，即所述可付款金额，然后将所述可付款金额与应付金额进行比较，筛选出可付款金额大于或等于应付金额的组合账户作为待选账户。

需要说明的是，不同的金融账户所属支付通道的支付费用(即完成一笔交易时交易服务商所花费的费用)以及支付时耗(即完成一笔交易所耗费的时长)并不相同，甚至同一条支付通道在不同时段的支付时耗也不相同。因此，为了能够提供给用户更佳的交易体验，本实施例服务器在确定出待选账户后会根据各待选账户对应的支付费用以及支付时耗来对其进行优先级排序，然后根据排序结果选取最终的付款账户。

步骤s3032：获取各待选账户完成本次支付的支付费用，以及对应的支付时耗；

需要说明的是，所述支付费用及所述支付时耗均为平均值。例如，待选账户a对应的组合账户为“卡1+卡2”，若当前时刻，卡1所属的支付通道每笔交易的支付费用为0.1元，交易时耗为0.5秒；卡2所属的支付通道每笔交易的支付费用为0.3元，交易时耗为0.3秒，则待选账户a完成本次支付的支付费用则为(0.1+0.3)/2＝0.2，支付时耗则为(0.5+0.3)/2＝0.4。

在具体实现中，服务器可从历史交易数据库或金融系统的数据库中获取各待选账户在完成本次支付时所对应的支付费用以及支付时耗。

步骤s3033：根据所述支付费用和所述支付时耗，分别确定各待选账户的优先级系数；

在具体实现中，服务器可根据获取到的各待选账户的支付费用和支付时耗，通过公式“p＝αh+βs”分别确定各待选账户的优先级系数；其中，p为优先级系数，h为支付时耗，s为支付费用，α为预设时耗权重系数，β为预设费用权重系数。例如，待选账户a通过上述公式计算出的优先级系数为pa＝0.3×0.4+0.7×0.2＝0.26，其中，0.3为预设时耗权重系数，0.7为预设费用权重系数，当然，所述预设时耗权重系数和所述预设费用权重系数可根据实际情况设定，本实施例对此不作限制。

步骤s3034：对各待选账户的优先级系数进行排序，根据排序结果从所述待选账户中选取出目标账户，并通过所述目标账户进行付款。

可理解的是，在计算出各待选账户的优先级系数后，服务器可按从小到大的顺序对各优先级系数进行排序，然后将排序第一或靠前的优先级系数对应的待选账户作为最终的付款账户(即所述目标账户)进行付款。

本实施例通过分别获取各组合账户对应的可付款金额，将可付款金额大于或等于应付金额的组合账户作为待选账户；获取各待选账户完成本次支付的支付费用，以及对应的支付时耗；根据支付费用和支付时耗，分别确定各待选账户的优先级系数；对各待选账户的优先级系数进行排序，根据排序结果从所述待选账户中选取出目标账户，并通过目标账户进行付款，能够在保证完成本次支付的情况下，进一步降低支付成本，提高支付效率。

此外，本发明实施例还提出一种可读存储介质，所述可读存储介质上存储有支付程序，所述支付程序被处理器执行时实现如上文所述的支付方法的步骤。

参照图6，图6为本发明支付装置第一实施例的结构框图。

如图6所示，本发明实施例还提出的支付装置包括：请求响应模块601、账户检测模块602以及账户组合模块603；

其中，所述请求响应模块601，用于接收用户发送的支付请求，根据所述支付请求获取与所述用户相关联的若干个可用存管账户；

可理解的是，当前用户可以通过安装在上述移动设备上的应用程序(application，app)，例如，支付宝、微信、平安财富宝等来向对应的服务器发起所述支付请求，当服务器接收到该支付请求后，根据所述支付请求携带的数据信息确定获取与所述用户相关联的若干个可用存管账户，并检测这些账户是否为有效付款账户，其中所述数据信息可包括用户标识信息、付款账户信息(银行卡信息)、应付金额、支付密钥等。

在具体实现中，请求响应模块601可通过支付请求中携带的数据信息确定发送所述支付请求的用户账户(即当前登录app的用户账户)，然后确定该用户账户相关联(已绑定)的若干个其它的可用存管账户。

所述账户检测模块602，用于检测所述若干个可用存管账户中是否存在有效付款账户；

在具体实现中，账户检测模块602可根据所述支付请求确定出本次支付对应的应付金额，并分别查询各可用存管账户的可用余额；然后再分别将可用余额与应付金额进行比较，在可用余额大于或等于应付金额时，判定可用存管付款账户为有效付款账户；在可用余额小于应付金额时，判定可用存管付款账户为无效付款账户。

所述账户组合模块603，用于在所述若干个可用存管账户中不存在有效付款账户时，将所述若干个可用存管账户作为共同支付账户进行付款。

当账户组合模块603在检测到当前用户相关联的若干个其它可用存管账户中不存在有效付款账户时，将所述若干个可用存管账户作为共同支付账户进行付款，以完成本次支付。

当然，若账户组合模块603在检测到所述若干个可用存管账户中存在有效付款账户时，则生成相应的支付提示信息，并将所述支付提示信息推送至用户的移动设备进行展示；并在接收到用户输入的确认付款指令时，通过所述有效付款账户进行付款，完成支付。

本实施例支付装置通过接收用户发送的支付请求，根据支付请求获取与用户相关联的若干个可用存管账户；检测若干个可用存管账户中是否存在有效付款账户；在若干个可用存管账户中不存在有效付款账户时，将若干个可用存管账户作为共同支付账户进行付款，完成本次支付，由于是根据支付请求获取与用户相关联的若干个可用存管账户，然后再检测这些可用存管账户中是否存在能完成本次支付的账户，在不存在时，将可用存管账户作为共同支付账户进行付款，从而避免了用户因单个账户资金不足导致付款失败时，只能使用现金进行支付的不便，提高了用户的支付体验。

本发明支付装置的其他实施例或具体实现方式可参照上述各方法实施例，此处不再赘述。

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

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如只读存储器(readonlymemory，rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。