CN113822661A - 支付方法、装置和*** - Google Patents

Abstract

本公开的实施例公开了支付方法、装置和***。该方法的一具体实施方式包括：接收针对待支付资源的初始支付资源；根据待支付资源和初始支付资源的差值，确定未支付资源；执行如下支付处理步骤：接收针对未支付资源的当前支付资源，以及根据未支付资源和当前支付资源的差值，更新未支付资源；确定更新后的未支付资源是否为零；响应于确定更新后的未支付资源为零，返回用于指示支付成功的支付结果信息。该实施方式实现了通过两次及以上的支付来完成待支付资源的支付过程。

Description

支付方法、装置和***

技术领域

本公开的实施例涉及计算机技术领域，具体涉及支付方法、装置 和***。

背景技术

随着电子商务的快速发展和普及，其逐渐成为互联网应用的热点 之一。在这一过程中，电子支付也随之发展起来。电子支付通常指交 易的各方(包括如消费者、商家、金融机构等)之间使用安全电子手 段把支付信息通过信息网络安全地传送到相应的处理机构(如银行 等)，用来实现货币支付或资金流转等各种交易行为。

目前，支付流程通常是交易中的一方(如支付货币方)选择支付 方式进行支付，交易中的另一方(如货币接收方)校验本次支付是否 成功，并返回相应的支付结果信息。

为了保证电子支付的安全性等原因，针对各种支付方式通常都设 置有相应的措施。例如，为了规避一些异常交易行为，会进行单笔限 额、周交易限额、月交易限额等等。又例如，根据用户个人的信用信 息，设置不同的限额额度等等。因此，在支付过程中，可能会出现支 付受限的情况(如单次支付金额超额等)，在这些情况下通常就会无 法完成本次支付。

发明内容

本公开的实施例提出了支付方法和装置。

第一方面，本公开的实施例提供了一种支付方法，应用于服务端， 该方法包括：接收针对待支付资源的初始支付资源；根据待支付资源 和初始支付资源的差值，确定未支付资源；执行如下支付处理步骤： 接收针对未支付资源的当前支付资源，以及根据未支付资源和当前支 付资源的差值，更新未支付资源；确定更新后的未支付资源是否为零； 响应于确定更新后的未支付资源为零，返回用于指示支付成功的支付 结果信息。

第二方面，本公开的实施例提供了一种支付方法，应用于客户端， 该方法包括：发送针对待支付资源的初始支付资源；接收未支付资源， 其中，未支付资源根据待支付资源和初始支付资源的差值确定；执行 如下支付步骤：发送针对未支付资源的当前支付资源；接收用于指示 支付成功的支付结果信息，其中，支付结果信息响应于确定更新后的 未支付资源为零被发送，更新后的未支付资源根据未支付资源和当前 支付资源的差值确定。

第三方面，本公开的实施例提供了一种支付***，包括客户端和 服务端；服务端用于实现如第一方面描述的方法；客户端用于实现如 第二方面描述的方法。

第四方面，本公开的实施例提供了一种支付装置，应用于服务端， 该装置包括：初始支付资源接收单元，被配置成接收针对待支付资源 的初始支付资源；确定单元，被配置成根据待支付资源和初始支付资 源的差值，确定未支付资源；支付处理单元，被配置成执行如下支付 处理步骤：接收针对未支付资源的当前支付资源，以及根据未支付资 源和当前支付资源的差值，更新未支付资源；确定更新后的未支付资 源是否为零；响应于确定更新后的未支付资源为零，返回用于指示支 付成功的支付结果信息。

第五方面，本公开的实施例提供了一种支付装置，应用于客户端， 该装置包括：初始支付资源发送单元，被配置成发送针对待支付资源 的初始支付资源；未支付资源接收单元，被配置成接收未支付资源， 其中，未支付资源根据待支付资源和初始支付资源的差值确定；支付 单元，被配置成执行如下支付步骤：发送针对未支付资源的当前支付 资源；接收用于指示支付成功的支付结果信息，其中，支付结果信息 响应于确定更新后的未支付资源为零被发送，更新后的未支付资源根 据未支付资源和当前支付资源的差值确定。

第六方面，本公开的实施例提供了一种电子设备，该电子设备包 括：一个或多个处理器；存储装置，用于存储一个或多个程序；当一 个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现 如第一方面或第二方面描述的方法。

第七方面，本公开的实施例提供了一种计算机可读介质，其上存 储有计算机程序，该计算机程序被处理器执行时实现如第一方面或第 二方面描述的方法。

本公开的实施例提供的支付方法、装置和***，通过接收针对待 支付资源的初始支付资源并计算未支付资源，然后再接收针对未支付 资源的当前支付资源以更新未支付资源，直至更新后的未支付资源为 零时确定支付成功。由此一来，可以通过两次及以上的支付来完成待 支付资源的支付过程，从而增加一种新的支付过程，同时也可以提升 支付过程的灵活性。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描 述，本公开的其它特征、目的和优点将会变得更明显：

图1是本公开的一个实施例可以应用于其中的示例性***架构 图；

图2是根据本公开的支付方法的一个实施例的流程图；

图3是根据本公开的支付方法的又一个实施例的流程图；

图4是根据本公开的实施例的支付方法的一个应用场景的示意 图；

图5是根据本公开的支付方法的再一个实施例的流程图；

图6是根据本公开的支付***的一个实施例的时序图；

图7是根据本公开的支付装置的一个实施例的结构示意图；

图8是根据本公开的支付装置的又一个实施例的结构示意图；

图9是适于用来实现本公开的实施例的电子设备的结构示意图。

具体实施方式

