业务订单数据的生成方法及装置

本申请为2016年12月19日提交的申请号为201611178175.7，名为“业务订单数据的生成方法及装置”的发明专利申请的分案申请。

技术领域

本申请涉及计算机技术领域，尤其涉及一种业务订单数据的生成方法及装置。

背景技术

传统技术中，在实现业务的过程中，用户会先向第三方服务平台发送请求，第三方服务平台在接收到该请求之后，将其实时地转发至业务方系统，从而由业务方系统对用户的请求进行处理，并通过第三方服务平台将处理结果返回给用户。然而，在实际应用中，仅仅在实现一种业务的过程中，用户就会频繁地向第三方服务平台发送多次请求(比如，在实现用户的投保业务时，用户依次会向互联网保险平台(即第三方服务平台)发送询价请求、投保请求以及出单请求等)，如果第三方服务平台需要将每次的请求都转发至业务方系统进行处理，会造成业务方系统负载压力大的问题；此外，第三方服务平台的并发能力也会受限，由此会造成用户体验差的问题。

发明内容

本申请描述了一种业务订单数据的生成方法及装置，以提高第三方服务平台的并发能力。

第一方面，提供了一种业务订单数据的生成方法，包括：

第三方服务平台接收用户发送的业务请求，其中，所述业务请求包括业务对象的标识信息以及所述用户的描述信息；

根据所述业务对象的标识信息，确定所述业务对象对应的鉴权算法；

根据所述鉴权算法以及所述描述信息，对所述用户进行鉴权；

在对所述用户鉴权通过后，生成所述业务请求对应的支付信息，并输出所述支付信息；

接收第三方支付平台在完成与所述支付信息对应的支付操作后发送的支付结果信息；

根据所述支付结果信息，生成所述业务请求对应的业务订单数据。

第二方面，提供了一种业务订单数据的生成装置，包括：

接收单元，用于接收用户发送的业务请求，其中，所述业务请求包括业务对象的标识信息以及所述用户的描述信息；

确定单元，用于根据所述接收单元接收的所述业务对象的标识信息，确定所述业务对象对应的鉴权算法；

鉴权单元，用于根据所述确定单元确定的所述鉴权算法以及所述描述信息，对所述用户进行鉴权；

生成单元，用于在所述鉴权单元对所述用户鉴权通过后，生成所述业务请求对应的支付信息，并输出所述支付信息；

所述接收单元，还用于接收第三方支付平台在完成与所述支付信息对应的支付操作后发送的支付结果信息；

所述生成单元，还用于根据所述接收单元接收的所述支付结果信息，生成所述业务请求对应的业务订单数据。

本申请提供的业务订单数据的生成方法及装置，第三方服务平台在接收到用户发送的业务请求时，可以直接获取与该业务请求对应的鉴权算法；并根据该鉴权算法对用户进行鉴权；在鉴权通过后，进一步生成相应的支付信息；在用户为支付信息执行相应的支付操作之后，第三方服务平台可直接生成业务订单数据。也即本申请中，第三方服务平台可以不通过与业务方系统进行实时交互，即可生成业务请求对应的业务订单数据，也即实现业务请求对应的业务，从而可以提高第三方服务平台的并发能力。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1为传统的互联网保险平台与保险公司系统的信息交互图；

图2为本申请提供的业务订单数据的生成方法的应用场景示意图；

图3为本申请一种实施例提供的业务订单数据的生成方法流程图；

图4为本申请提供的互联网保险平台与保险公司系统的信息交互图；

图5为本申请另一种实施例提供的业务订单数据的生成装置示意图。

具体实施方式

下面结合附图，对本发明的实施例进行描述。

本申请实施例提供的业务订单数据的生成方法及装置，适用于用户通过第三方服务平台请求实现业务的场景。

如，适用于用户通过互联网保险平台实现投保业务的场景。此处的互联网保险平台可以包括保险业务系统和保险中台，其中，保险业务系统用于接收用户的请求(如，询价请求、投保请求以及出单请求)，并将接收的用户的请求转发至保险中台，其可以包括但不限于购物平台的保险系统、支付平台的保险系统以及理财险系统等；保险中台用于在接收到保险业务系统转发的用户的请求时，通过与保险公司系统(也称保险机构)进行实时的交互来对用户的请求作出响应，从而来实现用户的投保业务。

