CN106875175A - 一种便于支付主体扩展的方法和装置 - Google Patents

Abstract

本申请提供一种便于支付主体扩展的方法和装置。所述方法包括：确定支付主体的类型；查找所述类型对应的主键生成规则；根据所述主键生成规则为所述支付主体生成支付主键，并保存所述支付主体与其支付主键之间的对应关系，其中，所述主键生成规则中指定有用于生成支付主键的支付主体要素，不同支付主体类型对应的主键生成规则中用于生成支付主键的支付主体要素不同。在本申请提供的支付主键生成方案中，可以根据支付主体类型对应的主键生成规则为所述支付主体生成支付主键，当支付主体扩展时，比如：新增支付主体类型，或新增支付主体的支付主体要素时，更新所述主键生成规则即可，无需重新开发整个模型，大大降低了开发成本。

Description

一种便于支付主体扩展的方法和装置

技术领域

本申请涉及互联网技术领域，尤其涉及一种便于支付主体扩展的方法和装置。

背景技术

随着互联网技术的快速发展，电子支付以其方便、快捷的优势逐渐取代了传统的支付方式。相关技术中，为确保电子支付过程中用户支付信息的安全传输，通常会将银行卡号等支付主体以密文的形式传输，风控、金融网关等相关平台可以通过所述密文查找对应的支付主体。然而，在这样的实现方式中，随着支付主体的扩展，原有的支付主体模型需要不断的升级才能满足业务的需求，带来了巨大的开发成本。

发明内容

有鉴于此，本申请提供一种便于支付主体扩展的方法和装置。

具体地，本申请是通过如下技术方案实现的：

一种便于支付主体扩展的方法，应用在服务器，所述方法包括：

确定支付主体的类型；

查找所述类型对应的主键生成规则；

根据所述主键生成规则为所述支付主体生成支付主键，并保存所述支付主体与其支付主键之间的对应关系；

其中，所述主键生成规则中指定有用于生成支付主键的支付主体要素，不同支付主体类型对应的主键生成规则中用于生成支付主键的支付主体要素不同。

可选的，所述根据所述主键生成规则为所述支付主体生成支付主键，包括：

获取所述主键生成规则指定的支付主体要素，作为主键生成要素；

按照所述主键生成规则指定的顺序对所述主键生成要素进行排序；

根据预设的算法计算排序后的主键生成要素的密文，以作为为所述支付主体生成的支付主键。

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

在接收到风控平台发送的携带有目标支付主键的主键查询请求后，查找所述目标支付主键对应的目标支付主体，并将所述目标支付主体的所有目标支付主体要素返回给所述风控平台；

在接收到所述风控平台发送的携带有风控要素的要素查询请求后，查找包括所述风控要素的支付主体列表，并将所述支付主体列表返回给所述风控平台，其中，所述风控要素是所有目标支付主体要素的子集。

可选的，所述确定支付主体的类型，包括：

在接收到针对支付主体的注册请求时，确定支付主体的类型。

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

当所述主键生成规则更新时，根据更新后的主键生成规则重新为所述支付主体生成支付主键；

在保存所述支付主体与其原支付主键之间对应关系的基础上，保存所述支付主体与为其重新生成的支付主键之间的对应关系。

一种便于支付主体扩展的装置，应用在服务器，所述装置包括：

类型确定单元，确定支付主体的类型；

规则查找单元，查找所述类型对应的主键生成规则；

主键生成单元，根据所述主键生成规则为所述支付主体生成支付主键，并保存所述支付主体与其支付主键之间的对应关系；

其中，所述主键生成规则中指定有用于生成支付主键的支付主体要素，不同支付主体类型对应的主键生成规则中用于生成支付主键的支付主体要素不同。

可选的，所述主键生成单元包括：

要素获取子单元，获取所述主键生成规则指定的支付主体要素，作为主键生成要素；

要素排序子单元，按照所述主键生成规则指定的顺序对所述主键生成要素进行排序；

主键生成子单元，根据预设的算法计算排序后的主键生成要素的密文，以作为为所述支付主体生成的支付主键。

可选的，所述装置还包括：

