信用支付处理方法、装置、介质及电子设备与流程

文档序号:17607195发布日期:2019-05-07 20:49阅读:137来源:国知局
信用支付处理方法、装置、介质及电子设备与流程

本公开涉及信息技术领域,具体而言,涉及一种信用支付处理方法、装置、介质及电子设备。



背景技术:

随着互联网的快速发展,互联网信用支付处理也已成为一种趋势。但是,目前在投保流程中,往往存在一个问题:线上资金支付功能紧密结合业务,资金支付的结果直接决定出单,也就是出单条件会受到支付结果的影响,但是由于一些环境限制等因素导致用户无法完成支付,也就无法出单,支付模块对业务影响日渐明显,也逐渐影响用户体验,导致线上高信用低风险用户群体的保费规模受影响。

出现上述引起用户流失、体验不佳的主要分原因是随着社会各类信用体系的建设与完善,传统的资金支付已经不能完全满足互联网+保险的用户需求。

因此,现有技术中的技术方案中还存在有待改进之处。

需要说明的是,在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解,因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。



技术实现要素:

本公开实施例的目的在于提供一种信用支付处理方法、装置、介质及电子设备,进而至少在一定程度上克服现有的访问机制安全性差的缺点。

本公开的其他特性和优点将通过下面的详细描述变得显然,或部分地通过本公开的实践而习得。

根据本公开实施例的第一方面,提供了一种信用支付处理方法,包括:

对保险产品的支付情况进行检测,得到未完成支付的订单;

针对所述未完成支付的订单获取用户的信用评分;

将所述信用评分与预设分值进行比较,并根据比较结果决定是否承保出单。

在本公开的一种示例性实施例中,所述保险产品为具有等待期或观察期,且已经通过核保的保险产品。

在本公开的一种示例性实施例中,所述获取用户的信用评分,包括:

根据评分因子中的至少一项或多项构建信用评分模型,其所述评分因子包括:黑名单、第三方信用体系、区块链风控、大数据风控和行为分析;

基于所述未完成支付的订单提取到与所述未完成支付的订单所关联的用户基本信息;

将所述用户基本信息输入到所述信用评分模型中,得到信用评分。

在本公开的一种示例性实施例中,所述根据评分因子中的至少一项或多项构建信用评分模型,包括:

针对所述评分因子中的至少一项或多项分别进行信用评价,得到的信用分为第一数值或第二数值,其中所述第一数值和所述第二数值用于表示每一项评分因子中两种不同的评价结果;

根据对所述黑名单、所述第三方信用体系、所述区块链风控、所述大数据风控和所述行为分析中的至少一种信用分或者至少两种的信用分进行求和,得到所述信用评分模型。

在本公开的一种示例性实施例中,所述根据评分因中的至少一项或多项子构建信用评分模型,包括:

针对所述评分因子中的至少一项或多项分别进行信用评价,得到的信用分为第一数值或第二数值,其中所述第一数值和所述第二数值用于表示每一项评分因子中两种不同的评价结果;

设置所述黑名单、所述第三方信用体系、所述区块链风控、所述大数据风控和所述行为分析中的至少两种评分因子的权重系数;

按照所述至少两种评分因子的信用分和对应的权重系数的乘积进行求和,得到所述信用评分模型。

在本公开的一种示例性实施例中,将所述信用评分与预设分值进行比较,并根据比较结果决定是否承保出单,包括:

如果所述比较结果为所述信用评分大于或等于所述预设分值,则确定支付宽限期;

如果所述支付宽限期不晚于所述保险产品的等待期或观察期,则承保出单成功,得到保单;

如果所述支付宽限期晚于所述保险产品的等待期或观察期,则承保出单失败。

在本公开的一种示例性实施例中,如果所述支付宽限期不晚于所述保险产品的等待期或观察期,还包括:

生成催缴计划,所述催缴计划用于提醒用户在规定日期前进行缴费;

如果用户在所述规定日期前完成缴费,则所述保单生效;

如果用户在所述规定日期前未完成缴费,则所述保单失效。

根据本公开的第二方面,提供一种信用支付处理装置,包括:

检测模块,用于对保险产品的支付情况进行检测,得到未完成支付的订单;

评分模块,用于针对所述未完成支付的订单获取用户的信用评分;

出单模块,用于将所述信用评分与预设分值进行比较,并根据比较结果决定是否承保出单。

根据本公开实施例的第三方面,提供一种计算机可读介质,其上存储有计算机程序,所述程序被处理器执行时实现以上所述的信用支付处理方法的步骤。

根据本公开实施例的第四方面,提供一种电子设备,包括:

一个或多个处理器;

存储装置,用于存储一个或多个程序,当所述一个或多个程序被所述一个或多个处理器执行时,使得所述一个或多个处理器实现以上所述的信用支付处理方法。

本公开实施例提供的技术方案可以包括以下有益效果:

在本公开的一些实施例所提供的技术方案中,一方面,在投保过程中,如果用户用资金支付失败,则根据对用户的信用评分进行判断,如果信用评分能够通过,则执行非必要性资金支付流程,完成承保出单,对于信用评分较高的用户可以减少等待时间,提升用户体验。另一方面,通过跨平台甚至跨行业获取用户的信用评分,降低理赔风险,提高保险企业收益。

应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本公开的实施例,并与说明书一起用于解释本公开的原理。显而易见地,下面描述中的附图仅仅是本公开的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。在附图中:

图1示出根据本公开的实施例的一种信用支付处理方法的流程示意图;

图2示出根据本公开的实施例图1中步骤s102的流程示意图;

图3示出本公开实施例中用于实现上述信用支付处理方法的架构图;

图4示出了根据本公开的实施例的信用支付处理装置的结构示意图;

图5示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而,示例实施方式能够以多种形式实施,且不应被理解为限于在此阐述的范例;相反,提供这些实施方式使得本公开将更加全面和完整,并将示例实施方式的构思全面地传达给本领域的技术人员。

此外,所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中,提供许多具体细节从而给出对本公开的实施例的充分理解。然而,本领域技术人员将意识到,可以实践本公开的技术方案而没有特定细节中的一个或更多,或者可以采用其它的方法、组元、装置、步骤等。在其它情况下,不详细示出或描述公知方法、装置、实现或者操作以避免模糊本公开的各方面。

附图中所示的方框图仅仅是功能实体,不一定必须与物理上独立的实体相对应。即,可以采用软件形式来实现这些功能实体,或在一个或多个硬件模块或集成电路中实现这些功能实体,或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明,不是必须包括所有的内容和操作/步骤,也不是必须按所描述的顺序执行。例如,有的操作/步骤还可以分解,而有的操作/步骤可以合并或部分合并,因此实际执行的顺序有可能根据实际情况改变。

为此,本公开提供一种信用支付处理方法、装置、介质及电子设备,以解决上述问题,下面对本公开的技术方案做具体介绍。

图1示出了根据本公开的实施例的一种信用支付处理方法的流程示意图,参考图1,该信用支付处理方法包括:

步骤s101,对保险产品的支付情况进行检测,得到未完成支付的订单。

步骤s102,针对所述未完成支付的订单获取用户的信用评分。

步骤s103,将所述信用评分与预设分值进行比较,并根据比较结果决定是否承保出单。

在图1所示实施例所提供的技术方案中,一方面,在投保过程中,如果用户用资金支付失败,则根据对用户的信用评分进行判断,如果信用评分能够通过,则执行非必要性资金支付流程,完成承保出单,对于信用评分较高的用户可以减少等待时间,提升用户体验。另一方面,通过跨平台甚至跨行业获取用户的信用评分,降低理赔风险,提高保险企业收益。

以下对图1所示实施例的各个步骤的具体实现进行详细阐述:

在步骤s101中,对保险产品的支付情况进行检测,得到未完成支付的订单。

在本公开的一种示例性实施例中,该步骤中的所述保险产品为具有等待期或观察期,且已经通过核保的保险产品。需要说明的是,这里的保险产品即使是根据其他因素来设置等待期的长短,则该保险产品也归属到有等待期的产品。

在本公开的一种示例性实施例中,对于有等待期/观察期的保险产品,在核保通过后,如果用户支付保费环节因各类原因(如卡类余额不足、短暂冻结等)不能完成资金支付情况下的订单,就属于该步骤中未完成支付的订单。

在步骤s102中,针对所述未完成支付的订单获取用户的信用评分。

在本公开的一种示例性实施例中,该步骤中针对未完成支付的订单可以调用用户信用评分体系或信用评分模型等对未完成支付的用户的信用评分进行评价,确认该用户的信用评分或信用等级的评价结果。

需要说明的是,接下来以信用评分模型为例对获取用户的信用评分的过程进行介绍,但是在本公开其他实施例中不限于该模型。

图2示出图1的步骤s102中获取用户的信用评分的流程示意图,具体包括以下步骤:

步骤s201,根据评分因子中的至少一项或多项构建信用评分模型,其所述评分因子包括:黑名单、第三方信用体系、区块链风控、大数据风控和行为分析。

在本公开的一种示例性实施例中,以下对各项评分因子的作用和数据来源进行介绍:

1)黑名单,该黑名单可以仅包括保险企业公司内部的黑名单,还可以包括其他保险机构或银行机构的黑名单,只要存在于这些重点关注的企业或机构的黑名单中,则也将该用户列入黑名单中,

2)第三方信用体系,由于个人信用评分是信用服务中介机构使用专门设计的数学模型,根据个人信用报告所记录的内容,对个人信用能力进行评估、测算,给出一个人的风险分数。个人信用评分越高,个人的信用度越高。个人信用评分所采用的数学模型选用与个人信用相关的四十多个变量,概括起来可分为个人基本信息、银行信用信息、个人缴费信息、个人资本状况四类变量,其中,银行信用信息所占权重最大,接近50%,其余三类变量所占权重大致相当,即分别在17%左右。

3)区块链风控,区块链技术可以帮助收集并存储风险控制所需的信息,而且信息一经存储便永久记录并无法篡改。这样就可以最大程度地精确了解谁在何时做了什么(比如出现偷税漏税、欠款久拖不还等失信行为),及时发现各种形式的不当行为,并可对当前个人风险管理及风险评分。

4)大数据风控,一方面,可以通过线下定性指标,如家庭构成、社交圈、生活消费等,判断个人投保意愿。另一方面,通过线上征信的定量指标,如借款企业的交易流水、与上下游的交易合同、企业完税情况、现金储备、资产价值、股东实力、企业实际控制人个人征信报告等,判断个人是否具缴保费能力。

5)行为分析,这里的行为分析主要是用户对投保关注情况,例如在获得网站访问量基本数据的情况下,对有关数据进行统计、分析,从中发现用户访问网站的规律,并将这些规律与网络营销策略等相结合,从而判断当前客户对产品的关注程度。如,根据用户停留在某一个或某几个保险产品网页的时间较短(3秒之内),说明该用户对保险产品的关注度不高,相反,如果用户停留在某一个或某几个保险产品网页的时间很长(15秒以上),说明该用户对保险产品的关注度较高。

基于上述,该步骤在构建信用评分模型过程中,需要考虑多个平台以及多个领域的信息作为评分因子,以便对用户的信用评分做更加全面的评价。其中,这些评分因子中所涉及的范围不仅涉及保险企业内部的信息,还会涉及不同领域的信息(如信用评价、风控评价、行为分析等),还会涉及不同技术手段(如大数据和区块链)等等。评分因子越多,所涉及的行业和领域越多,则得到的信用评分模型的可靠性更高。

在本公开的一种示例性实施例中,根据评分因子中的至少一项或多项构建信用评分模型包括:

针对所述评分因子中的至少一项或多项分别进行信用评价,得到的信用分为第一数值或第二数值,其中所述第一数值和所述第二数值用于表示每一项评分因子中两种不同的评价结果;根据对所述黑名单、所述第三方信用体系、所述区块链风控、所述大数据风控和所述行为分析中的至少一种信用分或者至少两种的信用分进行求和,得到所述信用评分模型;或者