下面结合附图和实施例对本公开作进一步的详细说明。可以理解 的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发 明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与 有关发明相关的部分。

需要说明的是，在不冲突的情况下，本公开中的实施例及实施例 中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本 公开。

图1示出了可以应用本公开的支付方法或支付装置的实施例的示 例性架构100。

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

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

终端设备101、102、103可以是硬件，也可以是软件。当终端设 备101、102、103为硬件时，可以是各种电子设备，包括但不限于智 能手机、平板电脑、电子书阅读器、膝上型便携计算机和台式计算机 等等。当终端设备101、102、103为软件时，可以安装在上述所列举的电子设备中。其可以实现成多个软件或软件模块(例如用来提供分 布式服务的多个软件或软件模块)，也可以实现成单个软件或软件模 块。在此不做具体限定。

服务器105可以是提供各种服务的服务器，例如为终端设备101、 102、103上安装的客户端应用提供支持的后端服务器。服务器105可 以接收终端设备101、102、103发送的支付资源并进行处理以完成待 支付资源的支付，并将指示是否支付成功的支付结果信息返回至终端 设备101、102、103。

需要说明的是，本公开的实施例所提供的应用于服务端的支付方 法一般由服务器105执行，相应地，应用于服务端的支付装置一般设 置于服务器105中。对应地，本公开的实施例所提供的应用于客户端 的支付方法一般由终端设备101、102、103执行，相应地，应用于客 户端的支付装置一般设置于终端设备101、102、103中。

需要说明的是，服务器105可以是硬件，也可以是软件。当服务 器105为硬件时，可以实现成多个服务器组成的分布式服务器集群， 也可以实现成单个服务器。当服务器105为软件时，可以实现成多个 软件或软件模块(例如用来提供分布式服务的多个软件或软件模块)， 也可以实现成单个软件或软件模块。在此不做具体限定。

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

继续参考图2，其示出了根据本公开的支付方法的一个实施例的 流程200。该支付方法可以应用于服务端(如图1所示的服务器105)， 具体包括以下步骤：

步骤201，接收针对待支付资源的初始支付资源。

在本实施例中，资源可以指各种能够用于价值交换的、真实或虚 拟的对象。例如，资源包括但不限于：物品、货币(包括虚拟货币、 在线货币等等)、服务等等。

待支付资源可以指当前还没有开始进行支付的资源。例如，待支 付资源可以是用户订单的总金额。初始支付资源可以指首次接收到的、 用于支付上述待支付资源的资源。一般地，初始支付资源小于待支付 资源。

支付方法的执行主体(如图1所示的服务器等)可以接收客户端 (如图1所示的终端设备101、102、103等)发送的初始支付资源。 具体地，客户端可以展示有用于指示待支付资源的信息，并针对该信 息向服务端发送针对该待支付资源的初始支付资源。作为示例，客户 端可以显示有对应用户的订单总金额500，然后用户可以通过客户端 向服务端发送初始支付金额200。

步骤202，根据待支付资源和初始支付资源的差值，确定未支付 资源。

在本实施例中，未支付资源可以指针对待支付资源当前剩余还没 有开始进行支付的资源。一般地，未支付资源可以通过计算待支付资 源和初始支付资源的差值得到。

在一些情况下，初始支付资源或其它一些因素(如具有关联优惠 资源等等)可能会影响未支付资源。此时，可以结合具体的应用场景 和应用需求确定未支付资源。

作为示例，服务端接收到客户端发送的针对总金额500的用户订 单的初始支付金额200，则此时未支付资源为300(500-200＝300)。

步骤203，执行如下支付处理步骤2031-2033：

步骤2031，接收针对未支付资源的当前支付资源，以及根据未支 付资源和当前支付资源的差值，更新未支付资源。

在本实施例中，服务端在确定未支付资源之后，可以将用于指示 未支付资源的信息发送至客户端，并接收客户端当前针对未支付资源 发送的支付资源。当前支付资源可以指本次接收到的、用于支付当前 的未支付资源的资源。一般地，当前支付资源不大于当前的未支付资 源。然后，可以根据未支付资源和当前支付资源的差值来更新未支付 资源，以得到更新后的未支付资源作为当前最新的未支付资源。

作为示例，未支付资源为300，若之后接收到客户端发送的支付 资源100，则此时未支付资源可以更新为200(300-100＝200)。

步骤2032，确定更新后的未支付资源是否为零。

在本实施例中，服务端在对未支付资源每次更新后都可以进一步 确定更新后的未支付资源是否为0。若更新后的未支付资源为0，可以 表示已经完成针对待支付资源的支付。对应地，若更新后的未支付资 源不为0，则可以表示还存在剩余没有进行支付的资源，即还未完成 针对待支付资源的支付。

步骤2033，响应于确定更新后的未支付资源为零，返回用于指示 支付成功的支付结果信息。

在本实施例中，在更新后的未支付资源为0时，可以确定已经完 成针对待支付资源的支付，此时服务端可以向客户端返回用于指示支 付成功的支付结果信息。例如，向客户端返回内容为“支付成功”的 提示信息和相关支付凭证。

在本实施例的一些可选的实现方式中，上述支付处理步骤还包括： 响应于确定更新后的未支付资源不为零，确定更新后的未支付资源作 为未支付资源，继续执行上述支付处理步骤。

在更新后的未支付资源不为0时，可以更新当前的未支付资源， 并使用更新后的未支付资源作为新的未支付资源，继续执行上述支付 处理步骤，直至更新后的未支付资源为0，以完成针对待支付资源的 支付。

