CN111489147A - 资格确认的方法、支付***和支付方法 - Google Patents

Abstract

本发明涉及资格确认方法、支付***以及支付方法，属于移动支付领域。资格确认方法包括：获取表示用户信息的数据；根据数据对用户进行等级评定；为不同等级的用户分配相应的垫付资格参数；以及在所需垫付资格参数满足垫付条件的情况下确认用户具有垫付资格。支付***包括：资格确认模块，其配置成获取表示用户信息的数据，根据数据对用户进行等级评定，为不同等级的所述用户分配相应的垫付资格参数，以及在所需垫付资格参数满足垫付条件的情况下确认用户具有垫付资格；以及垫付执行模块，其配置成根据用户是否具有垫付资格来确定是否为用户进行垫付。

Description

资格确认的方法、支付***和支付方法

技术领域

本发明属于移动支付领域，且具体涉及一种资格确认方法、支付***和支付方法。

背景技术

行业内现有移动支付产品，总体来说有以下三种方式。第一，控件支付方式，商户APP生成订单后，通过后台调用支付控件来完成支付。第二，二维码支付方式。第三，签约免密支付方式。签约免密支付模式下，当用户签约授权商户后，用户在进行消费时，支付客户端会进行自动扣款。

上述三种支付方式的后台扣款流程大体类似，当用户的支付账号的默认银行卡扣款失败时，需要用户手工选择需要其他银行卡进行支付，没有托底方案，严重影响用户体验。

即使是类似于***的在用户余额不足时进行垫付支付的方式，提供服务的平台一般也需要先对用户的信用进行评级以确定是否给用户提供支付的托底服务。现在的机构给用户进行分析时大多使用仅与该机构有关的非常有限的用户数据，例如用户的***数目、守信还款记录、资金流水等，容易造成分析结果的失真、偏差甚至误信虚假数据。

发明内容

因此，需要一种综合大量数据的资格确认方法、支付***和方法，以解决原有的数据来源单一、规模有限、缺乏全面性的问题，使得对用户分析评级更真实和准确。

为实现以上目的中的一个或多个，本发明提供以下技术方案。

按照本发明的第一方面，提供一种资格确认方法，其包括：获取表示用户信息的数据；根据数据对用户进行等级评定；为不同等级的用户分配相应的垫付资格参数；以及在所需垫付资格参数满足垫付条件的情况下确认用户具有垫付资格。

根据本发明一实施例的资格确认方法，其中在获取步骤中，还获取用于进行垫付管理的商户数据。

根据本发明一实施例或以上任一实施例的资格确认方法，其中，垫付资格参数包括下列项目中的一种或多种：年垫付次数、年垫付金额、单笔垫付金额和可用垫付金额。

根据本发明一实施例或以上任一实施例的资格确认方法，其还包括：利用数据中的下列参数中的一个或多个确定用户的等级：用户年龄、用户学历、毕业院校、所持卡等级、所在地区和失信情况以及历史交易记录。

根据本发明一实施例或以上任一实施例的资格确认方法，其中，通过使用大数据技术从用户相关联数据集合中获取表示用户信息的数据。

根据本发明一实施例或以上任一实施例的资格确认方法，其中，通过采用数据抽取方式和/或者数据推送方式获取表示用户信息的数据。

按照本发明的第二方面，提供一种支付***，其包括：资格确认模块，其配置成：获取表示用户信息的数据，根据数据对用户进行等级评定，为不同等级的用户分配相应的垫付资格参数，以及在所需垫付资格参数满足垫付条件的情况下确认用户具有垫付资格；以及垫付执行模块，其配置成根据用户是否具有垫付资格来确定是否为用户进行垫付。

根据本发明一实施例的支付***，其还包括：垫付流水记录模块，其配置成记录对用户进行的垫付的信息；以及还款流水记录模块，其配置成记录用户进行的还款的信息。

根据本发明一实施例或以上任一实施例的支付***，其中，垫付执行模块还配置成在用户具有垫付资格且待接受垫付的商户支持垫付的情况下为用户向商户进行垫付。

根据本发明一实施例或以上任一实施例的支付***，其中，垫付资格判断模块还配置成：获取用于进行垫付管理的商户数据。

