识别重复付款的方法、装置及设备与流程

本说明书涉及互联网技术领域，尤其涉及识别重复付款的方法、装置及设备。

背景技术

通常情况下，付款业务的发起过程包括：付款发起方(简称发起方)向付款受理方(简称受理方)发送付款请求，受理方接收到付款请求后，生成待付款单据并存储于数据库中，接着，受理方受理该付款请求并完成扣款业务，并将扣款结果返回给发起方。

由于网络超时或者其他因素的影响，可能会发生付款请求没有返回明确结果的情况，发起方会重复发起付款申请。为了防止重复付款，发起方和受理方通常约定一个唯一的付款申请号(也称为幂等号)，同一个付款申请号只受理并付款一次。基于此，需要提供一种准确识别重复付款的方案。

技术实现要素：

为克服相关技术中存在的问题，本说明书提供了识别重复付款的方法、装置及服务设备。

根据本说明书实施例的第一方面，提供一种识别重复付款的方法，所述方法包括：

获取待付款单据，所述待付款单据在付款业务被发起后生成，且包含有付款业务信息；

基于付款业务信息的一致性，判断所述待付款单据与指定单据是否匹配；

输出判断结果，所述判断结果指示所述待付款单据是否属于重复付款。

可选的，所述指定单据满足如下一种或多种条件：

在预设时间范围内存储、与所述待付款单据的付款账户信息相同或与所述待付款单据的付款金额信息相同。

可选的，所述付款业务信息，包括如下一种或多种：

付款金额信息、付款账户信息、收款账户信息、付款账户的身份信息、收款账户的身份信息、支付方式信息、产品信息或付款原因信息。

可选的，所述判断所述待付款单据与指定单据是否匹配，基于相同付款业务信息的个数或优先级而确定。

可选的，所述判断所述待付款单据与指定单据是否匹配，包括：

若任一付款业务信息不同，则所述待付款单据与指定单据不匹配；

若所有付款业务信息相同，则所述待付款单据与指定单据匹配。

根据本说明书实施例的第二方面，提供一种识别重复付款的装置，所述装置包括：

获取模块，用于：获取待付款单据，所述待付款单据在付款业务被发起后生成，且包含有付款业务信息；

判断模块，用于：基于付款业务信息的一致性，判断所述待付款单据与指定单据是否匹配；

输出模块，用于：输出判断结果，所述判断结果指示所述待付款单据是否属于重复付款。

可选的，所述指定单据满足如下一种或多种条件：

在预设时间范围内存储、与所述待付款单据的付款账户信息相同或与所述待付款单据的付款金额信息相同。

可选的，所述付款业务信息，包括如下一种或多种：

付款金额信息、付款账户信息、收款账户信息、付款账户的身份信息、收款账户的身份信息、支付方式信息、产品信息或付款原因信息。

可选的，所述判断所述待付款单据与指定单据是否匹配，基于相同付款业务信息的个数或优先级而确定。

可选的，所述判断所述待付款单据与指定单据是否匹配，包括：

若任一付款业务信息不同，则所述待付款单据与指定单据不匹配；

若所有付款业务信息相同，则所述待付款单据与指定单据匹配。

根据本说明书实施例的第三方面，提供一种识别重复付款的设备，包括：

处理器；

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

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

获取待付款单据，所述待付款单据在付款业务被发起后生成，且包含有付款业务信息；

基于付款业务信息的一致性，判断所述待付款单据与指定单据是否匹配；

输出判断结果，所述判断结果指示所述待付款单据是否属于重复付款。

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

本说明书实施例提供了一种识别重复付款的方法、装置及设备，考虑到两笔不同的付款请求所拥有的业务属性完全一致的可能性非常低，本实施例方案可以对比待付款单据中的付款业务信息与指定单据的付款业务信息是否一致，进而判断待付款单据是否重复付款。实际应用中，发起方系统若发生故障，有可能针对同一笔付款发起多次付款请求，并在每次付款请求时分配不同的付款申请号，此种情况下，本实施例采用付款业务信息的比对，可以准确地发现重复付款现象。

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

附图说明

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

图1是本说明书根据一示例性实施例示出的一种付款处理场景示意图。

图2a是本说明书根据一示例性实施例示出的一种识别重复付款的方法的流程图。

图2b是本说明书根据一示例性实施例示出的另一种识别重复付款的方法的流程图。

图3是本说明书识别重复付款的装置所在设备的一种硬件结构图。

图4是本说明书根据一示例性实施例示出的一种识别重复付款的装置的框图。

具体实施方式

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

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

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

如图1所示，是本说明书根据一示例性实施例示出的一种付款处理场景示意图。图1中包括付款发起方和付款受理方，作为例子，付款受理方可以是第三方支付服务方，该第三方支付服务方为用户提供支付服务，用户可以在个人设备中安装第三方支付服务方提供的支付app(application，应用程序)，利用该app登录服务器获得服务，也可以利用个人设备登录第三方支付服务方提供的服务页面。在其他例子中，付款发起方可以面向机构或商户结算相关的财务系统，或者资金清算系统(面向机构做资金结算)等，付款受理方可以是具有付款能力的业务系统等等。

以商户结算场景为例，商户可以采用个人设备登录业务系统，作为发起方侧，业务系统可以在用户触发下，业务系统生成待付款单据存储于数据库中，该待付款单据包含有多种信息，例如付款发起方与付款受理方约定的唯一付款申请号(也称为幂等号)、付款请求发起时间、付款时间、订单编号、付款金额、付款账户、收款账户、付款账户的身份信息、收款账户的身份信息、支付方式信息、产品信息或付款原因信息等等。发起方的业务系统会基于该待付款单据生成付款请求，付款申请中可以携带有如上的部分或全部信息。

付款受理方接收到该付款请求后，会将付款请求转化为一条待付款单据，并保存至数据库中。可选的，待付款单据除了可能包含付款请求中所携带的部分或全部信息之外，也可能包含有付款受理方写入的其他信息，例如付款请求的接收时间、付款完成时间、单据状态等等。作为例子，单据状态可以包括待付款、已付款、已入账等，付款受理方根据付款业务等业务流程的执行情况，可以相应地修改该条单据的状态。付款受理方受理付款请求后，启动扣款流程，之后将扣款结果返回给付款受理方。

由于网络超时或者其他因素的影响，可能会发生付款请求没有返回明确结果的情况，发起方会重复发起付款申请。为了防止重复付款，付款发起方可以利用幂等号识别本次付款请求是否属于重复付款。然而，实际使用中，有可能付款发起方出现系统故障，付款发起方对一笔付款发起了两次或者多次付款请求，并且对每次付款请求分配了不同的幂等号，此时将无法识别到此类问题，最终造成重复付款。

本说明书实施例提供了一种识别重复付款的方案，考虑到两笔不同的付款请求所拥有的业务属性完全一致的可能性非常低，本实施例方案可以对比待付款单据中的付款业务信息与指定单据的付款业务信息是否一致，进而判断待付款单据是否重复付款。实际应用中，发起方系统若发生故障，有可能针对同一笔付款发起多次付款请求，并在每次付款请求时分配不同的付款申请号，此种情况下，本实施例采用付款业务信息的比对，可以准确地发现重复付款现象。接下来对本说明书实施例进行详细说明。

如图2a所示，图2a是本说明书根据一示例性实施例示出的一种识别重复付款的方法的流程图，包括以下步骤：

在步骤202中，获取待付款单据，所述待付款单据在付款业务被发起后生成，且包含有付款业务信息。

在步骤204中，基于付款业务信息的一致性，判断所述待付款单据与指定单据是否匹配。

在步骤206中，输出判断结果，所述判断结果指示所述待付款单据是否属于重复付款。

本说明书实施例的方法可以应用于付款发起方，也可应用于付款受理方，作为例子，付款发起方可以在生成待付款单据后应用本实施例的方法进行重复付款的识别；在另一些例子中，付款受理方可以接收付款发起方的付款请求，根据付款请求中携带的信息和付款业务需要生成待付款单据后，应用本实施例的方法进行重复付款的识别。该条单据可以包含有多种信息，例如付款发起方与付款受理方约定的唯一付款申请号(也称为幂等号)、付款金额信息、付款账户信息、收款账户信息、付款账户的身份信息、收款账户的身份信息、支付方式信息、产品信息或付款原因信息等等。

本实施例方案基于付款业务信息进行重复付款的识别，付款业务信息包括付款金额信息、付款账户信息、收款账户信息、付款账户的身份信息、收款账户的身份信息、支付方式信息、产品信息或付款原因信息等等。本实施例方案中，考虑到两笔不同的付款单所拥有的付款业务属性完全一致的可能性非常低，假如发现两笔付款单之间的付款业务信息完全一致，那么有足够大的概率认为这是重复付款。

