CN105931036A - 支付方法及装置 - Google Patents

Abstract

本公开是关于支付方法及装置，所述方法包括：将携带付款金额的付款请求发送至支付通道对应的服务器，所述付款金额是付款方向收款方待支付的金额；若在第一预设时长内未接收到所述服务器返回的指定支付信息，获取付款方的信用度；根据所获取的信用度判定满足预设垫付条件时，垫付所述付款金额，并向收款方的终端输出支付成功信息，从而避免由于网速、服务器状况等多方面因素导致付款时间延长，缩短了付款响应时间，提高了支付效率。

Description

支付方法及装置

技术领域

本申请涉及支付技术领域，尤其涉及支付方法及装置。

背景技术

随着互联网的发展，通过第三方支付平台进行支付已成为人们日常生活中广泛使用的支付方式。第三方支付平台可以是支付宝、快钱、微信等，使得付款方和收款方之间的交易更加方便、快捷。

第三方支付平台上可以有很多支付通道，不同的支付通道对应有相应的服务器，例如第三方支付平台绑定的银行支付通道，银行支付通道对应有银行服务器。第三方支付平台接收支付请求，在根据支付请求对用户身份验证通过的情况下，生成携带付款金额的付款请求，并将付款请求发送至支付通道对应的服务器，第三方支付平台在接收到该服务器返回的支付成功信息时，向收款方的终端输出支付成功信息。

然而，第三方支付平台向其他服务器请求付款的过程中，可能会受到网速、服务器状况等多方面因素的影响，导致付款响应时间长，从而降低网上支付效率。

发明内容

为克服相关技术中存在的问题，本公开提供了支付方法及装置。

根据本公开实施例的第一方面，提供一种支付方法，所述方法包括：

将携带付款金额的付款请求发送至支付通道对应的服务器，所述付款金额是付款方向收款方待支付的金额；

若在第一预设时长内未接收到所述服务器返回的指定支付信息，获取付款方的信用度；

根据所获取的信用度判定满足预设垫付条件时，垫付所述付款金额，并向收款方的终端输出支付成功信息。

可选的，所述若在第一预设时长内未接收到所述服务器返回的指定支付信息，获取付款方的信用度，包括：

若在第一预设时长内没有接收到所述服务器返回的支付成功信息，获取付款方的信用度；

或，

在第一预设时长内既没接收到所述服务器返回的支付成功信息，也没接收到所述服务器返回的支付失败信息时，获取付款方的信用度。

可选的，所述获取付款方的信用度，包括：

获取付款方的历史交易记录；

根据所获取的历史交易记录确定所述付款方的信用度。

可选的，所述历史交易记录包括历史交易频率、历史交易中支付成功的概率、历史交易中垫付金额的还款记录中的一种或多种。

可选的，所述预设垫付条件包括：

信用度大于或等于预设信用阈值；

或，信用度大于或等于预设信用阈值、且所述付款金额小于或等于预设垫付额度。

可选的，所述方法还包括：

在第二预设时长内每间隔设定时间向所述服务器发送所述付款请求，直到接收到所述服务器返回的支付成功信息。

可选的，所述方法还包括：

若在第二预设时长内未接收到所述服务器返回的支付成功信息时，向付款方的终端输出还款提醒信息，所述还款提醒信息中携带所述付款金额。

根据本公开实施例的第二方面，提供一种支付装置，所述装置包括：

请求发送模块，被配置为将携带付款金额的付款请求发送至支付通道对应的服务器，所述付款金额是付款方向收款方待支付的金额；

信用度获取模块，被配置为若在第一预设时长内未接收到所述服务器返回的指定支付信息，获取付款方的信用度；

金额垫付模块，被配置为根据所获取的信用度判定满足预设垫付条件时，垫付所述付款金额；

信息输出模块，被配置为向收款方的终端输出支付成功信息。

可选的，所述信用度获取模块包括：

第一信用度获取子模块，被配置为若在第一预设时长内没有接收到所述服务器返回的支付成功信息，获取付款方的信用度；

或，

第二信用度获取子模块，被配置为在第一预设时长内既没接收到所述服务器返回的支付成功信息，也没接收到所述服务器返回的支付失败信息时，获取付款方的信用度。

可选的，所述信用度获取模块包括：

记录获取子模块，被配置为获取付款方的历史交易记录；

信用度确定子模块，被配置为根据所获取的历史交易记录确定所述付款方的信用度。

可选的，所述历史交易记录包括历史交易频率、历史交易中支付成功的概率、历史交易中垫付金额的还款记录中的一种或多种。

可选的，所述预设垫付条件包括：

信用度大于或等于预设信用阈值；

或，信用度大于或等于预设信用阈值、且所述付款金额小于或等于预设垫付额度。

可选的，所述请求发送模块还被配置为：

在第二预设时长内每间隔设定时间向所述服务器发送所述付款请求，直到接收到所述服务器返回的支付成功信息。

可选的，所述信息输出模块，还被配置为若在第二预设时长内未接收到所述服务器返回的支付成功信息时，向付款方的终端输出还款提醒信息，所述还款提醒信息中携带所述付款金额。

根据本公开实施例的第三方面，提供一种支付装置，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

将携带付款金额的付款请求发送至支付通道对应的服务器，所述付款金额是付款方向收款方待支付的金额；

若在第一预设时长内未接收到所述服务器返回的指定支付信息，获取付款方的信用度；

根据所获取的信用度判定满足预设垫付条件时，垫付所述付款金额，并向收款方的终端输出支付成功信息。

本公开的实施例提供的技术方案可以包括以下有益效果：

本公开通过将携带付款金额的付款请求发送至支付通道对应的服务器，若在第一预设时长内未接收到服务器返回的指定支付信息，获取付款方的信用度，根据所获取的信用度判定满足预设垫付条件时，垫付付款金额，并向收款方的终端输出支付成功信息，从而避免由于网速、服务器状况等多方面因素导致付款时间延长，缩短了付款响应时间，提高了支付效率。

本公开只要在第一预设时长内没有接收到支付成功信息，均进行垫付条件的判断，从而实现不管是收到支付失败信息，还是没有接收到任何反馈信息，均根据付款方的信用度判断是否进行垫付，从而提高成功支付的概率。

本公开为了避免无法偿还垫付金额的情况，在接收到支付失败信息时也不进行金额垫付，从而减小了垫付的风险。

本公开通过获取付款方的历史交易记录，根据所获取的历史交易记录确定所述付款方的信用度，从而提高信用度的可靠性。

本公开可以根据历史交易频率确定付款方的信用度，从而实现将经常消费的用户判定为信用度较高的用户；也可以根据支付成功的概率确定付款方的信用度，从而实现将经常消费且支付成功率比较高的用户判定为信用度较高的用户；还可以根据付款方还款的记录确定付款方的信用度，从而减小垫付风险。

本公开将信用度大于或等于预设信用阈值作为预设垫付条件，从而实现根据信用度判断是否执行垫付行为。

本公开不仅将信用度作为是否垫付的判断条件，还将付款金额作为是否垫付的判断条件，从而避免信用度低、金额过大造成不还款的风险。

本公开可以在第二预设时长内每间隔设定时间向服务器发送付款请求，直到接收到服务器返回的支付成功信息，以实现主动向服务器发送付款请求，以便完成付款。

本公开在第二预设时长内未接收到所述服务器返回的支付成功信息时，向付款方的终端输出还款提醒信息，从而提醒付款方还款，避免服务器不进行付款操作造成的损失。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1A是本公开根据一示例性实施例示出的一种支付方法的流程图。

图1B是本公开根据一示例性实施例示出的一种支付通道选择示意图。

图2是本公开根据一示例性实施例示出的另一种支付方法的流程图。

图3是本公开根据一示例性实施例示出的一种支付装置的框图。

图4是本公开根据一示例性实施例示出的另一种支付装置的框图。

图5是本公开根据一示例性实施例示出的另一种支付装置的框图。

图6是本公开根据一示例性实施例示出的另一种支付装置的框图。

图7是根据一示例性实施例示出的一种用于支付装置的一结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

在本公开使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开。在本公开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本公开可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

随着互联网的发展，用户习惯通过第三方支付平台进行支付。例如用户通过第三方支付平台在电子商务平台进行支付，如用户在淘宝上进行购物时，通过支付平台中工商银行通道进行支付。其中，第三方支付平台可以是为买方和卖方双方提供信用增强的一方平台，相当于在银行的直接支付环节中增加一中介。在通过第三方支付平台交易时，买方选购商品，将款项不直接打给卖方而是付给第三方支付平台，第三方支付平台通知卖家发货；买方收到商品后，通知付款，第三方支付平台将款项转至卖家账户，在没收到买方发送的付款通知时，也可以在间隔预设时长时默认买方收到商品，将款项转至卖家账户。