传统技术中，在实现用户的投保业务时，互联网保险平台与保险公司系统的信息交互图可以如图1所示，图1中，可以包括如下步骤：

步骤110，用户向保险业务系统发送询价请求。

其中，该询价请求可以包括用户所选择的保险产品的标识信息。

步骤120，保险业务系统通过保险中台将询价请求转发至金融超级网关。

此处的金融超级网关属于互联网保险平台所在的公司。

步骤130，金融超级网关将上述询价请求同步至保险机构。

保险机构在接收到询价请求之后，可以根据保险产品的标识信息，确定保险产品所包含的至少一个险种，此处，当险种的个数为一个时，该险种为主险；当险种的个数为多个时，可以包含一个以上的主险以及多个附加险；在确定至少一个险种之后，可以获取该至少一个险种中每个险种对应的定价规则，此处的定价规则可以是指如何对每个险种进行定价的算法，其可以是由保险机构自己定义，可以理解的是，针对不同的险种，其对应的定价规则可以是不相同的；最后根据获取各个险种的定价规则，确定各个险种的价格信息；并对各个险种的价格信息进行汇总之后，可以得到保险产品的价格信息。

步骤140，保险机构通过保险中台向保险业务系统返回询价请求的响应结果。

可以理解的是，此处的响应结果可以包括保险机构确定的保险产品的价格信息。

保险业务系统在接收到询价请求的响应结果之后，可以向用户输出其请求的保险产品的价格信息，也即向用户展示其请求的保险产品的价格信息。

步骤150，用户向保险业务系统发送投保请求。

其中，投保请求可以包括用户待购买的保险产品的标识信息以及用户的描述信息。用户的描述信息可以包括但不限于如下信息：用户的年龄、用户的性别以及用户的标识等信息。

步骤160，保险业务系统向保险中台发送投保请求。

此处，保险中台在接收到保险业务系统发送的投保请求之后，可以生成与投保请求对应的投保订单，其中，该投保订单中可以包括保险产品的标识信息以及用户的描述信息。

步骤170，保险中台通过金融超级网关将投保订单同步至保险机构。

保险机构在接收到投保订单之后，可以根据保险产品的标识信息，确定保险产品所包含的至少一个险种；在确定至少一个险种之后，可以获取该至少一个险种中每个险种对应的核保规则，此处的核保规则可以是指对投保订单进行审核的算法，在一个例子中，该核保规则可以是指对投保订单中的用户的描述信息进行审核的算法，也即对购买保险产品的用户进行鉴权的算法，如，该核保规则可以为：性别：女；年龄：≤30；工资：≥5000等；其也可以是由保险机构自己定义，可以理解的是，针对不同的险种，其对应的核保规则可以是不相同的；最后根据获取的各个险种的核保规则以及用户的描述信息，对用户进行鉴权。

步骤180，保险机构向保险中台返回投保订单的审核结果。

此处的审核结果可以是指对投保订单审核通过或者不通过的结果信息；当审核结果为对投保订单审核通过的结果信息时，保险中台可以通过调用支付平台生成支付订单，该支付订单可以包括用户待购买的保险产品的标识信息以及支付金额等信息。

步骤190，保险中台向保险业务系统返回投保请求的响应结果。

可以理解的是，此处的响应结果可以包括支付订单或者对投保订单审核不通过的信息。

保险业务系统在接收到投保请求的响应结果之后，可以向用户输出或者展示支付订单或者对投保订单审核不通过的信息。

步骤200，用户向保险业务系统发送支付请求。

其中，支付请求可以包括支付订单。

步骤210，保险业务系统将该支付请求转发至极简收银台。

此处的极简收银台属于上述支付平台。极简收银台可以根据接收的支付请求执行相应的支付操作。

步骤220，极简收银台向保险中台返回支付结果。

在完成相应的支付操作之后，极简收银台可以向保险中台返回支付结果。

步骤230，保险中台通过金融超级网关向保险机构发送出单请求。

