Order status query method, device and storage medium

Abstract

The present application discloses an order status query method, device and storage medium. When a merchant server does not receive a payment result notification returned by a payment system, it does not directly query the payment status of an order in the payment system. Instead, the merchant server first calculates the purchase probability of the product purchased by the user in the order, the probability of the product being purchased, and the probability of the order being abnormal based on the network environment status, and comprehensively evaluates the probability of inconsistent payment status for the order. Only orders with a probability of inconsistent payment status greater than or equal to a preset threshold for querying the order will continue to query the payment system; and orders with a probability of inconsistent payment status less than the preset threshold for querying the order will no longer query the payment system, thereby reducing the number of order queries in the payment system, thereby reducing the resource overhead cost of order queries, and improving the response speed of order queries.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an order status query method, device, terminal and storage medium. Background Art

[0002] After the user selects the goods or services to be purchased on the e-commerce platform and makes payment, the payment system will notify the e-commerce platform of the payment result of the order, such as payment success or payment failure. However, if there is an abnormality in the system or network environment, the user may have paid the order, but the e-commerce platform will not receive the payment result notification. At this time, the e-commerce platform will mark the order as unpaid, while the order will be paid in the payment system, resulting in inconsistency between the order payment status in the e-commerce platform and the order payment status in the payment system, which in turn affects the e-commerce platform's further processing of the order. Summary of the invention

[0003] In view of this, the present application provides an order status query method, device and storage medium to solve the technical problem that the related technology cannot quickly determine that the order payment status in the e-commerce platform is inconsistent with the order payment status in the payment system, and discloses the following technical solutions:

[0004] To achieve the above objectives, on the one hand, the present application provides an order status query method, the method comprising:

[0005] Obtaining order information of the order to be queried and network status information of the current network environment, wherein the order information includes product information and user information of a user who purchased the product in the order;

[0006] Obtaining a probability of inconsistent payment status of the order to be queried according to the product information, the user information and the network status information, wherein the inconsistent payment status indicates that the user has paid for the order but the order is in an unpaid state;

[0007] When the probability of inconsistency of the payment status of the order to be queried is greater than or equal to a preset threshold for order query, the payment status of the order to be queried in the payment system is queried to obtain an order status result of the order to be queried.

[0008] In a possible implementation, obtaining the probability of inconsistent payment status of the order to be queried according to the product information, the user information, and the network status information includes:

[0009] Obtaining, based on the product information and the user information, a probability that the user pays the order to be queried;

[0010] Obtaining, according to the network status information, a probability that an abnormality occurs in the payment process of the order to be queried;

[0011] The probability of inconsistent payment status of the order to be queried is determined according to the probability that the user pays the order to be queried and the probability that an abnormality occurs in the payment process of the order to be queried.

[0012] In another possible implementation, obtaining, according to the product information and the user information, the probability that the user pays the order to be queried includes:

[0013] Inputting the commodity information and the user information into a purchase rate prediction model to obtain a purchase probability of the user purchasing the commodity;

[0014] Inputting the commodity information into a commodity popularity prediction model to obtain the probability of the commodity being purchased;

[0015] According to the purchase probability of the user purchasing the commodity and the probability of the commodity being purchased, the probability of the user paying the order to be queried is obtained.

[0016] In yet another possible implementation, inputting the product information into a product popularity prediction model to obtain the probability of the product being purchased includes:

[0017] If the product is a historical product, the first listing time of the product is obtained;

[0018] The first listing time and the current time are sent to a historical commodity popularity prediction model to obtain the probability of the commodity being purchased, wherein the historical commodity popularity prediction model is trained by the historical data of the commodity.

[0019] In another possible implementation, inputting the product information into a product popularity prediction model to obtain the probability of the product being purchased includes:

[0020] The product is a newly listed product, and payment data corresponding to the product in at least two different time periods are obtained;

[0021] The payment data is sent to a new commodity popularity prediction model to obtain the probability of the commodity being purchased, wherein the new commodity popularity prediction model includes weight coefficients corresponding to each time period and average payment data.

[0022] In yet another possible implementation, the method further includes:

[0023] When the probability of inconsistency of the payment status of the order to be queried is less than the preset threshold for order query, the step of querying the payment status of the order to be queried in the payment system is not triggered.

[0024] In another possible implementation, the method further includes:

[0025] Obtain the effective order query rate based on the number of orders with inconsistent payment status and the total number of order queries;

[0026] If the effective order checking rate is greater than a preset value, reducing the preset order checking threshold;

[0027] If the effective order-checking rate is less than the preset value, the preset order-checking threshold is increased.

[0028] In another possible implementation, the process of determining the order to be queried includes:

[0029] Orders that have not received payment result notifications returned by the payment system are determined as pending orders.

[0030] On the other hand, the present application also provides an order status query device, comprising:

[0031] Processor and memory;

[0032] Wherein, the processor is used to execute the program stored in the memory;

[0033] The memory is used to store a program, and the program is at least used to:

[0034] Obtaining order information of the order to be queried and network status information of the current network environment, wherein the order information includes product information and user information of a user who purchased the product in the order;

[0035] Obtaining a probability of inconsistent payment status of the order to be queried according to the product information, the user information and the network status information, wherein the inconsistent payment status indicates that the user has paid for the order but the order is unpaid;

[0036] When the probability of inconsistency of the payment status of the order to be queried is greater than or equal to a preset threshold for order query, the payment status of the order to be queried in the payment system is queried to obtain an order status result of the order to be queried.

[0037] On the other hand, the present application provides a storage medium, in which computer executable instructions are stored. When the computer executable instructions are loaded and executed by a processor, the order status query method as described in any one of the above items is implemented.

[0038] On the other hand, the present application also provides a computer program product, which, when executed on an electronic device, is suitable for executing and initializing any of the order status query methods described above.

[0039] The order status query method provided by the present application is that the server obtains the order information of the order to be queried, wherein the order information includes the product information and the user information of the user who purchased the product in the order; and, obtains the network status information of the current network environment; further, the probability of inconsistent payment status of the order to be queried is obtained according to the product information, user information and network status information, wherein inconsistent payment status means that the user has paid the order but the order is in an unpaid state; for orders with inconsistent payment status probability greater than or equal to the preset threshold of the order query, the payment status of the order in the payment system is further queried to obtain the order status result of the order to be queried. It can be seen from the above process that before querying the payment status of the order from the payment system, the scheme first obtains the inconsistent payment status probability of the order, and filters out the orders with a probability less than the preset threshold of the order query, and further only queries the status of the order from the payment system for the orders with a probability greater than the preset threshold of the order query. It can be seen that the scheme reduces the number of orders to be queried from the payment system, thereby reducing the resource overhead cost of order query, and thus improving the response speed of order query. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0041] Figure 1 is a schematic diagram of an order query system provided by an embodiment of the present application;

[0042] Figure 2 This is an optional structural diagram of a distributed system provided by an embodiment of the present invention applied to a blockchain system;

[0043] Figure 3 is an optional schematic diagram of a block structure provided by an embodiment of the present invention;

[0044] Figure 4 is a flow chart of an order status query method provided by an embodiment of the present invention;

[0045] Figure 5 is a flow chart of another order status query method provided by an embodiment of the present invention;

[0046] Figure 6 This is a comparison diagram of the effective order-checking rates of the new and old schemes;

[0047] Figure 7 It is a flow chart of an order status query method provided by an embodiment of the present application;

[0048] Figure 8 It is a structural diagram of an order status query device provided in an embodiment of the present application;

[0049] Fig. 9 It is a structural diagram of another order status query device provided in an embodiment of the present application;

[0050] Fig.10 It is a structural diagram of a terminal provided in an embodiment of the present application. DETAILED DESCRIPTION

[0051] In the related art, when an abnormality occurs in the system or network environment, the user may have paid the order but has not received the payment result notification returned by the payment system. In this case, the e-commerce platform may frequently initiate order query requests to the payment system when it cannot know the order payment result, thereby increasing the resource overhead cost of order query. Moreover, the queried orders may include many invalid queries, such as orders with failed payment, which greatly affects the speed of determining orders with inconsistent status in the e-commerce platform and the payment system. In order to solve the above technical problems, the present application provides an order status query method, which obtains the probability of inconsistent payment status of the order based on the product information and user information in the order, as well as the network status information. The status of the order in the payment system is further queried only when the probability is greater than or equal to the preset threshold of the order query, thereby reducing the number of order queries, thereby reducing the resource overhead cost of order queries, and at the same time improving the order query response speed.

[0052] In order to facilitate understanding of the order query method of the present application, the order query system of the present application is introduced below.

[0053] See also Figure 1 , shows a schematic diagram of an order query system provided in an embodiment of the present application, the system comprising a merchant client 1, a merchant server 2, and a payment server 3.

[0054] The merchant client 1 may be an application program running on a mobile terminal such as a smart phone, a tablet computer, or a smart wearable device, or may be a program running on a terminal device such as a personal computer.

[0055] The merchant server 2 is a server that interacts with the client 1 to provide goods or services to users, such as a merchant server.

[0056] The merchant client 1 and the merchant server 2 interact and communicate with each other through the network 1, and the merchant server 2 and the payment server 3 interact and communicate with each other through the network 2, wherein both the network 1 and the network 2 are the Internet. In order to clearly indicate that the information transmitted between the merchant server 2 and the merchant client 1 and the payment server 3 is different, the networks are represented as network 1 and network 2.

[0057] The payment server 3 is a server or cloud service that provides payment services.

[0058] The server in this application can be an independent server or a server cluster composed of multiple independent servers.

[0059] The user can select the goods to be purchased (such as real goods or virtual goods) and place an order through the merchant client 1. After the user confirms the settlement order, the display interface of the merchant client 1 will enter the settlement interface and jump to the payment page of the payment system. After the display page of the merchant client 1 jumps to the payment page, the user enters the payment information such as the payment password on the payment page and sends it to the payment system (i.e., the payment server 3).

[0060] The payment system may be any system that can provide payment services, such as the WeChat payment system or other payment systems.

[0061] After receiving the user's payment information, the payment server 3 initiates the deduction and returns the payment result notification to the merchant server 2. However, in abnormal situations such as payment system abnormalities or network abnormalities, the merchant server 2 cannot receive the payment result notification returned by the payment system. If the merchant server does not receive the payment result notification returned by the payment system within the preset time after sending the payment information to the payment system, the order status is recorded as unpaid.

[0062] For orders in the unpaid state, the merchant server 2 will obtain the payment status inconsistency probability of the order based on the order information and the network status information of the current network environment. For orders with a payment status inconsistency probability greater than or equal to the preset threshold for order checking, the payment status of the order will be further queried in the payment system. Inconsistent payment status means that the user has paid for the order but the order is in the unpaid state in the merchant server.

[0063] The system involved in the embodiment of the present invention may be a distributed system formed by connecting a client and multiple nodes (computing devices of any form in an access network, such as a server and a user terminal) through network communication.

[0064] Take the distributed system as the blockchain system as an example, see Figure 2 , Figure 2This is an optional structural diagram of the distributed system 100 provided by the embodiment of the present invention applied to the blockchain system. It is formed by multiple nodes (any form of computing devices in the access network, such as servers and user terminals) and clients, and the nodes form a peer-to-peer (P2P, Peer To Peer) network. The P2P protocol is an application layer protocol running on the Transmission Control Protocol (TCP, Transmission Control Protocol) protocol. In a distributed system, any machine such as a server or a terminal can join and become a node. The node includes a hardware layer, an intermediate layer, an operating system layer, and an application layer.

[0065] See also Figure 2 The functions of each node in the blockchain system shown include:

[0066] 1) Routing: a basic function of a node, used to support communication between nodes.

[0067] In addition to the routing function, the node can also have the following functions:

[0068] 2) Applications are deployed in the blockchain to implement specific businesses based on actual business needs, record data related to the implementation of functions to form record data, carry digital signatures in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain system for other nodes to add the record data to a temporary block when they successfully verify the source and integrity of the record data.

[0069] For example, the services implemented by the application may include:

[0070] 2.1) Wallet, used to provide the function of conducting electronic currency transactions, including initiating transactions (i.e., sending the transaction record of the current transaction to other nodes in the blockchain system. After the other nodes successfully verify the transaction, as a response to acknowledge the validity of the transaction, the transaction record data is stored in the temporary block of the blockchain; of course, the wallet also supports querying the remaining electronic currency in the electronic currency address;

[0071] 2.2) Shared ledger, which is used to provide functions such as storage, query and modification of account data. The record data of the operation on the account data is sent to other nodes in the blockchain system. After other nodes verify the validity, as a response to acknowledging the validity of the account data, the record data is stored in a temporary block, and a confirmation can also be sent to the node that initiated the operation.

[0072] 2.3) Smart contracts are computerized protocols that can execute the terms of a contract. They are implemented by deploying code on a shared ledger that is executed when certain conditions are met. The code is used to complete automated transactions based on actual business needs, such as querying the logistics status of the goods purchased by the buyer and transferring the buyer's electronic currency to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions, but can also execute contracts for processing received information.

[0073] 3) Blockchain, including a series of blocks that are connected to each other in the order of their generation. Once a new block is added to the blockchain, it will not be removed. The block records the record data submitted by the nodes in the blockchain system.

[0074] See also Figure 3 , Figure 3 This is an optional schematic diagram of the block structure provided by an embodiment of the present invention. Each block includes the hash value of the transaction record stored in this block (the hash value of this block) and the hash value of the previous block. Each block is connected by the hash value to form a blockchain. In addition, the block can also include information such as the timestamp when the block was generated. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains relevant information for verifying the validity of its information (anti-counterfeiting) and generating the next block.

[0075] The following will be combined Figure 4 The process of the merchant server querying the payment system about the payment status of an order is introduced in detail.

[0076] See also Figure 4 , Figure 4 is a flow chart of an order status query method provided by an embodiment of the present invention, such as Figure 4 As shown, the order status query method includes:

[0077] S110, the merchant server obtains order information of the order to be queried and network status information of the current network environment.

[0078] The order information includes product information and user information corresponding to the user who purchased the product in the order.

[0079] In an exemplary embodiment, the order to be queried is an order among all orders submitted by the merchant client to the merchant server, for which no payment result notification returned by the payment system has been received.

[0080] S120, the merchant server obtains the payment status inconsistency probability of the order to be queried based on the product information, user information and network status information.

[0081] Among them, inconsistent payment status means that the user has paid for the order but the order is in an unpaid state.

[0082] In an exemplary embodiment, the process of obtaining the probability of inconsistent payment status of an order may include the following steps:

[0083] 1) Based on the product information and user information, obtain the probability that the user will pay for the order to be queried.

[0084] In an exemplary embodiment, the process of obtaining the probability of a user paying for an order may include the following steps:

[0085] 11) Input the product information and user information into the purchase rate prediction model to obtain the purchase probability of the user purchasing the product.

[0086] 12) Input the product information into the product popularity prediction model to obtain the probability of the product being purchased.

[0087] The higher the popularity of a product, the higher the probability that it will be purchased.

[0088] 13) Based on the probability of the user purchasing the product and the probability of the product being purchased, the probability of the user paying for the order to be queried is obtained.

[0089] The probability that a user pays for an order is positively correlated with the probability that the product is purchased and the purchase probability of the user purchasing the product. For example, the higher the purchase probability of the user purchasing the product and the higher the probability that the product is purchased, the higher the probability that the user pays for the product order.

[0090] 2) Obtain the probability of abnormality in the payment process of the order to be queried based on the network status information.

[0091] The network status information includes, but is not limited to: the total duration of network failures in a certain area over a period of time, the network load rate of the merchant server at a certain time, and information about network failures in a certain area.

[0092] For example, the total duration of network failure in a certain area over a period of time can be used to obtain the probability of network failure in the area. The information of network failure in a certain area can be used to obtain the probability of network failure in the area. For a certain area (where the scope of the area is smaller than the area), the probability of abnormality in the payment process of users in the area can be obtained based on the probability of network failure in the area to which the area belongs, the network load rate of the merchant server at this time, and the probability of network failure in the area.

[0093] 3) According to the probability that the user pays the order to be queried and the probability that an abnormality occurs in the payment process of the order to be queried, the probability of inconsistent payment status of the order to be queried is determined.

[0094] Among them, the probability of inconsistent payment status of an order is positively correlated with the probability of the user paying the order and the probability of abnormalities occurring in the payment process of the order. For example, the higher the probability of the user paying the order and the higher the probability of abnormalities occurring in the payment process of the order, the higher the probability of inconsistent payment status of the order.

[0095] Furthermore, the merchant server decides whether to initiate an order inquiry request to the payment system according to the probability of inconsistent payment status of the order.

[0096] S130, when the probability of inconsistency of the payment status of the order to be queried is greater than or equal to the preset threshold for order query, query the payment status of the order to be queried in the payment system to obtain the order status result of the order to be queried.

[0097] The preset order checking threshold can be set according to actual needs. For example, the initial value of the preset order checking threshold can be obtained according to the effective number of tests, and the preset order checking threshold can be updated later according to the effective order checking rate.

[0098] The orders for which the merchant server initiates order inquiry requests to the payment system must be orders for which the payment result notification has not been received from the payment system, and the merchant server will mark the payment status of such orders as unpaid.

[0099] If the order is successfully paid in the payment system, it is determined that the status of the order in the merchant server is inconsistent with the status in the payment system, and the payment status in the payment system is used as the final payment status of the order.

[0100] If the payment system shows that the order has failed payment, it is determined that the status of the order in the merchant server and the payment system is consistent, and the final payment status is payment failure.

[0101] In other embodiments of the present application, if the probability of inconsistent payment status of an order is less than a preset threshold for order checking, the order is preliminarily determined to be an invalid order (e.g., an order that the user has not paid for), and no order checking request will be initiated to the payment system. It can be seen that this solution reduces the number of queries for invalid orders.

[0102] The order status query method provided in this embodiment is that the merchant server obtains the order information of the order to be queried, wherein the order information includes the product information and the user information corresponding to the user who purchased the product in the order; and obtains the network status information of the current network environment; further, the probability of inconsistent payment status of the order to be queried is obtained according to the product information, user information and network status information, and for orders with the probability greater than or equal to the preset threshold of the order query, the payment status of the order in the payment system is further queried to obtain the order status result of the order to be queried; wherein, inconsistent payment status means that the user has paid the order but the order is in an unpaid state. It can be seen from the above process that before querying the payment status of the order from the payment system, the scheme first obtains the probability of inconsistent payment status of the order, and filters out the orders with the probability less than the preset threshold of the order query, and further only queries the status of the order from the payment system for the orders with the probability greater than the preset threshold of the order query. It can be seen that the scheme reduces the number of orders to be queried from the payment system, thereby reducing the resource overhead cost of order query, and thus improving the response speed of order query.

[0103] See also Figure 5 , Figure 5 FIG. 1 is a flow chart of another order status query method provided by an embodiment of the present invention. This embodiment will focus on the process of the merchant server obtaining the order status result of an order. Figure 5 As shown, the method mainly includes the following steps:

[0104] S210, the merchant server obtains order information of the order to be queried and network status information of the current network environment.

[0105] The order information includes product information and user information. The network status information represents the stability of the network environment where the server is located.

[0106] S220, the merchant server obtains the payment status inconsistency probability of the order to be queried based on the product information, user information, and network status information.

[0107] In one embodiment of the present invention, the probability of inconsistent payment status of an order can be measured from the following two dimensions: the probability of a user paying an order and the probability of an abnormality in the order payment process; wherein the probability of a user paying an order is positively correlated with the probability of the user purchasing and the probability of the product being purchased. Moreover, the probability of an abnormality in the order payment process is mainly related to the network status information of the current network environment. Therefore, the probability of inconsistent payment status of an order can be measured from three dimensions: the probability of the user purchasing, the probability of the product being purchased, and the network environment status.

