Payment abnormality processing method, processing device, storage medium and electronic device

Abstract

The present disclosure provides a payment exception processing method, processing device, storage medium and electronic device, which relate to the field of payment exception processing technology. The method includes obtaining order information in response to an order submitted by a client; requesting a payment service from a payment service provider according to the order information; determining whether the payment service request is successful; when the request is successful, storing the order information in an order information queue; and returning the order information to the client. The technical solution provided by the present disclosure can improve the efficiency of payment exception processing.

Description

Background Art

[0002] In the current payment business scenario, payment services are mainly completed through individual users, merchants and third-party service providers. When individual users conduct payment services with third-party service providers on the business platform provided by the merchant, payment anomalies may occur due to stability and quality issues of the network or third-party service providers, resulting in individual users being unable to obtain the correct payment status in a timely manner.

[0003] Therefore, a method, a processing device, a storage medium and an electronic device for processing payment exceptions are needed.

[0004] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of the present disclosure, and therefore may include information that does not constitute the prior art known to ordinary technicians in the field. Summary of the invention

[0005] The purpose of the present disclosure is to provide a method for processing payment anomalies, which at least to some extent overcomes the problem of low efficiency in processing payment anomalies.

[0006] Other features and advantages of the present disclosure will become apparent from the following detailed description, or may be learned in part by the practice of the present disclosure.

[0007] According to one aspect of the present disclosure, a method for handling payment exceptions is provided, comprising: obtaining order information in response to an order submitted by a client; requesting payment service from a payment service provider according to the order information; determining whether the payment service request is successful; when the request is successful, storing the order information in an order information queue; and returning the order information to the client.

[0008] In one embodiment of the present disclosure, the order information includes the payment channel identifier and the order number of the payment service provider, and storing the order information in the order information queue includes: using the payment channel identifier as a key value and storing the order number in the order information queue.

[0009] In one embodiment of the present disclosure, the method further includes: when the request fails, starting a retry mechanism; obtaining a preset number of runs of the retry mechanism; obtaining an actual number of runs of the retry mechanism within a retry time; and when the actual number of runs is greater than the preset number of runs, triggering a global threshold alarm.

[0010] In one embodiment of the present disclosure, the method further includes: using the payment channel identifier as a key value to store a preset number of runs of the retry mechanism; when the actual number of runs is greater than the preset number of runs, removing the payment service provider corresponding to the payment channel identifier from the shelves.

[0011] In one embodiment of the present disclosure, the method further includes: when the request is successful, obtaining a prepaid note generated by the payment service provider, the prepaid note including the order number, the payment channel identifier and the order status; sending the prepaid note to the client so that the client sends a payment request to the payment service provider corresponding to the payment channel identifier; the payment service provider receives the payment request and pays the prepaid note according to the payment request; after the payment service provider completes the payment, it updates the order status to a payment success status and sends a payment success notification.

[0012] In one embodiment of the present disclosure, the method further includes: receiving a payment success notification sent by the payment service provider; using the payment channel identifier as a key value and storing the order number in a payment success queue.

[0013] In one embodiment of the present disclosure, the method further includes: obtaining the order number in the order information queue; determining whether the order number exists in the payment success queue; if the order number exists in the payment success queue, deleting the order number in the order information queue.

[0014] In one embodiment of the present disclosure, the method further includes: if the order number does not exist in the payment success queue, querying the order status; when the order status is a payment waiting state, triggering a payment alarm; when the order status is a payment closed state, deleting the order number in the order information queue.

[0015] In one embodiment of the present disclosure, the method further includes: generating a payment information management interface based on the order information queue and the payment success queue; and using the payment information management interface to monitor background data of the order information queue and the payment success queue.

[0016] According to another aspect of the present disclosure, there is provided a device for processing payment exceptions, including: an order information acquisition unit, used to acquire order information in response to an order submitted by a client; a payment service request unit, used to request a payment service from a payment service provider according to the order information; a request judgment unit, used to judge whether the payment service request is successful; when the request is successful, the order information is stored in an order information queue; and an order information return unit, used to return the order information to the client.

[0017] In one embodiment of the present disclosure, the request success unit includes: an order information queue storage unit, which is used to use the payment channel identifier as a key value and store the order number in the order information queue.

[0018] In one embodiment of the present disclosure, the device also includes: a retry mechanism starting unit, which is used to start the retry mechanism when the request fails; a preset operation number acquisition unit, which is used to obtain the preset operation number of the retry mechanism; an actual operation number acquisition unit, which is used to obtain the actual operation number of the retry mechanism within the retry time; and a global threshold alarm triggering unit, which is used to trigger a global threshold alarm when the actual operation number is greater than the preset operation number.

[0019] In one embodiment of the present disclosure, the device also includes: a preset running number storage unit, which is used to store the preset running number of the retry mechanism using the payment channel identifier as a key value; and a payment service provider delisting unit, which is used to delist the payment service provider corresponding to the payment channel identifier when the actual running number is greater than the preset running number.