由于第三方支付平台上可以有很多支付通道，不同的支付通道对应有相应的服务器。在第三方支付平台向支付通道对应的服务器请求付款的过程中，可能会受到网速、服务器状况等多方面因素的影响，导致付款耗费时间长，从而降低网上支付效率。

为了提高支付效率，本公开提供一种支付方法，该支付方法将携带付款金额的付款请求发送至支付通道对应的服务器，若在第一预设时长内未接收到服务器返回的指定支付信息，获取付款方的信用度，根据所获取的信用度判定满足预设垫付条件时，垫付所述付款金额，并向收款方的终端输出支付成功信息，避免因为网速、服务器状况等因素造成等待指定支付信息时间长，从而提高网上支付效率。

如图1A所示，图1A是本公开根据一示例性实施例示出的一种支付方法的流程图，包括以下步骤101至步骤103：

在步骤101中，将携带付款金额的付款请求发送至支付通道对应的服务器，所述付款金额是付款方向收款方待支付的金额。

在步骤102中，若在第一预设时长内未接收到所述服务器返回的指定支付信息，获取付款方的信用度。

在步骤103中，根据所获取的信用度判定满足预设垫付条件时，垫付所述付款金额，并向收款方的终端输出支付成功信息。

本公开方法可以应用于支付平台的服务端中，例如第三方支付平台的服务器中。本公开方法所涉及的应用场景是，付款过程中至少存在两个需要交互的服务端，即支付平台所在服务器以及支付通道对应的服务器。基于此，应用场景既可以是线上交易，如网上购物、网上转账等，也可以是线下交易。

其中，第三方支付平台是和产品所在国家以及国内外各大银行签约、并具备一定实力和信誉保障的第三方独立机构提供的交易支持平台。例如，第三方支付平台可以是支付宝、快钱、微信等。第三方支付平台提供多种支付通道，支付通道是第三方支付平台上提供的支付渠道。在第三方支付平台上可以提供多种付款方式，每种付款方式为一种支付通道。如图1B所示，图1B是本公开根据一示例性实施例示出的一种支付通道选择示意图。该示意图中，以淘宝的支付平台为例，付款方式中提供了多种支付通道，例如余额宝、中国工商银行、中国建设银行、中国交通银行。由于涉及与服务器的交互，因此也可能存在付款延迟的问题。

本实施例在将携带付款金额的付款请求发送至支付通道对应的服务器之前，可以接收支付请求，并根据支付请求对用户身份进行验证。在根据支付请求对用户身份验证通过的情况下，根据与支付通道对应的服务器之间的协议，根据所接收的支付请求将携带付款金额的付款请求发送至支付通道对应的服务器。

其中，支付请求可以是用户通过电子商务平台触发生成的支付请求，例如，在电子商务平台上进行购物，电子商务平台生成订单信息，并将携带订单信息的支付请求发送至支付平台。支付请求也可以是通过支付平台触发生成的支付请求。例如，用户在支付平台上进行转账操作触发生成的支付请求，又如，用户终端扫描支付平台上的付款码触发生成的支付请求。

针对身份验证，可以采用预先设置的风控策略根据支付请求对用户身份进行验证。预先设置的风控策略可以是对用户信息的验证、可以是对请求时间的验证、可以是对请求地址的验证等。

可以理解的是，风控策略还可以是相关技术中的其他风控策略，在此不再一一赘述。此外，在一些可选的实现方式中，可以不对用户身份进行验证，在接收到支付请求后，直接将携带付款金额的付款请求发送至支付通道对应的服务器，是否进行身份验证可以根据需求设定。

关于步骤101，付款请求中可以携带付款金额，付款金额是付款方向收款方待支付的金额。以淘宝为例，付款方是买家，收款方是卖家，以转账为例，付款方是转账方，收款方是金额接收方。付款请求中除了携带付款金额，还可以携带流水号、商品信息等。支付通道可以是付款方选中的支付通道。例如，付款方在支付时可以选择不同的支付通道，从而实现利用该支付通道进行支付。又如，付款方可以将其中一个支付通道设置为默认支付通道，当扫描支付平台上的付款码时，直接向该默认支付通道对应的服务器发送付款请求。支付通道还可以是支付平台筛选出的支付成功率最高的支付通道。支付平台通过对历史支付记录进行统计，筛选出支付成功率最高的支付通道，并向该支付通道发送付款请求。

关于步骤102，在支付通道对应的服务器接收到付款请求后，可以根据付款请求进行付款操作，并将指定支付信息返回至支付平台。其中，指定支付信息是预先指定的某种类型的支付信息。