保险中台在接收到支付结果之后，若该支付结果为用于表示支付成功的信息，则可以根据支付结果，向金融超级网关发送出单请求，之后由金融超级网关将出单请求同步至保险机构，该出单请求可以包括用户已购买的保险产品的标识信息。

步骤240，保险机构生成保单数据。

保险机构在接收到出单请求之后，可以根据保险产品的标识信息，确定保险产品所包含的至少一个险种；在确定至少一个险种之后，可以获取该至少一个险种中每个险种对应的出单规则，此处的出单规则可以是指定义最终生成的保单数据(也称合同)所包含的信息的算法，其可以是由保险机构自己定义，可以理解的是，针对不同的险种，其对应的出单规则可以是不相同的；最后根据获取的各个险种出单规则，生成保单数据。

步骤250，保险机构向保险中台返回出单请求的响应结果。

可以理解的是，此处的响应结果可以包括保险机构生成的保单数据。在接收到该响应结果之后，保险中台还可以生成由其自己定义的保险订单数据，这个保险订单数据和保险机构生成的保单数据对应，主要用作后续理赔和批改的保全服务。

步骤260，保险中台向保险业务系统返回出单请求的结果信息。

此处的出单请求的结果信息如果为用于表示出单成功的信息，则其可以包括保险订单数据，可以理解的是，该保险订单数据与保险机构生成的保单数据是一一对应的；保险业务系统在接收到保险订单数据之后，可以向用户输出或者展示保险订单数据。

而上述出单请求的结果信息如果为用于表述出单失败的信息，则可以自动向用户退款。

从图1中可以看出，保险中台每次接收到用户的请求，都需要与保险公司系统进行交互，以对该请求作出响应。而在实际应用中，互联网保险平台每天可能要接收数以亿计的用户的请求，这使得互联网保险平台与保险公司系统需要频繁地进行信息交互，由此会造成保险公司系统的负载压力大，互联网保险平台的并发能力受限的问题。

为解决上述问题，本申请提出以下改进思路：将保险公司系统定义的定价规则、核保规则以及出单规则(统称为保险规则)内置到保险中台，在保险中台中内置保险规则之后，当保险中台接收到保险业务系统转发的用户的请求时，保险中台可以直接根据内置的保险规则，对用户的请求作出响应；之后当达到设定的发送周期时，才与保险公司系统进行交互。由此可以减少互联网保险平台与保险公司系统的交互次数，从而可以减小保险公司系统的负载压力，并且可以提高互联网保险平台的并发能力。

事实上，不限于保险产品，还有很多其他业务，在实现该业务的过程中，通常需要第三方服务平台与业务方系统进行频繁交互，为此，本申请通过图2和图3来说明本申请针对所有业务所提出的改进方案。

图2为本申请提供的业务订单数据的生成方法的应用场景示意图，图2中，第三方服务平台可以预置业务对象对应的算法，如，定价算法和/或鉴权算法等，该算法可以是由业务方系统定义的，上述业务对象包括但不限于保险产品、理财产品等业务请求所请求的对象；第三方服务平台可以不与业务方系统进行实时交互，而是周期性(如，以天或者小时为单位)与业务方系统进行交互；第三方支付平台可以与第三方服务平台进行信息交互，从而实现针对业务对象的支付操作；业务方系统用于实现数据的落地(如，实现保单数据的落地)。具体地，在发送周期到达之前，第三方服务平台在接收到用户的业务请求时，可以直接根据预置的算法，对该业务请求作出响应，并最终生成与该业务请求对应的业务订单数据；而在发送周期到达之后，根据在该时间片段内生成的业务订单数据，创建对应于该时间片段的业务订单数据文件，并将创建的业务订单数据文件发送至业务方系统，从而实现数据的真正落地。

图3为本申请一种实施例提供的业务订单数据的生成方法流程图，图3中，所述方法的执行主体可以为图2中的第三方服务平台，如，互联网保险平台，如图3所示，所述方法具体可以包括：

步骤310，第三方服务平台接收用户发送的业务请求。

其中，该业务请求可以包括业务对象的标识信息以及用户的描述信息。此处的业务请求包括但不限于投保请求等。其中，用户的描述信息是由用户输入的，其可以包括但不限于如下信息：用户的年龄、用户的性别以及用户的标识等信息。