第一返回单元，在接收到风控平台发送的携带有目标支付主键的主键查询请求后，查找所述目标支付主键对应的目标支付主体，并将所述目标支付主体的所有目标支付主体要素返回给所述风控平台；

第二返回单元，在接收到所述风控平台发送的携带有风控要素的要素查询请求后，查找包括所述风控要素的支付主体列表，并将所述支付主体列表返回给所述风控平台，其中，所述风控要素是所有目标支付主体要素的子集。

可选的，所述类型确定单元，在接收到针对支付主体的注册请求时，确定支付主体的类型。

可选的，所述装置还包括：

规则更新单元，当所述主键生成规则更新时，根据更新后的主键生成规则重新为所述支付主体生成支付主键；

规则保存单元，在保存所述支付主体与其原支付主键之间对应关系的基础上，保存所述支付主体与为其重新生成的支付主键之间的对应关系。

由以上描述可以看出，在本申请提供的支付主键生成方案中，可以根据支付主体类型对应的主键生成规则为所述支付主体生成支付主键，当支付主体扩展时，比如：新增支付主体类型，或新增支付主体的支付主体要素时，更新所述主键生成规则即可，无需重新开发整个模型，大大降低了开发成本。

附图说明

图1是本申请一示例性实施例示出的一种便于支付主体扩展的方法的流程图。

图2是本申请一示例性实施例示出的一种为支付主体生成支付主键的方法流程图。

图3是本申请一示例性实施例示出的一种风控平台和服务器的交互方法图。

图4是本申请一示例性实施例示出的一种风控平台和服务器交互的组网示意图。

图5是本申请一示例性实施例示出的一种用于便于支付主体扩展的装置的一结构示意图。

图6是本申请一示例性实施例示出的一种便于支付主体扩展的装置的结构框图。

具体实施方式

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

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

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

相关技术中，假设，用户使用支付宝客户端进行电子支付，其支付宝客户端的账号为手机号码。起先，用户在支付宝客户端中绑定了第三方支付平台百度钱包的账号，当用户使用支付宝客户端进行电子支付时，基于当前的主键生成模型，服务器可以根据用户的手机号和已验证的真实姓名生成百度钱包的密文并返回。后续根据该密文，服务器可以查找到用户绑定的支付主体百度钱包。

又假设，用户后续又绑定了第三方支付平台京东支付的账号，基于前述的主键生成模型，服务器还会根据用户的手机号和真实姓名户名生成京东账号的密文。然而，该密文对应有两个第三方支付平台账号：百度钱包和京东支付，在后续的交互过程中，无法确认用户到底是选择百度钱包支付还是京东支付。因此，上述主键生成模型已不再适用，需要开发新的模型，由此带来了巨大的开发成本。

有鉴于此，本申请提供一种便于支付主体扩展的方案，可以提供通用的支付主体模型。

图1是本申请一示例性实施例示出的一种便于支付主体扩展的方法的流程示意图。

请参考图1，所述便于支付主体扩展的方法可以应用在服务器，包括有以下步骤：

步骤101，确定支付主体的类型。

在本实施例中，用户在进行电子支付时，通常需要使用银行卡、第三方支付平台账号等信息完成支付，在这个过程中，所述银行卡、第三方支付平台账号就是支付主体。

在本实施例中，所述支付主体要素为支付主体的信息，以支付主体为信用卡为例，其支付主体要素通常包括有：卡号、有效期、安全校验码、户名等信息。以支付主体为第三方支付平台账号为例，其支付主体要素通常包括有：账号名、平台标识等信息。每个支付主体都对应有唯一的一组支付主体要素，换言之，一组支付主体要素可以确定唯一的一个支付主体。

在本实施例中，运行所述便于支付主体扩展的方法的服务器通常是电子支付服务提供商部署的用于存储支付主体的服务器。以电子支付服务提供商是支付宝为例，所述服务器用于存储支付宝用户在支付宝中绑定的银行卡、除支付宝以外的第三方支付平台账号等支付主体。

在本实施例中，服务器可以在接收到支付主体的注册请求时，确定所述支付主体的类型，其中，所述注册请求通常由用户发起。举例来说，假设用户想在支付宝中绑定一张自己新办理的信用卡，则用户可以通过支付宝客户端发起针对支付主体的注册请求(也就是绑定请求)。具体地，客户端可以将用户输入的这张信用卡的信息，即该信用卡的支付主体要素，携带在注册请求中发送给服务器。服务器在接收到所述注册请求后，保存所述该支付主体的各支付主体要素，然后可以根据所述支付主体要素确定所述支付主体的类型。当然，在实际实现中，依据相关技术，在支付主体的注册过程中，通常还需要执行面用户身份验证等操作，本申请在此不再一一赘述。

在本实施例中，所述支付主体的类型可以包括：全网通银行卡、储蓄存折、第三方支付平台账号等，可以由开发人员根据各支付主体的特点进行设置。在一个例子中，服务器可以先根据支付主体的大类标识确定所述支付主体所属的大类。其中，所述支付主体的大类可以由用户输入，举例来说，用户在绑定支付主体时，客户端可以提供支付主体的大类选项让用户选择，比如：客户端可以显示“绑定银行卡、储蓄存折”以及“绑定第三方支付平台账号”的选项给用户，用户可以根据支付主体的类型进行选择。客户端在发送注册请求给服务器时，可以将用户选择的大类标识作为所述支付主体的支付主体要素发送给服务器。服务器在确定支付主体类型时，可以先根据支付主体要素中的大类标识确定出所述支付主体的大类，然后再进行具体类型的确定。

举例来说，假设某支付主体的大类是银行卡、储蓄存折等金融机构发行的支付主体，则服务器可以进一步根据支付主体要素中卡号的位数、预设位的字符等信息识别所述支付主体是全网通银行卡还是储蓄存折，以确定所述支付主体的具体类型。

步骤102，查找所述类型对应的主键生成规则。

基于前述步骤101，在确定出支付主体的类型时，可以查找所述类型对应的主键生成规则。其中，所述主键生成规则可以由开发人员预先设置，用于为支付主体生成支付主键，通常包括有：用于生成支付主键的支付主体要素、生成算法等信息。一般而言，不同支付主体类型对应的主键生成规则中用于生成支付主键的支付主体要素不同。

在本实施例中，所述支付主键是对应支付主体的标识，一个支付主键能够确定唯一一个支付主体，所述支付主键可以理解为基于能够确定唯一一个支付主体的一组支付主体要素生成的密文，可以在电子支付过程中代替支付主体进行交互传输，从而确保用户支付主体的安全。

步骤103，根据所述主键生成规则为所述支付主体生成支付主键，并保存所述支付主体与其支付主键之间的对应关系。

在本实施例中，在保存所述支付主体与其支付主键之间的对应关系后，服务器可以向其他相关业务平台提供支付主键的请求、支付主体的查询等服务。

在一个例子中，在支付主体扩展时，比如：新增支付主体类型，或为支付主体新增的支付主体要素时，开发人员可以对主键生成规则进行更新，以实现对整个支付主体模型的更新。

举例来说，假设在处理以储蓄存折为支付主体的电子支付业务时，为确保在储蓄存折类型的支付主体中根据某一组支付主体要素能够确定唯一的一张储蓄存折，扩展了电子支付时用于确定储蓄存折的支付主体要素，在原有支付主体要素：存折账号、户名、开户银行的基础上，新增了开户日期，则开发人员可以根据新增的开户日期对所述主键生成规则进行更新，比如：在储蓄存折对应的主键生成规则中增加用于生成支付主键的支付主体要素：开户日期。服务器在所述主键生成规则更新后，可以根据新的主键生成规则为存储的各储蓄存折生成新的支付主键，然后无需删除旧的支付主键，保存所述储蓄存折与其新的支付主键的对应关系。这是因为，当所述主键生成规则更新前的电子支付业务出现退款、维权等情况时，基于该储蓄存折旧的支付主键仍可以查找到该储蓄存折，以便后续退款、维权业务的顺利开展。

由以上描述可以看出，在本申请提供的支付主键生成方案中，可以根据支付主体类型对应的主键生成规则为所述支付主体生成支付主键，当支付主体扩展时，比如：新增支付主体类型，或新增支付主体的支付主体要素时，更新所述主键生成规则即可，无需重新开发整个模型，大大降低了开发成本。