[0020] In one embodiment of the present disclosure, the device also includes: a prepaid bill acquisition unit, which is used to obtain the prepaid bill generated by the payment service provider when the request is successful, and the prepaid bill includes the order number, the payment channel identifier and the order status; a payment request sending unit, which is used to send the prepaid bill to the client, so that the client sends a payment request to the payment service provider corresponding to the payment channel identifier; a prepaid bill payment unit, which is used for the payment service provider to receive the payment request and pay the prepaid bill according to the payment request; and a payment success notification sending unit, which is used for the payment service provider to update the order status to a payment success status and send a payment success notification after completing the payment.

[0021] In one embodiment of the present disclosure, the device also includes: a payment success notification receiving unit, used to receive a payment success notification sent by the payment service provider; a payment success queue storage unit, used to use the payment channel identifier as a key value and store the order number in the payment success queue.

[0022] In one embodiment of the present disclosure, the device also includes: an order number acquisition unit, used to acquire the order number in the order information queue; an order number judgment unit, used to judge whether the order number exists in the payment success queue; and an order number deletion unit, used to delete the order number in the order information queue if the order number exists in the payment success queue.

[0023] In one embodiment of the present disclosure, the device also includes: an order status query unit, which is used to query the order status if the order number does not exist in the payment success queue; a payment alarm triggering unit, which is used to trigger a payment alarm when the order status is a payment waiting state; and an order number deletion unit, which is used to delete the order number in the order information queue when the order status is a payment closed state.

[0024] In one embodiment of the present disclosure, the device also includes: a payment information management interface generation unit, which is used to generate a payment information management interface based on the order information queue and the payment success queue; and a background data monitoring unit, which is used to monitor the background data of the order information queue and the payment success queue using the payment information management interface.

[0025] According to another aspect of the present disclosure, there is provided an electronic device, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute the above-mentioned payment exception processing method by executing the executable instructions.

[0026] According to another aspect of the present disclosure, there is provided a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the above-mentioned payment exception processing method when executed by a processor.

[0027] The embodiment of the present disclosure provides a method for processing payment anomalies. After the merchant obtains the order information submitted by the client, it requests the payment service of the payment service provider. After the payment service request is successful, the order information is stored in the order information queue and the order information is returned to the client. When the payment is abnormal, the merchant can solve the payment anomaly problem according to the order information queue storing the order information, thereby improving the efficiency of processing payment anomalies.

[0028] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The accompanying drawings herein are incorporated into the specification and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the specification are used to explain the principles of the present disclosure. Obviously, the accompanying drawings described below are only some embodiments of the present disclosure, and for ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without creative work.

[0030] Figure 1 A schematic diagram showing the structure of a computer system in an embodiment of the present disclosure is shown;

[0031] Figure 2 A flow chart of a payment service in an embodiment of the present disclosure is shown;

[0032] Figure 3 A flow chart of a method for processing payment anomalies in an embodiment of the present disclosure is shown;

[0033] Figure 4 A flow chart showing another method for processing payment anomalies in an embodiment of the present disclosure is shown;

[0034] Figure 5 A flow chart showing another method for processing payment anomalies in an embodiment of the present disclosure is shown;

[0035] Figure 6 A flow chart of another method for processing payment anomalies in an embodiment of the present disclosure is shown;

[0036] Figure 7 A flow chart of another method for processing payment anomalies in an embodiment of the present disclosure is shown;

[0037] Figure 8 A schematic diagram showing a payment exception processing device 800 according to an embodiment of the present disclosure;

[0038] Fig. 9 A structural block diagram of an electronic device 900 according to an embodiment of the present disclosure is shown;

[0039] Fig.10 A schematic diagram of a program product 1000 for implementing the above method in an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0040] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in a variety of forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that the disclosure will be more comprehensive and complete and to fully convey the concepts of the example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0041] In addition, the accompanying drawings are only schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the figures represent the same or similar parts, and their repeated description will be omitted. Some of the block diagrams shown in the accompanying drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software form, or implemented in one or more hardware modules or integrated circuits, or implemented in different networks and / or processor devices and / or microcontroller devices.

[0042] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0043] The inventor of the present invention has found that there are at least the following problems in the prior art, that is, in the prior art, the merchant side relies on the payment success notification sent by the payment service provider and cannot continue to complete the payment business when a payment anomaly occurs. The specific payment anomaly situations are as follows:

[0044] 1) When the merchant obtains the payment information from the payment service provider, it is easy to fail to obtain the information due to network or other reasons, resulting in uncertainty as to whether the payment can be made. If the payment is abandoned, it may cause the merchant to lose users.

[0045] 2) The merchant only knows the status of the payment order based on the payment success notification sent by the payment service provider. In some payment scenarios, for example, the merchant does not receive the payment success notification due to network problems or stability and quality issues of the payment service. At this time, the merchant cannot know the status of the payment order. When the user sends a request to the merchant to query the status of the payment order through the client, the merchant cannot respond to the query request and cannot return the status of the payment order to the client. If the user is unable to query the status of the payment order for a long time, he may complain.

