CA3052768A1 - Refund processing method and device, electronic device, and storage medium - Google Patents

Abstract

The invention provides a refund processing method and a device, an electronic device and a computer-readable storage medium, belonging to the technical field of computers and communications. The method comprises the following steps: obtaining a refund request and copying the refund request into a message list; if the history waiting to send request is detected in the message list, transmitting the detected history waiting to send request, and detecting whether the history waiting to send request exists in the message list again after a preset time; if it is detected that there is no historical pending request in the message list, the refund request is sent. The invention can reduce the processing delay of the refund request, improve the efficiency, realize the resending of the refund request under the condition of occupying less system resources, and has high utilization rate of the system resources.

Description

Refund processing method and device, electronic device, and storage medium Technical Field [0001] The present disclosure relates to the field of computer and communication technologies, and in particular, to a refund processing method and apparatus, an electronic equipment, and a computer readable storage medium.
Background Technology

[0002] With the development of computers and electronic equipment, electronic payment methods are becoming more and more popular, and people are becoming more and more popular in daily life. For example, consumers can use POS machines (Point of Sales).
Pay the bank card to complete the payment, or you can pay by mobile app (Application), online banking, etc.

[0003] When electronic payment encounters a situation in which a refund is required, the processing flow is more complicated. For example, if the merchant refunds to the consumer, the merchant needs to send the refund request to the management party of the electronic payment, such as the back office of the bank and the background of the third-party payment platform, etc., and the management party reviews the refund request, and then approves the refund request. The form of the original transaction is revoked and the money is returned to the consumer account. If the refund is not completed within the predetermined time due to network failure, abnormal refund request, etc. (for example, the POS refund needs to be completed on the same day, WeChat payment needs to be confirmed within 24 hours, etc.), the refund request may be cancelled or Being upgraded, the need to re-initiate a refund or the need to provide more verification information to the management, greatly extend the refund process, resulting in inefficient refund processing.

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

[0005] An object of the present disclosure is to provide a refund processing method and apparatus, an electronic equipment, and a computer readable storage medium, and at least to some extent overcome the problem that the existing refund processing method cannot be processed in time when the refund is abnormal..

[0006] Other features and advantages of the present disclosure will be apparent from the following detailed description.

[0007] According to an aspect of the present disclosure, a refund processing method is provided, including: obtaining a refund request, and copying the refund request into a message list; if it is detected that there is a history to be sent in the message list Sending, by the request, the historical to-be-sent request, and detecting whether there is a historical to-be-sent request in the message list after a preset time; if it is detected that there is no historical to-be-sent request in the message list, sending the Refund request.

[0008] In an exemplary embodiment of the present disclosure, the method further includes: after transmitting the refund request, detecting whether feedback information about the refund request is received; if the feedback information is received And deleting the refund request from the message list; if the feedback information is not received within the preset time, marking the refund request in the message list as a historical to-be-sent request.

[0009] In an exemplary embodiment of the present disclosure, the refund request is copied to a message list including encrypting the refund request and copying the encrypted refund request to the message list.

[0010] In an exemplary embodiment of the present disclosure, the method further includes: after copying the encrypted refund request into the message list, presenting the refund request; if receiving the external The input confirmation command detects whether there is a historical pending request in the message list.

[0011] In an exemplary embodiment of the present disclosure, encrypting the refund request includes converting the refund request to an intermediate code by a Huffman encoding rule; filling the intermediate code with a preset number The number of bits of the intermediate code after the preset number is filled is a multiple of n; the intermediate code after the preset number is filled is converted into an encrypted string by a 2n -bit encoding rule; wherein n is greater than 1. Integer.

[0012] In an exemplary embodiment of the present disclosure, the refund request includes refund order information, refund amount information, and an allowable refund identifier; converting the refund request to a Huffman encoding rule to The intermediate encoding includes: forming the refund order information, the refund amount information, the allowable refund identifier, and the encrypted version number into a sequence of characters; converting the sequence of characters into the intermediate code by the Huffman encoding rule; The encrypted version number has a correspondence with the Huffman encoding rule, a rule for populating a preset number, and a 2" -bit encoding rule.

[0013] In an exemplary embodiment of the present disclosure, if it is detected that there is no historical to-be-sent request in the message list, sending the refund request includes: if it is detected that there is no history in the message list When the request is to be sent, the encrypted refund request is sent.

