Transaction management method and device, equipment and medium

Abstract

The invention relates to the field of financial science and technology, and discloses a transaction management method and device, equipment and a medium, and the method comprises the steps: obtaining a transaction order generation request; analyzing the transaction order generation request to generate user account information and transaction content information representing a transaction type; when the transaction type is a refund transaction, generating a repeated transaction query request; generating first query information corresponding to the service end and second query information corresponding to the fund management end based on the repeated query request; determining whether the transaction request is a repeated refund request according to the first query information and the second query information; if the transaction request is not a repeated refund request, the refund transaction order is sent to the fund management end to execute a corresponding refund behavior, and whether the refund is returned to the user is determined by querying and retrieving the transaction records of the business end and the fund management end, so that the refund transaction is prevented from being repeated, and the fund management safety of the fund management end is improved.

Description

Technical Field

[0001] The present application relates to the field of financial technology, and in particular to a transaction management method, device, equipment and medium. Background Art

[0002] Fund prevention and control is an important task of insurance companies' financial management. If the fund prevention is not done well, it will affect the professional image of the insurance company and affect the customers' reliance on the insurance company. Once the insurance company suffers a fund loss, the company needs to invest a large amount of cost to deal with the fund recovery.

[0003] The fund management end generally fully trusts the payment and collection requests of the business end, without doing any control over the funds from the business rule logic. The fund end is likely to only do fund transaction control at the transaction order level, but ignore the fund control at the order detail level (business document level). This makes it easy for the same business document to be traded repeatedly, especially for refunds, or for the same document to be used in multiple places, resulting in "double spending" of the same funds, which reduces the security of centralized payment and collection of funds under the order transaction model, increases the company's fund losses, and poses a risk of income and expenditure. Summary of the invention

[0004] The embodiments of the present application provide a transaction management method, apparatus, device and medium, which aim to avoid repeated refund transactions, improve the fund management security of the fund management end, and avoid income and expenditure risks.

[0005] In a first aspect, an embodiment of the present application provides a transaction management method, the method comprising:

[0006] Obtaining a transaction order generation request from the business end, where the transaction order generation request is generated based on the transaction request input by the user to the business end;

[0007] Parsing a transaction order generation request to generate transaction content information and corresponding user account information, where the transaction content information is at least used to characterize a transaction type corresponding to the transaction request;

[0008] When the transaction type is a refund transaction, a repeated transaction query request is generated that is mapped with the transaction content information and the user account information;

[0009] generating first query information corresponding to the business end based on the repeated query request, the first query information including a record corresponding to the transaction content information in the transaction record of the business end;

[0010] Sending a repeated query request to the fund management end so that the fund management end generates second query information, the second query information including a record corresponding to the transaction content information in the transaction record of the fund management end;

[0011] Obtaining the second query information fed back by the fund management end, and determining whether the transaction request is a repeated refund request according to the first query information and the second query information;

[0012] If the transaction request is not a duplicate refund request, a refund transaction order is generated according to the transaction request, and the refund transaction order is sent to the fund management end so that the fund management end executes the corresponding refund behavior.

[0013] In some implementations, generating a repeated transaction query request that is mapped with transaction content information and user account information includes:

[0014] Determine the target amount corresponding to the transaction request according to the transaction content information, where the target amount is the amount requested to be returned by the transaction request;

[0015] Retrieving a first transaction history record corresponding to the user account information, and querying a target payment record for paying a target amount in the first transaction history record;

[0016] Generates a duplicate transaction query request based on the target payment record.

[0017] In some implementations, generating first query information corresponding to the service end based on the repeated query request includes:

[0018] Retrieve the second transaction history record from the business end;

[0019] Determine the refund request characteristics corresponding to the target payment record;

[0020] A match is performed in the second transaction history record according to the refund request feature, and the matching result is used as the first query information.

[0021] In some implementations, determining whether the transaction request is a repeated refund request according to the first query information and the second query information includes:

[0022] Parsing the first query information to obtain a corresponding matching result to determine whether the transaction record of the business end includes a refund history record corresponding to the target payment record;

[0023] Parsing the second query information to obtain a corresponding matching result to determine whether the transaction record of the fund management end includes a refund history record corresponding to the target payment record;

[0024] When neither the transaction record at the business end nor the transaction record at the funds management end includes a refund history record corresponding to the target payment record, the transaction request is determined to be a non-duplicate refund request; and / or, when at least one of the transaction record at the business end and the transaction record at the funds management end includes a refund history record corresponding to the target payment record, the transaction request is determined to be a non-duplicate refund request.

[0025] In some implementations, the refund request feature includes a refund amount and a refund time, and matching is performed in the second transaction history record according to the refund request feature, including:

[0026] Filtering out the payment transaction history corresponding to the user account information in the second transaction history;

[0027] Query the first matching transaction record whose transaction amount matches the refund amount from the collection transaction history;

[0028] Querying the second matching transaction record whose refund time is at the target transaction time from the collection transaction history, and the target transaction time is associated with the payment time of the target payment record;

[0029] A refund history record is determined based on the first matching transaction record and the second matching transaction record.

[0030] In some embodiments, the method further comprises:

[0031] Sending an account lock instruction to the fund management terminal according to the user account information, so that the fund management terminal stops receiving transaction orders corresponding to the user account information;