作为示例，未支付资源为300，之后接收到客户端发送的支付资 源100，此时未支付资源可以更新为200(300-100＝200)。然后，若 继续接收到客户端发送的支付资源200，此时未支付资源可以更新为0 (200-200＝0)，进而可以向客户端返回内容为支付成功的提示信息。

可选地，支付处理步骤在每次执行时从客户端接收到的当前支付 资源可以由客户端的用户灵活设置。例如，客户端的用户可以根据实 际的需求设置每次发送的支付资源。

由此一来，可以通过两次以上的支付来完成针对待支付资源的支 付，而无需当下一次就完成针对待支付资源的支付。

在本实施例的一些可选的实现方式中，初始支付资源的支付方式 信息可以与当前支付资源的支付方式信息可以不同。其中，支付方式 信息可以用于指示支付资源时所使用的支付方式。作为示例，在资源 为货币时，支付方式包括但不限于：***支付、储蓄卡支付、第三 方支付平台提供各种支付方式等等。

此时，支付处理步骤在每次执行时的当前支付资源的支付方式信 息也可以不同。即支付处理步骤在循环多次执行时，每次的支付方式 可以不同。

可选地，可以在客户端展示可选或可使用的支付方式，以便于用 户选择其期望使用的支付方式。在客户端展示的支付方式可以根据实 际的应用场景或应用需求灵活设置。例如，可以根据用户的历史支付 记录分析用户对支付方式的偏好，然后可以在客户端优先展示用户偏 好度较高的支付方式。又例如，可以根据实际的应用场景针对不同的 支付方式设置不同的优先级，然后按照对应的优先级由高到低的顺序 在客户端展示不同的支付方式。

这种情况下，用户通过两次以上的支付来完成针对待支付资源的 支付时，可以根据实际的应用需求每次灵活地选择不同的支付方式来 完成支付，避免一次完成对待支付资源的支付时只能使用一种支付方 式的问题。

现有技术中，对于待支付资源，用户通常需要一次支付过程来完 成待支付资源的支付，这样就会出现一些如只能使用一种支付方式来 完成支付、由于限额导致阻塞待支付资源的支付的情况。例如，用户 选择一种支付方式后，若出现超额情况，通常会使得用户只能退出当 前支付页面放弃本次支付。

针对这些情况，本公开的上述实施例提供的方法可以通过两次或 超过两次的支付过程来完成待支付资源的支付，这样一来，可以为在 支付过程中为用户提供较高的灵活性，如控制支付的次数和每次支付 的资源、使用不同的支付方式等等。对于用户来说，有助于提升用户 在支付过程中的体验，减少支付失败的次数。

进一步参考图3，其示出了支付方法的又一个实施例的流程300。 该支付方法应用于服务端，具体的流程300包括以下步骤：

步骤301，接收针对待支付资源的非单次支付请求。

在本实施例中，非单次支付请求可以指请求通过两次及以上的资 源支付来完成待支付资源的支付。服务端可以接收客户端发送的非单 次支付请求。具体地，客户端可以展示有用于指示非单次支付请求的 信息，然后客户端的用户可以根据该信息向服务端发送非单次支付请 求。

作为示例，客户端的支付页面中可以展示用于指示非单次支付请 求的按钮，用户可以通过点击该按钮向服务端发送非单次支付请求。

步骤302，基于非单次支付请求，接收针对待支付资源的初始支 付资源。

在本实施例中，在接收到非单次支付请求之后，可以根据该非单 次支付请求，接收针对待支付资源的初始支付资源。例如，客户端可 以在发送非单次支付请求的同时发送初始支付资源。

作为示例，用户可以使用客户端输入初始支付资源，然后向服务 端发送携带有初始支付资源这一参数的非单次支付请求。

步骤303，根据待支付资源和初始支付资源的差值，确定未支付 资源。

步骤304，执行如下支付处理步骤3041-3043：

步骤3041，接收针对未支付资源的当前支付资源，以及根据未支 付资源和当前支付资源的差值，更新未支付资源。

步骤3042，确定更新后的未支付资源是否为零。

步骤3043，响应于确定更新后的未支付资源为零，返回用于指示 支付成功的支付结果信息。

在本实施例的一些可选的实现方式中，在上述步骤301之前，服 务端可以接收针对待支付资源的单次支付请求。然后，响应于确定单 次支付请求不符合预设支付条件，可以进一步执行上述步骤301即接 收针对待支付资源的非单次支付请求。

其中，单次支付请求可以指请求通过一次的资源支付来完成待支 付资源的支付。服务端可以接收客户端发送的单次支付请求。具体地， 客户端可以展示有用于指示单次支付请求的信息，然后客户端的用户 可以根据该信息向服务端发送单次支付请求。

在接收到单次支付请求之后，服务端可以进一步对该单次支付请 求进行校验，以确定该单次支付请求是否符合预设支付条件。其中， 预设支付条件可以根据实际的应用需求或应用场景预先进行设置。

作为示例，服务端可以预先存储有用于指示每个客户端是否具有 单次支付的权限的信息。每个客户端是否具有单次支付的权限具体可 以根据客户端的用户的信用确定。此时，服务端可以通过查询上述存 储的信息确定客户端发送的单次支付请求是否符合预设支付条件。具 体地，若查询到客户端具有单次支付的权限，则可以认为客户端发送 的单次支付请求符合预设支付条件。对应地，若查询到客户端不具有 单次支付的权限，则可以认为客户端发送的单次支付请求不符合预设 支付条件。

可选地，服务端还可以接收客户端基于其发送的单次支付请求而 发送的单次支付资源。其中，单次支付资源可以指用于一次完成上述 待支付资源的支付的资源。例如，客户端可以在发送单次支付请求的 同时发送单次支付资源。

