CN110838012B - 一种支付方法、存储介质及相关设备 - Google Patents

Abstract

本发明实施例公开了一种支付方法、存储介质及相关设备，应用于通信技术领域。在本实施例的方法中，当业务合作终端检测到支付终端提供的用户支付信息，会根据支付系统下的第一风险用户列表和业务合作系统下的第二风险用户列表，确定用户支付信息对应用户是否是风险用户，如果是风险用户，则拒绝将用户支付信息发送给支付系统进行支付，以拦截支付终端。这样当支付终端离线时，如果支付终端向业务合作终端提供了用户支付信息，可以从业务合作终端一侧对具有风险的用户的支付终端进行拦截；且在确定用户是否风险用户时，需要结合两个系统下的风险用户列表，范围比较广，使得对风险用户的确定更准确。

Description

一种支付方法、存储介质及相关设备

技术领域

本发明涉及通信技术领域，特别涉及一种支付方法、存储介质及相关设备。

背景技术

随着信息通信的发展，现在很多支付系统中都可以通过支付终端拉取用户支付信息，并提供给商家系统以完成支付，比如在微信系统中通过微信终端可以拉取用户支付码，并提供给商户系统以完成支付，这样给用户带来很多便利，但是，只有保障支付终端拉取用户支付信息的安全性，才能避免对应用户的资金损失。

现有技术中支付终端在拉取用户支付信息的过程中，当用户通过支付终端发起拉取用户支付信息的流程后，由支付信息后台判断该支付终端对应用户是否存在风险，并对存在风险的用户进行拦截，这样支付信息后台就不会发送用户支付信息给该支付终端，从而减少了对应用户的资金损失。

但是现有技术中，有些支付终端在首次拉取了用户支付信息后会在本地存储该用户支付信息一段时间，在这段时间内，当支付终端在离线的情况下，支付终端还是可以显示在本地存储的用户支付信息，当用户将该用户支付信息提供给商户系统，商户系统会根据该用户支付信息完成异步支付，使得支付信息后台无法进行有效阻止，会对用户资金造成风险。

发明内容

本发明实施例提供一种支付方法、存储介质及相关设备，实现了在业务合作终端对具有风险的用户进行拦截。

本发明实施例一方面提供一种支付方法，所述方法应用于业务合作终端，包括：

当检测到支付终端提供的用户支付信息，获取支付系统下的第一风险用户列表，及业务合作系统下的第二风险用户列表；所述第一风险用户列表和第二风险用户列表包括风险用户的信息；

根据所述第一风险用户列表和第二风险用户列表，确定所述用户支付信息对应用户是否为风险用户；

如果所述用户支付信息对应用户为风险用户，拒绝将所述用户支付信息发送给所述支付系统进行支付，以拦截所述支付终端。

本发明实施例第二方面提供一种支付方法，包括：

生成支付系统下的第一风险用户列表；

获取业务合作系统下的第二风险用户列表；所述第一风险用户列表和第二风险用户列表包括风险用户的信息；

将所述第一风险用户列表和第二风险用户列表下发给所述业务合作系统中的业务合作终端，以便所述业务合作终端在支付终端进行支付时，根据所述第一风险用户列表和第二风险用户列表对具有风险的用户进行拦截。

本发明实施例第三方面提供业务合作终端，包括：

列表获取单元，用于当检测到支付终端提供的用户支付信息，获取支付系统下的第一风险用户列表，及业务合作系统下的第二风险用户列表；所述第一风险用户列表和第二风险用户列表包括风险用户的信息；

风险确定单元，用于根据所述第一风险用户列表和第二风险用户列表，确定所述用户支付信息对应用户是否为风险用户；

支付拦截单元，用于如果所述用户支付信息对应用户为风险用户，拒绝将所述用户支付信息发送给所述支付系统进行支付，以拦截所述支付终端对应用户。

本发明实施例第四方面提供一种支付信息后台，包括：

第一列表生成单元，用于生成支付系统下的第一风险用户列表；

第二列表获取单元，用于获取业务合作系统下的第二风险用户列表；所述第一风险用户列表和第二风险用户列表包括风险用户的信息；

下发支付单元，用于将所述第一风险用户列表和第二风险用户列表下发给所述业务合作系统中的业务合作终端，以便所述业务合作终端在支付终端进行支付时，根据所述第一风险用户列表和第二风险用户列表对具有风险的用户进行拦截。

本发明实施例第五方面提供一种存储介质，所述存储介质储存多条指令，所述指令适于由处理器加载并执行如第一方面或第二方面所述的支付方法。

本发明实施例第六方面提供一种终端设备，包括处理器和存储介质，所述处理器，用于实现各个指令；

所述存储介质用于储存多条指令，所述指令用于由处理器加载并执行如第一方面所述的支付方法。

本发明实施例第七方面提供一种服务器，包括处理器和存储介质，所述处理器，用于实现各个指令；

所述存储介质用于储存多条指令，所述指令用于由处理器加载并执行如第二方面所述的支付方法。

可见，在本实施例的方法中，当业务合作终端检测到支付终端提供的用户支付信息，会根据支付系统下的第一风险用户列表和业务合作系统下的第二风险用户列表，确定用户支付信息对应用户是否是风险用户，如果是风险用户，则拒绝将用户支付信息发送给支付系统进行支付，以拦截支付终端。这样当支付终端离线时，如果支付终端向业务合作终端提供了用户支付信息，可以从业务合作终端一侧对具有风险的用户的支付终端进行拦截；且在确定用户是否风险用户时，需要结合两个系统下的风险用户列表，范围比较广，使得对风险用户的确定更准确。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的支付方法所应用于的场景的示意图；

