CN113298571A - 一种优惠信息处理方法、装置、电子设备以及存储介质 - Google Patents

Abstract

本公开提供了一种优惠信息处理方法、装置、电子设备以及存储介质，其中，该方法包括：响应于待支付订单的支付操作，确定与所述待支付订单相匹配的至少一种优惠策略；在多个预设支付流程中确定与每种优惠策略相匹配的至少一个预设支付流程作为目标支付流程；基于所述目标支付流程确定所述待支付订单在对应优惠策略下的优惠金额，并根据所述优惠金额对所述待支付订单进行结算。本公开实施例能够在不增加相应计算逻辑的基础上，对待支付订单进行结算，从而降低了相应的开发成本，并简化了订单价格的计算逻辑。

Description

一种优惠信息处理方法、装置、电子设备以及存储介质

技术领域

本公开涉及计算机的技术领域，具体而言，涉及一种优惠信息处理方法、装置、电子设备以及存储介质。

背景技术

随着计算机技术的快速发展，现有的货品交易方式已经从线下交易逐渐转化为线上交易。在货品进行线上交易时，需要对该货品所关联订单的价格进行计算。然而，在进行价格计算时，复杂的下单场景会导致订单价格的计算逻辑非常冗长和复杂。例如，该订单包含多种不同类型的优惠信息时，针对每种不同类型的优惠信息都包含各自的计算逻辑，从而根据各自的计算逻辑进行订单价格的计算。然而，当新增一种类型的优惠信息时，需要新增相应的计算逻辑。此时，会相应的增加开发成本，并使得订单价格计算系统越来越冗杂和难以维护。

发明内容

本公开实施例至少提供一种优惠信息处理方法、装置、电子设备以及存储介质。

第一方面，本公开实施例提供了一种优惠信息处理方法，包括：响应于待支付订单的支付操作，确定与所述待支付订单相匹配的至少一种优惠策略；在多个预设支付流程中确定与每种优惠策略相匹配的至少一个预设支付流程作为目标支付流程；基于所述目标支付流程确定所述待支付订单在对应优惠策略下的优惠金额，并根据所述优惠金额对所述待支付订单进行结算。

一种可选的实施方式中，所述基于所述目标支付流程确定所述待支付订单在对应优惠策略下的优惠金额，并根据所述优惠金额对所述待支付订单进行结算，包括：基于所述目标支付流程中的计算流程计算所述待支付订单在对应优惠策略下的优惠金额；基于所述目标支付流程中的第一验证流程验证优惠策略的合法性；基于所述待支付订单在验证出的合法优惠策略下的优惠金额，对所述待支付订单进行结算。

一种可选的实施方式中，所述基于所述待支付订单在验证出的合法优惠策略下的优惠金额，对所述待支付订单进行结算，包括：通过所述目标支付流程中的叠加流程对所述待支付订单在验证出的合法优惠策略下的优惠金额进行叠加，得到叠加优惠金额；根据所述叠加优惠金额对所述待支付订单进行结算。

一种可选的实施方式中，所述根据所述优惠金额对所述待支付订单进行结算，包括：确定所述待支付订单的发起端所选择的实际优惠策略；在所述实际优惠策略中确定与所述至少一种优惠策略相匹配的目标优惠策略；通过所述目标支付流程中的第二验证流程验证所述目标优惠策略的有效性；在验证通过的情况下，基于所述待支付订单在所述目标优惠策略下的优惠金额结算所述待支付订单。

一种可选的实施方式中，所述方法还包括：在所述目标优惠策略的有效性验证通过的情况下，通过所述目标支付流程中的核销流程对所述目标优惠策略中所属于核销类的优惠策略进行核销处理。

一种可选的实施方式中，所述方法还包括：在所述目标优惠策略的有效性验证未通过的情况下，向所述待支付订单的发起端返回验证失败信息，其中，所述验证失败信息中携带验证失败的目标优惠策略的信息。

一种可选的实施方式中，所述确定与所述待支付订单相匹配的至少一种优惠策略，包括：确定所述待支付订单的发起端所属的优惠列表信息；其中，所述优惠列表信息中包含：所述发起端所属的优惠策略和该优惠策略的标识信息，该标识信息用于指示能够使用该优惠策略的货品和/或订单；在所述优惠列表信息中查找与所述待支付订单相匹配的优惠策略作为所述至少一种优惠策略。

一种可选的实施方式中，所述在多个预设支付流程中确定与每种优惠策略相匹配的至少一个预设支付流程作为目标支付流程，包括：确定每种优惠策略的优惠类型，其中，所述优惠类型包括以下至少一种：核销类、非核销类；在目标关联表中查找与所述优惠类型相匹配的至少一个预设支付流程作为目标支付流程。

第二方面，本公开实施例提供了一种优惠信息处理装置，包括：第一确定单元，用于响应于待支付订单的支付操作，确定与所述待支付订单相匹配的至少一种优惠策略；第二确定单元，用于在多个预设支付流程中确定与每种优惠策略相匹配的至少一个预设支付流程作为目标支付流程；第三确定单元，用于基于所述目标支付流程确定所述待支付订单在对应优惠策略下的优惠金额；结算单元，用于根据所述优惠金额对所述待支付订单进行结算。

第三方面，本公开实施例还提供一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行上述第一方面，或第一方面中任一种可选的实施方式中的步骤。