作为示例，用户可以使用客户端输入单次支付资源，然后向服务 端发送携带有单次支付资源这一参数的单次支付请求。

此时，服务端可以通过校验单次支付请求对应的单次支付资源来 确定该单次支付请求是否符合预设支付条件。例如，服务端可以预先 存储有用于指示针对每个客户端的单次支付请求对应的单次支付资源 的要求的条件信息，也可以实时确定每个客户端的单次支付请求对应 的单次支付资源的要求的条件信息。

服务端就可以通过查询上述存储的条件信息确定客户端发送的单 次支付请求对应的单次支付资源是否符合预设支付条件。具体地，若 查询到单次支付资源符合对应的条件信息，则可以认为客户端发送的 单次支付请求符合预设支付条件。对应地，若查询到单次支付资源不 符合对应的条件信息，则可以认为客户端发送的单次支付请求不符合 预设支付条件。

其中，针对单次支付资源的条件信息可以根据实际的应用场景确 定。例如，用户的单次支付资源可能是受限的(如支付的货币被限额 等)。又例如，用户当天所花费的总支付资源是受限的。

若服务端确定客户端发送的单次支付请求符合预设支付条件，则 可以根据客户端发送的单次支付资源完成待支付资源的支付，然后进 一步还可以向客户端返回用于指示支付成功的支付结果信息。

若服务端确定客户端发送的单次支付请求不符合预设支付条件， 则可以向客户端返回用于指示客户端发送的单次支付请求不符合预设 支付条件的指示信息。之后，服务端可以接收客户端基于该指示信息 发送的非单次支付请求，并通过非单次支付来完成待支付资源的支付。

本实施例中未具体说明的内容可参考图2对应实施例中的相关说 明，在此不再赘述。

继续参见图4，图4是根据本实施例的支付方法的一个示意性的 应用场景400。在图4的应用场景中，客户端401的页面4011中显示 有待支付金额2000，且可选的支付方式包括方式一、方式二和方式三。 另外，页面4011中显示有按钮“非单次支付”。客户端401的用户若 未点击该按钮可认为用户默认选择单次支付。用户可以向服务器402 发送单次支付请求，以请求通过支付方式一完成2000的支付。

服务器402确定用户的单次支付金额最大限度为1500，则向客户 端401返回指示本次支付超额的超额提示信息。之后如页面4012所示， 用户可以点击按钮“非单次支付”，同时修改金额为1000，并向服务 器402发送非单次支付请求，以请求利用支付方式一先支付1000。

服务器402可以计算剩余未支付金额为1000并在客户端页面 4013中显示。用户可以进一步向服务器402发送非单次支付请求，以 请求利用支付方式二先支付1000。

服务器402可以计算剩余未支付金额为0，则表示用户已经完成 待支付金额2000的支付。进而，服务器402可以向用户返回支付明细。 具体如客户端页面4014所示，支付明细的内容可以包括“支付成功”、 “支付总金额2000”、“利用支付方式一支付1000”和“利用支付方 式二支付1000”等信息。

本公开的上述实施例提供的方法通过向用户提供单次支付和非单 次支付两种支付选择，以便于用户根据实际的需求选择合适的支付流 程。同时，能够让用户通过两次或多次支付来完成支付流程，以解决 用户在单次支付过程中常出现的由于超额等情况而导致的本次支付失 败的问题，从而提升支付效率。

进一步参考图5，其示出了支付方法的再一个实施例的流程500。 该支付方法可以应用于客户端(如图1所示的终端设备101、102、103 等)。该支付方法的流程500具体包括以下步骤：

步骤501，发送针对待支付资源的初始支付资源。

在本实施例中，支付方法的执行主体(如图1所示的终端设备101、 102、103等)可以向服务端(如图1所示的服务器等)发送初始支付 资源。具体地，客户端可以展示有用于指示待支付资源的信息，并针 对该信息向服务端发送针对该待支付资源的初始支付资源。一般地， 初始支付资源小于待支付资源。

步骤502，接收未支付资源。

在本实施例中，未支付资源可以根据待支付资源和初始支付资源 的差值确定。一般地，未支付资源可以由服务端通过计算待支付资源 和初始支付资源的差值得到。

在一些情况下，初始支付资源或其它一些因素(如具有关联优惠 资源等等)可能会影响未支付资源。此时，可以结合具体的应用场景 和应用需求确定未支付资源。

步骤503，执行如下支付步骤5031-5032：

步骤5031，发送针对未支付资源的当前支付资源。

在本实施例中，客户端可以针对当前的未支付资源向服务端发送 支付资源作为当前支付资源。一般地，当前支付资源不大于当前的未 支付资源。然后，服务端可以根据未支付资源和当前支付资源的差值 来更新未支付资源，以得到更新后的未支付资源作为当前最新的未支 付资源，并将最新的未支付资源发送至客户端。

另外，服务端在对未支付资源每次更新后都可以进一步确定更新 后的未支付资源是否为0。若更新后的未支付资源为0，可以表示已经 完成针对待支付资源的支付。对应地，若更新后的未支付资源不为0， 则可以表示还存在剩余没有进行支付的资源，即还未完成针对待支付 资源的支付。

步骤5032，接收用于指示支付成功的支付结果信息。

在本实施例中，支付结果信息可以响应于确定更新后的未支付资 源为零由服务端发送至客户端。其中，更新后的未支付资源可以由服 务端根据未支付资源和当前支付资源的差值确定。

在更新后的未支付资源为0时，可以表示已经完成针对待支付资 源的支付，此时客户端可以接收服务端返回的、用于指示支付成功的 支付结果信息。

