CN109461045A - 订单支付方法、系统、计算机设备和存储介质 - Google Patents

Abstract

本申请涉及一种订单支付方法、系统、计算机设备和存储介质。方法包括：发布产品下单页面；产品下单页面包含指定时间；在指定时间之前接收终端基于产品下单页面上传的投保数据；对投保数据进行规则校验，得到核保结论；当投保数据校验通过时，根据核保结论生成目标订单；将目标订单发送至终端，以使终端在指定时间之后支付目标订单；接收终端发送的支付验证请求；支付验证请求携带支付时间标识；当支付时间标识对应的支付时间排序处于前预设位次时，判定订单支付成功。采用本方法优化了业务流程，能够降低平台服务器在抢购时间区间时的负载量。

Description

订单支付方法、系统、计算机设备和存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种订单支付方法、系统、计算机设备和存储介质。

背景技术

随着计算机技术的发展，出现了网络保险。在用户通过保险销售平台对网络保险产品下单之后，平台服务器通常还需要对订单进行核保，只有当用户符合承保条件且成功支付订单的时候才说明已成功购买到网络保险产品，否则订单无效。当需要对特定网络保险产品进行宣传促销时，通常会提供一个抢购时间区间，以使得用户能够在该抢购时间区间内下单抢购有限数量的网络保险产品。传统方式中，平台服务器需要在抢购时间区间内产生的大量订单进行核保和支付判断，容易导致平台服务器的负载量过高，造成平台服务器宕机。

发明内容

基于此，有必要针对上述技术问题，提供一种能够降低平台服务器在抢购时间区间时的负载量的订单支付方法、系统、计算机设备和存储介质。

一种订单支付方法，所述方法包括：发布产品下单页面；所述产品下单页面包含指定时间；在所述指定时间之前接收终端基于所述产品下单页面上传的投保数据；对所述投保数据进行规则校验，得到核保结论；当所述投保数据校验通过时，根据所述核保结论生成目标订单；将所述目标订单发送至所述终端，以使所述终端在所述指定时间之后支付所述目标订单；接收所述终端发送的支付验证请求；所述支付验证请求携带支付时间标识；当所述支付时间标识对应的支付时间排序处于前预设位次时，判定订单支付成功。

在其中一个实施例中，所述投保数据携带产品标识；所述对所述投保数据进行规则校验，得到核保结论，包括：查找与所述产品标识对应的规则库；所述规则库与多个校验指标相对应；从所述投保数据中提取与每个所述校验指标对应的初始指标数据；调用规则引擎基于所述规则库对所述初始指标数据进行校验，得到核保结论。

在其中一个实施例中，所述投保数据携带用户标识；所述方法还包括：在所述指定时间之前查找与所述用户标识对应的用户数据；根据所述用户数据和所述投保数据重新提取与每个所述校验指标对应的目标指标数据；将所述初始指标数据转换为初始散列值，将所述目标指标数据转换为目标散列值；当所述初始散列值与所述目标散列值不一致时，重新调用规则引擎基于所述规则库对所述目标指标数据进行校验，得到更新后的核保结论。

一种订单支付方法，所述方法包括：获取平台服务器发布的产品下单页面；所述产品下单页面包含指定时间；在所述指定时间之前基于所述产品下单页面获取投保数据，以及将所述投保数据发送至平台服务器，以使所述平台服务器对所述投保数据进行规则校验，得到核保结论并根据所述核保结论生成目标订单；接收所述平台服务器发送的所述目标订单；在所述指定时间之后支付所述目标订单，得到支付时间标识；向所述平台服务器发送支付验证请求；所述支付验证请求携带所述支付时间标识；所述支付验证请求用于指示所述平台服务器当所述支付时间标识对应的支付时间排序处于前预设位次时，判定订单支付成功。

在其中一个实施例中，所述在所述指定时间之后支付所述目标订单，得到支付时间标识，包括：在所述指定时间之后基于所述目标订单向支付服务器发送支付请求；所述支付请求携带支付参数；所述支付请求用于指示所述支付服务器验证所述支付参数；当所述支付参数验证通过时，接收所述支付服务器发送的授权请求；基于所述授权请求向所述支付服务器返回授权信息，以使所述支付服务器根据所述授权信息支付所述目标订单；获取所述支付服务器返回支付时间标识。