在一个可选的实现方式中，指定支付信息为支付成功信息，则步骤102为，若在第一预设时长内没有接收到所述服务器返回的支付成功信息，获取付款方的信用度。

可见，本实施例只要在第一预设时长内没有接收到支付成功信息，均进行垫付条件的判断，从而实现不管是收到支付失败信息，还是没有接收到任何反馈信息，均根据付款方的信用度判断是否进行垫付，从而提高成功支付的概率。

在另一个可选的实现方式中，指定支付信息为支付成功信息或支付失败信息，则步骤102为，在第一预设时长内既没接收到所述服务器返回的支付成功信息，也没接收到所述服务器返回的支付失败信息时，获取付款方的信用度。

由于在账户内余额不足时会造成支付失败，即服务器会返回支付失败信息，因此，为了避免无法偿还垫付金额的情况，该实施例对支付失败的情况不进行金额垫付，从而减小了垫付的风险。

针对付款方的信用度，信用度是付款方的守信程度。针对信用度的获取时机，在一个可选的实现方式中，可以是在判定第一预设时长内未接收到服务器返回的指定支付信息时，实时获取付款方的信用度。例如，实时从其他系统中获取付款方的信用度，又如实时获取付款方的历史交易记录，根据所获取的历史交易记录确定所述付款方的信用度。

在另一个可选的实现方式中，也可以预先获取付款方的信用度，并将其存储在本地，当判定第一预设时长内未接收到服务器返回的指定支付信息时，从本地获取付款方的信用度。例如预先获取方法可以为从其他系统中获取付款方的信用度，并存储在本地；又如，获取付款方的历史交易记录，根据所获取的历史交易记录确定所述付款方的信用度，并存储在本地。

其中，付款方可以是本执行端中历史交易记录中的付款方。

针对从其他系统中获取付款方的信用度。例如，从银行系统中获取付款方的信用度，又如，从电子商务平台上获取付款方的信用度。可见，直接从其他系统中获取付款方的信用度，可以提高获取信用度的效率。

针对获取付款方的历史交易记录，根据所获取的历史交易记录确定所述付款方的信用度。历史交易记录可以是本支付平台记录的该付款方的历史交易记录，也可以是其他系统中记录的付款方的历史交易记录。

其中，针对其他系统中记录的付款方的历史交易记录，可以是电子商务平台上用户成功交易的记录，可以是银行系统中付款方还信用卡的记录等。

针对本支付平台记录的该付款方的历史交易记录，为了减小计算量以及信用度的可靠性，历史交易记录可以为指定时间内的历史交易记录。例如，一个月内的历史交易记录、半年内的历史交易记录等。

其中，历史交易记录可以是历史交易频率，则可以根据历史交易频率确定付款方的信用度，例如将历史交易频率确定为信用度；又如不同历史交易频率对应有相应的信用度；又如不同历史交易频率范围对应有相应的信用度，即可根据历史交易频率所在范围确定信用度。可见，根据历史交易频率确定付款方的信用度，可以实现将经常消费的用户判定为信用度较高的用户。

历史交易记录也可以是历史交易中支付成功的概率，则可以根据支付成功的概率确定付款方的信用度。例如将支付成功的概率确定为信用度；又如不同支付成功的概率对应有相应的信用度；又如支付成功的不同概率范围对应有相应的信用度，即可以根据支付成功的概率所在的范围确定信用度。可见，根据支付成功的概率确定付款方的信用度，可以实现将经常消费且支付成功率比较高的用户判定为信用度较高的用户。

历史交易记录还可以是历史交易中垫付金额的还款记录。在每次垫付付款金额后，统计付款方还款的记录，可以根据付款方还款的记录确定付款方的信用度。例如，根据记录中成功还款的概率确定付款方的信用度。可见，根据付款方还款的记录确定付款方的信用度，以减小垫付风险。

可以理解的是，还可以根据历史交易频率、历史交易中支付成功的概率、历史交易中垫付金额的还款记录等中的多种数据确定付款方的信用度。例如，对不同数据设置相应的权重，从而确定付款方的信用度。

关于步骤103，预设垫付条件是预先设置的可以垫付付款金额的条件，可以通过垫付条件判断付款方是否有还款的可能。

在一个可选的实现方式中，预设垫付条件可以是信用度大于或等于预设信用阈值。