在本申请一个例子中，请参考图2，根据主键生成规则为支付主体生成支付主键的过程可以包括以下步骤：

步骤201，获取主键生成规则指定的支付主体要素作为主键生成要素。

在本实施例中，所述主键生成规则中指定有能够确定其对应支付主体类型中唯一一个支付主体的支付主体要素。举例来说，假设某主键生成规则对应的支付主体类型为全网通银行卡，即Visa、Mastercard等类型的银行卡，则该主键生成规则指定的支付主体要素通常包括有：卡号、户名、有效期。又假设，某主键生成规则对应的支付主体类型为储蓄存折，则该主键生成规则指定的支付主体要素通常包括有：存折账号、户名、开户银行。

在本实施例中，服务器可以在存储的所述支付主体的所有支付主体要素中，获取所述主键生成规则中指定的支付主体要素，为便于描述，可以将获取到的所述主键生成规则指定的支付主体要素称为主键生成要素。

步骤202，按照所述主键生成规则指定的顺序对所述主键生成要素进行排序。

在本实施例中，所述主键生成规则中还可以包括生成支付主键的各主键生成要素的排序，也就是在生成支付主键时，各主键生成要素的顺序。基于前述步骤201，在获取到各主键生成要素后，可以根据所述顺序对各主键生成要素进行排序。假设，所述主键生成要素包括有：存折账号(1234)、户名(张三)、开户银行(招商银行北京大运村支行)，所述主键生成规则指定的顺序为：户名、存折账号、开户银行，则可以将主键生成要素排序为：张三、1234、招商银行北京大运村支行。

步骤203，根据预设的算法计算排序后的主键生成要素的密文，以作为为所述支付主体生成的支付主键。

基于前述步骤202，在对所述主键生成要素进行排序后，可以根据预设的算法计算排序后的主键生成要素的密文，该密文就是为支付主体生成的支付主键。其中，所述预设的算法可以由开发人员设置，所述预设的算法可以包含在所述主键生成规则中，这样，不同主键生成规则采用的密文生成算法可以不同。开发人员也可以为所有主键生成规则设置一个相同的算法，并将这个算法存储在预设位置，这样，就无需在各主键生成规则中分别进行算法的设置。所述预设的算法可以为：MD5(Message-Digest Algorithm 5，信息-摘要算法5)，HASH算法等，本申请对此不作特殊限制。

由此可见，本申请提供的所述主键生成规则可以由如下公式表示：支付主键＝预设算法(主键生成要素1，主键生成要素2，…，主键生成要素N)，其中，N为大于等于1的自然数。

基于上述主键生成公式，当支付主体扩展时，比如：新增主键生成要素时，可以将新增的主键生成要素排列在最后，以此减少新增主键生成要素时的代码开发工作量。举例来说，以前述步骤103中银行对储蓄存折类型的支付主体新增开户日期为例，在此之前，储蓄存折类支付主体对应的主键生成规则为：支付主键＝预设算法(户名，存折账号，开户银行)，而更新后的主键生成规则为：支付主键＝预设算法(户名，存折账号，开户银行，开户日期)。

在本实施例中，参考上述主键生成公式，服务器也可以按照所述公式中指定的主键生成要素的顺序依次获取各主键生成要素，以此节省前述步骤202的排序操作，本申请对此不作特殊限制。

由以上描述可以看出，本申请提供的主键生成规则中指定有生成支付主键时各主键生成要素的排序信息，当支付主体扩展时，比如：新增主键生成要素时，可以将新增的主键生成要素排列在最后，以此减少新增主键生成要素时的代码开发工作量，从而节省开发成本。

在本申请另一个例子中，采用本申请提供的电子支付安全实现方法，可以提高风控平台对支付风险的识别判断效率。请参考图3，基于图1所示的实施例，风控平台和服务器的交互过程可以包括以下步骤：

步骤301，在接收到风控平台发送的携带有目标支付主键的主键查询请求后，查找所述目标支付主键对应的目标支付主体，并将所述目标支付主体的所有目标支付主体要素返回给所述风控平台。