[0108] 1) User purchase probability (F1)

[0109] Order information usually includes the product information purchased by the user and user information. For example, product information may include a unique product identifier (such as itemid), and user information includes a user identifier (such as uin). The probability F1 of the user purchasing the product is determined by the user information and product information. For example, for a game user, the purchase of a skin by the user is positively correlated with whether the user has played the game recently and whether the skin has appeared in the recent game.

[0110] The probability of the user purchasing the product can be obtained by calling the interface in the product recommendation data platform, where a purchase rate prediction model is deployed in the product recommendation data platform. The product information and user information are input into the purchase rate prediction model by calling the interface of the platform, and the probability of the user purchasing the product is obtained through the purchase rate prediction model, and returned to the merchant server through the above interface, where the value range of F1 is [0,1].

[0111] 2) The probability of the product being purchased (F2)

[0112] Different products have different popularity. For example, the popularity of discounted products and returning products is greater than or equal to the popularity of unpopular products. A popular product is more likely to be purchased than an unpopular product. Therefore, the probability of a product being purchased can be determined by analyzing its popularity.

[0113] In an application scenario of the present invention, the commodity purchased by the user is a historical commodity, that is, a commodity that has been on the shelf for a period of time and has a certain amount of sales data. In this application scenario, the merchant server obtains the probability of the commodity in the order being purchased by calling the historical commodity popularity prediction model, where the commodity popularity prediction model can be expressed by Formula 1:

[0114] F2(today,pubdate)=m*e -(pubdate-today) (Formula 1)

[0115] Today is the current time, pubdate is the time when the product was first put on the shelves, and m is the fitting coefficient. The specific value of m can be obtained by fitting the sales data of the product in each period (for example, every day or every week) after it is put on the shelves. The value range of F2 is [0,1].

[0116] In another application scenario of the present invention, the product purchased by the user is a newly listed product, that is, a product with no sales data. In this application scenario, the merchant server can call the new product popularity prediction model to obtain the probability of the product in the order being purchased, where the new product popularity prediction model can be expressed by Formula 2:

[0117] F2(itemid)=a*PV_i / i+b*PV_j / j+...+c*PV_k / k (Formula 2)

[0118] In formula 2, the value range of F2 is [0,1]. The larger the value is, the higher the probability that the product will be purchased by the user.

[0119] PV_i represents the number of payments made by different users for a certain product (the product corresponding to itemid) within i cycles. For example, PV_1 represents the number of payments within 1 cycle. Similarly, PV_30 represents the number of payments made for the product within 30 cycles. The cycle can be set according to application needs. For example, 1 cycle is 1 day. In another example, 1 cycle can be less than 1 day or more than 1 day.

[0120] In a possible implementation, the number of payment transactions for the product within a period of time may be obtained from the payment transaction information of the backend system.

[0121] PV_i / i represents the average number of payments for a certain product (the product corresponding to itemid) in each period within i periods. For example, PV_3 / 3 represents the average number of payments for the product within 3 periods. Similarly, PV_30 / 30 represents the average number of payments for the product within 30 periods. The values ​​of i, j, ..., k can be set according to application requirements, taking into account both short-term and long-term data. For example, if a product has been on the shelf for 10 days, the payment data of days 1, 3, 5, 7, and 10 are selected from these 10 days respectively, and the probability of the product being purchased is calculated according to Formula 2.

[0122] For example, PV_3=210 means that the number of payments for the product within 3 cycles is 210 times, and PV_3 / 3=70 means that the average payment is 70 times per cycle within these 3 cycles.

[0123] a, b, ..., c represent weighted payment factors corresponding to different periods respectively. The specific value of each weighted payment factor can be set according to actual application requirements, wherein each weighted payment factor needs to satisfy the following constraint: a+b+...+c=1.

[0124] For example, take the payment data of a certain product in 1, 3, 5, 7, 10, 15, 20, and 30 cycles respectively, and calculate the probability of the product being purchased according to Formula 3:

[0125]

[0126] The above-mentioned new product popularity prediction model combines short-term and long-term factors to comprehensively judge the popularity of products to prevent deviations caused by abnormal payments in a single cycle. For example, if a user has made 200 payments in 3 days but only 200 payments in the last 30 days, it does not mean that the user has a preference for the product recently.

[0127] 3) Network environment assessment

[0128] If the number of payment orders is large, the probability of inconsistent payment status of the orders is high. Similarly, if the network condition is poor, the probability of inconsistent payment status of the orders is high. Therefore, the network environment of the merchant server can be comprehensively evaluated based on the user's location, the merchant server load and the network condition, and then the probability of inconsistent payment status of the orders can be evaluated.

[0129] In one embodiment of the present invention, the probability of an order being abnormal can be expressed by Formula 4:

[0130]

[0131] In Formula 4, F3 represents the probability of network failure of the user, and its value range is [0,1]. The larger the value, the greater the probability of abnormal order of the user. X(area) represents the probability of network failure in the area where the user is located, which can be obtained by dividing the total duration of network failure in the area where the user is located within a period of time by the duration of the period. Y(load) represents the network load rate of the merchant server, and the value of this parameter can be directly obtained from the monitoring data of the merchant server. Z(networkStatus) represents the probability of network failure in a certain area, where the area range is smaller than the area, and is similar to the acquisition process of X(area). It is obtained by dividing the total duration of network failure in the area where the user is located within a period of time by the duration of the period. a, b, c represent the weighting factors of X(area), Y(load) and Z(networkStatus) respectively, where the specific values ​​of a, b, c meet the constraint condition: a+b+c=1, and the specific values ​​of a, b, c can be set according to the actual network environment, for example, a=0.1, b=0.5, c=0.4.

[0132] Finally, the probability of inconsistent payment status of an order is obtained based on the probabilities of the above three dimensions, as shown in Formula 5:

[0133] F=m*F1+n*F2+o*F3 (Formula 5)

[0134] In Formula 5, F represents the probability that the status of a certain order is inconsistent. The value range of F is [0,1]. The larger the value of F, the higher the probability that the order is inconsistent. Conversely, the smaller the value, the lower the probability that the order is inconsistent.

[0135] F1 represents the probability that the user corresponding to the order purchases the goods in the order, F2 represents the probability that the goods in the order are purchased, and F3 represents the probability that the order is abnormal. For goods whose shelf time exceeds the preset time, the value of F2 is obtained by using formula 1; if the shelf time is shorter than the preset time, the value of F2 is obtained by using formula 2.

[0136] Among them, m, n, and o represent the weighting factors of F1, F2, and F3 respectively, and satisfy the constraint condition: m+n+o=1. The values ​​of m, n, and o can be fitted according to actual payment data, for example, m=0.3, n=0.2, and o=0.5.

