CN107025604B - Method and device for generating business order data - Google Patents
Method and device for generating business order data Download PDFInfo
- Publication number
- CN107025604B CN107025604B CN201611178175.7A CN201611178175A CN107025604B CN 107025604 B CN107025604 B CN 107025604B CN 201611178175 A CN201611178175 A CN 201611178175A CN 107025604 B CN107025604 B CN 107025604B
- Authority
- CN
- China
- Prior art keywords
- service
- unit
- user
- information
- insurance
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 32
- 230000003993 interaction Effects 0.000 abstract description 11
- 230000004044 response Effects 0.000 description 11
- 230000005540 biological transmission Effects 0.000 description 6
- 230000008569 process Effects 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 230000006872 improvement Effects 0.000 description 4
- 238000012550 audit Methods 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 230000002452 interceptive effect Effects 0.000 description 2
- 238000012937 correction Methods 0.000 description 1
- 230000003203 everyday effect Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000004091 panning Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000026676 system process Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/08—Insurance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
- G06Q20/023—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] the neutral party being a clearing house
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/085—Payment architectures involving remote charge determination or related payment systems
- G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0201—Market modelling; Market analysis; Collecting market data
- G06Q30/0206—Price or cost determination based on market factors
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Theoretical Computer Science (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Entrepreneurship & Innovation (AREA)
- Computer Security & Cryptography (AREA)
- Technology Law (AREA)
- Data Mining & Analysis (AREA)
- Game Theory and Decision Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The application relates to the technical field of computers, in particular to a method and a device for generating business order data, wherein in the method for generating the business order data, a third-party service platform can directly acquire an authentication algorithm corresponding to a business request when receiving the business request sent by a user; and authenticating the user according to the authentication algorithm; after the authentication is passed, further generating corresponding payment information; after the user performs corresponding payment operation for the payment information, the third-party service platform can directly generate business order data. That is, in the present application, the third party service platform may generate the service order data corresponding to the service request without performing real-time interaction with the service party system, that is, implement the service corresponding to the service request, thereby improving the concurrency capability of the third party service platform.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for generating business order data.
Background
In the conventional technology, in the process of implementing a service, a user sends a request to a third-party service platform, and after receiving the request, the third-party service platform forwards the request to a service side system in real time, so that the service side system processes the request of the user, and returns a processing result to the user through the third-party service platform. However, in practical applications, only in the process of implementing one service, the user may frequently send multiple requests to the third-party service platform (for example, when implementing the insurance application service of the user, the user may sequentially send an inquiry request, an insurance application request, and a receipt request to the internet insurance platform (i.e., the third-party service platform), and if the third-party service platform needs to forward each request to the service system for processing, a problem of high load pressure of the service system may be caused; in addition, the concurrency capability of the third party service platform is limited, thereby causing a problem of poor user experience.
Disclosure of Invention
The application describes a method and a device for generating business order data so as to improve the concurrency capability of a third-party service platform.
In a first aspect, a method for generating business order data is provided, including:
a third-party service platform receives a service request sent by a user, wherein the service request comprises identification information of a service object and description information of the user;
determining an authentication algorithm corresponding to the service object according to the identification information of the service object;
authenticating the user according to the authentication algorithm and the description information;
after the user passes the authentication, generating payment information corresponding to the service request, and outputting the payment information;
receiving payment result information sent by a third party payment platform after the payment operation corresponding to the payment information is finished;
and generating service order data corresponding to the service request according to the payment result information.
In a second aspect, an apparatus for generating business order data is provided, including:
a receiving unit, configured to receive a service request sent by a user, where the service request includes identification information of a service object and description information of the user;
a determining unit, configured to determine, according to the identifier information of the service object received by the receiving unit, an authentication algorithm corresponding to the service object;
the authentication unit is used for authenticating the user according to the authentication algorithm and the description information determined by the determination unit;
the generating unit is used for generating payment information corresponding to the service request after the authentication unit passes the authentication of the user and outputting the payment information;
the receiving unit is further used for receiving payment result information sent by a third party payment platform after the payment operation corresponding to the payment information is completed;
the generating unit is further configured to generate service order data corresponding to the service request according to the payment result information received by the receiving unit.
According to the method and the device for generating the business order data, when a third-party service platform receives a business request sent by a user, an authentication algorithm corresponding to the business request can be directly obtained; and authenticating the user according to the authentication algorithm; after the authentication is passed, further generating corresponding payment information; after the user performs corresponding payment operation for the payment information, the third-party service platform can directly generate business order data. That is, in the present application, the third party service platform may generate the service order data corresponding to the service request without performing real-time interaction with the service party system, that is, implement the service corresponding to the service request, thereby improving the concurrency capability of the third party service platform.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
FIG. 1 is a diagram of information interaction between a conventional Internet insurance platform and an insurance company system;
fig. 2 is a schematic view of an application scenario of a method for generating service order data provided in the present application;
fig. 3 is a flowchart of a method for generating service order data according to an embodiment of the present application;
FIG. 4 is an information interaction diagram of the Internet insurance platform and the insurance company system provided by the present application;
fig. 5 is a schematic diagram of a device for generating service order data according to another embodiment of the present application.
Detailed Description
Embodiments of the present invention will be described below with reference to the accompanying drawings.
The method and the device for generating the service order data are suitable for a scene that a user requests to realize a service through a third-party service platform.
For example, the method is suitable for a scene that a user realizes insurance application business through an internet insurance platform. The internet insurance platform herein may include an insurance business system and an insurance central station, wherein the insurance business system is configured to receive requests (e.g., price inquiry requests, insurance application requests, and order output requests) from users, and forward the received requests to the insurance central station, which may include, but is not limited to, an insurance system of a treasure panning network, an insurance system of a treasure payment network, and an insurance management system; the insurance middlebox is used for responding to the user request by interacting with an insurance company system (also called an insurance agency) in real time when receiving the user request forwarded by the insurance business system, thereby realizing the insurance business of the user.
In the conventional technology, when implementing an insurance application service of a user, an information interaction diagram of an internet insurance platform and an insurance company system may be as shown in fig. 1, where in fig. 1, the following steps may be included:
at step 110, the user sends an inquiry request to the insurance business system.
Wherein the inquiry request can include identification information for the insurance product selected by the user.
Step 120, the insurance business system forwards the inquiry request to the finance super gateway through the insurance relay station.
The financial super gateway belongs to ant golden clothes.
In step 130, the financial super gateway synchronizes the request to the insurance agency.
After receiving the inquiry request, the insurance mechanism can determine at least one risk type contained in the insurance product according to the identification information of the insurance product, wherein when the number of the risk types is one, the risk type is a main risk; when the number of the dangerous seeds is multiple, more than one main danger and multiple additional dangers can be contained; after determining the at least one risk category, obtaining a pricing rule corresponding to each risk category in the at least one risk category, where the pricing rule may refer to an algorithm for how to price each risk category, which may be defined by the insurance agency itself, and it is understood that the corresponding pricing rules may be different for different risk categories; finally, determining the price information of each dangerous case according to the pricing rule of each dangerous case; and after the price information of each dangerous species is summarized, the price information of the insurance product can be obtained.
In step 140, the insurance agency returns the response to the request to the insurance business system through the insurance kiosk.
It will be appreciated that the response results herein may include price information for the insurance product as determined by the insurance agency.
After receiving the response result of the inquiry request, the insurance business system can output the price information of the insurance product requested by the user to the user, namely, show the price information of the insurance product requested by the user to the user.
Step 150, the user sends an insurance application request to the insurance business system.
Wherein the application request may include identification information of the insurance product to be purchased by the user and description information of the user. The user's descriptive information may include, but is not limited to, the following information: age of the user, gender of the user, identification of the user, and the like.
Step 160, the insurance business system sends insurance request to the insurance middlebox.
Here, after receiving an insurance request sent by the insurance business system, the insurance intermediate station may generate an insurance order corresponding to the insurance request, where the insurance order may include identification information of the insurance product and description information of the user.
Step 170, the insurance central office synchronizes the insuring order to the insurance institution through the financial super gateway.
After receiving the insurance order, the insurance mechanism can determine at least one risk type contained in the insurance product according to the identification information of the insurance product; after determining at least one risk category, an underwriting rule corresponding to each risk category in the at least one risk category may be obtained, where the underwriting rule may refer to an algorithm for auditing an insured order, and in one example, the underwriting rule may refer to an algorithm for auditing description information of a user in the insured order, that is, an algorithm for authenticating a user who purchases an insurance product, for example, the underwriting rule may be: sex: a woman; age: less than or equal to 30; payroll: not less than 5000, and the like; it can also be defined by the insurance organization, it can be understood that, aiming at different dangerous cases, the corresponding underwriting rules can be different; and finally, authenticating the user according to the acquired insurance rules of each dangerous case and the description information of the user.
And step 180, the insurance agency returns the auditing result of the insurance order to the insurance central station.
The audit result here may refer to the result information that the audit on the insurance order is passed or not passed; when the audit result is the result information that the insurance application order is approved, the insurance central station can generate a payment order by calling the payment system, and the payment order can include the identification information of the insurance product to be purchased by the user, the payment amount and other information.
And 190, returning a response result of the insurance request to the insurance service system by the insurance middlebox.
It is to be understood that the response results herein may include information that the payment order or the underwriting order was not approved.
After receiving the response result of the insurance request, the insurance business system can output or display the payment order or the information that the insurance order cannot be approved to the user.
Step 200, the user sends a payment request to the insurance business system.
Wherein the payment request may include a payment order.
The insurance service system forwards the payment request to a very simple cash register, step 210.
The very simple cash desk here belongs to a pay treasure system. The minimalist cash register may perform a corresponding payment operation according to the received payment request.
Step 220, the miniatur checkout station returns the payment result to the insurance middling station.
After completing the corresponding payment operation, the miniatures cash desk may return the payment result to the insurance midrange.
Step 230, the insurance middlebox sends out a form request to the insurance structure through the financial super gateway.
After the insurance intermediate station receives the payment result, if the payment result is the information indicating that the payment is successful, an order issuing request can be sent to the financial super gateway according to the payment result, and then the financial super gateway synchronizes the order issuing request to the insurance institution, wherein the order issuing request can include the identification information of the insurance products purchased by the user.
At step 240, the insurance agency generates policy data.
After receiving the order issuing request, the insurance mechanism can determine at least one risk category contained in the insurance product according to the identification information of the insurance product; after determining at least one risk category, obtaining an order rule corresponding to each risk category in the at least one risk category, where an order rule may refer to an algorithm defining information included in finally generated policy data (also called a contract), which may be defined by an insurance agency itself, and it is understood that, for different risk categories, corresponding order rules may be different; and finally generating policy data according to the acquired policy issuing rules of all the risk types.
In step 250, the insurance agency returns the response result of the order request to the insurance middlebox.
It will be appreciated that the response results herein may include insurance policy data generated by the insurance mechanism. After receiving the response result, the insurance central station can also generate insurance order data defined by itself, and the insurance order data corresponds to the insurance policy data generated by the insurance institution and is mainly used as a security service for subsequent claims and correction.
Step 260, the insurance central station returns the result information of the order request to the insurance business system.
The result information of the order-out request herein may include insurance order data if it is information indicating that the order-out is successful, and it is understood that the insurance order data corresponds one-to-one to insurance policy data generated by the insurance agency; the insurance business system, upon receiving the insurance order data, can output or present the insurance order data to the user.
And if the result information of the order-out request is information for expressing the order-out failure, the user can be refunded automatically.
As can be seen from fig. 1, each time the insurance central station receives a user's request, it needs to interact with the insurance company system to respond to the request. In practical application, the internet insurance platform may receive requests of hundreds of millions of users every day, which causes the internet insurance platform and the insurance company system to need frequent information interaction, thereby causing the problems of high load pressure of the insurance company system and limited concurrency capability of the internet insurance platform.
In order to solve the above problems, the present application proposes the following improvement: after the insurance rules are built in the insurance center station, when the insurance center station receives a user request forwarded by an insurance service system, the insurance center station can directly respond to the user request according to the built-in insurance rules; and then interacts with the insurance company system when the set transmission period is reached. Therefore, the interaction times of the internet insurance platform and the insurance company system can be reduced, the load pressure of the insurance company system can be reduced, and the concurrency capability of the internet insurance platform can be improved.
In fact, not limited to insurance products, there are many other businesses, and in the process of implementing the business, frequent interaction between the third party service platform and the business side system is usually required, and for this reason, the present application explains the improvement scheme proposed by the present application for all businesses by using fig. 2 and fig. 3.
Fig. 2 is a schematic view of an application scenario of the method for generating business order data provided in the present application, and in fig. 2, a third party service platform may preset an algorithm corresponding to a business object, such as a pricing algorithm and/or an authentication algorithm, which may be defined by a business party system, where the business object includes, but is not limited to, an object requested by a business request such as an insurance product, a financial product, and the like; the third-party service platform may not interact with the business side system in real time, but periodically (e.g., in units of days or hours) interact with the business side system; the third-party payment platform can perform information interaction with the third-party service platform, so that payment operation for the business object is realized; the business side system is used for realizing the landing of data (for example, realizing the landing of policy data). Specifically, before the sending period is reached, when the third-party service platform receives a service request of a user, the third-party service platform can directly respond to the service request according to a preset algorithm, and finally generate service order data corresponding to the service request; and after the sending period is reached, a business order data file corresponding to the time segment is created according to the business order data generated in the time segment, and the created business order data file is sent to a business side system, so that the real landing of the data is realized.
Fig. 3 is a flowchart of a method for generating business order data according to an embodiment of the present disclosure, and in fig. 3, an execution subject of the method may be the third-party service platform in fig. 2, for example, an internet insurance platform, and as shown in fig. 3, the method may specifically include:
in step 310, the third-party service platform receives a service request sent by a user.
The service request may include identification information of the service object and description information of the user. The service request includes but is not limited to an application request and the like. Wherein, the description information of the user is input by the user, which may include but is not limited to the following information: age of the user, gender of the user, identification of the user, and the like.
Optionally, when the business object included in the business request has attribute information such as price, for example, when the business object is an insurance product, before step 310, the following steps may also be performed:
step A: and receiving a request for inquiring the business object sent by the user.
Wherein the query request may include identification information of the business object.
And B: and determining at least one service unit contained in the service object according to the identification information of the service object.
The service units here include a main service unit and an additional service unit. Specifically, when the number of the service units is one, the service unit is a main service unit; when the number of the service units is multiple, more than one main service unit and multiple additional service units can be included.
And C: and acquiring a pricing algorithm corresponding to each service unit in at least one service unit.
Since the prices corresponding to different business units are usually different, a pricing algorithm corresponding to each business unit included in the business object needs to be determined first. For example, insurance products contain different risk categories, which typically correspond to different prices.
Step D: and determining the price information of each service unit according to a pricing algorithm.
Step E: and determining the price information of the business object according to the price information of each business unit.
After the price information of each service unit is determined, the price information of the service object can be obtained by summarizing the price information of each service unit.
Step F: and returning the price information of the business object to the user.
After the user views the price information of the business object, the business request can be sent to the third-party service platform.
And 320, determining an authentication algorithm corresponding to the service object according to the identification information of the service object.
Wherein, step 320 may specifically include:
determining at least one service unit contained in the service object according to the identification information of the service object;
and acquiring an authentication algorithm corresponding to each service unit in at least one service unit.
The authentication algorithm may be defined by a service side system, and specifically, the service side system defines the authentication algorithm by using a service unit as a dimension, that is, different service units, and the corresponding authentication algorithms are the same. After the business side system defines the authentication algorithm, the authentication algorithm is set into a third-party service platform by a person or a machine.
Specifically, according to the identification information of the business object, a business object can be uniquely determined, so that at least one business unit contained in the business object can be determined; then, the authentication algorithm corresponding to each service unit can be obtained. For example, at least one risk category contained in an insurance product may be determined based on the identification information of the insurance product; after at least one risk category is determined, an authentication algorithm (e.g., the above-mentioned underwriting rule, also called underwriting algorithm) corresponding to each risk category may be obtained.
Step 330, authenticating the user according to the authentication algorithm and the description information.
Here, for example, taking a business object as an insurance product, it is assumed that the insurance product only contains one main risk category, and an underwriting algorithm corresponding to the main risk category is as follows: sex: a woman; age: less than or equal to 30; payroll: 5000 or more, and the description information of the user is: sex: a woman; age: 25; payroll: 8000, because the description information of the user meets the condition set by the underwriting rule, the authentication of the user is passed.
Certainly, in practical application, during the process of authenticating the user, the recorded information of the user can be acquired from the third-party service platform or the platform related to the third-party service platform according to the information input by the user; and then authenticating the user according to the recorded information of the user and the information input by the user. For example, in a scenario where a user realizes an insurance application service through an internet insurance platform, assuming that information input by the user includes identification information (e.g., an identification number) of the user, transaction information of the user can be obtained from a payment system according to the identification information of the user, where the transaction information can generally reflect the consumption capability of the user; and then authenticating the user according to the transaction information of the user and the information input by the user.
In addition, the business side system can also feed back historical behavior data of the user to the third-party service platform, so that the third-party service platform can authenticate the user according to the information input by the user and the historical behavior data. For example, in a scenario where a user realizes an insurance application service through an internet insurance platform, the insurance company system may return historical claim settlement information or insurance participation information of the user to the internet insurance platform; therefore, when the internet insurance platform authenticates the user, the user can be authenticated according to the information input by the user and the historical claim settlement information or the participation information of the user.
And 340, after the user passes the authentication, generating payment information corresponding to the service request, and outputting the payment information.
After the user authentication is passed, the payment information may be generated by calling the third party payment platform, where the payment information may include information such as the identification information of the service object and the payment amount. In one example, the third party service platform may generate a payment order by invoking the third party payment platform and output payment information to the user in the form of the payment order.
And 350, receiving payment result information sent by the third-party payment platform after the payment operation corresponding to the payment information is completed.
After sending the payment information to the user, the user may send a payment request to the third-party payment platform through the third-party service platform, so that the third-party payment platform executes a corresponding payment operation, and sends payment result information to the third-party service platform, where the payment result information may refer to information that payment is successful or information that payment is failed.
And step 360, generating service order data corresponding to the service request according to the payment result information.
Specifically, when the payment result information is successful payment information, the third-party payment platform may be invoked to generate service order data corresponding to the service request, and the service order data is output to the user, thereby implementing the service requested by the user.
Therefore, after the authentication algorithm is set by the third-party service platform, the third-party service platform can directly respond to the service request of the user and generate the service order data corresponding to the service request, and therefore the problems that in the traditional technology, the third-party service platform needs to interact with a service party system every time the third-party service platform receives the service request of the user, so that the load pressure of the service party system is high, and the concurrency capability of the third-party service platform is poor can be solved.
Optionally, in order to realize the real landing of the data, the application may further set a sending period corresponding to the service object. In an example, when a certain service object has a relatively high requirement on real-time performance, the set sending period may send a service data file to the service system in units of hours, that is, in a T + h manner, where T represents the current day and h represents an hour; and when the real-time requirement of another service object is lower, the set sending period may be in units of days, that is, the service data file is sent to the service side system in a T +1 manner, where T +1 represents the second day. If the service object is an insurance product and the insurance product is a return freight insurance, the set sending period can be in units of days; and when the insurance product is a car insurance or a life insurance, the set transmission period may be in units of hours.
When a sending period is set, assuming that the set sending period is 8 hours, the third-party service platform creates a service order data file according to the generated service order data every 8 hours (namely when the sending period arrives); and sending a service order data file to the service side system; and the service side system realizes the real landing of the data after receiving the service data file. For example, in a scenario of insuring a service, the generated service order data file is an insurance order data file, and after receiving the insurance order data file, the insurance company system generates insurance policy data (also called a insurance policy contract) and returns the insurance policy data to the user.
When the method for generating business order data of the present application is applied to a scenario of insuring a business, the third-party service platform in fig. 2 may refer to an internet insurance platform, where the internet insurance platform includes: an insurance business system and an insurance central station; the business system may refer to an insurance company system (also called an insurance agency), and the information interaction between the internet insurance platform and the insurance company system may be as shown in fig. 4. In fig. 4, the method mainly includes the following steps:
at step 410, the user sends an inquiry request to the insurance business system.
Wherein the inquiry request can include identification information for the insurance product selected by the user. Insurance products herein include, but are not limited to, car insurance, life insurance, and return freight insurance.
In step 420, the insurance business system forwards the inquiry request to the insurance relay station.
In step 430, the insurance central station determines price information for the insurance product.
Specifically, the insurance intermediate station can determine at least one dangerous species contained in the insurance product according to the identification information of the insurance product, wherein when the number of the dangerous species is one, the dangerous species is a main risk; when the number of the dangerous seeds is multiple, more than one main danger and multiple additional dangers can be contained; after determining the at least one risk category, a pricing algorithm (also called a pricing rule) corresponding to each risk category in the at least one risk category may be obtained, where a pricing algorithm may refer to an algorithm how to price each risk category, which may be defined by the insurance agency itself, and it is understood that corresponding pricing algorithms may be different for different risk categories; finally, determining the price information of each dangerous case according to the obtained pricing algorithm of each dangerous case; and after the price information of each dangerous species is summarized, the price information of the insurance product can be obtained.
At step 440, the insurance middlebox returns price information for the insurance product to the insurance business system.
The insurance business system presents the price information of the insurance product to the user after receiving the price information.
Step 450, the user sends an insurance application request to the insurance business system.
Wherein the application request may include identification information of the insurance product to be purchased by the user and description information of the user. The user's descriptive information may include, but is not limited to, the following information: age of the user, gender of the user, identification of the user, and the like.
Step 460, the insurance business system forwards the application request to the insurance central station.
Here, after receiving an insurance request sent by the insurance business system, the insurance intermediate station may generate an insurance order corresponding to the insurance request, where the insurance order may include identification information of the insurance product and description information of the user.
Step 470, the insurance center reviews the insured order.
Specifically, after receiving an insurance order, the insurance intermediate station determines at least one risk category contained in an insurance product; after determining the at least one risk category, an underwriting algorithm corresponding to each risk category in the at least one risk category may be obtained, where the underwriting algorithm may refer to an algorithm for auditing an insured order, and in one example, the underwriting algorithm may refer to an algorithm for auditing description information of a user in the insured order, that is, an algorithm for authenticating a user who purchases an insurance product, for example, the underwriting algorithm may be: sex: a woman; age: less than or equal to 30; payroll: not less than 5000, and the like; it can also be defined by the insurance institution itself, it can be understood that, aiming at different dangerous species, the corresponding underwriting algorithm can be different; and finally, authenticating the user according to the acquired underwriting algorithm and the description information of the user.
Certainly, in practical application, during the authentication process of the user, the recorded information of the user can be acquired from the internet insurance platform or the payment system according to the information input by the user; and then authenticating the user according to the recorded information of the user and the information input by the user. If the information input by the user includes identification information (e.g., identification number) of the user, the transaction information of the user can be obtained from the payment system according to the identification information of the user, where the transaction information can generally reflect the consuming capability of the user; and then authenticating the user according to the transaction information of the user and the information input by the user.
In addition, the insurance company system can also feed back historical claim settlement information or insurance participation information of the user to the internet insurance platform; therefore, when the internet insurance platform authenticates the user, the user can be authenticated according to the information input by the user and the historical claim settlement information or the participation information of the user.
Optionally, after the user authentication is passed, that is, after the insurance application order is approved, the insurance central station may further invoke the very simple cash desk to generate a corresponding payment order, where the payment order may include information such as identification information and payment amount of an insurance product to be purchased by the user.
In step 480, the insurance middlebox returns a payment order to the insurance business system.
The insurance service system, upon receiving the payment order, presents the payment order to the user.
It can be understood that after the user authentication is not passed, the insurance intermediate station only returns the result information of the authentication failure to the service system, and the subsequent steps are not executed.
At step 490, the user sends a payment request to the insurance service system.
Wherein the payment request may include a payment order.
Step 4100, the insurance business system forwards the payment request to a minimalist cash register.
The very simple cash desk here belongs to a pay treasure system. The minimalist cash register may perform a corresponding payment operation according to the received payment request.
Step 4110, the miniatur checkout station returns the payment result to the insurance middling station.
Step 4120, the insurance central station generates insurance order data.
After the insurance intermediate station receives the payment result, if the payment result is information for indicating successful payment, at least one dangerous case contained in the insurance product can be determined according to the identification information of the insurance product; after determining at least one risk category, an order-issuing algorithm for each risk category in the at least one risk category may be obtained, where an order-issuing algorithm may refer to an algorithm that defines information included in finally generated insurance order data, and may be defined by an insurance center station itself, and it is understood that, for different risk categories, corresponding order-issuing algorithms may be different; and finally, generating insurance order data according to the acquired order-issuing algorithm of each dangerous type. In one example, the generated insurance order data may include, but is not limited to, the following information: information of the applicant, information of the insured person, information of the premium, information of the beneficiary, information of the premium, information of the dangerous kind, information of the insurer, etc.
Step 4130, the insurance central station returns insurance order data to the insurance business system.
The insurance business system, upon receiving the insurance order data, can output or present the insurance order data to the user.
Step 4140, when the transmission period arrives, the insurance central station creates an insurance order data file based on the generated insurance order data.
Step 4150, the insurance central station sends insurance order data files to the insurance agency.
Step 4160, the insurance agency returns policy data to the insurance business system.
In order to realize the real landing of data, the method and the device can also set corresponding sending periods for different insurance products. In one example, when a certain insurance product has a high real-time requirement, the set sending period may be in units of hours; and when the real-time requirement of another insurance product is low, the set transmission period can be in units of days. For example, when the insurance product is a return freight insurance product, the set transmission period may be in units of days; and when the insurance product is a car insurance or a life insurance, the set transmission period may be in units of hours.
When the sending period is set, assuming that the set sending period is 8 hours, the insurance middlebox creates an insurance order data file according to the generated insurance order data every 8 hours (namely when the sending period arrives); and sending insurance order data files to the insurance institution; after receiving the insurance order data file, the insurance mechanism realizes the real landing of the data. For example, policy data (also called a policy contract) is generated and returned to the user.
In order to make the improvement of the present application more clear to those skilled in the art, the technical solution of the present application is summarized as follows:
1) the method and the system decompose a real-time synchronous request link among a user, an internet insurance platform and an insurance company system into a real-time request interactive link between the user and the internet insurance platform and a 'T +1/T + h' non-real-time interactive mode between the internet insurance platform and the insurance company system, and realize the function of rapidly outputting insurance order data.
2) The internet insurance platform has the capabilities of pricing, underwriting and the like, does not need to depend on an insurance company system in real time, improves the flexible processing capacity of the internet insurance platform, and ensures the transaction concurrency and response time of the internet insurance platform.
3) The internet insurance platform can output insurance order data to the user in real time. For the user, a long link of a user-internet insurance platform-insurance company system is changed into a short link of the user-internet insurance platform, so that the links of faults in the request link are reduced, the fault rate is reduced, the response delay is shortened, and the user experience is greatly improved.
4) The periodic non-real-time interaction is adopted between the Internet insurance platform and the insurance company system, so that the access frequency and the load pressure of the insurance company system are greatly reduced, and the normal and stable service can be provided.
Corresponding to the method for generating service order data, as shown in fig. 5, a device for generating service order data provided in the embodiment of the present application includes:
a receiving unit 501, configured to receive a service request sent by a user, where the service request includes identification information of a service object and description information of the user.
The determining unit 502 is configured to determine, according to the identification information of the service object received by the receiving unit 501, an authentication algorithm corresponding to the service object.
Optionally, the determining unit 502 may specifically be configured to:
determining at least one service unit contained in the service object according to the identification information of the service object;
and acquiring an authentication algorithm corresponding to each service unit in at least one service unit.
An authentication unit 503, configured to authenticate the user according to the authentication algorithm and the description information determined by the determination unit 502.
A generating unit 504, configured to generate payment information corresponding to the service request after the authentication unit 503 passes the user authentication, and output the payment information.
The receiving unit 501 is further configured to receive payment result information sent by the third party payment platform after the payment operation corresponding to the payment information is completed.
The generating unit 504 is further configured to generate service order data corresponding to the service request according to the payment result information received by the receiving unit 501.
Optionally, the apparatus further comprises:
a judging unit 505, configured to judge whether a sending period arrives, where the sending period is corresponding to a service object.
A creating unit 506, configured to create a service order data file according to the generated service order data when the determining unit 505 determines that the sending cycle is reached.
A sending unit 507, configured to send the service order data file created by the creating unit 506 to the service system.
Optionally, the apparatus further comprises: an acquisition unit 508 and a return unit 509;
the receiving unit 501 is further configured to receive a query request for the business object sent by a user, where the query request includes identification information of the business object.
The determining unit 502 is further configured to determine at least one service unit included in the service object according to the identification information of the service object received by the receiving unit 501.
An obtaining unit 508, configured to obtain a pricing algorithm corresponding to each service unit in the at least one service unit.
The determining unit 502 is further configured to determine price information of each service unit according to the pricing algorithm obtained by the obtaining unit 508.
The determining unit 502 is further configured to determine price information of the service object according to the price information of each service unit.
A returning unit 509, configured to return price information of the service object to the user.
Optionally, the receiving unit 501 is further configured to receive historical behavior data of the user, which is sent by the service-side system.
The authentication unit 503 is specifically configured to: and authenticating the user according to the authentication algorithm, the description information and the historical behavior data of the user.
The functions of the functional modules of the device in the embodiment of the present application may be implemented through the steps in the method embodiment described above, and therefore, the specific working process of the device provided in the present application is not repeated herein.
In the device for generating service order data provided by the present application, the receiving unit 501 receives a service request sent by a user; the determining unit 502 determines an authentication algorithm corresponding to the service object according to the identification information of the service object; the authentication unit 503 authenticates the user according to the authentication algorithm and the description information; after the user authentication is passed, the generating unit 504 generates payment information corresponding to the service request, and outputs the payment information to the user; the receiving unit 501 receives payment result information sent by a user after completing a payment operation corresponding to the payment information through a third-party payment platform; the generating unit 504 generates service order data corresponding to the service request according to the payment result information. This can improve the concurrency capability of the device for generating the service order data.
Those skilled in the art will recognize that, in one or more of the examples described above, the functions described in this invention may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium.
The above-mentioned embodiments, objects, technical solutions and advantages of the present invention are further described in detail, it should be understood that the above-mentioned embodiments are only exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made on the basis of the technical solutions of the present invention should be included in the scope of the present invention.
Claims (8)
1. A method for generating service order data is characterized by comprising the following steps:
a third-party service platform receives a service request sent by a user, wherein the service request comprises identification information of a service object and description information of the user;
determining an authentication algorithm corresponding to the service object according to the identification information of the service object;
authenticating the user according to the authentication algorithm and the description information;
after the user passes the authentication, generating payment information corresponding to the service request, and outputting the payment information;
receiving payment result information sent by a third party payment platform after the payment operation corresponding to the payment information is finished;
generating service order data corresponding to the service request according to the payment result information;
judging whether a sending period is reached, wherein the sending period corresponds to a business object;
when the sending period is up, creating a service order data file according to the generated service order data;
and sending the service order data file to a service side system.
2. The method of claim 1, wherein the determining the authentication algorithm corresponding to the service object according to the identification information of the service object comprises:
determining at least one service unit contained in the service object according to the identification information of the service object;
and acquiring an authentication algorithm corresponding to each service unit in the at least one service unit.
3. The method of claim 1, before the third-party service platform receives the service request sent by the user, further comprising:
receiving a query request for the business object sent by the user, wherein the query request comprises identification information of the business object;
determining at least one service unit contained in the service object according to the identification information of the service object;
acquiring a pricing algorithm corresponding to each service unit in the at least one service unit;
determining price information of each service unit according to the pricing algorithm;
determining price information of the business object according to the price information of each business unit;
and returning the price information of the business object to the user.
4. The method according to any one of claims 1-3, further comprising:
receiving historical behavior data of the user, which is sent by a service side system;
the authenticating the user according to the authentication algorithm and the description information comprises:
and authenticating the user according to the authentication algorithm, the description information and the historical behavior data of the user.
5. An apparatus for generating service order data, comprising:
a receiving unit, configured to receive a service request sent by a user, where the service request includes identification information of a service object and description information of the user;
a determining unit, configured to determine, according to the identifier information of the service object received by the receiving unit, an authentication algorithm corresponding to the service object;
the authentication unit is used for authenticating the user according to the authentication algorithm and the description information determined by the determination unit;
the generating unit is used for generating payment information corresponding to the service request after the authentication unit passes the authentication of the user and outputting the payment information;
the receiving unit is further used for receiving payment result information sent by a third party payment platform after the payment operation corresponding to the payment information is completed;
the generating unit is further configured to generate service order data corresponding to the service request according to the payment result information received by the receiving unit;
the device comprises a judging unit, a sending unit and a sending unit, wherein the judging unit is used for judging whether a sending period is reached, and the sending period corresponds to a service object;
the creating unit is used for creating a service order data file according to the generated service order data when the judging unit judges that the sending period is reached;
and the sending unit is used for sending the service order data file created by the creating unit to a service side system.
6. The apparatus according to claim 5, wherein the determining unit is specifically configured to:
determining at least one service unit contained in the service object according to the identification information of the service object;
and acquiring an authentication algorithm corresponding to each service unit in the at least one service unit.
7. The apparatus of claim 5, further comprising: an acquisition unit and a return unit;
the receiving unit is further configured to receive a query request for the business object sent by the user, where the query request includes identification information of the business object;
the determining unit is further configured to determine at least one service unit included in the service object according to the identification information of the service object received by the receiving unit;
the acquiring unit is used for acquiring a pricing algorithm corresponding to each service unit in the at least one service unit;
the determining unit is further configured to determine price information of each service unit according to the pricing algorithm acquired by the acquiring unit;
the determining unit is further configured to determine price information of the service object according to the price information of each service unit;
and the return unit is used for returning the price information of the service object to the user.
8. The apparatus according to any one of claims 5 to 7,
the receiving unit is further configured to receive historical behavior data of the user, which is sent by a service side system;
the authentication unit is specifically configured to: and authenticating the user according to the authentication algorithm, the description information and the historical behavior data of the user.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110251111.XA CN112927090B (en) | 2016-12-19 | 2016-12-19 | Method and device for generating service order data |
| CN201611178175.7A CN107025604B (en) | 2016-12-19 | 2016-12-19 | Method and device for generating business order data |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201611178175.7A CN107025604B (en) | 2016-12-19 | 2016-12-19 | Method and device for generating business order data |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110251111.XA Division CN112927090B (en) | 2016-12-19 | 2016-12-19 | Method and device for generating service order data |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107025604A CN107025604A (en) | 2017-08-08 |
| CN107025604B true CN107025604B (en) | 2021-01-12 |
Family
ID=59525536
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201611178175.7A Active CN107025604B (en) | 2016-12-19 | 2016-12-19 | Method and device for generating business order data |
| CN202110251111.XA Active CN112927090B (en) | 2016-12-19 | 2016-12-19 | Method and device for generating service order data |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110251111.XA Active CN112927090B (en) | 2016-12-19 | 2016-12-19 | Method and device for generating service order data |
Country Status (1)
| Country | Link |
|---|---|
| CN (2) | CN107025604B (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114840151A (en) * | 2017-12-04 | 2022-08-02 | 西安艾润物联网技术服务有限责任公司 | Taxi invoice acquisition method and system and computer readable storage medium |
| CN109961360A (en) * | 2017-12-21 | 2019-07-02 | 平安科技（深圳）有限公司 | Financial fee payment method, device and equipment based on insurance business |
| CN108242014A (en) * | 2017-12-26 | 2018-07-03 | 平安科技（深圳）有限公司 | Sale processing method, apparatus, storage medium and the terminal of insurance products |
| CN109949119A (en) * | 2018-06-06 | 2019-06-28 | 北京诚盾诚讯信息技术有限公司 | The support method and system of process of exchange |
| CN109783802A (en) * | 2018-12-13 | 2019-05-21 | 平安医疗健康管理股份有限公司 | A kind of business rule processing method, server and computer readable storage medium |
| CN110188930A (en) * | 2019-05-17 | 2019-08-30 | 深圳前海微众银行股份有限公司 | A kind of method for customizing and device of equity product |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8239281B1 (en) * | 2002-04-10 | 2012-08-07 | At&T Intellectual Property Ii, L.P. | System and methods for purchasing services |
| CN103873558A (en) * | 2014-01-15 | 2014-06-18 | 北京奇虎科技有限公司 | Processing method and system for business object based on third-party platforms |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| NL1015318C2 (en) * | 1999-09-01 | 2003-10-03 | Zelfverzekerd B V | Non-life insurance product SELF-INSURED, application form and (computer) system for it. |
| US20030204425A1 (en) * | 2002-04-30 | 2003-10-30 | Kennedy David V. | Method and apparatus for creating and processing applications |
| US7689444B2 (en) * | 2003-02-19 | 2010-03-30 | Internet Pipeline, Inc. | Electronic insurance application fulfillment system and method |
| US8554916B2 (en) * | 2005-04-11 | 2013-10-08 | Accenture Global Services Gmbh | Service delivery platform and development of new client business models |
| US7567938B1 (en) * | 2005-06-22 | 2009-07-28 | Arch Insurance Group | Method for reimbursing administrators of payments |
| CN101231722B (en) * | 2007-01-22 | 2014-09-17 | 阿里巴巴集团控股有限公司 | System and method of network payment |
| CN101414375A (en) * | 2008-12-15 | 2009-04-22 | 阿里巴巴集团控股有限公司 | System and method for networking trading using intermediate platform |
| CN101546416A (en) * | 2009-04-27 | 2009-09-30 | 谢谦 | Method for remotely treating automobile insurance service and system thereof |
| CN102880947A (en) * | 2011-07-11 | 2013-01-16 | 阿里巴巴集团控股有限公司 | Information interactive method and device of electronic business platform and logistics trading platform |
| CN103428700A (en) * | 2013-07-26 | 2013-12-04 | 中国联合网络通信集团有限公司 | Business authentication method and device |
| CN103699979A (en) * | 2014-01-09 | 2014-04-02 | 吉安万吉物流运输有限公司 | Logistic public information platform system |
| JP6477107B2 (en) * | 2015-03-24 | 2019-03-06 | 日本電気株式会社 | Information processing system, order receiving device, checkout device, information processing method, and program |
| CN104766196B (en) * | 2015-04-14 | 2020-04-28 | 中国科学院计算技术研究所 | Intelligent logistics method and system based on third-party payment online shopping |
| CN106022928A (en) * | 2016-05-25 | 2016-10-12 | 财付通支付科技有限公司 | Data processing method and device |
| CN106204284A (en) * | 2016-06-30 | 2016-12-07 | 北京未来付网络技术有限公司 | The implementation method of the future payment product of a kind of pre-core insurance system and device |
| CN106204288A (en) * | 2016-08-01 | 2016-12-07 | 深圳市永兴元科技有限公司 | Vehicle insurance purchasing method and device |
-
2016
- 2016-12-19 CN CN201611178175.7A patent/CN107025604B/en active Active
- 2016-12-19 CN CN202110251111.XA patent/CN112927090B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8239281B1 (en) * | 2002-04-10 | 2012-08-07 | At&T Intellectual Property Ii, L.P. | System and methods for purchasing services |
| CN103873558A (en) * | 2014-01-15 | 2014-06-18 | 北京奇虎科技有限公司 | Processing method and system for business object based on third-party platforms |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112927090A (en) | 2021-06-08 |
| CN112927090B (en) | 2024-11-01 |
| CN107025604A (en) | 2017-08-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107025604B (en) | Method and device for generating business order data | |
| CN110458562B (en) | Bill reimbursement method, device and equipment and computer storage medium | |
| US10043165B2 (en) | Cloud service integration pay trading system | |
| CN101937598A (en) | Insurance policy output device based on bank teller terminal | |
| US20230289692A1 (en) | Risk management system interface | |
| CN111104556A (en) | Service processing method and device | |
| CN112633954B (en) | Rights and interests processing method and device based on block chain | |
| CN111127224B (en) | Information processing method, information processing device, electronic equipment and storage medium | |
| CN112990991B (en) | Method and device for combined invoicing | |
| CN110909376B (en) | Paid user management method, device and system | |
| CN113177772A (en) | Service data processing method, device and system | |
| CN110782310B (en) | Method, device and system for asynchronously acquiring user attribute information from third-party platform | |
| US20210103918A1 (en) | Generating virtual credit cards when purchasing products from a merchant system | |
| CN111176588B (en) | Service bill issuing method, device, medium and electronic equipment | |
| CN110706051B (en) | Order data aggregation method and device and server | |
| US20090006252A1 (en) | Billing data report system | |
| US20220382775A1 (en) | Employee compensation manager | |
| US11748786B2 (en) | Method and apparatus for serving a digital advertisement having an advertisement identifier | |
| CN112995244B (en) | Subscription withholding method, resource access method and equipment | |
| US20160321620A1 (en) | Method and apparatus for implementing a gateway for managing user subscriptions | |
| KR20170115013A (en) | Method of testing contract, server performing the same and storage medium storing the same | |
| CN114119103A (en) | Point sharing method, device, apparatus, medium, and program product | |
| CA3120507A1 (en) | Employee compensation manager | |
| CN113487413A (en) | Accounting processing method and device, electronic equipment and computer readable medium | |
| CN112488861A (en) | Client historical insurance data method, device, medium and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 1241114 Country of ref document: HK |
|
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20201016 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Innovative advanced technology Co.,Ltd. Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant before: Advanced innovation technology Co.,Ltd. Effective date of registration: 20201016 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Advanced innovation technology Co.,Ltd. Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands Applicant before: Alibaba Group Holding Ltd. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |