支付渠道异常检查方法、装置、计算设备及存储介质与流程

1.本技术涉及电子商务技术领域，尤其涉及一种支付渠道异常检查方法、装置、计算设备及存储介质。


背景技术：

2.支付渠道指的是平台上支持用户支付的通道。常见的支付渠道有第三方支付渠道(比如支付宝、微信)、银联支付、银行直连等等，这些支付渠道能够帮助平台用户完成交易金额的支付，并且支持平台与银行之间进行资金流转、对账和清分。支付渠道的稳定性和安全性对于平台来讲至关重要，对于交易量庞大的平台来说更是如此，支付渠道短时间的崩溃很可能造成巨额的损失，还会使用户对平台的信任感下降。因此，平台公司一般都会选择对接多家支付渠道，渠道间可相互作为备份以保障交易顺利完成。
3.支付渠道的常规维护或者突发异常在所难免，这时候平台需要为支付渠道设置静默期，即在一段时间内临时屏蔽该渠道。然而，渠道维护后能否重新开启、渠道实际健康状况如何，需要平台的运营人员值守并观察一定的线上交易情况，人为分析判断。这种方法逻辑复杂且费时费力，还容易出现判断失误，如果渠道实际异常未解决却被开启，则很可能造成大批量交易失败。


技术实现要素：