[0137] S230: When the probability of inconsistency in the payment status of the order to be queried is greater than a preset threshold for order checking, the merchant server initiates an order checking request for the order to be queried to the payment system.

[0138] The preset threshold for checking a single item may be set according to actual application requirements. For example, the initial value of the preset threshold for checking a single item may be obtained based on valid times of testing.

[0139] In one application scenario, the merchant server initiates an order query request to the payment system only for orders with a probability greater than a preset order query threshold.

[0140] In another application scenario, for example, after a user pays for an order, he or she has not received a payment result notification. In this case, the user can perform an order query operation on the merchant client and initiate an order query request to the merchant server. After receiving the order query request, the merchant server can directly initiate a query request to the payment system.

[0141] S240, the merchant server receives the payment status of the order to be queried returned by the payment system.

[0142] The payment system receives an order query request sent by the merchant server. The order query request carries information about the order, such as product information, user information, and a unique identifier for the order. The payment system obtains the payment status of the order (e.g., payment success or payment failure) based on the order information and feeds it back to the merchant server.

[0143] S250, the merchant server compares whether the payment status of the order to be queried in the merchant server and the payment system are consistent; if not, execute S260; if consistent, execute S270.

[0144] The merchant server must initiate a query request to the payment system for an order that has not received a payment result notification from the payment system, and the merchant server will mark the payment status of such an order as unpaid. Therefore, if the payment status returned by the payment system is payment failure, the payment status of the order is determined to be consistent; if the payment status returned by the payment system is payment success, the payment status of the order is determined to be inconsistent.

[0145] S260, the merchant server determines that the payment status of the order to be queried is payment successful.

[0146] If the payment status of the order to be queried in the merchant server is inconsistent with its payment status in the payment system, the payment status in the payment system is used as the payment status of the order to be queried. In addition, the merchant server can also return a notification of successful order payment to the merchant client. Furthermore, the merchant server can also directly trigger the merchant's unified re-shipment system to re-ship the order, and send an order shipment notification to the merchant client. The merchant client displays the order shipment notification on the display interface to remind the user of the latest status of the order.

[0147] S270, the merchant server determines that the payment status of the order to be queried is payment failure.

[0148] Furthermore, the merchant server returns a notification of order payment failure to the merchant client, and the merchant client displays the notification of payment failure on the display interface to remind the user of the latest status of the order.

[0149] In one embodiment of the present invention, Figure 5 As shown, the method may further include the following steps:

[0150] S280, the merchant server obtains an effective order query rate according to the number of orders with inconsistent payment status and the total number of order queries.

[0151] The effective order query rate is the ratio of the number of orders with inconsistent payment status to the total number of order queries. S290, the merchant server adjusts the preset order query threshold according to the effective order query rate.

[0152] If the effective order query rate is greater than the preset value, reduce the preset order query threshold; if the effective order query rate is less than the preset value, increase the preset order query threshold.

[0153] The preset value can be set according to actual needs. If the effective order checking rate is greater than the preset value, it indicates that there are many orders with inconsistent payment status in the checked orders. Therefore, the preset order checking threshold can be appropriately reduced to avoid missing checks.

[0154] If the effective order query rate is small, such as less than the minimum preset value, it means that there are many invalid queries in the order query. In this case, it is necessary to appropriately increase the preset order query threshold to reduce the number of order queries.

[0155] In addition, the effective order checking rate and missed check ratio can also be used to evaluate the order checking effect of the merchant server.

[0156] Omission ratio = number of orders found in reconciliation / total number of orders checked; number of orders found in reconciliation refers to the number of orders whose payment status is inconsistent between the merchant server and the payment system through reconciliation and settlement. The closer the omission ratio is to zero, the better the merchant server's order checking effect is, and vice versa, the worse the merchant server's order checking effect is.

[0157] It has been verified that after adopting the order status query solution provided by the present invention, the effective order query rate is relatively high and the missed query ratio is close to zero.

[0158] See also Figure 6 , shows a schematic diagram comparing the effective order query rates of the new and old schemes, where Curve 1 is the effective order query rate obtained by using the order status query scheme provided by the present invention, and Curve 2 is the effective order query rate obtained by using the traditional order query scheme. Figure 6 As shown, the values ​​of each point in curve 1 are greater than the values ​​of each point in curve 2. It can be seen that the effect of the solution provided by the present invention is better than the traditional order checking solution.

[0159] In the order status query method provided by this embodiment, the merchant server does not receive the payment result notification returned by the payment system, and does not directly query the payment status in the payment system. Instead, the merchant server first calculates the purchase probability of the commodity purchased by the user in the order, the probability of the commodity being purchased, and the probability of the order being abnormal according to the network environment, and comprehensively evaluates the probability of the order having inconsistent payment status. Only orders with a probability of inconsistent payment status greater than or equal to the preset threshold for querying the order will continue to query the payment system; and orders with a probability of inconsistent payment status less than the preset threshold for querying the order will no longer query the payment system, thereby reducing the number of order queries in the payment system, thereby reducing the resource overhead cost of order queries, and improving the order query response speed. Therefore, the scheme can quickly determine the order with inconsistent payment status. In addition, the order status query method provided by this embodiment also counts the effective query rate, and adjusts the preset threshold for querying the order according to the effective query rate, and uses the adjusted preset threshold for querying the order to make a query judgment, further improving the accuracy of the query.

[0160] The following will be combined Figure 7 The example shown introduces the process of the order status query method provided by the present invention, wherein: Figure 7 The merchant payment system, merchant delivery system order MQ, merchant unified reissue system, payment analysis system and merchant settlement system are all systems within the merchant server.

[0161] like Figure 7 As shown, the order status query method may include the following steps:

[0162] S310, the user selects the goods to be purchased on the merchant client and places an order for settlement.

[0163] S320, the merchant payment system stores the order in the order queue.

[0164] The user's order settlement information is sent to the merchant's payment system, and the merchant's payment system stores the received order information in the order MQ.

[0165] S330, the merchant payment system calls the payment channel's interface to obtain the payment URL of the payment channel.

[0166] The payment channel party is the payment service provider, that is, the payment system server.

[0167] S340, the merchant payment system returns the payment URL to the merchant client, the display page of the merchant client jumps to the payment page, the user enters the payment information, and the payment channel backend initiates the deduction.

[0168] S350, after the user has successfully paid, the payment channel informs the merchant's delivery system that the payment is successful.

[0169] S360, the merchant shipping system performs shipping operations.

[0170] S370, the merchant delivery system sends a delivery notification to the merchant client.

[0171] S380, the merchant's delivery system will send the payment flow to the merchant's settlement system.

