Business processing method, device, storage medium and computer program product

Abstract

The embodiment of the present invention provides a business processing method, device, storage medium and computer program product. After receiving a refund request, a synchronous thread is used to query the transaction order corresponding to the refund request, and the refund amount and user information are verified; if the verification is passed, a refund order is generated, and a refund processing notification message is sent to the terminal to trigger an asynchronous thread; an asynchronous thread is used to query the business order to be offset related to the transaction order, and an offset operation is performed on the business order to be offset according to the refund order, and an accounting process is called to perform an accounting operation on the offset operation; the refund status is modified to a completed status, and a refund completion notification message is sent to the terminal. The refund business process is divided into synchronous and asynchronous, and the verification and refund order creation operations are performed by the synchronous thread, and the refund offset operation and accounting operation are performed by the asynchronous thread, so as to avoid the refund business process using the synchronous process in full, which leads to a long time consumption, and quickly respond to the user's refund request, thereby improving the system stability and user experience.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of computer and Internet technology, and in particular, to a business processing method, device, storage medium, and computer program product. Background Art

[0002] With the continuous development of online consumption, credit payment is becoming more and more popular. Credit payment is a consumption method of consuming first and repaying later. Credit payment business mainly includes transaction processes such as consumption, refund, and repayment. In particular, when consumption supports installment, multiple installment orders will be generated, including principal, handling fees, daily interest, penalty interest, etc. After consumption, if the user is not satisfied with the purchased items or services, the user can apply for after-sales service for a refund. Refund is the reverse operation of consumption, and consumption needs to be offset.

[0003] At present, the general process of refund business is particularly complicated. After receiving the refund request from the user, the refund system needs to immediately execute a series of operation processes for the refund request until the refund is successful, and then return the refund result notification to the user.

[0004] In the prior art, each operation in the refund business process is processed synchronously, and the refund process is time-consuming. Especially in high concurrency situations, system response timeout or even system crash will occur, which will lead to refund failure and require users to re-initiate the refund. The system stability and user experience are poor. Summary of the invention

[0005] The embodiments of the present invention provide a business processing method, device, storage medium and computer program product for quickly responding to user refund requests, ensuring the success of refund services, and improving refund service system stability and user experience.

[0006] In a first aspect, an embodiment of the present invention provides a service processing method, including:

[0007] After receiving the refund request sent by the terminal, a synchronous thread is used to query the transaction order corresponding to the refund request, and the refund amount and user information in the refund request are verified;

[0008] If the verification is passed, a refund slip is generated through the synchronous thread, a notification message of refund processing is sent to the terminal, and an asynchronous thread is triggered;

[0009] The asynchronous thread is used to query the to-be-offset business orders related to the transaction order, the to-be-offset business orders are offset according to the refund order, and the reimbursement process is called to perform reimbursement operations on the offset operations;

[0010] The refund status is modified to a completed status through the asynchronous thread, and a notification message of refund completion is sent to the terminal.

[0011] In a second aspect, an embodiment of the present invention provides a service processing device, including:

[0012] A synchronous processing unit, configured to, after receiving a refund request sent by a terminal, query the transaction sheet corresponding to the refund request using a synchronous thread, and verify the refund amount and user information in the refund request; if the verification passes, generate a refund sheet through the synchronous thread, send a notification message in the refund processing to the terminal, and trigger an asynchronous thread;

[0013] The asynchronous processing unit is used to use the asynchronous thread to query the pending business order related to the transaction order, offset the pending business order according to the refund order, and call the reimbursement process to perform reimbursement operation on the reimbursement operation; modify the refund status to the completed status through the asynchronous thread, and send a notification message of refund completion to the terminal.

[0014] In a third aspect, an embodiment of the present invention provides an electronic device, including: at least one processor; and a memory;

[0015] The memory stores computer-executable instructions;

[0016] The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor performs the method according to the first aspect.

[0017] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions. When a processor executes the computer-executable instructions, the method of the first aspect is implemented.

[0018] In a fifth aspect, an embodiment of the present invention provides a computer program product, comprising computer instructions, which implement the method of the first aspect when executed by a processor.

[0019] The business processing method, device, storage medium and computer program product provided by the embodiment of the present invention use a synchronous thread to query the transaction order corresponding to the refund request after receiving the refund request sent by the terminal, and verify the refund amount and user information in the refund request; if the verification is passed, a refund order is generated through the synchronous thread, a notification message in the refund processing is sent to the terminal, and an asynchronous thread is triggered; an asynchronous thread is used to query the business order to be offset related to the transaction order, and an offset operation is performed on the business order to be offset according to the refund order, and the reimbursement process is called to perform an reimbursement operation on the offset operation; the refund status is modified to a completed status through an asynchronous thread, and a notification message of refund completion is sent to the terminal. This embodiment divides the refund business process into two parts, synchronous and asynchronous. The synchronous thread performs the verification and refund order creation operations, and the asynchronous thread performs the more complex and cumbersome offset operations and reimbursement operations, so as to avoid the refund business process using the synchronous process entirely, which leads to a long time consumption, and can quickly respond to the user's refund request. In addition, the stability of the refund business process is improved, the accuracy of user data is guaranteed, and the system stability and user experience are improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] 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 present disclosure.

