本说明书实施例涉及互联网技术领域，尤其涉及付款申请处理方法、装置及设备。
背景技术
通常情况下，付款业务的发起过程包括：付款发起方发起付款申请，付款受理方接收付款申请后，受理该付款申请并完成扣款业务，并将扣款结果返回给付款发起方。
实际使用中，有可能由于网络超时或者其他因素的影响，可能会发生付款请求没有返回明确结果的情况，付款发起方可能会重复发起付款申请。面对可能发生的重复付款申请，如何处理成为亟待解决的技术问题。
技术实现要素：
为克服相关技术中存在的问题，本说明书提供了付款申请处理方法、装置及设备。
根据本说明书实施例的第一方面，提供一种付款申请处理装置，所述装置应用于业务系统，包括：策略模块、识别模块和判定模块；
所述策略模块，用于：确定生效的开关策略，并发送给所述识别模块；以及，确定生效的处理策略，并发送给所述控制模块；
所述识别模块，用于：根据所述开关策略的指示，确定是否触发识别流程；其中，所述识别流程包括：识别付款申请是否属于重复付款，并将识别结果发送给所述控制模块；
所述判定模块，用于：接收对所述付款申请的识别结果，结合所述处理策略的指示，判定是否拒绝所述付款申请。
可选的，所述处理策略包括如下任一：
以所述识别结果为判定依据的处理策略；
以黑名单和/或白名单优先，结合所述识别结果为判定依据的处理策略；其中，所述黑名单表征需要拒绝的付款申请，所述白名单表征需要受理的付款申请。
可选的，所述白名单记录有：被误判为重复付款的付款申请。
可选的，所述黑名单记录有：具有风险的付款申请。
可选的，所述识别流程，具体包括：
获取对应付款申请的待付款单据，所述待付款单据包含有付款业务信息；
基于付款业务信息的一致性，识别所述待付款单据与指定单据是否匹配，获得指示所述付款申请是否属于重复付款的识别结果。
可选的，所述指定单据满足如下一种或多种条件：
在预设时间范围内存储、与所述待付款单据的付款账户信息相同或与所述待付款单据的付款金额信息相同。
可选的，所述付款业务信息，包括如下一种或多种：
付款金额信息、付款账户信息、收款账户信息、付款账户的身份信息、收款账户的身份信息、支付方式信息、产品信息或付款原因信息。
可选的，若任一付款业务信息不同，则所述待付款单据与指定单据不匹配；若所有付款业务信息相同，则所述待付款单据与指定单据匹配。
根据本说明书实施例的第二方面，提供一种付款申请处理方法，包括：
确定生效的开关策略，以及确定生效的处理策略；
根据所述开关策略的指示，确定是否触发识别流程；其中，所述识别流程包括：识别付款申请是否属于重复付款，并将识别结果发送给所述控制模块；
接收对所述付款申请的识别结果，结合所述处理策略的指示，判定是否拒绝所述付款申请。
可选的，所述处理策略包括如下任一：
以所述识别结果为判定依据的处理策略；
以黑名单和/或白名单优先，结合所述识别结果为判定依据的处理策略；其中，所述黑名单表征需要拒绝的付款申请，所述白名单表征需要受理的付款申请。
可选的，所述白名单记录有：被误判为重复付款的付款申请。
可选的，所述黑名单记录有：具有风险的付款申请。
可选的，所述识别流程，具体包括：
获取对应所述付款申请的待付款单据，所述待付款单据包含有付款业务信息；
基于付款业务信息的一致性，识别所述待付款单据与指定单据是否匹配，获得指示所述付款申请是否属于重复付款的识别结果。
可选的，所述指定单据满足如下一种或多种条件：
在预设时间范围内存储、与所述待付款单据的付款账户信息相同或与所述待付款单据的付款金额信息相同。
可选的，所述付款业务信息，包括如下一种或多种：
付款金额信息、付款账户信息、收款账户信息、付款账户的身份信息、收款账户的身份信息、支付方式信息、产品信息或付款原因信息。
可选的，若任一付款业务信息不同，则所述待付款单据与指定单据不匹配；若所有付款业务信息相同，则所述待付款单据与指定单据匹配。
根据本说明书实施例的第三方面，提供一种付款申请处理设备，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器被配置为：
确定生效的开关策略，以及确定生效的处理策略；
根据所述开关策略的指示，确定是否触发识别流程；其中，所述识别流程包括：识别付款申请是否属于重复付款，并将识别结果发送给所述控制模块；
接收对所述付款申请的识别结果，结合所述处理策略的指示，判定是否拒绝所述付款申请。
本说明书的实施例提供的技术方案可以包括以下有益效果：
本说明书实施例提供了一种付款申请处理装置，该装置可以引入于付款业务系统中，该装置可以根据业务需要配置开关策略，以决定是否启动对付款请求的识别，例如，在装置故障或异常等情况下，可以通过开关策略的配置，令识别模块中的识别流程关闭。
在识别流程启动的情况下，识别流程可以对在线实时发起的付款申请进行识别，以确定该付款申请是否属于重复付款；在该识别结果的基础上，可以根据业务需要灵活配置处理策略，例如可以根据需要直接拒绝属于重复付款的付款申请，也可以结合其他因素判定是否拒绝付款申请。
综上，利用本说明书的付款申请处理装置能够及时发现重复付款、能够解决付款业务中对重复付款的处理需求。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本说明书的实施例，并与说明书一起用于解释本说明书的原理。
图1是本说明书根据一示例性实施例示出的一种付款处理场景示意图。
图2是本说明书根据一示例性实施例示出的一种付款申请处理装置的框图。
图3a是本说明书根据一示例性实施例示出的一种付款申请处理示意图。
图3b是本说明书根据一示例性实施例示出的一种策略模块获取策略的示意图。
图3c是本说明书根据一示例性实施例示出的一种付款申请处理装置的运行示意图。
图4是付款申请处理装置所在设备的一种硬件结构图。
图5是本说明书根据一示例性实施例示出的一种付款申请处理方法的流程图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。
在本说明书使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
如图1所示，是本说明书根据一示例性实施例示出的一种付款处理场景示意图。图1中包括付款发起方(简称发起方)和付款受理方(简称受理方)，发起方配置有业务系统，该业务系统可以发起付款申请。受理方也配置有业务系统，该业务系统能够接收付款申请，并受理该付款申请并完成扣款业务，将扣款结果返回给发起方的业务系统。
可选的，发起方的业务系统，以及受理方的业务系统分别部署有数据库，以存储和管理业务数据。在需要付款时，发起方的业务系统生成待付款单据存储于数据库中，该待付款单据包含有多种信息，例如付款发起方与付款受理方约定的唯一付款申请号(也称为幂等号)、付款请求发起时间、付款时间、订单编号、付款金额、付款账户、收款账户、付款账户的身份信息、收款账户的身份信息、支付方式信息、产品信息或付款原因信息等等。发起方的业务系统会基于该待付款单据生成付款申请，付款申请中可以携带有如上的部分或全部信息。
发起方的业务系统可以将该付款申请发送给受理方的业务系统。受理方的业务系统接收到该付款申请后，会将付款请求转化为一条待支付单据，并保存至数据库中。可选的，待支付单据除了可能包含付款申请中所携带的部分或全部信息之外，也可能包含有受理方写入的其他信息，例如付款请求的接收时间、付款完成时间、单据状态等等。作为例子，单据状态可以包括待付款、已付款、已入账等，受理方根据付款业务等业务流程的执行情况，可以相应地修改该条单据的状态。付款受理方受理付款申请后，会启动扣款流程，之后将扣款结果返回给受理方。
由于网络超时或者其他因素的影响，可能会发生付款请求没有返回明确结果的情况，发起方会重复发起付款申请。基于此，本说明书实施例提供了一种付款申请处理装置，如图2所示，是本说明书根据一示例性实施例示出的一种付款申请处理装置的框图，包括：策略模块21、识别模块22和判定模块23。
所述策略模块21，用于：确定生效的开关策略，并发送给所述识别模块；以及，确定生效的处理策略，并发送给所述控制模块。
所述识别模块22，用于：根据所述开关策略的指示，确定是否触发识别流程；其中，所述识别流程包括：识别付款申请是否属于重复付款，并将识别结果发送给所述控制模块。
所述判定模块23，用于：接收对所述付款申请的识别结果，结合所述处理策略的指示，判定是否拒绝所述付款申请。
实际应用中，本说明书实施例的付款申请处理装置可应用于发起方的业务系统，也可应用于受理方的业务系统。作为例子，若付款申请处理装置应用于发起方的业务系统，在付款申请发起后、至发送给受理方的业务系统之前，由付款申请处理装置判定是否拒绝该付款申请。若付款申请处理装置应用于受理方的业务系统，在接收到付款申请后、至受理该付款申请之前，由付款申请处理装置判定是否拒绝该付款申请。可以看出，通过在已有业务系统中引入付款申请处理装置，该装置可以对已有的付款申请等功能模块进行控制，但无需对业务系统的已有功能模块进行改造，对已有业务系统的影响较小。
本实施例中，付款申请处理装置包括有三个模块，策略模块负责策略同步、识别模块负责识别付款申请是否属于重复付款，判定模块负责决定是否拒绝付款申请。其中，识别模块负责识别重复付款，考虑到实际应用中可能出现一些预期意外的情况，例如把正常付款识别为重复付款从而拦截了正常业务，或者其他功能异常，比如装置运行过程中出现了不可控的软件异常，影响到了正常业务，需要实现隔离功能，以实现快速的隔离故障、恢复正常业务。因此，本实施例中的策略模块能够确定生效的开关策略，开关策略可以理解为一个功能开关，当开关开启，指示识别模块触发识别流程生效；当开关关闭时，指示识别模块关闭识别流程。
另一方面，识别模块能识别出属于重复付款的付款申请，但对于该付款申请是否做出拒绝决定，实际应用中可以灵活配置多种处理策略，以根据业务需要灵活做出决定。
可选的，策略模块的开关策略和处理策略可以由技术人员配置，作为例子，可以实现一交互界面，以供技术人员对开关策略和处理策略进行配置或更新。策略模块确定生效的开关策略，并发送给所述识别模块；在一些例子中，开关策略可以包括开启策略或关闭策略，关闭策略指示识别模块不需要触发识别流程，开启策略指示识别模块需要触发识别流程。在不需要触发识别流程的情况下，识别模块不需要对付款申请进行识别，付款申请按照原有业务流程进行处理。在需要触发识别流程的情况下，识别模块可以识别付款申请是否属于重复付款，并将识别结果发送给所述判定模块。
策略模块还可用于确定生效的处理策略，并发送给所述判定模块。判定模块接收对所述付款申请的识别结果，结合所述处理策略的指示，判定是否拒绝所述付款申请。实际应用中，本领域技术人员可以根据需要灵活配置处理策略。
作为例子，处理策略包括如下任一：
以所述识别结果为判定依据的处理策略；也即是，识别结果为：付款申请属于重复付款，则拒绝该付款申请；识别结果为付款申请不属于重复付款，则不需要拒绝。
以黑名单和/或白名单优先，结合所述识别结果为判定依据的处理策略；其中，所述黑名单表征需要拒绝的付款申请，所述白名单表征需要受理的付款申请。
其中，白名单可以理解为一种“绿色通道”策略。白名单优先，可以用来恢复被误拦截的付款申请。例如，如果一个正常付款申请被识别模块误判为重复付款，并且被拒绝，但是之后经过人工检查等方式确定该付款申请不是重复付款，则需要重新受理该付款申请。但是因为该付款申请之前已经被误判了，再次发起仍然会发生被拒绝(因为识别流程的规则没有变化)的情况，采用本实施例的方案，该付款申请可以记录于白名单中，即使该付款申请被识别模块识别为重复付款，但由于采用了白名单优先、结合识别结果为判定依据的处理策略，该付款申请不会被拒绝，能够进行正常的付款流程。
黑名单可以理解为一种“禁止”策略，也就是说，不管识别结果如何，只要在黑名单中的付款申请都会被直接拒绝。黑名单优先的处理策略可以应对某些紧急情况，例如，当付款申请已经发起，即使识别模块识别为不属于重复付款，此种情况下，该付款申请可能随时可以正常付款，但来自风控系统的指令，风控系统指示该付款申请可能涉嫌作弊等风险，该具有风险的付款申请可以记录于黑名单中，从而由判定模块判定为拒绝。
实际应用中，处理策略还可以是：以黑名单和白名单优先、结合识别结果为判定依据的策略。此种策略可以应用于小规模的业务验证场景，例如，假设新开发并上线了一种付款业务，但还未经过大规模的验证，因此该新开发业务暂未全部开放使用，需要在线验证少量业务进行测试。此时，技术人员可以设置少量的付款申请记录于白名单中，其他所有付款申请为黑名单，这样就只有在白名单内的付款申请才可以被新上线的付款业务受理付款，而其他的业务不会被付款。
实际使用中，还有可能出现一个付款申请同时存在于黑名单和白名单中，作为例子，还可以根据需要设置白名单的优先级高于黑名单，因此该付款申请不会被拒绝。当然，也可以根据需要设置黑名单的优先级高于白名单，则该付款申请会被拒绝。
由此可知，本说明书实施例通过引入付款申请处理装置于业务系统中，可以在实时业务流程中可以识别付款申请是否属于重复付款，并且还可以决定是否拒绝付款申请，从而能够拦截付款申请或终止付款，进而有效地控制风险。
另一方面，通过策略模块实现了在线实时调整开关策略和处理策略，例如，可以指导判定模块执行正常的重复付款的拒绝处理，也可以指导判定模块结合白名单或/和黑名单等策略，使得被误判的付款申请在重新发起时，能够得到正常处理。
本实施例中，识别模块中配置有识别流程，以用于识别付款申请是否属于重复付款，实际使用中，有可能发起方的业务系统出现系统故障，发起方的业务系统对一笔付款发起了两次或者多次付款申请，并且对每次付款申请分配了不同的幂等号，此时可能无法准确快速识别到此类问题，最终造成重复付款。基于此，本实施例还提供一种识别流程，识别付款申请是否属于重复付款，包括：
获取对应所述付款申请的待付款单据，所述待付款单据包含有付款业务信息；
基于付款业务信息的一致性，识别所述待付款单据与指定单据是否匹配，获得指示所述付款申请是否属于重复付款的识别结果。
本实施例中，考虑到两笔不同的付款申请所拥有的业务属性完全一致的可能性非常低，本实施例方案可以对比待付款单据中的付款业务信息与指定单据的付款业务信息是否一致，进而判断待付款单据是否重复付款。实际应用中，发起方系统若发生故障，有可能针对同一笔付款发起多次付款请求，并在每次付款请求时分配不同的付款申请号，此种情况下，本实施例采用付款业务信息的比对，可以准确地识别重复付款。
具体的，待付款单据包含有多种属性信息，例如付款发起方与付款受理方约定的唯一付款申请号(也称为幂等号)、付款金额信息、付款账户信息、收款账户信息、付款账户的身份信息、收款账户的身份信息、支付方式信息、产品信息或付款原因信息等等。
本实施例方案基于付款业务信息进行重复付款的识别，付款业务信息包括付款金额信息、付款账户信息、收款账户信息、付款账户的身份信息、收款账户的身份信息、支付方式信息、产品信息或付款原因信息等等。本实施例方案中，考虑到两笔不同的付款单所拥有的付款业务属性完全一致的可能性非常低，假如发现两笔付款单之间的付款业务信息完全一致，那么有足够大的概率认为这是重复付款。
因此，本实施例方案的构思是：不对比付款单号、幂等号、付款状态等这类没有业务含义、或者是具有唯一性的属性信息。原因是，如果要识别重复付款，采用幂等号、付款单号这类本身就具有唯一性的属性信息是无法做出精准识别，因为假如由于系统问题发生了重复付款的现象，付款发起方发起了多次付款请求，那这些单据的幂等号等属性信息肯定是不一样的，因为它们是单据的唯一属性，通过判断这些属性不一致是无法识别出重复付款的。因此，本实施例采用付款业务信息进行识别，因为此类信息具有业务含义、具有非唯一性。通过本实施例识别和判断重复付款，假如发现两条单据之间的付款业务信息完全一致，那么有足够大的概率认为这是重复付款。通过这种方法识别和判断重复付款，无关于技术因素的影响，可以有效地解决由于技术缺陷导致的重复付款问题。
作为例子，针对某些付款业务信息进行说明。其中，付款账户的身份信息可以是付款用户的名称、手机号码或联系地址等等。收款账户的身份信息可以是收款用户的名称、收款银行卡号、手机号码或联系地址等等。支付方式信息表征付款用户所采用的支付方式，可以包括信用卡(例如卡号、开户银行名称等)、储蓄卡(例如卡号、开户银行名称等)等。在一些例子中，用户可能购买某个产品，则付款请求中可以携带有产品信息，以表征本次付款所涉及的产品。在其他例子中，待付款单据中还可能包含有付款原因信息，该付款原因信息用于描述本次付款的缘由，例如信用卡还款、水电费缴纳、挂号费等等。待付款单据中包含的此类属性信息具有付款业务含义、且具有非唯一性，因此采用付款业务信息作为识别基础。
上述付款业务信息描述了待付款单据所具有的业务属性，考虑到两笔不同的付款单所拥有的付款业务属性完全一致的可能性非常低，因此可以利用付款业务信息来识别重复付款。假设付款发起方出现系统故障，针对同一笔付款发起了多次付款申请，既然是同一笔付款，对应付款申请的待付款单据中所包含的付款业务信息应该是一致的，都是同一个付款账户、同一个收款账户、同样的付款金额或同样的付款原因等等。
基于此，可以基于付款业务信息的一致性，判断所述待付款单据与指定单据是否匹配。因此要判断当前付款请求的待付款单据是否属于重复付款，需要从数据库中已有单据中，查找是否有与待付款单据匹配的单据。在一些例子中，该指定单据可以是数据库中已存储的任一单据，可以将待付款单据的付款业务信息与每一条已存储单据的付款业务信息进行对比。在另一些例子中，为了提高判断效率，可以先排除部分不可能与待付款单据匹配的单据，再将剩余单据作为该指定单据进行后续的判断。
作为示例，本实施例中，可以在所述判断所述待付款单据与指定单据是否匹配之前，从数据库中查找出部分单据作为该指定单据，例如，所述指定单据满足如下一种或多种条件：
在预设时间范围内存储、与所述待付款单据的付款账户信息相同或与所述待付款单据的付款金额信息相同。
其中，该预设时间范围从时间上限制了可能与待付款单据匹配的单据数量，该预设时间范围具体可以根据业务场景的特点来设置，例如，在一些业务场景下，发生重复付款的时间跨度可以是几分钟，则预设时间范围可以设置为距离待付款单据存储时间的几分钟内，在其他例子中，还可以是几天或者几十天等等，实际应用中可以灵活配置。
对于“与所述待付款单据具有相同付款账户”的条件，该条件从付款账户上限制了可能与待付款单据匹配的单据数量，该条件的考虑因素是，同一笔付款申请是由同一用户发起的，因此两个单据具有相同的付款账户信息。
对于“与所述待付款单据具有相同付款金额”的条件，该条件从付款金额限制了可能与待付款单据匹配的单据数量，该条件的考虑因素是，同一笔付款申请具有相同的付款金额信息。
基于上述任一条件或者任意组合，可以从数据库中捞取出指定单据，继而进行后续的判断流程，具体可以是，对比待付款单据的每一项付款业务信息，与指定单据的每一项付款业务信息是否相同。
通过对比，付款受理方可以判断所述待付款单据与指定单据是否匹配，实际应用中，是否匹配的策略可以根据需要灵活配置。在一些例子中，可以基于相同付款业务信息的个数或优先级而确定，例如，可以是：只要其中n个付款业务信息相同，则认为待付款单据与指定单据匹配，n为设定数值；还可以是其中m个优先级较高的付款业务信息相同，认为待付款单据与指定单据匹配等等。在另一些例子，还可以设置较为严格的策略，以防止错误判断，配置的策略可以是：若任一付款业务信息不同，则所述待付款单据与指定单据不匹配；若所有付款业务信息相同，则所述待付款单据与指定单据匹配。实际应用中，本领域技术人员可以结合具体业务场景而灵活配置，本实施例对此不做限定。
接下来再通过一实施例进行详细说明。如图3a所示，是本说明书根据一示例性实施例示出的一种付款申请处理示意图，图3a中以该装置应用于付款发起方的业务系统为例进行说明，付款申请处理装置可以理解为一拦截器，发起方业务系统的付款申请在被受理方业务系统处理之前，先通过付款申请处理装置执行校验。
付款申请处理装置分为三个模块：“防重复付款策略模块(简称策略模块)”、“防重复付款识别模块(简称识别模块)”、“防重复付款判定模块(简称判定模块)”，分别负责：策略同步和选择、识别重复付款、根据策略和识别结果执行控制和处理。
可选的，图3a中还包括一“信息管控平台”，该平台用于给操作员同步策略给“策略模块”，让付款申请处理装置可以实时获取到最新的策略，策略的同步和更新由操作员管理。
如图3b所示，是本说明书根据一示例性实施例示出的一种策略模块获取策略的示意图，操作员可以通过“信息管控平台”推送“开关策略”和“处理策略”：
操作员通过信息管控平台执行策略推送操作，信息管控平台先将策略保存，然后将策略推送到策略模块，使策略生效，从而实现策略的实时更新。或者，策略模块也可以定时从信息管控平台获取最新保存的策略，实现策略的实时更新。
如图3c所示，是本说明书根据一示例性实施例示出的一种付款申请处理装置的运行示意图，识别模块可以触发识别流程，首先从策略模块获取“防重复付款的开关策略(简称开关策略)”：
如果开关策略的状态是“关闭”状态，则识别流程不会触发，跳过识别流程，因此付款申请直接发送给发起方的业务系统。
如果开关策略的状态是“开启”状态，则触发识别流程：
识别模块开始识别付款申请是否属于重复付款，具体的识别流程可参考前述实施例的识别流程说明，此处不再赘述。
识别模块将识别结果发送给判定模块，由判定模块进行处理。
判定模块从策略模块获取当前的防重复付款的处理策略(简称处理策略)，根据处理策略执行对应的措施。
本说明书实施例提供的处理策略可以有以下几种：
第一种、普通识别和拦截策略
识别模块识别待付款单据是否为重复付款，如果识别结果判定为“重复付款”，判定模块以识别结果为判定依据，拒绝该付款申请，该付款申请被拦截，不会发送给受理方的业务系统。如果识别结果判定为“非重复付款”，则待付款单据不会被拒绝，该付款申请通过付款申请处理装置的校验，会被发送给受理方的业务系统。
第二种、白名单优先策略
白名单策略包含一个白名单，白名单可以理解成一个列表，默认情况下可以为空，说明没有任何付款申请处于白名单内。如果白名单中记录一些付款申请的标识(可以采用对应待付款单据的单号作为唯一标识)，则这些付款申请以白名单优先的策略执行，不管该付款申请的识别结果如何，都会被受理。没有处于白名单的付款申请，则执行第一种策略。
第三种、黑名单优先策略
黑名单中则记录了需要拒绝的付款申请，这些付款申请以黑名单优先的策略执行，不管该付款申请的识别结果如何，都会被拒绝。没有处于黑名单的付款申请，则执行第一种策略。
第四种、黑名单和白名单优先策略
本策略中同时包括黑名单和白名单，当付款申请存在于白名单中时，执行对应的白名单优先策略；当付款申请存在于黑名单中时，执行对应的黑名单优先策略。当付款申请既存在于黑名单又存在于白名单中时，可以根据需要灵活配置，例如，可以是白名单优先于黑名单，即该付款申请执行白名单优先策略，忽略黑名单策略。既不在黑名单中也不在白名单中的付款申请，执行第一种策略。
本说明书实施例中，通过在业务系统引入付款申请处理装置，将防重复付款校验逻辑嵌入到业务流程中，因此，在实时在线业务流程中就可以执行防重复付款校验；通过识别模块，可以在识别重复付款风险后由判定模块进行实时拒绝处理，能够有效控制重复付款风险。通过引入策略模块，可以在线实时调整开关策略或者处理策略，通过不同的“处理策略”可以指定判定模块做出多种处理。例如，既可以指导判定模块执行正常的重复付款风险拦截策略，又可以指导控制模块执行白名单优先策略，使得被误判的付款申请再次发起后，可以正常通过校验从而恢复业务。不仅解决了可以在线实时业务中，是否执行防重复付款校验的问题，也解决了发现重复付款后如何处理和恢复问题。
本说明书付款申请处理装置的实施例可以应用在服务器等设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图4所示，为本说明书付款申请处理装置所在设备的一种硬件结构图，除了图4所示的处理器410、内存430、网络接口420、以及非易失性存储器440之外，实施例中装置431所在的设备，通常根据该设备的实际功能，还可以包括其他硬件，对此不再赘述。
以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
与前述付款申请处理装置的实施例相对应，本说明书还提供了付款申请处理方法及其所应用的设备的实施例。
如图5所示，图5是本说明书根据一示例性实施例示出的一种付款申请处理方法的流程图，包括：
在步骤502中，确定生效的开关策略，以及确定生效的处理策略；
在步骤504中，根据所述开关策略的指示，确定是否触发识别流程；其中，所述识别流程包括：识别付款申请是否属于重复付款，并将识别结果发送给所述控制模块；
在步骤506中，接收对所述付款申请的识别结果，结合所述处理策略的指示，判定是否拒绝所述付款申请
可选的，所述处理策略包括如下任一：
以所述识别结果为判定依据的处理策略；
以黑名单和/或白名单优先，结合所述识别结果为判定依据的处理策略；其中，所述黑名单表征需要拒绝的付款申请，所述白名单表征需要受理的付款申请。
可选的，所述白名单记录有：被误判为重复付款的付款申请。
可选的，所述黑名单记录有：具有风险的付款申请。
可选的，所述识别流程，具体包括：
获取对应所述付款申请的待付款单据，所述待付款单据包含有付款业务信息；
基于付款业务信息的一致性，识别所述待付款单据与指定单据是否匹配，获得指示所述付款申请是否属于重复付款的识别结果。
可选的，所述指定单据满足如下一种或多种条件：
在预设时间范围内存储、与所述待付款单据的付款账户信息相同或与所述待付款单据的付款金额信息相同。
可选的，所述付款业务信息，包括如下一种或多种：
付款金额信息、付款账户信息、收款账户信息、付款账户的身份信息、收款账户的身份信息、支付方式信息、产品信息或付款原因信息。
可选的，若任一付款业务信息不同，则所述待付款单据与指定单据不匹配；若所有付款业务信息相同，则所述待付款单据与指定单据匹配。
相应的，本说明书还提供一种付款申请处理设备，所述设备包括有处理器；用于存储处理器可执行指令的存储器；其中，所述处理器被配置为：
确定生效的开关策略，以及确定生效的处理策略；
根据所述开关策略的指示，确定是否触发识别流程；其中，所述识别流程包括：识别付款申请是否属于重复付款，并将识别结果发送给所述控制模块；
接收对所述付款申请的识别结果，结合所述处理策略的指示，判定是否拒绝所述付款申请。
上述付款申请处理方法中各个步骤，具体可详见上述付款申请处理装置中各个模块的功能和作用的实现过程，在此不再赘述。对于方法实施例而言，由于其基本对应于装置实施例，所以相关之处参见装置实施例的部分说明即可。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
本领域技术人员在考虑说明书及实践这里申请的发明后，将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未申请的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本说明书的真正范围和精神由下面的权利要求指出。
应当理解的是，本说明书并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。
以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。