根据本发明一实施例或以上任一实施例的支付***，其中，垫付资格参数包括下列项目中的一种或多种：年垫付次数、年垫付金额、单笔垫付金额和可用垫付金额。

根据本发明一实施例或以上任一实施例的支付***，其中，支付***还配置成：利用数据中的下列参数中的一个或多个来得到用户的等级：用户年龄、用户学历、毕业院校、所持卡等级、所在地区和失信情况以及历史交易记录。

根据本发明一实施例或以上任一实施例的支付***，其中，垫付资格判断模块还配置成：通过使用大数据技术从用户相关联数据集合中获取表示用户信息的数据。

根据本发明一实施例或以上任一实施例的支付***，其中，垫付资格判断模块还配置成：通过采用数据抽取方式和/或者数据推送方式获取表示用户信息的数据。

按照本发明的第三方面，提供一种支付方法，其包括：响应于用户订单的支付请求，获取用户的付款账户列表，向付款账户列表中的第一顺序的账户发起扣款请求，当第一顺序的账户支付失败时，向付款账户列表中的下一顺序的账户发起扣款请求；确认订单经由用户的付款账户列表中的所有账户支付失败；根据本发明第一方面的方法确认所述用户具有垫付资格；以及进行垫付。

根据本发明一实施例的支付方法，其还包括在进行垫付前确认商户是否支持垫付。

根据本发明一实施例或以上任一实施例的支付方法，其还包括执行签约以获得令牌从而生成支付请求，签约包括下列步骤：从商户接收响应于用户请求的签约请求；将用户ID发送给TSP以获取来自TSP的与用户ID对应的令牌，并后续地将令牌发送给商户以用于生成支付请求。

与现有技术相比，本发明实现了利用大数据技术对用户进行等级评定，以作为进行垫付的依据之一。在无需人工干预的情况下，在获取了用户账户列表后，当***发现交易失败时可以在账户列表中进行依次扣款，而无需用户手动选卡。另外，还通过垫付使得用户支付的成功率提升，增强了用户体验。

附图说明

本发明的上述和/或其它方面和优点将通过以下结合附图的各个方面的描述变得更加清晰和更容易理解，附图中相同或相似的单元采用相同的标号表示。在所述附图中：

图1为根据本发明的实施例的签约过程的示意性流程图；

图2为根据本发明的实施例的通过垫付进行支付的方法的示意性流程图；

图3为根据本发明的实施例的支付方法的流程图；

图4为根据本发明的实施例的资格确认的方法的示例流程图；以及

图5为根据本发明的实施例的判断是否满足垫付条件的方法的示例流程图。

具体实施方式

在本说明书中，参照其中图示了本发明示意性实施例的附图更为全面地说明本发明。但本发明可以按不同形式来实现，而不应解读为仅限于本文给出的各实施例。给出的各实施例旨在使本文的公开全面完整，以将本发明的保护范围更为全面地传达给本领域技术人员。

诸如“包含”和“包括”之类的用语表示除了具有在说明书中有直接和明确表述的单元和步骤以外，本发明的技术方案也不排除具有未被直接或明确表述的其它单元和步骤的情形。诸如“第一”和“第二”之类的用语并不表示单元在时间、空间、大小等方面的顺序而仅仅是作区分各单元之用。

下文参考根据本发明实施例的装置和设备的框图来描述本发明。

图1为根据本发明的实施例的签约过程的示意性流程图，以及图2为根据本发明的实施例的通过垫付进行支付的方法的示意性流程图。

如图2所示，本发明的通过垫付进行支付的方法涉及商户（例如：线下商户如超市、便利店等，线上商户如外卖APP、购物APP等）、支付客户端、支付平台、用户***、TSP（TokenService Provider令牌服务提供方）和垫付平台。

本发明的通过垫付进行支付的方法可以首先可选地包括签约过程。

签约过程是用户为了在商户处使用垫付支付功能而和商户、支付平台进行三方签约的流程。如图1所示，在一个实施例中，签约过程如以下所描述的来进行。在步骤S101中当用户120在商户110的页面中点击确认开通“签约代扣”按钮后，商户110将在步骤S102中调用支付客户端130的支付签约API（Application Programming Interface应用编程接口）向支付客户端130发起签约请求（即图2中的S201）。接下来当支付客户端130收到商户110发起的签约请求后，支付客户端130会通过一定的方式（例如，将用户ID进行加密后再发送等）向TSP发送该支付客户端130的用户ID（图2中的步骤S202）。在TSP在收到支付客户端发送的用户ID后，TSP会执行如图2中所示的步骤S203，即根据收到的用户ID来生成令牌（签约号）。在后续步骤S204中，TSP将生成的令牌发送至支付客户端130，支付客户端130再将从TSP处接收到的令牌发送给商户110（如图1中所示的步骤S105）。商户110在接收到令牌后，将该令牌储存在商户110的储存模块，以便后续使用。

在一个实施例中，还存在支付客户端130与用户120之间进行的交互S103和S104。具体地，在步骤S102之后，支付客户端向用户显示代扣签约页面，用户进行确认并将确认消息返回给支付客户端，然后进行步骤S105。上述用户的确认消息可以是诸如输入支付密码等操作。

现在转到图2，在一个实施例中，在签约成功之后的任意时刻，商户在步骤S205中发送令牌至支付平台以发起支付请求。在接下来的步骤S206中，支付平台将接收到的令牌发送至TSP，以用于TSP在后续步骤S207中对令牌进行解析。然后TSP在步骤S208中将解析得到的用户ID信息以及商户是否支持垫付的信息发送返回至支付平台。在步骤S209中，支付平台将收到的用户ID发送至用户***，以供用户***在步骤S210查询对应于收到的用户ID的卡列表，并在后续步骤S211中将查询得到的卡列表返回给支付平台。紧接着，支付平台在步骤S212根据接收到的卡列表创建订单并同步返回商户支付请求受理成功。

接下来，扣款流程S213处开始。接着，支付平台执行步骤S214，即对在步骤S211中返回的卡列表中的卡依次进行扣款，并轮询扣款结果，如果扣款成功则终止扣款流程，扣款不成功则继续对下一张卡进行扣款。按照步骤S220，如果支付平台对卡列表中所有卡均扣款失败，跳转至S221。如果扣款成功，则跳转至S227，扣款流程结束。通过此循环扣款操作，可以在获取了用户账户列表后，在无需人工干预的情况下，当***发现交易失败时对账户列表中的账户进行依次扣款，而无需用户手动选卡。

在一个实施例中，在上述步骤S221之前，支付平台还根据商户对垫付的支持性信息来进行初步判断。如果商户不支持垫付，则跳转至S227，扣款流程结束。如果商户支持垫付，则进行S221以及之后的过程。判断商户是否支持垫付的步骤并不一定在S221之前，也可以在S221之后，在步骤S224为用户进行垫付之前即可。

在步骤S221中，支付平台向垫付平台查询用户是否具有垫付资格。在后续步骤S222中，垫付平台将用户是否具有垫付资格的信息返回至支付平台。关于步骤S221与步骤S222之间进行的垫付平台对用户是否具有垫付资格进行的判断将在下文中进一步描述。根据垫付平台返回的关于用户是否具有垫付资格的信息，如果用户有垫付资格则继续进行S224，为用户进行垫付；并且在步骤225中将垫付流水发送至垫付平台然后跳转至步骤S227，扣款流程结束。如果用户没有垫付资格，跳转至S227，扣款流程结束。所述垫付流水由垫付平台在步骤S227中进行存储，以供后续使用。

在一个实施例中，在扣款流程结束后，支付平台还执行步骤S250以发送交易结果至商户。如果垫付成功，支付平台还可以执行步骤S251，发送还款通知至支付客户端供客户查看。在一个实施例中，用户可以在步骤S252中通过支付平台进行还款，在接收到还款信息后，支付平台将在步骤S253中将接收到的该还款信息生成还款流水并发送至垫付平台。在一个实施例中，在后续步骤S254中垫付平台将接收到的还款流水记录至垫付平台的本地存储模块中。

在另一个实施例中，商户可以在任意时刻执行步骤S255以向支付平台请求查询签约支付的历史交易结果。在接下来的步骤S256中，支付平台会根据收到查询请求提供查询服务，并将该请求商户的签约支付的历史交易结果返还至商户。