[0021] Figure 1 A schematic diagram of an application scenario of a business processing method provided by an embodiment of the present invention;

[0022] Figure 2 A flowchart of a business processing method provided by an embodiment of the present invention;

[0023] Figure 3 A flowchart of a business processing method provided by another embodiment of the present invention;

[0024] Figure 4 A flowchart of a business processing method provided by another embodiment of the present invention;

[0025] Figure 5 A flowchart of a business processing method provided by another embodiment of the present invention;

[0026] Figure 6 A flowchart of a business processing method provided by another embodiment of the present invention;

[0027] Figure 7 A flowchart of a business processing method provided by another embodiment of the present invention;

[0028] Figure 8 A flowchart of a business processing method provided by another embodiment of the present invention;

[0029] Fig. 9 A flowchart of a business processing method provided by another embodiment of the present invention;

[0030] Fig.10 A structural diagram of a service processing device provided by an embodiment of the present invention;

[0031] Fig.11 A structural diagram of an electronic device provided by an embodiment of the present invention.

[0032] The above drawings show clear embodiments of the present disclosure, which will be described in more detail below. These drawings and text descriptions are not intended to limit the scope of the present disclosure in any way, but to illustrate the concepts of the present disclosure to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0033] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present disclosure. Instead, they are merely examples of devices and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

[0034] At present, the general process of refund business is very complicated. The general process of refund business is to receive the user's refund request, conduct voucher and identity verification, obtain consumption information, perform offset, and synchronously return the notification of refund result. In the credit payment scenario, especially the installment payment scenario, the refund process is more complicated. It is necessary to obtain the user transaction lock to ensure that only one business can be executed for the same user at the same time. It is necessary to query all business orders under the user for offset, record the offset flow, call the account system for accounting and update the user's credit limit, update the bill, update the loan order, and update the relevant business order. In particular, when the user has a scenario where the repayment is made before the refund, it is also necessary to call the payment system for payment operation.

[0035] If all these operations in the refund business process are processed synchronously, there will be the following shortcomings: the refund process takes a long time, especially in high concurrency situations, the system response timeout or even crashes, the system stability and user experience are poor; because the refund process needs to obtain transaction locks, there are a large number of update operations, and it needs to rely on the account system and payment system, the refund may fail. If the refund fails, the user needs to re-initiate the refund, and the user interactivity is poor.

[0036] In view of the above technical problems, the embodiment of the present invention divides the refund business process into two sub-processes, synchronous and asynchronous. The transaction order corresponding to the refund request is queried in the synchronous thread, and the refund amount and user information are verified. After the verification is passed, the user is responded to, and a notification message in the refund process is sent to the user, and the asynchronous thread is triggered. The more complex operations in the refund business process are performed through the asynchronous thread, such as write-off operations, reimbursement operations, etc., and the payment operation, update of the account system user quota, bills, loan orders, related business orders, etc. can also be performed. After the refund is finally completed, the refund status is modified to the completed status through the asynchronous thread, and a notification message of the refund completion is sent to the terminal. The synchronous thread can quickly respond to the user's refund request, avoiding the user having to wait for the notification of the final refund result. The asynchronous thread performs complex operations. In the case of system response timeout or even downtime, the asynchronous thread can be continued after the system is restored. The entire refund process will not be blocked, which can ensure the success of the refund, ensure the accuracy of user data, and improve system stability and user experience.

[0037] The service processing method provided by the embodiment of the present invention is applicable to Figure 1 In the application scenario described,

[0038] The service processing method provided by the embodiment of the present invention is applicable to Figure 1 The application scenario includes a terminal 101 and a server 102. The terminal can send a refund request to the server 102. After receiving the refund request, the server 102 uses a synchronous thread to query the transaction order corresponding to the refund request, and verifies the refund amount and user information in the refund request; if the verification passes, a refund order is generated through a synchronous thread, a notification message of refund processing is sent to the terminal 101, and an asynchronous thread is triggered; an asynchronous thread is used to query the business order to be offset related to the transaction order, and an offset operation is performed on the business order to be offset according to the refund order, and the reimbursement process is called to perform an reimbursement operation on the offset operation; the refund status is modified to a completed status through an asynchronous thread, and a notification message of refund completion is sent to the terminal 101. The terminal 101 may not be limited to a smart phone, a tablet computer, a personal computer, a wearable device, etc.; the server 102 may be a server or a server cluster, or a cloud server.

[0039] The following specific embodiments are used to describe in detail the technical solutions of the present invention and how the technical solutions of the present application solve the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present invention will be described below in conjunction with the accompanying drawings.

[0040] Figure 2A flowchart of a service processing method is provided for an embodiment of the present invention. This embodiment provides a service processing method, the execution subject of which is an electronic device such as a service end for service processing. The specific steps of the service processing method are as follows:

[0041] S201. After receiving a refund request sent by a terminal, a synchronous thread is used to query a transaction sheet corresponding to the refund request, and the refund amount and user information in the refund request are verified.

[0042] In this embodiment, after a user has completed a transaction, there may be a refund situation. In this case, the user can apply for a refund from the payee. The user can perform the refund operation on the terminal. After receiving the refund request sent by the terminal, the server used for refund business processing can use a synchronous thread to perform some relatively simple operations, including but not limited to querying the transaction order corresponding to the refund request, verifying the refund amount, and user information, etc.

[0043] Among them, the transaction order corresponding to the refund request can be queried based on the transaction order number, and the transaction order includes information such as the consumption amount; if the transaction order cannot be queried, a query transaction order failure can be sent to the terminal. The transaction refund amount is to compare the refund amount with the refundable amount of the transaction order. If the refund amount does not exceed the refundable amount, the subsequent process will continue to execute. If the refund amount exceeds the refundable amount, a refund amount verification failure will be sent to the terminal. If the transaction order has not been refunded, the refundable amount can be the consumption amount or the agreed amount. If the transaction order has been refunded, the refundable amount is the difference between the consumption amount and the refunded amount, or the difference between the agreed amount and the refunded amount. When verifying user information, user information verification includes but is not limited to login status verification, user account status verification, etc.

[0044] In an alternative embodiment, Figure 3 As shown, the step of using a synchronous thread to query the transaction sheet corresponding to the refund request in S201 and verifying the refund amount and user information in the refund request may specifically include:

[0045] S2011, verifying the user's login status;

[0046] If the user is logged in, S2012 is executed; if the user is not logged in, the login status verification fails and the business processing flow is terminated, that is, other subsequent business processing flows are not performed;

[0047] S2012. Check whether there is a transaction order corresponding to the refund request;

[0048] If the transaction order corresponding to the refund request is found, S2013 is executed; if the transaction order corresponding to the refund request is not found, the business processing flow is terminated, and a failure to query the transaction order is returned to the terminal;

[0049] S2013, verifying whether the refund amount in the refund request exceeds the refundable amount in the transaction order;

[0050] If the refund amount does not exceed the refundable amount, S2014 is executed; if the refund amount exceeds the refundable amount, the business processing flow is terminated and a refund amount verification failure is returned to the terminal;

[0051] S2014. Verify the user account status;

[0052] If the user account does not exist or is blocked (no permission), the user account status verification fails, and the account status failure can be returned to the terminal; otherwise, the user account status is normal and the verification passes.

[0053] By executing the verification operations of S2011-S2014 through the synchronous thread, the legitimacy of the refund request can be guaranteed, providing a basis for the security of the subsequent asynchronous thread, and the refund request of the user can be responded to quickly. If any verification fails, the business processing flow can be terminated.

[0054] S202: If the verification is passed, a refund slip is generated through the synchronous thread, a notification message of the refund process is sent to the terminal, and an asynchronous thread is triggered.

[0055] In this embodiment, the refund slip can be used as a voucher for the refund process. Since there is no refund slip after the refund request is received and verified, the refund slip is generated through the synchronization thread after the verification is passed. In addition, the refund slip status can be modified to refund processing, and a notification message of refund processing is sent to the terminal, and the asynchronous thread is triggered. At this time, the synchronous thread can end without waiting for the result of the asynchronous thread, and the user's refund request can be responded to quickly.

[0056] S203: Use the asynchronous thread to query the business orders to be offset related to the transaction order, perform an offset operation on the business orders to be offset according to the refund order, and call the reimbursement process to perform an reimbursement operation on the offset operation.

[0057] In this embodiment, the asynchronous thread can execute more complex operations in the refund business, including but not limited to reversal operations and reimbursement operations.

[0058] Specifically, the asynchronous thread can query the user's pending business orders based on the transaction order. The pending business orders are business orders generated during the transaction process, where the pending business orders can include business orders that have been issued and business orders that have not been issued. More specifically, the pending business orders can include at least one business order, such as a principal installment order, an installment fee order, a daily interest order, a penalty interest order, a carry-over order, etc. Since different types of business orders are stored in different business tables, the pending business orders can be queried through multi-threading technology to improve the query speed.

[0059] After obtaining the business order to be offset, the offset operation can be performed, where offset is an accounting concept, that is, offsetting the original account of the business order to be offset. Since the refund amount in the refund request may be equal to the amount of all the business orders to be offset, or may be less than the amount of all the business orders to be offset, or more than the amount of all the business orders to be offset, it is necessary to perform an offset operation on the business order to be offset according to the refund request. Furthermore, after the offset operation, the reimbursement operation needs to be completed on the user account before the refund of the user account can be realized.

[0060] S204: Modify the refund status to a completed status through the asynchronous thread, and send a refund completion notification message to the terminal.

[0061] In this embodiment, the asynchronous thread can finally modify the refund order status to a completed status, including but not limited to modifying the offset transaction status, accounting transaction status, refund order status, bill status, etc., and send a notification message of refund completion to the terminal, at which time the asynchronous thread can end.