其中，预设信用阈值是预先设定的用来判断付款方是否有还款可能的信用度临界值。在该实施例中，将所获取的信用度与预设信用阈值进行比较，在信用度大于或等于预设信用阈值时，判定满足垫付条件，可以执行垫付行为。否则判定不满足垫付条件，可以输出支付失败提醒信息。

可见，在该实现方式中，将信用度大于或等于预设信用阈值作为预设垫付条件，从而实现根据信用度判断是否执行垫付行为。

在另一个可选的实现方式中，预设垫付条件为信用度大于或等于预设信用阈值、且所述付款金额小于或等于预设垫付额度。

其中，预设信用阈值可以是预先设定的用来判断付款方是否有还款可能的信用度临界值。预设垫付额度可以是预先设置的用来判断付款方是否有偿还能力的金额临界值，则预设垫付额度可以根据不同付款方设置不同的额度。预设垫付额度也可以是预先设置的支付平台可承受的金额临界值，例如将预设垫付额度设置为一固定金额。

在该实施例中，将所获取的信用度与预设信用阈值进行比较，将付款金额与预设垫付额度进行比较，在同时满足信用度大于或等于预设信用阈值、且付款金额小于或等于预设垫付额度时，判定满足垫付条件，可以执行垫付行为。否则判定不满足垫付条件，可以输出支付失败提醒信息。

可以理解的是，可以先判断付款金额是否小于或等于预设垫付额度，若否，直接判定不满足预设垫付条件，若是，则继续判断信用度是否大于或等于预设信用阈值；也可以先判断信用度是否大于或等于预设信用阈值，若否，直接判定不满足预设垫付条件，若是，则继续判断付款金额是否小于或等于预设垫付额度，从而可以提高判断效率。

可见，在该实现方式中，不仅将信用度作为是否垫付的判断条件，还将付款金额作为是否垫付的判断条件，从而避免信用度低、金额过大造成不还款的风险。

针对垫付付款金额，垫付付款金额可以是帮付款方预先垫付付款金额。例如，在第三方支付平台中帮付款方预先垫付付款金额，并向收款方的终端发送发货请求。其中，所谓垫付可以不需要将付款金额转至收款方的账户，而是在第三方支付平台上进行垫付操作，并向收款方发送支付成功信息，收款方可以根据支付成功信息进行相应的处理，例如发货处理，从而避免由于网速、服务器状况等多方面因素导致付款时间延长，缩短了付款响应时间，提高了支付效率。

其中，付款方的终端是付款方的账户所在终端，收款方的终端是收款方的账户所在终端。终端可以是智能手机、平板电脑、PDA(Personal Digital Assistant，个人数字助理)、电子书阅读器、多媒体播放器、计算机等等。

在垫付付款金额后，不仅向收款方的终端输出支付成功，以使收款方清楚付款情况，并执行后续操作，例如发货等；还可以向付款方的终端输出垫付结果，以使付款方清楚付款情况。其中，输出方式可以是显示、语音提示等。

由上述实施例可见，通过将携带付款金额的付款请求发送至支付通道对应的服务器，若在第一预设时长内未接收到服务器返回的指定支付信息，获取付款方的信用度，根据所获取的信用度判定满足预设垫付条件时，垫付付款金额，并向收款方的终端输出支付成功信息，从而避免由于网速、服务器状况等多方面因素导致付款时间延长，提高了支付效率。

在垫付付款金额后，需要付款方进行还款。在一个可选的实现方式中，所述支付方法还包括：在第二预设时长内每间隔设定时间向所述服务器发送所述付款请求，直到接收到所述服务器返回的支付成功信息。

其中，付款请求同步骤101中的付款请求相同，例如流水号相同，以避免服务器根据付款请求重复付款。第二预设时长是预先设置的还款等待时间。在该时间内，本执行端每间隔设定时间向服务器发送付款请求，直到接收到服务器返回的支付成功信息。设定时间可以根据需求设定，例如在第二预设时长内设定发送2次付款请求，则将第二预设时长除以2获得设定时间。假设本执行端向收款方转账的时长为第三预设时长，即间隔第三预设时长后向收款方转账所述付款金额。基于此，在设置时长时，第二预设时长比第三预设时长短，以便在转账前使付款方及时付款。

进一步的，当接收到所述服务器返回的支付成功信息时，将该次交易标记为支付成功状态。可见，将该次交易标记为支付成功状态，以便后续对账。