[0014] According to an aspect of the present disclosure, there is provided a refund processing apparatus for applying to a terminal including an input apparatus, comprising:
requesting a copy module for acquiring a refund request, and copying the refund request to a message list a list detection module, configured to detect whether there is a historical to-be-sent request in the message list, and a history sending module, configured to send the historical to-be-sent request if the history pending request exists in the message list, and After the preset time, it is detected again whether there is a historical to-be-sent request in the message list; the current sending module is configured to send the refund request if there is no historical to-be-sent request in the message list.

[0015] According to one aspect of the disclosure, an electronic device is provided, including a processor, and a memory for storing executable instructions of the processor, wherein the processor is configured to execute any of the methods described above by executing the executable instructions.

[0016] According to an aspect of the present disclosure, a computer readable storage medium having stored thereon a computer program, the computer program being executed by a processor, implements the method of any of the above.

[0017] In the above method and apparatus, after obtaining the refund request, copying it to the message list, and detecting whether there is a historical pending request in the message list, if yes, sending a historical pending request, if not, sending The refund request. On the one hand, in the case that the historical refund request processing caused by network failure or abnormal information is unsuccessful, when a new refund request occurs, the historical refund request can be processed again to reduce the delay of the refund request processing.
Situation, improve efficiency. On the other hand, when all the historical pending requests have been sent, the current refund request can be sent, so that the user can be reminded of the unsuccessful processing of the historical refund request, so that the user can promptly check the cause and deal with it accordingly. . In another aspect, the historical pending request in this embodiment is not repeated attempts to send, but attempts to resend when a new refund request occurs, because the occurrence of a new refund request may indicate that the historical refund request is not processed. The reason for the success has been solved. At this time, the probability of attempting to resend is large.
Compared with the method of repeatedly trying to send, this embodiment improves the probability of success of resending as much as possible when the system resources are occupied less. The utilization of system resources is high.

[0018] The above general description and the following detailed description are intended to be illustrative and not restrictive.
Brief Description

[0019] Drawings herein are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the principles of the embodiments of the present disclosure, and together with the description serve to explain the present disclosure. It is apparent that the drawings in the following description are only some of the embodiments of the present disclosure, and other drawings may be obtained from those skilled in the art without departing from the drawings.

[0020] Figure 1 shows a system architecture diagram of a refund processing method to which an exemplary embodiment of the present disclosure is applied;

[0021] Figure 2 shows a flowchart of a refund processing method in an exemplary embodiment of the present disclosure;

[0022] Figure 3 is a schematic diagram showing a refund request in an exemplary embodiment of the present disclosure;

[0023] Figure 4 shows a flow chart of another refund processing method in an exemplary embodiment of the present disclosure;

[0024] Figure 5 illustrates a sub-flow diagram of a refund processing method in an exemplary embodiment of the present disclosure;

[0025] Figure 6 is a block diagram showing the structure of a refund processing apparatus in an exemplary embodiment of the present disclosure;

[0026] Figure 7 illustrates an electronic equipment for implementing the above method in an exemplary embodiment of the present disclosure; Figure

[0027] Figure 8 illustrates a computer readable storage medium for implementing a method in an exemplary embodiment of the present disclosure.
Description of the Preferred Examples

[0028] Example embodiments will now be described more fully with reference to the accompanying drawings. However, the example embodiments can be implemented in various forms and should not be construed as being limited to the examples described herein; on the contrary, the provision of these embodiments will make the present disclosure more comprehensive and complete and will fully convey the concept of the example embodiments to those skilled in the art. The described attributes, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0029] An exemplary embodiment of the present disclosure provides a refund processing method that can be applied to a terminal that supports electronic payment, such as a computer, a POS
machine, a smart phone, and the like. Figure 1 shows a system architecture diagram in which a refund processing method of the present exemplary embodiment can be applied.
As shown in Figure 1, the system 100 can include a payer terminal 101, a payee terminal 102, a network 103, and a server 104. In the present exemplary embodiment, the payer and the payee refer to the payer and the payee of the original transaction. In the refund processing, the refund request may be initiated by either of the payer and the payee. Network 103 is used to provide communication connections between payer terminal 101, payee terminal 102, and server 104, and may include various types of connections, such as wired, wireless communication links, fiber optic cables, and the like. The server 104 refers to a management server that reviews a refund request, such as a bank backend server, a server of a third party payment platform, and the like.