在其中一个实施例中，所述方法还包括：当所述支付时间标识对应的支付时间排序不处于前预设位次时，接收所述平台服务器发送的订单支付失败信息；所述订单支付失败信息携带订单退款标识；根据所述订单退款标识生成退款请求，将所述退款请求发送至所述支付服务器；所述退款请求用于指示所述支付服务器对所述订单退款标识进行验证；当所述订单退款标识验证通过时，接收所述支付服务器发送的退款结果。

一种订单支付系统，所述系统包括：终端，用于获取平台服务器发布的产品下单页面，所述产品下单页面包含指定时间，在所述指定时间之前基于所述产品下单页面获取投保数据；平台服务器，用于接收所述终端在所述指定时间之前上传的所述投保数据，对所述投保数据进行规则校验，得到核保结论，当所述投保数据校验通过时，根据所述核保结论生成目标订单，将所述目标订单发送至所述终端；支付服务器，用于接收所述终端在所述指定时间之后基于所述目标订单发送的支付请求，根据所述支付请求支付所述目标订单，向所述终端发送支付时间标识；所述终端还用于向所述平台服务器发送支付验证请求；所述支付验证请求携带所述支付时间标识；所述平台服务器还用于当所述支付时间标识对应的支付时间排序处于前预设位次时，判定订单支付成功。

在其中一个实施例中，所述支付请求携带支付参数；所述支付服务器还用于验证所述支付参数，当所述支付参数验证通过时，向所述终端发送授权请求；所述终端还用于向所述支付服务器返回授权信息；所述支付服务器还用于根据所述授权信息支付所述目标订单。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述各个实施例中所述的订单支付方法的步骤。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述各个实施例中所述的订单支付方法的步骤。

上述订单支付方法、系统、计算机设备和存储介质，通过将网络保险产品抢购的过程拆分为两个时间区间，在指定时间之前由终端基于产品下单页面接收用户输入的投保数据，并转发至平台服务器对投保数据进行验证，得到核保结论，当投保数据校验通过时，根据核保结论生成目标订单。终端在收到平台服务器发送的目标订单之后，可在指定时间之后对该目标订单进行支付，并将携带支付时间标识的支付验证请求发送至平台服务器。平台服务器在实际的抢购期间只需要检测支付时间标识对应的支付时间排序是否处于前预设位次时，便能判定用户订单是否支付成功，降低了平台服务器在抢购时期的负载量。

附图说明

图1为一个实施例中订单支付方法的应用场景图；

图2为一个实施例中订单支付方法的流程示意图；

图3为另一个实施例中订单支付方法的流程示意图；

图4为又一个实施例中订单支付方法的时序图；

图5为一个实施例中计算机设备的内部结构图；

图6为另一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的订单支付方法，可以应用于如图1所示的应用环境中。其中，终端102通过网络分别与平台服务器104和支付服务器106进行通信。平台服务器104与支付服务器106通过网络进行通信。其中，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，平台服务器104和支付服务器106可以用独立的服务器或者是多个服务器组成的服务器集群来实现。平台服务器104发布了产品下单页面之后，用户可在指定时间之前通过终端102基于产品下单页面输入投保数据。终端102将投保数据发送至平台服务器104之后，平台服务器104对投保数据进行规则校验，得到核保结论，当核保数据校验通过时，根据核保结论生成目标订单发送至终端 102。终端102在指定时间之后发送支付请求至支付服务器106进行订单支付，支付服务器106返回支付时间标识至终端102。终端102用于根据支付时间标识生成支付验证请求，将支付验证请求发送至平台服务器104。当平台服务器104 检测到支付时间标识对应的支付时间排序处于前预设位次时，则判定订单支付成功。

在一个实施例中，如图2所示，提供了一种订单支付方法，以该方法应用于图1中的平台服务器104为例进行说明，包括以下步骤：

步骤202，发布产品下单页面；产品下单页面包含指定时间。