4.本技术提供一种支付渠道异常检查方法、装置、计算设备及存储介质，支持从多种维度配置抽样条件，根据不同的抽样条件获取目标交易，能够满足不同业务场景下的各种支付渠道的检测需求。
5.第一方面，本技术提供了一种支付渠道异常检查方法，该方法包括：获取目标业务的目标支付渠道，其中，目标业务对应至少一种支付渠道，目标支付渠道是目标业务对应的支付渠道中的任意一种；基于目标业务和目标支付渠道确定抽样条件，根据抽样条件确定目标交易；获取目标支付渠道对目标交易的处理结果，根据处理结果确定目标业务下的目标支付渠道是否异常。
6.第二方面，本技术提供了一种支付渠道异常检查装置，该装置包括：获取模块，用于获取目标业务的目标支付渠道，其中，目标业务对应至少一种支付渠道，目标支付渠道是目标业务对应的支付渠道中的任意一种；处理模块，用于基于目标业务和目标支付渠道确定抽样条件，根据抽样条件确定目标交易；处理模块还用于，获取目标支付渠道对目标交易的处理结果，根据处理结果确定目标业务下的目标支付渠道是否异常。
7.第三方面，本技术提供了一种计算设备，包括处理器和存储器，所述处理器和存储器可通过总线相互连接，也可以集成在一起。该处理器执行存储器中存储的代码实现如第一方面所描述的方法。
8.第四方面，本技术提供了一种计算机可读存储介质，包括程序或指令，当上述程序或指令在计算机设备上运行时，可使上述计算机设备执行如第一方面所描述的方法。
9.可以看出，本技术实施例首先获取目标业务的目标支付渠道，然后根据目标业务以及目标支付渠道确定出相应的抽样条件，再根据抽样条件确定目标交易并将目标交易送至目标支付渠道进行处理，最后根据目标支付渠道对目标交易的处理结果，便可以确定目标业务下的目标支付渠道是否存在异常。该方法可以预先建立多种业务类型、多种支付渠道和多种不同的抽样条件之间的映射关系，每种业务类型下的每种支付渠道都有对应的一种抽样条件。应理解，基于该映射关系可以轻松实现定制化的支付渠道自动检查，运营人员可以对这些抽样条件进行合理配置，根据配置好的这些抽样条件便可以自动获取到目标交易，然后使用目标交易自动进行目标支付渠道的快速检查，以自动决定是否开启或者关闭该渠道，避免渠道异常造成大规模交易失败，同时减少了人力投入，降低了运营成本。
附图说明
10.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
11.图1是本技术实施例提供的一种平台对接支付渠道的示意图；
12.图2是本技术实施例提供的一种支付渠道异常检查方法的流程示意图；
13.图3是本技术实施例提供的一种支付渠道异常检查装置的结构示意图；
14.图4是本技术实施例提供的一种计算设备的结构示意图。
具体实施方式
15.下面介绍本技术实施例涉及的应用场景。
16.对于有资金转移需求的平台，比如电子商务类、消费金融类、知识付费类的平台等等，通过接入一种或多种支付渠道(简称渠道)，具有了支付能力，从而能够为平台公司的各种业务提供支持。图1是本技术提供的一种平台与支付渠道对接的示意图，如图1所示，平台可以和第三方支付公司对接，也可以直接和银行类组织直连，包括接入银行、银联或者网联。
17.其中，银行类组织具有直接的资金转移能力。而第三方支付公司是具有支付牌照的支付公司，比如支付宝和微信，其通过对接多家直接具有资金转移能力的组织，从而间接具有强大的资金转移能力。需要说明的是，图1中支付渠道的个数、名称、顺序等等只是示例性的，对本技术不构成限定。
18.平台接入多家支付渠道，有时候需要对支付渠道的健康状况进行检查。第一种方案是由平台的运营人员观察每种支付渠道在一段时间内的交易处理情况，人为判断各支付渠道是否存在异常。第二种方案，可以提供定制化的支付渠道异常检查方法，在不同业务场景下抽取符合条件的交易来检验渠道的健康状况。
19.下面的内容将详细介绍第二种方案。
20.请参见图2，图2是本技术实施例提供的一种支付渠道异常检查方法的流程示意图，该方法包括以下步骤：
21.s101.获取目标业务的目标支付渠道。
22.其中，目标业务对应至少一种支付渠道，也就是说，目标业务下可以有一种或者多种支付渠道，目标支付渠道是目标业务对应的支付渠道中的任意一种。本技术对支付渠道不做具体限定，可以是第三方支付公司的渠道(包括支付宝、微信)，也可以是银行类组织的渠道(比如银联、网联、中国工商银行直连、中国银行直连，等等)。
23.应理解，平台通过接入一种或多种支付渠道拥有了支付能力，进而可以为平台的各种业务提供支持。平台可以为用户提供一种或多种业务(下文中的业务均指的是具有支付需求的业务)，每种业务都对应至少一种支付渠道，不同业务所对应的支付渠道可以相同，也可以不同。上述目标业务可以是平台所提供的多种业务中的任意一种。本技术对平台的具体类型、名称等不做限定，可以是电子商务类、消费金融类或者知识付费类的平台，等等。本技术对业务类型也不做具体限定，平台所提供的业务的类型一般是由业务人员进行设计和划分的。
24.举例来说，某理财交易平台对接了支付宝、微信、银联和中国银行直连这四种支付渠道，这些支付渠道能够为该平台下的各种业务提供支持。对于该平台的其中一种业务——购买理财产品的业务(投资业务)，该业务对应的支付渠道为支付宝和银联，于是可以使用上述两种渠道来处理该业务下的支付交易。对于该平台的另一种业务——充值业务，该业务对应的支付渠道为微信和银联，于是可以使用上述两种渠道来处理该业务下的交易。
25.需要说明的是，步骤s101中“获取目标业务的目标支付渠道”，其实也就是确定目标业务下的某个待检测渠道，待检测的渠道(即目标支付渠道)可以是人为指定的或者自动确定的。
26.在一种可能的实施例中，目标支付渠道是用户输入的目标业务下的第一支付渠道，其中，第一支付渠道是目标业务下的任意一个支付渠道，也就是说，用户可以直接指定当前想要对哪个业务下的哪个支付渠道进行检测。比如，运营人员当前想要对业务1对应的多个渠道中的支付渠道1进行检查，于是输入业务1以及支付渠道1，支付渠道1便被确定为业务1的目标支付渠道，支付渠道1将按照后面的各种步骤进行异常检测。
27.在另一种可能的实施例中，目标支付渠道是目标业务下的处于静默期的第二支付渠道，其中，第二支付渠道是目标业务下的任意一个支付渠道。也就是说，目标支付渠道还可以是自动确定的，如果目标业务下的某个支付渠道处在静默期，就直接将其确定为目标业务的目标支付渠道。比如，在目标业务下的某个支付渠道的静默期结束之前(仍处于静默期)，可以自动将该支付渠道确定为目标业务的目标支付渠道。具体举例来说，业务1下的支付渠道2正处于静默期，即业务1下的支付渠道2正处于屏蔽状态，在静默期内暂时不能使用支付渠道2处理业务1下的交易。在支付渠道2的静默期即将结束时，可以自动将支付渠道2确定为业务1的目标支付渠道，以实现静默期结束前的渠道健康状况自动检测，进而可以控制是否结束该渠道的静默期或者延长静默期，避免渠道异常却误被开放的问题。
28.应理解，上面所说的静默期，指的是在一段时间内临时屏蔽支付渠道。比如，对于支付渠道方的日常维护，平台可以设置该支付渠道的静默期的开始时间和结束时间，覆盖该支付渠道的日常维护时间，处在静默期的支付渠道被临时屏蔽，暂时不能使用该渠道处理交易。再比如，支付渠道方一般会有日/月/单次限额，在支付渠道的交易超过单日金额限制或者单日成功支付笔数时，平台可以自动开启该渠道的静默期，次日自动关闭，渠道重新
恢复使用。当渠道出现突发异常的时候，平台也可以为渠道设置静默期。需要说明的是，本技术对静默期的设置方式不做具体限定。
29.s102.基于目标业务和目标支付渠道确定抽样条件，根据抽样条件确定目标交易。
30.上述目标交易可以是一笔或者多笔交易。需要说明的是，根据抽样条件确定的目标交易，指的是待处理的交易(不是历史交易)，这些交易实际还未完成，还需要送至某个支付渠道进行处理。比如用户发起的一笔支付交易，该交易实际还未完成(未完成支付扣款的动作)，需要送至某个支付渠道进行处理。
31.还需要说明的是，目标支付渠道应该具有处理目标交易的能力。例如，目标交易是要扣除某用户在银行a的银行卡上的一笔钱，目标支付渠道是支付宝渠道，那么，支付宝应该对接了银行a，获得了银行a提供的权限，具有间接的资金转移能力，才能够扣除用户在银行a的银行卡上的这笔钱。如果支付宝渠道未对接银行a，那么它不具备对该交易进行处理的能力。
32.在一种可能的实施例中，抽样条件中包括金额区间、交易类型、银行、支付类型(具体可以包括第一支付类型和第二支付类型)、银行标识代码中的一种或者多种维度的信息。也就是说，本技术实施例支持从多种维度对抽样条件进行设置，能够满足不同场景下的支付渠道检测需求。
33.上述各种维度信息分别介绍如下：
34.1)金额区间：包括金额上限和金额下限，可以用来区分不同额度的交易。
35.2)交易类型：可以是先投资后代扣、定投或还款等类型。交易类型还可以有其他划分方式，本技术不做具体限定。
36.3)银行：用于表示用户银行卡的归属银行。
37.4)第一支付类型：可以表示支付类型的一级分类。比如，可以包括充值和取现两个大类别，即代收和代付。
38.5)第二支付类型：可以表示支付类型的二级分类。比如，第一支付类型如果是代收，代收又可细分为先投资后代扣、定期投资代扣、普通充值和后台还款等第二支付类型；第一支付类型如果是代付，代付又可以细分为对公代付、对私取现和普通代发等第二支付类型。本技术对第一支付类型、第二支付类型的划分方式不做具体限定。
39.6)银行标识代码(bank identification number,bin)：可用于指定某一组银行的银行卡。
40.需要说明的是，用户还可以设置目标交易的数量，或者直接按照默认的数量抽取目标交易，还可以设定抽取某一段时间内的符合相应抽样条件的交易作为目标交易，等等。
41.应理解，平台的运营人员可以通过以上多种维度信息对抽样条件进行合理配置，以满足不同业务场景下的渠道健康检测需求。比如，通过设置小范围抽样，既可以达到渠道异常检查的目的，又可以尽量降低对业务的影响，不会影响其他交易的顺利进行。
42.在一种可能的实施例中，可以在基于目标业务和目标支付渠道确定抽样条件之前，预先建立多种业务类型、多种支付渠道和多种不同的抽样条件之间的映射关系，其中，多种业务类型中的每种业务类型至少对应一种支付渠道，每种业务类型下的每一种支付渠道都会对应一种抽样条件，该映射关系用于指定一种业务类型在指定的支付渠道下的抽样条件，这里的一种业务类型可以是多种业务类型中的任意一种。应理解，目标业务是这多种
业务类型中的任意一种业务类型，目标业务对应至少一种支付渠道，目标业务下的每种支付渠道都对应有一种抽样条件。
43.表1是本技术实施例提供的一种业务类型、支付渠道和抽样条件的映射关系表，其中，业务1对应两种支付渠道，分别是支付渠道1和支付渠道3，业务1下的两种支付渠道又分别对应了抽样条件1和抽样条件2，其他业务类型和支付渠道、抽样条件之间的映射关系同理。显然，表中的业务类型和支付渠道是一对多的关系，还可以是一对一的关系(比如某业务类型仅对应一种支付渠道)；同一业务类型下的各种支付渠道与抽样条件之间是一一对应的。可以理解的是，基于预先建立的此种映射关系，便可以基于目标业务和目标支付渠道自动确定对应的抽样条件，然后再根据抽样条件确定目标交易。需要说明的是，除了采用图1中的表格形式，还可以采用其他方式建立多种业务类型、多种支付渠道和多种不同的抽样条件之间的映射关系，本技术不做具体限定。
44.具体举例来说，某平台提供的其中一种业务为游戏充值业务，该业务对应的支付渠道为支付宝和银行a。根据预先建立的映射关系，可以自动确定该业务下的每种支付渠道所对应的抽样条件，以便执行支付渠道的检查。其中，该业务下的支付宝渠道对应的抽样条件1为：金额区间在0
‑
999元，第一支付类型是代收，第二支付类型是普通充值。该业务下的银行a渠道对应的抽样条件2为：金额区间在1000
‑
10000元，银行卡归属银行为银行a。如果这时候要对该业务下的支付宝渠道的健康状况进行检查，则自动根据抽样条件1确定目标交易(可以从该业务下的在线交易中自动抽取一笔或者多笔符合抽样条件1的交易作为目标交易)，然后将目标交易发送至支付宝渠道进行处理，支付宝渠道处理完后会将处理结果反馈到平台。同理，如果要对该业务下的银行a渠道进行检查，则自动根据抽样条件2确定目标交易，然后将目标交易发送至银行a进行处理，银行a渠道处理完目标交易后将处理结果反馈到平台，平台再自动根据该处理结果确定该渠道是否异常。显然，基于预先建立的此种映射关系，可以轻松实现支付渠道的自动检查，无需人工监测，减少人力投入和运营成本。
45.在一种可能的实施例中，运营人员还可以直接输入抽样条件，然后根据输入的抽样条件确定目标交易。比如，预先建立的映射关系表不够全面或者不能满足当前的检测需求，于是运营人员可以自行配置抽样条件，然后基于此抽样条件确定目标交易以进行目标支付渠道的自动检查。
46.表1业务类型、支付渠道和抽样条件的映射关系表
[0047][0048]
在一种可能的实施例中，获取目标业务下的第一交易，然后提取第一交易的属性；若第一交易的属性满足抽样条件，则将第一交易确定为目标交易，其中，抽样条件包括金额区间、支付类型、银行卡归属银行、银行标识代码中的一个或者多个。上述第一交易可以是目标业务下的任意一个交易，然后提取该交易的属性与抽样条件进行匹配，如果该交易的
属性能够满足抽样条件，即可将该交易作为目标交易，其他交易也是同样的判断方法，提取交易的属性与抽样条件进行匹配。例如，抽样条件中的金额区间是0
‑
100，抽取目标业务下的某个交易，提取该交易的属性，发现该交易的金额是55，刚好和抽样条件的金额区间匹配，于是可以确定为目标交易。再抽取目标业务下的另一个交易并提取该交易的属性，发现该交易的金额是156，不满足抽样条件。
[0049]
s103.获取目标支付渠道对目标交易的处理结果，根据处理结果确定目标业务下的目标支付渠道是否异常。
[0050]
也就是说，将目标交易送至目标支付渠道进行处理，然后根据目标支付渠道对目标交易的处理结果，可以确定目标业务下的目标支付渠道是否存在异常。
[0051]
在可能的实施例中，上述处理结果包括交易成功率和/或平均处理时间，根据该处理结果可以确定目标业务下的目标支付渠道是否异常。
[0052]
具体的，上述处理结果可以包括目标交易的交易成功率或者失败率，根据目标支付渠道处理目标交易的交易成功率，可以确定目标业务下的目标支付渠道是否正常：如果通过目标支付渠道处理目标交易的交易成功率大于或等于第一阈值(可以设定)，说明目标支付渠道正常；如果通过目标支付渠道处理目标交易的交易成功率小于第一阈值，说明目标支付渠道异常。例如，根据抽样条件1从业务1下的所有在线交易中确定了100笔交易(即目标交易)，然后将这100笔交易送至目标支付渠道进行处理，其中，交易成功的有90笔，交易失败的有10笔，于是目标交易的交易成功率为90％。此交易成功率低于设定的第一阈值(96％)，于是认为业务1下的目标支付渠道存在异常。
[0053]
上述处理结果可以包括目标交易的平均处理时间。应理解，渠道的网络抖动可能会导致处理时间延长。如果通过目标支付渠道处理目标交易的平均处理时间小于或等于第二阈值(可以设定)，说明目标支付渠道正常；如果通过目标支付渠道处理目标交易的平均处理时间大于第二阈值，说明目标支付渠道异常。
[0054]
在可能的实施例中，在确定目标支付渠道正常的情况下，开启目标业务下的目标支付渠道，于是可以使用目标支付渠道处理目标业务下的其他交易。
[0055]
在可能的实施例中，在确定目标支付渠道异常的情况下，关闭目标业务下的目标支付渠道，也就是说，在目标业务中暂时屏蔽掉目标支付渠道，不使用该渠道处理目标业务下的交易，可以使用其他正常的渠道处理目标业务下的交易。在确定目标支付渠道异常的情况下，还可以向目标支付渠道的提供方发送异常通知，以使目标支付渠道的提供方对目标支付渠道进行维护
[0056]
在一种可能的实施例中，如果目标业务的目标支付渠道正处于静默期(或者说静默期即将结束)，那么，在确定目标支付渠道异常的情况下，延长目标业务下的目标支付渠道的静默期，在确定目标支付渠道正常的情况下，结束目标业务下的目标支付渠道的静默期。这样实现了对渠道静默期的控制(结束或者延长)，以避免对异常渠道的错误开启。
[0057]
综上所述，本技术实施例首先确定目标业务的目标支付渠道(即待检测的渠道，可以根据用户的输入确定，也可以自动确定)，然后根据目标业务和目标支付渠道确定抽样条件并根据抽样条件确定目标交易，接着将目标交易送至目标支付渠道进行处理，根据目标支付渠道对目标交易的处理结果(交易成功率、失败率、平均处理时间等等)，可以确定目标业务下的目标支付渠道的健康状况(正常或者异常)。在确定目标支付渠道正常的情况下，
可以开放目标业务下的目标支付渠道；在确定目标支付渠道异常的情况下，关闭目标业务下的目标支付渠道，目标业务暂时屏蔽/暂停使用目标支付渠道一段时间，也是就是为目标业务下的目标支付渠道设置静默期。在目标支付渠道的静默期结束之前，也可以采用同样的方式检测该渠道是否异常(是否恢复正常)，以决定是否结束其静默期或者延长静默期。可以理解的是，在支付渠道重新开启之前，有必要对其健康状况进行检查，只有在确认该渠道健康的情况下才开启，避免渠道实际未恢复正常却被开启的状况，避免造成大批量交易失败、影响平台用户的体验。该方法支持从多种维度配置抽样条件，能够精确抽取目标交易、满足不同业务场景下的渠道健康检测需求，而且可以预先配置多种业务类型、多种支付渠道和多种不同的抽样条件之间的映射关系，这样能够快速确定抽样条件并根据抽样条件确定目标交易，实现定制的、自动化的渠道健康检测，无需专人留守，提高运营效率。
[0058]
需要说明的是，本技术实施例抽取的是真实交易，比如从平台的在线交易(真实在线交易)中抽取符合抽样条件的目标交易。采用真实交易来验证渠道健康状况，能够满足一些特定平台的要求。例如，理财交易平台严格对应实际资产，涉及合规与监管等方面的要求，因此要求必须采用真实交易、真实账号支付。抽取真实交易验证，能够满足平台的真实性要求。
[0059]
还需要说明的是，本技术中不同业务下的渠道健康状况检测是分开进行的，即使不同业务对应了同一种渠道，每种业务下该渠道的检测也需要分别进行。一方面是因为，不同业务对接的渠道可能不同，需要分别检测。二是因为，支付渠道对于平台的各种业务来说不是统一开放的。比如，即使两个不同业务对应了同一种渠道，可能会出现同一渠道在处理业务1的交易的时候正常，在处理业务2下的交易的时候异常，即渠道所提供的部分功能正常，部分功能存在异常，于是在业务1下该渠道开放，业务2下该渠道关闭(或者说临时屏蔽)。不同业务下的相同渠道不统一检测其健康状况，能够尽量保证受影响的业务较少。
[0060]
本技术实施例所提供的上述方法，除了可以用于一般的商户平台，还可以用于第三方支付公司平台，甚至可以用于第四方支付机构平台等，在这些平台的支付路由设计中，也可以结合该渠道异常检查方法。
[0061]
请参见图3，图3是本技术提供的一种支付渠道异常检查装置300的结构示意图，该装置300包括获取模块301和处理模块302。
[0062]
获取模块301用于获取目标业务的目标支付渠道，其中，目标业务对应至少一种支付渠道，目标支付渠道是目标业务对应的支付渠道中的任意一种；
[0063]
处理模块302用于基于目标业务和目标支付渠道确定抽样条件，根据抽样条件确定目标交易；
[0064]
处理模块302还用于，获取目标支付渠道对目标交易的处理结果，根据处理结果确定目标业务下的目标支付渠道是否异常。
[0065]
上述支付渠道异常检查装置300的各个模块具体用于实现图2的支付渠道异常检查方法中的任一实施例，为了说明书的简洁，这里不赘述。
[0066]
图4是本技术实施例提供的一种计算设备400的结构示意图。计算设备400可以是笔记本电脑、平板电脑以及云端服务器等计算设备，本技术不做限制。
[0067]
计算设备400包括处理器401、存储器402以及通信接口403，计算设备400具体用于实现图2的支付渠道异常检查方法中的步骤s101至s103。其中，处理器401、存储器402以及
通信接口403可以通过内部总线404相互连接，也可通过无线传输等其他手段实现通信。本技术实施例以通过总线404连接为例，总线404可以是外设部件互连标准(peripheral component interconnect,pci)总线或扩展工业标准结构(extended industry standard architecture,eisa)总线等。总线404可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
[0068]
处理器401可以由至少一个通用处理器构成，例如中央处理器(central processing unit,cpu)，或者cpu和硬件芯片的组合。上述硬件芯片可以是专用集成电路(application
‑
specific integrated circuit,asic)、可编程逻辑器件(programmable logic device,pld)或其组合。上述pld可以是复杂可编程逻辑器件(complex programmable logic device,cpld)、现场可编程逻辑门阵列(field
‑
programmable gate array,fpga)、通用阵列逻辑(generic array logic,gal)或其任意组合。处理器401执行各种类型的数字存储指令，例如存储在存储器402中的软件或者固件程序，它能使计算设备400提供多种服务。
[0069]
存储器402用于存储程序代码，并由处理器401来控制执行，以执行上述图2的支付渠道异常检查方法中的任一实施例。程序代码中可以包括一个或多个软件模块，这一个或多个软件模块可以为图3实施例中提供的软件模块，如获取模块301以及处理模块302。计算设备400的各模块具体可用于执行图2中的步骤s101至s103中的任一实施例，为了说明书的简洁，这里不赘述。
[0070]
需要说明的是，本实施例可以是通用的物理服务器实现的，例如，arm服务器或者x86服务器，也可以是基于通用的物理服务器结合nfv技术实现的虚拟机实现的，虚拟机指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统，本技术不作具体限定。应理解，图4所示的计算设备400还可以是至少一个服务器构成的计算机集群，本技术不作具体限定。
[0071]
存储器402可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，ram)；存储器402也可以包括非易失性存储器(non
‑
volatile memory)，例如只读存储器(read
‑
only memory，rom)、快闪存储器(flash memory)、硬盘(hard disk drive，hdd)或固态硬盘(solid
‑
state drive，ssd)；存储器402还可以包括上述种类的组合。存储器402可以存储有程序代码，具体可以包括用于执行图2描述的步骤s101至s103的程序代码，这里不再进行赘述。
[0072]
通信接口403可以为有线接口(例如以太网接口)，可以为内部接口(例如高速串行计算机扩展总线(peripheral component interconnect express,pcie)总线接口)、有线接口(例如以太网接口)或无线接口(例如蜂窝网络接口或使用无线局域网接口)，用于与与其他设备或模块进行通信。
[0073]
需要说明的，图4仅仅是本技术实施例的一种可能的实现方式，实际应用中，计算设备400还可以包括更多或更少的部件，这里不作限制。关于本技术实施例中未出示或未描述的内容，可参见前述图2的支付渠道异常检查方法的实施例中的相关阐述，这里不再赘述。
[0074]
本技术实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有指令，当其在处理器上运行时，图2所示的方法流程得以实现。
[0075]
本技术实施例还提供一种计算机程序产品，当计算机程序产品在处理器上运行时，图2所示的方法流程得以实现。
[0076]
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，的存储介质可为磁碟、光盘、只读存储记忆体(read
‑
only memory，rom)或随机存储记忆体(random access memory，ram)等。
[0077]
以上所揭露的仅为本技术一种较佳实施例而已，当然不能以此来限定本技术之权利范围，本领域普通技术人员可以理解实现上述实施例的全部或部分流程，并依本技术权利要求所作的等同变化，仍属于发明所涵盖的范围。