[0030] It should be noted that the system shown in Figure 1 may also include only one of the payer terminal and the payee terminal, and the number of terminals, networks, and servers is not limited to the case shown in Figure 1, according to actual conditions. Any number of terminals, networks, and servers can be set up as needed.

[0031] Referring to Figure 2, the refund processing method may include the following steps S21 to S23:

[0032] Step S21, obtaining a refund request and copying the refund request into the message list.

[0033] The refund request may be generated according to the input information of the user, for example, the user inputs the information of the refund order at the payee terminal and requests the refund, or may be from another terminal, for example, the payee terminal acquires and is sent by the payer terminal. Refund request. The message list is a specific file or process on the terminal, which stores information about the refund. When the terminal processes the new refund request, it can first copy the refund request to the message list for use in subsequent steps.

[0034] Step S22: If it is detected that there is a historical to-be-sent request in the message list, send the detected historical to-be-sent request, and check whether there is a historical to-be-sent request in the message list after the preset time.

[0035] Wherein, the historical to-be-sent request is a historical refund request to be sent. The message list not only stores the current refund request, but also stores a historical pending request.
The message list can arrange all the refund requests in the chronological order of writing. If it is found that there is a historical pending request before the current refund request, the history pending request is sent preferentially. After the transmission is successful, the historical pending request can be deleted from the message list. After the transmission is successful, the historical pending transmission request can be changed to the sent status. After the feedback information is received, the historical pending transmission request can be deleted or changed. Etc., this embodiment does not particularly limit this.

[0036] In order to confirm whether the historical to-be-sent request is successfully sent, and to detect whether there are other historical pending requests, the message list may be detected again after the preset time. If there is still a historical pending request, the step is repeated if the detection is performed. If there is no history pending request, then step S23 is performed.

[0037] It should be added that when a history pending request is detected, since the current refund request cam-lot be immediately sent, the reason for the user not being able to immediately send the refund request can be notified through a message pop-up, a short message, or the like, so as to facilitate In some cases, the user manually processes the history pending request.

[0038] Step S23: If it is detected that there is no history pending request in the message list, send a refund request.

[0039] In the case that all history pending requests have been processed, the current refund request is sent. The address sent is usually the backend server of the management, such as the bank backend server. It should be noted that the sending address of different refund requests may be different. For example, a request for a refund from a different bank needs to be sent to the backend server of the corresponding bank. When sending a refund request or a history pending request, the information of the request usually contains the relevant information of the sending address, such as bank outlet information, refund channel information, etc. After the address is identified based on these information, the refund request or history pending request is sent to the corresponding address.

[0040] Based on the above description, it should be understood that the refund processing method of the present exemplary embodiment can be applied to the payer terminal 101 of the system shown in Figure 1, and can also be applied to the payee terminal 102. For example, in the scenario of online banking payment, the refund processing method may be executed by the payer terminal 101, and the refund request is sent to the payee terminal 102, and the payee terminal 102 checks and then initiates an application to the server 104; or the refund processing method is executed by the payer terminal 101, and the refund request is directly sent to the server 104;
in the scenario of payment by the POS machine, the refund processing method can be executed by the payee terminal 102 (i.e., the POS machine). A refund request is sent to the server 104, and the server 104 returns the money to the payer's account after the review request is passed. This embodiment is not particularly limited.

[0041] In the above method, after obtaining the refund request, copying it to the message list, and detecting whether there is a historical pending request in the message list, if yes, sending a historical pending request, if not, sending the Refund request. On the one hand, in the case that the historical refund request processing caused by network failure or abnormal information is unsuccessful, when a new refund request occurs, the historical refund request can be processed again to reduce the delay of the refund request processing. Situation, improve efficiency. On the other hand, when all the historical pending requests have been sent, the current refund request can be sent, so that the user can be reminded of the unsuccessful processing of the historical refund request, so that the user can promptly check the cause and deal with it accordingly. In another aspect, the historical pending request in this embodiment is not repeated attempts to send, but attempts to resend when a new refund request occurs, because the occurrence of a new refund request may indicate that the historical refund request is not processed. The reason for the success has been solved. At this time, the probability of attempting to resend is large. Compared with the method of repeatedly trying to send, this embodiment improves the probability of success of resending as much as possible when the system resources are occupied less. The utilization of system resources is high.