产品下单页面是指用于销售网络保险产品的页面。指定时间是网络保险产品抢购的开始时间。比如说，指定时间可以是2018年10月1日00:00。

在一个实施例中，产品下单页面中可包含产品抢购的预售时长，比如说两周或一个月。预售时长是指用户可下单但不能对订单进行支付的时长。还可包含产品抢购的抢购时长，比如20分钟或24小时。抢购时长是指用户不可下单但能对已下单的订单进行支付的时长。

步骤204，在指定时间之前接收终端基于产品下单页面上传的投保数据。

投保数据是指用户用于购买网络保险产品所需提供的数据。投保数据包括但不限于用户姓名、年龄、性别、健康数据、相关产品购买数据等其中一种或多种。

在一个实施例中，平台服务器可将产品下单页面下发至终端进行展示，自终端展示该产品下单页面起，至该指定时间，用户可通过终端访问该产品下单页面。用户可通过产品下单页面中的多种控件输入投保数据。产品下单页面中的控件可包含文本输入框、下拉框、勾选框等。

步骤206，对投保数据进行规则校验，得到核保结论。

核保结论包括标准承保、附加条件承保、延期承保和拒保。标准承保是指身体、职业、道德等方面没有明显缺陷的被保险人可按照所制定的标准费率来承保。附加条件承保是指不能按照标准保险费率承保。当核保结论为附加条件承保时，则查找相应的附加条件，比如相应的费率或不能进行购买的保险产品类型或除外责任信息。当用户提供的投保数据符合附加条件承保的情况时，则根据相应的费率计算生成支付金额，核保结论包含该支付金额，用户可根据确定后的支付金额再次选择是否进行抢购。延期承保是指用户当前条件无法承保，但一段时间之后可承保。当核保结论为延期承保时，比较所延期的期限是否在指定时间之前，若是则判定可生成目标订单，若否，则判定无法创建目标订单。拒保是指用户承保风险太大，无法进行承保的情况。举例来说，核保规则可为当用户存在骨折且有内固定的情况时，则该用户不能购买医疗险。若对投保数据进行规则校验发现投保数据中包含骨折情况，则核保结论为拒保。

步骤208，当投保数据校验通过时，根据核保结论生成目标订单。

投保数据校验通过是指核保结论为标准承保、附加条件承保或延期至指定时间之前的延期承保。当核保结论为标准承保和延期至指定时间之前的延期承保时，可按照标准费率计算得到的支付金额生成目标订单。当核保结论为附加条件承保时，可按照附加费率计算得到的支付金额生成目标订单。当核保结论为拒保和延期至指定时间之后的延期承保时，可生成无效订单，以提示用户无法进行订单支付。

步骤210，将目标订单发送至终端，以使终端在指定时间之后支付目标订单。

在一个实施例中，目标订单中可包含支付链接，当终端检测到作用于该支付链接的点击操作时，判断点击时间是否在指定时间之后。若否，则展示无效操作的提示信息。若是，则触发调用支付服务器的支付接口，向支付服务器发送支付请求。支付服务器还可返回订单支付页面，用户授权了之后，支付服务器会基于目标订单中携带的信息完成支付操作。支付服务器还会将支付结果发送至终端，支付结果可携带支付时间标识。

步骤212，接收终端发送的支付验证请求；支付验证请求携带支付时间标识。

支付验证请求是指终端发送给平台服务器的，用于验证终端是否成功完成支付的请求。支付时间标识是指用于记录终端在支付服务器中完成支付操作时间的标识。支付时间标识可以是时间戳。终端在接收了支付服务器发送的支付时间标识之后，可根据支付时间标识生成支付验证请求。

在一个实施例中，支付时间标识还可通过支付服务器的私钥进行加密，由终端转发给平台服务器之后，平台服务器可通过支付服务器的公钥进行解密，以保证支付时间标识的安全性和有效性。

步骤214，当支付时间标识对应的支付时间排序处于前预设位次时，判定订单支付成功。

