组合支付方法、装置、设备及可读存储介质

技术领域

本申请的实施例涉及电子支付技术领域，尤其涉及一种组合支付方法、装置、设备及可读存储介质。

背景技术

网络支付、移动支付已经成为人们日常生活中必需的支付手段。商家平台生成订单发起支付请求，支付平台生成账单启动支付，终端用户通过应用程序(application，APP)交互完成订单支付，是一种常见的用户消费场景的支付流程。

但是上述支付流程中，在用户账户绑定的多张银行卡的余额均小于订单的金额，但该多张银行卡的总余额大于订单金额的情况下，用户需要将多张银行卡的余额转账到一张银行卡上，用于支付订单。这样，用户在支付订单的过程中，操作繁琐，体验较差。

发明内容

本申请提供一种组合支付方法、装置、设备及可读存储介质，解决了用户不能使用绑定的多张银行卡同时进行电子支付的问题。

第一方面，本申请提供一种组合支付方法，应用于电子设备，该组合支付方法包括：电子设备确定订单金额、第一支付金额、以及第二支付金额，在确定第一支付金额与第二支付金额之和为订单金额的情况下，向第一服务器发送第一支付请求，并向第二服务器发送第二支付请求。之后，电子设备在接收到来自第一服务器的第一支付成功响应，和来自第二服务器的第二支付成功响应的情况下，显示支付成功。

其中，第一支付金额为第一支付账户的支付金额，第二支付金额为第二支付账户的支付金额；第一服务器为第一支付账户的支付平台，第二服务器为第二支付账户的支付平台，第一支付请求中携带第一支付金额，第二支付请求中携带第二支付金额。

上述方案中，电子设备在确定第一支付账户的支付金额(第一支付金额)和第二支付账户的支付金额(第二支付金额)为订单金额的情况下，向第一支付账户的支付平台(第一服务器)发送包含第一支付金额第一支付请求，向第二支付账户的支付平台(第二服务器)发送包含第二支付金额第二支付请求，并且在接收到第一服务器和第二服务器的支付成功响应的情况下，确定支付成功。能够使用第一支付账户(如银行卡账户)和第二支付账户(如亲情卡账户)支付同一笔订单的订单金额，避免了用户不能使用多个支付账户同时进行电子支付的问题，节省了用户将多个支付账户的余额转账到一个支付账户的时间，从而提高了用户体验。

可选的，上述“确定订单金额、第一支付金额、以及第二支付金额”的方法，包括：电子设备响应于用户对支付账户的选择操作，显示第一提示信息，响应于用户对第一支付账户输入第一支付金额的操作，确定并显示第二支付金额。

其中，第一提示信息用于提示用户输入支付金额，第一支付账户和第二支付账户均为用户执行过选择操作的支付账户，第一支付账户包括至少一个支付账户，第二支付账户包括一个支付账户，第一支付账户不包括第二支付账户；第二支付金额为第二支付账户对应的支付金额。

可选的，第二支付金额为订单金额与第一支付金额之差。

上述方案中，电子设备根据订单金额和用户输入的第一支付金额确定第二支付金额，节省了用户根据第一支付金额和订单金额计算第二支付金额的时间，从而提高了用户体验。

可选的，至少两个支付账户包括默认账户。

上述方案中，将至少两个支付账户中一个支付账户确定为默认账户，避免了用户每次支付前都需要选择支付账户的问题，节省了用户不必要的操作。

可选的，该组合支付方法，还包括：电子设备在确定第一支付金额与第二支付金额之和大于订单金额的情况下，显示第二提示信息。其中，上述第二提示信息用于提示超额支付。

上述方案中，在第一支付金额与第二支付金额之和大于订单金额的情况下，提示用户超额支付，避免了给用户造成财产损失。

可选的，该组合支付方法，还包括：电子设备在接收到支付失败消息的情况下，回滚已支付金额。

上述方案中，任一支付账户支付失败，只要电子设备接收到支付失败消息，立即回滚已支付金额，避免了给用户造成财产损失的问题。

可选的，在向第一服务器发送第一支付请求，并向第二服务器发送第二支付请求之前，该组合支付方法，还包括：电子设备在确定第一支付金额与第二支付金额之和为订单金额的情况下，将付款控件的状态更新为可操作状态，响应于用户对付款控件的触发操作，显示第三提示信息。之后，电子设备确定用户输入的支付凭证与预设支付凭证相同。其中，上述第三提示信息用于提示输入支付凭证。

上述方案中，电子设备在向支付平台发送支付请求之前，需要用户验证支付凭证，在用户输入的支付凭证正确(与预设支付凭证相同)时，再向支付平台发送支付请求，避免了给用户造成财产损失。

第二方面，本申请提供一种组合支付装置，应用于电子设备，包括确定模块、发送模块以及显示模块。确定模块，用于确定订单金额、第一支付金额、以及第二支付金额；第一支付金额为第一支付账户的支付金额，第二支付金额为第二支付账户的支付金额；发送模块，用于在确定模块确定的第一支付金额与第二支付金额之和为订单金额的情况下，向第一服务器发送第一支付请求，并向第二服务器发送第二支付请求；第一服务器为第一支付账户的支付平台，第二服务器为第二支付账户的支付平台，第一支付请求中携带第一支付金额，第二支付请求中携带第二支付金额；显示模块，用于在接收到来自第一服务器的第一支付成功响应，和来自第二服务器的第二支付成功响应的情况下，显示支付成功。

可选的，确定模块，具体用于：确定订单金额和至少两个支付账户；响应于用户对支付账户的选择操作，显示第一提示信息；第一提示信息用于提示用户输入支付金额；响应于用户对第一支付账户输入第一支付金额的操作，确定并显示第二支付金额；第一支付账户和第二支付账户均为用户执行过选择操作的支付账户，第一支付账户包括至少一个支付账户，第二支付账户包括一个支付账户，第一支付账户不包括第二支付账户；第二支付金额为第二支付账户对应的支付金额。

可选的，第二支付金额为订单金额与第一支付金额之差。

可选的，至少两个支付账户包括默认账户。

可选的，显示模块，还用于在确定第一支付金额与第二支付金额之和大于订单金额的情况下，显示第二提示信息；第二提示信息用于提示超额支付。

可选的，该组合支付装置还包括处理模块。处理模块，用于在接收到支付失败消息的情况下，回滚已支付金额。

可选的，显示模块，还用于：在确定第一支付金额与第二支付金额之和为订单金额的情况下，将付款控件的状态更新为可操作状态；响应于用户对付款控件的触发操作，显示第三提示信息；第三提示信息用于提示输入支付凭证；确定模块，还用于确定用户输入的支付凭证与预设支付凭证相同。

第三方面，本申请提供一种电子设备，包括处理器。当电子设备运行时，处理器执行计算机执行指令，以使电子设备执行如上述第一方面中任一种可选的组合支付方法。

第四方面，本申请提供一种计算机可读存储介质，其中，计算机可读存储介质上存储有指令，当计算机可读存储介质中的指令由组合支付装置的处理器执行时，使得组合支付装置执行如上述第一方面中任一种可选的组合支付方法。

第五方面，本申请提供一种计算机程序产品，计算机程序产品包括指令代码，指令代码用于执行如上述第一方面中任一种可选的组合支付方法。

可以理解地，上述提供的组合支付装置、电子设备、计算机可读存储介质或计算机程序产品均用于执行上文第一方面所提供的方法，因此，其所能达到的有益效果可参考上文的方法以及下文具体实施方式中对应的方案的有益效果，此处不再赘述。

附图说明

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

图1为本申请的实施例提供的一种组合支付系统的结构示意图；

图2为本申请的实施例提供的一种电子设备的硬件结构示意图；

图3为本申请的实施例提供的一种组合支付方法的流程示意图；

图4为本申请的实施例提供的一种确定金额的方法的流程示意图；

图5为本申请的实施例提供的一种电子设备的显示界面示意图之一；

图6为本申请的实施例提供的一种电子设备的显示界面示意图之一；

图7为本申请的实施例提供的一种组合支付装置的结构示意图。

具体实施方式

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

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。

首先，对本申请实施例的应用场景进行介绍。

本申请实施例应用于用户使用移动支付的场景中。

目前，网络支付、移动支付已经成为人们日常生活中必需的支付手段。商家平台生成订单发起支付请求，支付平台生成账单启动支付，终端用户通过APP交互完成订单支付，是一种常见的用户消费场景的支付流程。

但是上述支付流程中，在用户账户绑定的多张银行卡的余额均小于订单的金额，但该多张银行卡的总余额大于订单金额的情况下，用户需要将多张银行卡的余额转账到一张银行卡上，用于支付订单。这样，用户在支付订单的过程中，操作繁琐，体验较差。

为了解决上述问题，本申请提供一种组合支付方法，能够使用第一支付账户和第二支付账户支付同一笔订单金额，避免了用户不能使用多个支付账户同时进行电子支付的问题，节省了用户将多个支付账户的余额转账到一个支付账户的时间，从而提高了用户体验。