图2是本发明一个实施例提供的一种支付方法的流程图；

图3是本发明另一个实施例提供的一种支付方法的流程图；

图4是本发明应用实施例中支付方法所应用于的系统的结构示意图；

图5是本发明应用实施例中在发起支付流程之前的处理方法的示意图；

图6是本发明应用实施例提供的一种支付方法的示意图；

图7是本发明实施例提供的一种业务合作终端的结构示意图；

图8是本发明实施例提供的一种支付信息后台的结构示意图；

图9是本发明实施例提供的一种终端设备的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排它的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本发明实施例提供一种支付方法，主要可以应用于如图1所示的场景中，在该场景中包括业务合作终端、业务合作后台、支付终端和支付信息后台，其中：

支付终端是提供给用户的接口，用户可以操作支付终端，使得支付终端从支付信息后台获取用户支付信息，并按照一定方式显示获取的用户支付信息；支付信息后台用于根据支付终端发起的用户支付信息的获取请求，判断对应用户是否是风险用户，如果是风险用户，拒绝发送对应的用户支付信息给支付终端，如果非风险用户，将对应的用户支付信息发送给支付终端；业务合作终端用于当检测到支付终端的用户支付信息，将用户支付信息和支付金额等信息发送给支付系统以完成支付；业务合作后台是该业务合作终端对应的服务后台，可以管理各个业务合作终端。

在实际应用中，上述支付终端可以是装载微信小程序等支付程序的终端；业务合作终端可以是在支付系统中开通了支付业务的终端，比如公交通系统行人通行的验证设备，包括但不限于公交车上的刷卡机，地铁系统的验票闸机等，简称为机具。

需要说明的是，上述支付信息后台可以是支付系统中用于支付的支付后台，也可以是业务合作方的服务器。例如，如果支付终端是装载微信小程序的终端，即微信终端，而支付信息后台为微信小程序的服务器，该服务器可以是业务合作方的服务器。

进一步地，在本实施例中，支付信息后台与业务合作后台之间会交换风险用户列表，即支付信息后台会将支付系统下的第一风险用户列表发送给业务合作后台，而业务合作后台会将业务合作系统下的第二风险用户列表发送给支付信息后台。这样，支付信息后台可以根据第一风险用户列表和第二风险用户列表判断某一用户是否为风险用户。

具体地，在本发明实施例中，上述的业务合作终端可以按照如下方法完成支付流程：

当检测到支付终端提供的用户支付信息，获取支付系统下的第一风险用户列表，及业务合作系统下的第二风险用户列表，第一风险用户列表和第二风险用户列表包括风险用户的信息；根据第一风险用户列表和第二风险用户列表，确定用户支付信息对应用户是否为风险用户；如果用户支付信息对应用户为风险用户，拒绝将用户支付信息发送给支付系统进行支付，以拦截支付终端。

而本发明实施例中的支付信息后台会执行如下步骤：

生成支付系统下的第一风险用户列表；获取业务合作系统下的第二风险用户列表；所述第一风险用户列表和第二风险用户列表包括风险用户的信息；将所述第一风险用户列表和第二风险用户列表下发给所述业务合作系统中的业务合作终端，以便所述业务合作终端在支付终端进行支付时，根据所述第一风险用户列表和第二风险用户列表对具有风险的用户进行拦截。

这样当支付终端离线时，如果支付终端向业务合作终端提供了用户支付信息，可以从业务合作终端一侧对具有风险的用户的支付终端进行拦截；且在确定用户是否风险用户时，需要结合两个系统下的风险用户列表，范围比较广，使得对风险用户的确定更准确。

本发明一个实施例提供一种支付方法，主要是业务合作终端所执行的方法，流程图如图2所示，包括：

步骤101，当检测到支付终端提供的用户支付信息，获取支付系统下的第一风险用户列表，及业务合作系统下的第二风险用户列表，第一风险用户列表和第二风险用户列表包括风险用户的信息。

可以理解，用户可以操作支付终端使得支付终端向支付信息后台获取了用户支付信息，并按照一定方式(比如按照二维码或条形码等方式)进行显示后，如果将支付终端显示用户支付信息的界面靠近业务合作终端，比如将显示用户支付信息的界面放置在业务合作终端所包括的信息检测装置(比如二维码扫描装置等)的检测范围内，这样业务合作终端会接到支付终端提供的用户支付信息。其中用户支付信息中可以包括：用户的支付账号，和用户的身份信息等。

当业务合作终端检测到用户支付信息后，会先获取第一风险用户列表和第二风险用户列表。

可以理解，第一风险用户列表可以是支付信息后台利用一定的策略对支付系统中的各个用户进行风险评估得到的，第二风险用户列表是业务合作后台对业务合作系统中的各个用户进行风险评估得到的，在各个风险用户列表中都包括多个风险用户的信息，比如标识信息等。

一种情况下，支付信息后台可以将第一风险用户列表下发到业务合作终端储存，且业务合作后台会将第二风险用户列表下发到业务合作终端进行储存，当业务合作终端检测到用户支付信息后，会直接从本地存储中提取出第一风险用户列表和第二风险用户列表。

另一种情况下，支付信息后台和业务合作后台在得到各自的风险用户列表后，会进行交换，即支付信息后台会将第一风险用户列表发送给业务合作后台，而业务合作后台会将第二风险用户列表发送给支付信息后台，使得在支付信息后台和业务合作后台中都会储存第一风险用户列表和第二风险用户列表，这样，支付信息后台或是业务合作后台可以将第一风险用户列表和第二风险用户列表主动发送给业务合作终端进行储存。当业务合作终端检测到用户支付信息后，会直接从本地存储中提取出第一风险用户列表和第二风险用户列表。