[0062] By executing the more complex and tedious write-off and accounting operations in the refund business process through asynchronous threads, the problem of time-consuming refund business processes caused by the use of synchronous processes can be avoided. There is no need for the synchronous process to wait for the final refund result. In the event of a system response timeout or even crash, the asynchronous thread can continue after the system is restored. The entire refund process will not be blocked, ensuring the success of the refund and the accuracy of the user data.

[0063] The business processing method provided in this embodiment uses a synchronous thread to query the transaction order corresponding to the refund request after receiving the refund request sent by the terminal, and verifies the refund amount and user information in the refund request; if the verification is passed, a refund order is generated through the synchronous thread, a notification message of the refund processing is sent to the terminal, and an asynchronous thread is triggered; an asynchronous thread is used to query the business order to be offset related to the transaction order, and an offset operation is performed on the business order to be offset according to the refund order, and the reimbursement process is called to perform an reimbursement operation on the offset operation; the refund status is modified to a completed status through an asynchronous thread, and a notification message of refund completion is sent to the terminal. This embodiment divides the refund business process into two parts, synchronous and asynchronous. The synchronous thread performs verification and creates refund order operations, and the asynchronous thread performs more complex and cumbersome offset operations and reimbursement operations, so as to avoid the refund business process using the synchronous process, which is time-consuming, and can quickly respond to user refund requests. In addition, the stability of the refund business process is improved, the accuracy of user data is guaranteed, and the system stability and user experience are improved.

[0064] Based on any of the above embodiments, there are multiple business orders to be written off; the operation of writing off the business orders to be written off according to the refund orders in S203 of the above embodiments includes:

[0065] According to the refund amount and the preset business priority of the business order to be written off, the business order to be written off is written off in sequence.

[0066] In this embodiment, there may be multiple business orders to be offset, for example, they may include at least two of the following business orders: principal installment order, installment fee order, daily interest order, penalty interest order, carry-over order, etc. Since the refund amount in the refund request may be less than the amount of all business orders to be offset, that is, only some of the multiple business orders to be offset may be able to be offset, the business priority of various business orders can be pre-set in this embodiment, which is equivalent to the priority of the offset operation, and then the offset operation is performed according to the refund amount and the preset business priority of each business order to be offset. For example, the business orders to be offset can be sorted in order from high to low according to the preset business priority, and then offset in sequence according to the sorting.

[0067] Optionally, based on the above embodiment, the offsetting operation is performed on each business order to be offset in sequence according to the refund amount and the preset business priority of the business order to be offset, including:

[0068] According to the preset business priority from high to low, each business order to be written off is traversed in turn to perform the writing-off operation until the accumulated writing-off amount of the business orders to be written off that have been written off reaches the refund amount.

[0069] In this embodiment, since the refund amount in the refund request may be less than the amount of all the business orders to be offset, that is, only some of the multiple business orders to be offset may be able to be offset. When traversing the business orders to be offset in order from high to low according to the preset business priority to perform the offset operation, when traversing to a certain business order to be offset, if the refund amount has been used up, that is, the cumulative offset amount of the business orders that have been offset reaches the refund amount, the offset operation is completed.

[0070] For example, the preset business priorities are from high to low, the amount of business order 1 to be written off is 10 yuan, the amount of business order 2 to be written off is 20 yuan, and the amount of business order 3 to be written off is 30 yuan. If the refund amount is 30 yuan, 10 yuan will be written off for business order 1 to be written off first, and then 20 yuan will be written off for business order 2 to be written off. At this time, the cumulative write-off amount of the business orders that have been written off is 30 yuan, which has reached the refund amount. Business order 3 to be written off cannot be written off any further, and the write-off operation can be ended at this time; if the refund amount is 40 yuan, 10 yuan can be written off for business order 3 to be written off again. At this time, the cumulative write-off amount of the business orders that have been written off is 30 yuan, which has reached the refund amount. The cumulative write-off amount of the business orders to be written off is 40 yuan, which reaches the refund amount; in addition, if the refund amount is equal to the amount of all business orders to be written off, all business orders to be written off can be written off successfully. For example, in the above example, if the refund amount is 60 yuan, all business orders to be written off can be written off successfully; in this example, there is usually no situation where the refund amount is greater than the amount of all business orders to be written off, because in the refund amount verification process in the aforementioned synchronous thread, if the refund amount is greater than the amount of all business orders to be written off (that is, the refundable amount in the transaction order), it will not enter the asynchronous thread.

[0071] In a possible embodiment, for the business orders to be written off, the user may have made repayments before the refund. The user may query the business orders that have been repaid among the business orders to be written off, and then perform the payment operation. The specific process is as follows:

[0072] If there is a business order that has been repaid among the business orders to be offset, the asynchronous thread is used to call the payment process to perform the payment operation.

[0073] In this embodiment, if it is determined that there are business orders for which repayment has been made among the business orders to be offset, the business orders for which repayment has been made among the business orders to be offset can be found, and then an asynchronous thread can be used to call the payment process to perform the payment operation, and the amount repaid by the user can be returned to the user first, and then subsequent reimbursement operations can be performed.

[0074] Specifically, Figure 4 As shown, the asynchronous thread is used to call the payment process to perform the payment operation, including:

[0075] S301, using the asynchronous thread, creating a payment application form according to the repayment amount of the repaid business form;

[0076] S302: Freeze the overpaid amount of the account according to the payment application form, call the payment side device to make the payment, and unfreeze the overpaid amount of the account after the payment is successful.

[0077] In this embodiment, the repayment amount of the repaid business order can be determined, and then a payment application form can be created based on the repayment amount, so that payment can be made according to the reply application form in the payment operation. The payment application form may include but is not limited to the repayment amount and the refund order number, etc., wherein the refund order number is used to identify that the payment application form is a payment application form generated in the current refund process.

[0078] When performing payment on behalf of others, you can query the payment application form based on the refund order number. After querying the payment application form, if the status of the payment application form is pending, you can freeze the account overpayment based on the payment application form. The overpayment refers to the funds overpaid by the customer when repaying or the funds deposited in the account. After freezing the overpayment, you can call the payment side device to perform payment on behalf of others. After the payment is completed, you can unfreeze the account overpayment.

[0079] More specifically, in order to ensure that S301-S302 successfully complete the payment on behalf of others, the status of the payment application form and the status of the overpaid amount in the account may be monitored. Figure 5 As shown, the process of executing S302 may include the following steps:

[0080] S311. Query the payment application form according to the refund order number, and filter out the payment application forms that are in a failed state and have been replaced;

[0081] Among them, if the payment system is abnormal or the available balance of the overpayment account is insufficient during the payment operation, the payment operation will fail. Since the payment operation calls the payment system, the payment application number needs to be sent. After failure, the application number cannot be used again. Therefore, the status of the payment application form can be changed to failure, and a new payment application form can be created to replace the original payment application form; and if the payment application form with a failed status and replaced is queried, it means that the payment application form has been replaced by a new payment application form. Therefore, when querying the payment application form, the payment application form with a failed status and replaced can be filtered out.

[0082] S312: for the payment application form that has not been filtered out, determine the status of the payment application form;

[0083] If the status of the payment application form is successful or empty, then the process returns success and ends, ensuring idempotence; if the status of the payment application form is failed, then S313 is executed; if the status of the payment application form is pending, then S314 is executed; if the status of the payment application form is unfreezing failure, then S316 is executed;

[0084] S313: Create a new payment application form to replace the failed payment application form;

[0085] After executing S313, continue to execute S314 based on the new payment application form;

[0086] S314, call account overpayment freeze;

[0087] If the freezing of the overpaid amount of the account fails, the process returns failure and ends; otherwise, execute S315;

[0088] S315, calling the payment side device to make payment on behalf of the user;

[0089] If the payment fails, the status of the payment application form is updated to failure, and failure is returned, and the process ends; otherwise, the payment succeeds and execution is performed at 316;

[0090] S316, calling the account overpayment unfreezing operation;

[0091] If the account overpayment fails to be unfrozen, the payment application form status will be updated to unfreeze failure, otherwise the payment application form status will be updated to success.

[0092] Based on any of the above embodiments, Figure 6 As shown, the calling reimbursement process described in S203 of the above embodiment performs a reimbursement operation on the write-off operation, specifically including:

[0093] S401, querying the accounting status of the refund request;

[0094] S402: If the accounting flow state is in the state of waiting for reimbursement, relevant amounts are summarized according to the accounting flow, and the account system is called to perform reimbursement operations.

[0095] In this embodiment, after the cancellation operation is completed, you can try to create an accounting flow to record the information in the accounting process as a voucher for the accounting operation, and then you can perform the accounting operation based on the accounting flow. When the accounting flow status is in the pending accounting status, the receivable amount, actual amount received, user amount and other related amounts are summarized based on the accounting flow, and the account is called to perform the accounting operation.

[0096] Specifically, in order to ensure that S401-S402 successfully completes the accounting, the status can be monitored, specifically, Figure 7 As shown, the reimbursement operation may include the following processes:

[0097] S411. Query the accounting records according to the refund order number, and filter out the accounting records that are in a failed state and have been replaced;

[0098] In this embodiment, if the accounting operation fails, the accounting flow may contain errors. The status of the accounting flow can be changed to failure, and a new accounting flow is created to replace the original accounting flow. Therefore, when querying the accounting flow, the accounting flow with a failed status and replaced can be filtered out.

[0099] S412, for the accounting records that have not been filtered out, determine the status of the accounting records;

[0100] If the status of the accounting flow is successful, success is returned and the process ends to ensure idempotence; if the status of the accounting flow is failed, S413 is executed; if the status of the accounting flow is pending, S414 is executed;

[0101] S413, create a new accounting flow to replace the failed accounting flow;

[0102] After executing S313, continue to execute S414 based on the new accounting flow;

[0103] S414. Summarize the relevant amounts according to the accounting records and call the account system to perform the accounting operation;

[0104] If the reimbursement is successful, it returns "reimbursement success", otherwise it returns "reimbursement failure" and the process ends.

[0105] In addition, based on the above embodiment, a reversal flow can be created after the reversal operation is completed to record information including but not limited to the refund order number, reversal amount, reversal time, etc. as a voucher for the reversal operation.

