CN117557329A - 订单处理方法、装置、存储介质和计算机设备 - Google Patents

Abstract

本申请公开了一种订单处理方法、装置、存储介质和计算机设备。方法包括：响应于目标授信用户的下单请求，获取目标授信用户的授信信息；若目标授信用户的授信信息存在异常，则确定目标授信用户的授信异常类型；若授信异常类型属于预设类型，则根据目标授信用户对应的临时授信额度和下单请求对应的订单金额，生成能源订单；若授信异常类型不属于预设类型，取消生成能源订单。不仅能够减少用户因为授信问题而无法下单的情况，提高用户在的使用体验，而且能够帮助平台及时发现潜在的风险，减少因用户信用问题导致的欠款和亏损，大大降低了平台的损失。

Description

订单处理方法、装置、存储介质和计算机设备

技术领域

本申请涉及互联网技术领域，尤其是涉及到一种订单处理方法、装置、存储介质和计算机设备。

背景技术

能源站是指为汽车和其它机动车辆提供能源或非能源服务的补给站，场站一般零售汽油、柴油、机油、天然气、氢气、电以及非能源品(如饮品、零食等)。

对于能源需求多的用户(如物流车队、公车需求企业)，为了方便管理一般会与能源平台签署合作协议，通过能源平台下订单，下单后去能源站进行能源补充即可，如此，用户经由平台与能源站进行结算，无需与能源站直接结算。

相关技术中，平台通常会为用户设定一个授信额度，在授信额度内可以先消费，随后定期结算，根据结算金额恢复授信额度。但有时会出现结算款未到账导致授信额度不足，或者授信超期后用户未及时更新，再或者授信数据拉取失败等非用户主观操作导致的授信异常的情况。若直接根据授信异常的情况判定用户无法下单则会影响用户使用体验，进而造成平台用户流失。

发明内容

有鉴于此，本申请提供了一种订单处理方法、装置、存储介质和计算机设备，从而为提供用户的临时授信额度功能，保证用户能够及时享受能源站的补给服务。

依据本申请的第一方面实施例，提供了一种订单处理方法，包括：

响应于目标授信用户的下单请求，获取目标授信用户的授信信息；

若目标授信用户的授信信息存在异常，则确定目标授信用户的授信异常类型；

若授信异常类型属于预设类型，则根据目标授信用户对应的临时授信额度和下单请求对应的订单金额，生成能源订单；

若授信异常类型不属于预设类型，取消生成能源订单。

可选地，根据目标授信用户对应的临时授信额度生成能源订单之前，订单处理方法还包括：

获取目标授信用户的信用属性信息，其中，信用属性信息包括以下至少一种：信用等级、历史授信额度、第一预设时段内产生的历史能源订单的订单金额、结算周期；

确定不同的信用属性信息对应的权重系数；

根据权重系数对信用属性信息进行加权计算，得到临时授信额度。

可选地，信用属性信息包括信用等级，订单处理方法还包括：

获取目标授信用户的资质信息和/或第二预设时段内目标授信用户的信用异常标签；

根据资质信息和/或信用异常标签，计算目标授信用户的风险评分；

若风险评分位于预设等级的评分区间内，则将预设等级确定为目标授信用户的信用等级。

可选地，授信异常类型属于预设类型，订单处理方法还包括：

若授信异常类型为授信信息中剩余授信额度不足，且未检测到目标授信用户的历史能源订单，则取消生成能源订单。

可选地，根据目标授信用户对应的临时授信额度和下单请求对应的订单金额，生成能源订单，包括：

若目标授信用户为预设聚合用户中的子用户，且目标授信用户的身份信息符合预设聚合用户对应的临时授信权限，根据临时授信额度和下单请求对应的订单金额，生成能源订单；和/或，

若目标授信用户为预设聚合用户中的子用户，且目标授信用户所属预设聚合用户在当前统计周期的历史授信金额小于或等于预设聚合用户对应的可用临时额度，则根据临时授信额度和下单请求对应的订单金额，生成能源订单，其中，历史授信金额为预设聚合用户在当前统计周期内产生的历史能源订单中使用临时授信额度结算的订单金额的总和；和/或，

若目标授信用户的携带有临时授信标签的历史能源订单的个数小于预设个数，则根据临时授信额度和下单请求对应的订单金额，生成能源订单，其中，临时授信标签在生成历史能源订单的情况下被标记。

可选地，根据目标授信用户对应的临时授信额度和下单请求对应的订单金额，生成能源订单，包括：

若下单请求对应的订单金额小于或等于临时授信额度，则根据下单请求对应的订单金额生成能源订单；

若下单请求对应的订单金额大于临时授信额度，则取消生成能源订单。

可选地，订单处理方法还包括：

若授信异常类型为未获取到授信信息，则确定授信异常类型属于预设类型。

可选地，订单处理方法还包括：

若授信异常类型为授信超期，则确定授信异常类型属于预设类型。

可选地，订单处理方法还包括：

若授信异常类型为授信信息中剩余授信额度不足，则确定授信异常类型属于预设类型。

可选地，订单处理方法还包括：

若取消生成能源订单，则向目标授信用户发送异常提示信息；

若生成能源订单，则向目标授信用户反馈下单确认信息，以及对能源订单添加临时授信标签。

可选地，订单处理方法还包括：

根据能源订单的订单金额执行与能源站的结算操作；

根据目标授信用户对应的结算期限内产生的能源订单，确定待支付金额；

根据待支付金额执行与目标授信用户的结算操作。

根据本申请的第二方面实施例，提供了一种订单处理装置，包括：

获取模块，用于响应于目标授信用户的下单请求，获取目标授信用户的授信信息；

异常监测模块，用于若目标授信用户的授信信息存在异常，则确定目标授信用户的授信异常类型；

订单处理模块，用于若授信异常类型属于预设类型，则根据目标授信用户对应的临时授信额度和下单请求对应的订单金额，生成能源订单；以及，若授信异常类型不属于预设类型，取消生成能源订单。

可选地，获取模块，还用于获取目标授信用户的信用属性信息，其中，信用属性信息包括以下至少一种：信用等级、历史授信额度、第一预设时段内产生的历史能源订单的订单金额、结算周期；

订单处理装置还包括：

额度计算模块，用于确定不同的信用属性信息对应的权重系数；以及，根据权重系数对信用属性信息进行加权计算，得到临时授信额度。

可选地，信用属性信息包括信用等级，

获取模块，还用于获取目标授信用户的资质信息和/或第二预设时段内目标授信用户的信用异常标签；

订单处理装置还包括：

评估模块，用于根据资质信息和/或信用异常标签，计算目标授信用户的风险评分；以及，若风险评分位于预设等级的评分区间内，则将预设等级确定为目标授信用户的信用等级。

可选地，订单处理模块，还用于若授信异常类型为授信信息中剩余授信额度不足，且未检测到目标授信用户的历史能源订单，则取消生成能源订单。

可选地，订单处理模块，具体用于若目标授信用户为预设聚合用户中的子用户，且目标授信用户的身份信息符合预设聚合用户对应的临时授信权限，根据临时授信额度和下单请求对应的订单金额，生成能源订单。

可选地，订单处理模块，具体用于若目标授信用户为预设聚合用户中的子用户，且目标授信用户所属预设聚合用户在当前统计周期的历史授信金额小于或等于预设聚合用户对应的可用临时额度，则根据临时授信额度和下单请求对应的订单金额，生成能源订单，其中，历史授信金额为预设聚合用户在当前统计周期内产生的历史能源订单中使用临时授信额度结算的订单金额的总和。

可选地，订单处理模块，具体用于若下单请求对应的订单金额小于或等于临时授信额度，则根据下单请求对应的订单金额生成能源订单；若下单请求对应的订单金额大于临时授信额度，则取消生成能源订单。

可选地，订单处理模块，具体用于若目标授信用户的携带有临时授信标签的历史能源订单的个数小于预设个数，则根据临时授信额度和下单请求对应的订单金额，生成能源订单，其中，临时授信标签在生成历史能源订单的情况下被标记。

可选地，异常监测模块，具体用于若授信异常类型为未获取到授信信息，则确定授信异常类型属于预设类型。

可选地，异常监测模块，具体用于若授信异常类型为授信超期，则确定授信异常类型属于预设类型。

可选地，异常监测模块，具体用于若授信异常类型为授信信息中剩余授信额度不足，则确定授信异常类型属于预设类型。

可选地，订单处理装置还包括：

通信模块，用于若取消生成能源订单，则向目标授信用户发送异常提示信息；若生成能源订单，则向目标授信用户反馈下单确认信息。

可选地，订单处理模块，还用于若生成能源订单，则对能源订单添加临时授信标签。

可选地，订单处理装置还包括：

结算模块，用于根据能源订单的订单金额执行与能源站的结算操作；根据目标授信用户对应的结算期限内产生的能源订单，确定待支付金额；根据待支付金额执行与目标授信用户的结算操作。

依据本申请的第三方面实施例，提供了一种可读存储介质，其上存储有程序或指令，程序或指令被处理器执行时实现上述实施例提供的订单处理方法的步骤。

依据本申请的第四方面实施例，提供了一种计算机设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，处理器执行所述程序时实现上述实施例提供的订单处理方法的步骤。

借由上述技术方案，平台服务端接收到用户的下单请求后，会自动调取目标授信用户的授信信息。如果目标授信用户的授信信息存在异常，平台服务端进一步确定授信异常的类型。在授信异常类型不属于预设类型的情况下，也即该用户可能存在较为严重的信用问题，平台服务端则会取消本次订单。反之，在授信异常类型属于预设类型的情况下，说明授信信息的异常原因可能并不是由目标授信用户直接导致的，此时，平台服务端为该目标授信用户本次的下单行为提供一个临时授信额度，以便于在用户授信信息异常时依旧可以通过临时授信额度生成能源订单，如此，目标授信用户可及时在能源站核销该能源订单并获得相应能源补给。不仅能够减少用户因为授信问题而无法下单的情况，提高用户在的使用体验，而且能够帮助平台及时发现潜在的风险，减少因用户信用问题导致的欠款和亏损，大大降低了平台的损失。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1示出了本申请实施例提供的订单处理方法的应用环境示意图；

图2示出了本申请实施例提供的订单处理方法的流程示意图；

图3示出了本申请实施例提供的订单处理装置的结构框图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本申请。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本申请的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“相接”到另一元件时，它可以直接连接或相接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“相接”可以包括无线连接或无线稠接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