其中，支付信息后台会按照一定的周期更新第一风险用户列表，而业务合作后台也会按照一定的周期更新第二风险用户列表，并在支付信息后台与业务合作后台之间交换风险用户列表。

步骤102，根据第一风险用户列表和第二风险用户列表，确定用户支付信息对应用户是否为风险用户，如果用户支付信息对应用户为风险用户，则执行步骤103；如果对应用户非风险用户，则执行步骤104。

具体地，业务合作终端在确定用户支付信息对应用户是否为风险用户时，可以确定用户支付信息中的任一信息是否与第一风险用户列表或第二风险用户列表中各个风险用户的信息一致，如果一致，则该用户支付信息对应用户是风险用户；如果不一致，则该用户支付信息对应用户非风险用户。

例如，用户支付信息中包括某一用户的真实姓名a及该用户的微信号b等，而在第一风险用户列表中包括多个用户的微信号，这些微信号中包括上述用户的微信号b，在第二风险用户列表中包括多个用户的真实姓名，这些真实姓名中也包括上述用户的真实姓名a，则该用户为风险用户。

步骤103，拒绝将用户支付信息发送给支付系统进行支付，以拦截上述支付终端对应用户。

步骤104，将用户支付信息发送给支付系统进行支付。

在实际应用中，如果本实施例的业务合作终端中包括信息检测装置和通行装置，在一种情况下，信息检测装置执行上述步骤101、102和104后，该信息检测装置还会触发通行装置开启通行通道，以便行人通过。

另一种情况下，信息检测装置执行上述步骤101、102和103后，该信息检测装置不会触发通行装置开启通行通道，达到拦截支付终端的目的。在这种情况下，业务合作终端还可以向上述支付信息后台上报拦截信息，该拦截信息用于指示上述支付终端提供的用户支付信息对应用户为风险用户，这样，支付信息后台可以根据该拦截信息向对应的支付终端发送删除命令，使得支付终端根据删除命令删除在支付终端中储存的用户支付信息。

其中，在实际应用中，当支付信息后台在首次发送用户支付信息给支付终端时，会为用户支付信息打标签，并将该标签与对应的用户支付信息一同发送给支付终端。这样支付终端在删除用户支付信息时，需要将该标签一同删除。

可见，在本实施例的方法中，当业务合作终端检测到支付终端提供的用户支付信息，会根据支付系统下的第一风险用户列表和业务合作系统下的第二风险用户列表，确定用户支付信息对应用户是否是风险用户，如果是风险用户，则拒绝将用户支付信息发送给支付系统进行支付，以拦截支付终端。这样当支付终端离线时，如果支付终端向业务合作终端提供了用户支付信息，可以从业务合作终端一侧对具有风险的用户的支付终端进行拦截；且在确定用户是否风险用户时，需要结合两个系统下的风险用户列表，范围比较广，使得对风险用户的确定更准确。

本发明另一个实施例提供一种支付方法，主要是由上述的支付信息后台所执行的方法，该支付信息后台可以是支付后台，也可以是业务合作方的服务器等，本实施例的流程图如图3所示，包括：

步骤201，生成支付系统下的第一风险用户列表。

可以理解，支付信息后台会按照一定的周期发起本实施例的流程，且在生成第一风险用户列表时，会根据支付系统下用户的多个维度的信息确定第一风险用户列表。具体地：

支付信息后台针对用户每个维度的信息，分别确定对应的分数，然后将每个维度对应的分数的函数计算值作为一个用户对应的风险衡量值，如果该风险衡量值不在预置范围内，则确定该用户为风险用户，将该用户的信息(比如用户标识，用户实名信息等)加入到第一风险用户列表中。其中，用户各个维度的信息可以包括：用户的历史支付金额，和用户是否实名认证的信息等。

例如，用户的信息包括3个维度的信息，其中，对于维度1的信息，确定的对应分数为a；对于维度2的信息确定的对应分数为b；对于维度3的信息确定的对应分数为c，则支付信息后台将a、b与c的函数计算值作为该用户的风险衡量值。

步骤202，获取业务合作系统下的第二风险用户列表；第一风险用户列表和第二风险用户列表包括风险用户的信息。

该第二风险用户列表是业务合作系统中的业务合作后台根据业务合作系统下的用户的各个维度的信息得到的，与上述第一风险用户列表得到的方法类似，不同的是，第二风险用户列表是针对业务合作系统中的用户。

支付信息后台可以在发起本实施例的流程时，主动向业务合作后台获取到第二风险用户列表，也可以是在业务合作后台获取到第二风险用户列表后主动发送给支付信息后台的。

需要说明的是，由于开通支付业务的业务合作系统有多个，如果该支付信息后台是支付系统中的支付后台，则支付信息后台在执行本步骤时，可以向每个业务合作系统获取对应的第二风险用户列表。

当支付信息后台获取到第一风险用户列表和第二风险用户列表后，会在支付信息后台储存该第一风险用户列表和第二风险用户列表。

步骤203，将第一风险用户列表和第二风险用户列表下发给业务合作系统中的业务合作终端，以便业务合作终端在支付终端进行支付时，根据第一风险用户列表和第二风险用户列表对具有风险的用户进行拦截，业务合作终端具体对具有风险用户的拦截方法见上述实施例中所述，在此不进行赘述。