[0106] Based on any of the above embodiments, the step of modifying the refund status to a completed status through the asynchronous thread in S204 may specifically include:

[0107] The accounting flow status, refund order status and bill status are modified to a completed status through the asynchronous thread; in addition, the reversal flow status can also be modified to a completed status.

[0108] Based on any of the above embodiments, if the reversal operation fails during the reversal process, the reversal operation is performed again at a scheduled time; if the reimbursement operation fails during the reimbursement process, the reimbursement operation is performed again at a scheduled time; in addition, if the payment operation fails during the payment process, the payment operation is performed again at a scheduled time.

[0109] Based on any of the above embodiments, Figure 8 As shown, the step of using the asynchronous thread to query the business orders to be offset related to the transaction order in S203 may specifically include:

[0110] S501, try to obtain a user transaction lock;

[0111] S502: After successfully acquiring the user transaction lock, use the asynchronous thread to query the business orders to be offset related to the transaction order.

[0112] In this embodiment, in order to ensure that only one business can be executed for the same user at the same time and to ensure the correctness of the user's business data in a distributed scenario, an attempt is made to obtain the user transaction lock when the asynchronous thread is triggered. If the user transaction lock is successfully obtained, the subsequent query of the user's pending cancellation business order can be continued, and other businesses of the user can no longer obtain the user transaction lock; if the user transaction lock fails to be obtained, the user transaction lock can be re-attempted at a fixed time. Further, after sending a notification message of refund completion to the terminal, the user transaction lock can be released, and only then can other businesses obtain the user transaction lock and then execute the business process of obtaining the user transaction lock.

[0113] Based on any of the above embodiments, this embodiment provides an asynchronous process of a business processing method, such as Fig. 9 As shown, the specific steps are as follows:

[0114] S601, try to obtain a user transaction lock;

[0115] If the user transaction lock is successfully obtained, S602 is executed; if the user transaction lock is failed, an attempt to obtain the user transaction lock may be made again at a fixed time;

[0116] S602, using the asynchronous thread to query the user's pending business orders;

[0117] S603, performing an offset operation on each of the business orders to be offset in sequence according to the refund amount and the preset business priority of the business order to be offset;

[0118] Wherein, in the order of preset business priorities from high to low, each to-be-offset business order is traversed in turn to perform an offset operation until the accumulated offset amount of the to-be-offset business orders that have undergone the offset operation reaches the refund amount;

[0119] S604, try to create a write-off flow, a bookkeeping flow, and update the business order; if there is a business order that has been repaid among the business orders to be written off, create a payment application form;

[0120] If the attempt to create a write-off flow or bookkeeping flow is successful or the unique key conflicts, S605 is executed; otherwise, a timed retry is performed; when creating a write-off flow or bookkeeping flow, the refund order number is used as the unique key for creation, that is, only one write-off flow or bookkeeping flow can exist for the same refund order number at the same time. If a unique key conflict is found during creation, it means that there are other write-off flow or bookkeeping flow, that is, the write-off flow or bookkeeping flow has been created, and S605 can be continued to be executed;

[0121] S605, performing accounting operations based on the created accounting flow;

[0122] If the reimbursement is successful, S606 is executed; otherwise, the reimbursement operation is re-executed at a fixed time;

[0123] S606, performing payment operation based on the payment application form;

[0124] If the payment is successful, execute S607; otherwise, re-execute the payment operation at a fixed time;

[0125] S607, updating the reversal transaction status, accounting transaction status, refund order status, and bill status to a completed status; and sending a refund completion notification message to the terminal;

[0126] S608: Release the user transaction lock.

[0127] The principle and technical effects of the asynchronous process of this embodiment can be referred to the above embodiments, and will not be repeated here.

[0128] Fig.10 The business processing device provided in this embodiment can execute the processing flow provided in the method embodiment, such as Fig.10 As shown, the service processing device 700 includes a synchronous processing unit 701 and an asynchronous processing unit 702 .

[0129] The synchronization processing unit 701 is used to query the transaction order corresponding to the refund request by using a synchronization thread after receiving the refund request sent by the terminal, and verify the refund amount and user information in the refund request; if the verification passes, generate a refund order by using the synchronization thread, send a notification message of the refund processing to the terminal, and trigger the asynchronous thread;

[0130] The asynchronous processing unit 702 is used to use the asynchronous thread to query the pending business order related to the transaction order, offset the pending business order according to the refund order, and call the reimbursement process to perform reimbursement operations on the reimbursement operation; modify the refund status to the completed status through the asynchronous thread, and send a notification message of the refund completion to the terminal.

[0131] Based on any of the above embodiments, when the synchronization processing unit 701 uses a synchronization thread to query the transaction order corresponding to the refund request and verifies the refund amount and user information in the refund request, it is used to:

[0132] Using the synchronization thread, verifying the user's login status;

[0133] If the user is logged in, check whether there is a transaction order corresponding to the refund request;

[0134] If the transaction order corresponding to the refund request is found, verify whether the refund amount in the refund request exceeds the refundable amount in the transaction order;

[0135] If it does not exceed, the user account status is verified; if the user account status is normal, the verification passes.