可选地，上述支付步骤在每次执行时客户端向服务端发送的当前 支付资源可以灵活设置。例如，可以由用户根据实际的需求设置每次 发送的支付资源。

在本实施例的一些可选的实现方式中，响应于确定更新后的未支 付资源不为零，继续执行上述支付步骤。在更新后的未支付资源不为 0时，可以由服务端更新当前的未支付资源，并使用更新后的未支付 资源作为新的未支付资源，并将新的未支付资源返回至客户端。然后 客户端可以继续发送针对当前的未支付资源的支付资源，直至在更新 后的未支付资源为0时接收到服务端返回的、用于指示支付成功的支 付结果信息。

在本实施例的一些可选的实现方式中，初始支付资源的支付方式 信息可以与当前支付资源的支付方式信息可以不同。其中，支付方式 信息可以用于指示支付资源时所使用的支付方式。作为示例，在资源 为货币时，支付方式包括但不限于：***支付、储蓄卡支付、第三 方支付平台提供各种支付方式等等。

此时，支付步骤在每次执行时的当前支付资源的支付方式信息也 可以不同。即支付步骤在循环多次执行时，每次的支付方式可以不同。

可选地，客户端可以展示供用户可选的或可使用的支付方式，以 便于用户选择其期望使用的支付方式。客户端展示的支付方式可以根 据实际的应用场景或应用需求灵活设置。例如，可以根据用户的历史 支付记录分析用户对支付方式的偏好，在客户端优先展示用户偏好度 较高的支付方式。又例如，可以根据实际的应用场景针对不同的支付 方式设置不同的优先级，然后按照对应的优先级由高到低的顺序在客 户端展示不同的支付方式。

在本实施例的一些可选的实现方式中，客户端还可以向服务端发 送针对待支付资源的非单次支付请求，然后基于该非单次支付请求， 向服务端发送针对待支付资源的初始支付资源。之后可以继续执行上 述步骤502-503以完成待支付资源的支付。

具体地，客户端可以展示有用于指示非单次支付请求的信息，然 后客户端的用户可以根据该信息向服务端发送非单次支付请求。作为 示例，客户端的支付页面中可以展示用于指示非单次支付请求的按钮， 用户可以通过点击该按钮向服务端发送非单次支付请求。

可选地，客户端可以在向服务端发送非单次支付请求的同时发送 初始支付资源。作为示例，用户可以使用客户端输入初始支付资源， 然后向服务端发送携带有初始支付资源这一参数的非单次支付请求。

在本实施例的一些可选的实现方式中，在上述步骤501之前，客 户端可以向服务端发送针对待支付资源的单次支付请求。然后，客户 端响应于确定单次支付请求不符合预设支付条件，可以进一步执行上 述步骤502以向服务端发送针对待支付资源的非单次支付请求。

具体地，客户端可以展示有用于指示单次支付请求的信息，然后 客户端的用户可以根据该信息向服务端发送单次支付请求。服务端在 接收到单次支付请求之后，可以进一步对该单次支付请求进行校验， 以确定该单次支付请求是否符合预设支付条件，并向客户端返回用于 指示该单次支付请求是否符合预设支付条件的信息。客户端则可以根 据服务端返回的、用于指示该单次支付请求是否符合预设支付条件的 信息确定该单次支付请求是否符合预设支付条件。

其中，预设支付条件可以根据实际的应用需求或应用场景预先进 行设置。

可选地，客户端还可以基于其发送的单次支付请求向服务端发送 单次支付资源。其中，单次支付资源可以指用于一次完成上述待支付 资源的支付的资源。例如，客户端可以在发送单次支付请求的同时发 送单次支付资源。作为示例，用户可以使用客户端输入单次支付资源， 然后向服务端发送携带有单次支付资源这一参数的单次支付请求。

此时，服务端可以通过校验单次支付请求对应的单次支付资源来 确定该单次支付请求是否符合预设支付条件。具体地，若查询到单次 支付资源符合对应的条件信息，则可以认为客户端发送的单次支付请 求符合预设支付条件。对应地，若查询到单次支付资源不符合对应的 条件信息，则可以认为客户端发送的单次支付请求不符合预设支付条 件。

若客户端发送的单次支付请求符合预设支付条件，则可以利用该 单次支付请求完成待支付资源的支付，并接收服务端返回的、用于指 示支付成功的支付结果信息。

若客户端发送的单次支付请求不符合预设支付条件，则可以向服 务端发送非单次支付请求，以请求通过非单次支付来完成待支付资源 的支付。

本实施例中未具体说明的内容可参考图2-图3对应实施例中的相 关说明，在此不再赘述。

本公开的上述实施例提供的方法可以通过两次或超过两次的支付 过程来完成待支付资源的支付，这样一来，可以在支付过程中为用户 提供较高的灵活性，如控制支付的次数和每次支付的资源、使用不同 的支付方式等等。对于用户来说，有助于提升用户在支付过程中的体 验，减少支付失败的次数。

进一步参考图6，其示出了支付***的一个实施例的时序图600。 该支付***包括客户端(如图1所示的终端设备101、102、103等) 和服务端(如图1所示的服务器105等)。

在步骤601中，客户端向服务端发送针对待支付资源的初始支付 资源。

在步骤602中，服务端根据待支付资源和初始支付资源的差值， 确定未支付资源。

在步骤603中，服务端向客户端发送未支付资源。

在步骤604中，客户端向服务端发送针对未支付资源的当前支付 资源。

在步骤605中，服务端根据未支付资源和当前支付资源的差值， 更新未支付资源，以及确定更新后的未支付资源是否为零。

在步骤606中，服务端响应于确定更新后的未支付资源为零，向 客户端返回用于指示支付成功的支付结果信息。