具体地，支付信息后台在执行本步骤203时，可以对第一风险用户列表与第二风险用户列表之间相同用户的信息合并到第一风险用户列表或第二风险用户列表中，然后将合并后的第一风险用户列表和第二风险用户列表下发给业务合作终端。

由于支付信息后台和业务合作终端各自生成的风险用户列表中的用户可能会重叠，即第一风险用户列表和第二风险用户列表中可能会有相同用户的信息，为了减少网络流量，支付信息后台可以先合并第一风险用户列表和第二风险用户列表，然后再发送给业务合作终端。其中，如果第一风险用户列表中某一用户的第一信息，与第二风险用户列表中另一用户的第二信息中，第一信息与第二信息之间有重叠信息，则可以确定某一用户与另一用户为相同用户。

例如，在第一风险用户列表中包括3个用户的信息，即用户1、用户2和用户3的信息，在第二风险用户列表中包括4个用户的信息，即用户a、用户b、用户c和用户d的信息，其中，用户2和用户c为相同用户，则可以将用户c的信息储存到第一风险用户列表中并与用户2的信息进行关联，且删除第二风险用户列表中用户c的信息；或者，将用户2的信息储存到第二风险用户列表中并与用户c的信息进行关联，且删除第一风险用户列表中用户2的信息。

需要说明的是，如果支付信息后台为支付系统中的支付后台，则支付信息后台发送给某一业务合作终端的第二风险用户列表可以是与支付信息后台相关联的一个或多个业务合作系统下的风险用户列表。

可见，本实施例中，由支付信息后台在生成第一风险用户列表，且获取第二风险用户列表后，会将第一风险用户列表和第二风险用户列表都发送给业务合作系统中的业务合作终端，这样业务合作终端会在支付终端提供了用户支付信息进行支付时，根据第一风险用户列表和第二风险用户列表确定提供的用户支付信息对应用户是否为风险用户，如果为风险用户，则进行拦截。这样，即使是离线的支付终端在支付时，如果该支付终端提供了用户支付信息，也可以通过业务合作终端来对具有风险的用户进行拦截。

需要说明的是，上述步骤201到203中的方法是由支付信息后台将风险用户列表下发到业务合作终端中，以对支付过程中的风险用户拦截的过程；另一方面，在支付过程中，支付信息后台还可以通过如下的方法对风险用户进行拦截，这样可以实现通过双向判别支付终端对应用户是否为风险用户，使得用户支付过程更为安全：

支付信息后台接收到支付终端发送的获取用户支付信息的获取请求，会根据获取请求及第一风险用户列表和第二风险用户列表，确定获取请求对应用户是否为风险用户，如果对应用户为风险用户，拒绝向支付终端发送对应的用户支付信息。

其中，用户使用支付终端进行支付时，可以先操作支付终端，使得支付终端显示用户支付信息，具体地，用户可以触发支付终端某一界面上显示的获取接口，这样如果支付终端在线(与支付信息后台之间连接)，会发送获取请求给支付信息后台，来获取相应的用户支付信息；如果支付终端离线(与支付信息后台之间断开连接)，会提取支付终端中储存的用户支付信息进行显示，如果在支付终端中未储存用户支付信息，则支付终端会反馈获取用户支付信息失败。

在一个具体的实施例中，支付信息后台可以在如下几种情况下，会主动发送删除命令给支付终端，以删除支付终端中储存的用户支付信息：

(1)当支付信息后台接收到业务合作终端发送的拦截信息，该拦截信息用于指示某一支付终端对应的用户为风险用户，则根据拦截信息发送删除命令给某一支付终端，以便某一支付终端根据所述删除命令删除支付终端中储存的用户支付信息。

可以理解，如果业务合作终端在检测到支付终端提供的用户支付信息后，如果确定该用户支付信息对应用户为风险用户，则向支付信息后台发送拦截信息，使得支付信息后台及时地发送删除命令，删除支付终端中的用户支付信息。

(2)支付信息后台在执行了上述步骤201和202后，会根据上述第一风险用户列表和第二风险用户列表确定某一支付终端对应用户是否为风险用户，如果为风险用户，支付信息后台会发送删除命令给某一支付终端，这样该支付终端会根据删除命令删除支付终端中储存的用户支付信息。

这样，通过删除命令可以避免风险用户的支付终端在离线时，使用支付终端中储存的用户支付信息进行支付，从而减少了用户的损失。

以下以一个具体的应用实例来说明本发明中支付方法，本实施例的方法可以应用于如图4所示的场景中，且其中的公交通系统中的机具为上述的业务合作终端，管理机具的服务器(即机具服务器)为上述的业务合作服务器；装载微信小程序的终端(即微信终端)为上述的支付终端，微信小程序对应的服务器为上述的支付信息后台。本发明实施例的方法可以包括如下两部分：

(1)参考图5所示，在发起支付流程之前的处理包括如下步骤：

步骤301，微信小程序的服务器生成微信支付系统下的第一风险用户列表，在第一风险用户列表中包括多个风险用户的信息，每个风险用户的信息可以包括用户微信号，还可以包括与用户微信号相关联的用户身份信息等信息。

步骤302，微信小程序的服务器向机具服务器获取公交通系统下的第二风险用户列表，在第二风险用户列表中每个风险用户的信息可以包括用户身份信息等信息。

这里的机具服务器可以是一个或多个公交通系统中的机具服务器，第二风险用户列表可以一个或多个公交通系统分别对应的风险用户的信息。

步骤303，微信小程序的服务器将第一风险用户列表和第二风险用户列表下发给机具，这样机具在用户使用微信终端进行支付的过程中，判别微信终端对应用户是否为风险用户，以拦截对应用户。