第四方面，本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述第一方面，或第一方面中任一种可选的实施方式中的步骤。

在本公开实施例提供的优惠信息处理方法、装置、电子设备以及存储介质中，预先为多种优惠策略设置了预设支付流程，每种优惠策略都可以在多个预设支付流程中确定与之相匹配的目标支付流程。此时，针对任意一个待支付订单，可以确定与之相匹配的至少一种优惠策略，从而在多个预设支付流程中确定与每种优惠策略相匹配的预设支付流程作为目标支付流程；之后，就可以根据该目标支付流程确定待支付订单在对应优惠策略下的优惠金额，并根据优惠金额对待支付订单进行结算。通过上述描述可知，在本公开提供了一种统一化的订单价格的计算流程，通过该计算流程可以实现对待支付订单在多种优惠策略下的支付流程进行统一化处理。若待支付订单新增了对应的优惠策略，依然可以在不增加相应计算逻辑的基础上，对待支付订单进行统一化结算，从而降低了相应的开发成本，并简化了订单价格的计算逻辑。

为使本公开的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本公开实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，此处的附图被并入说明书中并构成本说明书中的一部分，这些附图示出了符合本公开的实施例，并与说明书一起用于说明本公开的技术方案。应当理解，以下附图仅示出了本公开的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本公开实施例所提供的一种优惠信息处理方法的流程图；

图2示出了本公开实施例所提供的优惠信息处理方法中，确定与待支付订单相匹配的至少一种优惠策略的具体方法的流程图；

图3示出了本公开实施例所提供的优惠信息处理方法中，步骤S106的具体方法的流程图；

图4示出了本公开实施例所提供的优惠信息处理方法中，根据优惠金额对待支付订单进行结算的具体方法的流程图；

图5示出了本公开实施例所提供的一种优惠信息处理方法中订单预览流程的流程图；

图6示出了本公开实施例所提供的一种优惠信息处理方法中订单下单流程的流程图；

图7示出了本公开实施例所提供的一种多个预设支付流程的结构示意图；

图8示出了本公开实施例所提供的一种优惠信息处理装置的示意图；

图9示出了本公开实施例所提供的一种电子设备的示意图。

具体实施方式

为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围，而是仅仅表示本公开的选定实施例。基于本公开的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

本文中术语“和/或”，仅仅是描述一种关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合，例如，包括A、B、C中的至少一种，可以表示包括从A、B和C构成的集合中选择的任意一个或多个元素。

经研究发现，在进行价格计算时，复杂的下单场景会导致订单价格的计算逻辑非常冗长和复杂。例如，该订单包含多种不同类型的优惠信息时，针对每种不同类型的优惠信息都包含各自的计算逻辑，从而根据各自的计算逻辑进行订单价格的计算。然而，当新增一种类型的优惠信息时，需要新增相应的计算逻辑。此时，会相应的增加开发成本，并使得订单价格计算系统越来越冗杂和难以维护。

基于上述研究，本公开提供了一种优惠信息处理方法，该方法提供了一种统一化的订单价格的计算流程，通过该计算流程可以实现对待支付订单在多种优惠策略下的支付流程进行统一化处理。若待支付订单新增了对应的优惠策略，依然可以在不增加相应计算逻辑的基础上，对待支付订单进行结算，从而降低了相应的开发成本，并简化了订单价格的计算逻辑。

为便于对本实施例进行理解，首先对本公开实施例所公开的一种优惠信息处理方法进行详细介绍，本公开实施例所提供的优惠信息处理方法的执行主体一般为具有一定计算能力的电子设备，该电子设备例如包括：终端设备或服务器或其它处理设备，终端设备可以为用户设备(User Equipment，UE)、移动设备、用户终端、终端、蜂窝电话、无绳电话、个人数字助理(Personal Digital Assistant，PDA)、手持设备、计算设备、车载设备、可穿戴设备等。在一些可能的实现方式中，该优惠信息处理方法可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。

参见图1所示，为本公开实施例提供的一种优惠信息处理方法的流程图，所述方法包括步骤S102～S106，其中：

S102：响应于待支付订单的支付操作，确定与所述待支付订单相匹配的至少一种优惠策略。

在本公开实施例中，优惠策略可以包含以下类型的策略：核销类优惠策略、非核销类优惠策略。

核销类优惠策略可以包含以下优惠策略：优惠券、第三方优惠(例如，第三方兑换码)等需要进行核销的优惠。非核销类优惠策略可以包含以下优惠策略：订单满减、订单满包邮、订单赠礼、订单优惠活动等等不需要进行核销的优惠。

这里，待支付订单中所包含的货品可以为任意一种类型的货品，比如，教育类、衣物类、家电类、软件类、食品类等，本公开对待支付订单中所包含货品的类型不作具体限定，以能够实现为准。

针对待支付订单，可以满足一种或多种优惠策略，例如，某待支付订单满足：优惠券；又例如，某待支付订单满足：优惠券和订单满包邮。

因此，在检测到待支付订单的支付操作之后，需要确定与待支付订单相匹配的至少一种优惠策略。

S104：在多个预设支付流程中确定与每种优惠策略相匹配的至少一个预设支付流程作为目标支付流程。

在本公开实施例中，多个预设支付流程为预先设定好的支付流程，每种预设支付流程对应不同的功能，能够实现不同的技术效果。

