阅读说明：本技术 支付异常的处理方法、处理装置、存储介质及电子设备 (Payment abnormity processing method, processing device, storage medium and electronic equipment ) 是由 李凯乐 于 2021-01-29 设计创作，主要内容包括：本公开提供了一种支付异常的处理方法、处理装置、存储介质及电子设备,涉及支付异常处理技术领域。该方法包括响应于客户端提交的订单,获取订单信息；根据所述订单信息请求支付服务方的支付服务；判断所述支付服务是否请求成功；当所述请求成功时,将所述订单信息存储到订单信息队列中；返回所述订单信息给所述客户端。通过本公开提供的技术方案,能够提高支付异常的处理效率。(The disclosure provides a payment abnormity processing method, a processing device, a storage medium and electronic equipment, and relates to the technical field of payment abnormity processing. The method comprises the steps of responding to an order submitted by a client, and obtaining order information; requesting payment service of a payment service party according to the order information; determining whether the payment service request is successful; when the request is successful, storing the order information into an order information queue; and returning the order information to the client. Through the technical scheme provided by the disclosure, the processing efficiency of payment abnormity can be improved.)

1. A method for processing payment exceptions, comprising:

responding to an order submitted by a client, and acquiring order information;

requesting payment service of a payment service party according to the order information;

determining whether the payment service request is successful;

when the request is successful, storing the order information into an order information queue;

and returning the order information to the client.

2. The processing method of claim 1, wherein the order information comprises a payment channel identification and an order number of the payment facilitator, and wherein storing the order information into the order information queue comprises:

and taking the payment channel identification as a key value, and storing the order number into the order information queue.

3. The processing method of claim 1, further comprising:

initiating a retry mechanism when the request fails;

acquiring the preset operation times of the retry mechanism;

acquiring the actual operation times of the retry mechanism within the retry time;

and triggering a global threshold value to alarm when the actual operation times are greater than the preset operation times.

4. The processing method of claim 3, further comprising:

taking the payment channel identification as a key value, and storing the preset operation times of the retry mechanism;

and when the actual operation times are larger than the preset operation times, the payment service party corresponding to the payment channel identification is off-shelf.

5. The processing method of claim 1, further comprising:

when the request is successful, acquiring a prepaid sheet generated by the payment service party, wherein the prepaid sheet comprises the order number, the payment channel identifier and the order state;

sending the prepayment sheet to the client so that the client can send a payment request to the payment server corresponding to the payment channel identifier;

the payment server side receives the payment request and pays the prepaid sheet according to the payment request;

and after the payment server finishes the payment, updating the order state into a payment success state, and sending a payment success notice.

6. The processing method of claim 5, further comprising:

receiving a payment success notice sent by the payment service party;

and taking the payment channel identification as a key value, and storing the order number into a payment success queue.

7. The processing method of claim 6, further comprising:

acquiring the order number in the order information queue;

judging whether the order number exists in the payment success queue;

and if the order number exists in the payment success queue, deleting the order number in the order information queue.

8. The processing method of claim 7, further comprising:

if the order number does not exist in the payment success queue, inquiring the order state;

when the order state is a payment waiting state, triggering a payment alarm;

and when the order state is a payment closing state, deleting the order number in the order information queue.

9. The processing method of claim 8, further comprising:

generating a payment information management interface based on the order information queue and the payment success queue;

and monitoring background data of the order information queue and the payment success queue by using the payment information management interface.

10. A payment exception handling apparatus, comprising:

the order information acquisition unit is used for responding to the order submitted by the client and acquiring order information;

a payment service request unit for requesting a payment service of a payment service provider according to the order information;

a request judging unit for judging 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;

and the order information returning unit is used for returning the order information to the client.

11. A computer-readable storage medium, on which a computer program is stored, which program, when being executed by a processor, carries out the method according to any one of claims 1 to 9.

12. An electronic device, comprising:

one or more processors;

storage means for storing one or more programs which, when executed by the one or more processors, cause the one or more processors to carry out the method of any one of claims 1 to 9.

Technical Field

The present disclosure relates to the field of payment exception handling technologies, and in particular, to a payment exception handling method, a payment exception handling apparatus, a computer-readable storage medium, and an electronic device.

Background

In the current payment service scenario, payment services are mainly completed by individual users, merchants and third-party service providers. When an individual user performs payment service with a third-party service provider on a service platform provided by a merchant terminal, due to reasons such as stability and quality problems of a network or the third-party service provider, abnormal payment can be caused, and therefore the individual user cannot acquire a correct payment state in time.

Therefore, a payment exception handling method, a payment exception handling apparatus, a storage medium, and an electronic device are needed.

It is to be noted that the information disclosed in the above background section is only for enhancement of understanding of the background of the present disclosure, and thus may include information that does not constitute prior art known to those of ordinary skill in the art.

Disclosure of Invention

The invention aims to provide a method for processing payment abnormity, which overcomes the problem of low processing efficiency of the payment abnormity at least to a certain extent.

Additional features and advantages of the disclosure will be set forth in the detailed description which follows, or in part will be obvious from the description, or may be learned by practice of the disclosure.

According to one aspect of the present disclosure, there is provided a method for processing a payment exception, including: responding to an order submitted by a client, and acquiring order information; requesting payment service of a payment service party according to the order information; determining whether the payment service request is successful; when the request is successful, storing the order information into an order information queue; and returning the order information to the client.

In an embodiment of the present disclosure, the order information includes a payment channel identifier and an order number of the payment server, and storing the order information in the order information queue includes: and taking the payment channel identification as a key value, and storing the order number into the order information queue.

In one embodiment of the present disclosure, the method further comprises: initiating a retry mechanism when the request fails; acquiring the preset operation times of the retry mechanism; acquiring the actual operation times of the retry mechanism within the retry time; and triggering a global threshold value to alarm when the actual operation times are greater than the preset operation times.

In one embodiment of the present disclosure, the method further comprises: taking the payment channel identification as a key value, and storing the preset operation times of the retry mechanism; and when the actual operation times are larger than the preset operation times, the payment service party corresponding to the payment channel identification is off-shelf.

In one embodiment of the present disclosure, the method further comprises: when the request is successful, acquiring a prepaid sheet generated by the payment service party, wherein the prepaid sheet comprises the order number, the payment channel identifier and the order state; sending the prepayment sheet to the client so that the client can send a payment request to the payment server corresponding to the payment channel identifier; the payment server side receives the payment request and pays the prepaid sheet according to the payment request; and after the payment server finishes the payment, updating the order state into a payment success state, and sending a payment success notice.

In one embodiment of the present disclosure, the method further comprises: receiving a payment success notice sent by the payment service party; and taking the payment channel identification as a key value, and storing the order number into a payment success queue.

In one embodiment of the present disclosure, the method further comprises: acquiring the order number in the order information queue; judging whether the order number exists in the payment success queue; and if the order number exists in the payment success queue, deleting the order number in the order information queue.

In one embodiment of the present disclosure, the method further comprises: if the order number does not exist in the payment success queue, inquiring the order state; when the order state is a payment waiting state, triggering a payment alarm; and when the order state is a payment closing state, deleting the order number in the order information queue.

In one embodiment of the present disclosure, the method further comprises: generating a payment information management interface based on the order information queue and the payment success queue; and monitoring background data of the order information queue and the payment success queue by using the payment information management interface.

According to another aspect of the present disclosure, there is provided a payment exception handling apparatus, including: the order information acquisition unit is used for responding to the order submitted by the client and acquiring order information; a payment service request unit for requesting a payment service of a payment service provider according to the order information; a request judging unit for judging whether the payment service request is successful; when the request is successful, storing the order information into an order information queue; and the order information returning unit is used for returning the order information to the client.

In one embodiment of the present disclosure, the request success unit includes: and the order information queue storage unit is used for storing the order number into the order information queue by taking the payment channel identifier as a key value.

In one embodiment of the present disclosure, the apparatus further comprises: a retry mechanism starting unit configured to start a retry mechanism when the request fails; a preset operation frequency obtaining unit, configured to obtain a preset operation frequency of the retry mechanism; an actual operation number obtaining unit, configured to obtain an actual operation number of the retry mechanism within a retry time; and the global threshold alarm triggering unit is used for triggering global threshold alarm when the actual operation times are greater than the preset operation times.

In one embodiment of the present disclosure, the apparatus further comprises: the preset operation frequency storage unit is used for storing the preset operation frequency of the retry mechanism by taking the payment channel identification as a key value; and the payment server off-shelf unit is used for off-shelf the payment server corresponding to the payment channel identifier when the actual operation times are greater than the preset operation times.

In one embodiment of the present disclosure, the apparatus further comprises: a prepaid form acquisition unit for acquiring a prepaid form generated by the payment service when the request is successful, the prepaid form including the order number, the payment channel identification, and an order status; a payment request sending unit, configured to send the prepaid sheet to the client, so that the client sends a payment request to the payment service provider corresponding to the payment channel identifier; a prepaid sheet payment unit for the payment service provider to receive the payment request and pay the prepaid sheet according to the payment request; and the payment success notification sending unit is used for updating the order state into a payment success state and sending a payment success notification after the payment server completes the payment.

In one embodiment of the present disclosure, the apparatus further comprises: a payment success notification receiving unit, configured to receive a payment success notification sent by the payment service provider; and the payment success queue storage unit is used for storing the order number into a payment success queue by taking the payment channel identification as a key value.

In one embodiment of the present disclosure, the apparatus further comprises: the order number acquisition unit is used for acquiring the order numbers in the order information queue; an order number judgment unit for judging whether the order number exists in the payment success queue; and the order number deleting unit is used for deleting the order number in the order information queue if the order number exists in the payment success queue.

In one embodiment of the present disclosure, the apparatus further comprises: the order state query unit is used for querying the order state if the order number does not exist in the payment success queue; the payment alarm triggering unit is used for triggering a payment alarm when the order state is a payment waiting state; and the order number deleting unit is used for deleting the order number in the order information queue when the order state is a payment closing state.

In one embodiment of the present disclosure, the apparatus further comprises: the payment information management interface generating unit is used for generating a payment information management interface based on the order information queue and the payment success queue; and the background data monitoring unit is used for monitoring the background data of the order information queue and the payment success queue by using the payment information management interface.

According to yet another aspect of the present disclosure, there is provided an electronic device, including: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform the above-described payment exception handling method via execution of the executable instructions.

According to yet another aspect of the present disclosure, there is provided a computer-readable storage medium, on which a computer program is stored, the computer program, when executed by a processor, implementing the above-mentioned method for processing a payment exception.

The embodiment of the disclosure provides a method for processing payment exception, after a merchant terminal obtains order information submitted by a client terminal, a payment service of a payment service provider is requested, after the payment service is successfully requested, the order information is stored in an order information queue, and the order information is returned to the client terminal. When the payment is abnormal, the merchant terminal can solve the problem of abnormal payment according to the order information queue stored with the order information, and the processing efficiency of the abnormal payment is improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and together with the description, serve to explain the principles of the disclosure. It is to be understood that the drawings in the following description are merely exemplary of the disclosure, and that other drawings may be derived from those drawings by one of ordinary skill in the art without the exercise of inventive faculty.

FIG. 1 is a schematic diagram illustrating a computer system according to an embodiment of the present disclosure;

FIG. 2 illustrates a flow diagram of a payment service in an embodiment of the present disclosure;

FIG. 3 is a flow chart illustrating a method for processing a payment exception in an embodiment of the present disclosure;

FIG. 4 is a flow chart illustrating a method for processing a payment exception according to an embodiment of the present disclosure;

FIG. 5 is a flow chart illustrating another payment exception handling method in an embodiment of the present disclosure;

FIG. 6 is a flow chart illustrating a method for processing a payment exception according to yet another embodiment of the present disclosure;

FIG. 7 is a flow chart illustrating a method for processing a payment exception according to yet another embodiment of the present disclosure;

FIG. 8 is a schematic diagram illustrating a device 800 for processing payment exceptions in accordance with an embodiment of the present disclosure;

FIG. 9 shows a block diagram of an electronic device 900 in an embodiment of the disclosure;

fig. 10 shows a schematic diagram of a program product 1000 for implementing the above method in an embodiment of the present disclosure.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of 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.

Furthermore, the drawings are merely schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus their repetitive description will be omitted. Some of the block diagrams shown in the figures are functional entities and do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

The flow charts shown in the drawings are merely illustrative and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.

The inventor of the present invention finds that in the prior art, at least the following problem exists, namely, in the prior art, the merchant terminal depends on the payment success notification sent by the payment service side, and cannot continuously complete the payment service when the payment is abnormal. The specific payment exception is as follows:

1) when the merchant terminal acquires the payment information of the payment service party, the acquisition is easily failed due to a network or other reasons, so that whether the payment can be carried out is uncertain, and if the payment is abandoned, the user loss of the merchant terminal may be caused.

2) The merchant side only knows the status of the payment order according to the payment success notification sent by the payment facilitator. In some payment scenarios, for example, the merchant does not receive the payment success notification due to network reasons or stability and quality problems of the payment service, and the merchant cannot know the status of the payment order. When a user initiates a request for inquiring the state of a payment order to a merchant terminal through a client terminal, the merchant terminal cannot respond to the inquiry request and cannot return the state of the payment order to the client terminal, and if the user cannot inquire the state of the payment order later, complaints may occur.

3) After the payment server completes payment, the payment order is in a waiting state possibly due to the problems of the network state of the merchant terminal and the like, so that the payment server does not send a payment success notification, and when the client sends an inquiry request to the merchant terminal, the merchant terminal cannot respond to the inquiry request of the client terminal because the merchant terminal does not receive the payment success notification. At the moment, no corresponding processing method exists for the condition that the payment order is in a waiting state or an order closing state, so that the problem that the experience of the user is poor in the transaction process is caused.

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

Fig. 1 shows a schematic structural diagram of a computer system in an embodiment of the present disclosure. As shown in FIG. 1, FIG. 1 provides a schematic diagram of the structure of a computer system of an exemplary embodiment. The system comprises: a number of user terminals 120, merchant terminals 130, and payment services 140.

The user end 120 may be a mobile user end 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, an intelligent home device, an AR (Augmented Reality) device, a VR (Virtual Reality) device, or a Personal Computer (PC), such as a laptop Computer and a desktop Computer.

The user terminal 120 may be installed with an application program for the user terminal 120 to interact with the merchant terminal 130.

The user terminal 120 and the payment service provider 140 are connected through a communication network. In some embodiments, the communication network is a wired network or a wireless network.

The merchant terminal 130 includes a merchant client and a merchant server, where the merchant client is a virtualization platform, and integrates a visualization page with the merchant server to provide merchant information in the visualization page. The merchant server may be one or more servers.

The payment server 140 is a server, or consists of several servers, or is a virtualization platform, or a cloud computing service center. The payment facilitator 140 is used to provide background services for applications that provide payment services. In some embodiments, the payment facilitator 140 undertakes primary computing work and the user terminal 120 undertakes secondary computing work; alternatively, the payment facilitator 140 undertakes the secondary computing work and the user terminal 120 undertakes the primary computing work; alternatively, the user terminal 120 and the payment service provider 140 perform cooperative computing by using a distributed computing architecture.

In some embodiments, the payment facilitator 140 is configured to store information of the payment channel of the payment facilitator.

In some embodiments, the payment facilitator 140 is further coupled to the server system 142, and the payment facilitator 140 stores the transaction information and/or transaction records provided by the merchant at the server system 142. In some embodiments, the payment facilitator 140 itself may also operate and store the data as a node in the server system.

In some embodiments, the payment facilitator 140 includes a logic server (not shown in FIG. 1) and a payment server (not shown in FIG. 1). The logic server is used to implement logic control of the application program, for example, request processing for commodity transaction, account resource management, interface content management, and the like, and the payment server is used as a part of the server system 142 to implement storage of transaction information and/or transaction records of each user terminal 120 and decision management of important functions, for example, decision of a payment request can be implemented.

It should be noted that the logic server and the payment server may belong to the same computer device, or the logic server and the payment server may belong to different computer devices.

In some embodiments, the applications installed in different clients 120 are the same, or the clients of the applications installed on two clients 120 are clients of the same type of application of different control system platforms. Based on different client platforms, the client of the application program has different specific forms, for example, the client of the application program may exist in a mobile phone client platform, a PC (Personal computer) client platform, or a World Wide Web (Web) client platform.

Those skilled in the art will appreciate that the number of the user terminals 120 may be greater or less. For example, the number of the user terminals may be only one, or several tens or hundreds of the user terminals, or a larger number. The number of the user terminals and the type of the device are not limited in the embodiment of the application.

In some embodiments, the system may further include a management device (not shown in fig. 1) connected to the payment facilitator 140 via a communication network. In some embodiments, the communication network is a wired network or a wireless network.

In some embodiments, the wireless or wired networks described above use standard communication technologies and/or protocols. The Network is typically the Internet, but may 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, wireline or wireless Network, a private Network, or any combination of virtual private networks. In some embodiments, data exchanged over a network is represented using techniques and/or formats including Hypertext Mark-up Language (HTML), Extensible markup Language (XML), and the like. All or some of the links may also be encrypted using conventional encryption techniques such as Secure Socket Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), Internet protocol Security (IPsec). In other embodiments, custom and/or dedicated data communication techniques may also be used in place of, or in addition to, the data communication techniques described above.

Hereinafter, each step of the processing method of the payment exception in the present exemplary embodiment will be described in more detail with reference to the drawings and the examples.

Fig. 2 shows a flow diagram of a payment service in an embodiment of the disclosure. As shown in fig. 2, fig. 2 provides a method flow of a payment service. The method includes, but is not limited to, the steps of:

in S210, an order is placed. The client sends a ordering request to the merchant terminal.

In S220, the merchant generates an order and requests payment information. And the merchant receives the order placing request, generates an order and requests the payment information of the order from the payment server.

In one embodiment, the payment facilitator may be a technical facilitator with a state-issued payment transaction license, such as WeChat and Payment treasures.

In S230, the payment server transmits payment information. And after receiving the request sent by the merchant terminal, the payment server side sends the payment information of the order to the client side.

In S240, the client receives payment information. And after receiving the payment information, the client selects a payment server for paying the order.

In S250, the client sends a payment request to the payment server.

In S260, the payment service side receives the payment request, and completes the payment process of the order.

In S270, the payment facilitator asynchronously sends a payment notification. And after the payment server side successfully pays the order, asynchronously sending a payment success notice to the merchant side.

In S280, the merchant terminal asynchronously receives the payment notification. And after receiving the payment success notification, the merchant continues to perform subsequent business operations of the order, such as packaging the goods, arranging goods for delivery and the like.

The embodiment of the disclosure provides a method for processing payment exception. The methods provided in the embodiments of the present disclosure may be performed by any electronic device with computing processing capabilities, such as the merchant terminal 130 and/or the payment service provider 140 in fig. 1. In the following description, the merchant terminal 130 is taken as an execution subject for illustration.

Fig. 3 shows a flowchart of a processing method of a payment exception in an embodiment of the present disclosure. As shown in fig. 3, fig. 3 provides a processing method in a payment exception scenario. The method includes, but is not limited to, the steps of:

in S310, order information is acquired in response to an order submitted by a client. The client submits the order to the merchant terminal, and the merchant terminal responds to the order and acquires the order information.

In S320, a payment service of the payment service provider is requested according to the order information. And the merchant terminal sends a payment service request to the payment service party according to the order information, and the payment service request is used for requesting the payment service of the order.

In S330, it is determined whether the payment service request is successful. The payment service side receives a payment service request of the merchant side and generates a prepayment sheet, and the prepayment sheet comprises a payment channel mark of the payment service side. And sending the prepaid bill to the merchant terminal. If the merchant end receives the prepayment bill, the payment service request is successful. And if the merchant terminal does not receive the prepayment bill, the payment service request is not successful.

In S340, when the request is successful, the order information is stored in the order information queue. After the merchant receives the prepaid order, the order information is stored in an order information queue, and the order information can comprise order number, commodity information, address information, time information, amount information and other information.

In one embodiment, the order information includes a payment channel identification and an order number of the payment facilitator, and storing the order information into the order information queue includes: and taking the payment channel identification as a key value, and storing the order number into an order information queue. In the embodiment of the present disclosure, the order information may further include a payment channel mark, different payment service providers have different payment channel marks, and the payment services of the different payment service providers can be obtained according to the payment channel mark. And based on the database, taking the payment channel mark as a key value, and storing the order number into an 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 a Remote Dictionary service (Remote Dictionary service) database as a key value database as an example, the order number is stored in the order information queue by using the Remote Dictionary database.

In S350, order information is returned to the client. And the merchant side returns the obtained order information to the client side.

Fig. 4 shows a flowchart of a method for processing a payment exception in an embodiment of the present disclosure. As shown in fig. 4, fig. 4 provides a processing method in a payment exception scenario. The method includes, but is not limited to, the steps of:

in S410, the client submits an order. The user submits the order to the merchant terminal through the client terminal.

In S420, the merchant acquires the order information, and requests the payment service of the payment service provider according to the order information. The merchant side combines the order information and the order data and then requests the payment service from the payment service side.

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.

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

In S450, order information is returned to the client. And the merchant side returns the order information to the client side.

In S460, the retry is performed once. And when the payment service is not successfully requested, the merchant terminal re-requests the payment service.

In S470, a global threshold alarm is performed.

In one embodiment, when a request fails, a retry mechanism is initiated; acquiring the preset operation times of a retry mechanism; acquiring the actual operation times of a retry mechanism in the retry time; and triggering a global threshold value to alarm when the actual operation times are greater than the preset operation times. In the disclosed embodiment, the retry-initiating mechanism re-requests the payment service of the payment service provider on behalf of the merchant terminal. A timer may be used to count the time, and if the actual number of times of operation of the retry mechanism is greater than the preset number of times of operation of the retry mechanism within the retry time, a global threshold alarm may be issued. The embodiment of the disclosure can eliminate the influence of bad network on the payment service by performing a retry mechanism, thereby solving the problem of user loss caused by the failure of the payment service due to network or other reasons.

In embodiments of the present disclosure, the technical framework implementing the timer may comprise a distributed task scheduling framework, such as an Elastic-job scheduling framework.

In one embodiment, the payment channel identifier is used as a key value, and the preset operation times of the retry mechanism are stored; and when the actual operation times are greater than the preset operation times, the payment service party corresponding to the payment channel identifier is off-shelved. Based on the key-value database, the payment channel indicia is keyed to store a preset number of operations of the retry mechanism. And when the actual operation times of the retry mechanism are greater than the preset operation times, identifying the corresponding payment server in the off-shelf payment channel of the merchant terminal, and enabling manual intervention to search the reason of the payment service failure of the payment server and solve the problem of the payment service failure.

Fig. 5 shows a flowchart of another payment exception handling method in an embodiment of the present disclosure. As shown in fig. 5, fig. 5 provides a processing method in a payment exception scenario. The method includes, but is not limited to, the steps of:

in S510, when the request is successful, a prepaid sheet generated by the payment service is acquired, the prepaid sheet including the order number, the payment channel identifier, and the order status. In the embodiment of the disclosure, the merchant terminal requests the payment service from the payment service side. The payment facilitator receives the request, generates a prepaid order and transmits the prepaid order to the merchant location, the prepaid order including an order number, a payment channel indicia for the payment facilitator, and an order status.

In S520, the prepaid sheet is transmitted to the client, so that the client transmits a payment request to the payment service provider corresponding to the payment channel identifier. In the embodiment of the disclosure, the merchant terminal includes merchant application software and a merchant server. The payment server comprises payment software and a payment server. Wherein, 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, and can also perform business transaction with the payment server by operating the payment software. The merchant terminal sends the received prepaid sheet to the merchant application software so that the merchant application software provides different payment software for the user according to the prepaid sheet. After the user selects the payment software on the merchant application software on the client, the client sends a payment request to the corresponding payment service party according to the payment channel mark corresponding to the selected payment software.

In S530, the payment service part receives the payment request and pays the prepaid sheet according to the payment request. And the payment service party receives the payment request from the client and completes the payment of the prepaid bill.

In S540, after the payment service completes the payment, the order status is updated to a payment success status, and a payment success notification is sent. In the embodiment of the disclosure, after the payment service party finishes the payment of the payment prepaid form, the order state in the prepaid form is updated to the payment success state, and a payment success notification is sent to the merchant terminal.

According to the embodiments provided in S510-S540, when the payment service provider cannot provide the payment service due to a network or the like, the problem that the request of the payment service from the merchant terminal to the payment service provider fails can be solved.

Fig. 6 is a flowchart illustrating a method for processing a payment exception according to another embodiment of the disclosure. As shown in fig. 6, fig. 6 provides a processing method in a payment exception scenario. The method includes, but is not limited to, the steps of:

in S610, when the request is successful, a prepaid sheet generated by the payment service is acquired, the prepaid sheet including the order number, the payment channel identifier, and the order status.

In S620, the prepaid sheet is transmitted to the client, so that the client transmits a payment request to the payment service provider corresponding to the payment channel identifier.

In S630, the payment service part receives the payment request and pays the prepaid sheet according to the payment request.

In S640, after the payment service completes the payment, the order status is updated to a successful payment status, and a successful payment notification is sent.

Wherein, the embodiments in S510-S540 can be referred to in S610-S640. The descriptions of S650-S660 are as follows:

in S650, a payment success notification sent by the payment service side is received. After the merchant receives the payment success notification, the merchant can know that the order state is the payment success state.

In S660, the payment channel identifier is used as a key value, and the order number is stored in a payment success queue. Based on the key value database, the merchant terminal takes the payment channel mark as a key value and stores the order number into a payment success queue.

In one embodiment, the order number in the order information queue is obtained; judging whether the order number exists in the payment success queue; and if the order number exists in the payment success queue, deleting the order number in the order information queue. In the embodiment of the present disclosure, the merchant acquires 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, which indicates that the payment of the prepaid order is successful, the merchant end receives the payment success notice sent by the payment service party, and then deletes the order number in the order information queue.

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 and judge whether the order number exists in the payment success queue.

In one embodiment, if the order number does not exist in the payment success queue, the order status is queried; when the order state is a payment waiting state, triggering a payment alarm; and when the order state is a payment closing state, deleting the order number in the order information queue. And when the order number acquired from the order information queue by the merchant side does not exist in the payment success queue, the fact that the prepaid order is not paid successfully is indicated, and the payment server does not send a payment success notice. The merchant terminal actively sends a request for inquiring the order state to the payment server side, and the payment server side receives the request of the merchant terminal and sends the order state to the merchant terminal. The order status includes a payment hold status and a payment close status. When the order status is the payment waiting status, it indicates that the order may be waiting for payment due to network delay and the like. When the order state is the payment closing state, it indicates that the order may be closed due to reasons such as the order being overdue, the user giving up payment, or the order being invalid, and at this time, the merchant deletes the order number in the order information queue. According to the technical scheme provided by the embodiment of the disclosure, corresponding processing can be performed according to different order states. And when the payment server does not successfully send the payment success notification, the merchant terminal actively sends a request for inquiring the order state to the payment server, and the payment server responds to the request of the merchant terminal and sends the order state to the merchant terminal. The merchant terminal carries out corresponding processing according to different order states and sends the order states to the client terminal, so that the user can master the order states, and the problem that the user experiences poor experience in the transaction process at the merchant terminal is further solved.

In one embodiment, a timer may be used to enable the merchant to send a request for the status of the order to the payment server at regular time.

In one embodiment, a payment information management interface is generated based on the order information queue and the payment success queue; and monitoring background data of the order information queue and the payment success queue by using the payment information management interface. In the embodiment of the disclosure, when the payment is abnormal, the merchant terminal may generate the payment information management interface through log monitoring information, order information of the fixed rule and a change condition of the order information queue and the payment success queue. On the payment information management interface, background data such as response time, response frequency, system performance consumption and the like of a merchant terminal requesting payment service from a payment service party can be monitored.

Fig. 7 is a flowchart illustrating a method for processing a payment exception according to another embodiment of the disclosure. As shown in fig. 7, fig. 7 provides a processing method in a payment exception scenario. The method for processing the payment abnormity can be realized through the client, the merchant end and the payment server. The payment services may include WeChat, Payment treasures, and Unionpay official software. In the disclosed embodiment, the payment service is a WeChat. The method includes, but is not limited to, the steps of:

in S701, a placing request is sent. The user clicks a link on the client or scans the two-dimensional code using the client to open an order page for the merchant to send an order placement request.

In S702, the merchant generates an order, where the order includes an order number, commodity information, address information, time information, amount information, and other information.

In S703, the merchant terminal requests a payment service. The merchant side combines the order information with the payment channel mark of the payment service side, and requests the payment service side for payment service according to the order.

In S704, the wechat generates a prepaid order. And the WeChat receives a request of the payment service sent by the merchant terminal to generate a prepayment sheet.

In S705, the WeChat returns the prepaid form including the prepaid form number, order status, and payment channel indicia. The WeChat sends the prepaid order to the merchant location.

In S706, the merchant stores the order information in the order information queue. And the business side stores the order information into an order information queue.

In S707, the merchant terminal returns the prepaid sheet to the client terminal.

In S708, the client sends a payment request. And after receiving the prepayment order, the client sends a payment request to the WeChat according to the payment channel mark.

In S709, the wechat receives the payment request sent by the client, and pays for the prepaid sheet.

In S710, the WeChat obtains the payment result.

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

In S712, the WeChat updates the order status according to the payment result. And if the payment is successful, updating the order state to a payment success state. And if the order is in a payment waiting state, updating the order state into a payment waiting state. If the order is closed, the order status is updated to a payment closed status.

In S713, the WeChat sends a payment success notification. And when the order state is a payment success state, sending a payment success notice to the merchant terminal by the WeChat. The WeChat may send the payment success notification in a synchronous sending manner, and may also send the payment success notification in an asynchronous sending manner, which is not limited in the present disclosure.

In S714, after receiving the payment success notification, the merchant stores the order information into the payment success queue. In one embodiment, the order information is transmitted in the form of a ciphertext over the communications network. And after receiving the payment success notification, the merchant terminal decrypts, checks and verifies the order information in the payment success notification, namely judges and verifies the order information by using the agreed encryption mode and decryption mode, and stores the verified order information into a payment success queue.

In S715, the merchant determines whether the order information in the order information queue exists in the payment success queue. If so, the process proceeds to S716. If not, the process proceeds to S717.

In S716, the merchant deletes the order information in the order information queue. And when the order information in the order information queue exists in the payment success queue, the merchant terminal deletes the order information in the order information queue.

In S717, the merchant transmits a request for inquiring the order status. And when the order information in the order information queue does not exist in the payment success queue, the merchant side sends a request for inquiring the order state to the WeChat.

In S718, the WeChat receives a request to query the status of the order.

At S719, the WeChat returns the order status. After receiving the request for inquiring the order state sent by the merchant side, the WeChat returns the inquired order state to the merchant side.

In S720, the merchant terminal receives the order status.

In S730, the client queries the order status. And after receiving the payment result, the client sends a request for inquiring the order state to the merchant terminal.

In S731, the merchant returns the order status. And after receiving the request for inquiring the order state sent by the client, the merchant returns the inquired order state to the client.

In S732, the client checks the order status. The client can view the order status.

In the embodiments provided in S701-S732, the merchant terminal actively issues a request for inquiring the status of the order to the payment server, and dynamic changes of the status of the order can be obtained, so that when the client terminal issues a request for inquiring the status of the payment order to the merchant terminal, the merchant terminal can respond to the inquiry request in time and return the status of the payment order to the client terminal, and further, the problem that the user complains about the merchant terminal is solved.

It is to be noted that the above-mentioned figures are only schematic illustrations of the processes involved in the method according to an exemplary embodiment of the invention, and are not intended to be limiting. It will be readily understood that the processes shown in the above figures are not intended to indicate or limit the chronological order of the processes. In addition, it is also readily understood that these processes may be performed synchronously or asynchronously, e.g., in multiple modules.

Fig. 8 shows a schematic diagram of a device 800 for processing a payment exception in an embodiment of the present disclosure. As shown in fig. 8, a payment abnormality processing apparatus 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.

An order information obtaining unit 810, configured to obtain order information in response to an order submitted by a client.

A payment service request unit 820, configured to request a payment service of the payment service provider according to the order information.

The request determining unit 830 is configured to determine whether the payment service request is successful.

A request success unit 840, configured to store the order information into the order information queue when the request is successful.

In one embodiment, the request success unit 840 includes an order information queue storage unit, configured to store the order number into the order information queue by using the payment channel identifier as a key.

An order information returning unit 850, configured to return the order information to the client.

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or program product. Thus, various aspects of the invention may be embodied in the form of: an entirely hardware embodiment, an entirely software embodiment (including firmware, microcode, etc.) or an embodiment combining hardware and software aspects that may all generally be referred to herein as a "circuit," module "or" system.

An electronic device 900 according to this embodiment of the invention is described below with reference to fig. 9. The electronic device 900 shown in fig. 9 is only an example and should not bring any limitations to the function and scope of use of the embodiments of the present invention.

As shown in fig. 9, the electronic device 900 is embodied in the form of a general purpose computing device. Components of electronic device 900 may include, but are not limited to: the at least one processing unit 910, the at least one memory unit 920, and a bus 930 that couples various system components including the memory unit 920 and the processing unit 910.

Wherein the storage unit stores program codes, which can be executed by the processing unit 910, so that the processing unit 910 executes the steps according to various exemplary embodiments of the present invention described in the "exemplary method" section above in this specification. For example, the processing unit 910 may execute S310 shown in fig. 3, in response to an order submitted by a client, acquiring order information; s320, requesting the payment service of the payment service party according to the order information; s330, judging whether the payment service request is successful; s340, when the request is successful, storing the order information into an order information queue; and S350, returning the order information 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 memory unit (RAM)9201 and/or a cache memory unit 9202, and may further include a read only memory unit (ROM) 9203.

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 thereof, may comprise an implementation of a network environment.

Bus 930 can be any 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.

The electronic device 900 may also communicate with one or more external devices 970 (e.g., keyboard, pointing device, bluetooth device, etc.), with one or more devices that enable a user to interact with the electronic device 900, and/or with any devices (e.g., router, modem, etc.) that enable the electronic device 900 to communicate with one or more other computing devices. Such communication may occur via input/output (I/O) interface 950. Also, the electronic device 900 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN) and/or a public network, such as the Internet) via the network adapter 960. As shown, the network adapter 960 communicates with the other modules of the electronic device 900 via the bus 930. It should be appreciated that although not shown, 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, among others.

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, a client device, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.

In an exemplary embodiment of the present disclosure, there is also provided a computer-readable storage medium having stored thereon a program product capable of implementing the above-described method of the present specification. In some possible embodiments, the various aspects of the present invention may also be implemented in the form of a program product comprising program code means for causing a user end device to carry out the steps according to various exemplary embodiments of the present invention described in the above section "exemplary method" of this specification, when said program product is run on the user end device.

Referring to fig. 10, a program product 1000 for implementing the above method according to an embodiment of the present invention is described, which may employ a portable compact disc read only memory (CD-ROM) and include program code, and may be run on a user end device, such as a personal computer. However, the program product of the present invention is not limited in this regard and, in the present document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

The program product described above may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having 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 disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

A computer readable signal medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A readable signal medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device and partly on a remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any kind 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., through the internet using an internet service provider).

It should be noted that although in the above detailed description several modules or units of the device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit, according to embodiments of the present disclosure. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units.

Moreover, although the steps of the methods of the present disclosure are depicted in the drawings in a particular order, this does not require or imply that the steps must be performed in this particular order, or that all of the depicted steps must be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions, etc.

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments 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 disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a mobile client, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.