步骤304，微信小程序的服务器会根据第一风险用户列表和第二风险用户列表，确定各个微信终端对应用户是否为风险用户。

如果某一微信终端对应用户为风险用户，可以发送删除命令给该微信终端，这样微信终端会根据删除命令删除微信终端中储存的用户支付信息。

(2)参考图6所示，发起的支付流程包括如下步骤：

步骤401，微信终端首次向微信小程序的服务器发送获取请求，该获取请求用于请求获取用户支付信息，在获取请求中可以包括用户微信号等信息。

需要说明的是，用户可以操作微信终端，使得微信终端启动某一微信小程序，这样微信终端就可以通过微信服务器向微信小程序的服务器发送获取请求。其中，微信服务器与微信小程序的服务器是不同的，微信小程序的服务器是微信终端启动的微信小程序对应的服务器，微信服务器是微信这个本体程序对应的服务器，微信小程序的服务器与微信终端之间的通信都需要经过微信服务器。

步骤402，微信小程序的服务器根据获取请求，获取微信支付系统下的第一风险用户列表和公交通系统下的第二风险用户列表，并根据第一风险用户列表和第二风险用户列表确定对应用户是否为风险用户，如果是风险用户，拒绝该获取请求；如果非风险用户，可以发送对应的用户支付信息给微信终端进行储存。

微信小程序的服务器在发送用户支付信息时，可以为用户支付信息打标签，并将打标签后的用户支付信息发送给微信终端，其中，为用户支付信息打的标签可以是离线卡证书，该离线卡证书是具有一定的期限的，。

步骤403，微信终端在获取到用户支付信息后，用一定方式显示用户支付信息，比如用二维码显示用户支付信息，用户将显示用户支付信息的界面靠近机具。

步骤404，机具在检测到用户支付信息，获取第一风险用户列表和第二风险用户列表。

步骤405，机具根据第一风险用户列表和第二风险用户列表，确定该用户支付信息对应用户是否是风险用户，如果是风险用户，则不会将用户支付信息发送给微信支付系统(即支付系统)进行支付，且不会触发机具中包括的通行装置开启通行通道；如果非风险用户，将用户支付信息发送给微信支付系统进行支付，且触发及具体中包括的通行装置开启通行通道。

进一步需要说明的是，当微信终端首次获取到用户支付信息后，会将用户支付信息储存到微信终端中。后续需要用微信终端进行支付，且该微信终端处于离线状态，则微信终端会显示该微信终端中储存的用户支付信息，并提供给机具。

本发明实施例还提供一种业务合作终端，其结构示意图如图7所示，具体可以包括：

列表获取单元10，用于当检测到支付终端提供的用户支付信息，获取支付系统下的第一风险用户列表，及业务合作系统下的第二风险用户列表；所述第一风险用户列表和第二风险用户列表包括风险用户的信息；

风险确定单元11，用于根据所述列表获取单元10获取的第一风险用户列表和第二风险用户列表，确定所述用户支付信息对应用户是否为风险用户；

支付拦截单元12，用于如果所述风险确定单元11确定用户支付信息对应用户为风险用户，拒绝将所述用户支付信息发送给所述支付系统进行支付，以拦截所述支付终端对应用户。

进一步地，业务合作终端还可以包括上报单元13和通行装置14，其中：

上报单元13，用于如果风险确定单元11确定用户支付信息对应用户为风险用户，向所述支付信息后台上报拦截信息，所述拦截信息用于指示所述用户支付信息对应用户为风险用户，以便所述支付信息后台根据所述拦截信息向所述支付终端发送删除命令，以删除所述支付终端中储存的用户支付信息。

通行装置14，用于开启或关闭通行通道。

则上述的风险确定单元11还用于在确定用户支付信息对应用户非风险用户时，触发通行装置14开启通行通道。

可见，在本实施例的业务合作终端中，当检测到支付终端提供的用户支付信息，风险确定单元11会根据支付系统下的第一风险用户列表和业务合作系统下的第二风险用户列表，确定用户支付信息对应用户是否是风险用户，如果是风险用户，则支付拦截单元12拒绝将用户支付信息发送给支付系统进行支付，以拦截支付终端。这样当支付终端离线时，如果支付终端向业务合作终端提供了用户支付信息，可以从业务合作终端一侧对具有风险的用户的支付终端进行拦截；且在确定用户是否风险用户时，需要结合两个系统下的风险用户列表，范围比较广，使得对风险用户的确定更准确。

本发明实施例还提供一种支付信息后台，其结构示意图如图8所示，具体可以包括：

第一列表生成单元20，用于生成支付系统下的第一风险用户列表；

第二列表获取单元21，用于获取业务合作系统下的第二风险用户列表；所述第一风险用户列表和第二风险用户列表包括风险用户的信息；

下发支付单元22，用于将所述第一列表生成单元20生成的第一风险用户列表和第二列表获取单元21获取的第二风险用户列表下发给所述业务合作系统中的业务合作终端，以便所述业务合作终端在支付终端进行支付时，根据所述第一风险用户列表和第二风险用户列表对具有风险的用户进行拦截。

具体地，下发支付单元22，用于对所述第一风险用户列表与第二风险用户列表之间相同用户的信息合并到所述第一风险用户列表或第二风险用户列表中；将合并后的第一风险用户列表和第二风险用户列表下发给所述业务合作终端。其中，如果本实施例的支付信息后台为支付系统中的之后后台，则所述第二风险用户列表可以为与所述支付信息后台关联的一个或多个业务合作系统下的风险用户列表。

进一步地，本实施例中的支付信息后台还可以包括信息拦截单元23和删除发送单元24，其中：