[0042] In an exemplary embodiment, the refund processing method may further include the following steps:

[0043] After sending the refund request, it is detected whether feedback information about the refund request is received.

[0044] If the feedback information is received, the refund request is deleted from the message list.

[0045] If the feedback information is not received within the preset time, the refund request in the message list is marked as a historical to-be-sent request.

[0046] Wherein issuing the refund request does not mean that the refund request is processed normally, so the feedback information can be received as a criterion for determining that the refund request is normally processed, wherein the feedback information may be that the server receives the refund request. The message receipt can also be the result notification of whether the server has passed the refund request, or it can be the payment information of the refund directly executed by the server. The preset time may be the same as the preset time in step S22, and the time required for normal transmission according to the refund request and the time setting required for the normal response of the server, if no feedback information is received within the preset time, the refund request is provided. The processing has an exception, and may need to send a refund request again, so it is marked as a historical pending request, and when a new next refund request is generated, the history pending request is sent first.

[0047] It should be added that if the feedback information is received outside the preset time, the original refund request that has been marked as the historical pending request in the message list may be deleted to complete the processing of the original refund request, or may be passed. The message pop-up window and the like request the user's manual intervention, so that the user can select the processing flow of ending the original refund request according to the feedback information, or perform other operations such as modifying the original refund request, resending the original refund request, and the like. No special restrictions.

[0048] Usually, the refund request contains some privacy information of the consumer, and may be stored in the message list in the form of a historical pending request in the terminal locality for a long time, in order to ensure the security of the information locally, in an exemplary implementation In the example, when copying a refund request to a message list, the refund request can be encrypted first, and the encrypted refund request can be copied to the message list. When the user logged in to the terminal needs to view the refund request in the message list, the identity of the user can be verified, and whether the refund request is decrypted according to the verification result is determined.

[0049] In an exemplary embodiment, the refund request may be sent by the payer terminal to the payee terminal first, and then the payee terminal performs the method of the embodiment to initiate a refund request to the server. Therefore, after obtaining a refund request from the payer terminal, a manual check can be performed to determine whether the refund request is correct. The payee terminal can include a display apparatus, such as a display screen, an external display, etc., to display a refund request. Based on this, the refund processing method may further include the following steps:

[0050] After copying the encrypted refund request into the message list, a refund request is presented.

[0051] If an externally input confirmation command is received, it is detected whether there is a historical to-be-sent request in the message list.

[0052] The detailed information of the refund request may be as shown in Figure 3, and it should be noted that before the refund request is presented, the necessary processing may be performed first, for example, the refund request is converted through a specific user interface. A form that is easy for users to view. By presenting the refund request to the payer terminal, after the user of the payer terminal confirms that the information is correct, the user can click the "confirm refund" in the figure or confirm the instruction by other means to execute whether the history of the check message list exists. The step of transmitting the request may then perform step S22 or S23 according to the detected result.

[0053] Further, in order to ensure information security during the sending of the refund request, in an exemplary embodiment, step S23 can be implemented by the following steps:

[0054] If it is detected that there is no history pending request in the message list, the encrypted refund request is sent.

[0055] Wherein, when transmitting the encrypted refund request, it should be ensured that the server receiving the refund request has the necessary decryption information, for example, by the key encryption already agreed with the server, or by obtaining the private key of the server in advance. The public key is used to asymmetrically encrypt the refund request by using the public key. This embodiment does not specifically limit this.

[0056] Figure 4 shows the complete flow of refund processing in an exemplary embodiment.
Referring to Figure 4, after the refund request is obtained, it is encrypted and copied into the message list, and can be presented to the display apparatus of the terminal.
If the user thinks that the refund request is problematic, he can modify the refund request and re-execute the above steps.
When he copies the modified refund request to the message list, he can override the original refund request. If the user confirms that there is no problem with the refund request, the step of detecting the historical pending request in the message list can be performed. If a history pending request is detected, the history pending request is sent. The processing method after the historical to-be-sent request is sent may be similar to the current refund request, and when the feedback information of the historical pending request is received, it is deleted from the message list, so it can be detected again after the preset time, if it is not received When the feedback information is sent to cause the above historical pending request to exist, or there are other historical pending requests, the detected historical pending request is sent again. You can preset the number of transmissions for each history to be sent. If the corresponding feedback information cannot be received after the preset number of transmissions is reached, the user can be notified by message pop-up, SMS, etc. The requested option to avoid normal processing of other refund requests due to an exception in a history pending request. If it is detected that there is no history pending request in the message list, indicating that all history pending requests have been processed normally (or manually skipped), then the step of sending a refund request is sent, and the encrypted refund request is sent. Then, according to whether the corresponding feedback information is received within the preset time, it is decided to delete or mark the refund request in the message list as a historical pending request, thereby ending the entire process. When a new refund request is generated, the above process may be performed for processing. If the previous refund request is not processed successfully, it has become a historical pending request, and is executed in the step of detecting the history pending request. Send another instruction to complete the processing.

[0057] In an exemplary embodiment, referring to Figure 5, the encryption of the refund request may be implemented by steps S51 to S53:

[0058] Step S51, converting the refund request into an intermediate code by a Huffman encoding rule.

[0059] Step S52, the intermediate code is filled with a preset number, so that the number of bits of the intermediate code after the preset number is filled is a multiple of n.

[0060] Step S53, converting the intermediate code filled with the preset number into an encrypted character string by using a 2" -bit encoding rule.

[0061] Wherein n is an integer greater than 1. Huffman coding is a variable word length coding that can uniformly encode various types of characters. The intermediate code of the output is a 0/1 digit sequence. The Huffman coded output digital sequence has a lower expected length. To further reduce the length of the sequence, the intermediate coding can be 2" -bit encoded, such as 4-bit coding, 8-bit coding, 16-bit coding or 32-bit coding. Taking 32-bit encoding as an example, the specific process is as follows: divide the 5-digit string into the intermediate code, and divide each 5-digit number into a digital unit in order. When the total number of intermediate codes is not a multiple of 5, pre-populate the preset. The number is such that the number of bits after padding is a multiple of 5, such as 0 or 1 at the forefront or the last of the intermediate code. Thus, a number of 5-bit digital units are obtained, which are converted into alphabetic characters according to the correspondence in Table 1 (note the case sensitivity), and constitute the final encrypted string, that is, the encrypted string is a sequence of alphabetic characters. When 16-bit encoding is performed, the intermediate encoding is pre-filled with a preset number such that the number of bits is a multiple of 4, a number of 4-bit digital units are divided, and converted into an encrypted character string according to the correspondence in Table 1.

[0062]
8-bit 32-bit 4-bit code 16-bit code character encoding encoding

[0063]

11011 a

[0064] Table 1

[0065] Table 1 only shows four encoding rules that do not exceed 32-bit encoding. When using 64-bit encoding or higher-order encoding, characters such as Greek letters, Roman letters, etc. can be added to achieve the required number of encoded characters. This embodiment does not particularly limit this.

[0066] Further, the refund request may include refund order information, refund amount information, and permission refund identifier; step S51 may include the following steps: refund order information, refund amount information, allowable refund identification, and encryption The version number constitutes a sequence of characters; the sequence of characters is converted into the intermediate code by a Huffman coding rule; wherein the encrypted version number has a correspondence with a Huffman coding rule, a rule for filling a preset number, and a 2" -bit coding rule.

[0067] For example: in a refund request, the refund order information is "poiid 00001", the refund amount information is "total fee 20000 refund fee 1000", and the refund identifier is allowed to "allow refund 1", the encoded version The number is "version 2.1"
and is merged into the original character sequence of the refund request. The character sequence is encoded by Huffman coding rules, and the intermediate code is obtained as:

11011111101010011000.
The above code is a total of 99 bits, and the front is padded with a 0, so that the total number of bits becomes a multiple of 5. The intermediate code after padding 0 is:

011011111101010011000.
According to the 32-bit encoding rule, every 5 digits of the digital unit is converted into a letter character, and the final encrypted string is: HJRTPzeXzAedBUCJadTX.

[0068] In the present exemplary embodiment, the Huffman coding may adopt different rules, for example, the information of the refund request may be encoded as a whole, or only the non-numeric characters may be encoded, and the numeric characters may be converted into Binary numbers; rules for populating preset numbers may also include various types, such as first-most padding in the intermediate encoding, last-party padding 1, front-most padding 0, last-party padding 0, etc.; 2" -bit encoding rules may include 4 bits Coding, 8-bit encoding, 16-bit encoding or 32-bit encoding rules. That is, each of the above three rules includes multiple specific schemes.
When encrypting the refund request, different specific schemes are adopted, and a plurality of encrypted versions can be formed, so Huffman can be encoded by the encrypted version number.
The combination of rules, rules for populating preset numbers, and specific schemes for 2" -bit encoding rules is identified. When the information security of a refund request is compromised, the encryption rules can be changed and recorded by encrypting the version number to improve the security of the refund processing.

[0069] In an exemplary embodiment, if the refund request is acquired by the payee terminal from the payer terminal, after the refund processing flow shown in Figure 3 is performed on the payee terminal, whether or not it is received The feedback information can send a message receipt similar to "Refund Accepted" to the payer terminal to inform the payer terminal about the processing result of the refund request.

[0070] An exemplary embodiment of the present disclosure further provides a refund processing apparatus that can be applied to a terminal that supports electronic payment.
Referring to Figure 6, the refund processing apparatus 600 can include: requesting a copy module 610, Obtaining a refund request, and copying the refund request into the message list; the list detection module 620 is configured to detect whether there is a historical to-be-sent request in the message list; the history sending module 630 is configured to: if there is a history to be sent in the message list Sending the detected history pending request, and detecting whether there is a historical pending request in the message list after the preset time; the current sending module 640 is configured to send if there is no historical pending request in the message list. Refund request.

[0071] In an exemplary embodiment, the current sending module may further include: a feedback detecting unit, configured to: after receiving the refund request, detect whether the feedback information about the refund request is received; request the deleting unit, if After receiving the feedback information, the refund request is deleted from the message list; the history marking unit is configured to mark the refund request in the message list as a historical pending request if the feedback information is not received within the preset time.

[0072] In an exemplary embodiment, the request replication module may also be configured to encrypt the refund request and copy the encrypted refund request into the message list.

[0073] In an exemplary embodiment, the refund processing apparatus may further include: a user confirmation module, configured to present a refund request, and receive a confirmation instruction regarding the refund request; the list detection module may further be configured to receive the An externally entered confirmation command detects whether there is a historical pending request in the message list.

[0074] In an exemplary embodiment, the request copy module may further include: a Huffman conversion unit configured to convert the refund request into an intermediate code by a Huffman encoding rule; and a preset filling unit for the middle Encoding fills the preset number so that the number of bits of the intermediate code after the preset number is filled is a multiple of n; the encryption coding unit is configured to convert the intermediate code after the preset number is filled into the encrypted string by the 2 -bit encoding rule; Where n is an integer greater than one.

[0075] In an exemplary embodiment, a refund request may include refund order information, refund amount information, and allowable refund identification; the Huffman conversion unit can also be used to compose character sequences from refund order information, refund amount information, allowable refund identification and encrypted version number, and to convert character sequences into intermediate codes through Huffman coding rules.
Among them, The encrypted version number has a correspondence with Huffman coding rules, rules for filling preset numbers, and 2n-bit coding rules.

[0076] In an exemplary embodiment, the current sending module may be further configured to send an encrypted refund request if there is no history pending request in the message list.

[0077] The specific details of each of the above modules/units have been described in detail in the embodiment of the method section, and thus will not be described again.

[0078] Exemplary embodiments of the present disclosure also provide an electronic equipment capable of implementing the above method.

[0079] Those skilled in the art will appreciate that various aspects of the present disclosure can be implemented as a system, method, or program product. Accordingly, various aspects of the present disclosure may be embodied in the form of a complete hardware implementation, a complete software implementation (including firmware, microcode, etc.), or a combination of hardware and software aspects, which may be collectively referred to herein.
"Circuit," "module,"
or "system."

[0080] An electronic equipment 700 in accordance with such an exemplary embodiment of the present disclosure is described below with reference to Figure 7. The electronic equipment 700 shown in Figure 7 is merely an example and should not impose any limitation on the function and scope of use of the embodiments of the present disclosure.

[0081] As shown in Figure 7, electronic equipment 700 is embodied in the form of a general purpose computing apparatus. The components of the electronic equipment 700 may include, but are not limited to, the at least one processing unit 710, the at least one storage unit 720, the bus 730 connecting the different system components (including the storage unit 720 and the processing unit 710), and the display unit 740.