[0136] Based on any of the above embodiments, there are multiple business orders to be offset; when the asynchronous processing unit 702 performs an offset operation on the business order to be offset according to the refund order, it is used to:

[0137] According to the refund amount and the preset business priority of the business order to be written off, the business order to be written off is written off in sequence.

[0138] Based on any of the above embodiments, when the asynchronous processing unit 702 performs the offset operation on each business order to be offset in sequence according to the refund amount and the preset business priority of the business order to be offset, it is used to:

[0139] According to the preset business priority from high to low, each business order to be written off is traversed in turn to perform the writing-off operation until the accumulated writing-off amount of the business orders to be written off that have been written off reaches the refund amount.

[0140] Based on any of the above embodiments, the asynchronous processing unit 702 is further configured to:

[0141] If there is a business order that has been repaid among the business orders to be offset, the asynchronous thread is used to call the payment process to perform the payment operation.

[0142] Based on any of the above embodiments, when the asynchronous processing unit 702 uses the asynchronous thread to call the payment process to perform the payment operation, it is used to:

[0143] Using the asynchronous thread, creating a payment application form according to the repayment amount of the repaid business form;

[0144] The overpaid amount of the account is frozen according to the payment application form, and the payment side device is called to make the payment. After the payment is successful, the overpaid amount of the account is unfrozen.

[0145] Based on any of the above embodiments, when the asynchronous processing unit 702 calls the reimbursement process to perform a reimbursement operation on the write-off operation, it is used to:

[0146] Query the accounting status of the refund request;

[0147] If the accounting flow status is pending reimbursement, the relevant amounts are summarized according to the accounting flow, and the account system is called to perform the reimbursement operation.

[0148] Based on any of the above embodiments, when the asynchronous processing unit 702 modifies the refund status to the completed status through the asynchronous thread, it is used to:

[0149] The accounting flow status, refund order status and bill status are modified to a completed status through the asynchronous thread.

[0150] Based on any of the above embodiments, the asynchronous processing unit 702 is further configured to:

[0151] If the write-off operation fails, re-run the write-off operation at a scheduled time; and / or

[0152] If the reimbursement operation fails, the reimbursement operation will be performed again at a scheduled time.

[0153] Based on any of the above embodiments, when the asynchronous processing unit 702 uses the asynchronous thread to query the to-be-reversed business order related to the transaction order, it is used to:

[0154] Attempt to obtain a user transaction lock; after successfully obtaining the user transaction lock, use the asynchronous thread to query the to-be-reversed business orders related to the transaction order;

[0155] After sending a refund completion notification message to the terminal, the asynchronous processing unit 702 is further used to:

[0156] Release the user transaction lock.

[0157] The service processing device provided in the embodiment of the present invention can be specifically used to perform the above Figure 2-9 The specific functions of the provided method embodiment will not be repeated here.

[0158] The business processing device provided by the embodiment of the present invention uses a synchronous thread to query the transaction order corresponding to the refund request after receiving the refund request sent by the terminal, and verifies the refund amount and user information in the refund request; if the verification is passed, a refund order is generated through the synchronous thread, a notification message in the refund processing is sent to the terminal, and an asynchronous thread is triggered; an asynchronous thread is used to query the business order to be offset related to the transaction order, and an offset operation is performed on the business order to be offset according to the refund order, and the reimbursement process is called to perform an reimbursement operation on the offset operation; the refund status is modified to a completed status through an asynchronous thread, and a notification message of refund completion is sent to the terminal. This embodiment divides the refund business process into two parts, synchronous and asynchronous. The synchronous thread performs verification and refund order creation operations, and the asynchronous thread performs more complex and cumbersome offset operations and reimbursement operations, so as to avoid the refund business process using the synchronous process entirely, which leads to a long time consumption, and can quickly respond to the user's refund request. In addition, the stability of the refund business process is improved, the accuracy of user data is guaranteed, and the system stability and user experience are improved.

[0159] Fig.11 The electronic device provided by the embodiment of the present invention can execute the processing flow provided by the service processing method embodiment, such as Fig.11 As shown, the electronic device 80 includes a memory 81, a processor 82, a computer program and a communication interface 83; wherein the computer program is stored in the memory 81 and is configured so that the processor 82 executes the business processing method described in the above embodiment.

[0160] Fig.11 The electronic device of the illustrated embodiment can be used to execute the technical solution of the above-mentioned business processing method embodiment, and its implementation principle and technical effect are similar, which will not be repeated here.

[0161] In addition, this embodiment also provides a non-transitory computer-readable storage medium, on which a computer program is stored, and the computer program is executed by a processor to implement the service processing method described in the above embodiment. The non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0162] In addition, this embodiment further provides a computer program product, including computer instructions, which implement the service processing method described in the above embodiment when executed by a processor.

[0163] In the several embodiments provided in the embodiments of the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0164] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0165] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0166] The above-mentioned integrated unit implemented in the form of a software functional unit can be stored in a computer-readable storage medium. The above-mentioned software functional unit is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to perform some steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program codes.