[0172] The merchant settlement system is used to conduct reconciliation and settlement operations with the payment channel party.

[0173] S390, the order MQ sends the information of the order to be queried to the merchant's unified replenishment system.

[0174] S3100, the merchant unified replenishment system sends the information of the order to be queried to the payment analysis system, and the payment analysis system analyzes the probability of inconsistent payment status of the order.

[0175] S3110: When the probability is greater than or equal to the preset threshold for order checking, the merchant's unified re-shipment system is triggered to initiate an order check with the payment channel.

[0176] S3120: When the probability is less than the preset threshold for order checking, the merchant's unified re-shipment system abandons order checking.

[0177] S3130, the merchant's unified re-shipping system receives the payment status of the order returned by the payment channel, and when the payment status is inconsistent, triggers the merchant's shipping system to re-ship.

[0178] S3140, the merchant delivery system sends a delivery notification to the merchant client.

[0179] In this embodiment, the delivery notification is the order status result mentioned above.

[0180] S3150, the merchant delivery system sends the payment flow of the order to the merchant settlement system.

[0181] After the merchant's delivery system completes the re-delivery, it sends the payment flow of the order to the merchant's settlement system so that the merchant's settlement system and the payment system can conduct reconciliation and settlement.

[0182] The order status query method provided in this embodiment is that before querying the payment status of the order from the payment channel party, the payment analysis system first analyzes the probability of inconsistency between the order status and the payment status of the payment channel party. The order is only checked when the probability value is greater than or equal to a preset threshold for checking the order, otherwise the order is abandoned. Therefore, the frequency of order checking is reduced, and the overhead cost of order checking is further reduced.

[0183] On the other hand, the present application also provides an order status query device, see Figure 8 , shows a structural schematic diagram of the order status query device of the present application, such as Figure 8 As shown, the device may include:

[0184] The first acquisition module 110 is used to acquire order information of the order to be queried, where the order information includes product information and user information.

[0185] The second acquisition module 120 is used to acquire network status information of the current network environment.

[0186] The order status analysis module 130 is used to obtain the payment status inconsistency probability of the order to be queried based on the product information, user information, and network and load status information.

[0187] In one embodiment of the present application, the order status analysis module 130 includes:

[0188] The payment order probability determination submodule is used to obtain the probability of the user paying the order to be queried based on the product information and user information.

[0189] The payment abnormality probability determination submodule is used to obtain the probability of abnormality in the payment process of the order to be queried based on the network status information.

[0190] The payment status inconsistency probability determination submodule is used to determine the payment status inconsistency probability of the order to be queried based on the probability that the user pays the order to be queried and the probability that an abnormality occurs in the payment process of the order to be queried.

[0191] In an exemplary embodiment, the payment order probability determination submodule may include:

[0192] The purchase probability determination submodule is used to input product information and user information into the purchase rate prediction model to obtain the purchase probability of the user purchasing the product;

[0193] The product purchase probability determination submodule is used to input product information into the product popularity prediction model to obtain the product purchase probability;

[0194] The payment probability determination submodule is used to obtain the probability of the user paying the order to be queried based on the purchase probability of the user purchasing the product and the probability of the product being purchased.

[0195] In different application scenarios, the functions of the product purchase probability determination submodule are different:

[0196] 1) The product is a historical product. In this scenario, the product purchase probability determination submodule is used to:

[0197] The first listing time of the product is obtained, and the first listing time and the current time are sent to the historical product popularity prediction model to obtain the probability of the product being purchased; wherein the historical product popularity prediction model is trained by the historical data of the product.

[0198] 2) The product is a new product. In this application scenario, the product purchase probability determination submodule is used to:

[0199] Obtain payment data corresponding to the product in at least two different time periods;

[0200] The payment data is sent to a new product popularity prediction model to obtain the probability of the product being purchased, where the new product popularity prediction model includes weight coefficients and average payment data corresponding to each time period.

[0201] The order query module 140 is used to query the status of the order to be queried in the payment system to obtain the order status result corresponding to the order to be queried when the probability of inconsistency of the payment status of the order to be queried is greater than a preset threshold for querying the order.

[0202] In the order status query device provided in this embodiment, if the merchant server does not receive the payment result notification returned by the payment system, it does not directly query the payment status of the order in the payment system. Instead, the merchant server first determines the probability of the user purchasing the product in the order, the probability of the product being purchased, and the probability of the order being abnormal based on the network environment conditions, and comprehensively evaluates the probability of the order having inconsistent payment status. Only orders with a probability of inconsistent payment status greater than or equal to a preset threshold for querying the order will continue to query the payment system; and orders with a probability of inconsistent payment status less than the preset threshold for querying the order will no longer query the payment system, thereby reducing the number of order queries in the payment system, thereby reducing the resource overhead cost of order queries, and at the same time improving the response speed of order queries. Therefore, this solution can quickly identify orders with inconsistent payment status. See Fig. 9 , Fig. 9 is a structural diagram of another order status query device provided in an embodiment of the present application. The order status query device provided in this embodiment is Figure 8 The embodiment shown also includes:

[0203] The effective order query rate determination module 210 is used to obtain the effective order query rate according to the number of orders with inconsistent payment status and the total number of order queries.

[0204] The threshold reduction module 220 is used to reduce the preset threshold of the order query when the effective order query rate is greater than the preset value.

[0205] The threshold increasing module 230 is used to increase the preset order checking threshold when the effective order checking rate is less than a preset value.

[0206] The order status query device provided in this embodiment obtains the effective order query rate by statistics, adjusts the order query preset threshold according to the effective order query rate, and uses the adjusted order query preset threshold to perform order query judgment, thereby further improving the accuracy of order query.

[0207] On the other hand, the present application also provides a terminal, as shown in Fig.10 , Fig.10 It is a schematic diagram of a component structure of a terminal of the present application. The terminal of this embodiment may include: a processor 310 and a memory 320.

[0208] Optionally, the terminal may further include a communication interface 330 , an input unit 340 , a display 350 , and a communication bus 360 .

[0209] The processor 310 , the memory 320 , the communication interface 330 , the input unit 340 , and the display 350 all communicate with each other via the communication bus 360 .

[0210] In the embodiment of the present application, the processor 310 may be a central processing unit (CPU), an application specific integrated circuit, a digital signal processor, a readily available programmable gate array, or other programmable logic devices.

[0211] The processor may call the program stored in the memory 320. Specifically, the processor may execute the operations executed by the application server side in the following embodiment of the message sending method.

[0212] The memory 320 is used to store one or more programs, which may include program codes, and the program codes include computer operation instructions. In the embodiment of the present application, the memory at least stores programs for implementing the following functions:

[0213] Obtaining order information of the order to be queried and network status information of the current network environment, the order information includes product information and user information of the user who purchased the product in the order;

[0214] According to the product information, user information and network status information, the probability of inconsistent payment status of the order to be queried is obtained, where inconsistent payment status indicates that the user has paid for the order but the order is in an unpaid state;

[0215] When the probability of inconsistency of the payment status of the order to be queried is greater than or equal to a preset threshold for order query, the payment status of the order to be queried in the payment system is queried to obtain an order status result of the order to be queried.

[0216] In a possible implementation, obtaining the probability of inconsistent payment status of the order to be queried according to the product information, user information and network status information includes:

[0217] Based on product information and user information, obtain the probability that the user will pay for the order to be queried;

[0218] Obtain the probability of abnormality in the payment process of the order to be queried based on the network status information;

[0219] According to the probability that the user pays the order to be queried and the probability that an abnormality occurs in the payment process of the order to be queried, the probability of inconsistent payment status of the order to be queried is determined.

[0220] In another possible implementation, obtaining the probability of the user paying the order to be queried according to the product information and the user information includes:

[0221] Input product information and user information into the purchase rate prediction model to obtain the purchase probability of the user purchasing the product;

[0222] Input product information into the product popularity prediction model to obtain the probability of the product being purchased;

[0223] According to the purchase probability of the user and the probability of the product being purchased, the probability of the user paying for the order to be queried is obtained.

[0224] In another possible implementation, the product information is input into the product popularity prediction model to obtain the probability of the product being purchased, including:

[0225] If the product is a historical product, get the first listing time of the product;

[0226] The first listing time and the current time are sent to the historical commodity popularity prediction model to obtain the probability of the commodity being purchased, wherein the historical commodity popularity prediction model is trained by the historical data of the commodity.

[0227] In another possible implementation, the product information is input into the product popularity prediction model to obtain the probability of the product being purchased, including:

[0228] If the product is newly listed, obtain the payment data corresponding to the product in at least two different time periods;

[0229] The payment data is sent to a new product popularity prediction model to obtain the probability of the product being purchased, where the new product popularity prediction model includes weight coefficients and average payment data corresponding to each time period.

[0230] In yet another possible implementation, the method further includes:

[0231] When the probability of inconsistency of the payment status of the order to be queried is less than the preset threshold for order query, the step of querying the payment status of the order to be queried in the payment system is not triggered.

[0232] In yet another possible implementation, the method further includes:

[0233] Obtain the effective order query rate based on the number of orders with inconsistent payment status and the total number of order queries;

[0234] If the effective order checking rate is greater than the preset value, the preset order checking threshold is reduced;

[0235] If the effective order inquiry rate is less than the preset value, increase the preset order inquiry threshold.

[0236] In another possible implementation, the process of determining the order to be queried includes:

[0237] Orders that have not received payment result notifications returned by the payment system are determined as pending orders.

[0238] In one possible implementation, the memory 320 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and application programs required for at least one function (such as an image playback function, etc.); the data storage area may store data created during the use of the computer, such as user data and image data, etc.

[0239] In addition, the memory 320 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device or other volatile solid-state storage device.

[0240] The communication interface 330 may be an interface of a communication module, such as an interface of a GSM module.

[0241] The present application may further include a display 340 and an input unit 350 and the like.

[0242] certainly, Fig.10 The structure of the terminal shown does not constitute a limitation on the terminal in the embodiment of the present application. In actual applications, the terminal may include Fig.10 More or fewer components than shown, or combinations of certain components.

[0243] On the other hand, the present application further provides a merchant server, the merchant server comprising a memory and a processor, the memory storing program instructions, the processor being used to call the program instructions in the memory to implement the following method steps:

[0244] Obtaining order information of the order to be queried and network status information of the current network environment, the order information includes product information and user information of the user who purchased the product in the order;

[0245] According to the product information, user information and network status information, the probability of inconsistent payment status of the order to be queried is obtained, where inconsistent payment status indicates that the user has paid for the order but the order is in an unpaid state;

[0246] When the probability of inconsistency of the payment status of the order to be queried is greater than or equal to a preset threshold for order query, the payment status of the order to be queried in the payment system is queried to obtain an order status result of the order to be queried.

[0247] In a possible implementation, obtaining the probability of inconsistent payment status of the order to be queried according to the product information, user information and network status information includes:

[0248] Based on product information and user information, obtain the probability that the user will pay for the order to be queried;

[0249] Obtain the probability of abnormality in the payment process of the order to be queried based on the network status information;

[0250] According to the probability that the user pays the order to be queried and the probability that an abnormality occurs in the payment process of the order to be queried, the probability of inconsistent payment status of the order to be queried is determined.

[0251] In another possible implementation, obtaining the probability of the user paying the order to be queried according to the product information and the user information includes:

[0252] Input product information and user information into the purchase rate prediction model to obtain the purchase probability of the user purchasing the product;

[0253] Input product information into the product popularity prediction model to obtain the probability of the product being purchased;

[0254] According to the purchase probability of the user and the probability of the product being purchased, the probability of the user paying for the order to be queried is obtained.

[0255] In another possible implementation, the product information is input into the product popularity prediction model to obtain the probability of the product being purchased, including:

[0256] If the product is a historical product, get the first listing time of the product;

[0257] The first listing time and the current time are sent to the historical commodity popularity prediction model to obtain the probability of the commodity being purchased, wherein the historical commodity popularity prediction model is trained by the historical data of the commodity.

[0258] In another possible implementation, the product information is input into the product popularity prediction model to obtain the probability of the product being purchased, including:

[0259] If the product is newly listed, obtain the payment data corresponding to the product in at least two different time periods;

[0260] The payment data is sent to a new product popularity prediction model to obtain the probability of the product being purchased, where the new product popularity prediction model includes weight coefficients and average payment data corresponding to each time period.

[0261] In yet another possible implementation, the method further includes:

[0262] When the probability of inconsistency of the payment status of the order to be queried is less than the preset threshold for order query, the step of querying the payment status of the order to be queried in the payment system is not triggered.

[0263] In yet another possible implementation, the method further includes:

[0264] Obtain the effective order query rate based on the number of orders with inconsistent payment status and the total number of order queries;

[0265] If the effective order checking rate is greater than the preset value, the preset order checking threshold is reduced;

[0266] If the effective order inquiry rate is less than the preset value, increase the preset order inquiry threshold.

[0267] In another possible implementation, the process of determining the order to be queried includes:

[0268] Orders that have not received payment result notifications returned by the payment system are determined as pending orders. On the other hand, an embodiment of the present application further provides a storage medium, wherein the storage medium stores computer executable instructions, and when the computer executable instructions are loaded and executed by a processor, the order status query method executed by the merchant server side in any of the above embodiments is implemented.