可选地，服务端响应于确定更新后的未支付资源不为零，可以确 定更新后的未支付资源作为未支付资源，继续执行上述步骤603-606。

可选地，客户端还可以向服务端发送针对待支付资源的非单次支 付请求；然后根据该非单次支付请求，向服务端发送针对待支付资源 的初始支付资源。之后可以执行上述步骤602-606。

可选地，客户端还可以向服务端发送针对待支付资源的单次支付 请求；然后服务端可以校验该单次支付请求是否符合预设支付条件。 服务端响应于确定该单次支付请求不符合预设支付条件，可以向服务 端发送用于指示该单次支付请求不符合预设支付条件的信息。之后， 客户端可以根据用于指示该单次支付请求不符合预设支付条件的信 息，向服务端发送针对待支付资源的非单次支付请求。

可选地，初始支付资源的支付方式信息与当前支付资源的支付方 式信息可以不同。另外，客户端每次向服务端发送的当前支付资源的 支付方式信息可以不同。

可选地，服务端可以根据实际的应用需求和应用场景进行配置。 例如，服务端可以包括第一服务端和第二服务端。其中，第一服务端 可以与客户端进行直接的信息交互。第二服务端可以与第一服务端进 行交互以处理第一服务端从客户端接收的信息，以生成用于发送至客 户端的信息。

作为示例，第一服务端可以用于接收客户端发送的单次支付请求， 以及接收客户端发送的单次支付资源，并根据单次支付资源校验单次 支付请求是否符合预设支付条件；若单次支付资源校验单次支付请求 不符合预设支付条件，第一服务端可以向客户端发送用于指示支付失 败的支付结果信息；若单次支付资源校验单次支付请求符合预设支付 条件，第一服务端可以完成针对待支付资源的支付过程，并向客户端 发送用于指示支付成功的支付结果信息。

第一服务端还可以用于接收客户端发送的非单次支付请求，以及 接收客户端发送的初始支付资源，并将初始支付资源发送至第二服务 端。第二服务端可以用于根据初始支付资源和待支付资源的差值确定 未支付资源，并确定未支付资源是否为0；若未支付资源为0，第二服 务端可以通知第一服务端向客户端发送用于指示支付成功的支付结果 信息；若未支付资源不为0，第二服务端可以通知第一服务端继续接 收客户端发送的当前支付资源并继续更新未支付资源以完成待支付资 源的支付过程。

本实施例中未具体说明的内容可参考图2-图5对应实施例中的相 关说明，在此不再赘述。

本公开的实施例提供的支付***，通过客户端向服务端发送针对 待支付资源的初始支付资源，服务端根据初始支付资源确定未支付资 源，并接收客户端发送的当前支付资源，再根据当前支付资源更新未 支付资源，直至更新后的未支付资源为零时确定支付成功。由此一来， 可以通过两次及以上的支付来完成待支付资源的支付过程，从而增加 一种新的支付过程，同时也可以提升支付过程的灵活性。

进一步参考图7，作为对上述图2所示方法的实现，本公开提供 了应用于服务端的支付装置的一个实施例，该装置实施例与图2所示 的方法实施例相对应，该装置具体可以应用于各种电子设备中。

如图7所示，本实施例提供的支付装置700包括初始支付资源接 收单元701、确定单元702和支付处理单元703。其中，初始支付资源 接收单元701被配置成接收针对待支付资源的初始支付资源；确定单 元702被配置成根据待支付资源和初始支付资源的差值，确定未支付 资源；支付处理单元703被配置成执行如下支付处理步骤：接收针对 未支付资源的当前支付资源，以及根据未支付资源和当前支付资源的 差值，更新未支付资源；确定更新后的未支付资源是否为零；响应于 确定更新后的未支付资源为零，返回用于指示支付成功的支付结果信 息。

在本实施例中，支付装置700中：初始支付资源接收单元701、 确定单元702和支付处理单元703的具体处理及其所带来的技术效果 可分别参考图2对应实施例中的步骤201、步骤202和步骤203的相 关说明，在此不再赘述。

在本实施例的一些可选的实现方式中，上述支付处理步骤还包括： 响应于确定更新后的未支付资源不为零，确定更新后的未支付资源作 为未支付资源，继续执行上述支付处理步骤。

在本实施例的一些可选的实现方式中，上述支付装置700还包括： 非单次支付请求接收单元(图中未示出)，被配置成接收针对待支付 资源的非单次支付请求；初始支付资源接收单元701进一步被配置成 基于非单次支付请求，接收针对待支付资源的初始支付资源。

在本实施例的一些可选的实现方式中，上述支付装置700还包括： 单次支付请求接收单元(图中未示出)，被配置成接收针对待支付资 源的单次支付请求；上述非单次支付请求接收单元，进一步被配置成 响应于确定单次支付请求不符合预设支付条件，接收针对待支付资源 的非单次支付请求。

在本实施例的一些可选的实现方式中，初始支付资源的支付方式 信息与当前支付资源的支付方式信息不同；以及上述支付处理步骤在 每次执行时的当前支付资源的支付方式信息不同。

本公开的上述实施例提供的支付装置通过初始支付资源接收单元 接收针对待支付资源的初始支付资源；确定单元根据待支付资源和初 始支付资源的差值，确定未支付资源；支付处理单元执行如下支付处 理步骤：接收针对未支付资源的当前支付资源，以及根据未支付资源 和当前支付资源的差值，更新未支付资源；确定更新后的未支付资源 是否为零；响应于确定更新后的未支付资源为零，返回用于指示支付 成功的支付结果信息。由此一来，可以向用户提供单次支付和非单次 支付两种支付选择，以便于用户根据实际的需求选择合适的支付流程。 同时，能够让用户通过两次或多次支付来完成支付流程，以解决用户 在单次支付过程中常出现的由于超额等情况而导致的本次支付失败的 问题，从而提升支付效率。