针对所述评分因子中的至少一项或多项分别进行信用评价,得到的信用分为第一数值或第二数值,其中所述第一数值和所述第二数值用于表示每一项评分因子中两种不同的评价结果;设置所述黑名单、所述第三方信用体系、所述区块链风控、所述大数据风控和所述行为分析中的至少两种评分因子的权重系数;按照所述至少两种评分因子的信用分和对应的权重系数的乘积进行求和,得到所述信用评分模型。

其中信用分的第一数值和第二数值可以分别用0和1进行标记,还可以用0和5进行标记,或者0和10进行标记,而且在不同的评分因子中标记的最大分值可以相同或不同,在此不做限制。如果不同的评分因子中标记的最大分值不同,则在进行求和计算之前还需要将不同的分值做归一化处理,使不同的评分因子都具有相同的评分基准。

步骤s202,基于所述未完成支付的订单提取到与所述未完成支付的订单所关联的用户基本信息。

在本公开的一种示例性实施例中,对于未完成支付的订单,需要从中提取出相关的用户基本信息,如,用户的姓名、证件号、手机号等信息。

步骤s203,将所述用户基本信息输入到所述信用评分模型中,得到信用评分。

在本公开的一种示例性实施例中,基于用户基本信息查询该用户在各个评分因子中的信用评分,然后根据信用评分模型中预设的计算规则进行评分计算,得到该用户的信用评分。

以下为步骤s203的第一种实施方案,具体包括,可采用下述至少一种方案获得用户的信用分:

1)针对所述黑名单,当用户在所述黑名单中时,信用分记为0;当用户不在所述黑名单中时,信用分记为1;

2)针对所述第三方信用体系,当用户在所述第三方信用体系中风险分数大于或等于第一阈值时,信用分记为1;当用户在所述第三方信用体系中风险分数小于所述第一阈值时,信用分记为0;

3)针对所述区块链风控,当用户在所述区块链风控中有不良记录时,信用分记为0;当用户在所述区块链风控中没有不良记录时,信用分记为1;

4)针对所述大数据风控,根据线上和线下的财务、消费、征信情况进行综合评价,当用户在所述大数据风控中有不良记录时,信用分记为0;当用户在所述大数据风控中没有不良记录时,信用分记为1;

5)针对所述行为分析,当用户对所述保险产品的关注度低于第二阈值时,信用分记为0;当用户对所述保险产品的关注度等于或高于所述第二阈值时,信用分记为1。

在一种示例中,可以根据所述黑名单、所述第三方信用体系、所述区块链风控、所述大数据风控和所述行为分析中的信用分的其中一种,得到所述信用评分模型。

在另一种示例中,选择所述黑名单、所述第三方信用体系、所述区块链风控、所述大数据风控和所述行为分析中的至少两种的信用分进行求和,得到所述信用评分模型。

以下为步骤s203的第二种实施方案,可采用下述至少一种方案获得用户的信用分:

1)针对所述黑名单,当用户在所述黑名单中时,信用分记为0;当用户不在所述黑名单中时,信用分记为1;

2)针对所述第三方信用体系,当用户在所述第三方信用体系中风险分数大于或等于第一阈值时,信用分记为1;当用户在所述第三方信用体系中风险分数小于所述第一阈值时,信用分记为0;

3)针对所述区块链风控,当用户在所述区块链风控中有不良记录时,信用分记为0;当用户在所述区块链风控中没有不良记录时,信用分记为1;

4)针对所述大数据风控,根据线上和线下的财务、消费、征信情况进行综合评价,当用户在所述大数据风控中有不良记录时,信用分记为0;当用户在所述大数据风控中没有不良记录时,信用分记为1;

5)针对所述行为分析,当用户对所述保险产品的关注度低于第二阈值时,信用分记为0;当用户对所述保险产品的关注度等于或高于所述第二阈值时,信用分记为1;

6)设置所述黑名单、所述第三方信用体系、所述区块链风控、所述大数据风控和所述行为分析中至少两种评分因子的权重系数;

7)按照所述至少两种评分因子的信用分和对应的权重系数的乘积进行求和,得到所述信用评分模型。

当然针对上述两种不同信用评分模型计算出的信用评分,在后续步骤判断是否通过时的评判标准也不同。

需要说明的是,上述两种实施方案中的信用分除了用1进行标记,还可以在两种结果(即第一数值和第二数值)之间进行分级标记,例如,对于第三方信用体系的评分过程中,实际信用分为0~10时标记为0,实际信用分为10~30时标记为1,实际信用分为3~50时标记为2,实际信用分为50~70时标记为3,实际信用分为7~90时标记为4,实际信用分为90~100时标记为5。

同样,在计算过程中也需要进行归一化处理使其具有相同的评分基准,例如当第三方信用体系采用0、1、2、3、4、5六级分级时,相应的黑名单的信用分标记为在黑名单中记为0,不在黑名单中记为5。

除了上述信用评分模型,还可以采用表1所示的信用评分审核体系得到信用评分:

表1

其中在表1以最高分为5为例,表1中虽然没有通过量化的方式对各个评分因子的重要性进行设定,但是也可以看出对于行为分析是非必须的审核项目。基于上述表1可以看出,对于信用评分累加值在20-25分之间的,属于高信用低风险的用户,也就是上述五项评分因子中至少有四项通过,则认为该用户为低风险用户;对于信用评分累加值在0-15分之间的,属于低信用高风险的用户,也就是上述五项评分因子中只有不超过三项通过,则认为该用户为高风险用户。

在步骤s103中,将所述信用评分与预设分值进行比较,并根据比较结果决定是否承保出单。

在本公开的一种示例性实施例中,如果以上述信用评分模型为例,该步骤中将所述信用评分与预设分值进行比较,并根据比较结果决定是否承保出单,具体包括:

如果所述比较结果为所述信用评分大于或等于所述预设分值,则确定支付宽限期;如果所述支付宽限期不晚于所述保险产品的等待期或观察期,则承保出单成功,得到保单;如果所述支付宽限期晚于所述保险产品的等待期或观察期,则承保出单失败。

在本公开的一种示例性实施例中,如果所述支付宽限期不晚于所述保险产品的等待期或观察期,还包括:

生成催缴计划,所述催缴计划用于提醒用户在规定日期前进行缴费;

如果用户在所述规定日期前完成缴费,则所述保单生效;

如果用户在所述规定日期前未完成缴费,则所述保单失效。

如果以上述表1所示评分体系为例,则该步骤具体包括:

信用评分的累计分值在0-15分范围,信用评级的结果为低信用高风险,不允许承保;信用评分的累计分值在20-25分范围,信用评级的结果为高信用低风险,则允许承保。

图3示出本公开实施例中用于实现上述信用支付处理方法的架构图,如图3所示,该架构中设计用户(即投保人)、渠道平台、支付平台和信用评分体系四部分,所涉及的步骤大致分为s31~s34四个阶段,具体如下:

第一阶段,投保/核保。

如图3所示,在该阶段中,选择有等待期(等待期m天)类的保险产品,填写保单信息,在线提交系统进行核保,如果核保通过,则进入到下一阶段,即进行支付。

第二阶段,智能支付及用户评分。

如图3所示,在该阶段中,用户先进行常规支付(如微信、支付宝、网银等),如果常规支付成功,则系统确认支付信息,即可正常出单;如果常规支付失败,则转入智能支付过程。

通过调用用户信用评分功能,以表1所示为例,根据信用评分对应的评分结果累加信用分值,累计分值在0-15分范围,信用评级的结果为低信用高风险,即不允许对该用户未成功支付的保险订单进行承保;累计分值在20-25分范围,信用评级的结果为高信用低风险,则允许对该用户未成功支付的保险订单进行承保,进入下一阶段。

在该阶段中,不仅仅局限于原有的常规支付,为用户提供更加丰富和人性化的支付方式,也就是说对于高信用低风险的用户即便在常规支付不成功的情况下,依然可以凭借其高信用评分作为支付手段,使得其未成功支付的保险订单可以正常进入承保阶段。

第三阶段,承保出单。