这里，多个预设支付流程可以包含：可选流程和必选流程。其中，必选流程是与每种优惠策略均匹配的流程；可选流程是指与部分优惠策略相匹配的流程。

在一个可能的实施方式中，必选流程包含：计算流程和验证流程；可选流程包含：查询流程(或者查询最优流程)和核销流程。

需要说明的是，在本公开实施例中，多个预设支付流程的数量并不是固定的，可以根据实际新增的优惠策略新增对应的支付流程，对新增的支付流程此处不作具体限定。

S106：基于所述目标支付流程确定所述待支付订单在对应优惠策略下的优惠金额，并根据所述优惠金额对所述待支付订单进行结算。

在本公开实施例中，在确定出目标支付流程之后，就可以基于目标支付流程中所包含的各个流程(比如，可选流程和必选流程)确定待支付订单在对应优惠策略下的优惠金额，并通过目标支付流程中所包含的流程基于该优惠金额对待支付订单进行结算。

在本公开实施例中，预先为多种优惠策略设置了预设支付流程，每种优惠策略都可以在多个预设支付流程中确定与之相匹配的预设支付流程。此时，针对任意一个待支付订单，可以确定与之相匹配的至少一种优惠策略，从而在多个预设支付流程中确定与每种优惠策略相匹配的预设支付流程作为目标支付流程；之后，就可以根据该目标支付流程确定待支付订单在对应优惠策略下的优惠金额，并根据优惠金额对待支付订单进行结算。通过上述描述可知，在本公开提供了一种统一化的订单价格的计算流程，通过该计算流程可以实现对待支付订单在多种优惠策略下的支付流程进行统一化处理。若待支付订单新增了对应的优惠策略，依然可以在不增加相应计算逻辑的基础上，对待支付订单进行结算，从而降低了相应的开发成本，并简化了订单价格的计算逻辑。

在一个可选的实施方式中，如图2所示，上述步骤S102，确定与所述待支付订单相匹配的至少一种优惠策略，包括如下过程：

步骤S201，确定所述待支付订单的发起端所属的优惠列表信息；其中，所述优惠列表信息中包含：所述发起端所属的优惠策略和该优惠策略的标识信息，该标识信息用于指示能够使用该优惠策略的货品和/或订单。

步骤S202，在所述优惠列表信息中查找与所述待支付订单相匹配的优惠策略作为所述至少一种优惠策略。

这里，待支付订单的发起端可以理解为发起待支付订单的用户(买家或者买货方)，用户可以通过终端设备向用于进行订单处理的服务器发起待支付订单的支付操作，此时，该支付操作可以为待支付订单的订单预览操作。

在检测到待支付订单的订单预览操作之后，服务器可以确定待支付订单的发起端所属的优惠列表信息。比如，可以确定待支付订单的发起端的用户标识信息，该用户标识信息可以理解为用户的账号信息，该账号信息可以为：邮箱、电话号码、身份证号码等信息。

服务器可以根据确定出的发起端的用户标识信息在数据库中查找与该发起端对应的优惠列表信息。该优惠列表信息中包含该发起端所拥有的全部优惠策略，以及每个优惠策略的标识信息。

比如，优惠列表信息中包含的优惠策略为：优惠券、订单满减、订单满包邮、订单赠礼。针对每种优惠策略，都对应设置了标识信息，该标识信息用于指示每种优惠策略的使用范围，比如该使用范围可以是：货品的范围和/或订单的范围。

货品的范围可以理解为能够使用该优惠策略的货品，订单的范围可以理解为能够使用该优惠策略的订单。比如，优惠券所能使用的货品的范围是：食品类和家电类；订单满包邮所能使用的订单的范围是：位于北上广深的买家。

基于此，服务器在获取到该优惠信息列表之后，可以根据优惠策略的标识信息在优惠列表信息中查找与待支付订单相匹配的优惠策略作为至少一种优惠策略，具体查找过程可以描述为下述过程：

在标识信息中查找货品至少一个货品标识信息和至少一个订单标识信息；然后，可以在至少一个订单标识信息中确定与待支付订单相匹配的目标订单标识信息，并将该目标订单标识信息所对应的优惠策略作为至少一种优惠策略中的策略；还可以在至少一个货品订单标识信息中确定待支付订单的货品相匹配的目标货品标识信息，并将该目标货品标识信息所对应的优惠策略作为至少一种优惠策略中的策略。

这里，订单标识信息用于指示能够使用该优惠策略的订单，货品订单标识信息用于指示能够使用该优惠策略的货品。

通过上述描述可知，多个预设支付流程可以包含查询流程。此时，针对步骤S102，可以通过多个预设支付流程中的查询流程在优惠列表信息中查找与待支付订单相匹配的优惠策略作为至少一种优惠策略。

如果查找出每种优惠策略所对应的数量为多个，则可以通过查询流程在优惠列表信息中查找与待支付订单相匹配的最优优惠策略作为至少一种优惠策略，其中，最优优惠策略可以理解为优惠幅度最大的优惠策略。

上述实施方式中，通过标识信息在优惠列表信息中查找与待支付订单相匹配的优惠策略的方式，可以提高至少一种优惠策略的查询效率，同时可以为发起端查询更加面的优惠策略，从而节省了发起端的结算时间。