[0032] After determining that the transaction request is not a duplicate refund request, an account unlock instruction is sent to the fund management end to instruct the fund management end to resume receiving transaction orders corresponding to the user account information.

[0033] In some embodiments, the method further comprises:

[0034] If the transaction request is a repeated refund request, a corresponding transaction closing instruction is generated according to the transaction content information and user account information;

[0035] Send a transaction closing instruction to the fund management end to instruct the fund management end to close the refund transaction order that is subsequently received and matches the transaction content information and user account information.

[0036] In a second aspect, an embodiment of the present application further provides a transaction management device, including:

[0037] A request receiving module, used to obtain a transaction order generation request from a business end, where the transaction order generation request is generated based on a transaction request input by a user to the business end;

[0038] An information parsing module, used to parse a transaction order generation request to generate transaction content information and corresponding user account information, where the transaction content information is at least used to characterize a transaction type corresponding to the transaction request;

[0039] A query request module, used for generating a repeated transaction query request mapped with transaction content information and user account information when the transaction type is a refund transaction;

[0040] A first query module, configured to generate first query information corresponding to the business end based on the repeated query request, wherein the first query information includes a record corresponding to the transaction content information in the transaction record of the business end;

[0041] A second query module, used for sending a repeated query request to the fund management end, so that the fund management end generates second query information, the second query information including a record corresponding to the transaction content information in the transaction record of the fund management end;

[0042] A refund detection module, used to obtain the second query information fed back by the fund management end, and determine whether the transaction request is a repeated refund request based on the first query information and the second query information;

[0043] The order issuing module is used to generate a refund transaction order according to the transaction request if the transaction request is not a duplicate refund request, and send the refund transaction order to the fund management end so that the fund management end can execute the corresponding refund behavior.

[0044] In a third aspect, an embodiment of the present application further provides a computer device, the computer device comprising a memory and a processor;

[0045] Memory for storing computer programs;

[0046] A processor, used to execute a computer program and implement a transaction management method as provided in any embodiment of the present application specification and / or a claim risk analysis method as provided in any embodiment of the present application specification when executing the computer program.

[0047] In a fourth aspect, an embodiment of the present application also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the processor implements a transaction management method as provided in any embodiment of the present application specification and / or a claims risk analysis method as provided in any embodiment of the present application specification.

[0048] The embodiments of the present application provide a transaction management method, apparatus, device and medium, the method comprising: obtaining a transaction order generation request from a business end, the transaction order generation request being generated based on a transaction request input by a user to the business end; parsing the transaction order generation request to generate transaction content information and corresponding user account information, the transaction content information being at least used to characterize the transaction type corresponding to the transaction request; when the transaction type is a refund transaction, generating a repeated transaction query request mapped with the transaction content information and the user account information; generating first query information corresponding to the business end based on the repeated query request, the first query information including a record corresponding to the transaction content information in the transaction record of the business end; sending the repeated query request to the fund management end The second query information fed back by the fund management end is obtained, and whether the transaction request is a repeated refund request is determined according to the first query information and the second query information; if the transaction request is not a repeated refund request, a refund transaction order is generated according to the transaction request, and the refund transaction order is sent to the fund management end, so that the fund management end executes the corresponding refund behavior, and determines whether the refund amount has been returned to the user by querying and retrieving the transaction records of the business end and the fund management end, so as to avoid repeated refund transactions, thereby improving the fund management security of the fund management end and avoiding income and expenditure risks. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0050] Figure 1 A flowchart showing the steps of a transaction management method provided in an embodiment of the present application;

[0051] Figure 2 A schematic diagram of an application scenario of a transaction management method provided in an embodiment of the present application;

[0052] Figure 3 A flowchart of the steps for determining a claim settlement behavior in a transaction management method provided in an embodiment of the present application;

[0053] Figure 4 A flowchart showing the steps of another transaction management method provided in an embodiment of the present application;

[0054] Figure 5 A schematic diagram of the module structure of a transaction management device provided in an embodiment of the present application;

[0055] Figure 6 A schematic block diagram of the structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0056] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

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

[0058] Fund prevention and control is an important task of insurance companies' financial management. If the fund prevention is not done well, it will affect the professional image of the insurance company and affect the customers' reliance on the insurance company. Once the insurance company suffers a fund loss, the company needs to invest a large amount of cost to deal with the fund recovery.

[0059] The fund management end generally fully trusts the payment and collection requests of the business end, without doing any control over the funds from the business rule logic. The fund end is likely to only do fund transaction control at the transaction order level, but ignore the fund control at the order detail level (business document level). This makes it easy for the same business document to be traded repeatedly, especially for refunds, or for the same document to be used in multiple places, resulting in "double spending" of the same funds, which reduces the security of centralized payment and collection of funds under the order transaction model, increases the company's fund losses, and poses a risk of income and expenditure.

[0060] Based on this, the embodiments of the present application provide a transaction management method, device, equipment and medium, which aim to avoid repeated refund transactions, improve the fund management security of the fund management end, and avoid income and expenditure risks.

[0061] See also Figure 1 and Figure 2 , Figure 1 A flowchart showing the steps of a transaction management method provided in an embodiment of the present application is provided. Figure 2 A schematic diagram of an application scenario of a transaction management method provided in an embodiment of the present application.