[0167] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example for illustration. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. The specific working process of the device described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0168] The above embodiments are only used to illustrate the technical solutions of the embodiments of the present invention, rather than to limit them. Although the embodiments of the present invention are described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some or all of the technical features therein by equivalents. However, these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present invention.

[0169] Those skilled in the art will readily appreciate other embodiments of the present disclosure after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or customary techniques in the art that are not disclosed in the present disclosure. The description and examples are to be regarded as exemplary only, and the true scope and spirit of the present disclosure are indicated by the following claims.

[0170] It should be understood that the present disclosure is not limited to the exact structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A business processing method, characterized in that: include: After receiving the refund request sent by the terminal, a synchronous thread is used to query the transaction order corresponding to the refund request, and the refund amount and user information in the refund request are verified; If the verification is passed, a refund slip is generated through the synchronous thread, a notification message of refund processing is sent to the terminal, and an asynchronous thread is triggered; Attempt to obtain a user transaction lock; after successfully obtaining the user transaction lock, use the asynchronous thread to query the pending cancellation business order related to the transaction order, cancel the pending cancellation business order according to the refund order, and call the reimbursement process to perform a reimbursement operation on the cancellation operation; Modify the refund status to a completed status through the asynchronous thread, and send a refund completion notification message to the terminal; There are multiple business orders to be offset, and the offsetting operation on the business orders to be offset according to the refund order includes: According to the refund amount and the preset business priority of the business order to be written off, the business order to be written off is written off in sequence; If there is a repaid business order among the business orders to be offset, the asynchronous thread is used to create a payment application form according to the repayment amount of the repaid business order; The overpaid amount of the account is frozen according to the payment application form, and the payment side device is called to make the payment. After the payment is successful, the overpaid amount of the account is unfrozen.

2. The method according to claim 1, characterized in that The adopting of a synchronous thread to query the transaction sheet corresponding to the refund request, and verifying the refund amount and user information in the refund request, includes: Using the synchronization thread, verifying the user's login status; If the user is logged in, check whether there is a transaction order corresponding to the refund request; If the transaction order corresponding to the refund request is found, verify whether the refund amount in the refund request exceeds the refundable amount in the transaction order; If it does not exceed, the user account status is verified; if the user account status is normal, the verification passes.

3. The method according to claim 1, characterized in that The performing the offset operation on each of the to-be-offset business orders in sequence according to the refund amount and the preset business priority of the to-be-offset business order includes: According to the preset business priority from high to low, each business order to be written off is traversed in turn to perform the writing-off operation until the accumulated writing-off amount of the business orders to be written off that have been written off reaches the refund amount.

4. The method according to claim 1, characterized in that: The calling of the reimbursement process to perform a reimbursement operation on the write-off operation includes: Query the accounting status of the refund request; If the accounting flow status is pending reimbursement, the relevant amounts are summarized according to the accounting flow, and the account system is called to perform the reimbursement operation.

5. The method according to claim 1, characterized in that The step of modifying the refund status to a completed status through the asynchronous thread includes: The accounting flow status, refund order status and bill status are modified to a completed status through the asynchronous thread.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: If the write-off operation fails, re-run the write-off operation at a scheduled time; and / or If the reimbursement operation fails, the reimbursement operation will be performed again at a scheduled time.

7. The method according to any one of claims 1 to 5, characterized in that: After sending the notification message of refund completion to the terminal, the method further includes: Release the user transaction lock.

8. A service processing device, characterized in that: include: A synchronization processing unit, configured to, after receiving a refund request sent by a terminal, query the transaction sheet corresponding to the refund request using a synchronization thread, and verify the refund amount and user information in the refund request; If the verification is passed, a refund slip is generated through the synchronous thread, a notification message of refund processing is sent to the terminal, and an asynchronous thread is triggered; an asynchronous processing unit, configured to use the asynchronous thread to query the to-be-reversed business order related to the transaction order, perform a reversal operation on the to-be-reversed business order according to the refund order, and call a reimbursement process to perform a reimbursement operation on the reversal operation; modify the refund status to a completed status through the asynchronous thread, and send a notification message of refund completion to the terminal; There are multiple business orders to be offset. When the asynchronous processing unit performs an offset operation on the business orders to be offset according to the refund order, it is used to: According to the refund amount and the preset business priority of the business order to be written off, the business order to be written off is written off in sequence; The asynchronous processing unit is further used to: if there is a repaid business order among the business orders to be offset, use the asynchronous thread to create a payment application form according to the repayment amount of the repaid business order; Freeze the overpaid amount of the account according to the payment application form, call the payment side device to make the payment, and unfreeze the overpaid amount of the account after the payment is successful; When the asynchronous thread is used to query the business orders to be offset related to the transaction order, the asynchronous processing unit is used to: try to obtain the user transaction lock; after successfully obtaining the user transaction lock, use the asynchronous thread to query the user's business orders to be offset.

9. An electronic device, characterized in that: include: at least one processor; and memory; The memory stores computer-executable instructions; The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor performs the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and when the processor executes the computer-executable instructions, the method according to any one of claims 1 to 7 is implemented.

11. A computer program product comprising computer instructions, characterized in that: When the computer instructions are executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images