在一个可选的实施方式中，步骤S104，在多个预设支付流程中确定与每种优惠策略相匹配的至少一个预设支付流程作为目标支付流程，包括如下过程：

(1)、确定每种优惠策略的优惠类型，其中，所述优惠类型包括以下至少一种：核销类、非核销类；

(2)、在目标关联表中查找与所述优惠类型相匹配的至少一个预设支付流程作为目标支付流程。

这里，在确定出至少一种优惠策略之后，还可以确定每种优惠策略的优惠类型。比如，可以预先创建一个数据表，该数据表中包含每种优惠策略所对应的类型标识。该数据表为key-value形式的表格，key表示优惠策略的名称，value表示该优惠策略所对应的类型标识。

在本公开实施例中，类型标识主要包含核销类和非核销类，除此之外，如果所属于相同类型的优惠策略所匹配的预设支付流程不相同，还可以对核销类和非核销类分别进行更加详细的区分，本公开对类型标识的划分过程不作具体限定，以能够实现为准。

在确定出类型标识之后，就可以在目标关联表中查找与每个类型标识相匹配的至少一个预设支付流程作为该优惠策略的目标支付流程。

上述实施方式中，多个预设支付流程为预先设定好的相互独立又具有关联关系的支付流程。通过设置多个预设支付流程，可以满足多种不同类型的优惠策略，通过上述处理方式，可以在不增加相应计算逻辑的基础上，对待支付订单进行结算，从而降低了相应的开发成本，并简化了订单价格的计算逻辑。

在一个可选的实施方式中，如图3所示，步骤S106，基于所述目标支付流程确定所述待支付订单在对应优惠策略下的优惠金额，并根据所述优惠金额对所述待支付订单进行结算，包括如下步骤：

步骤S301，基于所述目标支付流程中的计算流程计算所述待支付订单在对应优惠策略下的优惠金额；

步骤S302，基于所述目标支付流程中的第一验证流程验证优惠策略的合法性；

步骤S303，基于所述待支付订单在验证出的合法优惠策略下的优惠金额，对所述待支付订单进行结算。

在本公开实施例中，针对至少一个优惠策略中的每个优惠策略，在确定出其所对应的目标支付流程之后，可以根据目标支付流程中所包含的必选的计算流程，计算待支付订单在每种优惠策略下的优惠金额。比如，待支付订单在使用优惠券时的优惠金额，待支付订单在使用订单满减时的优惠金额，待支付订单在使用兑换码时的优惠金额。

在确定出上述优惠金额之后，就可以根据目标支付流程中所包含的必选的第一验证流程验证每种优惠策略的合法性。

这里，合法性是指：优惠策略的使用时间是否合法、优惠策略是否适用当前待支付订单等合法性验证。

在对优惠策略进行合法性验证之后，就可以基于所述待支付订单在验证出的合法优惠策略下的优惠金额，对所述待支付订单进行结算，具体包括如下过程：

首先，通过所述目标支付流程中的叠加流程对所述待支付订单在验证出的合法优惠策略下的优惠金额进行叠加，得到叠加优惠金额；然后，根据所述叠加优惠金额对所述待支付订单进行结算。

在本公开实施例中，如果合法优惠策略的数量为多个，则可以在目标支付流程中预先设置一个叠加流程，其中，该叠加流程可以设置在任意一个优惠策略所对应的目标支付流程中，本公开对此不作具体限定。

基于此，在合法优惠策略的数量为多个的情况下，可以通过目标支付流程中的叠加流程对待支付订单在验证出的合法优惠策略下的优惠金额进行叠加，得到叠加优惠金额，从而根据叠加优惠金额对待支付订单进行计算，具体叠加流程可以描述如下：

在合法优惠策略为多个的情况下，在数据库中查询与多个合法优惠策略相匹配的优惠金额的叠加策略；然后按照叠加策略对待支付订单在每种合法优惠策略下的优惠金额进行叠加，得到叠加优惠金额。

具体地，可以判断多个合法优惠策略之间是否存在叠加矛盾，其中，叠加矛盾是指两个合法优惠策略不允许同时使用。如果不存在，则按照默认的叠加策略进行叠加，其中，默认的叠加策略是指对每个合法优惠策略所对应的优惠金额进行汇总，从而计算出待支付订单的总优惠金额(也即，叠加优惠金额)。

如果判断出存在叠加矛盾的合法优惠策略，则可以按照最优叠加策略对优惠金额进行叠加，其中，最优叠加策略是指叠加优惠金额最大。

除此之外，还可以按照全面叠加策略对优惠金额进行叠加，其中，全面叠加策略是指计算出多个合法优惠策略所有可能的叠加优惠金额。比如，多个合法优惠策略包含：策略1、策略2和策略3，其中，策略2和策略3存在叠加矛盾，此时，可以将策略1和策略2所对应的优惠金额进行叠加，得到叠加优惠金额1，并将策略1和策略3所对应的优惠金额进行叠加，得到叠加优惠金额2，从而将叠加优惠金额1和叠加优惠金额2一起反馈给发起端，以使发起端根据上述叠加优惠金额进行优惠策略的选择。

在确定出叠加优惠金额之后，可以向待支付订单的发起端返回该叠加优惠金额，同时还可以向发起端返回其所需要支付的实际金额。此时，发起端就可以返回的叠加优惠金额和实际金额提交该待支付订单，以完成待支付订单的结算。