可选地，在该业务请求中包括的业务对象具有价格等属性信息时，如，在业务对象为保险产品时，则在步骤310之前，还可以执行如下步骤：

步骤A：接收用户发送的对业务对象的询价请求。

其中，该询价请求可以包括业务对象的标识信息。

步骤B：根据业务对象的标识信息，确定业务对象包含的至少一个业务单元。

此处的业务单元包括主业务单元和附加业务单元。具体地，在该业务单元的个数为一个时，则该一个业务单元为主业务单元；而在该业务单元的个数为多个时，可以包含一个以上主业务单元以及多个附加业务单元。

步骤C：获取至少一个业务单元中每个业务单元对应的定价算法。

因为不同业务单元，其对应的价格通常是不一样的，所以需要先确定该业务对象所包含的每个业务单元对应的定价算法。如，保险产品所包含的不同的险种，其通常对应不同的价格。

步骤D：根据定价算法，确定各个业务单元的价格信息。

步骤E：根据各个业务单元的价格信息，确定业务对象的价格信息。

在确定出各个业务单元的价格信息之后，通过对各个业务单元的价格信息进行汇总，就可以获得业务对象的价格信息。

步骤F：向用户返回业务对象的价格信息。

在用户查看业务对象的价格信息之后，可以向第三方服务平台发送上述业务请求。

步骤320，根据业务对象的标识信息，确定业务对象对应的鉴权算法。

其中，步骤320具体可以包括：

根据业务对象的标识信息，确定业务对象包含的至少一个业务单元；

获取至少一个业务单元中每个业务单元对应的鉴权算法。

上述鉴权算法可以是由业务方系统定义的，具体地，业务方系统是以业务单元为维度来定义鉴权算法的，也即不同的业务单元，其对应的鉴权算法是同的。业务方系统在定义上述鉴权算法之后，由人为或者机器将该鉴权算法设置到第三方服务平台中。

具体地，根据业务对象的标识信息，可以唯一地确定一个业务对象，从而可以确定该业务对象所包含的至少一个业务单元；之后就可以获取每个业务单元对应的鉴权算法。如，根据保险产品的标识信息，可以确定该保险产品所包含的至少一个险种；在确定出至少一个险种之后，可以获取每个险种对应的鉴权算法(如，上述核保规则，也称核保算法)。

步骤330，根据鉴权算法以及描述信息，对用户进行鉴权。

此处，以业务对象为保险产品为例来说，假设该保险产品只包含一个主险种，且与该主险种对应的核保算法为：性别：女；年龄：≤30；工资：≥5000，而用户的描述信息为：性别：女；年龄：25；工资：8000，因为用户的描述信息均满足上述核保规则设定的条件，因此对该用户的鉴权通过。

当然，在实际应用中，在对用户进行鉴权的过程中，还可以根据用户输入的信息，从第三方服务平台或者与其相关的平台获取已记录的用户的信息；之后根据已记录的用户的信息以及用户输入的信息，对用户进行鉴权。如，在用户通过互联网保险平台实现投保业务的场景下，假设用户输入的信息包括了用户的标识信息(如，身份证号)，则可以根据该用户的标识信息，从第三方支付平台获取该用户的交易信息，此处的交易信息通常可以反应用户的消费能力；之后根据用户的交易信息以及用户输入的信息，对用户进行鉴权。

此外，业务方系统也可以向第三方服务平台反馈用户的历史行为数据，从而第三方服务平台可以根据用户输入的信息以及历史行为数据，对用户进行鉴权。如，在用户通过互联网保险平台实现投保业务的场景下，保险公司系统可以向互联网保险平台返回用户的历史理赔信息或者参保信息；从而当互联网保险平台对用户进行鉴权时，可以根据用户输入的信息以及用户的历史理赔信息或者参保信息，对用户进行鉴权。

步骤340，在对用户鉴权通过后，生成业务请求对应的支付信息，并输出支付信息。

在对用户鉴权通过后，可以通过调用第三方支付平台生成支付信息，此处的支付信息可以包括业务对象的标识信息以及支付金额等信息。在一个例子中，第三方服务平台可以通过调用第三方支付平台生成支付订单，并通过该支付订单的形式向用户输出支付信息。

步骤350，接收第三方支付平台在完成与支付信息对应的支付操作后发送的支付结果信息。

在向用户发送支付信息之后，用户可以通过第三方服务平台向第三方支付平台发送支付请求，从而由第三方支付平台执行相应的支付操作，并向第三方服务平台发送支付结果信息，其中，该支付结果信息可以是指支付成功的信息，也可以是指支付失败的信息。

步骤360，根据支付结果信息，生成业务请求对应的业务订单数据。

具体地，在支付结果信息为支付成功的信息时，可以调用第三方支付平台生成业务请求对应的业务订单数据，并向用户输出该业务订单数据，从而实现了用户所请求的业务。

由此可以看出，本申请在第三方服务平台设置鉴权算法之后，第三方服务平台可以直接对用户的业务请求作出响应，并生成业务请求对应的业务订单数据，由此可以避免传统技术中，第三方服务平台每次在接收到用户的业务请求时，都需要与业务方系统进行交互而造成的业务方系统负载压力大、第三方服务平台并发能力差的问题。

可选地，为实现数据的真正落地，本申请还可以设置与业务对象对应的发送周期。在一个例子中，在某一业务对象对实时性要求比较高时，则设置的发送周期可以以小时为单位，也即通过T+h的方式向业务方系统发送业务数据文件，其中，T表示当天，h表示小时；而在另一业务对象对实时性要求比较低时，则设置的发送周期可以以天为单位，也即通过T+1的方式向业务方系统发送业务数据文件，其中，T+1表示第二天。如，在业务对象为保险产品，且该保险产品为退货运费险时，设置的发送周期可以以天为单位；而在该保险产品为车险或者寿险时，设置的发送周期可以以小时为单位。

在设置发送周期时，假设设置的发送周期为8小时，则第三方服务平台每隔8小时(也即发送周期到达时)，根据生成的业务订单数据创建业务订单数据文件；并向业务方系统发送业务订单数据文件；业务方系统在接收到业务数据文件之后，实现数据的真正落地。如，在投保业务的场景下，生成的业务订单数据文件为保险订单数据文件，保险公司系统在接收到保险订单数据文件之后，生成保单数据(也称保单合同)，并将该保单数据返回给用户。

当本申请的业务订单数据的生成方法应用于投保业务的场景时，图2中的第三方服务平台可以是指互联网保险平台，其中，该互联网保险平台包括：保险业务系统和保险中台；业务方系统可以是指保险公司系统(也称保险机构)，且互联网保险平台与保险公司系统之间的信息交互可以如图4所示。图4中，主要包括如下步骤：

步骤410，用户向保险业务系统发送询价请求。

其中，该询价请求可以包括用户所选择的保险产品的标识信息。此处的保险产品包括但不限于车险、寿险以及退货运费险等。

步骤420，保险业务系统将询价请求转发至保险中台。

步骤430，保险中台确定保险产品的价格信息。

具体地，保险中台可以根据保险产品的标识信息，确定保险产品所包含的至少一个险种，此处，当险种的个数为一个时，该险种为主险；当险种的个数为多个时，可以包含一个以上的主险以及多个附加险；在确定至少一个险种之后，可以获取该至少一个险种中每个险种对应的定价算法(也称定价规则)，此处的定价算法可以是指如何对每个险种进行定价的算法，其可以是由保险机构自己定义，可以理解的是，针对不同的险种，其对应的定价算法可以是不相同的；最后根据获取的各个险种的定价算法，确定各个险种的价格信息；并对各个险种的价格信息进行汇总之后，可以得到保险产品的价格信息。

步骤440，保险中台向保险业务系统返回保险产品的价格信息。

保险业务系统在接收保险产品的价格信息之后，向用户展示该价格信息。

步骤450，用户向保险业务系统发送投保请求。

其中，投保请求可以包括用户待购买的保险产品的标识信息以及用户的描述信息。用户的描述信息可以包括但不限于如下信息：用户的年龄、用户的性别以及用户的标识等信息。

步骤460，保险业务系统将投保请求转发至保险中台。

此处，保险中台在接收到保险业务系统发送的投保请求之后，可以生成与投保请求对应的投保订单，其中，该投保订单中可以包括保险产品的标识信息以及用户的描述信息。