根据本发明的第三方面，提供了一种支付方法300。图3为根据本发明的实施例的支付方法300的流程图。

在步骤310中，响应于用户订单的支付请求，获取所述用户的付款账户列表，向所述付款账户列表中的第一顺序的账户发起扣款请求。当第一顺序的账户支付失败时，向付款账户列表中的下一顺序的账户发起扣款请求。通过此循环扣款操作，可以在获取了用户账户列表后，在无需人工干预的情况下，当***发现交易失败时对账户列表中的账户进行依次扣款，而无需用户手动选卡。

在一种情况下，在步骤320中，确认订单经由用户的付款账户列表中的所有账户支付失败。那么在步骤330中，根据本发明的第一方面所述的方法确认所述订单满足垫付条件。如果订单用户满足垫付条件，则最终在步骤340中进行垫付。

在一个实施例中，在于步骤340进行垫付之前还确认所述商户是否支持垫付。该步骤根据所获取的商户支持性信息来进行。此时，只有在商户接受垫付的情况下，才能完成垫付的操作。

在另一个实施例中，支付方法300还包括执行签约以获得令牌从而生成支付请求。该签约可以采取如以上关于图1和图2的一部分所描述的签约过程，也可以使用行业内公知的任何一种签约过程。例如，签约可以包括下列步骤：从商户接收响应于用户请求的签约请求；将用户ID发送给TSP以获取来自TSP的与用户ID对应的令牌，并后续地将令牌发送给所述商户以用于生成支付请求。

在又一个实施例中，还可以向用户提供查询垫付记录的功能。如果有必要，还可以给每一条垫付记录附上相关的图片（例如：垫付停车费时，可以附上用户进出停车场的照片）。

图4为根据本发明的实施例的资格确认的方法的示例流程图，以及图5为根据本发明的实施例的判断是否满足垫付条件的方法的示例流程图。其具体说明了图2的S221与S222之间在支付平台发生的操作。

根据本发明的一个方面的资格确认的方法包括以下所述的操作。参考图4，在步骤S410中，使用大数据技术从用户相关联数据集合中获取（例如，通过数据抽取方式和/或者数据推送方式获取）表示用户信息的数据。其中，术语“大数据”如本领域技术人员所知的那样表示巨量数据集合，其具有大量、高速、多样、低价值密度和真实性的特点；而大数据技术是由于大数据的特点导致的处理大数据所通常使用的技术。如上所述的数据抽取表示从数据库中抽取数据的过程，该抽取操作可以根据***作数据库的不同类而不同。例如，对于关系数据库可以采取全量抽取和/或增量抽取的方式；以及对于非关系数据库中的文件数据通常采用全量抽取方式。如上所述的数据推送表示通过特定的推送体系（例如，JavaScript中的Promise推送体系）对数据进行传递，与抽取方式相对地，推送方式是推送体系主动提供数据，而不是完全由用户决定何时请求数据。在以上的用户相关联数据集合中存储有与用户相关联的数据，例如，可以是对应该用户的交易数据，用户相关联数据集合中还可以包括用于进行垫付管理的商户数据，例如对应该用户的交易数据中的商户数据，商户数据可以反映商户对于垫付的要求诉求信息并可以用来进行垫付管理。

需要说明的是，用户相关联数据集合（例如交易数据）可以分布或存储在一个***或装置中、或在多个***或装置中，也可以分布或存储在云端；当然商户数据也可以分布或存储在一个***或装置中、或在多个***或装置中，也可以分布或存储在云端。

在一个实施例中，所述数据包括：用户年龄、用户学历、毕业院校、所持卡等级、所在地区和失信情况中的一个或多个以及历史交易记录。在步骤S420中，在一个实施例中，垫付平台对获取的用户的数据进行分析（可以不仅仅是需要垫付的用户）。在步骤S430中，为用户进行打分同时确定用户等级，并为不同等级的所述用户分配相应的垫付资格参数。在步骤S440中，根据分配给用户的垫付资格参数来确认用户的垫付资格，具体如图5中所示出的那样。

在图5中，根据分配给用户的垫付资格参数以及垫付条件来判断用户是否具有垫付资格。如图5中所示，在一个实施例中，当用户通过控件支付、二维码支付和签约免密支付中的一种或多种支付失败（S501）时，垫付平台确认用户的垫付资格。在S502中，根据用户的评分得到其需要满足的条件（不同的用户评分会对应着不同的单次垫付金额上限、年垫付金额上限和年垫付次数上限），在用户评分达到一定阈值（例如，图5中所示的60分）的情况下才能继续步骤S503，否则垫付失败。在S503中，判断本次支付的金额是否超过单次的垫付金额上限。在S504中，判断用户的年垫付金额是否达到上限。在S505中，判断用户的年垫付次数是否达到上限。在S503-S505中的判断结果均为否时，则用户满足垫付条件，（可选地，在商户也接受垫付的情况下）垫付成功，否则垫付失败。在一个实施例中，如果用户将垫付款还清后，垫付平台可以增加该用户当年的垫付金额上限和垫付次数。

在一实施例中，可以根据用户需要办理的不同业务、用户已经使用垫付的情况（诸如，已使用垫付的次数、金额等）以及对应于该用户等级的垫付资格参数来判断该等级的用户是否满足垫付条件并具有垫付资格。上文所述的垫付条件在一个实施例中具体为：当一用户需要进行一次垫付时，其在该年度已经进行的垫付次数未达到其年垫付次数、该年度已经进行的垫付总额未达到年垫付金额、此次垫付的金额不超过其等级所对应的单笔垫付金额并且不超过其可用垫付金额（可用垫付金额=年垫付金额-已经醒的垫付总额）。例如，一位用户已经被评定为A级用户，其年垫付次数为3次、年垫付金额为1000元以及单笔垫付金额为500元。并且假设该用户已经在本年度进行过一次金额为300元的垫付，即该用户的可用垫付金额为700元。在判断过程中，例如，对于需要一次性垫付800元的业务，由于该业务的单笔垫付额度超过了评级为A的用户所享受的单笔垫付额度以及用户的可用垫付金额，所以该用户不满足垫付条件，不具有垫付资格。

需要说明的是，垫付条件是包含垫付相关参数的阈值信息，其可以管理方预先地设置好，例如，为不同等级的用户设置相应垫付条件（例如分别不同的阈值）；垫付相关参数例如可以但不限于包括笔垫付额度、预定时间段的垫付次数等，将理解，更加交易安全需要，管理方预先地定义各种垫付条件。

由于用户的消费能力是一个动态变化的过程，所以分数也会动态变化。在垫付资格参数满足垫付条件的情况下判断所述用户具有垫付资格。

在一个实施例中，从用户相关联数据集合中获取的数据可以包括商户数据、***/服务器数据、持卡人数据等的一种或多种。

在一个实施例中，垫付资格参数包括年垫付次数、年垫付金额、单笔垫付金额和可用垫付金额中的一种或多种。相应地，在一个实施例中，针对某一次的用户订单的垫付条件为：用户本年进行垫付的次数和金额总和分别不超过年垫付次数和年垫付金额，以及此次垫付的金额不超过单笔垫付金额和可用垫付金额。

具体地，为用户进行打分和评级的过程可以如以下所描述的那样执行。首先，该垫付平台的数据整合模块向用户相关联数据***发起数据查询请求。用户相关联数据***在收到数据整合模块的数据查询请求后，会将相关数据发送或拷贝至所述数据整合模块。接下来，数据整合模块对用户相关联数据***发来的数据进行处理以生成用户历史交易信息和用户个人信息。用户的一条历史交易信息包括但不限于：用户ID、交易金额、交易地点、交易时间、交易是否成功。数据生成模块将生成的用户历史交易信息和用户个人信息发送至数据分析模块。

当然，由于消费是动态的过程，所以用户评级也会动态变化，即S级的用户有可能被降至任意等级例如C级，C级用户也有可能被升至任意等级例如S级。

数据分析模块还可以通过机器学习算法来生成各商圈的维度，即生成各商圈以及商圈中的商户对用户的吸引力指标，该吸引力指标可以但不限于为城市商圈建设提供数据支撑。