上述实施方式中，通过目标支付流程对确定待支付订单在对应优惠策略下的优惠金额，并根据优惠金额对所述待支付订单进行结算的方式，可以满足多种类型的优惠策略，从而能够统一化的订单价格的计算流程，通过该计算流程可以实现对待支付订单在多种优惠策略下的支付流程进行统一化处理。若待支付订单新增了对应的优惠策略，依然可以在不增加相应计算逻辑的基础上，对待支付订单进行结算，从而降低了相应的开发成本，并简化了订单价格的计算逻辑。

在一个可选的实施方式中，如图4所示，步骤S106，根据所述优惠金额对所述待支付订单进行结算，还包括如下流程：

步骤S401，确定所述待支付订单的发起端所选择的实际优惠策略；

步骤S402，在所述实际优惠策略中确定与所述至少一种优惠策略相匹配的目标优惠策略；

步骤S403，通过所述目标支付流程中的第二验证流程验证所述目标优惠策略的有效性；

步骤S404，在验证通过的情况下，基于所述待支付订单在所述目标优惠策略下的优惠金额结算所述待支付订单；

步骤S405，在所述目标优惠策略的有效性验证通过的情况下，通过所述目标支付流程中的核销流程对所述目标优惠策略中所属于核销类的优惠策略进行核销处理；

步骤S406，在所述目标优惠策略的有效性验证未通过的情况下，向所述待支付订单的发起端返回验证失败信息，其中，所述验证失败信息中携带验证失败的目标优惠策略的信息。

在本公开实施例中，基于目标支付流程确定待支付订单在对应优惠策略下的优惠金额之后，可以通过上述所描述的叠加流程对合法优惠策略所对应的优惠金额进行叠加，从而得到叠加优惠金额，并向待支付订单的发起端返回该叠加优惠金额，同时还可以向发起端返回其所需要支付的实际金额。

待支付订单的发起端可以根据获取到叠加优惠金额和实际金额对待支付订单执行下单操作。服务器在检测到该下单操作之后，就可以根据该下单操作确定发起端所选择的实际优惠策略。并在实际优惠策略中确定与至少一种优惠策略相匹配的目标优惠策略。

为了保证待支付订单的安全交易，还需要验证目标优惠策略的有效性。比如，发起端在11:59进行订单的预览，在12:01提交该订单，然而，针对该订单的某个优惠策略来说有效期为12:00之前。因此，在检测到下单操作之后，需要对目标优惠策略进行有效性验证。

在有效性验证通过的情况下，一种可选的实施方式是基于待支付订单在所述目标优惠策略下的优惠金额结算所述待支付订单。

在有效性验证通过的情况下，另一种可选的实施方式是通过所述目标支付流程中的核销流程对所述目标优惠策略中所属于核销类的优惠策略进行核销处理。

也就是说，在有效性验证通过的情况下，需要在目标优惠策略中确定核销类的优惠策略，然后，按照目标支付流程中可选的核销流程对核销类的优惠策略进行核销处理。

在有效性验证未通过的情况下，还可以向待支付订单的发起端返回验证失败信息，其中，验证失败信息中携带验证失败的目标优惠策略的信息。

在一种可选的实施方式中，步骤S106，基于所述目标支付流程确定所述待支付订单在对应优惠策略下的优惠金额，并根据所述优惠金额对所述待支付订单进行结算，还包括如下过程：

为每个优惠策略创建对应的类；并在创建的类中，添加该优惠策略所对应目标支付流程的主程序，其中，该主程序用于运行对应的目标支付流程，主程序的数量与目标支付流程的数量相同。

在创建类，并在类中添加对应的主程序之后，就可以通过添加主程序之后的类确定待支付订单在对应优惠策略下的优惠金额，并根据优惠金额对所述待支付订单进行结算。

通过上述描述可知，在本公开提供了一种统一化的订单价格的计算流程，通过该计算流程可以实现对待支付订单在多种优惠策略下的支付流程进行统一化处理。若待支付订单新增了对应的优惠策略，依然可以在不增加相应计算逻辑的基础上，对待支付订单进行结算，从而降低了相应的开发成本，并简化了订单价格的计算逻辑。

通过上述描述可知，待支付订单的结算流程主要包含订单预览流程和订单下单流程，下面将基于上述两个流程对优惠信息处理方法进行进一步介绍。

需要说明的是，在本实施例中，设定至少一种优惠策略包含：优惠券、订单满减类优惠活动和兑换码。

参见图5所示，为本公开实施例提供的一种优惠信息处理方法中订单预览流程的流程图，该方法具体包括如下流程：

步骤S501，检测待支付订单的订单预览操作。

步骤S502，确定与所述待支付订单相匹配的至少一种优惠策略，其中，至少一种优惠策略包括：优惠券、订单满减类优惠活动和兑换码。

其中，在步骤S502中，可以通过多个预设支付流程中的查询流程查找与待支付订单相匹配的优惠券、订单满减类优惠活动。针对兑换码，为发起端发起订单预览操作时在该操作中所携带的优惠策略。

步骤S503，通过计算流程计算待支付订单在优惠券下的优惠金额。

步骤S504，通过计算流程计算待支付订单在订单满减类优惠活动下的优惠金额。