[0062] like Figure 2As shown, specifically, for application scenarios in which users operate the business end and the fund management end performs fund management and transaction behaviors, the transaction management method provided in the embodiment of the present application can be applied to the control end connected to the business end and the fund management end respectively, and can also be applied to either the business end or the fund management end.

[0063] Exemplarily, the above-mentioned control end can be an electronic device such as a computer, an intelligent robot, an independent server or a server cluster, which is not limited here.

[0064] In this embodiment, the transaction management method is applied to an independent server connected to the business end and the fund management end respectively as an example for explanation, but the transaction management method is not limited to being used in this scenario only.

[0065] Some implementation modes of the present application are described in detail below in conjunction with the accompanying drawings. In the absence of conflict, the following embodiments and features in the embodiments may be combined with each other.

[0066] like Figure 1 As shown, an embodiment of the present application provides a transaction management method, which specifically includes the following steps S1-S7.

[0067] Step S1: Obtain a transaction order generation request from a business end, where the transaction order generation request is generated based on a transaction request input by a user to the business end.

[0068] It should be noted that the business end is an electronic device such as a computer, a smart phone or a smart watch. The user can operate the business end to generate a transaction request, or input a transaction request to the business end. The business end generates a transaction order generation request based on the transaction request, and the transaction order generation request is obtained by the server that executes this application.

[0069] Specifically, the transaction order generation request includes information related to the transaction request, such as transaction content information and corresponding user account information, wherein the user account information is the user account used to operate the business end to generate a transaction request or input a transaction request to the business end, and / or the user account currently logged in to the business end. The transaction content information includes but is not limited to the time when the user inputs the transaction request, the type information of the transaction request (which can be divided into refund transactions, payment transactions, etc.), the amount of the transaction request, etc.

[0070] Furthermore, when the type of transaction request is a refund transaction, the transaction order generation request also includes a target payment record corresponding to the refund transaction, and the target payment record refers to a record in which the user previously paid the amount of the refund transaction to the fund management terminal.

[0071] Exemplarily, the user can sign a contract with the target service provider by operating the business terminal or inputting a request to the business terminal, so that the target service provider provides corresponding services to the user based on the contract. For example, the target service provider can be an insurance service company, a technology service company, a medical service company, etc.

[0072] Among them, when the user signs a contract with the target service provider, he or she generally needs to pay a certain amount of money to the target service provider, specifically to the fund management end of the target service provider. After signing the contract, if the contract between the user and the target service provider permits, the user can terminate the contract with the target service provider and request a corresponding refund by operating the business end or inputting a request to the business end. At this time, the amount requested for refund is the amount paid to the fund management end of the target service provider when signing the contract.

[0073] Step S2: parsing the transaction order generation request to generate transaction content information and corresponding user account information, where the transaction content information is at least used to characterize the transaction type corresponding to the transaction request.

[0074] Specifically, based on the fact that the transaction order generation request includes information related to the transaction request, the device executing the method parses the transaction order generation request to generate transaction content information and corresponding user account information. The transaction content information at least includes type information of the transaction request, which represents the transaction type corresponding to the transaction request, and the transaction type can be divided into refund transaction, payment transaction or other types.

[0075] Step S3: When the transaction type is a refund transaction, a repeated transaction query request is generated that is mapped with the transaction content information and the user account information.

[0076] Specifically, the device executing the method is configured to query and retrieve the transaction records of the business end and the fund management end based on the repeated transaction query request to determine whether the refund amount has been returned to the user.

[0077] Among them, the transaction content information mapped by the repeated transaction query request is the transaction content information corresponding to the transaction request, which includes the time when the user inputs the transaction request, the amount of the transaction request, etc., and the user account information mapped by the repeated transaction query request is the user account used to operate the business end to generate the transaction request or input the transaction request to the business end, and / or, the user account currently logged in to the business end.

[0078] In some implementations, step S3 generates a repeated transaction query request that is mapped with the transaction content information and the user account information, including:

[0079] Determine the target amount corresponding to the transaction request according to the transaction content information, where the target amount is the amount requested to be returned by the transaction request;

[0080] Retrieving a first transaction history record corresponding to the user account information, and querying a target payment record for paying a target amount in the first transaction history record;

[0081] Generates a duplicate transaction query request based on the target payment record.

[0082] It should be noted that when the transaction type is a refund transaction, the target amount is the amount that the transaction request requests to be refunded, that is, the amount that the user paid to the fund management terminal in the previous time. The first transaction history record is at least part of the transaction record under the user account within the preset historical time period, and the target payment record refers to the record of the user paying the target amount to the fund management terminal in the first transaction history record. Further, the first transaction history record can also be all transaction records under the user account within the preset historical time period, that is, within the preset historical time period, the transactions executed by the user account logging in to different business terminals, and the various types of transactions executed are all reflected in the first transaction history record.

[0083] Specifically, the server executing the method determines the target amount corresponding to the transaction request according to the transaction content information, retrieves the first transaction history record corresponding to the user account information, and then searches the first transaction history record for the target payment record for paying the target amount, and generates a repeated transaction query request according to the target payment record. After that, the transaction records of the business end and the fund management end can be queried and retrieved based on the repeated transaction query request to determine whether the refund has been returned to the user.

[0084] Step S4: Generate first query information corresponding to the business end based on the repeated query request, the first query information including records corresponding to the transaction content information in the transaction records of the business end.