信息拦截单元23，用于接收所述支付终端发送的获取用户支付信息的获取请求；根据所述获取请求及所述第一列表生成单元20生成的第一风险用户列表和第二列表获取单元21获取的第二风险用户列表，确定所述获取请求对应用户是否为风险用户；如果对应用户为风险用户，拒绝向所述支付终端发送对应的用户支付信息。

删除发送单元24，用于接收业务合作终端发送的拦截信息，所述拦截信息用于指示某一支付终端对应的用户为风险用户；根据所述拦截信息发送删除命令给所述某一支付终端，以便所述某一支付终端根据所述删除命令删除所述支付终端中储存的用户支付信息。

另一方面，删除发送单元24，还用于根据所述第一风险用户列表和第二风险用户列表确定所述某一支付终端对应用户为风险用户；发送删除命令给所述某一支付终端，以便所述某一支付终端根据所述删除命令删除所述支付终端中储存的用户支付信息。

可见，本实施例的支付信息后台中，第一列表生成单元20会生成第一风险用户列表，且第二列表获取单元21获取第二风险用户列表后，下发支付单元22会将第一风险用户列表和第二风险用户列表都发送给业务合作系统中的业务合作终端，这样业务合作终端会在支付终端提供了用户支付信息进行支付时，根据第一风险用户列表和第二风险用户列表确定提供的用户支付信息对应用户是否为风险用户，如果为风险用户，则进行拦截。这样，即使是离线的支付终端在支付时，如果该支付终端提供了用户支付信息，也可以通过业务合作终端来对具有风险的用户进行拦截。

本发明实施例还提供一种终端设备，比如机具等，其结构示意图如图9所示，该语音数据的评价系统可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)30(例如，一个或一个以上处理器)和存储器31，一个或一个以上存储应用程序321或数据322的存储介质32(例如一个或一个以上海量存储设备)。其中，存储器31和存储介质32可以是短暂存储或持久存储。存储在存储介质32的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对终端设备中的一系列指令操作。更进一步地，中央处理器30可以设置为与存储介质32通信，在终端设备上执行存储介质32中的一系列指令操作。

具体地，在存储介质32中储存的应用程序321包括支付应用程序，且该程序可以包括上述业务合作终端中的列表获取单元10，风险确定单元11，支付拦截单元12，上报单元13和通行装置14，在此不进行赘述。更进一步地，中央处理器30可以设置为与存储介质32通信，在终端设备上执行存储介质32中储存的支付应用程序对应的一系列操作。

终端设备还可以包括一个或一个以上电源33，一个或一个以上有线或无线网络接口34，一个或一个以上输入输出接口35，和/或，一个或一个以上操作系统323，例如WindowsServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

其中，一个或多个输入输出接口35连接有通行装置36，该通行装置36用于开启或关闭通行通道，当中央处理器30确定某一支付终端对应用户非风险用户，则通过输入输出接口35触发通行装置36开启通行通道；当中央处理器30确定某一支付终端对应用户为风险用户，则通过输入输出接口35不会通行装置36开启通行通道，以拦截用户。

上述方法实施例中所述的由业务合作终端所执行的步骤可以基于该图9所示的终端设备的结构。

本发明实施例还提供一种服务器，该服务器的结构类似上述图9所示的终端设备的结构，不同的是，本实施例中的服务器不包括通行装置，且服务器中的存储介质中储存的应用程序包括支付应用程序，且该程序可以包括上述支付信息后台中的第一列表生成单元20，下发支付单元22，第二列表获取单元21，信息拦截单元23和删除发送单元24，在此不进行赘述。更进一步地，中央处理器可以设置为与存储介质通信，在服务器上执行存储介质中储存的支付应用程序对应的一系列操作。

本发明实施例还提供一种存储介质，所述存储介质储存多条指令，所述指令适于由处理器加载并执行如上述业务合作终端或支付信息后台所执行的支付方法。

本发明实施例还提供一种终端设备，包括处理器和存储介质，所述处理器，用于实现各个指令；所述存储介质用于储存多条指令，所述指令用于由处理器加载并执行如上述业务合作终端所执行的支付方法。

本发明实施例还提供一种服务器，包括处理器和存储介质，所述处理器，用于实现各个指令；所述存储介质用于储存多条指令，所述指令用于由处理器加载并执行如支付信息后台所执行的支付方法。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(ROM)、随机存取存储器RAM)、磁盘或光盘等。

以上对本发明实施例所提供的支付方法、存储介质及相关设备进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (15)

1.一种支付方法，其特征在于，应用于业务合作终端，包括：

当检测到支付终端提供的用户支付信息，获取支付系统下的第一风险用户列表，及业务合作系统下的第二风险用户列表；所述第一风险用户列表和第二风险用户列表包括风险用户的信息；所述用户支付信息包括用户的支付账号和用户的身份信息；其中，所述第一风险用户列表中某些风险用户的信息关联所述业务合作系统下的用户信息，或者，所述第二风险用户列表中的某些风险用户的信息关联所述支付系统下的用户信息；

其中，所述支付终端接收到的离线卡证书，是由支付信息后台首次发送所述用户支付信息给所述支付终端时一同发送的；

根据所述第一风险用户列表和第二风险用户列表，确定所述用户支付信息对应用户是否为风险用户；其中，所述第一风险用户列表和第二风险用户列表中相同用户的信息是关联的；

如果所述用户支付信息对应用户为风险用户，拒绝将所述用户支付信息发送给所述支付系统进行支付，以通过以下方式拦截所述支付终端对应用户：