由于网络保险产品的产品数量为有限的，因此可依据支付时间来判断订单是否支付成功。平台服务器可将所接收到支付验证请求按照支付时间标识对应的支付时间，记录用户的支付时间顺序，并根据支付的时间顺序确定用户是否抢购成功。将支付时间排序处于前预设位次时，判定订单支付成功，即抢购成功。从而能够在有抢购余额的时候已支付成功，但是由于网络拥堵，支付成功消息未能及时传输至平台服务器的情况时，平台服务器能够根据支付时间标识对应的支付时间准确确定用户是否抢购成功。

在一个实施例中，当检测到支付时间标识对应的支付时间排序不处于前预设位次时，即抢购余额为零时，将抢购结束信息发送至终端。终端可根据抢购结束信息将产品下单页面上显示的抢购控件改为失效状态，则终端将不再接收投保数据。

在一个实施例中，在检测到抢购余额为零至更新抢购控件之间的期间，可能也会发生订单支付的情况，但这些支付的订单实际上是没有抢购成功的。因此还需要对这些抢购失败订单进行退款流程。终端可调用支付服务器的退款接口，发送退款请求，退款请求需携带抢购平台标识、订单号、退款单号、订单金额、退款金额、退款原因等。支付服务器将根据退款请求完成退款操作，平台服务器将发送抢购失败提示信息至终端。

上述订单支付方法中，通过将网络保险产品抢购的过程拆分为两个时间区间，在指定时间之前由终端基于产品下单页面接收用户输入的投保数据，并转发至平台服务器对投保数据进行验证，得到核保结论，当投保数据校验通过时，根据核保结论生成目标订单。终端在收到平台服务器发送的目标订单之后，可在指定时间之后对该目标订单进行支付，并将携带支付时间标识的支付验证请求发送至平台服务器。平台服务器在实际的抢购期间只需要检测支付时间标识对应的支付时间排序是否处于前预设位次时，便能判定用户订单是否支付成功，降低了平台服务器在抢购时期的负载量。

在一个实施例中，投保数据携带产品标识；对投保数据进行规则校验，得到核保结论，包括：查找与产品标识对应的规则库；规则库与多个校验指标相对应；从投保数据中提取与每个校验指标对应的初始指标数据；调用规则引擎基于规则库对初始指标数据进行校验，得到核保结论。

产品标识是指产品下单页面对应的网络保险产品的标识。比如网络保险的名称、编号等。由于每种网络保险产品都会有其特定的承保条件，因此可针对网络保险预设规则库用于规则校验。规则库中可包含多个保险业务条件，每个保险业务条件可对应一个或多个校验指标。比如保险业务条件可为被保人的年龄范围为18至60岁、学历水平为高中以上、健康状况优良，则其对应的校验指标分别为被保人的年龄、学历、健康状况。从用户上传的投保数据中提取相应的初始指标数据，比如初始指标数据可用JSON结构记录为{年龄：25；学历：本科；健康：优良}，则将初始指标数据进行规则校验可得出标准承保的核保结论。

在一个实施例中，投保数据携带用户标识，方法还包括：在指定时间之前查找与用户标识对应的用户数据；根据用户数据和投保数据重新提取与每个校验指标对应的目标指标数据；将初始指标数据转换为初始散列值，将目标指标数据转换为目标散列值；当初始散列值与目标散列值不一致时，重新调用规则引擎基于规则库对目标指标数据进行校验，得到更新后的核保结论。

用户提供投保数据的下单时间至指定时间之间，用户的实际情况可能发生变化，而该变化可能影响投保数据，从而影响核保结论。比如说，若网络保险产品的保险业务规则为该产品同一用户只能购买一次，在下单时间用户并无该产品的购买行为，核保结论为标准承保，而若在下单时间至指定时间之间该用户却发生了该产品的购买行为，则核保结论需更新为拒保。

可在指定时间之前的时间区间内对获取的投保数据进行更新校验。比如说在指定时间的前一天查找与用户标识对应的用户数据。举例来说，提供一个网络保险产品，11月11日00：00至12月11日24:00用户可进行投保上传投保数据，平台服务器可根据投保信息进行初次核保得到核保结论生成目标订单发送至终端；12月11日00:00至24:00可对之前已经进行投保数据重新进行规则校验；12月12日00:00至24:00用户可进行抢购支付。