[0085] Specifically, the transaction management method provided in the embodiment of the present application is applied to independent servers respectively connected to the business end and the fund management end. The server executing this method sends the repeated query request to the business end to instruct the business end to retrieve the local transaction history record of the user account, so as to obtain the first query information based on the local transaction history record of the business end, that is, to query and retrieve the transaction records of the business end to confirm whether the refund has been returned to the user.

[0086] Further explanation: the first query information can be obtained according to the local transaction history record of the business end by the business end, and then the business end feeds back the first query information to the server executing this method, or the server executing this method retrieves the local transaction history record of the business end from the business end, and then the server queries and retrieves the local transaction history record of the business end to confirm whether the refund has been returned to the user. The following is an explanation of the implementation method of querying and retrieving the local transaction history record of the business end by the server:

[0087] See also Figure 3 , Figure 3 A flowchart showing the steps of generating first query information in a transaction management method provided in an embodiment of the present application.

[0088] like Figure 3 As shown, in some implementations, step S4 generates first query information corresponding to the service end based on the repeated query request, including:

[0089] Step S41, retrieve the second transaction history record of the business end;

[0090] Step S42: determining a refund request feature corresponding to the target payment record;

[0091] Step S43: Match the refund request in the second transaction history record according to the refund request feature, and use the matching result as the first query information.

[0092] Among them, the second transaction history record is at least part of the transaction record of the local business end within the preset historical time period. Further, the second transaction history record can also be all the transaction records of the local business end within the preset historical time period, that is, the transactions executed by different user accounts logging into the business end within the preset historical time period, and the various types of transactions executed are all reflected in the second transaction history record. When the transaction type is a refund transaction, the target payment record refers to the record of the user paying the target amount to the fund management end, and the target amount is the amount paid by the user to the fund management end when the user signs a contract with the target service provider.

[0093] Specifically, the server executing this method sends a repeated query request to the business end, so that the business end retrieves the local second transaction history record, and then the server obtains the second transaction history record fed back by the business end, and determines the refund request characteristics corresponding to the target payment record, and then matches it in the second transaction history record according to the refund request characteristics, and uses the matching result as the first query information.

[0094] It should be noted that the matching result includes one of the two results: the second transaction history record contains a transaction record that matches the refund request feature, and the second transaction history record does not contain a transaction record that matches the refund request feature. If the second transaction history record contains a transaction record that matches the refund request feature, it means that the transaction record on the business end contains a record of whether the refund amount has been returned to the user. On the contrary, if the second transaction history record does not contain a transaction record that matches the refund request feature, it means that the transaction record on the business end does not contain a record of whether the refund amount has been returned to the user.

[0095] In some implementations, the refund request feature includes a refund amount and a refund time, and step S43 performs matching in the second transaction history record according to the refund request feature, including:

[0096] Filtering out the payment transaction history corresponding to the user account information in the second transaction history;

[0097] Query the first matching transaction record whose transaction amount matches the refund amount from the collection transaction history;

[0098] Querying the second matching transaction record whose refund time is at the target transaction time from the collection transaction history, and the target transaction time is associated with the payment time of the target payment record;

[0099] A refund history record is determined based on the first matching transaction record and the second matching transaction record.

[0100] Specifically, the payment transaction history records the payment transactions under the corresponding user account name. The first matching transaction record refers to the transaction record in which the user's payment amount matches the refund amount, and the second matching record refers to the transaction record in which the user's payment time is within the target transaction time.

[0101] Specifically, determining the refund history record according to the first matching transaction record and the second matching transaction record includes: taking the intersection (i.e., the overlapping part) of the first matching transaction record and the second matching transaction record as the refund history record. If the refund history record exists, it means that the transaction record of the business end contains a record of whether the refund amount has been returned to the user, otherwise, it means that the transaction record of the business end does not contain a record of whether the refund amount has been returned to the user.

[0102] Exemplarily, the target transaction time is a period of time after the payment time of the target payment record, and the specific time range can be determined according to the contract between the user and the target service provider (ie, the time allowed for refunds stipulated in the contract).

[0103] It should be understood that screening the collection transaction history by using both transaction amount and refund time can accurately identify whether the transaction records on the business side contain records of whether the refunded funds have been returned to the user, thereby avoiding errors and omissions.

[0104] Step S5: Send a repeated query request to the fund management end, so that the fund management end generates second query information, and the second query information includes a record corresponding to the transaction content information in the transaction record of the fund management end.

[0105] Step S6: Obtain the second query information fed back by the fund management end, and determine whether the transaction request is a repeated refund request based on the first query information and the second query information.

[0106] Specifically, the transaction management method provided in the embodiment of the present application is applied to independent servers connected to the business end and the fund management end respectively as an example. The server executing this method sends the repeated query request to the fund management end to instruct the fund management end to retrieve the transaction history records, and obtain the first query information based on the local transaction history records of the fund management end, that is, query and retrieve the transaction records of the fund management end to confirm whether the refund has been returned to the user.

[0107] Further explanation: considering the high privacy importance of transaction records of general fund management end, the fund management end responds to the repeated query request and continues to query to obtain the second query information, and then the fund management end feeds back the second query information to the server executing this method.

[0108] In some implementations, step S6 determines whether the transaction request is a repeated refund request based on the first query information and the second query information, including:

[0109] Parsing the first query information to obtain a corresponding matching result to determine whether the transaction record of the business end includes a refund history record corresponding to the target payment record;

[0110] Parsing the second query information to obtain a corresponding matching result to determine whether the transaction record of the fund management end includes a refund history record corresponding to the target payment record;

[0111] When neither the transaction record at the business end nor the transaction record at the funds management end includes a refund history record corresponding to the target payment record, the transaction request is determined to be a non-duplicate refund request; and / or, when at least one of the transaction record at the business end and the transaction record at the funds management end includes a refund history record corresponding to the target payment record, the transaction request is determined to be a non-duplicate refund request.

[0112] It should be understood that the first query information represents whether the transaction record of the business end includes a refund history record corresponding to the target payment record, and the second query information represents whether the transaction record of the fund management end includes a refund history record corresponding to the target payment record.

[0113] Step S7: If the transaction request is not a duplicate refund request, a refund transaction order is generated according to the transaction request, and the refund transaction order is sent to the fund management end so that the fund management end executes the corresponding refund behavior.

[0114] Specifically, if the transaction request is not a duplicate refund request, the fund management end is allowed to execute the action of returning the target amount to the user.

[0115] In some implementations, the transaction management method provided in the embodiments of the present application further includes:

[0116] If the transaction request is a repeated refund request, a corresponding transaction closing instruction is generated according to the transaction content information and user account information;

[0117] Send a transaction closing instruction to the fund management end to instruct the fund management end to close the refund transaction order that is subsequently received and matches the transaction content information and user account information.

[0118] Specifically, if the transaction request is a repeated refund request, a transaction closing instruction is generated and sent to the fund management end. The transaction closing instruction is used to instruct the fund management end to close the refund transaction order that matches the transaction content information and user account information received later, so as to avoid repeated refunds to users, improve the fund management security of the fund management end, and avoid income and expenditure risks.

[0119] like Figure 2 As shown, it should be noted that the user can choose to log in to the user account at different business terminals (such as A01, A02, and A03). The present embodiment sends a transaction closing instruction to the fund management terminal C01, so that subsequent users can operate other business terminals to generate transaction requests, or input transaction requests with the same transaction content information, that is, the same refund request, to other business terminals. The fund management terminal can quickly and accurately identify the refund request as a repeated refund request and reject it. In particular, some business terminals, such as A03, can communicate directly with the fund management terminal C01 without going through the server B01 that executes this method. The server B01 actively sends a transaction closing instruction to the fund management terminal C01 to avoid some business terminals bypassing the server to request the fund management terminal for a refund, thereby eliminating the possibility of repeated refunds to users from the source, thereby greatly improving the fund management security of the fund management terminal C01.

[0120] See also Figure 4 , Figure 4A flowchart illustrating the steps of another transaction management method provided in an embodiment of the present application.

[0121] like Figure 2 and Figure 4 As shown, in some implementations, the transaction management method provided in the embodiment of the present application further includes:

[0122] Step S8: sending an account lock instruction to the fund management terminal according to the user account information, so that the fund management terminal stops receiving transaction orders corresponding to the user account information;

[0123] Step S9: After determining that the transaction request is not a duplicate refund request, an account unlocking instruction is sent to the fund management end to instruct the fund management end to resume receiving transaction orders corresponding to the user account information.

[0124] It should be noted that, taking the example of a user logging into the user account at the business terminal A01 and inputting a transaction request for a refund transaction through the business terminal A01: after generating a repeated transaction query request, in addition to sending a repeated query request to the fund management terminal C01, an account lock instruction is also sent to the fund management terminal to stop the fund management terminal from receiving transaction orders corresponding to the user account information, in order to avoid the user sending repeated refund requests to the fund management terminal through other business terminals (such as A02) other than the business terminal A01, which causes repeated refund transactions.

[0125] On the other hand, after determining that the transaction request is not a duplicate refund request, an account unlocking instruction is sent to the fund management end to instruct the fund management end to resume receiving transaction orders corresponding to the user's account information to avoid affecting the user's normal transaction requests.

[0126] See also Figure 5 , Figure 5 A schematic diagram of the module structure of a transaction management device provided in an embodiment of the present application.

[0127] like Figure 5 As shown, the transaction management device 100 includes:

[0128] The request receiving module 101 is used to obtain a transaction order generation request from the business end, where the transaction order generation request is generated based on the transaction request input by the user to the business end;

[0129] An information parsing module 102 is used to parse a transaction order generation request to generate transaction content information and corresponding user account information, where the transaction content information is at least used to characterize a transaction type corresponding to the transaction request;

[0130] A query request module 103, for generating a repeated transaction query request mapped with the transaction content information and the user account information when the transaction type is a refund transaction;

[0131] A first query module 104, configured to generate first query information corresponding to the business end based on the repeated query request, the first query information including a record corresponding to the transaction content information in the transaction record of the business end;

[0132] The second query module 105 is used to send a repeated query request to the fund management end, so that the fund management end generates second query information, and the second query information includes a record corresponding to the transaction content information in the transaction record of the fund management end;

[0133] The refund detection module 106 is used to obtain the second query information fed back by the fund management end, and determine whether the transaction request is a repeated refund request according to the first query information and the second query information;

[0134] The order issuing module 107 is used to generate a refund transaction order according to the transaction request if the transaction request is not a duplicate refund request, and send the refund transaction order to the fund management end so that the fund management end executes the corresponding refund behavior.

[0135] In some implementations, the query request module 103 generates a repeated transaction query request that is mapped with the transaction content information and the user account information, including:

[0136] Determine the target amount corresponding to the transaction request according to the transaction content information, where the target amount is the amount requested to be returned by the transaction request;

[0137] Retrieving a first transaction history record corresponding to the user account information, and querying a target payment record for paying a target amount in the first transaction history record;

[0138] Generates a duplicate transaction query request based on the target payment record.

[0139] In some implementations, the first query module 104 generates first query information corresponding to the service end based on the repeated query request, including:

[0140] Retrieve the second transaction history record from the business end;

[0141] Determine the refund request characteristics corresponding to the target payment record;

[0142] A match is performed in the second transaction history record according to the refund request feature, and the matching result is used as the first query information.

[0143] In some implementations, the refund detection module 106 determines whether the transaction request is a repeated refund request based on the first query information and the second query information, including:

[0144] Parsing the first query information to obtain a corresponding matching result to determine whether the transaction record of the business end includes a refund history record corresponding to the target payment record;

[0145] Parsing the second query information to obtain a corresponding matching result to determine whether the transaction record of the fund management end includes a refund history record corresponding to the target payment record;

[0146] When neither the transaction record at the business end nor the transaction record at the funds management end includes a refund history record corresponding to the target payment record, the transaction request is determined to be a non-duplicate refund request; and / or, when at least one of the transaction record at the business end and the transaction record at the funds management end includes a refund history record corresponding to the target payment record, the transaction request is determined to be a non-duplicate refund request.

[0147] In some implementations, the refund request feature of the first query module 104 includes a refund amount and a refund time, and matching is performed in the second transaction history record according to the refund request feature, including:

[0148] Filtering out the payment transaction history corresponding to the user account information in the second transaction history;

[0149] Query the first matching transaction record whose transaction amount matches the refund amount from the collection transaction history;

[0150] Querying the second matching transaction record whose refund time is at the target transaction time from the collection transaction history, and the target transaction time is associated with the payment time of the target payment record;

[0151] A refund history record is determined based on the first matching transaction record and the second matching transaction record.

[0152] In some embodiments, the transaction management device 100 is further configured to:

[0153] Sending an account lock instruction to the fund management terminal according to the user account information, so that the fund management terminal stops receiving transaction orders corresponding to the user account information;

[0154] After determining that the transaction request is not a duplicate refund request, an account unlock instruction is sent to the fund management end to instruct the fund management end to resume receiving transaction orders corresponding to the user account information.

[0155] In some implementations, the order issuing module 107 is further used to:

[0156] If the transaction request is a repeated refund request, a corresponding transaction closing instruction is generated according to the transaction content information and user account information;

[0157] Send a transaction closing instruction to the fund management end to instruct the fund management end to close the refund transaction order that is subsequently received and matches the transaction content information and user account information.

[0158] See also Figure 6 , Figure 6 A schematic block diagram of the structure of a computer device provided in an embodiment of the present application.

[0159] like Figure 6 As shown, the computer device 200 includes a processor 201 and a memory 202, and the processor 201 and the memory 202 are connected via a bus 203, such as an I2C (Inter-integrated Circuit) bus.

[0160] Specifically, the processor 201 is used to provide computing and control capabilities to support the operation of the entire computer device. The processor 201 can be a central processing unit (CPU), and the processor 201 can also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc.

[0161] Specifically, the memory 202 may be a Flash chip, a read-only memory (ROM) disk, an optical disk, a USB flash drive, or a mobile hard disk.

[0162] Those skilled in the art will understand that Figure 6 The structure shown in the figure is merely a block diagram of a partial structure related to the embodiment of the present application, and does not constitute a limitation on the computer device to which the embodiment of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0163] Among them, the processor is used to run the computer program stored in the memory, and implement any transaction management method provided in the embodiments of the present application and / or any claim risk analysis method provided in the embodiments of the present application specification when executing the computer program.

[0164] In some implementations, the processor 201 is configured to run a computer program stored in the memory 202, and implement the following steps when executing the computer program:

[0165] Obtaining a transaction order generation request from the business end, where the transaction order generation request is generated based on the transaction request input by the user to the business end;

[0166] Parsing a transaction order generation request to generate transaction content information and corresponding user account information, where the transaction content information is at least used to characterize a transaction type corresponding to the transaction request;

[0167] When the transaction type is a refund transaction, a repeated transaction query request is generated that is mapped with the transaction content information and the user account information;

[0168] generating first query information corresponding to the business end based on the repeated query request, the first query information including a record corresponding to the transaction content information in the transaction record of the business end;

[0169] Sending a repeated query request to the fund management end so that the fund management end generates second query information, the second query information including a record corresponding to the transaction content information in the transaction record of the fund management end;

[0170] Obtaining the second query information fed back by the fund management end, and determining whether the transaction request is a repeated refund request according to the first query information and the second query information;

[0171] If the transaction request is not a duplicate refund request, a refund transaction order is generated according to the transaction request, and the refund transaction order is sent to the fund management end so that the fund management end executes the corresponding refund behavior.