在一个可选的实现方式中，由于服务器故障，或是账户余额不足，可能存在支付失败等情况，则若在第二预设时长内未接收到所述服务器返回的支付成功信息时，向付款方的终端输出还款提醒信息。其中，还款提醒信息中至少携带付款金额，以便提醒用户还款的金额，付款方可以通过支付通道向该支付平台进行还款。另外，为了使用户清楚还款事件，可以输出该次交易的相关信息，以提醒用户此次还款的缘由。

此外，在支付平台与服务器或电子商务平台进行对账时，若对账失败，可以根据失败理由确定待还款事件，并根据待还款事件向付款方进行提醒。

可见，在输出支付成功信息后，等待用户还款，若在第二预设时长内未接收到任何服务器返回的支付成功信息时，直接向付款方的终端输出还款提醒信息，以便提醒用户还款。

可以理解的是，当第三间隔预设时长后，若仍没有收到支付成功信息，为了保证第三方支付平台的信誉，仍可以向收款方转账。

以上实施方式中的各种技术特征可以任意进行组合，只要特征之间的组合不存在冲突或矛盾，但是限于篇幅，未进行一一描述，因此上述实施方式中的各种技术特征的任意进行组合也属于本说明书公开的范围。

以下列举其中一种组合进行说明。如图2所示，图2是本公开根据一示例性实施例示出的另一种支付方法的流程图，包括以下步骤201至步骤208：

在步骤201中，将携带付款金额的付款请求发送至支付通道对应的服务器，所述付款金额是付款方向收款方待支付的金额。

在步骤202中，若在第一预设时长内未接收到所述服务器返回的指定支付信息，获取付款方的信用度。

在步骤203中，根据所获取的信用度判断是否满足预设垫付条件，当不满足预设垫付条件时，进入步骤204，当满足预设垫付条件时，进入步骤205。

在步骤204中，向付款方的终端和收款方的终端输出支付失败的提醒信息。

在步骤205中，垫付所述付款金额，并向收款方的终端输出支付成功信息，并进入步骤206。

在一个可选的实现方式中，还可以向付款方的终端输出支付成功信息，以提示付款方付款成功。

在步骤206中，在第二预设时长内每间隔设定时间向所述服务器发送所述付款请求，并判断是否接收到服务器返回的支付成功信息，若接收到支付成功信息，则进入步骤207，否则进入步骤208。

在步骤207中，将该次交易标记为支付成功状态。

在步骤208中，将该次交易标记为支付失败状态，并向付款方的终端输出还款提醒信息，所述还款提醒信息中携带所述付款金额。

由上述实施例可见，若在第一预设时长内未接收到服务器返回的指定支付信息时，根据付款方的信用度判断是否满足预设垫付条件，在满足预设垫付条件时进行垫付，从而避免由于网速、服务器状况等多方面因素导致等待付款时间延长，提高了支付效率。在不满足预设垫付条件时，在第二预设时长内每间隔设定时间向服务器发送付款请求，以实现还款行为，并在第二预设时长内未接收到服务器返回的支付成功信息时，向付款方的终端输出还款提醒信息，以提醒付款方还款。

与前述支付方法的实施例相对应，本公开还提供了支付装置及其所应用的服务端的实施例。

如图3所示，图3是本公开根据一示例性实施例示出的一种支付装置的框图，所述装置包括：请求发送模块310、信用度获取模块320、金额垫付模块330和信息输出模块340。

其中，请求发送模块310，被配置为将携带付款金额的付款请求发送至支付通道对应的服务器，所述付款金额是付款方向收款方待支付的金额。

信用度获取模块320，被配置为若在第一预设时长内未接收到所述服务器返回的指定支付信息，获取付款方的信用度。

金额垫付模块330，被配置为根据所获取的信用度判定满足预设垫付条件时，垫付所述付款金额。

信息输出模块340，被配置为向收款方的终端输出支付成功信息。

由上述实施例可见，通过将携带付款金额的付款请求发送至支付通道对应的服务器，若在第一预设时长内未接收到服务器返回的指定支付信息，获取付款方的信用度，根据所获取的信用度判定满足预设垫付条件时，垫付付款金额，并向收款方的终端输出支付成功信息，从而避免由于网速、服务器状况等多方面因素导致付款时间延长，提高了支付效率。

如图4所示，图4是本公开根据一示例性实施例示出的另一种支付装置的框图，该实施例在前述图3所示实施例的基础上，所述信用度获取模块320包括：第一信用度获取子模块321。

其中，第一信用度获取子模块321，被配置为若在第一预设时长内没有接收到所述服务器返回的支付成功信息，获取付款方的信用度。

