一种订单处理方法及装置与流程

文档序号:11408781阅读:251来源:国知局
一种订单处理方法及装置与流程

本发明实施例涉及互联网技术领域,尤其涉及一种订单处理方法及装置。



背景技术:

目前,随着互联网技术的日益成熟和快速发展,网民的消费方式也逐渐多元化。信用消费平台为广大用户提供了一种全新的消费方式。

在互联网信用消费平台上,用户可依靠平台授予的信用额度去购买商品或者借贷,具备在线办理、随时取现、零首付分期购物以及还款便利等优点,受到了很多用户的青睐。为了保证平台金融安全以及降低平台坏账率,信用消费平台通常会在下单流程中按照一定的风险控制(简称风控)规则来进行风控拦截,以防范风险用户,然而,由于目前的风控规则普遍比较粗放,经常会误伤到正常用户,导致下单成功率低、下单耗时长以及下单转化率低等问题,不利于信用消费平台的运行效率。



技术实现要素:

本发明实施例的目的是提供一种订单处理方法及装置,以优化基于互联网信用消费平台的订单处理方案。

一方面,本发明实施例提供了一种订单处理方法,应用于互联网信用消费平台,包括:

在接收到购买请求时,采用第一风险控制策略对所述购买请求进行第一验证;

在所述第一验证成功时,建立所述购买请求对应的订单并将对应的订单状态设置为待支付状态;

采用第二风险控制策略对所述订单进行第二验证,其中,所述第二风险控制策略的风险控制等级高于所述第一风险控制策略的风险控制等级;

在所述第二验证失败时,进入授信流程并在检测到授信审核通过时,进入所述订单的支付流程。

另一方面,本发明实施例提供了一种订单处理装置,应用于互联网信用消费平台,包括:

第一验证模块,用于在接收到购买请求时,采用第一风险控制策略对所述购买请求进行第一验证;

订单建立模块,用于在所述第一验证成功时,建立所述购买请求对应的订单并将对应的订单状态设置为待支付状态;

第二验证模块,用于采用第二风险控制策略对所述订单进行第二验证,其中,所述第二风险控制策略的风险控制等级高于所述第一风险控制策略的风险控制等级;

授信模块,用于在所述第二验证失败时,进入授信流程并在检测到授信审核通过时,进入所述订单的支付流程。

本发明实施例中提供的订单处理方案,在接收到购买请求时,采用等级低的第一风险控制策略对购买请求进行第一验证,可避免误伤正常可信用户,在验证成功时,建立订单并设置为待支付状态,随后采用等级高的第二风险控制策略对订单进行第二验证,若验证失败,不会直接关闭订单也不会直接进入支付流程,而是进入授信流程并在检测到授信审核通过时,进入订单的支付流程。通过采用上述技术方案,通过分级风险控制的方式逐步对用户发起的购买行为进行验证,可避免误伤正常用户,并在进入支付流程前为用户提供授信审核的机会,减少重复下单的操作,可提高下单成功率及下单转化率,并减少下单时长,提高信用消费平台的运行效率。

附图说明

图1为本发明实施例一提供的一种订单处理方法的流程示意图;

图2为本发明实施例二提供的一种订单处理方法的流程示意图;

图3为本发明实施例二提供的一种购买流程示意图;

图4为本发明实施例二提供的一种支付流程示意图;

图5为本发明实施例三提供的一种订单处理装置的结构框图。

具体实施方式

下面结合附图并通过具体实施方式来进一步说明本发明的技术方案。可以理解的是,此处所描述的具体实施例仅仅用于解释本发明,而非对本发明的限定。另外还需要说明的是,为了便于描述,附图中仅示出了与本发明相关的部分而非全部结构。

在更加详细地讨论示例性实施例之前应当提到的是,一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各步骤描述成顺序的处理,但是其中的许多步骤可以被并行地、并发地或者同时实施。此外,各步骤的顺序可以被重新安排。当其操作完成时所述处理可以被终止,但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

实施例一

图1为本发明实施例一提供的一种订单处理方法的流程示意图,该方法应用于互联网信用消费平台,可以由订单处理装置执行,其中该装置可由软件和/或硬件实现,一般可集成在电脑或服务器等终端中。如图1所示,该方法包括:

步骤101、在接收到购买请求时,采用第一风险控制策略对所述购买请求进行第一验证。

示例性的,用户在信用消费平台对应的页面上选择需要购买的商品后,可通过点击购买选项等方式触发购买流程,此时,信用消费平台会接收到用户发起的购买请求,采用第一风险控制策略对购买请求进行第一验证。

示例性的,第一风险控制策略的风险控制级别较低,可避免误伤正常用户。例如,第一风险控制策略中可包含冻结账户拦截或年龄拦截中的至少一种。例如,当检测到发起购买请求的用户所使用的账户是已经被冻结的账户时,第一验证失败。此外,具体的拦截标准可根据实际的商品类别及价格等属性进行设定。例如,对于a类商品,年龄小于15岁的用户会被拦截,第一验证失败;年龄大于或等于18岁的用户不会被拦截,第一验证成功。对于b类商品,年龄小于20岁或大于60岁的用户会被拦截,第一验证失败;年龄大于或等于20岁且小于或等于60岁的用户不会被拦截,第一验证成功。第一风险控制策略中还可以有其他类型的拦截项目,本发明实施例不做具体限定。

步骤102、在所述第一验证成功时,建立所述购买请求对应的订单并将对应的订单状态设置为待支付状态。

示例性的,在第一验证成功时,可说明当前用户基本上具备了购买所选商品的资格,可建立对应的订单,并将该订单设置为待支付状态。

步骤103、采用第二风险控制策略对所述订单进行第二验证。

其中,所述第二风险控制策略的风险控制等级高于所述第一风险控制策略的风险控制等级,具体的,第二风险控制策略比第一风险控制策略更加严格,主要可以是对当前用户的信用额度进行拦截,所以第二风险控制策略中包含信用额度拦截。例如,当前用户的信用额度为1000,若订单总额为1200,则第二验证失败;若订单总额为800,则第二验证成功。

步骤104、在所述第二验证失败时,进入授信流程并在检测到授信审核通过时,进入所述订单的支付流程。

示例性的,当第二验证失败时,说明用户想要购买的东西已超过其信用额度,若直接进入支付流程,则会导致支付失败,浪费时间;若关闭订单,则用户需要重新选购商品,同样影响下单效率。因此,本发明实施例会进入授信流程。

示例性的,进入授信流程可包括:引导用户输入授信相关资料。例如,可显示文字提示,提示用户即将进入授信流程,请用户输入或上传授信流程所需要的材料,如身份证号、身份证扫描图像或工资流水扫描图像等等。可由平台自动对用户输入的授信相关材料进行信息识别提取并自动核实,或者由工作人员进行人工核实,将核实结果返回平台。在核实结果为审核通过时,说明用户已具备购买所选商品的信用额度,可进入订单的支付流程。

优选的,当第二验证成功时,可直接进入订单的支付流程。

本发明实施例中提供的订单处理方法,在接收到购买请求时,采用等级低的第一风险控制策略对购买请求进行第一验证,可避免误伤正常可信用户,在验证成功时,建立订单并设置为待支付状态,随后采用等级高的第二风险控制策略对订单进行第二验证,若验证失败,不会直接关闭订单也不会直接进入支付流程,而是进入授信流程并在检测到授信审核通过时,进入订单的支付流程。通过采用上述技术方案,通过分级风险控制的方式逐步对用户发起的购买行为进行验证,可避免误伤正常用户,并在进入支付流程前为用户提供授信审核的机会,减少重复下单的操作,可提高下单成功率及下单转化率,并减少下单时长,提高信用消费平台的运行效率。

实施例二

图2为本发明实施例二提供的一种订单处理方法的流程示意图,本实施例以上述实施例为基础进行优化,具体对进入所述订单的支付流程进行了优化。如图2所示,本实施例的方法包括如下步骤:

步骤201、在接收到购买请求时,采用第一风险控制策略对购买请求进行第一验证。