如果所述支付终端处于在线状态，所述支付终端发送获取请求给所述支付信息后台，来获取所述用户支付信息；所述业务合作终端向所述支付信息后台上报拦截信息，以使所述支付信息后台根据所述拦截信息向所述支付终端发送删除命令，使得所述支付终端根据所述删除命令删除在所述支付终端中储存的所述用户支付信息和所述离线卡证书；

如果所述支付终端处于离线状态，提取所述支付终端中储存的所述用户支付信息进行显示；根据所述第一风险用户列表和第二风险用户列表确定所述支付终端对应用户是所述风险用户，所述支付信息后台发送所述删除命令给所述支付终端，所述支付终端根据所述删除命令删除所述支付终端中储存的所述用户支付信息和所述离线卡证书；如果所述支付终端中未储存所述用户支付信息，所述支付终端反馈获取所述用户支付信息失败；

所述第一风险用户列表中用户信息的类型与第二风险用户列表中用户信息的类型不同；所述根据所述第一风险用户列表和第二风险用户列表，确定所述用户支付信息对应用户是否为风险用户，具体包括：

确定所述用户的支付账号和用户的身份信息中的任一信息是否与第一风险用户列表或第二风险用户列表中各个风险用户的信息一致。

2.如权利要求1所述的方法，其特征在于，所述方法还包括：

向所述支付信息后台上报所述拦截信息，所述拦截信息用于指示所述用户支付信息对应用户为风险用户，以便所述支付信息后台根据所述拦截信息向所述支付终端发送删除命令，以删除所述支付终端中储存的所述用户支付信息。

3.如权利要求1或2所述的方法，其特征在于，所述业务合作终端包括信息检测装置和通行装置，所述方法还包括：

如果所述信息检测装置确定所述用户支付信息对应用户非风险用户，触发所述通行装置开启通行通道。

4.一种支付方法，其特征在于，应用于支付信息后台，包括：

生成支付系统下的第一风险用户列表；

获取业务合作系统下的第二风险用户列表；所述第一风险用户列表和第二风险用户列表包括风险用户的信息；所述第一风险用户列表中用户信息的类型与第二风险用户列表中用户信息的类型不同；其中，所述第一风险用户列表中某些风险用户的信息关联所述业务合作系统下的用户信息，或者，所述第二风险用户列表中的某些风险用户的信息关联所述支付系统下的用户信息；

将所述第一风险用户列表和第二风险用户列表下发给所述业务合作系统中的业务合作终端，以便所述业务合作终端在支付终端进行支付时，获取用户支付信息，所述用户支付信息包括用户的支付账号和用户的身份信息，确定所述用户的支付账号和用户的身份信息中的任一信息是否与第一风险用户列表或第二风险用户列表中各个风险用户的信息一致，以确定所述用户支付信息对应用户是否为风险用户并进行拦截；其中，所述第一风险用户列表和第二风险用户列表中相同用户的信息是关联的；

其中，所述支付终端接收到的离线卡证书，是由所述支付信息后台首次发送所述用户支付信息给所述支付终端时一同发送的；

其中，所述拦截包括：

如果所述用户支付信息对应用户为风险用户，拒绝将所述用户支付信息发送给所述支付系统进行支付，以通过以下方式拦截所述支付终端对应用户：

如果所述支付终端处于在线状态，所述支付终端发送获取请求给所述支付信息后台，来获取所述用户支付信息；所述业务合作终端向所述支付信息后台上报拦截信息，以使所述支付信息后台根据所述拦截信息向所述支付终端发送删除命令，使得所述支付终端根据所述删除命令删除在所述支付终端中储存的所述用户支付信息和所述离线卡证书；

如果所述支付终端处于离线状态，提取所述支付终端中储存的所述用户支付信息进行显示；根据所述第一风险用户列表和第二风险用户列表确定所述支付终端对应用户是所述风险用户，所述支付信息后台发送所述删除命令给所述支付终端，所述支付终端根据所述删除命令删除所述支付终端中储存的所述用户支付信息和所述离线卡证书；如果所述支付终端中未储存所述用户支付信息，所述支付终端反馈获取所述用户支付信息失败。

5.如权利要求4所述的方法，其特征在于，所述方法还包括：

接收所述支付终端发送的用户支付信息的获取请求；

根据所述获取请求及所述第一风险用户列表和第二风险用户列表，确定所述获取请求对应用户是否为风险用户；

如果对应用户为风险用户，拒绝向所述支付终端发送对应的用户支付信息。

6.如权利要求4或5所述的方法，其特征在于，所述将所述第一风险用户列表和第二风险用户列表下发给所述业务合作系统中的业务合作终端，具体包括：

对所述第一风险用户列表与第二风险用户列表之间相同用户的信息合并到所述第一风险用户列表或第二风险用户列表中；

将合并后的第一风险用户列表和第二风险用户列表下发给所述业务合作终端。

7.如权利要求6所述的方法，其特征在于，所述第二风险用户列表为与支付信息后台关联的一个或多个业务合作系统下的风险用户列表。

8.如权利要求4或5所述的方法，其特征在于，所述方法还包括：

接收业务合作终端发送的拦截信息，所述拦截信息用于指示某一支付终端对应的用户为风险用户；

根据所述拦截信息发送删除命令给所述某一支付终端，以便所述某一支付终端根据所述删除命令删除所述支付终端中储存的用户支付信息。

9.如权利要求4或5所述的方法，其特征在于，所述方法还包括：

根据所述第一风险用户列表和第二风险用户列表确定所述某一支付终端对应用户为风险用户；