步骤470，保险中台对投保订单进行审核。

具体地，保险中台在接收到投保订单之后，确定保险产品所包含的至少一个险种；在确定至少一个险种之后，可以获取该至少一个险种中每个险种对应的核保算法，此处的核保算法可以是指对投保订单进行审核的算法，在一个例子中，该核保算法可以是指对投保订单中的用户的描述信息进行审核的算法，也即对购买保险产品的用户进行鉴权的算法，如，该核保算法可以为：性别：女；年龄：≤30；工资：≥5000等；其也可以是由保险机构自己定义，可以理解的是，针对不同的险种，其对应的核保算法可以是不相同的；最后根据获取的核保算法以及用户的描述信息，对用户进行鉴权。

当然，在实际应用中，在对用户进行鉴权的过程中，还可以根据用户输入的信息，从互联网保险平台或者第三方支付平台获取已记录的用户的信息；之后根据已记录的用户的信息以及用户输入的信息，对用户进行鉴权。如在用户输入的信息包括用户的标识信息(如，身份证号)的情况下，可以根据该用户的标识信息，从第三方支付平台获取该用户的交易信息，此处的交易信息通常可以反应用户的消费能力；之后根据用户的交易信息以及用户输入的信息，对用户进行鉴权。

此外，保险公司系统也可以向互联网保险平台反馈用户的历史理赔信息或者参保信息；从而当互联网保险平台对用户进行鉴权时，可以根据用户输入的信息以及用户的历史理赔信息或者参保信息，对用户进行鉴权。

可选地，在对用户鉴权通过后，也即在对投保订单审核通过后，保险中台还可以调用极简收银台生成相应的支付订单，该支付订单可以包括用户待购买的保险产品的标识信息以及支付金额等信息。

步骤480，保险中台向保险业务系统返回支付订单。

保险业务系统在接收到支付订单之后，向用户展示该支付订单。

可以理解的是，在对用户鉴权不通过后，保险中台只向业务系统返回鉴权不通过的结果信息，并且不在执行后续各步骤。

步骤490，用户向保险业务系统发送支付请求。

其中，支付请求可以包括支付订单。

步骤4100，保险业务系统将该支付请求转发至极简收银台。

此处的极简收银台属于第三方支付平台。极简收银台可以根据接收的支付请求执行相应的支付操作。

步骤4110，极简收银台向保险中台返回支付结果。

步骤4120，保险中台生成保险订单数据。

保险中台在接收到支付结果之后，若该支付结果为用于表示支付成功的信息，则可以根据保险产品的标识信息，确定保险产品所包含的至少一个险种；在确定至少一个险种之后，可以获取该至少一个险种中每个险种的出单算法，此处的出单算法可以是指定义最终生成的保险订单数据所包含的信息的算法，其可以是由保险中台自己定义，可以理解的是，针对不同险种，其对应的出单算法可以是不相同的；最后根据获取的各个险种的出单算法，生成保险订单数据。在一个例子中，生成的保险订单数据可以包括但不限于以下信息：投保人的信息、被保人的信息、保额信息、受益人信息、保费信息、险种信息、保险人信息等。

步骤4130，保险中台向保险业务系统返回保险订单数据。

保险业务系统在接收到保险订单数据之后，可以向用户输出或者展示保险订单数据。

步骤4140，当发送周期到达时，保险中台根据生成的保险订单数据创建保险订单数据文件。

步骤4150，保险中台向保险机构发送保险订单数据文件。

步骤4160，保险机构向保险业务系统返回保单数据。

为实现数据的真正落地，本申请还可以为不同的保险产品设置相应的发送周期。在一个例子中，在某一保险产品对实时性要求比较高时，设置的发送周期可以以小时为单位；而在另一保险产品对实时性要求比较低时，则设置的发送周期可以以天为单位。如，在该保险产品为退货运费险时，设置的发送周期可以以天为单位；而在该保险产品为车险或者寿险时，设置的发送周期可以以小时为单位。