现在，将参照附图更详细地描述根据本申请的示例性实施例。然而，这些示例性实施例可以多种不同的形式来实施，并且不应当被解释为只限于这里所阐述的实施例。应当理解的是，提供这些实施例是为了使得本申请的公开彻底且完整，并且将这些示例性实施例的构思充分传达给本领域普通技术人员。

图1示出了本申请实施例提供的订单处理方法的应用环境架构图，如图1所示，该应用环境可以包括目标授信用户的第一终端110、平台服务端120和能源站的第二终端130，该第一终端110和第二终端130可以通过互联网等网络与平台服务端120进行通信。其中，第一终端110或第二终端130可以包括但不限于各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，平台服务端120用于对第一终端110触发产生的订单请求进行确认，并生成能源订单，该服务端可以用独立的服务器或多个服务器组成的服务器集群，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。

下面结合实施例以及附图对本申请实施例提供的订单处理方法做进一步说明：

图2是根据一示例性实施例示出的一种订单处理方法的流程图，如图2所示，以订单处理方法应用于图1所示的平台服务端120进行说明，该方法包括：

步骤210，响应于目标授信用户的下单请求，获取目标授信用户的授信信息。

其中，授信信息包括用户身份信息、授信额度、剩余授信额度、授信额度使用记录、授信协议、授信有效期等能够表示用户授信情况的信息，本申请实施例不做具体限定。授信额度、授信协议、授信有效期等授信信息可根据目标授信用户的资质信息确定。

可以理解的是，本申请实施例中，目标授信用户为已获得授信资质的目标授信用户，目标授信用户可以是个体用户，也可以是包含有多个子用户的聚合用户。聚合用户可以是企业维度的聚合，聚合用户也可以是组织、家庭等其他维度的聚合。聚合用户的授信额度可以是多个子用户共享的，也可以是指定子用户配置对应的授信额度，指定子用户的授信额度之和即为聚合用户的授信额度。