用户数据包括但不限于用户的医疗数据、相关产品购买数据等，根据用户数据判断相较于用户下单时提供的投保数据是否发生变化。目标数据可从投保数据或用户数据中提取，若投保数据和用户数据均包含与校验指标对应的数据，则从用户数据中提取该校验指标对应的目标指标数据。可通过MD5(消息摘要算法第五版)或HASH算法(哈希算法)等散列算法，分别将初始指标数据转换为初始散列值，将目标指标数据转换为目标散列值。通过比较初始散列值和目标散列值是否一致，能够得知投保数据是否发生会影响核保结论的数据更新。若发生了数据更新，则需要重新核保，得到更新后的核保结论，基于更新后的核保结论重新生成目标订单。

在一个实施例中，还可以在指定之间之前设置定时任务，每隔预设时长对所有已经投保的投保数据重新进行批量核保，比如说每周日晚上进行重新核保；还可以实时监测用户是否对已经提交的投保数据进行是否进行了更改，当检测到更改则重新对更改后的投保数据进行核保。

在一个实施例中，如图3所示，提供了另一种订单支付方法，以该方法应用于图1中的终端102为例进行说明，包括以下步骤：

步骤302，获取平台服务器发布的产品下单页面；产品下单页面包含指定时间。

当终端接收到页面访问指令时，向平台服务器发送页面获取请求。平台服务器可向终端返回相应的产品下单页面。产品下单页面是指用于销售网络保险产品的页面。指定时间是产品抢购的开始时间。

步骤304，在指定时间之前基于产品下单页面获取投保数据，以及将投保数据发送至平台服务器，以使平台服务器对投保数据进行规则校验，得到核保结论并根据核保结论生成目标订单。

投保数据是指用户用于购买网络保险产品所需提供的数据。投保数据包括但不限于用户姓名、年龄、性别、健康数据、相关产品购买数据等其中一种或多种。自终端展示该产品下单页面起，至该指定时间，用户可通过终端访问该产品下单页面。用户可通过产品下单页面中的多种控件输入投保数据。产品下单页面中的控件可包含文本输入框、下拉框、勾选框等。终端可将用户输入的投保数据发送至平台服务器以进行核保。

步骤306，接收平台服务器发送的目标订单。

平台服务器可根据核保结论生成目标订单。核保结论包括标准承保、附加条件承保、延期承保和拒保。当核保结论为标准承保和延期至指定时间之前的延期承保时，目标订单中可包含按照标准费率计算得到的支付金额。当核保结论为附加条件承保时，目标订单中可包含按照附加费率计算得到的支付金额。当核保结论为拒保和延期至指定时间之后的延期承保时，目标订单可为无效订单。

步骤308，在指定时间之后支付目标订单，得到支付时间标识。

支付时间标识是指用于记录终端在支付服务器中完成支付操作时间的标识。支付时间标识可以是时间戳。

在一个实施例中，目标订单中可包含支付链接，当终端检测到作用于该支付链接的点击操作时，判断点击时间是否在指定时间之后。若否，则展示无效操作的提示信息。若是，则触发调用支付服务器的支付接口，向支付服务器发送支付请求。支付服务器还可返回订单支付页面，用户授权了之后，支付服务器会基于目标订单中携带的信息完成支付操作。支付服务器还会将支付结果发送至终端，支付结果可携带支付时间标识。

步骤310，向平台服务器发送支付验证请求；支付验证请求携带支付时间标识；支付验证请求用于指示平台服务器当支付时间标识对应的支付时间排序处于前预设位次时，判定订单支付成功。

在一个实施例中，支付时间标识还可通过支付服务器的私钥进行加密，由终端转发给平台服务器之后，若平台服务器可通过支付服务器的公钥对支付时间标识进行解密，说明了该支付时间标识的有效性，再进行下一步的订单支付成功与否的判断。