[0269] On the other hand, an embodiment of the present application provides a computer program product, which, when executed on a server, is suitable for executing a program that initializes the order status query method executed by the merchant server side in any of the above embodiments.

[0270] It should be noted that each embodiment in this specification is described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the embodiments can be referred to each other. For the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0271] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0272] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

[0273] The above are only preferred embodiments of the present invention. It should be pointed out that, for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A method for querying order status, characterized in that: The method comprises: Obtaining order information of the order to be queried and network status information of the current network environment, wherein the order information includes product information and user information of a user who purchased the product in the order; Obtaining, based on the product information and the user information, a probability that the user pays the order to be queried; Obtaining, according to the network status information, a probability that an abnormality occurs in the payment process of the order to be queried; Determine the probability of inconsistent payment status of the order to be queried according to the probability that the user pays the order to be queried and the probability that an abnormality occurs in the payment process of the order to be queried, wherein the inconsistent payment status indicates that the user has paid the order and the order is in an unpaid state; When the probability of inconsistency of the payment status of the order to be queried is greater than or equal to a preset threshold for order query, the payment status of the order to be queried in the payment system is queried to obtain an order status result of the order to be queried.

2. The method according to claim 1, characterized in that The obtaining, according to the product information and the user information, a probability that the user pays the order to be queried, includes: Inputting the commodity information and the user information into a purchase rate prediction model to obtain a purchase probability of the user purchasing the commodity; Inputting the commodity information into a commodity popularity prediction model to obtain the probability of the commodity being purchased; According to the purchase probability of the user purchasing the commodity and the probability of the commodity being purchased, the probability of the user paying the order to be queried is obtained.

3. The method according to claim 2, characterized in that The step of inputting the commodity information into a commodity popularity prediction model to obtain the probability of the commodity being purchased includes: If the product is a historical product, the first listing time of the product is obtained; The first listing time and the current time are sent to a historical commodity popularity prediction model to obtain the probability of the commodity being purchased, wherein the historical commodity popularity prediction model is trained by the historical data of the commodity.

4. The method according to claim 2, characterized in that: The step of inputting the commodity information into a commodity popularity prediction model to obtain the probability of the commodity being purchased includes: The product is a newly listed product, and payment data corresponding to the product in at least two different time periods are obtained; The payment data is sent to a new commodity popularity prediction model to obtain the probability of the commodity being purchased, wherein the new commodity popularity prediction model includes weight coefficients corresponding to each time period and average payment data.

5. The method according to any one of claims 1 to 4, characterized in that: The method further comprises: When the probability of inconsistency of the payment status of the order to be queried is less than the preset threshold for order query, the step of querying the payment status of the order to be queried in the payment system is not triggered.

6. The method according to any one of claims 1 to 4, characterized in that: The method further comprises: Obtain the effective order query rate based on the number of orders with inconsistent payment status and the total number of order queries; If the effective order checking rate is greater than a preset value, reducing the preset order checking threshold; If the effective order-checking rate is less than the preset value, the preset order-checking threshold is increased.

7. The method according to any one of claims 1 to 4, characterized in that: The process of determining the order to be queried includes: Orders that have not received payment result notifications returned by the payment system are determined as pending orders.

8. An order status query device, characterized in that: include: A first acquisition module is used to acquire order information of the order to be queried, wherein the order information includes product information and user information of a user who purchased the product in the order; The second acquisition module is used to obtain network status information of the current network environment; A payment order probability determination submodule, used to obtain the probability of the user paying the order to be queried based on the product information and the user information; A payment anomaly probability determination submodule, used to obtain the probability of anomaly in the payment process of the order to be queried according to the network status information; A payment status inconsistency probability determination submodule, used to determine the payment status inconsistency probability of the order to be queried according to the probability that the user pays the order to be queried and the probability that an abnormality occurs in the payment process of the order to be queried, wherein the payment status inconsistency indicates that the user has paid the order but the order is unpaid; The order query module is used to query the payment status of the order to be queried in the payment system when the probability of inconsistency of the payment status of the order to be queried is greater than or equal to a preset threshold for querying the order, and obtain the order status result of the order to be queried.

9. The device according to claim 8, characterized in that The payment order probability determination submodule includes: A purchase probability determination submodule, used to input the commodity information and the user information into a purchase rate prediction model to obtain a purchase probability of the user purchasing the commodity; A commodity purchase probability determination submodule is used to input the commodity information into a commodity popularity prediction model to obtain the probability of the commodity being purchased; The payment probability determination submodule is used to obtain the probability that the user pays the order to be queried based on the purchase probability of the user purchasing the product and the probability that the product is purchased.

10. The device according to claim 9, characterized in that The commodity purchase probability determination submodule is specifically used for: If the product is a historical product, the first listing time of the product is obtained; The first listing time and the current time are sent to a historical commodity popularity prediction model to obtain the probability of the commodity being purchased, wherein the historical commodity popularity prediction model is trained by the historical data of the commodity.

11. The device according to claim 9, characterized in that The commodity purchase probability determination submodule is specifically used for: The product is a newly listed product, and payment data corresponding to the product in at least two different time periods are obtained; The payment data is sent to a new commodity popularity prediction model to obtain the probability of the commodity being purchased, wherein the new commodity popularity prediction model includes weight coefficients corresponding to each time period and average payment data.

12. The device according to any one of claims 8 to 11, characterized in that: The device is also used for: When the probability of inconsistency of the payment status of the order to be queried is less than the preset threshold for order query, the step of querying the payment status of the order to be queried in the payment system is not triggered.

13. The device according to any one of claims 8 to 11, characterized in that: The device also includes: An effective order inquiry rate determination module is used to obtain an effective order inquiry rate according to the number of orders with inconsistent order payment status and the total number of order inquiries; A threshold reduction module, used to reduce the preset order-checking threshold if the effective order-checking rate is greater than a preset value; The threshold increasing module is used to increase the preset order checking threshold if the effective order checking rate is less than the preset value.

14. The device according to any one of claims 8 to 11, characterized in that: The device is also used for: Orders that have not received payment result notifications returned by the payment system are determined as pending orders.

15. A storage medium, characterized in that: The storage medium stores computer executable instructions, and when the computer executable instructions are loaded and executed by the processor, the order status query method as described in any one of claims 1 to 7 is implemented.

16. An order status inquiry terminal, characterized in that: include: Processor and memory; The memory is used to store programs; The processor is used to execute the program stored in the memory to implement the order status query method as described in any one of claims 1 to 7 above.

17. A computer program product, characterized in that When it is executed on an electronic device, it is suitable for executing and initializing the order status query method as described in any one of claims 1 to 7 above.

Images