需要说明的是，本申请实施例中所涉及的目标授信用户和/或能源站等平台用户的信息(包括但不限于用户设备信息、用户个人信息、用户授信信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者取消。

步骤220，若目标授信用户的授信信息存在异常，则确定目标授信用户的授信异常类型。

其中，授信异常类型包括以下至少一种：逾期还款、虚假资料、违约行为、异常交易、授信超期、未获取到授信信息、剩余授信额度不足等。

具体地，逾期还款是指用户未按照约定的时间和金额进行还款。虚假资料是指提供虚假的个人或财务信息。违约行为是指故意逃避还款责任等授信合同中的条款。异常交易是指存在高风险交易记录(如，大额消费、消费频率过高)。授信超期是指授信过期用户未重新评估，或者协议到期未更新新的授信协议。未获取到授信信息是指内部系统故障获取信息失败。剩余授信额度不足是指订单请求对应的订单金额大于剩余授信额度。

步骤230，若授信异常类型属于预设类型，则根据目标授信用户对应的临时授信额度和下单请求对应的订单金额，生成能源订单。

其中，预设类型包括：授信超期、未获取到授信信息、剩余授信额度不足等非用户主观行为导致的信用异常类型。

需要说明的是，临时授信额度与目标授信用户的资质信息、信用属性信息等影响授信的信息相关。临时授信额度可按照指定的周期进行更新，例如，每隔三个月更新一次临时授信额度，在2月至4月期间，目标授信用户的临时授信额度为1000，5月更新后，基于实时的资质信息、信用属性信息等信息，在5月至7月期间，目标授信用户的临时授信额度变更为100。临时授信额度用于评估目标授信用户的授信风险和提供临时的预支功能，与普通的授信额度不同，临时授信额度不会因生成了能源订单而扣减，在相同条件下时，目标授信用户在下一次下单时依然可以使用相同大小的临时授信额度。进一步地，临时授信额度具备一定的有效期，在指定有效期内目标授信用户才能使用该临时授信额度进行下单，例如，目标授信用户拥有1000的临时授信额度，但临时授信额度的有效期为1月份，那么目标授信用户在1月份下单时才可使用临时授信额度。

进一步地，在步骤230之前，订单处理方法还包括：若授信异常类型为未获取到授信信息，则确定授信异常类型属于预设类型。若授信异常类型为授信超期，则确定授信异常类型属于预设类型。若授信异常类型为授信信息中剩余授信额度不足，则确定授信异常类型属于预设类型。

在该实施例中，当目标授信用户本次提交的订单请求时检测到的授信异常类型为预设类型，说明授信信息的异常原因可能并不是由用户导致的，此时，平台服务端可为该用户本次的下单行为提供一个临时授信额度，以便于用户在授信信息异常时依旧可以通过临时授信额度生成能源订单，并进行预先消费。从而减少用户因为授信问题而无法下单的情况，可以及时满足目标授信用户的能源补给需求，提高用户满意度，增强用户对平台的信任和忠诚度。

在一实施例中，步骤230，也即根据目标授信用户对应的临时授信额度和下单请求对应的订单金额，生成能源订单，具体可采在下述场景中实现：

场景一，若目标授信用户为预设聚合用户中的子用户，且目标授信用户的身份信息符合预设聚合用户对应的临时授信权限，根据临时授信额度和下单请求对应的订单金额，生成能源订单。

其中，预设聚合用户是指与平台合作，且约定可采用临时授信额度下单的聚合用户。是否可采用临时授信额度进行下单可通过聚合用户资质信息等信息判断。聚合用户可以是企业维度的聚合，聚合用户也可以是组织、家庭等其他维度的聚合，聚合用户可为每个子用户可配置有不同的授信额度。临时授信权限可根据预设聚合用户和平台需求合理设置，本申请实施例不做具体限定。

在该实施例中，通过临时授信权限和子用户身份信息判断提交订单请求的子用户是否为预设聚合与平台约定的特殊用户。在子用户为特殊用户，也即身份信息符合预设聚合用户对应的临时授信权限的情况下，才会根据临时授信额度和下单请求对应的订单金额，生成能源订单，以满足子用户的紧急或临时能源需求。从而提供更加灵活的能源授信服务给不同预设聚合用户的子用户，进而控制每个预设聚合用户的授信风险，满足预设聚合用户的财务管理需求。

示例性的，企业A拥有子用户A1、A2、A3，企业A可以按需分别为子用户A1、A2、A3分配不同的授信额度，子用户A1、A2、A3拥有的授信额度的总和即为企业A整体的授信额度。子用户A1向平台提交了一个加油订单请求。在企业A授信信息存在异常(如，企业A整体的授信信息超期)或子用户A1授信信息存在异常(如，企业A分配给用户A1的剩余授信额度不足)二者之一，以及授信异常类型属于预设类型的情况下，进一步确定子用户A1是否为企业A约定的可以享受临时授信功能的特殊用户。以企业A配置的临时授信权限为经理级别以上为例，在子用户A1为职员的时候将无法生成能源订单。

场景二，若目标授信用户为预设聚合用户中的子用户，且目标授信用户所属预设聚合用户在当前统计周期的历史授信金额小于或等于预设聚合用户对应的可用临时额度，则根据临时授信额度和下单请求对应的订单金额，生成能源订单。

其中，历史授信金额为预设聚合用户在当前统计周期内产生的历史能源订单中使用临时授信额度结算的订单金额的总和。当前统计周期为当前时刻所属的预设统计周期，预设统计周期可根据预设聚合用户的交易情况合理设置，例如，每年1月作为第一个预设统计周期，每年2～3月作为第二个预设统计周期。可用临时额度是指预设统计周期内预设聚合用户整体可使用的临时预支额度，也即使用临时授信额度进行结算的订单金额上限，可用临时额度可根据预设聚合用户的资质信息合理设置，本申请实施例不做具体限定。

在该实施例中，预先为不同的预设聚合用户配置不同的可用临时额度，也即预设聚合用户用所有子用户可供使用的临时授信额度的总和。当预设聚合用户在当前时刻所属统计周期内统计得到的历史授信金额小于或等于预设聚合用户对应的可用临时额度时，预设聚合用户中的子用户才能够享受临时授信功能。反之，当预设聚合用户在当前时刻所属统计周期内统计得到的历史授信金额大于预设聚合用户对应的可用临时额度时，说明预设聚合用户中所有子用户通过临时授信额度结算的订单金额的总和超过了预先配置的该预设聚合用户整体的可用临时额度，也即预设聚合用户的子用户频繁使用临时授信额度进行结算或已使用授信额度结算结算的订单金额过大，此时则可使预设聚合用户中所有子用户均无法使用临时授信功能。从而利用预设聚合用户的可用临时额度，控制授信风险，不仅使平台资源分配更加合理化、公平化，而且大大降低了平台的授信风险。

示例性的，企业A拥有子用户A1、A2、A3，企业A具有的可用临时额度为5000，子用户A1和子用户A2在当前统计周期内通过临时授信额度下单的订单金额的总和(历史授信金额)为5500，当子用户A3提交了一个金额为50加油订单请求时，且企业A授信信息存在异常或子用户A3授信信息存在异常时，由于历史授信金额大于企业A的可用临时额度，平台判定企业A整体在预设周期内已经使用较多的预支额度，即使子用户A3加油订单请求的金额没有超过企业A分配给子用户A3的临时授信额度，平台也会拒绝本次订单。

场景三，若目标授信用户的携带有临时授信标签的历史能源订单的个数小于预设个数，则根据临时授信额度和下单请求对应的订单金额，生成能源订单。

其中，临时授信标签在生成历史能源订单的情况下被标记。预设个数可根据平台的风控需求合理设置，本申请实施例不做具体限定。

在该实施例中，当目标授信用户的携带有临时授信标签的历史能源订单的个数小于预设个数，说明目标授信用户曾经使用临时授信额度完成能源订单不多，风险较低，此时为该目标授信用户生成能源订单，以便于目标授信用户在能源站消费。反之，当目标授信用户的携带有临时授信标签的历史能源订单的个数大于或等于预设个数，说明目标授信用户曾经使用临时授信额度完成能源订单过多，存在恶意消费的风险，则取消生成能源订单。从而利用采用临时授信额度下单的个数来控制授信风险，不仅使平台资源分配更加合理化、公平化，而且大大降低了平台的授信风险。

在一实施例中，步骤230，也即根据目标授信用户对应的临时授信额度和下单请求对应的订单金额，生成能源订单，具体包括：

步骤231-1，若下单请求对应的订单金额小于或等于临时授信额度，则根据下单请求对应的订单金额生成能源订单。

步骤231-2，若下单请求对应的订单金额大于临时授信额度，则取消生成能源订单。

在该实施例中，如果下单请求对应的订单金额小于或等于临时授信额度，说明临时授信额度能够满足用户下单消费需求，则根据下单请求对应的订单金额生成能源订单。即使该目标授信用户存在授信信息异常问题也能够生成能源订单，以进行能源站的预先消费，从而及时满足用户的能源补给需求，提高用户在的使用体验。如果下单请求对应的订单金额大于临时授信额度，也即平台给予的临时授信额度无法完成对用户需求进行预先支付，则取消生成能源订单。一方面，可以优化平台资源的利用率，特别是在平台资源有限的情况下，取消不满足条件的订单请求可以避免浪费，尽可能多的保障了其他更有需要的目标授信用户的权益。另一方面，将临时授信额度可以作为一种风险控制的手段，有效降低授信风险，避免超出平台财务能力范围。

值得一提的是，由于用于判定授信情况的用户信用信息是实时变化的，若以统一的临时授信额度来服务不同用户可能容易导致能源需求量较大的目标授信用户无法使用临时授信功能。为此，步骤230，也即根据目标授信用户对应的临时授信额度生成能源订单之前，订单处理方法还包括：获取目标授信用户的信用属性信息；确定不同的信用属性信息对应的权重系数；根据权重系数对信用属性信息进行加权计算，得到临时授信额度。

具体地，信用属性信息包括以下至少一种：信用等级、历史授信额度(之前签约的授信额度、本次于前一次签约的授信额度是否有增/减)、第一预设时段内产生的历史能源订单的订单金额、结算周期(结算订单→对账→用户付款的周期)。

其中，权重系数可根据不同的业务需求和策略合理设置。例如，信用等级可能对应的权重系数为0.4，历史授信额度为0.3，订单金额为0.2，结算周期为0.1，那么，临时授信额度＝信用等级对应的分数×0.4+历史授信额度对应的分数×0.3+订单金额对应的分数×0.2+结算周期对应的分数×0.1，此时信用等级对临时授信额度大小影响较大。可以理解的是，不同信用属性信息的分数可根据预先配置的信用属性信息与分数之间的对应关系确定。

在该实施例中，加权计算得到的临时授信额度可以更准确地反映用户的信用能力，避免临时授信额度过高或过低的情况，实现了动态为每个目标授信用户分配临时授信额度的效果，使得临时授信额度的灵活性更高，让目标授信用户可使用的临时授信额度能够更加符合安全消费的要求，实现平台个性化的授信方案。

进一步地，在一实施例中，在信用属性信息包括信用等级的情况下，订单处理方法还包括：获取目标授信用户的资质信息和/或第二预设时段内目标授信用户的信用异常标签；根据资质信息和/或信用异常标签，计算目标授信用户的风险评分；若风险评分位于预设等级的评分区间内，则将预设等级确定为目标授信用户的信用等级。

其中，资质信息可用于评估目标授信用户的授信等级、授信额度等信息。资质信息包括但不限于以下至少一种：财务信息(如，收入、支出、负债、资产、税务申报等)、还款能力等级、用户属性信息(如，用户身份信息、公司身份信息)、担保物信息。信用异常标签在目标授信用户产生信用风险行为时被标记，例如，被列为失信人、企业存在经营困难、存在欺诈行为等。目标授信用户产生的信用风险行为可以利用埋点的形式从获得授权的其他征信机构或平台获取。第二预设时段可根据平台的风险需求合理设置，第二预设时段越长，目标授信用户的风险越小。

在该实施例中，利用目标授信用户的资质信息和/或第二预设时段内目标授信用户的信用异常标签对目标授信用户可能存在的授信风险进行评分。并以风险评分为依据为目标授信用户匹配合适的信用等级。从而准确评估目标授信用户的授信风险，在保证目标授信用户能够及时享受线上预支消费和线下能源站的补给服务的同时，避免临时授信给高风险用户，降低不良预支账目的损失。同时，通过将目标授信用户划分为不同的信用等级，平台可以有针对性地制定不同的授信策略，实现了授信策略定制功能，有助于吸引更多优质客户。

示例性的，名下有较多司机的企业用户或企业用户在平在消费金额超过阈值，说明企业规模较大，风险较低，可以提供更高的信用等级。或者授信协议签约时间长，也即长时间合作的企业用户可以提供更高的信用等级。

在一实施例中，在判定目标授信用户的授信异常类型属于预设类型的情况下，订单处理方法还包括：若授信异常类型为授信信息中剩余授信额度不足，且未检测到目标授信用户的历史能源订单，则取消生成能源订单。

在该实施例中，如果用户引用异常是由于余额不足导致的，则还可以获取该目标授信用户是否在之前生成过能源订单。若没有检测到历史能源订单，说明该用户为首次下单的用户，难以正确评估该用户的实际信用情况，则取消根据临时授信额度和下单请求对应的订单金额生成能源订单。从而可以精准管控临时授信额度的分配情况，在降低授信风险的基础上，提高平台资源的利用率，特别是在平台资源有限的情况下，取消不满足条件的订单请求可以避免浪费资源，避免授信给信用较差的用户，尽可能多的保障了其他更需要资源的目标授信用户的权益。

示例性的，用户W首次登陆能源平台，平台根据用户W的信用情况为其提供300的授信额度。当用户W在能源平台首次提交金额为400的加油请求时，由于授信额度不足，且无下单记录，能源平台拒绝利用临时授信额度生成加油订单。

值得一提到是，在一实施例中，步骤230，也即根据目标授信用户对应的临时授信额度和下单请求对应的订单金额，生成能源订单之后，订单处理方法还包括：向目标授信用户反馈下单确认信息，以及对能源订单添加临时授信标签。

在该实施例中，平台服务端在生成能源订单后，平台服务端向目标授信用户反馈下单确认信息，以使目标授信用户通过平台获知订单详情和临时授信额度的使用情况。从而方便目标授信用户及时通过能源订单在能源站进行线下核销，以获取能源资源。同时，平台服务端对该能源订单进行标记，生成临时授信标签，以便于平台管理人员获知该订单使用的临时授信功能，或者用于评估目标授信用户的风险。

进一步地，在一实施例中，步骤230，也即根据目标授信用户对应的临时授信额度和下单请求对应的订单金额，生成能源订单之后，订单处理方法还包括：根据能源订单的订单金额执行与能源站的结算操作；根据目标授信用户对应的结算期限内产生的能源订单，确定待支付金额；根据待支付金额执行与目标授信用户的结算操作。

在该实施例中，在用户下单成功后，平台可按照能源订单的中记录的订单金额和与能源站之间的协议执行实时或周期性的结算操作，以使平台帮助授信用户垫付结算期限内产生的能源订单的消费金额。从而使目标授信用户能够通过线上下单线下核销的方式及时在能源站进行能源补给。此外，对于授信用户，统计目标授信用户对应的结算期限内产生的能源订单的待支付金额，在通过与目标授信用户之间的协议约定结算期限内待支付金额发送账单并要求支付相应金额。从而为目标授信用户提供先消费后支付的功能，在保证目标授信用户能够及时获得能源资源的同时，缓解其资金紧张的问题。

可以理解的是，平台与能源站进行结算时能源订单可以对应同一用户也可以对应不同用户。而平台与用户结算时能源订单仅对应该用户。

步骤240，若授信异常类型不属于预设类型，取消生成能源订单。

通过本申请提供的订单处理方法，平台服务端接收到用户的下单请求后，会自动调取目标授信用户的授信信息。如果目标授信用户的授信信息存在异常，平台服务端进一步确定授信异常的类型。在授信异常类型不属于预设类型的情况下，也即该用户可能存在较为严重的信用问题，平台服务端则会取消本次订单。反之，在授信异常类型属于预设类型的情况下，说明授信信息的异常原因可能并不是由目标授信用户直接导致的，此时，平台服务端为该目标授信用户本次的下单行为提供一个临时授信额度，以便于在用户授信信息异常时依旧可以通过临时授信额度生成能源订单，如此，目标授信用户可及时在能源站核销该能源订单并获得相应能源补给。不仅能够减少用户因为授信问题而无法下单的情况，提高用户在的使用体验，而且能够帮助平台及时发现潜在的风险，减少因用户信用问题导致的欠款和亏损，大大降低了平台的损失。

值得一提到是，在一实施例中，在取消生成能源订单之后，订单处理方法还包括：向目标授信用户发送异常提示信息。

其中，异常提示信息可以包括授信异常类型和下单失败的消息。

在该实施例中，当平台服务端取消生成能源订单时，通过异常提示信息来提醒目标授信用户本次下单失败。同时，能够帮助目标授信用户及时发现存在的异常情况，有助于及时采取相应的措施进行处理，减少可能发生的安全问题。

需要说明的是，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

如图3所示，作为上述订单处理方法的具体实现，本申请实施例提供了一种订单处理装置300，该订单处理装置300包括：获取模块301、异常监测模块302、订单处理模块303。

其中，获取模块301，用于响应于目标授信用户的下单请求，获取目标授信用户的授信信息；

异常监测模块302，用于若目标授信用户的授信信息存在异常，则确定目标授信用户的授信异常类型；

订单处理模块303，用于若授信异常类型属于预设类型，则根据目标授信用户对应的临时授信额度和下单请求对应的订单金额，生成能源订单；以及，若授信异常类型不属于预设类型，取消生成能源订单。

在该实施例中，平台服务端接收到用户的下单请求后，会自动调取目标授信用户的授信信息。如果目标授信用户的授信信息存在异常，平台服务端进一步确定授信异常的类型。在授信异常类型不属于预设类型的情况下，也即该用户可能存在较为严重的信用问题，平台服务端则会取消本次订单。反之，在授信异常类型属于预设类型的情况下，说明授信信息的异常原因可能并不是由目标授信用户直接导致的，此时，平台服务端为该目标授信用户本次的下单行为提供一个临时授信额度，以便于在用户授信信息异常时依旧可以通过临时授信额度生成能源订单，如此，目标授信用户可及时在能源站核销该能源订单并获得相应能源补给。不仅能够减少用户因为授信问题而无法下单的情况，提高用户在的使用体验，而且能够帮助平台及时发现潜在的风险，减少因用户信用问题导致的欠款和亏损，大大降低了平台的损失。

进一步地，获取模块301，还用于获取目标授信用户的信用属性信息，其中，信用属性信息包括以下至少一种：信用等级、历史授信额度、第一预设时段内产生的历史能源订单的订单金额、结算周期；订单处理装置300还包括：额度计算模块(图中未示出)，额度计算模块用于确定不同的信用属性信息对应的权重系数；以及，根据权重系数对信用属性信息进行加权计算，得到临时授信额度。

进一步地，信用属性信息包括信用等级，获取模块301，还用于获取目标授信用户的资质信息和/或第二预设时段内目标授信用户的信用异常标签；订单处理装置300还包括：评估模块(图中未示出)，评估模块用于根据资质信息和/或信用异常标签，计算目标授信用户的风险评分；以及，若风险评分位于预设等级的评分区间内，则将预设等级确定为目标授信用户的信用等级。

进一步地，订单处理模块303，还用于若授信异常类型为授信信息中剩余授信额度不足，且未检测到目标授信用户的历史能源订单，则取消生成能源订单。

进一步地，订单处理模块303，具体用于若目标授信用户为预设聚合用户中的子用户，且目标授信用户的身份信息符合预设聚合用户对应的临时授信权限，根据临时授信额度和下单请求对应的订单金额，生成能源订单。

进一步地，订单处理模块303，具体用于若目标授信用户为预设聚合用户中的子用户，且目标授信用户所属预设聚合用户在当前统计周期的历史授信金额小于或等于预设聚合用户对应的可用临时额度，则根据临时授信额度和下单请求对应的订单金额，生成能源订单，其中，历史授信金额为预设聚合用户在当前统计周期内产生的历史能源订单中使用临时授信额度结算的订单金额的总和。

进一步地，订单处理模块303，具体用于若下单请求对应的订单金额小于或等于临时授信额度，则根据下单请求对应的订单金额生成能源订单；若下单请求对应的订单金额大于临时授信额度，则取消生成能源订单。

进一步地，订单处理模块303，具体用于若目标授信用户的携带有临时授信标签的历史能源订单的个数小于预设个数，则根据临时授信额度和下单请求对应的订单金额，生成能源订单，其中，临时授信标签在生成历史能源订单的情况下被标记。

进一步地，异常监测模块302，具体用于若授信异常类型为未获取到授信信息，则确定授信异常类型属于预设类型。

进一步地，异常监测模块302，具体用于若授信异常类型为授信超期，则确定授信异常类型属于预设类型。

进一步地，异常监测模块302，具体用于若授信异常类型为授信信息中剩余授信额度不足，则确定授信异常类型属于预设类型。

进一步地，订单处理装置300还包括：通信模块(图中未示出)，通信模块用于若取消生成能源订单，则向目标授信用户发送异常提示信息；若生成能源订单，则向目标授信用户反馈下单确认信息。

进一步地，订单处理模块303，还用于若生成能源订单，则对能源订单添加临时授信标签。

进一步地，订单处理装置300还包括：结算模块(图中未示出)，结算模块用于根据能源订单的订单金额执行与能源站的结算操作；根据目标授信用户对应的结算期限内产生的能源订单，确定待支付金额；根据待支付金额执行与目标授信用户的结算操作。

关于订单处理装置的具体限定可以参见上文中对于订单处理方法的限定，在此不再赘述。上述订单处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

基于上述如图2所示方法，相应的，本申请实施例还提供了一种可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述如图2所示的订单处理方法。

基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

基于上述如图2所示的方法，以及图3所示的虚拟装置实施例，为了实现上述目的，本申请实施例还提供了一种计算机设备，具体可以为个人计算机、服务器、网络设备等，该计算机设备包括存储介质和处理器；存储介质，用于存储计算机程序；处理器，用于执行计算机程序以实现上述如图2所示的订单处理方法。

可选地，该计算机设备还可以包括用户接口、网络接口、摄像头、射频(RadioFrequency，RF)电路，传感器、音频电路、WI-FI模块等等。用户接口可以包括显示屏(Display)、输入单元比如键盘(Keyboard)等，可选用户接口还可以包括USB接口、读卡器接口等。网络接口可选的可以包括标准的有线接口、无线接口(如蓝牙接口、WI-FI接口)等。

本领域技术人员可以理解，本实施例提供的一种计算机设备结构并不构成对该计算机设备的限定，可以包括更多或更少的部件，或者组合某些部件，或者不同的部件布置。

存储介质中还可以包括操作系统、网络通信模块。操作系统是管理和保存计算机设备硬件和软件资源的程序，支持信息处理程序以及其它软件和/或程序的运行。网络通信模块用于实现存储介质内部各组件之间的通信，以及与该实体设备中其它硬件和软件之间通信。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请实施例可以借助软件加必要的通用硬件平台的方式来实现，也可以通过硬件实现响应于目标授信用户的下单请求，获取目标授信用户的授信信息；若目标授信用户的授信信息存在异常，则确定目标授信用户的授信异常类型；若授信异常类型属于预设类型，则根据目标授信用户对应的临时授信额度和下单请求对应的订单金额，生成能源订单；若授信异常类型不属于预设类型，取消生成能源订单。本申请实施例，平台服务端接收到用户的下单请求后，会自动调取目标授信用户的授信信息。如果目标授信用户的授信信息存在异常，平台服务端进一步确定授信异常的类型。在授信异常类型不属于预设类型的情况下，也即该用户可能存在较为严重的信用问题，平台服务端则会取消本次订单。反之，在授信异常类型属于预设类型的情况下，说明授信信息的异常原因可能并不是由目标授信用户直接导致的，此时，平台服务端为该目标授信用户本次的下单行为提供一个临时授信额度，以便于在用户授信信息异常时依旧可以通过临时授信额度生成能源订单，如此，目标授信用户可及时在能源站核销该能源订单并获得相应能源补给。不仅能够减少用户因为授信问题而无法下单的情况，提高用户在的使用体验，而且能够帮助平台及时发现潜在的风险，减少因用户信用问题导致的欠款和亏损，大大降低了平台的损失。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。本领域技术人员可以理解实施场景中的装置中的模块可以依据实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (10)

1.一种订单处理方法，其特征在于，所述方法包括：

响应于目标授信用户的下单请求，获取所述目标授信用户的授信信息；

若所述目标授信用户的授信信息存在异常，则确定所述目标授信用户的授信异常类型；

若所述授信异常类型属于预设类型，则根据所述目标授信用户对应的临时授信额度和所述下单请求对应的订单金额，生成能源订单；

若所述授信异常类型不属于所述预设类型，取消生成所述能源订单。

2.根据权利要求1所述的订单处理方法，其特征在于，所述根据所述目标授信用户对应的临时授信额度生成能源订单之前，所述方法还包括：

获取所述目标授信用户的信用属性信息，其中，所述信用属性信息包括以下至少一种：信用等级、历史授信额度信息、第一预设时段内产生的历史能源订单的订单金额、结算周期；

确定不同的所述信用属性信息对应的权重系数；

根据所述权重系数对所述信用属性信息进行加权计算，得到所述临时授信额度。

3.根据权利要求2所述的订单处理方法，其特征在于，所述信用属性信息包括信用等级，所述方法还包括：

获取所述目标授信用户的资质信息和/或第二预设时段内所述目标授信用户的信用异常标签；

根据所述资质信息和/或所述信用异常标签，计算所述目标授信用户的风险评分；

若所述风险评分位于预设等级的评分区间内，则将所述预设等级确定为所述目标授信用户的信用等级。

4.根据权利要求1所述的订单处理方法，其特征在于，所述授信异常类型属于预设类型，所述方法还包括：

若所述授信异常类型为所述授信信息中剩余授信额度不足，且未检测到所述目标授信用户的历史能源订单，则取消生成所述能源订单。

5.根据权利要求1所述的订单处理方法，其特征在于，所述根据所述目标授信用户对应的临时授信额度和所述下单请求对应的订单金额，生成能源订单，包括：

若所述目标授信用户为预设聚合用户中的子用户，且所述目标授信用户的身份信息符合所述预设聚合用户对应的临时授信权限，根据所述临时授信额度和所述下单请求对应的订单金额，生成能源订单；和/或，

若所述目标授信用户为预设聚合用户中的子用户，且所述目标授信用户所属预设聚合用户在当前统计周期的历史授信金额小于或等于所述预设聚合用户对应的可用临时额度，则根据所述临时授信额度和所述下单请求对应的订单金额，生成能源订单，其中，所述历史授信金额为所述预设聚合用户在所述当前统计周期内产生的历史能源订单中使用临时授信额度结算的订单金额的总和；和/或，

若所述目标授信用户的携带有临时授信标签的历史能源订单的个数小于预设个数，则根据所述临时授信额度和所述下单请求对应的订单金额，生成所述能源订单，其中，所述临时授信标签在生成历史能源订单的情况下被标记。

6.根据权利要求1至5中任一项所述的订单处理方法，其特征在于，所述方法还包括：

若所述授信异常类型为未获取到所述授信信息，则确定所述授信异常类型属于所述预设类型；和/或，

若所述授信异常类型为授信超期，则确定所述授信异常类型属于所述预设类型；和/或，

若所述授信异常类型为所述授信信息中剩余授信额度不足，则确定所述授信异常类型属于所述预设类型。

7.根据权利要求1至5中任一项所述的订单处理方法，其特征在于，所述方法还包括：

根据所述能源订单的订单金额执行与能源站的结算操作；

根据所述目标授信用户对应的结算期限内产生的能源订单，确定待支付金额；

根据所述待支付金额执行与所述目标授信用户的结算操作。

8.一种订单处理装置，其特征在于，所述装置包括：

获取模块，用于响应于目标授信用户的下单请求，获取所述目标授信用户的授信信息；

异常监测模块，用于若所述目标授信用户的授信信息存在异常，则确定所述目标授信用户的授信异常类型；

订单处理模块，用于若所述授信异常类型属于预设类型，则根据所述目标授信用户对应的临时授信额度和所述下单请求对应的订单金额，生成能源订单；以及，

若所述授信异常类型不属于所述预设类型，取消生成所述能源订单。

9.一种可读存储介质，其上存储有程序或指令，其特征在于，所述程序或指令被处理器执行时实现如权利要求1至7中任一项所述的订单处理方法的步骤。

10.一种计算机设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1至7中任一项所述的订单处理方法。