如图3所示,在该阶段中,根据信用评分进行智能支付是否通过,如果不通过,则出单失败并告知用户;如果评分通过,且确定当前用户支付宽限期(n天),若支付宽限期晚于保单等待期/观察期(n>m),出单失败并告知用户;若支付宽限期早于保单等待期/观察期(n<=m),保单承保,同时生成催缴计划并告知用户。

需要说明的是,对于信用评分进行智能支付是否通过的标准可以将信用评分是否超过预设分值作为判断标准,还可以将信用评分等级是否超过最低要求作为判断标准。

第四阶段,逾期不缴系统退保。

如图3所示,在该阶段中,在渠道平台根据催缴计划向用户推送缴费通知,如果用户能够按照缴费计划进行缴费,则系统保费更新实收状态,确认保费已收,保单生效;如果用户逾期不缴,则系统将在最后缴费时间点过后,执行系统退保操作,成功退保之后通知客户,保单失效。

基于图3所示,本公开实施例中对于高信用用户,改变常规出单流程(投保/核保-支付成功-承保),降低支付结果对业务的影响,通过信用评分体系控制出单风险(投保/核保-支付失败-信用评级高-出单),避免用户逾期不缴保费的风险,适用有等待/观察期(产品等待期>=缴费宽限期)的产品。另外,还可以可根据缴费情况,通知客户保单生效情况。

采用图3所示流程,只需调整资金支付结果对传统承保过程的影响,利用客户信用评分体系的评分,智能判断用户在资金支付失败的情况下,是否属于高信用低风险用户,结合完善的智能支付用户信用评分体系(借助信用黑名单、第三方信用体系、区块链风控、大数据风控、行为分析-投保产品关注度等)的支持,在图3所示架构中,通过搭建非必要性资金支付承保流程,之后根据缴费计划,控制承保后逾期不缴的风险,即只要在宽限期内完成支付保单即生效,相反,如果用户信用评分可以通过,但是未在宽限期内完成支付则保单也会失效。

基于上述实施例,在互联网+保险的应用场景下,结合用户信用评分体系,保险行业跨界与社交平台深度合作获取潜在客户和高理赔风险客户的方式,有效选择高评分低风险用户快速出单,可以提升用户体验,针对等待期类产品及高信用低风险人群,保证保费规模;有效控制承保风险,基于完善的信用体系,降低逾期不缴风险从而提高整体效益。

综上所述,采用本公开实施例提供的信用支付处理方法,一方面,在投保过程中,如果用户用资金支付失败,则根据对用户的信用评分进行判断,如果信用评分能够通过,则执行非必要性资金支付流程,完成承保出单,对于信用评分较高的用户可以减少等待时间,提升用户体验。另一方面,通过跨平台甚至跨行业获取用户的信用评分,降低理赔风险,提高保险企业收益。

以下介绍本公开的装置实施例,可以用于执行本公开上述的信用支付处理方法。

图4示出了根据本公开的实施例的信用支付处理装置的结构示意图,参考图4,信用支付处理装置400,包括:检测模块401、评分模块802和出单模块403。

检测模块401用于对保险产品的支付情况进行检测,得到未完成支付的订单;评分模块402用于针对所述未完成支付的订单获取用户的信用评分;出单模块403用于将所述信用评分与预设分值进行比较,并根据比较结果决定是否承保出单。

在本公开的一种示例性实施例中,检测模块401对具有等待期或观察期,且已经通过核保的保险产品的支付情况进行检测。对于有等待期/观察期的保险产品,在核保通过后,如果用户支付保费环节因各类原因(如卡类余额不足、短暂冻结等)不能完成资金支付情况下的订单,就属于该步骤中未完成支付的订单。

在本公开的一种示例性实施例中,评分模块402中针对未完成支付的订单可以调用用户信用评分体系或信用评分模型等对未完成支付的用户的信用评分进行评价,确认该用户的信用评分或信用等级的评价结果。根据黑名单、第三方信用体系、区块链风控、大数据风控和行为分析中的至少一项评分因子构建信用评分模型,例如可以采用直接将信用分累加求和,或者按照进行权重进行累加计算。