[0046] 3) After the payment is completed, the payment service provider may have a waiting state due to problems such as the merchant's network status, resulting in the payment service provider not sending a successful payment notification. When the client sends a query request to the merchant, the merchant cannot respond to the client's query request because it has not received the successful payment notification. At this time, there is no corresponding solution for the situation where the payment order is in a waiting state or the order is closed, resulting in a poor user experience during the transaction.

[0047] Based on the above problems, the embodiments of the present disclosure propose a payment exception processing method, processing device, storage medium and electronic device, which can overcome the problem of low efficiency in payment exception processing to a certain extent. The embodiments of the present disclosure are described in detail below.

[0048] Figure 1 FIG. 2 is a schematic diagram showing a structure of a computer system in an embodiment of the present disclosure. Figure 1 As shown, Figure 1 A schematic diagram of the structure of a computer system of an exemplary embodiment is provided. The system includes: a plurality of user terminals 120, a merchant terminal 130 and a payment service provider 140.

[0049] The user terminal 120 can be a mobile user terminal such as a mobile phone, a game console, a tablet computer, an e-book reader, smart glasses, an MP4 (Moving Picture Experts Group Audio Layer IV) player, a smart home device, an AR (Augmented Reality) device, a VR (Virtual Reality) device, etc., or the user terminal 120 can also be a personal computer (PC), such as a laptop computer and a desktop computer.

[0050] The user terminal 120 may be installed with an application program that allows the user terminal 120 to interact with the merchant terminal 130 .

[0051] The user terminal 120 is connected to the payment service provider 140 via a communication network. In some embodiments, the communication network is a wired network or a wireless network.

[0052] The merchant terminal 130 includes a merchant client and a merchant server. The merchant client is a virtualization platform that integrates a visualization page with the merchant server and provides merchant information in the visualization page. The merchant server can be one or more servers.

[0053] The payment service provider 140 is a server, or is composed of several servers, or is a virtualization platform, or is a cloud computing service center. The payment service provider 140 is used to provide background services for applications that provide payment services. In some embodiments, the payment service provider 140 undertakes the main computing work, and the user terminal 120 undertakes the secondary computing work; or, the payment service provider 140 undertakes the secondary computing work, and the user terminal 120 undertakes the main computing work; or, the user terminal 120 and the payment service provider 140 adopt a distributed computing architecture for collaborative computing.

[0054] In some embodiments, the payment service provider 140 is used to store information about the payment channel of the payment service provider.

[0055] In some embodiments, the payment service provider 140 is also connected to the server system 142, and the payment service provider 140 stores the transaction information and / or transaction records provided by the merchant in the server system 142. In some embodiments, the payment service provider 140 itself can also operate and store data as a node in the server system.

[0056] In some embodiments, the payment service provider 140 includes a logic server ( Figure 1 not shown) and the payment server ( Figure 1(not shown). The logic server is used to implement the logic control of the application, such as request processing for commodity transactions, account resource management, interface content management, etc. The payment server, as a part of the server system 142, is used to implement the storage of transaction information and / or transaction records of each user terminal 120, as well as decision management of important functions, such as making decisions on payment requests.

[0057] It should be noted that the above-mentioned logic server and payment server may belong to the same computer device, or the above-mentioned logic server and payment server may also belong to different computer devices.

[0058] In some embodiments, the applications installed in different user terminals 120 are the same, or the clients of the applications installed on the two user terminals 120 are clients of the same type of applications on different control system platforms. Based on the different user terminal platforms, the client of the application has different specific forms, for example, the client of the application can exist on a mobile user terminal platform, a PC (Personal Computers) user terminal platform, or a World Wide Web (Web) user terminal platform.

[0059] Those skilled in the art will appreciate that the number of the user terminals 120 may be more or less. For example, there may be only one user terminal, or there may be dozens or hundreds of user terminals, or a greater number. The embodiment of the present application does not limit the number and device type of the user terminals.

[0060] In some embodiments, the system may also include a management device ( Figure 1 (not shown), the management device is connected to the payment service provider 140 via a communication network. In some embodiments, the communication network is a wired network or a wireless network.

[0061] In some embodiments, the wireless network or wired network described above uses standard communication technology and / or protocols. The network is typically the Internet, but may also be any network, including but not limited to a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a mobile, wired or wireless network, a dedicated network or any combination of a virtual private network). In some embodiments, technologies and / or formats including Hyper Text Mark-up Language (HTML), Extensible Markup Language (XML), etc. are used to represent data exchanged over the network. In addition, conventional encryption technologies such as Secure Socket Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), Internet Protocol Security (IPsec), etc. may be used to encrypt all or some links. In other embodiments, customized and / or dedicated data communication technologies may also be used to replace or supplement the above data communication technologies.

[0062] Below, each step of the method for handling payment anomalies in this example implementation will be described in more detail with reference to the accompanying drawings and embodiments.

[0063] Figure 2 A flow chart of a payment service in an embodiment of the present disclosure is shown. Figure 2 As shown, Figure 2 A payment method is provided. The method includes but is not limited to the following steps:

[0064] In S210, an order is placed. The client sends an order request to the merchant.

[0065] In S220, the merchant generates an order and requests payment information. The merchant receives the order request, generates an order, and requests payment information of the order from the payment service provider.

[0066] In one embodiment, the payment service provider may be a technical service provider with a payment service license issued by the state, such as WeChat and Alipay.

[0067] In S230, the payment service provider sends the payment information. After receiving the request sent by the merchant, the payment service provider sends the payment information of the order to the client.

[0068] In S240, the client receives the payment information. After receiving the payment information, the client selects a payment service provider for paying the order.

[0069] In S250 , the client sends a payment request to the payment service provider.

[0070] In S260, the payment service provider receives the payment request and completes the payment process of the order.

[0071] In S270, the payment service provider asynchronously sends a payment notification. After the payment order is successfully paid, the payment service provider asynchronously sends a payment success notification to the merchant.

[0072] In S280, the merchant receives the payment notification asynchronously. After receiving the payment success notification, the merchant continues to perform subsequent business operations of the order, such as packing the goods, arranging the goods delivery, etc.

[0073] The present disclosure provides a method for processing payment anomalies. The method provided in the present disclosure can be executed by any electronic device with computing and processing capabilities, such as Figure 1 The merchant terminal 130 and / or the payment service provider 140 in the embodiment. In the following examples, the merchant terminal 130 is used as the execution subject for example description.

[0074] Figure 3 A flow chart of a method for processing payment anomalies in an embodiment of the present disclosure is shown. Figure 3 As shown, Figure 3 A method for handling abnormal payment scenarios is provided. The method includes but is not limited to the following steps:

[0075] In S310, in response to the order submitted by the client, order information is obtained. The client submits the order to the merchant, and the merchant responds to the order and obtains the order information.

[0076] In S320, a payment service of the payment service provider is requested according to the order information. The merchant sends a payment service request to the payment service provider according to the order information to request the payment service of the order.

[0077] In S330, it is determined whether the payment service request is successful. The payment service provider receives the payment service request from the merchant and generates a prepayment slip, which includes the payment channel mark of the payment service provider. The prepayment slip is sent to the merchant. If the merchant receives the prepayment slip, it means that the payment service request is successful. If the merchant does not receive the prepayment slip, it means that the payment service request is unsuccessful.

[0078] In S340, when the request is successful, the order information is stored in the order information queue. After receiving the prepaid order, the merchant stores the order information in the order information queue. The order information may include order number, product information, address information, time information, amount information and other information.

[0079] In one embodiment, the order information includes the payment channel identifier and the order number of the payment service provider, and storing the order information in the order information queue includes: using the payment channel identifier as a key value and storing the order number in the order information queue. In the embodiment of the present disclosure, the order information may also include a payment channel tag, and different payment service providers have different payment channel tags. The payment services of different payment service providers can be obtained according to the payment channel tags. Based on the database, the payment channel tag is used as a key value, and the order number is stored in the order information queue. The database includes a relational database and a non-relational database. Non-relational databases may include key-value databases, wide column storage databases, graph storage databases, and the like. In the embodiment of the present disclosure, taking the Redis (Remote Dictionary Server) database as an example of a key-value database, the Redis database is used to store the order number in the order information queue.

[0080] In S350, the order information is returned to the client. The merchant returns the obtained order information to the client.

[0081] Figure 4 A flow chart of another method for processing payment anomalies in an embodiment of the present disclosure is shown. Figure 4 As shown, Figure 4 A method for handling abnormal payment scenarios is provided. The method includes but is not limited to the following steps:

[0082] In S410, the client submits the order. The user submits the order to the merchant through the client.

[0083] In S420, the merchant obtains the order information and requests the payment service provider for payment service according to the order information. The merchant combines the order information and the order data and then requests the payment service provider for payment service.

[0084] In S430, it is determined whether the payment service request is successful. If yes, the process proceeds to S440, and if no, the process proceeds to S460.

[0085] In S440, when the request is successful, the order information is stored in the order information queue.

[0086] In S450, the order information is returned to the client. The merchant returns the order information to the client.

[0087] In S460, a retry is performed. When the payment service request is not successful, the merchant requests the payment service again.

[0088] In S470, a global threshold alarm is performed.

[0089] In one embodiment, when a request fails, a retry mechanism is started; the preset number of operations of the retry mechanism is obtained; the actual number of operations of the retry mechanism is obtained within the retry time; when the actual number of operations is greater than the preset number of operations, a global threshold alarm is triggered. In the embodiment of the present disclosure, starting the retry mechanism represents the merchant end re-requesting the payment service of the payment service provider. A timer can be used to count, and within the retry time, if the actual number of operations of the retry mechanism is greater than the preset number of operations of the retry mechanism, a global threshold alarm is issued. The embodiment of the present disclosure can eliminate the impact of poor network on payment services by implementing a retry mechanism, thereby solving the problem of user loss that may be caused by payment service failure due to network or other reasons.

[0090] In the embodiments of the present disclosure, the technical framework for implementing the timer may include a distributed task scheduling framework, such as an Elastic-job scheduling framework.

[0091] In one embodiment, the payment channel identifier is used as a key value to store the preset number of operations of the retry mechanism; when the actual number of operations is greater than the preset number of operations, the payment service provider corresponding to the payment channel identifier is removed from the shelves. Based on the key-value database, the payment channel tag is used as a key value to store the preset number of operations of the retry mechanism. When the actual number of operations of the retry mechanism is greater than the preset number of operations, the payment service provider corresponding to the payment channel identifier is removed from the shelves on the merchant side, and manual intervention is required to find the cause of the payment service failure of the payment service provider and solve the problem of payment service failure.

[0092] Figure 5 FIG. 2 is a flow chart showing another method for processing payment anomalies in an embodiment of the present disclosure. Figure 5 As shown, Figure 5 A method for handling abnormal payment scenarios is provided. The method includes but is not limited to the following steps:

[0093] In S510, when the request is successful, the prepaid bill generated by the payment service provider is obtained, and the prepaid bill includes the order number, the payment channel identifier and the order status. In the embodiment of the present disclosure, the merchant terminal requests payment services from the payment service provider. The payment service provider receives the request, generates a prepaid bill and sends the prepaid bill to the merchant terminal, and the prepaid bill includes the order number, the payment channel identifier of the payment service provider and the order status.

[0094] In S520, the prepaid order is sent to the client so that the client sends a payment request to the payment service provider corresponding to the payment channel identifier. In the disclosed embodiment, the merchant terminal includes a merchant application software and a merchant server. The payment service provider includes a payment software and a payment server. Among them, the merchant application software and the payment software are both installed on the client. The user can access the merchant server by operating the merchant application software, or conduct business transactions with the payment server by operating the payment software. The merchant terminal sends the received prepaid order to the merchant application software so that the merchant application software provides different payment software for the user according to the prepaid order. After the user selects the payment software using the merchant application software on the client, the client sends a payment request to the corresponding payment service provider according to the payment channel mark corresponding to the selected payment software.

[0095] In S530, the payment service provider receives the payment request and pays the prepaid bill according to the payment request. The payment service provider receives the payment request from the client and completes the payment of the prepaid bill.

[0096] In S540, after the payment service provider completes the payment, the order status is updated to a payment success status, and a payment success notification is sent. In the disclosed embodiment, after the payment service provider completes the payment of the prepaid bill, the order status in the prepaid bill is updated to a payment success status, and a payment success notification is sent to the merchant.

[0097] According to the embodiments provided in S510-S540, when the payment service provider is unable to provide payment services due to network reasons or the like, the problem of failure of the merchant's request for payment services to the payment service provider can be solved.

[0098] Figure 6 A flow chart of another method for processing payment anomalies in an embodiment of the present disclosure is shown. Figure 6 As shown, Figure 6 A method for handling abnormal payment scenarios is provided. The method includes but is not limited to the following steps:

[0099] In S610, when the request is successful, the prepayment slip generated by the payment service provider is obtained, and the prepayment slip includes the order number, the payment channel identifier and the order status.

[0100] In S620, the prepaid order is sent to the client so that the client sends a payment request to the payment service provider corresponding to the payment channel identifier.

[0101] In S630, the payment service provider receives the payment request and pays the prepaid order according to the payment request.

[0102] In S640, after completing the payment, the payment service provider updates the order status to a payment success status and sends a payment success notification.

[0103] Among them, S610-S640 can refer to the embodiment in S510-S540. The description of S650-S660 is as follows:

[0104] In S650, a payment success notification sent by the payment service provider is received. After receiving the payment success notification, the merchant side can know that the order status is a payment success status.

[0105] In S660, the payment channel identifier is used as a key value, and the order number is stored in a successful payment queue. Based on the key-value database, the merchant uses the payment channel identifier as a key value and stores the order number in a successful payment queue.

[0106] In one embodiment, the order number in the order information queue is obtained; it is determined whether the order number exists in the payment success queue; if the order number exists in the payment success queue, the order number is deleted from the order information queue. In the disclosed embodiment, the merchant obtains the order number in the order information queue and determines whether the order number is in the payment success queue. If the order number is in the payment success queue, it means that the prepaid order is paid successfully, and the merchant receives the payment success notification sent by the payment service provider, and then deletes the order number from the order information queue.

[0107] In the disclosed embodiment, the order number in the order information queue may be one or more. The merchant can take one order number at a time to determine whether the order number exists in the above payment success queue.

[0108] In one embodiment, if the order number does not exist in the payment success queue, the order status is queried; when the order status is the payment waiting state, the payment alarm is triggered; when the order status is the payment closed state, the order number is deleted from the order information queue. When the order number obtained by the merchant from the order information queue does not exist in the payment success queue, it means that the prepaid order has not been paid successfully and the payment service provider has not sent a payment success notification. The merchant actively initiates a request to query the order status to the payment service provider, and the payment service provider receives the merchant's request and sends the order status to the merchant. The order status includes a payment waiting state and a payment closed state. When the order status is the payment waiting state, it means that the order may be waiting for payment due to network delays and other reasons. When the order status is the payment closed state, it means that the order may be closed due to order expiration, user abandonment of payment, or order invalidation. At this time, the merchant deletes the order number in the order information queue. According to the technical solution provided in the embodiment of the present disclosure, corresponding processing can be made for different order statuses. When the payment service provider fails to send a successful payment notification, the merchant actively initiates a request to the payment service provider to query the order status. The payment service provider responds to the merchant's request and sends the order status to the merchant. The merchant handles the order status accordingly and sends the order status to the client, so that the user can understand the order status, further solving the problem of poor user experience during the transaction process at the merchant.

[0109] In one embodiment, a timer may be used to enable the merchant to periodically send a request to query the order status to the payment service provider.

[0110] In one embodiment, a payment information management interface is generated based on the order information queue and the payment success queue; the payment information management interface is used to monitor the background data of the order information queue and the payment success queue. In the disclosed embodiment, when payment is abnormal, the merchant can generate a payment information management interface through the log monitoring information, order information, and changes in the order information queue and the payment success queue according to fixed rules. On the payment information management interface, the merchant can monitor the response time, response frequency, system performance consumption and other background data of the merchant requesting payment services from the payment service provider.

[0111] Figure 7 A flow chart of another method for processing payment anomalies in an embodiment of the present disclosure is shown. Figure 7 As shown, Figure 7 A method for handling payment exceptions is provided. The method for handling payment exceptions can be implemented through a client, a merchant, and a payment service provider. The payment service provider may include WeChat, Alipay, and UnionPay official software. In the disclosed embodiment, the payment service provider is WeChat. The method includes but is not limited to the following steps:

[0112] In S701, an order request is sent. The user clicks a link on the client or uses the client to scan a QR code to open the merchant's order page to send an order request.

[0113] In S702, the merchant generates an order, which includes an order number, product information, address information, time information, amount information and other information.

[0114] In S703, the merchant side requests payment service. The merchant side combines the order information with the payment channel mark of the payment service provider, and requests payment service from the payment service provider according to the order.

[0115] In S704, WeChat generates a prepaid bill. WeChat receives the payment service request sent by the merchant and generates a prepaid bill.

[0116] In S705, WeChat returns the prepaid order, including the prepaid order number, order number, order status, and payment channel mark. WeChat sends the prepaid order to the merchant.

[0117] In S706, the merchant side stores the order information into the order information queue. The merchant side stores the order information into the order information queue.

[0118] In S707, the merchant returns the prepaid order to the client.

[0119] In S708, the client sends a payment request. After receiving the prepaid order, the client sends a payment request to WeChat according to the payment channel tag.

[0120] In S709, WeChat receives the payment request sent by the client and pays the prepaid order.

[0121] In S710, WeChat obtains the payment result.

[0122] In S711, WeChat sends the obtained payment result to the client.

[0123] In S712, WeChat updates the order status according to the payment result. If the payment is successful, the order status is updated to the payment successful status. If the order is waiting for payment, the order status is updated to the payment waiting status. If the order is closed, the order status is updated to the payment closed status.

[0124] In S713, WeChat sends a payment success notification. When the order status is a payment success status, WeChat sends a payment success notification to the merchant. WeChat can send the payment success notification using a synchronous sending method or an asynchronous sending method. The present disclosure does not limit the sending method.

[0125] In S714, after receiving the payment success notification, the merchant side stores the order information in the payment success queue. In one embodiment, the order information is transmitted in the form of ciphertext on the communication network. After receiving the payment success notification, the merchant side decrypts and verifies the order information in the payment success notification, that is, uses the agreed encryption method and decryption method to judge and verify the order information, and stores the verified order information in the payment success queue.

[0126] In S715, the merchant determines whether the order information in the order information queue exists in the payment success queue. If yes, proceed to S716. If not, proceed to S717.

[0127] In S716, the merchant deletes the order information in the order information queue. When the order information in the order information queue exists in the payment success queue, the merchant deletes the order information in the order information queue.

[0128] In S717, the merchant sends a request to query the order status. When the order information in the order information queue does not exist in the payment success queue, the merchant sends a request to query the order status to WeChat.

[0129] In S718, WeChat receives a request to query the order status.

[0130] In S719, WeChat returns the order status. After receiving the request for querying the order status sent by the merchant, WeChat returns the queried order status to the merchant.

[0131] In S720, the merchant receives the order status.

[0132] In S730, the client queries the order status. After receiving the payment result, the client sends a request to query the order status to the merchant.

[0133] In S731, the merchant returns the order status. After receiving the request for querying the order status sent by the client, the merchant returns the queried order status to the client.

[0134] In S732, the client checks the order status. The client can check the order status.

[0135] In the embodiments provided in S701-S732, the merchant side proactively initiates a request to query the order status to the payment service provider, and can obtain dynamic changes in the order status. In this way, when the client side initiates a query request for the status of the payment order to the merchant side, the merchant side can respond to the query request in a timely manner and return the status of the payment order to the client side, further solving the problem of users complaining about the merchant side.