提供本文中提出的实施例和示例，以便最好地说明按照本技术及其特定应用的实施例，并且由此使本领域的技术人员能够实施和使用本发明。但是，本领域的技术人员将会知道，仅为了便于说明和举例而提供以上描述和示例。所提出的描述不是意在涵盖本发明的各个方面或者将本发明局限于所公开的精确形式。

Claims (17)

1.一种资格确认方法，其特征在于，其包括：

获取表示用户信息的数据；

根据所述数据对所述用户进行等级评定；

为不同等级的所述用户分配相应的垫付资格参数；以及

在所需垫付资格参数满足垫付条件的情况下确认所述用户具有垫付资格。

2.根据权利要求1所述的资格确认方法，其特征在于，在获取步骤中，还获取用于进行垫付管理的商户数据。

3.根据权利要求1所述的资格确认方法，其特征在于，所述垫付资格参数包括下列项目中的一种或多种：年垫付次数、年垫付金额、单笔垫付金额和可用垫付金额。

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

利用所述数据中的下列参数中的一个或多个确定所述用户的所述等级：用户年龄、用户学历、毕业院校、所持卡等级、所在地区和失信情况以及历史交易记录。

5.根据权利要求1所述的资格确认方法，其特征在于，通过使用大数据技术从用户相关联数据集合中获取所述表示用户信息的数据。

6.根据权利要求4所述的资格确认方法，其特征在于，通过采用数据抽取方式和/或者数据推送方式获取所述表示用户信息的数据。

7.一种支付***，其特征在于，其包括：

资格确认模块，其配置成：

获取表示用户信息的数据，

根据所述数据对所述用户进行等级评定，

为不同等级的所述用户分配相应的垫付资格参数，以及

在所需垫付资格参数满足垫付条件的情况下确认所述用户具有垫付资格；以及

垫付执行模块，其配置成根据所述用户是否具有垫付资格来确定是否为所述用户进行垫付。

8.根据权利要求7所述的支付***，其特征在于，还包括：

垫付流水记录模块，其配置成记录对所述用户进行的垫付的信息；以及

还款流水记录模块，其配置成记录所述用户进行的还款的信息。

9.根据权利要求7或8所述的支付***，其特征在于，所述垫付执行模块还配置成在所述用户具有垫付资格且待接受垫付的商户支持垫付的情况下为所述用户向所述商户进行垫付。

10.根据权利要求9所述的支付***，其特征在于，所述垫付资格判断模块还配置成：获取用于进行垫付管理的商户数据。

11.根据权利要求9所述的支付***，其特征在于，所述垫付资格参数包括下列项目中的一种或多种：年垫付次数、年垫付金额、单笔垫付金额和可用垫付金额。

12.根据权利要求10或11所述的支付***，其特征在于，所述支付***还配置成：

利用所述数据中的下列参数中的一个或多个来得到所述用户的所述等级：用户年龄、用户学历、毕业院校、所持卡等级、所在地区和失信情况以及历史交易记录。

13.根据权利要求12所述的支付***，其特征在于，所述垫付资格判断模块还配置成：通过使用大数据技术从用户相关联数据集合中获取所述表示用户信息的数据。

14.根据权利要求13所述的支付***，其特征在于，所述垫付资格判断模块还配置成：通过采用数据抽取方式和/或者数据推送方式获取所述表示用户信息的数据。

15.一种支付方法，其特征在于，包括：

响应于用户订单的支付请求，获取所述用户的付款账户列表，向所述付款账户列表中的第一顺序的账户发起扣款请求，当所述第一顺序的账户支付失败时，向所述付款账户列表中的下一顺序的账户发起扣款请求；

确认所述订单经由所述用户的所述付款账户列表中的所有账户支付失败；

根据权利要求1-6所述的方法确认所述用户具有垫付资格；以及

进行所述垫付。

16.根据权利要求15所述的支付方法，其特征在于，还包括在进行所述垫付前确认商户是否支持垫付。

17.根据权利要求15所述的支付方法，其特征在于，还包括执行签约以获得令牌从而生成所述支付请求，所述签约包括下列步骤：

从商户接收响应于用户请求的签约请求；

将用户ID发送给TSP以获取来自所述TSP的与所述用户ID对应的所述令牌，并后续地将所述令牌发送给所述商户以用于生成所述支付请求。

Images