由上述实施例可见，只要在第一预设时长内没有接收到支付成功信息，均进行垫付条件的判断，从而实现不管是收到支付失败信息，还是没有接收到任何反馈信息，均根据付款方的信用度判断是否进行垫付，从而提高成功支付的概率。

如图5所示，图5是本公开根据一示例性实施例示出的另一种支付装置的框图，该实施例在前述图3所示实施例的基础上，所述信用度获取模块320包括：第二信用度获取子模块322。

其中，第二信用度获取子模块322，被配置为在第一预设时长内既没接收到所述服务器返回的支付成功信息，也没接收到所述服务器返回的支付失败信息时，获取付款方的信用度。

由上述实施例可见，由于账户余额不足等原因会造成支付失败，即服务器会返回支付失败信息，因此，为了避免无法偿还垫付金额的情况，该实施例对支付失败的情况不进行金额垫付，从而减小了垫付的风险。

如图6所示，图6是本公开根据一示例性实施例示出的另一种支付装置的框图，该实施例在前述图3所示实施例的基础上，所述信用度获取模块320包括：记录获取子模块323和信用度确定子模块324。

其中，记录获取子模块323，被配置为获取付款方的历史交易记录。

信用度确定子模块324，被配置为根据所获取的历史交易记录确定所述付款方的信用度。

由上述实施例可见，通过获取付款方的历史交易记录，根据所获取的历史交易记录确定所述付款方的信用度，从而提高信用度的可靠性。

在一个可选的实现方式中，所述历史交易记录包括历史交易频率、历史交易中支付成功的概率、历史交易中垫付金额的还款记录中的一种或多种。

由上述实施例可见，可以根据历史交易频率确定付款方的信用度，从而实现将经常消费的用户判定为信用度较高的用户；也可以根据支付成功的概率确定付款方的信用度，从而实现将经常消费且支付成功率比较高的用户判定为信用度较高的用户；还可以根据付款方还款的记录确定付款方的信用度，从而减小垫付风险。

在一个可选的实现方式中，所述预设垫付条件包括：信用度大于或等于预设信用阈值。

由上述实施例可见，将信用度大于或等于预设信用阈值作为预设垫付条件，从而实现根据信用度判断是否执行垫付行为。

在一个可选的实现方式中，所述预设垫付条件包括：信用度大于或等于预设信用阈值、且所述付款金额小于或等于预设垫付额度。

由上述实施例可见，不仅将信用度作为是否垫付的判断条件，还将付款金额作为是否垫付的判断条件，从而避免信用度低、金额过大造成不还款的风险。

在一个可选的实现方式中，所述请求发送模块还被配置为：在第二预设时长内每间隔设定时间向所述服务器发送所述付款请求，直到接收到所述服务器返回的支付成功信息。

由上述实施例可见，可以在第二预设时长内每间隔设定时间向服务器发送付款请求，直到接收到服务器返回的支付成功信息，以实现主动向服务器发送付款请求，以便完成付款。

在一个可选的实现方式中，所述信息输出模块还被配置为：若在第二预设时长内未接收到所述服务器返回的支付成功信息时，向付款方的终端输出还款提醒信息，所述还款提醒信息中携带所述付款金额。

由上述实施例可见，在第二预设时长内未接收到所述服务器返回的支付成功信息时，向付款方的终端输出还款提醒信息，从而提醒付款方还款，避免服务器不进行付款操作造成的损失。

相应的，本公开还提供一种支付装置，所述装置包括有处理器；用于存储处理器可执行指令的存储器；其中，所述处理器被配置为：

将携带付款金额的付款请求发送至支付通道对应的服务器，所述付款金额是付款方向收款方待支付的金额。

若在第一预设时长内未接收到所述服务器返回的指定支付信息，获取付款方的信用度。

根据所获取的信用度判定满足预设垫付条件时，垫付所述付款金额，并向收款方的终端输出支付成功信息。

上述装置中各个模块的功能和作用的实现过程具体详情见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本公开方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

如图7所示，图7是根据一示例性实施例示出的一种用于支付装置700的一结构示意图。例如，装置700可以被提供为一服务器。参照图7，装置700包括处理组件722，其进一步包括一个或多个处理器，以及由存储器732所代表的存储器资源，用于存储可由处理部件722的执行的指令，例如应用程序。存储器732中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件722被配置为执行指令，以执行上述支付方法。

装置700还可以包括一个电源组件726被配置为执行装置700的电源管理，一个有线或无线网络接口750被配置为将装置700连接到网络，和一个输入输出(I/O)接口758。装置700可以操作基于存储在存储器732的操作系统，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM或类似。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

以上所述仅为本公开的较佳实施例而已，并不用以限制本公开，凡在本公开的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本公开保护的范围之内。

Claims (15)

1.一种支付方法，其特征在于，所述方法包括：

将携带付款金额的付款请求发送至支付通道对应的服务器，所述付款金额是付款方向收款方待支付的金额；

若在第一预设时长内未接收到所述服务器返回的指定支付信息，获取付款方的信用度；

根据所获取的信用度判定满足预设垫付条件时，垫付所述付款金额，并向收款方的终端输出支付成功信息。

2.根据权利要求1所述的方法，其特征在于，所述若在第一预设时长内未接收到所述服务器返回的指定支付信息，获取付款方的信用度，包括：

若在第一预设时长内没有接收到所述服务器返回的支付成功信息，获取付款方的信用度；

或，

在第一预设时长内既没接收到所述服务器返回的支付成功信息，也没接收到所述服务器返回的支付失败信息时，获取付款方的信用度。

3.根据权利要求1所述的方法，其特征在于，所述获取付款方的信用度，包括：

获取付款方的历史交易记录；

根据所获取的历史交易记录确定所述付款方的信用度。

4.根据权利要求3所述的方法，其特征在于，所述历史交易记录包括历史交易频率、历史交易中支付成功的概率、历史交易中垫付金额的还款记录中的一种或多种。

5.根据权利要求1所述的方法，其特征在于，所述预设垫付条件包括：

信用度大于或等于预设信用阈值；

或，信用度大于或等于预设信用阈值、且所述付款金额小于或等于预设垫付额度。

6.根据权利要求1至5任一所述的方法，其特征在于，所述方法还包括：

在第二预设时长内每间隔设定时间向所述服务器发送所述付款请求，直到接收到所述服务器返回的支付成功信息。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

若在第二预设时长内未接收到所述服务器返回的支付成功信息，向付款方的终端输出还款提醒信息，所述还款提醒信息中携带所述付款金额。

8.一种支付装置，其特征在于，所述装置包括：

请求发送模块，被配置为将携带付款金额的付款请求发送至支付通道对应的服务器，所述付款金额是付款方向收款方待支付的金额；

信用度获取模块，被配置为若在第一预设时长内未接收到所述服务器返回的指定支付信息，获取付款方的信用度；

金额垫付模块，被配置为根据所获取的信用度判定满足预设垫付条件时，垫付所述付款金额；

信息输出模块，被配置为向收款方的终端输出支付成功信息。

9.根据权利要求8所述的装置，其特征在于，所述信用度获取模块包括：

第一信用度获取子模块，被配置为若在第一预设时长内没有接收到所述服务器返回的支付成功信息，获取付款方的信用度；

或，

第二信用度获取子模块，被配置为在第一预设时长内既没接收到所述服务器返回的支付成功信息，也没接收到所述服务器返回的支付失败信息时，获取付款方的信用度。

10.根据权利要求8所述的装置，其特征在于，所述信用度获取模块包括：

记录获取子模块，被配置为获取付款方的历史交易记录；

信用度确定子模块，被配置为根据所获取的历史交易记录确定所述付款方的信用度。

11.根据权利要求10所述的装置，其特征在于，所述历史交易记录包括历史交易频率、历史交易中支付成功的概率、历史交易中垫付金额的还款记录中的一种或多种。

12.根据权利要求8所述的装置，其特征在于，所述预设垫付条件包括：

信用度大于或等于预设信用阈值；

或，信用度大于或等于预设信用阈值、且所述付款金额小于或等于预设垫付额度。

13.根据权利要求8至12任一所述的装置，其特征在于，所述请求发送模块还被配置为：

在第二预设时长内每间隔设定时间向所述服务器发送所述付款请求，直到接收到所述服务器返回的支付成功信息。

14.根据权利要求13所述的装置，其特征在于，所述信息输出模块，还被配置为若在第二预设时长内未接收到所述服务器返回的支付成功信息，向付款方的终端输出还款提醒信息，所述还款提醒信息中携带所述付款金额。

15.一种支付装置，其特征在于，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

将携带付款金额的付款请求发送至支付通道对应的服务器，所述付款金额是付款方向收款方待支付的金额；

若在第一预设时长内未接收到所述服务器返回的指定支付信息，获取付款方的信用度；

根据所获取的信用度判定满足预设垫付条件时，垫付所述付款金额，并向收款方的终端输出支付成功信息。