[0172] In some implementations, the processor 201 generates a repeated transaction query request that is mapped with the transaction content information and the user account information, including:

[0173] Determine the target amount corresponding to the transaction request according to the transaction content information, where the target amount is the amount requested to be returned by the transaction request;

[0174] Retrieving a first transaction history record corresponding to the user account information, and querying a target payment record for paying a target amount in the first transaction history record;

[0175] Generates a duplicate transaction query request based on the target payment record.

[0176] In some implementations, the processor 201 generates first query information corresponding to the service end based on the repeated query request, including:

[0177] Retrieve the second transaction history record from the business end;

[0178] Determine the refund request characteristics corresponding to the target payment record;

[0179] A match is performed in the second transaction history record according to the refund request feature, and the matching result is used as the first query information.

[0180] In some implementations, the processor 201 determines whether the transaction request is a repeated refund request according to the first query information and the second query information, including:

[0181] Parsing the first query information to obtain a corresponding matching result to determine whether the transaction record of the business end includes a refund history record corresponding to the target payment record;

[0182] Parsing the second query information to obtain a corresponding matching result to determine whether the transaction record of the fund management end includes a refund history record corresponding to the target payment record;

[0183] When neither the transaction record at the business end nor the transaction record at the funds management end includes a refund history record corresponding to the target payment record, the transaction request is determined to be a non-duplicate refund request; and / or, when at least one of the transaction record at the business end and the transaction record at the funds management end includes a refund history record corresponding to the target payment record, the transaction request is determined to be a non-duplicate refund request.

[0184] In some implementations, the refund request feature includes a refund amount and a refund time, and the processor 201 performs matching in the second transaction history record according to the refund request feature, including:

[0185] Filtering out the payment transaction history corresponding to the user account information in the second transaction history;

[0186] Query the first matching transaction record whose transaction amount matches the refund amount from the collection transaction history;

[0187] Querying the second matching transaction record whose refund time is at the target transaction time from the collection transaction history, and the target transaction time is associated with the payment time of the target payment record;

[0188] A refund history record is determined based on the first matching transaction record and the second matching transaction record.

[0189] In some implementations, the processor 201 is further configured to:

[0190] Sending an account lock instruction to the fund management terminal according to the user account information, so that the fund management terminal stops receiving transaction orders corresponding to the user account information;

[0191] After determining that the transaction request is not a duplicate refund request, an account unlock instruction is sent to the fund management end to instruct the fund management end to resume receiving transaction orders corresponding to the user account information.

[0192] In some implementations, the processor 201 is further configured to:

[0193] If the transaction request is a repeated refund request, a corresponding transaction closing instruction is generated according to the transaction content information and user account information;

[0194] Send a transaction closing instruction to the fund management end to instruct the fund management end to close the refund transaction order that is subsequently received and matches the transaction content information and user account information.

[0195] It should be noted that technical personnel in the relevant field can clearly understand that for the convenience and brevity of description, the specific working process of the computer device described above can refer to the corresponding process in the aforementioned transaction management method embodiment, and will not be repeated here.

[0196] An embodiment of the present application also provides a storage medium, which stores a computer program. The computer program can be executed by one or more processors to implement any transaction management method provided in the embodiment of the present application and / or any claim risk analysis method provided in the embodiment of the present application specification.

[0197] The storage medium may be an internal storage unit of the computer device described in the above embodiment, such as a hard disk or memory of the computer device. The storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the computer device.

[0198] In summary, the embodiments of the present application provide a transaction management method, apparatus, device and medium, the method comprising: obtaining a transaction order generation request from a business end, the transaction order generation request being generated based on a transaction request input by a user to the business end; parsing the transaction order generation request to generate transaction content information and corresponding user account information, the transaction content information being at least used to characterize the transaction type corresponding to the transaction request; when the transaction type is a refund transaction, generating a repeated transaction query request mapped with the transaction content information and the user account information; generating first query information corresponding to the business end based on the repeated query request, the first query information including a record corresponding to the transaction content information in the transaction record of the business end; sending a repeated query request to a fund management end. The second query information fed back by the fund management end is obtained, and whether the transaction request is a repeated refund request is determined according to the first query information and the second query information; if the transaction request is not a repeated refund request, a refund transaction order is generated according to the transaction request, and the refund transaction order is sent to the fund management end, so that the fund management end executes the corresponding refund behavior, and determines whether the refund amount has been returned to the user by querying and retrieving the transaction records of the business end and the fund management end, so as to avoid repeated refund transactions, thereby improving the fund management security of the fund management end and avoiding income and expenditure risks.

[0199] It will be appreciated by those skilled in the art that all or some of the steps, systems, and functional modules / units in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. In a hardware embodiment, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or temporary medium). As known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, it is well known to those of ordinary skill in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0200] In the description of this application, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in this application can be understood according to specific circumstances.

[0201] It should be understood that the terms used in this application specification are only for the purpose of describing specific embodiments and are not intended to limit the application. As used in this application specification and the appended claims, unless the context clearly indicates otherwise, the singular forms "a", "an" and "the" are intended to include plural forms.

[0202] It should also be understood that the term "and / or" used in the specification of this application and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, including these combinations. It should be noted that, in this article, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or system including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or system. In the absence of further restrictions, an element defined by the sentence "including a..." does not exclude the presence of other identical elements in the process, method, article or system including the element.