在本实施例中，所述风控平台是指电子支付过程中用于进行风险评估的服务器或者服务器集群。风控平台在接收到电子支付的支付主键时，为进行风控，会将该支付主键发送给本申请中用于存储支付主体的服务器，以请求查询所述支付主键对应的支付主体。为便于描述，可以将风控平台发送给服务器的支付主键称为目标支付主键。

在本实施例中，服务器在接收到风控平台发送的主键查询请求后，可以查找目标支付主键对应的目标支付主体，然后将查找到的目标支付主体的所有目标支付主体要素返回给所述风控平台，而不仅限于生成支付主键的主键生成要素。

步骤302，在接收到所述风控平台发送的携带有风控要素的要素查询请求后，查找包括所述风控要素的支付主体列表，并将所述支付主体列表返回给所述风控平台，其中，所述风控要素是所有目标支付主体要素的子集。

基于前述步骤301，风控平台在接收到服务器返回的目标支付主体要素后，可以按照预设的策略在所述所有目标支付主体要素中选取一个或者多个目标支付主体要素作为风控要素。然后发送要素查询请求给服务器，所述要素查询请求中携带所述风控要素。服务器在接收到所述要素查询请求后，查找所有包括所述风控要素的支付主体，然后将所述支付主体列表返回给所述风控平台，其中，所述支付主体列表中包括所有支付主体的支付主体要素。风控平台可以根据所述支付主体列表对本次电子支付进行更加全面、准确的风险评估。

下面结合具体的例子来描述风险评估的过程。

请参考图4，以一个较为简单的电子支付场景为例，所述用户终端可以为智能手机、平板电脑、PC机等智能终端设备，所述用户终端中安装有具有电子支付功能的客户端软件。所述支付平台、风控平台、卡中心都是电子支付服务提供方部署的服务器或者服务器集群。其中，所述支付平台用于接收客户端发送的支付请求，并根据支付请求生成电子支付订单。所述卡中心用于存储用户绑定的支付主体。所述风控平台用于对用户发起的电子支付请求进行风险评估。

请继续参考图4，电子支付过程中的风控过程可以包括以下步骤：

(1)用户终端发送支付请求给支付平台。

以客户端软件为支付宝客户端为例，用户在支付宝客户端中发起一个支付请求，客户端会将本次支付请求的一些支付信息发送给支付平台，这些支付信息主要包括两类：支付主体要素和交易信息。以用户选择使用信用卡进行支付为例，所述支付主体要素通常包括：信用卡卡号、户名等。所述交易信息通常包括：支付金额、验证码等。

(2)支付平台发送主键生成请求给卡中心，所述主键生成请求中携带前述客户端发送的支付主体要素。

在本步骤中，支付平台将支付请求中携带的支付主体要素携带在主键生成请求中发送给卡中心，以请求卡中心为所述支付主体要素对应的支付主体生成用于后续交互的支付主键。

(3)卡中心向支付平台返回支付主体的支付主键。

在本步骤中，卡中心在接收到支付平台发送的支付主体要素后在存储在所有支付主体中查找匹配所述支付主体要素的支付主体，然后将该支付主体的支付主键返回给支付平台。其中，卡中心生成支付主键的过程可以参考前述图1或图2所示的实施例，本申请在此不再一一赘述。

(4)支付平台发送风控请求给风控平台。

支付平台在接收到卡中心返回的支付主键后，可以根据所述支付主键为用户发起的本次电子支付生成电子支付订单，然后将电子支付订单携带在风控请求中发送给风控平台。

(5)风控平台发送主键查询请求给卡中心。

风控平台在接收到针对电子支付订单的风控请求后，可以从电子支付订单中解析出支付主键，然后将支付主键发送给卡中心，以查询所述支付主键对应的支付主体。

(6)卡中心将支付主键对应的支付主体返回给风控平台。

卡中心在接收到风控中心发送的所述主键查询请求后，查询所述支付主键对应的支付主体，然后将查找到支付主体的所有支付主体要素返回给风控中心。

(7)风控平台发送风控要素查询请求给卡中心。

风控平台在接收到卡中心返回的所述支付主体的所有支付主体要素后，可以根据预设的策略在所述支付主体要素中选取一个或者多个支付主体要素作为风控要素。然后发送风控要素查询请求给卡中心，以查询卡中心存储的包括有所述风控要素的所有支付主体。