[0136] It should be noted that the above figures are only schematic illustrations of the processes included in the method according to an exemplary embodiment of the present invention, and are not intended to be limiting. It is easy to understand that the processes shown in the above figures do not indicate or limit the time sequence of these processes. In addition, it is also easy to understand that these processes can be performed synchronously or asynchronously, for example, in multiple modules.

[0137] Figure 8 FIG. 8 is a schematic diagram showing a payment exception processing device 800 according to an embodiment of the present disclosure. Figure 8 As shown, a payment exception processing device includes an order information acquisition unit 810, a payment service request unit 820, a request judgment unit 830, a request success unit 840 and an order information return unit 850.

[0138] The order information acquisition unit 810 is used to acquire order information in response to an order submitted by a client.

[0139] The payment service request unit 820 is used to request the payment service of the payment service provider according to the above order information.

[0140] The request determination unit 830 is used to determine whether the payment service request is successful.

[0141] The request success unit 840 is used to store the order information in the order information queue when the request is successful.

[0142] In one embodiment, the request success unit 840 includes an order information queue storage unit, which is used to use the payment channel identifier as a key value to store the order number in the order information queue.

[0143] The order information returning unit 850 is used to return the order information to the client.

[0144] It will be appreciated by those skilled in the art that various aspects of the present invention may be implemented as a system, method or program product. Therefore, various aspects of the present invention may be specifically implemented in the following forms, namely: a complete hardware implementation, a complete software implementation (including firmware, microcode, etc.), or a combination of hardware and software, which may be collectively referred to herein as a "circuit", "module" or "system".

[0145] Refer to the following Fig. 9 An electronic device 900 according to this embodiment of the present invention will be described. Fig. 9 The electronic device 900 shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0146] like Fig. 9As shown, the electronic device 900 is in the form of a general computing device. The components of the electronic device 900 may include but are not limited to: at least one processing unit 910, at least one storage unit 920, and a bus 930 connecting different system components (including the storage unit 920 and the processing unit 910).

[0147] The storage unit stores program codes, which can be executed by the processing unit 910, so that the processing unit 910 executes the steps of various exemplary embodiments of the present invention described in the "Exemplary Method" section of this specification. For example, the processing unit 910 can execute the following steps: Figure 3 As shown in S310, in response to the order submitted by the client, the order information is obtained; S320, the payment service of the payment service provider is requested according to the order information; S330, whether the payment service request is successful; S340, when the request is successful, the order information is stored in the order information queue; S350, the order information is returned to the client. The storage unit 920 may include a readable medium in the form of a volatile storage unit, such as a random access storage unit (RAM) 9201 and / or a cache storage unit 9202, and may further include a read-only storage unit (ROM) 9203.

[0148] The storage unit 920 may also include a program / utility 9204 having a set (at least one) of program modules 9205, such program modules 9205 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment.

[0149] Bus 930 may represent one or more of several types of bus structures, including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

[0150] The electronic device 900 may also communicate with one or more external devices 970 (e.g., keyboards, pointing devices, Bluetooth devices, etc.), may also communicate with one or more devices that enable a user to interact with the electronic device 900, and / or communicate with any device that enables the electronic device 900 to communicate with one or more other computing devices (e.g., routers, modems, etc.). Such communication may be performed via an input / output (I / O) interface 950. Furthermore, the electronic device 900 may also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter 960. As shown, the network adapter 960 communicates with other modules of the electronic device 900 via a bus 930. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the electronic device 900, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, etc.

[0151] Through the description of the above implementation, it is easy for those skilled in the art to understand that the example implementation described here can be implemented by software, or by software combined with necessary hardware. Therefore, the technical solution according to the implementation of the present disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, including several instructions to enable a computing device (which can be a personal computer, a server, a user terminal device, or a network device, etc.) to execute the method according to the implementation of the present disclosure.

[0152] In an exemplary embodiment of the present disclosure, a computer-readable storage medium is also provided, on which a program product capable of implementing the above method of the present specification is stored. In some possible implementations, various aspects of the present invention may also be implemented in the form of a program product, which includes a program code, and when the above program product is run on a user-end device, the above program code is used to enable the above user-end device to execute the steps according to various exemplary implementations of the present invention described in the above "Exemplary Method" section of the present specification.

[0153] refer to Fig.10 As shown, a program product 1000 for implementing the above method according to an embodiment of the present invention is described, which can adopt a portable compact disk read-only memory (CD-ROM) and include program code, and can be run on a user terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto. In this document, a readable storage medium can be any tangible medium containing or storing a program, which can be used by or in combination with an instruction execution system, an apparatus or a device.

[0154] The above program product can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but not limited to, a system, device or device of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination of the above. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0155] Computer readable signal media may include data signals propagated in baseband or as part of a carrier wave, in which readable program code is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Readable signal media may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0156] The program code embodied on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination of the foregoing.