[0203] The serial numbers of the embodiments of the present application are only for description and do not represent the advantages and disadvantages of the embodiments. The above are only specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in the present application, and these modifications or replacements should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

Claims

1. A transaction management method, characterized in that: The method comprises: Acquire a transaction order generation request from a service end, wherein the transaction order generation request is generated based on a transaction request input by a user to the service end; Parsing the transaction order generation request to generate transaction content information and corresponding user account information, wherein the transaction content information is at least used to characterize the transaction type corresponding to the transaction request; When the transaction type is a refund transaction, generating a repeated transaction query request that is mapped with the transaction content information and the user account information; generating first query information corresponding to the business end based on the repeated query request, the first query information including a record corresponding to the transaction content information in the transaction record of the business end; Sending the repeated query request to the fund management end, so that the fund management end generates second query information, wherein the second query information includes a record corresponding to the transaction content information in the transaction record of the fund management end; Acquire the second query information fed back by the fund management end, and determine whether the transaction request is a repeated refund request according to the first query information and the second query information; If the transaction request is not a duplicate refund request, a refund transaction order is generated according to the transaction request, and the refund transaction order is sent to the fund management end so that the fund management end executes the corresponding refund behavior.

2. The transaction management method according to claim 1, characterized in that: The generating of a repeated transaction query request that is mapped with the transaction content information and the user account information includes: Determine the target amount corresponding to the transaction request according to the transaction content information, where the target amount is the amount required to be returned by the transaction request; Retrieving a first transaction history record corresponding to the user account information, and searching the first transaction history record for a target payment record for paying the target amount; The repeated transaction query request is generated according to the target payment record.

3. The transaction management method according to claim 2, characterized in that: The generating first query information corresponding to the service end based on the repeated query request includes: Retrieving a second transaction history record of the business end; Determining a refund request feature corresponding to the target payment record; A match is performed in the second transaction history record according to the refund request feature, and the matching result is used as the first query information.

4. The transaction management method according to claim 3, characterized in that: The determining whether the transaction request is a repeated refund request according to the first query information and the second query information includes: Parsing the first query information to obtain a corresponding matching result to determine whether the transaction record of the business end includes a refund history record corresponding to the target payment record; parsing the second query information to obtain a corresponding matching result to determine whether the transaction record of the fund management terminal includes a refund history record corresponding to the target payment record; When neither the transaction record of the business end nor the transaction record of the funds management end includes a refund history record corresponding to the target payment record, the transaction request is determined to be a non-duplicate refund request; and / or, when at least one of the transaction record of the business end and the transaction record of the funds management end includes a refund history record corresponding to the target payment record, the transaction request is determined to be a non-duplicate refund request.

5. The transaction management method according to claim 3, characterized in that: The refund request feature includes a refund amount and a refund time, and matching in the second transaction history record according to the refund request feature includes: Filtering out the payment transaction history corresponding to the user account information from the second transaction history; Querying the first matching transaction record whose transaction amount matches the refund amount from the collection transaction history; Querying the second matching transaction record whose refund time is at the target transaction time from the collection transaction history, and the target transaction time is associated with the payment time of the target payment record; The refund history record is determined according to the first matching transaction record and the second matching transaction record.

6. The transaction management method according to claim 1, characterized in that: The method further comprises: Sending an account locking instruction to the fund management terminal according to the user account information, so that the fund management terminal stops receiving transaction orders corresponding to the user account information; After determining that the transaction request is not a duplicate refund request, an account unlocking instruction is sent to the fund management end to instruct the fund management end to resume receiving transaction orders corresponding to the user account information.

7. The transaction management method according to any one of claims 1 to 6, characterized in that: The method further comprises: If the transaction request is a repeated refund request, generating a corresponding transaction closing instruction according to the transaction content information and the user account information; The transaction closing instruction is sent to the fund management end to instruct the fund management end to close the refund transaction order subsequently received that matches the transaction content information and the user account information.

8. A transaction management device, characterized in that: include: A request receiving module, used to obtain a transaction order generation request from a business end, wherein the transaction order generation request is generated based on a transaction request input by a user to the business end; An information parsing module, used for parsing the transaction order generation request to generate transaction content information and corresponding user account information, wherein the transaction content information is at least used for characterizing the transaction type corresponding to the transaction request; A query request module, configured to generate a repeated transaction query request mapped with the transaction content information and the user account information when the transaction type is a refund transaction; A first query module, configured to generate first query information corresponding to the business end based on the repeated query request, wherein the first query information includes a record corresponding to the transaction content information in the transaction record of the business end; A second query module, configured to send a repeated query request to the fund management terminal, so that the fund management terminal generates second query information, wherein the second query information includes a record corresponding to the transaction content information in the transaction record of the fund management terminal; a refund detection module, configured to obtain the second query information fed back by the fund management terminal, and determine whether the transaction request is a repeated refund request according to the first query information and the second query information; The order issuing module is used to generate a refund transaction order according to the transaction request if the transaction request is not a duplicate refund request, and send the refund transaction order to the fund management end so that the fund management end executes the corresponding refund behavior.

9. A computer device, characterized in that: The computer device includes a memory and a processor; The memory is used to store computer programs; The processor is used to execute the computer program and implement the transaction management method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the processor implements the transaction management method according to any one of claims 1 to 7.

Images