在一个实施例中，当检测到支付时间标识对应的支付时间排序不处于前预设位次时，即抢购余额为零时，终端可接收平台服务器发送的将抢购结束信息。终端可根据抢购结束信息将产品下单页面上显示的抢购控件改为失效状态，则终端将不再接收投保数据。

上述订单支付方法中，通过将网络保险产品抢购的过程拆分为两个时间区间，在指定时间之前由终端基于产品下单页面接收用户输入的投保数据，并转发至平台服务器对投保数据进行验证，得到核保结论生成目标订单。终端在收到平台服务器发送的目标订单之后，可在指定时间之后对该目标订单进行支付，并将携带支付时间标识的支付验证请求发送至平台服务器进行验证。平台服务器在实际的抢购期间只需要检测支付时间标识对应的支付时间排序是否处于前预设位次时，便能判定用户订单是否支付成功，降低了平台服务器在抢购时期的负载量。

在一个实施例中，在指定时间之后支付目标订单，得到支付时间标识，包括：在指定时间之后基于目标订单向支付服务器发送支付请求；支付请求携带支付参数；支付请求用于指示支付服务器验证支付参数；当支付参数验证通过时，接收支付服务器发送的授权请求；基于授权请求向支付服务器返回授权信息，以使支付服务器根据授权信息支付目标订单；获取支付服务器返回支付时间标识。

在一个实施例中，支付服务器可为第三方支付平台的服务器。终端中可预置第三方支付平台开放的用于调用支付功能的SDK(Software Development Kit，软件开发工具包)。平台服务器与支付服务器可通过网络进行通信。平台服务器可调用支付服务器的接口生成目标订单，目标订单中包含支付参数。平台服务器将包含目标订单发送至终端之后，当用户通过终端点击了目标订单中包含的支付链接或支付控件之后，终端可调用第三方支付平台的SDK，终端可向支付服务器发送包含支付参数的支付请求。支付参数包括但不限于支付金额、支付账号、收款账号等。验证通过之后，用户还需要输入授权信息，比如支付密码或指纹数据。支付服务器对授权信息验证通过之后，可完成该订单的支付，并向终端返回支付结果，支付结果包含支付时间标识。

在一个实施例中，该方法还包括：当支付时间标识对应的支付时间排序不处于前预设位次时，接收平台服务器发送的订单支付失败信息；订单支付失败信息携带订单退款标识；根据订单退款标识生成退款请求，将退款请求发送至支付服务器；退款请求用于指示支付服务器对订单退款标识进行验证；当订单退款标识验证通过时，接收支付服务器发送的退款结果。

平台服务器可通过平台服务器的私钥对订单退款标识进行加密，经过终端转发至支付服务器，若支付服务器可通过平台服务器的公钥对订单退款标识进行解密，则可保障订单退款标识的真实性。支付服务器还可将订单退款标识发送至平台服务器验证其有效性。退款请求可携带抢购平台标识、订单号、退款单号、订单金额、退款账号、退款金额、退款原因等信息。支付服务器将根据退款请求完成退款操作并向终端发送退款结果，平台服务器还可以将发送抢购失败提示信息至终端。

应该理解的是，虽然图2和3的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2和3中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图4所示，提供了又一种订单支付方法的时序图。以该方法应用于图1中的终端102、平台服务器104和支付服务器106为例进行说明。

平台服务器104发布包含指定时间的产品下单页面之后，终端102可在指定时间之前基于产品下单页面获取投保数据。终端102将投保数据发送至平台服务器104，平台服务器104可对投保数据进行规则校验，得到核保结论，并根据核保结论生成目标订单。

平台服务器104将目标订单发送至终端102之后，终端102在指定时间之后可向支付服务器106发送携带支付参数的支付请求。支付服务器106可对支付参数进行验证，当支付参数验证通过时，支付服务器106可向终端102发送授权请求。支付服务器106可根据终端102返回的授权信息进行验证，若验证通过，则支付该目标订单，支付之后支付服务器106还可返回终端102支付时间标识。

终端102可根据支付时间标识生成支付验证请求，并将支付验证请求发送至平台服务器104进行验证。平台服务器104检测到支付时间标识对应的支付时间排序处于前预设位次时，则判定订单支付成功；若检测到支付时间标识对应的支付时间排序不处于前预设位次时，则说明抢购余额不足，用户抢购失败，还可进行退款流程。