接下来，对本申请实施例的实施环境进行介绍。

通常，上述APP可以开通或绑定多个支付账户(如银行卡账户、亲情卡账户)，并且一个支付账户对应一个支付平台。因此，图1为本申请的实施例提供的一种组合支付系统的结构示意图。如图1所示，该支付系统包括安装有上述APP的电子设备11和多个支付平台12。其中，电子设备11与支付平台12可以通过网络互连并通信。

其中，电子设备11可以为手机、平板电脑、桌面型、膝上型、手持计算机、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本等，本申请实施例对该电子设备11的具体形态不作特殊限制。

支付平台12可以是一台服务器，也可以是由多台服务器组成的服务器集群，或者是一个云计算服务中心。支付平台12可以包括处理器、存储器以及网络接口等。

需要说明的是，本申请实施例提供的组合支付方法应用于上述电子设备11，即本申请实施例提供的组合支付方法的执行主体可以为组合支付装置，组合支付装置可以为上述电子设备。

本领域技术人员应能理解上述电子设备11和支付平台12仅为举例，其他现有的或今后可能出现的电子设备11或支付平台12如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。

在具体实现时，电子设备具有如图2所示的部件。图2为本申请实施例提供的一种电子设备，可以包括至少一个处理器202，处理器202用于执行应用程序代码，从而实现本申请中的组合支付方法。

处理器202可以是一个中央处理器(central processing unit，CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。

如图2所示，电子设备还可以包括存储器203。其中，存储器203用于存储执行本申请方案的应用程序代码，并由处理器202来控制执行。

存储器203可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electricallyerasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器203可以是独立存在，通过总线与处理器202相连接。存储器203也可以和处理器202集成在一起。

如图2所示，电子设备还可以包括通信接口201，其中，通信接口201、处理器202、存储器203可以相互耦合，例如通过总线204相互耦合。通信接口201用于与其他设备进行信息交互，例如支持电子设备与其他设备的信息交互。

需要指出的是，图2中示出的设备结构并不构成对该电子设备的限定，除图2所示部件之外，该电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图1所示的组合支付系统和图2所示的电子设备，通过图3对本申请实施例提供的组合支付方法进行描述。

图3为本申请实施例提供的一种组合支付方法的流程示意图。参见图3所示，该组合支付方法包括如下步骤。

步骤31：电子设备确定订单金额、第一支付金额、以及第二支付金额。

其中，第一支付金额为第一支付账户的支付金额，第二支付金额为第二支付账户的支付金额。

可选的，如图4所示，电子设备确定订单金额、第一支付金额、以及第二支付金额的方法包括如下步骤。

步骤31a：电子设备确定订单金额和至少两个支付账户。

具体的，本申请实施例的支付账户为能够提供订单金额支付的账户。例如，支付账户可以为安装在电子设备上的APP对应的账户，也可以为该APP绑定的银行卡对应的账户，还可以为该APP下开通的子支付账户。本申请实施例对此不作具体限定。

可选的，至少两个支付账户包括默认账户。

其中，默认账户用于在用户无选择操作的情况下支付订单金额。

具体的，默认账户的选择可以由用户指定，也可以为根据预设规则选择。例如，将绑定的第一个支付账户确定为默认账户。本申请实施例对此不作具体限定。

又例如，图5为本申请实施例提供的一种电子设备的显示界面示意图。该界面包括订单金额、多个支付账户51、与支付账户51对应的多个选择控件52。其中，支付账户51包括支付账户一、支付账户二以及支付账户三，支付账户三被设置为默认账户，则在用户未执行选择操作的情况下，支付账户三对应的支付金额为订单金额。

上述方案中，将至少两个支付账户中一个支付账户确定为默认账户，避免了用户每次支付前都需要选择支付账户的问题，节省了用户不必要的操作。

步骤31b：电子设备响应于用户对支付账户的选择操作，显示第一提示信息。

其中，第一提示信息用于提示用户输入支付金额。

示例性的，图6为本申请实施例提供的一种电子设备的显示界面示意图。该界面包括订单金额、多个支付账户51、与支付账户51对应的多个选择控件52。其中，支付账户51包括支付账户一、支付账户二以及支付账户三，支付账户三被设置为默认账户，第一选择控件521对应支付账户一，第二选择控件522对应支付账户二，第三选择控件523对应支付账户三。这样，在用户点选了第一选择控件521时，电子设备响应于用户对第一选择控件521的触发，在与支付账户一对应的提示框中显示“请输入支付金额”；在用户点选了第二选择控件522时，电子设备响应于用户对第二选择控件522的触发，在与支付账户二对应的提示框中显示“请输入支付金额”。

步骤31c：电子设备响应于用户对第一支付账户输入第一支付金额的操作，确定并显示第二支付金额。

其中，第一支付账户和第二支付账户均为用户执行过选择操作的支付账户，第一支付账户包括至少一个支付账户，第二支付账户包括一个支付账户，第一支付账户不包括第二支付账户；第二支付金额为第二支付账户对应的支付金额。

具体的，第一支付账户包括用户执行过选择操作的支付账户中，除第二支付账户外的所有支付账户。第一支付账户包括至少一个支付账户，第二支付账户包括一个支付账户，且第一支付账户的第一支付金额为用户输入的，第二支付账户的第二支付金额为电子设备根据用户输入第一支付金额确定的。

例如，在图6所示的显示界面中，用户执行过选择操作的支付账户包括支付账户一、支付账户二以及支付账户三。在第一支付账户包括支付账户一和支付账户二时，支付账户三为第二支付账户；在第一支付账户包括支付账户二和支付账户三时，支付账户一为第二支付账户；在第一支付账户包括支付账户一和支付账户三时，支付账户二为第二支付账户。

具体的，第二支付金额为订单金额与第一支付金额之差。

示例性的，在订单金额为5，第一支付金额为3时，第二支付金额为5-3＝2。

上述方案中，电子设备根据订单金额和用户输入的第一支付金额确定第二支付金额，节省了用户根据第一支付金额和订单金额计算第二支付金额的时间，从而提高了用户体验。

步骤32：电子设备在确定第一支付金额与第二支付金额之和为订单金额的情况下，向第一服务器发送第一支付请求，并向第二服务器发送第二支付请求。

其中，第一服务器为第一支付账户的支付平台，第二服务器为第二支付账户的支付平台，第一支付请求中携带第一支付金额，第二支付请求中携带第二支付金额。

具体的，电子设备在确定第一支付金额与第二支付金额之和为订单金额的情况下，将付款控件的状态更新为可操作状态。在确定用户已开通免密支付的情况下，响应于用户对付款控件的触发操作，向第一服务器发送第一支付请求并向第二服务器发送第二支付请求。

可选的，在确定用户未开通免密支付的情况下，在向第一服务器发送第一支付请求，并向第二服务器发送第二支付请求之前，该方法还包括如下步骤。

步骤S1：电子设备在确定第一支付金额与第二支付金额之和为订单金额的情况下，将付款控件的状态更新为可操作状态。

步骤S2：电子设备响应于用户对付款控件的触发操作，显示第三提示信息。

其中，第三提示信息用于提示输入支付凭证。支付凭证可以为人脸、指纹、指静脉、密码等，本申请实施例对此不作具体限定。

步骤S3：电子设备确定用户输入的支付凭证与预设支付凭证相同。

其中，预设支付凭证为用户设置的支付凭证，可以为人脸、指纹、指静脉、密码等，本申请实施例对此不作具体限定。

上述方案中，电子设备在向支付平台发送支付请求之前，需要用户验证支付凭证，在用户输入的支付凭证正确(与预设支付凭证相同)时，再向支付平台发送支付请求，避免了给用户造成财产损失。

可选的，电子设备在确定第一支付金额与第二支付金额之和大于订单金额的情况下，显示第二提示信息。

其中，第二提示信息用于提示超额支付。

上述方案中，在第一支付金额与第二支付金额之和大于订单金额的情况下，提示用户超额支付，避免了给用户造成财产损失。

可选的，电子设备在显示第二提示信息时，清空用户输入的最后一个支付金额。

步骤33：电子设备在接收到来自第一服务器的第一支付成功响应，和来自第二服务器的第二支付成功响应的情况下，显示支付成功。

可选的，电子设备在接收到支付失败消息的情况下，回滚已支付金额。

具体的，电子设备在接收到支付失败消息的情况下，回滚已支付金额，并取消支付订单。

可选的，电子设备在接收到支付失败消息的情况下，确定支付失败消息对应的支付请求，并重新发送该支付失败消息对应的支付请求。电子设备在第N次接收到支付失败消息时，回滚已支付金额，并取消支付订单。其中，N为正整数。

上述方案中，电子设备在第N次支付失败的情况下，回滚已支付金额，避免了给用户造成财产损失的问题。

支付平台侧在确定支付账户为银行卡账户，且支付成功的情况下，以订单号和银行卡号为主键，存储订单交易数据。

本申请实施例至少带来以下有益效果：

电子设备在确定第一支付账户的支付金额(第一支付金额)和第二支付账户的支付金额(第二支付金额)为订单金额的情况下，向第一支付账户的支付平台(第一服务器)发送包含第一支付金额第一支付请求，向第二支付账户的支付平台(第二服务器)发送包含第二支付金额第二支付请求，并且在接收到第一服务器和第二服务器的支付成功响应的情况下，确定支付成功。能够使用第一支付账户(如银行卡账户)和第二支付账户(如亲情卡账户)支付同一笔订单的订单金额，避免了用户不能使用多个支付账户同时进行电子支付的问题，节省了用户将多个支付账户的余额转账到一个支付账户的时间，从而提高了用户体验。

以上结合图3-图6详细说明了本申请实施例提供的方法。为了实现上述功能，组合支付装置包含了执行各个功能相应的硬件结构和/或软件模块，这些执行各个功能相应的硬件结构和/或软件模块可以构成一个电子设备。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对组合支付装置进行功能模块的划分，例如，组合支付装置可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

以下，结合图7详细说明本申请实施例提供的组合支付装置。应理解，装置实施例的描述与方法实施例的描述相互对应，因此，未详细描述的内容可以参见上文方法实施例，为了简洁，这里不再赘述。

图7为本申请实施例提供的一种组合支付装置的结构示意图。如图7所示，组合支付装置用于执行图3-图6中所示的任一种组合支付方法。组合支付装置可以包括确定模块71、发送模块72以及显示模块73。

确定模块71，用于确定订单金额、第一支付金额、以及第二支付金额。第一支付金额为第一支付账户的支付金额，第二支付金额为第二支付账户的支付金额。例如，结合图3，确定模块71，用于执行图3中的步骤31。发送模块72，用于在确定模块71确定的第一支付金额与第二支付金额之和为订单金额的情况下，向第一服务器发送第一支付请求，并向第二服务器发送第二支付请求。第一服务器为第一支付账户的支付平台，第二服务器为第二支付账户的支付平台，第一支付请求中携带第一支付金额，第二支付请求中携带第二支付金额。例如，结合图3，发送模块72，用于执行图3中的步骤32。显示模块73，用于在接收到来自第一服务器的第一支付成功响应，和来自第二服务器的第二支付成功响应的情况下，显示支付成功。例如，结合图3，显示模块73，用于执行图3中的步骤33。

可选的，确定模块71，具体用于：确定订单金额和至少两个支付账户。响应于用户对支付账户的选择操作，显示第一提示信息；第一提示信息用于提示用户输入支付金额；响应于用户对第一支付账户输入第一支付金额的操作，确定并显示第二支付金额；第一支付账户和第二支付账户均为用户执行过选择操作的支付账户，第一支付账户包括至少一个支付账户，第二支付账户包括一个支付账户，第一支付账户不包括第二支付账户；第二支付金额为第二支付账户对应的支付金额。例如，结合图4，确定模块71，具体用于执行图4中的步骤31a-31c。

可选的，第二支付金额为订单金额与第一支付金额之差。

可选的，至少两个支付账户包括默认账户。

可选的，显示模块73，还用于在确定第一支付金额与第二支付金额之和大于订单金额的情况下，显示第二提示信息；第二提示信息用于提示超额支付。

可选的，该组合支付装置还包括处理模块74。处理模块74，用于在接收到支付失败消息的情况下，回滚已支付金额。

可选的，显示模块73，还用于：在确定第一支付金额与第二支付金额之和为订单金额的情况下，将付款控件的状态更新为可操作状态；响应于用户对付款控件的触发操作，显示第三提示信息；第三提示信息用于提示输入支付凭证；确定模块71，还用于确定用户输入的支付凭证与预设支付凭证相同。

当然，本申请实施例提供的组合支付装置包括但不限于上述模块。

在实际实现时，确定模块71、发送模块72、显示模块73以及处理模块74可以由图2所示的处理器202调用存储器203中的程序代码来实现。其具体的执行过程可参考图3-图6中所示的任一种组合支付方法部分的描述，这里不再赘述。

本申请另一实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当指令在组合支付装置上运行时，该组合支付装置，执行如图3和图4所示的实施例的组合支付方法中的步骤。

在本申请的另一实施例中，还提供一种计算机程序产品，该计算机程序产品包括计算机执行指令，该计算机执行指令存储在计算机可读存储介质中；组合支付装置的处理器可以从计算机可读存储介质读取该计算机执行指令，处理器执行该计算机执行指令使得组合支付装置，执行如图3和图4所示的实施例的组合支付方法中的步骤。

其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，其作用在此不再赘述。

应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的模块、单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

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

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

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

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。