[0157] Program code for performing the operations of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, etc., and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a separate software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving a remote computing device, the remote computing device may be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0158] It should be noted that, although several modules or units of the device for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiments of the present disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into multiple modules or units to be embodied.

[0159] In addition, although the steps of the method in the present disclosure are described in a specific order in the drawings, this does not require or imply that the steps must be performed in this specific order, or that all the steps shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps, etc.

[0160] Through the description of the above implementation, it is easy for those skilled in the art to understand that the example implementation described here can be implemented by software, or by software combined with necessary hardware. Therefore, the technical solution according to the implementation of the present disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, including several instructions to enable a computing device (which can be a personal computer, a server, a mobile user terminal, or a network device, etc.) to execute the method according to the implementation of the present disclosure.

[0161] Those skilled in the art will readily appreciate other embodiments of the present disclosure after considering the specification and practicing the invention disclosed herein. This application is intended to cover any modification, use or adaptation of the present disclosure, which follows the general principles of the present disclosure and includes common knowledge or customary techniques in the art that are not disclosed in the present disclosure. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present disclosure are indicated by the appended claims.

Claims

1. A method for processing payment anomalies, characterized in that: include: In response to an order submitted by a client, obtain order information; Requesting payment service from a payment service provider according to the order information, wherein the order information includes a payment channel identifier and an order number of the payment service provider; Determining whether the payment service request is successful; When the request is successful, the order information is stored in an order information queue, the payment channel identifier is used as a key value, and the order number is stored in the order information queue; Returning the order information to the client; Receiving a payment success notification sent by the payment service provider, storing the order information of the successful payment in a payment success queue, and deleting the order information of the successful payment in the order information queue; When the order information in the order information queue does not exist in the payment success queue, a request for querying the order status is sent to the payment service provider; when the order status is a payment waiting state, a payment alarm is triggered; when the order status is a payment closed state, the order information is deleted from the order information queue; Wherein, the method further comprises: When the payment service request of the payment service provider fails, a retry mechanism is initiated; Using the payment channel identifier as a key value, storing a preset number of times the retry mechanism is run; Obtaining a preset number of times the retry mechanism is run; Obtaining the actual number of times the retry mechanism is run within the retry time; When the actual number of operations is greater than the preset number of operations, a global threshold alarm is triggered, and the payment service provider corresponding to the payment channel identifier is removed from the shelves.

2. The processing method according to claim 1, characterized in that: Also includes: When the request is successful, obtaining a prepayment slip generated by the payment service provider, the prepayment slip including the order number, the payment channel identifier and the order status; Sending the prepaid bill to the client, so that the client sends a payment request to the payment service provider corresponding to the payment channel identifier; The payment service provider receives the payment request and pays the prepaid bill according to the payment request; After the payment service provider completes the payment, it updates the order status to a payment success status and sends a payment success notification.

3. The processing method according to claim 2, characterized in that: Also includes: Receiving a payment success notification sent by the payment service provider; The payment channel identifier is used as a key value, and the order number is stored in a successful payment queue.

4. The processing method according to claim 3, characterized in that: Also includes: Obtain the order number in the order information queue; Determine whether the order number exists in the payment success queue; If the order number exists in the payment success queue, the order number is deleted from the order information queue.

5. The processing method according to claim 4, characterized in that: Also includes: If the order number does not exist in the payment success queue, query the order status; When the order status is payment waiting status, a payment alarm is triggered; When the order status is a payment closed status, the order number is deleted from the order information queue.

6. The processing method according to claim 5, characterized in that: Also includes: Generate a payment information management interface based on the order information queue and the payment success queue; The payment information management interface is used to monitor the background data of the order information queue and the payment success queue.

7. A payment abnormality processing device, characterized in that: include: An order information acquisition unit, used to acquire order information in response to an order submitted by a client; A payment service request unit, configured to request a payment service from a payment service provider according to the order information, wherein the order information includes a payment channel identifier and an order number of the payment service provider; A request determination unit, used to determine whether the payment service request is successful; A request success unit, configured to store the order information into an order information queue when the request is successful, using the payment channel identifier as a key value, and storing the order number into the order information queue; An order information returning unit, used for returning the order information to the client; The device is also used to receive a payment success notification sent by the payment service provider, store the order information of the successful payment in the payment success queue, and delete the order information of the successful payment in the order information queue; when the order information in the order information queue does not exist in the payment success queue, send a request to query the order status to the payment service provider, and when the order status is a payment waiting state, trigger a payment alarm; when the order status is a payment closed state, delete the order number in the order information queue; when the request fails, start a retry mechanism; use the payment channel identifier as a key value to store the preset number of runs of the retry mechanism; obtain the preset number of runs of the retry mechanism; obtain the actual number of runs of the retry mechanism within the retry time; when the actual number of runs is greater than the preset number of runs, trigger a global threshold alarm, and remove the payment service provider corresponding to the payment channel identifier.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

9. An electronic device, characterized in that: include: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the one or more processors to implement the method according to any one of claims 1 to 6.

Images