上述订单支付方法，平台服务器在指定时间之前对投保数据执行核保流程，生成目标订单。终端在指定时间之后通过支付服务器对目标订单进行支付。通过终端转发支付时间标识至平台服务器，平台服务器在指定时间之后实际上只需要判断支付时间标识对应的支付时间排序是否处于前预设位次，便能准确判断用户是否抢购成功，大大减少了平台服务器在抢购时期的负载量。

在一个实施例中，提供了一种订单支付系统，包括：终端，用于获取平台服务器发布的产品下单页面，产品下单页面包含指定时间，在指定时间之前基于产品下单页面获取投保数据；平台服务器，用于接收终端在指定时间之前上传的投保数据，对投保数据进行规则校验，得到核保结论，当投保数据校验通过时，根据核保结论生成目标订单，将目标订单发送至终端；支付服务器，用于接收终端在指定时间之后基于目标订单发送的支付请求，根据支付请求支付目标订单，向终端发送支付时间标识；终端还用于向平台服务器发送支付验证请求；支付验证请求携带支付时间标识；平台服务器还用于当支付时间标识对应的支付时间排序处于前预设位次时，判定订单支付成功。

在一个实施例中，支付请求携带支付参数；支付服务器还用于验证支付参数，当支付参数验证通过时，向终端发送授权请求；终端还用于向支付服务器返回授权信息；支付服务器还用于根据授权信息支付目标订单。

在一个实施例中，投保数据携带产品标识；平台服务器还用于查找与产品标识对应的规则库；规则库与多个校验指标相对应；从投保数据中提取与每个校验指标对应的初始指标数据；调用规则引擎基于规则库对初始指标数据进行校验，得到核保结论。

在一个实施例中，投保数据携带用户标识；平台服务器还用于在指定时间之前查找与用户标识对应的用户数据；根据用户数据和投保数据重新提取与每个校验指标对应的目标指标数据；将初始指标数据转换为初始散列值，将目标指标数据转换为目标散列值；当初始散列值与目标散列值不一致时，重新调用规则引擎基于规则库对目标指标数据进行校验，得到更新后的核保结论。

在一个实施例中，终端还用于在指定时间之后基于目标订单向支付服务器发送支付请求；支付请求携带支付参数；支付请求用于指示支付服务器验证支付参数；当支付参数验证通过时，接收支付服务器发送的授权请求；基于授权请求向支付服务器返回授权信息，以使支付服务器根据授权信息支付目标订单；获取支付服务器返回支付时间标识。

在一个实施例中，终端还用于当支付时间标识对应的支付时间排序不处于前预设位次时，接收平台服务器发送的订单支付失败信息；订单支付失败信息携带订单退款标识；根据订单退款标识生成退款请求，将退款请求发送至支付服务器；退款请求用于指示支付服务器对订单退款标识进行验证；当订单退款标识验证通过时，接收支付服务器发送的退款结果。

关于订单支付系统的具体限定可以参见上文中对于订单支付方法的限定，在此不再赘述。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图5所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储产品下单页面和规则库等。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种订单支付方法。