举例来说，假设前述步骤中卡中心返回的支付主键对应的支付主体要素中包括有：信用卡卡号、户名、有效期、开户行、用户身份证号、安全校验码。风控平台根据开发人员设置的策略选取用户身份证号作为风控要素，然后将用户身份证号携带在风控要素查询请求中再次发送给卡中心。

(8)卡中心将所有包括所述风控要素的支付主体列表返回给风控平台。

卡中心在接收到风控平台发送的携带有用户身份证号的风控要素查询请求后，可以查询支付主体要素中包括所述用户身份证号的所有支付主体，然后将所有支付主体的列表返回给风控中心。所述支付主体的列表中包括有各个支付主体的支付主体要素。

仍以前述步骤的举例为例，卡中心查询包括有上述支付主体要素(上述用户身份证号)的所有支付主体。假设，卡中心查找到两张银行卡的用户身份证号为上述身份证号，卡中心进而可以将这两张银行卡的支付主体要素均返回给风控平台。

(9)风控平台根据所述支付主体列表进行风险评估，并将风险评估的结果返回给支付平台。

风控平台在接收到所述支付主体列表后，可以根据支付主体列表中所有支付主体的历史业务参数对本次电子支付进行风险评估，并将评估结果返回给支付平台，当评估结果为安全时，支付平台可以继续完成本次电子支付过程。当评估结果为风险较大时，支付平台可以返回风险提示给客户端。

仍假设，卡中心根据用户身份证号查询到两张银行卡，风控平台在接收到这两张银行卡的信息(这两张银行卡的支付主体要素)后，可以根据这两张银行卡的历史交易数据对本次电子支付进行风险评估，进而可以查找到发起本次电子支付的用户在使用其他银行卡进行电子交易时是否存在违规操作等具有风险的行为，进而对本次电子支付进行更为全面、准确的风险评估。

由以上描述可以看出，基于本申请提供的支付主键生成方案，风控平台可以通过两次查询查找到可用于风险评估的支付主体列表，从而可以为电子支付提供更为全面、准确的风险评估，提高电子支付的安全性。

与前述便于支付主体扩展的方法的实施例相对应，本申请还提供了便于支付主体扩展的装置的实施例。

本申请便于支付主体扩展的装置的实施例可以应用在服务器上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在服务器的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图5所示，为本申请便于支付主体扩展的装置所在服务器的一种硬件结构图，除了图5所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的服务器通常根据该服务器的实际功能，还可以包括其他硬件，对此不再赘述。

图6是本申请一示例性实施例示出的一种便于支付主体扩展的装置的结构框图。

请参考图6，所述便于支付主体扩展的装置500可以应用在前述图5所示的服务器中，包括有：类型确定单元501、规则查找单元502、主键生成单元503、第一返回单元504、第二返回单元505、规则更新单元506以及规则保存单元507。其中，所述主键生成单元503还可以包括：要素获取子单元5031、要素排序子单元5032以及主键生成子单元5033。

其中，所述类型确定单元501，确定支付主体的类型；

所述规则查找单元502，查找所述类型对应的主键生成规则；

所述主键生成单元503，根据所述主键生成规则为所述支付主体生成支付主键，并保存所述支付主体与其支付主键之间的对应关系；

其中，所述主键生成规则中指定有用于生成支付主键的支付主体要素，不同支付主体类型对应的主键生成规则中用于生成支付主键的支付主体要素不同。

所述要素获取子单元5031，获取所述主键生成规则指定的支付主体要素，作为主键生成要素；

所述要素排序子单元5032，按照所述主键生成规则指定的顺序对所述主键生成要素进行排序；

所述主键生成子单元5033，根据预设的算法计算排序后的主键生成要素的密文，以作为为所述支付主体生成的支付主键。

所述第一返回单元504，在接收到风控平台发送的携带有目标支付主键的主键查询请求后，查找所述目标支付主键对应的目标支付主体，并将所述目标支付主体的所有目标支付主体要素返回给所述风控平台；

所述第二返回单元505，在接收到所述风控平台发送的携带有风控要素的要素查询请求后，查找包括所述风控要素的支付主体列表，并将所述支付主体列表返回给所述风控平台，其中，所述风控要素是所有目标支付主体要素的子集。