进一步参考图8，作为对上述图5所示方法的实现，本公开提供 了应用于客户端的支付装置的又一个实施例，该装置实施例与图5所 示的方法实施例相对应，该装置具体可以应用于各种电子设备中。

如图8所示，本实施例提供的支付装置800包括初始支付资源发 送单元801、未接收资源接收单元802和支付单元803。初始支付资源 发送单元801被配置成发送针对待支付资源的初始支付资源；未支付 资源接收单元802被配置成接收未支付资源，其中，未支付资源根据 待支付资源和初始支付资源的差值确定；支付单元803被配置成执行 如下支付步骤：发送针对未支付资源的当前支付资源；接收用于指示 支付成功的支付结果信息，其中，支付结果信息响应于确定更新后的 未支付资源为零被发送，更新后的未支付资源根据未支付资源和当前 支付资源的差值确定。

在本实施例中，支付装置800中：初始支付资源发送单元801、 未接收资源接收单元802和支付单元803的具体处理及其所带来的技 术效果可分别参考图5对应实施例中的步骤501、步骤502和步骤503 的相关说明，在此不再赘述。

在本实施例的一些可选的实现方式中，上述支付步骤还包括：响 应于确定更新后的未支付资源不为零，继续执行上述支付步骤。

在本实施例的一些可选的实现方式中，上述支付装置800还包括： 非单次支付请求发送单元(图中未示出)，被配置成发送针对待支付 资源的非单次支付请求；以及初始支付资源发送单元801进一步被配 置成基于非单次支付请求，发送针对待支付资源的初始支付资源。

在本实施例的一些可选的实现方式中，上述支付装置800还包括： 单次支付请求发送单元(图中未示出)，被配置成发送针对待支付资 源的单次支付请求；上述非单次支付请求发送单元进一步被配置成： 响应于确定单次支付请求不符合预设支付条件，发送针对待支付资源 的非单次支付请求。

在本实施例的一些可选的实现方式中，初始支付资源的支付方式 信息与当前支付资源的支付方式信息不同；以及支付步骤在每次执行 时的当前支付资源的支付方式信息不同。

本公开的上述实施例提供的支付装置，通过初始支付资源发送单 元发送针对待支付资源的初始支付资源；未支付资源接收单元接收未 支付资源，其中，未支付资源根据待支付资源和初始支付资源的差值 确定；支付单元执行如下支付步骤：发送针对未支付资源的当前支付 资源；接收用于指示支付成功的支付结果信息，其中，支付结果信息 响应于确定更新后的未支付资源为零被发送，更新后的未支付资源根 据未支付资源和当前支付资源的差值确定。由此一来，可以在支付过 程中为用户提供较高的灵活性，如控制支付的次数和每次支付的资源、 使用不同的支付方式等等。对于用户来说，有助于提升用户在支付过 程中的体验，减少支付失败的次数。

下面参考图9，其示出了适于用来实现本公开的实施例的电子设 备(例如图1中的服务器)900的结构示意图。图9示出的电子设备 仅仅是一个示例，不应对本公开的实施例的功能和使用范围带来任何 限制。

如图9所示，电子设备900可以包括处理装置(例如中央处理器、 图形处理器等)901，其可以根据存储在只读存储器(ROM)902中的 程序或者从存储装置908加载到随机访问存储器(RAM)903中的程 序而执行各种适当的动作和处理。在RAM 903中，还存储有电子设备 900操作所需的各种程序和数据。处理装置901、ROM 902以及RAM 903通过总线904彼此相连。输入/输出(I/O)接口905也连接至总线 904。

通常，以下装置可以连接至I/O接口905：包括例如触摸屏、触摸 板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置 906；包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置 907；包括例如磁带、硬盘等的存储装置908；以及通信装置909。通 信装置909可以允许电子设备900与其他设备进行无线或有线通信以 交换数据。虽然图9示出了具有各种装置的电子设备900，但是应理 解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具 备更多或更少的装置。图9中示出的每个方框可以代表一个装置，也 可以根据需要代表多个装置。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以 被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程 序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程 序包含用于执行流程图所示的方法的程序代码。在这样的实施例中， 该计算机程序可以通过通信装置909从网络上被下载和安装，或者从 存储装置908被安装，或者从ROM 902被安装。在该计算机程序被处 理装置901执行时，执行本公开的实施例的方法中限定的上述功能。