步骤S505，通过计算流程计算待支付订单在在兑换码下的优惠金额。

步骤S506，通过第一验证流程验证优惠券合法性。

步骤S507，通过第一验证流程验证订单满减类优惠活动合法性。

步骤S508，通过第一验证流程验证兑换码合法性。

其中，在步骤S506至步骤S508合法性验证不通过的情况下，向待支付订单的发起端返回错误信息。在步骤S506至步骤S508合法性验证通过，且在合法优惠策略为多个的情况下执行步骤S509。

步骤S509，通过叠加流程对待支付订单在合法优惠策略下的优惠金额进行叠加，得到叠加优惠金额，并向发起端返回该叠加优惠金额。

参见图6所示，为本公开实施例提供的一种优惠信息处理方法中订单下单流程的流程图，该方法具体包括如下流程：

步骤S601，检测待支付订单的下单操作，其中，下单操作中携带实际优惠策略。

步骤S602，在实际优惠策略中确定与至少一种优惠策略相匹配的目标优惠策略。

步骤S603，通过目标支付流程中的第二验证流程验证目标优惠策略的有效性。

其中，在优惠券有效性验证通过的情况下，执行步骤S604；在兑换码有效性验证通过的情况下，执行步骤S605，否则向待支付订单的发起端返回错误信息。

步骤S604，通过核销流程对优惠券进行核销处理。

步骤S605，通过核销流程对兑换码进行核销处理。

参见图7所示，为本公开实施例提供的一种多个预设支付流程的结构示意图，如图7所示，该多个预设支付流程包含：查询流程、验证流程、计算流程和核销流程，下面将分情况对该上述4个流程进行介绍。

情况一、优惠策略为优惠券。

查询流程：查询优惠券(例如，可以是最优优惠券)。

具体地，在待支付订单下单前，可以通过查询流程为用户自动查询最优的优惠券(例如优惠金额最大)。

第一验证流程：验证优惠券。下单后通过服务器验证优惠券是否合法，如果不合法直接返回失败，避免生成无效订单以及消耗其他资源。

计算流程：用于计算待支付订单在该优惠券下的优惠金额和此待支付订单所属用户需要支付的金额。

核销流程：核销优惠券。通过服务器消耗此张优惠券，避免重复使用此优惠券，同时可以和服务器的数据实时对账避免错误。

除此之外，多个预设支付流程还可以包含：校验流程。

校验流程：主要是对用户下单时传入的支付金额二次校验，避免有人恶意篡改订单数据，造成损失。

情况二、优惠策略为订单满减类优惠活动。

查询流程：查询订单满减类优惠活动(例如，可以是最优订单满减类优惠活动)。

具体地，在待支付订单下单前，可以通过查询流程为用户自动查询最优的订单满减类优惠活动(例如优惠金额最大)。

第一验证流程：验证订单满减类优惠活动。下单后通过服务器验证订单满减类优惠活动是否合法，如果不合法直接返回失败，避免生成无效订单以及消耗其他资源。

计算流程：用于计算待支付订单在该订单满减类优惠活动下的优惠金额和此待支付订单所属用户需要支付的金额。

除此之外，多个预设支付流程还可以包含：校验流程。

校验流程：主要是对用户下单时传入的支付金额二次校验，避免有人恶意篡改订单数据，造成损失。

情况三、优惠策略为兑换码。

第一验证流程：验证兑换码。下单后通过服务器验证兑换码是否合法，如果不合法直接返回失败，避免生成无效订单以及消耗其他资源。

计算流程：用于计算待支付订单在该兑换码下的优惠金额和此待支付订单所属用户需要支付的金额。

核销流程：核销兑换码。通过服务器消耗此兑换码，避免重复使用此优惠券，同时可以和服务器的数据实时对账避免错误。

除此之外，多个预设支付流程还可以包含：校验流程。

校验流程：主要是对用户下单时传入的支付金额二次校验，避免有人恶意篡改订单数据，造成损失。

本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。

基于同一发明构思，本公开实施例中还提供了与优惠信息处理方法对应的优惠信息处理装置，由于本公开实施例中的装置解决问题的原理与本公开实施例上述优惠信息处理方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

参照图8所示，为本公开实施例提供的一种优惠信息处理装置的示意图，所述装置包括：第一确定单元81、第二确定单元82、结算单元83；其中，

第一确定单元81，用于响应于待支付订单的支付操作，确定与所述待支付订单相匹配的至少一种优惠策略；

第二确定单元82，用于在多个预设支付流程中确定与每种优惠策略相匹配的至少一个预设支付流程作为目标支付流程；

结算单元83，用于基于所述目标支付流程确定所述待支付订单在对应优惠策略下的优惠金额；并根据所述优惠金额对所述待支付订单进行结算。

在本公开实施例中，预先为多种优惠策略设置了预设支付流程，每种优惠策略都可以在多个预设支付流程中确定与之相匹配的预设支付流程。此时，针对任意一个待支付订单，可以确定与之相匹配的至少一种优惠策略，从而在多个预设支付流程中确定与每种优惠策略相匹配的预设支付流程作为目标支付流程；之后，就可以根据该目标支付流程确定待支付订单在对应优惠策略下的优惠金额，并根据优惠金额对待支付订单进行结算。通过上述描述可知，在本公开提供了一种统一化的订单价格的计算流程，通过该计算流程可以实现对待支付订单在多种优惠策略下的支付流程进行统一化处理。若待支付订单新增了对应的优惠策略，依然可以在不增加相应计算逻辑的基础上，对待支付订单进行结算，从而降低了相应的开发成本，并简化了订单价格的计算逻辑。

一种可能的实施方式中，结算单元83，还用于：基于所述目标支付流程中的计算流程计算所述待支付订单在对应优惠策略下的优惠金额；基于所述目标支付流程中的第一验证流程验证优惠策略的合法性；基于所述待支付订单在验证出的合法优惠策略下的优惠金额，对所述待支付订单进行结算。

一种可能的实施方式中，结算单元83，还用于：通过所述目标支付流程中的叠加流程对所述待支付订单在验证出的合法优惠策略下的优惠金额进行叠加，得到叠加优惠金额；根据所述叠加优惠金额对所述待支付订单进行结算。

一种可能的实施方式中，结算单元83，还用于：确定所述待支付订单的发起端所选择的实际优惠策略；在所述实际优惠策略中确定与所述至少一种优惠策略相匹配的目标优惠策略；通过所述目标支付流程中的第二验证流程验证所述目标优惠策略的有效性；在验证通过的情况下，基于所述待支付订单在所述目标优惠策略下的优惠金额结算所述待支付订单。

一种可能的实施方式中，结算单元83，还用于：在所述目标优惠策略的有效性验证通过的情况下，通过所述目标支付流程中的核销流程对所述目标优惠策略中所属于核销类的优惠策略进行核销处理。

一种可能的实施方式中，结算单元83，还用于：在所述目标优惠策略的有效性验证未通过的情况下，向所述待支付订单的发起端返回验证失败信息，其中，所述验证失败信息中携带验证失败的目标优惠策略的信息。

一种可能的实施方式中，第一确定单元81，还用于：确定所述待支付订单的发起端所属的优惠列表信息；其中，所述优惠列表信息中包含：所述发起端所属的优惠策略和该优惠策略的标识信息，该标识信息用于指示能够使用该优惠策略的货品和/或订单；在所述优惠列表信息中查找与所述待支付订单相匹配的优惠策略作为所述至少一种优惠策略。

一种可能的实施方式中，第二确定单元82，还用于：确定每种优惠策略的优惠类型，其中，所述优惠类型包括以下至少一种：核销类、非核销类；在目标关联表中查找与所述优惠类型相匹配的至少一个预设支付流程作为目标支付流程。

关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明，这里不再详述。

对应于图1中的优惠信息处理方法，本公开实施例还提供了一种电子设备900，如图9所示，为本公开实施例提供的电子设备900结构示意图，包括：

处理器91、存储器92、和总线93；存储器92用于存储执行指令，包括内存921和外部存储器922；这里的内存921也称内存储器，用于暂时存放处理器91中的运算数据，以及与硬盘等外部存储器922交换的数据，处理器91通过内存921与外部存储器922进行数据交换，当所述电子设备900运行时，所述处理器91与所述存储器92之间通过总线93通信，使得所述处理器91执行以下指令：

响应于待支付订单的支付操作，确定与所述待支付订单相匹配的至少一种优惠策略；

在多个预设支付流程中确定与每种优惠策略相匹配的至少一个预设支付流程作为目标支付流程；

基于所述目标支付流程确定所述待支付订单在对应优惠策略下的优惠金额，并根据所述优惠金额对所述待支付订单进行结算。

一种可能的实施方式中，所述处理器901的指令中，基于所述目标支付流程确定所述待支付订单在对应优惠策略下的优惠金额，并根据所述优惠金额对所述待支付订单进行结算，包括：基于所述目标支付流程中的计算流程计算所述待支付订单在对应优惠策略下的优惠金额；基于所述目标支付流程中的第一验证流程验证优惠策略的合法性；基于所述待支付订单在验证出的合法优惠策略下的优惠金额，对所述待支付订单进行结算。

一种可能的实施方式中，所述处理器901的指令中，基于所述待支付订单在验证出的合法优惠策略下的优惠金额，对所述待支付订单进行结算，包括：通过所述目标支付流程中的叠加流程对所述待支付订单在验证出的合法优惠策略下的优惠金额进行叠加，得到叠加优惠金额；根据所述叠加优惠金额对所述待支付订单进行结算。

一种可能的实施方式中，所述处理器901的指令中，根据所述优惠金额对所述待支付订单进行结算，包括：确定所述待支付订单的发起端所选择的实际优惠策略；在所述实际优惠策略中确定与所述至少一种优惠策略相匹配的目标优惠策略；通过所述目标支付流程中的第二验证流程验证所述目标优惠策略的有效性；在验证通过的情况下，基于所述待支付订单在所述目标优惠策略下的优惠金额结算所述待支付订单。

一种可能的实施方式中，所述处理器901的指令中，所述方法还包括：在所述目标优惠策略的有效性验证通过的情况下，通过所述目标支付流程中的核销流程对所述目标优惠策略中所属于核销类的优惠策略进行核销处理。

一种可能的实施方式中，所述处理器901的指令中，所述方法还包括：在所述目标优惠策略的有效性验证未通过的情况下，向所述待支付订单的发起端返回验证失败信息，其中，所述验证失败信息中携带验证失败的目标优惠策略的信息。