在设置发送周期时，假设设置的发送周期为8小时，则保险中台每隔8小时(也即发送周期到达时)，根据生成的保险订单数据创建保险订单数据文件；并向保险机构发送保险订单数据文件；保险机构在接收到保险订单数据文件之后，实现数据的真正落地。如，生成保单数据(也称保单合同)，并将该保单数据返回给用户。

为使本领域技术人员能够更清楚地了解本申请的改进思路，现对本申请的技术方案概括如下：

1)本申请将用户、互联网保险平台、保险公司系统三者之间的实时同步请求链路分解为用户与互联网保险平台的实时请求交互链路及互联网保险平台与保险公司系统间的“T+1/T+h”非实时交互模式，实现快速输出保险订单数据的功能。

2)互联网保险平台具备定价、核保等能力，无需实时依赖保险公司系统，提高了互联网保险平台的灵活处理能力，保证了互联网保险平台的交易并发量与响应时间。

3)互联网保险平台能实时向用户输出保险订单数据。对用户，由“用户-互联网保险平台-保险公司系统”的长链路变为“用户-互联网保险平台”的短链路，减少了请求链路中出现故障的环节，降低了故障率，缩短响应延迟，大大提高了用户体验。

4)互联网保险平台与保险公司系统之间的采用周期性的非实时交互，大大减少对保险公司系统的访问频率和其负载压力，保证其能正常稳定的提供服务。

与上述业务订单数据的生成方法对应地，本申请实施例还提供了业务订单数据的生成装置，如图5所示，该装置包括：

接收单元501，用于接收用户发送的业务请求，其中，该业务请求包括业务对象的标识信息以及用户的描述信息。

确定单元502，用于根据接收单元501接收的业务对象的标识信息，确定业务对象对应的鉴权算法。

可选地，确定单元502具体可以用于：

根据业务对象的标识信息，确定业务对象包含的至少一个业务单元；

获取至少一个业务单元中每个业务单元对应的鉴权算法。

鉴权单元503，用于根据确定单元502确定的鉴权算法以及描述信息，对用户进行鉴权。

生成单元504，用于在鉴权单元503对用户鉴权通过后，生成业务请求对应的支付信息，并输出所述支付信息。

接收单元501，还用于接收第三方支付平台在完成与支付信息对应的支付操作后发送的支付结果信息。

生成单元504，还用于根据接收单元501接收的支付结果信息，生成业务请求对应的业务订单数据。

可选地，该装置还包括：

判断单元505，用于判断发送周期是否到达，其中，发送周期是与业务对象相对应的。

创建单元506，用于当判断单元505判断发送周期到达时，根据生成的业务订单数据创建业务订单数据文件。

发送单元507，用于向业务方系统发送创建单元506创建的业务订单数据文件。

可选地，该装置还包括：获取单元508和返回单元509；

接收单元501，还用于接收用户发送的对业务对象的询价请求，询价请求包括业务对象的标识信息。

确定单元502，还用于根据接收单元501接收的业务对象的标识信息，确定业务对象包含的至少一个业务单元。

获取单元508，用于获取至少一个业务单元中每个业务单元对应的定价算法。

确定单元502，还用于根据获取单元508获取的定价算法，确定各个业务单元的价格信息。

确定单元502，还用于根据各个业务单元的价格信息，确定业务对象的价格信息。

返回单元509，用于向用户返回业务对象的价格信息。

可选地，接收单元501，还用于接收业务方系统发送的用户的历史行为数据。

鉴权单元503具体用于：根据鉴权算法、描述信息以及用户的历史行为数据，对用户进行鉴权。

本申请实施例装置的各功能模块的功能，可以通过上述方法实施例的各步骤来实现，因此，本申请提供的装置的具体工作过程，在此不复赘述。

本申请提供的业务订单数据的生成装置，接收单元501接收用户发送的业务请求；确定单元502根据业务对象的标识信息，确定业务对象对应的鉴权算法；鉴权单元503根据鉴权算法以及描述信息，对用户进行鉴权；生成单元504在对用户鉴权通过后，生成业务请求对应的支付信息，并向用户输出支付信息；接收单元501接收用户在通过第三方支付平台完成与支付信息对应的支付操作后发送的支付结果信息；生成单元504根据支付结果信息，生成业务请求对应的业务订单数据。由此，可以提高业务订单数据的生成装置的并发能力。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。