可选的，所述类型确定单元501，在接收到针对支付主体的注册请求时，确定支付主体的类型。

所述规则更新单元506，当所述主键生成规则更新时，根据更新后的主键生成规则重新为所述支付主体生成支付主键；

所述规则保存单元507，在保存所述支付主体与其原支付主键之间对应关系的基础上，保存所述支付主体与为其重新生成的支付主键之间的对应关系。

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

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

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

Claims (10)

1.一种便于支付主体扩展的方法，应用在服务器，其特征在于，所述方法包括：

确定支付主体的类型；

查找所述类型对应的主键生成规则；

根据所述主键生成规则为所述支付主体生成支付主键，并保存所述支付主体与其支付主键之间的对应关系；

其中，所述主键生成规则中指定有用于生成支付主键的支付主体要素，不同支付主体类型对应的主键生成规则中用于生成支付主键的支付主体要素不同。

2.根据权利要求1所述的方法，其特征在于，所述根据所述主键生成规则为所述支付主体生成支付主键，包括：

获取所述主键生成规则指定的支付主体要素，作为主键生成要素；

按照所述主键生成规则指定的顺序对所述主键生成要素进行排序；

根据预设的算法计算排序后的主键生成要素的密文，以作为为所述支付主体生成的支付主键。

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

在接收到风控平台发送的携带有目标支付主键的主键查询请求后，查找所述目标支付主键对应的目标支付主体，并将所述目标支付主体的所有目标支付主体要素返回给所述风控平台；

在接收到所述风控平台发送的携带有风控要素的要素查询请求后，查找包括所述风控要素的支付主体列表，并将所述支付主体列表返回给所述风控平台，其中，所述风控要素是所有目标支付主体要素的子集。

4.根据权利要求1所述的方法，其特征在于，所述确定支付主体的类型，包括：

在接收到针对支付主体的注册请求时，确定支付主体的类型。

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

当所述主键生成规则更新时，根据更新后的主键生成规则重新为所述支付主体生成支付主键；

在保存所述支付主体与其原支付主键之间对应关系的基础上，保存所述支付主体与为其重新生成的支付主键之间的对应关系。

6.一种便于支付主体扩展的装置，应用在服务器，其特征在于，所述装置包括：

类型确定单元，确定支付主体的类型；

规则查找单元，查找所述类型对应的主键生成规则；

主键生成单元，根据所述主键生成规则为所述支付主体生成支付主键，并保存所述支付主体与其支付主键之间的对应关系；

其中，所述主键生成规则中指定有用于生成支付主键的支付主体要素，不同支付主体类型对应的主键生成规则中用于生成支付主键的支付主体要素不同。

7.根据权利要求6所述的装置，其特征在于，所述主键生成单元包括：

要素获取子单元，获取所述主键生成规则指定的支付主体要素，作为主键生成要素；

要素排序子单元，按照所述主键生成规则指定的顺序对所述主键生成要素进行排序；

主键生成子单元，根据预设的算法计算排序后的主键生成要素的密文，以作为为所述支付主体生成的支付主键。

8.根据权利要求6所述的装置，其特征在于，所述装置还包括：

第一返回单元，在接收到风控平台发送的携带有目标支付主键的主键查询请求后，查找所述目标支付主键对应的目标支付主体，并将所述目标支付主体的所有目标支付主体要素返回给所述风控平台；

第二返回单元，在接收到所述风控平台发送的携带有风控要素的要素查询请求后，查找包括所述风控要素的支付主体列表，并将所述支付主体列表返回给所述风控平台，其中，所述风控要素是所有目标支付主体要素的子集。

9.根据权利要求6所述的装置，其特征在于，

所述类型确定单元，在接收到针对支付主体的注册请求时，确定支付主体的类型。

10.根据权利要求6所述的装置，其特征在于，所述装置还包括：

规则更新单元，当所述主键生成规则更新时，根据更新后的主键生成规则重新为所述支付主体生成支付主键；

规则保存单元，在保存所述支付主体与其原支付主键之间对应关系的基础上，保存所述支付主体与为其重新生成的支付主键之间的对应关系。