发送删除命令给所述某一支付终端，以便所述某一支付终端根据所述删除命令删除所述支付终端中储存的用户支付信息。

10.一种业务合作终端，其特征在于，包括：

列表获取单元，用于当检测到支付终端提供的用户支付信息，获取支付系统下的第一风险用户列表，及业务合作系统下的第二风险用户列表；所述第一风险用户列表和第二风险用户列表包括风险用户的信息；所述用户支付信息包括用户的支付账号和用户的身份信息；其中，所述第一风险用户列表中某些风险用户的信息关联所述业务合作系统下的用户信息，或者，所述第二风险用户列表中的某些风险用户的信息关联所述支付系统下的用户信息；

风险确定单元，用于根据所述第一风险用户列表和第二风险用户列表，确定所述用户支付信息对应用户是否为风险用户；所述第一风险用户列表中用户信息的类型与第二风险用户列表中用户信息的类型不同；其中，所述第一风险用户列表和第二风险用户列表中相同用户的信息是关联的；

所述风险确定单元，具体用于确定所述用户的支付账号和用户的身份信息中的任一信息是否与第一风险用户列表或第二风险用户列表中各个风险用户的信息一致，以确定所述用户支付信息对应用户是否为风险用户；

支付拦截单元，用于如果所述用户支付信息对应用户为风险用户，拒绝将所述用户支付信息发送给所述支付系统进行支付，以通过以下方式拦截所述支付终端对应用户：

如果所述支付终端处于在线状态，所述支付终端发送获取请求给支付信息后台，来获取所述用户支付信息；所述业务合作终端向所述支付信息后台上报拦截信息，以使所述支付信息后台根据所述拦截信息向所述支付终端发送删除命令，使得所述支付终端根据所述删除命令删除在所述支付终端中储存的所述用户支付信息和所述离线卡证书；

如果所述支付终端处于离线状态，提取所述支付终端中储存的所述用户支付信息进行显示；根据所述第一风险用户列表和第二风险用户列表确定所述支付终端对应用户是所述风险用户，所述支付信息后台发送所述删除命令给所述支付终端，所述支付终端根据所述删除命令删除所述支付终端中储存的所述用户支付信息和所述离线卡证书；如果所述支付终端中未储存所述用户支付信息，所述支付终端反馈获取所述用户支付信息失败。

11.一种支付信息后台，其特征在于，包括：

第一列表生成单元，用于生成支付系统下的第一风险用户列表；

第二列表获取单元，用于获取业务合作系统下的第二风险用户列表；所述第一风险用户列表和第二风险用户列表包括风险用户的信息；所述第一风险用户列表中用户信息的类型与第二风险用户列表中用户信息的类型不同；其中，所述第一风险用户列表中某些风险用户的信息关联所述业务合作系统下的用户信息，或者，所述第二风险用户列表中的某些风险用户的信息关联所述支付系统下的用户信息；

下发支付单元，用于将所述第一风险用户列表和第二风险用户列表下发给所述业务合作系统中的业务合作终端，以便所述业务合作终端在支付终端进行支付时，获取用户支付信息，所述用户支付信息包括用户的支付账号和用户的身份信息，确定所述用户的支付账号和用户的身份信息中的任一信息是否与第一风险用户列表或第二风险用户列表中各个风险用户的信息一致，以确定所述用户支付信息对应用户是否为风险用户并进行拦截；其中，所述第一风险用户列表和第二风险用户列表中相同用户的信息是关联的；

其中，所述支付终端接收到的离线卡证书，是由所述支付信息后台首次发送所述用户支付信息给所述支付终端时一同发送的；

其中，所述拦截包括：

如果所述用户支付信息对应用户为风险用户，拒绝将所述用户支付信息发送给所述支付系统进行支付，以通过以下方式拦截所述支付终端对应用户：

如果所述支付终端处于在线状态，所述支付终端发送获取请求给所述支付信息后台，来获取所述用户支付信息；所述业务合作终端向所述支付信息后台上报拦截信息，以使所述支付信息后台根据所述拦截信息向所述支付终端发送删除命令，使得所述支付终端根据所述删除命令删除在所述支付终端中储存的所述用户支付信息和所述离线卡证书；

如果所述支付终端处于离线状态，提取所述支付终端中储存的所述用户支付信息进行显示；根据所述第一风险用户列表和第二风险用户列表确定所述支付终端对应用户是所述风险用户，所述支付信息后台发送所述删除命令给所述支付终端，所述支付终端根据所述删除命令删除所述支付终端中储存的所述用户支付信息和所述离线卡证书；如果所述支付终端中未储存所述用户支付信息，所述支付终端反馈获取所述用户支付信息失败。

12.如权利要求11所述的支付信息后台，其特征在于，还包括：

信息拦截单元，用于接收所述支付终端发送的获取用户支付信息的获取请求；根据所述获取请求及所述第一风险用户列表和第二风险用户列表，确定所述获取请求对应用户是否为风险用户；如果对应用户为风险用户，拒绝向所述支付终端发送对应的用户支付信息。

13.一种存储介质，其特征在于，所述存储介质储存多条指令，所述指令适于由处理器加载并执行如权利要求1至9任一项所述的支付方法。

14.一种终端设备，其特征在于，包括处理器和存储介质，所述处理器，用于实现各个指令；

所述存储介质用于储存多条指令，所述指令用于由处理器加载并执行如权利要求1至3任一项所述的支付方法。

15.一种服务器，其特征在于，包括处理器和存储介质，所述处理器，用于实现各个指令；

所述存储介质用于储存多条指令，所述指令用于由处理器加载并执行如权利要求4至9任一项所述的支付方法。