在一个实施例中，提供了另一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图6所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种订单支付方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图6和5中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，该存储器存储有计算机程序，该处理器执行计算机程序时实现上述各个实施例中的订单支付方法的步骤。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述各个实施例中的订单支付方法的步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM (EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM (SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM (DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种订单支付方法，所述方法包括：

发布产品下单页面；所述产品下单页面包含指定时间；

在所述指定时间之前接收终端基于所述产品下单页面上传的投保数据；

对所述投保数据进行规则校验，得到核保结论；

当所述投保数据校验通过时，根据所述核保结论生成目标订单；

将所述目标订单发送至所述终端，以使所述终端在所述指定时间之后支付所述目标订单；

接收所述终端发送的支付验证请求；所述支付验证请求携带支付时间标识；

当所述支付时间标识对应的支付时间排序处于前预设位次时，判定订单支付成功。

2.根据权利要求1所述的方法，其特征在于，所述投保数据携带产品标识；所述对所述投保数据进行规则校验，得到核保结论，包括：

查找与所述产品标识对应的规则库；所述规则库与多个校验指标相对应；

从所述投保数据中提取与每个所述校验指标对应的初始指标数据；

调用规则引擎基于所述规则库对所述初始指标数据进行校验，得到核保结论。

3.根据权利要求2所述的方法，其特征在于，所述投保数据携带用户标识；所述方法还包括：

在所述指定时间之前查找与所述用户标识对应的用户数据；

根据所述用户数据和所述投保数据重新提取与每个所述校验指标对应的目标指标数据；

将所述初始指标数据转换为初始散列值，将所述目标指标数据转换为目标散列值；

当所述初始散列值与所述目标散列值不一致时，重新调用规则引擎基于所述规则库对所述目标指标数据进行校验，得到更新后的核保结论。

4.一种订单支付方法，所述方法包括：

获取平台服务器发布的产品下单页面；所述产品下单页面包含指定时间；

在所述指定时间之前基于所述产品下单页面获取投保数据，以及将所述投保数据发送至平台服务器，以使所述平台服务器对所述投保数据进行规则校验，得到核保结论并根据所述核保结论生成目标订单；

接收所述平台服务器发送的所述目标订单；

在所述指定时间之后支付所述目标订单，得到支付时间标识；

向所述平台服务器发送支付验证请求；所述支付验证请求携带所述支付时间标识；所述支付验证请求用于指示所述平台服务器当所述支付时间标识对应的支付时间排序处于前预设位次时，判定订单支付成功。

5.根据权利要求4所述的方法，其特征在于，所述在所述指定时间之后支付所述目标订单，得到支付时间标识，包括：

在所述指定时间之后基于所述目标订单向支付服务器发送支付请求；所述支付请求携带支付参数；所述支付请求用于指示所述支付服务器验证所述支付参数；

当所述支付参数验证通过时，接收所述支付服务器发送的授权请求；

基于所述授权请求向所述支付服务器返回授权信息，以使所述支付服务器根据所述授权信息支付所述目标订单；

获取所述支付服务器返回支付时间标识。

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

当所述支付时间标识对应的支付时间排序不处于前预设位次时，接收所述平台服务器发送的订单支付失败信息；所述订单支付失败信息携带订单退款标识；

根据所述订单退款标识生成退款请求，将所述退款请求发送至所述支付服务器；所述退款请求用于指示所述支付服务器对所述订单退款标识进行验证；

当所述订单退款标识验证通过时，接收所述支付服务器发送的退款结果。

7.一种订单支付系统，其特征在于，所述系统包括：

终端，用于获取平台服务器发布的产品下单页面，所述产品下单页面包含指定时间，在所述指定时间之前基于所述产品下单页面获取投保数据；

平台服务器，用于接收所述终端在所述指定时间之前上传的所述投保数据，对所述投保数据进行规则校验，得到核保结论，当所述投保数据校验通过时，根据所述核保结论生成目标订单，将所述目标订单发送至所述终端；

支付服务器，用于接收所述终端在所述指定时间之后基于所述目标订单发送的支付请求，根据所述支付请求支付所述目标订单，向所述终端发送支付时间标识；

所述终端还用于向所述平台服务器发送支付验证请求；所述支付验证请求携带所述支付时间标识；

所述平台服务器还用于当所述支付时间标识对应的支付时间排序处于前预设位次时，判定订单支付成功。

8.根据权利要求7所述的系统，其特征在于，所述支付请求携带支付参数；

所述支付服务器还用于验证所述支付参数，当所述支付参数验证通过时，向所述终端发送授权请求；

所述终端还用于向所述支付服务器返回授权信息；

所述支付服务器还用于根据所述授权信息支付所述目标订单。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至3中任一项所述方法的步骤；或者

所述处理器执行所述计算机程序时实现权利要求4至6中任一项所述方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至3中任一项所述的方法的步骤；或者

所述计算机程序被处理器执行时实现权利要求4至6中任一项所述的方法的步骤。