[0082] Wherein the storage unit stores program code, the program code may be executed by the processing unit 710, such that the processing unit 710 performs the operations according to the present disclosure described in the "Exemplary Method" section of the present specification. The steps of an exemplary embodiment. For example, the processing unit 710 may perform steps S21 to S23 shown in Figure 2, and it may also perform steps S51 to S53 shown in Figure 5.

[0083] The storage unit 720 may include a readable medium in the form of a volatile storage unit, such as a random access storage unit (RAM) 721 and/or a cache storage unit 722, and it may further include a read only storage unit (ROM) 723..

[0084] The storage unit 720 can also include a program/utility 724 having a set (at least one) of the program modules 725, including but not limited to: an operating system, one or more applications, other program modules, and Program data, each of these examples or some combination may include an implementation of a network environment.

[0085] Bus 730 can represent one or more of several types of bus structures, including memory cell bus or memory cell controller, peripheral bus, graphics acceleration port, processing unit or local area bus using any bus structure in a variety of bus structures.

[0086] The electronic equipment 700 can also be in communication with one or more external apparatus 900 (e.g., a keyboard, pointing apparatus, Bluetooth apparatus, etc.), and can also be in communication with one or more apparatus that enable a user to interact with the electronic equipment 700, and / or communicate with any apparatus (e.g., router, modem, etc.) that enables the electronic equipment 700 to communicate with one or more other computing apparatus. This communication can take place via an input/output (I/O) interface 750. Also, electronic equipment 700 can 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) through network adapter 760. As shown in the figure, network adapter 760 communicates with other modules of electronic equipment 700 via bus 730. It should be understood that although not shown in the figures, other hardware and/or software modules may be utilized in conjunction with electronic equipment 700, including but not limited to: microcode, apparatus drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives. And data backup storage systems, etc.

[0087] Through the description of the above embodiments, those skilled in the art can easily understand that the example embodiments described herein may be implemented by software, or may be implemented by software in combination with necessary hardware.
Therefore, the technical solution according to an embodiment of the present disclosure may be embodied in the form of a software product that can be stored in a nonvolatile storage medium (which may be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on the network, including a number of instructions to enable a computing apparatus (which may be a personal computer, server, terminal apparatus, or network apparatus, etc.) to execute according to the present The method of the exemplary embodiments is disclosed.

[0088] Exemplary embodiments of the present disclosure also provide a computer readable storage medium having stored thereon a program product capable of implementing the above method of the present specification. In some possible embodiments, various aspects of the disclosure may also be implemented as a form of program product, including program code. When the program product is running on the terminal device, the program code is used to enable the terminal device to perform the steps described in the "exemplary method"
section of this specification in accordance with various exemplary embodiments of the present disclosure.

[0089] Referring to Figure 8, a program product 800 for implementing the above method, which may employ a portable compact disk read only memory (CD-ROM) and including program code, is described in accordance with an exemplary embodiment of the present disclosure. It can be run on a terminal apparatus such as a personal computer. However, the program product of the present disclosure is not limited thereto, and in this document, the readable storage medium may be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0090] The program product may take any combination of one or more readable mediums. 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, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples (non-exhaustive lists) of readable storage media include:
electrical connections with one or more wires, portable disks, hard disks, random access memory (RAM), read only memory (ROM), erasable Programmable read-only memory (EPROM
or flash memory), optical fiber, portable compact disk read only memory (CD-ROM), optical storage apparatus, magnetic storage apparatus, or any suitable combination of the foregoing.

[0091] The computer readable signal medium may include a data signal that is propagated in the baseband or as part of a carrier, carrying readable program code. Such propagated data signals can take a variety of forms including, but not limited to, electromagnetic signals, optical signals, or any suitable combination of the foregoing. The readable signal medium can also be any readable medium other than a readable storage medium that can transmit, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

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

[0093] Program code for performing the operations of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language, such as Java, C++, etc., including A conventional programming language - such as the "C" language or a similar programming language. The program code can execute entirely on the user computing apparatus, partially on the user apparatus, as a stand-alone software package, partially on the remote computing apparatus on the user computing apparatus, or entirely on the remote computing apparatus or server. Execute on. In the case of a remote computing apparatus, the remote computing apparatus can be connected to the user computing apparatus via any kind of network, including a local area network (LAN) or wide area network (WAN), or can be connected to an external computing apparatus (e.g., provided using an Internet service) Businesses are connected via the Internet).