示例性的,图3为本发明实施例二提供的一种购买流程示意图,可参照图3对本发明实施例进一步地理解。可根据用户的操作由前端网页(web)发起购买,将购买入参转发至接入层处理,通过接入层进行简单拦截(如订单状态有效性拦截)和登录验证(如用户所登录的账号及密码的验证)处理后,将请求处理转发下单逻辑层处理。通过下单逻辑层服务调用基本风控服务拦截风险用户,即采用第一风险控制策略对购买请求进行第一验证。基本风控服务只包含最基本的风控规则,如冻结账户拦截或年龄拦截,基本不会误杀正常可信用户。

步骤202、判断第一验证是否成功,若是,则执行步骤203;否则,结束流程。

步骤203、建立购买请求对应的订单并将对应的订单状态设置为待支付状态。

示例性的,若第一验证成功,则通过基本风控服务的验证,可接着调用商品服务和优惠服务,调用通过之后将订单入库(即创建购买请求对应的订单并将订单放入订单库),置订单状态为待支付状态,等待后续的支付流程处理。

步骤204、采用第二风险控制策略对订单进行第二验证。

其中,所述第二风险控制策略的风险控制等级高于所述第一风险控制策略的风险控制等级,第二风险控制策略中包含信用额度拦截。

示例性的,图4为本发明实施例二提供的一种支付流程示意图,可参照图4对本发明实施例进一步地理解。用户可由订单购买页面跳转至支付页面或者由订单详情页面发起跳转至订单支付页面发起支付。也即在步骤203和步骤204还可包括,在订单购买页面或订单详情页面检测到触发支付事件。

步骤205、判断第二验证是否成功,若否,则执行步骤206;否则,执行步骤207。

通过信用额度对订单进行拦截判断,如果不满足条件则走授信流程,引导用户去提交资料,完成审核之后才能继续支付流程,如果满足条件,可直接继续支付流程。

步骤206、进入授信流程并检测授信审核是否通过,若是,则执行步骤207;否则,结束流程。

步骤207、接收订单的支付请求和身份验证信息。

步骤208、当身份验证信息验证成功时,将订单的订单号和支付请求的相关数据写入内存数据库,在内存数据库中初始化订单的支付状态,并向消息队列mq插入订单对应的消息,返回前端并锁住页面。

示例性的,身份验证信息可包括验证密码、短信验证码及指纹信息等。为避免用户不小心输错身份验证信息,在验证失败时,可为用户提供一定次数的重新输入机会(如2次)。当身份验证信息验证成功时,将支付请求转发支付接入层,支付接入层验证交易密码之后,将订单的订单号和支付请求的相关数据写入内存数据库。

示例性的,本发明实施例中的内存数据库可以包括memcache、ssdb、cassandra以及redis等数据库。其中,redis(remotedictionaryserver)是一种速度较快的内存型存储数据库服务器,它可以存储键(key)与5种不同类型的值(value)之间的映射(mapping),将存储在内存的键值对数据持久化到硬盘,在实际应用中已显现出较大的优势。优选的,本发明实施例中的内存数据库为redis,key为订单号,value存放支付请求的相关数据和支付状态(支付状态可包括初始化、等待、超时、成功及失败等,默认为初始化状态)。

本发明实施例中为了加快订单处理效率,采用消息队列(messagequeue,mq)异步化处理提高支付服务处理性能。在将相关数据写入redis后,向mq插入所述订单对应的消息,直接返回到前端,前端锁住页面。在后台mq消费者异步地对订单支付状态进行更新的同时,前端可按照预设时间间隔(如3秒)发起轮询接口根据订单号到redis查询支付处理状态,直至支付状态满足预设要求(如成功、失败或超时)才终止。

步骤209、通过后台的mq消费者基于异步方式从mq服务器中获取订单对应的订单号,采用第三风险控制策略对订单进行第三验证,并根据第三验证的结果对内存数据库中的支付状态进行更新。

其中,所述第三风险控制策略的风险控制等级高于所述第二风险控制策略的风险控制等级。示例性的,第三风险控制策略包括可信设备拦截、用户基本资料拦截、用户订单规则拦截、校区风险拦截和用户额度拦截中的至少一个。

示例性的,在进行第三验证之前,还可对订单进行重入性判断和状态有效性判断。例如,订单状态只有为初始化状态或者等待超时才能通过,否则当成订单重入或者状态无效拒绝后续处理。

随后,可调用完全风控服务进行拦截(即采用第三风险控制策略对订单进行第三验证),通过后修改订单的支付状态为成功,同时发出mq通知外围相关系统,最后将redis里对应订单的支付状态置为成功。如果调用流程有异常,会捕获异常同时置redis里对应订单的支付状态为失败。

步骤210、通过前端根据订单号按照预设时间间隔轮询内存数据库中订单的支付状态,在所查询到的支付状态满足预设要求时,返回查询结果。

本发明实施例二提供的订单处理方法,能够有效解决现有的基于互联网信用消费平台的订单处理方案中因下单流程僵化且被风控拦截后需重新下单所造成的影响用户购物体验的问题,以及解决下单同步调用且超时长,限制系统吞吐量的问题。通过引入待支付状态,优化订单流程为购买和支付流程,降低了系统复杂度;在待支付订单状态下,用户可重复发起支付,而无需重新下单,且可引导被拦截用户进行授信,提高下单成功转化率;采用mq异步化处理,通过增加状态机流转,提高支付服务吞吐量,提高信用消费平台的运行效率。

实施例三

图5为本发明实施例三提供的一种订单处理装置的结构框图,该装置应用于互联网信用消费平台,可由软件和/或硬件实现,一般集成在移动终端中,可通过执行订单处理方法来进行订单处理。如图5所示,该装置包括:

第一验证模块501,用于在接收到购买请求时,采用第一风险控制策略对所述购买请求进行第一验证;

订单建立模块502,用于在所述第一验证成功时,建立所述购买请求对应的订单并将对应的订单状态设置为待支付状态;

第二验证模块503,用于采用第二风险控制策略对所述订单进行第二验证,其中,所述第二风险控制策略的风险控制等级高于所述第一风险控制策略的风险控制等级;

授信模块504,用于在所述第二验证失败时,进入授信流程并在检测到授信审核通过时,进入所述订单的支付流程。

本发明实施例提供的订单处理装置,通过分级风险控制的方式逐步对用户发起的购买行为进行验证,可避免误伤正常用户,并在进入支付流程前为用户提供授信审核的机会,减少重复下单的操作,可提高下单成功率及下单转化率,并减少下单时长,提高信用消费平台的运行效率。

可选的,所述第一风险控制策略中包含冻结账户拦截和年龄拦截中的至少一种;所述第二风险控制策略中包含信用额度拦截。

可选的,所述进入所述订单的支付流程包括:

接收所述订单的支付请求和身份验证信息;

当所述身份验证信息验证成功时,将所述订单的订单号和所述支付请求的相关数据写入内存数据库,在所述内存数据库中初始化所述订单的支付状态,并向消息队列mq插入所述订单对应的消息,返回前端并锁住页面;

通过后台的mq消费者基于异步方式从mq服务器中获取所述订单对应的订单号,采用第三风险控制策略对所述订单进行第三验证,并根据所述第三验证的结果对所述内存数据库中的支付状态进行更新,其中,所述第三风险控制策略的风险控制等级高于所述第二风险控制策略的风险控制等级;

通过前端根据订单号按照预设时间间隔轮询所述内存数据库中所述订单的支付状态,在所查询到的支付状态满足预设要求时,返回查询结果。

可选的,所述第三风险控制策略包括可信设备拦截、用户基本资料拦截、用户订单规则拦截、校区风险拦截和用户额度拦截中的至少一个。

可选的,所述内存数据库为redis,key为订单号,value存放支付请求的相关数据和支付状态。

上述实施例中提供的订单处理装置可执行本发明任意实施例所提供的订单处理方法,具备执行该方法相应的功能模块和有益效果。未在上述实施例中详尽描述的技术细节,可参见本发明任意实施例所提供的订单处理方法。

注意,上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解,本发明不限于这里所述的特定实施例,对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此,虽然通过以上实施例对本发明进行了较为详细的说明,但是本发明不仅仅限于以上实施例,在不脱离本发明构思的情况下,还可以包括更多其他等效实施例,而本发明的范围由所附的权利要求范围决定。

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