在本公开的一种示例性实施例中,出单模块403根据评分模块402得到的信用评分与与预设分值进行比较,如果所述比较结果为所述信用评分大于或等于所述预设分值,则确定支付宽限期;如果所述支付宽限期不晚于所述保险产品的等待期或观察期,则承保出单成功,得到保单;如果所述支付宽限期晚于所述保险产品的等待期或观察期,则承保出单失败。

在本公开的一种示例性实施例中,出单之后,生成催缴计划,所述催缴计划用于提醒用户在规定日期前进行缴费;如果用户在所述规定日期前完成缴费,则所述保单生效;如果用户在所述规定日期前未完成缴费,则所述保单失效。

由于本公开的示例实施例的信用支付处理装置的各个功能模块与上述信用支付处理方法的示例实施例的步骤对应,因此对于本公开装置实施例中未披露的细节,请参照本公开上述的信用支付处理方法的实施例。

综上所述,采用本公开实施例提供的信用支付处理装置,一方面,在投保过程中,如果用户用资金支付失败,则根据对用户的信用评分进行判断,如果信用评分能够通过,则执行非必要性资金支付流程,完成承保出单,对于信用评分较高的用户可以减少等待时间,提升用户体验。另一方面,通过跨平台甚至跨行业获取用户的信用评分,降低理赔风险,提高保险企业收益。

下面参考图5,其示出了适于用来实现本公开实施例的电子设备的计算机系统500的结构示意图。图5示出的电子设备的计算机系统500仅是一个示例,不应对本公开实施例的功能和使用范围带来任何限制。

如图5所示,计算机系统500包括中央处理单元(cpu)501,其可以根据存储在只读存储器(rom)502中的程序或者从存储部分508加载到随机访问存储器(ram)503中的程序而执行各种适当的动作和处理。在ram503中,还存储有系统操作所需的各种程序和数据。cpu501、rom502以及ram503通过总线504彼此相连。输入/输出(i/o)接口505也连接至总线504。

以下部件连接至i/o接口505:包括键盘、鼠标等的输入部分506;包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分507;包括硬盘等的存储部分508;以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分509。通信部分505经由诸如因特网的网络执行通信处理。驱动器510也根据需要连接至i/o接口505。可拆卸介质511,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器510上,以便于从其上读出的计算机程序根据需要被安装入存储部分508。

特别地,根据本公开的实施例,上文参考流程图描述的过程可以被实现为计算机软件程序。例如,本公开的实施例包括一种计算机程序产品,其包括承载在计算机可读介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,该计算机程序可以通过通信部分509从网络上被下载和安装,和/或从可拆卸介质511被安装。在该计算机程序被中央处理单元(cpu)501执行时,执行本申请的系统中限定的上述功能。

需要说明的是,本公开所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中,计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:无线、电线、光缆、rf等等,或者上述的任意合适的组合。

附图中的流程图和框图,图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图或流程图中的每个方框、以及框图或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。

描述于本公开实施例中所涉及到的单元可以通过软件的方式实现,也可以通过硬件的方式来实现,所描述的单元也可以设置在处理器中。其中,这些单元的名称在某种情况下并不构成对该单元本身的限定。

作为另一方面,本申请还提供了一种计算机可读介质,该计算机可读介质可以是上述实施例中描述的电子设备中所包含的;也可以是单独存在,而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序,当上述一个或者多个程序被一个该电子设备执行时,使得该电子设备实现如上述实施例中所述的信用支付处理方法。

例如,所述的电子设备可以实现如图1中所示的:步骤s101:对保险产品的支付情况进行检测,得到未完成支付的订单;步骤s102:针对所述未完成支付的订单获取用户的信用评分;步骤s103:将所述信用评分与预设分值进行比较,并根据比较结果决定是否承保出单。

应当注意,尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元,但是这种划分并非强制性的。实际上,根据本公开的实施方式,上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之,上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

通过以上的实施方式的描述,本领域的技术人员易于理解,这里描述的示例实施方式可以通过软件实现,也可以通过软件结合必要的硬件的方式来实现。因此,根据本公开实施方式的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是cd-rom,u盘,移动硬盘等)中或网络上,包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本公开实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本公开的真正范围和精神由下面的权利要求指出。

应当理解的是,本公开并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1