[0094] Further, the above-described drawings are merely illustrative of the processes included in the method according to the exemplary embodiments of the present disclosure, and are not intended to be limiting. It is easy to understand that the processing shown in the above figures does not indicate or limit the chronological order of these processes. In addition, it is also easy to understand that these processes may be performed synchronously or asynchronously, for example, in a plurality of modules.

[0095] It should be noted that although several modules or units of equipment for action execution are mentioned in the detailed description above, such division is not mandatory. Indeed, in accordance with the exemplary embodiments of the present disclosure, the features and functions of the two or more modules or units described above may be embodied in one module or unit. Conversely, the features and functions of one of the modules or units described above may be further divided into multiple modules or units.

[0096] Those skilled in the art upon consideration of the specification and practice of the invention disclosed herein, other embodiments will readily occur to those embodiments disclosed.

The present application is intended to cover any variations, uses, or adaptations of the present disclosure, which are in accordance with the general principles of the disclosure and include common general knowledge or common technical means in the art that are not disclosed in the present disclosure. . The specification and examples are to be regarded as illustrative only,

[0097] It should be understood that the present disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from their scope. The scope of the disclosure is to be limited only by the appended claims.

Claims (10)

What is claimed is:

1. A refund processing method, comprising:
Obtain a refund request and copy the refund request to the message list;
If the history pending request is detected in the message list, the historical to-be-sent request is sent, and the historical to-be-sent request is detected in the message list again after the preset time;
If it is detected that there is no history pending request in the message list, the refund request is sent.

2. According to the method in Claim 1, it's characteristic of the method also including:
After sending the refund request, detecting whether feedback information about the refund request is received;
And if the feedback information is received, deleting the refund request from the message list;
If the feedback information is not received within the preset time, the refund request in the message list is marked as a historical to-be-sent request.

3. The method of Claim 1 wherein copying the refund request into a message list comprises:
The refund request is encrypted and the encrypted refund request is copied to the message list.

4. According to the method in Claim 3, it's characteristic of the method also including:
After copying the encrypted refund request into the message list, presenting the refund request;
If an external input confirmation command is received, it is detected whether there is a historical to-be-sent request in the message list.

5. The method of Claim 3 wherein encrypting the refund request comprises:
Converting the refund request to an intermediate code by a Huffman encoding rule;
Filling the intermediate code with a preset number such that the number of bits of the intermediate code after the preset number is filled is a multiple of n;
converting the intermediate code after filling the preset number into an encrypted character by a 2n -bit encoding rule string;
Where n is an integer greater than 1.

6. The method according to Claim 5, wherein the refund request comprises refund order information, refund amount information, and an allowable refund identifier;
Converting the refund request to an intermediate code by Huffman encoding rules includes:
Forming the refund order information, the refund amount information, the allowable refund identifier, and the encrypted version number into a sequence of characters;
Converting the sequence of characters to the intermediate encoding by the Huffman encoding rule;
The encrypted version number has a corresponding relationship with the Huffman coding rule, a rule for filling a preset number, and a 2n -bit coding rule.

7. The method according to Claim 3, wherein if it is detected that there is no history pending request in the message list, sending the refund request comprises:
If it is detected that there is no history pending request in the message list, the encrypted refund request is sent.

8. A refund processing apparatus for a terminal including an input apparatus, comprising:
Requesting a copy module for obtaining a refund request and copying the refund request to a message list;
A list detection module, configured to detect whether a history to be sent request exists in the message list;
A history sending module, configured to send the historical to-be-sent request if there is a historical to-be-sent request in the message list, and detect, after a preset time, whether a historical to-be-sent request exists in the message list;
The current sending module is configured to send the refund request if there is no history pending request in the message list.

9. An electronic equipment, comprising:
A processor; and A memory for storing executable instructions of the processor;
Wherein the processor is configured to perform the method of any one of Claims 1-7 via execution of the executable instructions.

10. A computer readable storage medium having stored thereon a computer program, wherein the computer program is executed by a processor to implement the method of any of Claims 1-7.