需要说明的是，本公开的实施例所述的计算机可读介质可以是计 算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组 合。计算机可读存储介质例如可以是——但不限于——电、磁、光、 电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。 计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或 多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器 (RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM 或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开的实施例 中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该 程序可以被指令执行***、装置或者器件使用或者与其结合使用。而 在本公开的实施例中，计算机可读信号介质可以包括在基带中或者作 为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。 这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光 信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机 可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可 以发送、传播或者传输用于由指令执行***、装置或者器件使用或者 与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何 适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或 者上述的任意合适的组合。

上述计算机可读介质可以是上述电子设备中所包含的；也可以是 单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一 个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使 得该电子设备：接收针对待支付资源的初始支付资源；根据待支付资 源和初始支付资源的差值，确定未支付资源；执行如下支付处理步骤： 接收针对未支付资源的当前支付资源，以及根据未支付资源和当前支 付资源的差值，更新未支付资源；确定更新后的未支付资源是否为零； 响应于确定更新后的未支付资源为零，返回用于指示支付成功的支付 结果信息。

可以以一种或多种程序设计语言或其组合来编写用于执行本公开 的实施例的操作的计算机程序代码，所述程序设计语言包括面向对象 的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式 程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可 以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一 个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、 或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中， 远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域 网(WAN)——连接到用户计算机，或者，可以连接到外部计算机(例 如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本公开各种实施例的***、 方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点 上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码 的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实 现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实 现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。 例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时 也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是， 框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的***来实现， 或者可以用专用硬件与计算机指令的组合来实现。

描述于本公开的实施例中所涉及到的单元可以通过软件的方式实 现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理 器中，例如，可以描述为：一种处理器包括初始支付资源接收单元、 确定单元和支付处理单元。其中，这些单元的名称在某种情况下并不 构成对该单元本身的限定，例如，初始支付资源接收单元还可以被描 述为“接收针对待支付资源的初始支付资源的单元”。

以上描述仅为本公开的较佳实施例以及对所运用技术原理的说 明。本领域技术人员应当理解，本公开的实施例中所涉及的发明范围， 并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在 不脱离上述发明构思的情况下，由上述技术特征或其等同特征进行任 意组合而形成的其它技术方案。例如上述特征与本公开的实施例中公 开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技 术方案。

Claims (15)

1.一种支付方法，应用于服务端，包括：

接收针对待支付资源的初始支付资源；

根据所述待支付资源和初始支付资源的差值，确定未支付资源；

执行如下支付处理步骤：

接收针对未支付资源的当前支付资源，以及根据未支付资源和当前支付资源的差值，更新未支付资源；

确定更新后的未支付资源是否为零；

响应于确定更新后的未支付资源为零，返回用于指示支付成功的支付结果信息。

2.根据权利要求1所述的方法，其中，所述支付处理步骤还包括：

响应于确定更新后的未支付资源不为零，确定更新后的未支付资源作为未支付资源，继续执行所述支付处理步骤。

3.根据权利要求1所述的方法，其中，所述方法还包括：

接收针对所述待支付资源的非单次支付请求；以及

所述接收针对待支付资源的初始支付资源，包括：

基于所述非单次支付请求，接收针对待支付资源的初始支付资源。

4.根据权利要求3所述的方法，其中，所述方法还包括：

接收针对所述待支付资源的单次支付请求；以及

所述接收针对所述待支付资源的非单次支付请求，包括：

响应于确定所述单次支付请求不符合预设支付条件，接收针对所述待支付资源的非单次支付请求。

5.根据权利要求1-4之一所述的方法，其中，所述初始支付资源的支付方式信息与当前支付资源的支付方式信息不同；以及

所述支付处理步骤在每次执行时的当前支付资源的支付方式信息不同。

6.一种支付方法，应用于客户端，包括：

发送针对待支付资源的初始支付资源；

接收未支付资源，其中，所述未支付资源根据所述待支付资源和初始支付资源的差值确定；

执行如下支付步骤：

发送针对未支付资源的当前支付资源；

接收用于指示支付成功的支付结果信息，其中，所述支付结果信息响应于确定更新后的未支付资源为零被发送，更新后的未支付资源根据未支付资源和当前支付资源的差值确定。

7.根据权利要求6所述的方法，其中，所述支付步骤还包括：

响应于确定更新后的未支付资源不为零，继续执行所述支付步骤。

8.根据权利要求6所述的方法，其中，所述方法还包括：

发送针对所述待支付资源的非单次支付请求；以及

所述发送针对待支付资源的初始支付资源，包括：

基于所述非单次支付请求，发送针对待支付资源的初始支付资源。

9.根据权利要求8所述的方法，其中，所述方法还包括：

发送针对所述待支付资源的单次支付请求；以及

所述发送针对所述待支付资源的非单次支付请求，包括：

响应于确定所述单次支付请求不符合预设支付条件，发送针对所述待支付资源的非单次支付请求。

10.根据权利要求6-9之一所述的方法，其中，所述初始支付资源的支付方式信息与当前支付资源的支付方式信息不同；以及

所述支付步骤在每次执行时的当前支付资源的支付方式信息不同。

11.一种支付***，包括客户端和服务端；

所述服务端，用于执行如权利要求1-5中任一所述的方法；

所述客户端，用于执行如权利要求6-10中任一所述的方法。

12.一种支付装置，应用于服务端，包括：

初始支付资源接收单元，被配置成接收针对待支付资源的初始支付资源；

确定单元，被配置成根据所述待支付资源和初始支付资源的差值，确定未支付资源；

支付处理单元，被配置成执行如下支付处理步骤：接收针对未支付资源的当前支付资源，以及根据未支付资源和当前支付资源的差值，更新未支付资源；确定更新后的未支付资源是否为零；响应于确定更新后的未支付资源为零，返回用于指示支付成功的支付结果信息。

13.一种支付装置，应用于客户端，包括：

初始支付资源发送单元，被配置成发送针对待支付资源的初始支付资源；

未支付资源接收单元，被配置成接收未支付资源，其中，所述未支付资源根据所述待支付资源和初始支付资源的差值确定；

支付单元，被配置成执行如下支付步骤：发送针对未支付资源的当前支付资源；接收用于指示支付成功的支付结果信息，其中，所述支付结果信息响应于确定更新后的未支付资源为零被发送，更新后的未支付资源根据未支付资源和当前支付资源的差值确定。

14.一种电子设备，包括：

一个或多个处理器；

存储装置，其上存储有一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-10中任一所述的方法。

15.一种计算机可读介质，其上存储有计算机程序，其中，该程序被处理器执行时实现如权利要求1-10中任一所述的方法。

Images