一种可能的实施方式中，所述处理器901的指令中，确定与所述待支付订单相匹配的至少一种优惠策略，包括：确定所述待支付订单的发起端所属的优惠列表信息；其中，所述优惠列表信息中包含：所述发起端所属的优惠策略和该优惠策略的标识信息，该标识信息用于指示能够使用该优惠策略的货品和/或订单；在所述优惠列表信息中查找与所述待支付订单相匹配的优惠策略作为所述至少一种优惠策略。

一种可能的实施方式中，所述处理器901的指令中，在多个预设支付流程中确定与每种优惠策略相匹配的至少一个预设支付流程作为目标支付流程，包括：确定每种优惠策略的优惠类型，其中，所述优惠类型包括以下至少一种：核销类、非核销类；在目标关联表中查找与所述优惠类型相匹配的至少一个预设支付流程作为目标支付流程。

本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法实施例中所述的优惠信息处理方法的步骤。其中，该存储介质可以是易失性或非易失的计算机可读取存储介质。

本公开实施例还提供一种计算机程序产品，该计算机程序产品承载有程序代码，所述程序代码包括的指令可用于执行上述方法实施例中所述的优惠信息处理方法的步骤，具体可参见上述方法实施例，在此不再赘述。

其中，上述计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一个可选实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(Software Development Kit，SDK)等等。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本公开所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台电子设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本公开的具体实施方式，用以说明本公开的技术方案，而非对其限制，本公开的保护范围并不局限于此，尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应所述以权利要求的保护范围为准。

Claims (11)

1.一种优惠信息处理方法，其特征在于，包括：

响应于待支付订单的支付操作，确定与所述待支付订单相匹配的至少一种优惠策略；

在多个预设支付流程中确定与每种优惠策略相匹配的至少一个预设支付流程作为目标支付流程；

基于所述目标支付流程确定所述待支付订单在对应优惠策略下的优惠金额，并根据所述优惠金额对所述待支付订单进行结算。

2.根据权利要求1所述的方法，其特征在于，所述基于所述目标支付流程确定所述待支付订单在对应优惠策略下的优惠金额，并根据所述优惠金额对所述待支付订单进行结算，包括：

基于所述目标支付流程中的计算流程计算所述待支付订单在对应优惠策略下的优惠金额；

基于所述目标支付流程中的第一验证流程验证优惠策略的合法性；

基于所述待支付订单在验证出的合法优惠策略下的优惠金额，对所述待支付订单进行结算。

3.根据权利要求2所述的方法，其特征在于，所述基于所述待支付订单在验证出的合法优惠策略下的优惠金额，对所述待支付订单进行结算，包括：

通过所述目标支付流程中的叠加流程对所述待支付订单在验证出的合法优惠策略下的优惠金额进行叠加，得到叠加优惠金额；

根据所述叠加优惠金额对所述待支付订单进行结算。

4.根据权利要求1所述的方法，其特征在于，所述根据所述优惠金额对所述待支付订单进行结算，包括：

确定所述待支付订单的发起端所选择的实际优惠策略；

在所述实际优惠策略中确定与所述至少一种优惠策略相匹配的目标优惠策略；

通过所述目标支付流程中的第二验证流程验证所述目标优惠策略的有效性；

在验证通过的情况下，基于所述待支付订单在所述目标优惠策略下的优惠金额结算所述待支付订单。

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

在所述目标优惠策略的有效性验证通过的情况下，通过所述目标支付流程中的核销流程对所述目标优惠策略中所属于核销类的优惠策略进行核销处理。

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

在所述目标优惠策略的有效性验证未通过的情况下，向所述待支付订单的发起端返回验证失败信息，其中，所述验证失败信息中携带验证失败的目标优惠策略的信息。

7.根据权利要求1至6中任一项所述的方法，其特征在于，所述确定与所述待支付订单相匹配的至少一种优惠策略，包括：

确定所述待支付订单的发起端所属的优惠列表信息；其中，所述优惠列表信息中包含：所述发起端所属的优惠策略和该优惠策略的标识信息，该标识信息用于指示能够使用该优惠策略的货品和/或订单；

在所述优惠列表信息中查找与所述待支付订单相匹配的优惠策略作为所述至少一种优惠策略。

8.根据权利要求1至6中任一项所述的方法，其特征在于，所述在多个预设支付流程中确定与每种优惠策略相匹配的至少一个预设支付流程作为目标支付流程，包括：

确定每种优惠策略的优惠类型，其中，所述优惠类型包括以下至少一种：核销类、非核销类；

在目标关联表中查找与所述优惠类型相匹配的至少一个预设支付流程作为目标支付流程。

9.一种优惠信息处理装置，其特征在于，包括：

第一确定单元，用于响应于待支付订单的支付操作，确定与所述待支付订单相匹配的至少一种优惠策略；

第二确定单元，用于在多个预设支付流程中确定与每种优惠策略相匹配的至少一个预设支付流程作为目标支付流程；

结算单元，用于基于所述目标支付流程确定所述待支付订单在对应优惠策略下的优惠金额；并根据所述优惠金额对所述待支付订单进行结算。

10.一种电子设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如权利要求1至8任一所述的优惠信息处理方法的步骤。

11.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如权利要求1至8任一所述的优惠信息处理方法的步骤。

Images