因此，本实施例方案的构思是：不对比付款单号、幂等号、付款状态等这类没有业务含义、或者是具有唯一性的属性信息。原因是，如果要识别重复付款，采用幂等号、付款单号这类本身就具有唯一性的信息是无法做出精准识别，因为假如由于系统问题发生了重复付款的现象，付款发起方发起了多次付款请求，那这些单据的幂等号等信息肯定是不一样的，因为它们是单据的唯一属性，通过判断这些属性不一致是无法识别出重复付款的。因此，本实施例采用付款业务信息进行识别，付款业务信息可以是指一类描述付款业务特性的信息，此类信息具有业务含义、具有非唯一性。通过本实施例识别和判断重复付款，假如发现两条单据之间的付款业务信息完全一致，那么有足够大的概率认为这是重复付款。通过这种方法识别和判断重复付款，无关于技术因素的影响，可以有效地解决由于技术缺陷导致的重复付款问题。

作为例子，针对某些付款业务信息进行说明。其中，付款账户的身份信息可以是付款用户的名称、手机号码或联系地址等等。收款账户的身份信息可以是收款用户的名称、收款银行卡号、手机号码或联系地址等等。支付方式信息表征付款用户所采用的支付方式，可以包括信用卡(例如卡号、开户银行名称等)、储蓄卡(例如卡号、开户银行名称等)等。在一些例子中，用户可能购买某个产品，则付款请求中可以携带有产品信息，以表征本次付款所涉及的产品。在其他例子中，待付款单据中还可能携带有付款原因信息，该付款原因信息用于描述本次付款的缘由，例如信用卡还款、水电费缴纳、挂号费等等。待付款单据中包含的此类属性信息具有付款业务含义、且具有非唯一性，因此采用付款业务信息作为识别基础。

上述付款业务信息描述了待付款单据所具有的业务属性，考虑到两笔不同的付款单所拥有的付款业务属性完全一致的可能性非常低，因此可以利用付款业务信息来识别重复付款。假设付款发起方出现系统故障，针对同一笔付款发起了多次付款请求，既然是同一笔付款，付款请求中所携带的付款业务信息应该是一致的，都是同一个付款账户、同一个收款账户、同样的付款金额或同样的付款原因等等。

基于此，在一些例子中，可以是付款发起方在付款请求发送给受理方之前，先识别该条待付款单据是否属于重复付款；在其他例子中，也可以是付款受理方针对待付款单据，在启动扣款业务前，可以先识别该条待付款单据是否属于重复付款。根据本实施例方案，可以基于付款业务信息的一致性，判断所述待付款单据与指定单据是否匹配。因此要判断当前付款请求的待付款单据是否属于重复付款，需要从数据库中已有单据中，查找是否有与待付款单据匹配的单据。在一些例子中，该指定单据可以是数据库中已存储的任一单据，可以将待付款单据的付款业务信息与每一条已存储单据的付款业务信息进行对比。在另一些例子中，为了提高判断效率，可以先排除部分不可能与待付款单据匹配的单据，再将剩余单据作为该指定单据进行后续的判断。

作为示例，本实施例中，可以在所述判断所述待付款单据与指定单据是否匹配之前，从数据库中查找出部分单据作为该指定单据，例如，所述指定单据满足如下一种或多种条件：

在预设时间范围内存储、与所述待付款单据的付款账户信息相同或与所述待付款单据的付款金额信息相同。

其中，该预设时间范围从时间上限制了可能与待付款单据匹配的单据数量，该预设时间范围具体可以根据业务场景的特点来设置，例如，在一些业务场景下，发生重复付款的时间跨度可以是几分钟，则预设时间范围可以设置为距离待付款单据存储时间的几分钟内，在其他例子中，还可以是几天或者几十天等等，实际应用中可以灵活配置。

对于“与所述待付款单据具有相同付款账户”的条件，该条件从付款账户上限制了可能与待付款单据匹配的单据数量，该条件的考虑因素是，同一笔付款申请是由同一用户发起的，因此两个单据具有相同的付款账户信息。

对于“与所述待付款单据具有相同付款金额”的条件，该条件从付款金额限制了可能与待付款单据匹配的单据数量，该条件的考虑因素是，同一笔付款请求具有相同的付款金额信息。

基于上述任一条件或者任意组合，可以从数据库中捞取出指定单据，继而进行后续的判断流程，具体可以是，对比待付款单据的每一项付款业务信息，与指定单据的每一项付款业务信息是否相同。

通过对比，可以判断所述待付款单据与指定单据是否匹配，实际应用中，是否匹配的策略可以根据需要灵活配置。在一些例子中，可以基于相同付款业务信息的个数或优先级而确定，例如，可以是：只要其中n个付款业务信息相同，则认为待付款单据与指定单据匹配，n为设定数值；还可以是其中m个优先级较高的付款业务信息相同，认为待付款单据与指定单据匹配等等。在另一些例子，还可以设置较为严格的策略，以防止错误判断，配置的策略可以是：若任一付款业务信息不同，则所述待付款单据与指定单据不匹配；若所有付款业务信息相同，则所述待付款单据与指定单据匹配。实际应用中，本领域技术人员可以结合具体业务场景而灵活配置，本实施例对此不做限定。

接下来再通过一实施例进行说明，如图2b所示，是本说明书根据一示例性实施例示出的一种识别重复付款方法的流程图，包括如下步骤：

step1：将待付款单据作为输入(以下称为入参付款单)。

step2：在本地数据库中查询与待付款单据的付款金额一致的所有付款单。其中，由于入参付款单也是存储于数据库，查询结果中会包含该入参付款单。

step3：从查询结果中取出一个付款单。

step4：检查当前是否已经遍历完所有的查询结果。如果已经遍历完就结束流程，否则进入step5。

step5：判断当前付款单和入参付款单的幂等号是否一致。由于幂等号是每个付款单独且唯一的标识，所以如果当前付款单和入参付款单的幂等号一致，说明当前当前付款单就是入参付款单，这种情况就结束后续的步骤，返回到step3；如果当前付款单和入参付款单的幂等号不一致，说明当前付款单和入参付款单不是同一付款单，进入下一个步骤。

step6：比较付款单和入参付款单是否匹配。比较的方法是：只对比付款单中的付款业务信息，不对比付款单号、幂等号、付款状态等这类没有业务含义、或者具有唯一性的属性。如果判断两个付款单的付款业务信息不是全部一致，说明两个付款单不属于重复付款，返回step3步骤继续比较下一个付款单。

step7、step8：假如两个付款单的付款业务信息全部一致，则判定两个付款单有可能是重复付款，输出判断结果，结束流程。

与前述重复付款识别的方法的实施例相对应，本说明书还提供了重复付款识别的装置及其所应用的设备的实施例。

本说明书识别重复付款的装置的实施例可以应用在设备上，例如服务器等。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在识别重复付款的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图3所示，为本说明书识别重复付款的装置所在设备的一种硬件结构图，除了图3所示的处理器310、内存330、网络接口320、以及非易失性存储器340之外，实施例中装置331所在的服务器等设备，通常根据该服务设备的实际功能，还可以包括其他硬件，对此不再赘述。

如图4所示，图4是本说明书根据一示例性实施例示出的一种识别重复付款的装置的框图，所述装置包括：

获取模块41，用于：获取待付款单据，所述待付款单据在付款业务被发起后生成，且包含有付款业务信息；

判断模块42，用于：基于付款业务信息的一致性，判断所述待付款单据与指定单据是否匹配；

输出模块43，用于：输出判断结果，所述判断结果指示所述待付款单据是否属于重复付款。

可选的，所述指定单据满足如下一种或多种条件：

在预设时间范围内存储、与所述待付款单据的付款账户信息相同或与所述待付款单据的付款金额信息相同。

可选的，所述付款业务信息，包括如下一种或多种：

付款金额信息、付款账户信息、收款账户信息、付款账户的身份信息、收款账户的身份信息、支付方式信息、产品信息或付款原因信息。

可选的，所述判断所述待付款单据与指定单据是否匹配，基于相同付款业务信息的个数或优先级而确定。

可选的，所述判断所述待付款单据与指定单据是否匹配，包括：

若任一付款业务信息不同，则所述待付款单据与指定单据不匹配；

若所有付款业务信息相同，则所述待付款单据与指定单据匹配。

根据本说明书实施例的第三方面，提供一种识别重复付款的设备，包括：

处理器；

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

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

获取待付款单据，所述待付款单据在付款业务被发起后生成，且包含有付款业务信息；

基于付款业务信息的一致性，判断所述待付款单据与指定单据是否匹配；

输出判断结果，所述判断结果指示所述待付款单据是否属于重复付款。

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

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

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

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

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

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