Transaction state checking method and device
By storing log information at the end of the transaction and comparing it in the database, the problem of untimely discovery of abnormal transaction status is solved, and timely and accurate abnormal detection is achieved to avoid the risk of fund liquidation.
Patent Information
- Application Number
- CN202410010039.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-01-03
- Publication Date
- 2025-07-04
AI Technical Summary
The prior art lacks timely and accurately discovers abnormal transaction status records to the database, resulting in risk of fund liquidation.
When the transaction reaches the preset final state, the final log information is printed and stored on the disk, and the transaction data is stored in the database at the same time. When the preset trigger condition is met, the final log information on the disk and the transaction data in the database are compared by transaction batch, and transaction data with inconsistent status are found.
By using the final state log information with homologous and immutable status as a comparison, transaction status abnormalities can be discovered in a timely and accurate manner to avoid the risk of fund liquidation.
Smart Images
Figure CN120258796A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular, to a method and device for verifying transaction status. Background Art
[0002] In recent years, it has become very common to conclude various transactions through online trading platforms. For the convenience of verification and traceability, during or after a transaction, the trading platform will store transaction status information in a database.
[0003] In extreme scenarios such as database hardware failures or human operation errors, the database may experience abnormal transfer of transaction status, resulting in the transaction status obtained by external institutions being inconsistent with the transaction status recorded by the trading platform in the database. Therefore, it is necessary to verify the transaction status recorded in the database.
[0004] However, there is currently a lack of an effective verification solution, which cannot timely and accurately detect abnormalities in the transaction status recorded in the database, posing a risk of fund settlement. Summary of the Invention
[0005] Embodiments of this application provide a method and device for verifying transaction status to solve the problem in the prior art that it is lacking in timely and accurately detecting abnormalities in the transaction status recorded in the database.
[0006] In a first aspect, embodiments of this application provide a method for verifying transaction status, including:
[0007] During the execution of a transaction by a target application, if the transaction reaches a preset final state, print the final state log information and store it on disk, and store the transaction data in a database;
[0008] Under the condition of meeting a preset trigger condition, read target transaction data from the database in transaction batches, and read the target final state log information of the corresponding transaction batches from the disk;
[0009] Compare the transaction data with the target final state log information item by item to determine whether the transaction status of each transaction in the transaction data is consistent with the transaction status in the corresponding final state log information;
[0010] If the transaction status in any piece of transaction data in the transaction data is inconsistent with the transaction status in the corresponding final state log information, record that there is an abnormality in this piece of transaction data.
[0011] In a second aspect, embodiments of this application further provide a device for verifying transaction status, including:
[0012] A data storage module, configured to print final state log information and store it on a disk, and store transaction data in a database when the transaction reaches a preset final state during the execution of a target application;
[0013] A data reading module, configured to read target transaction data from the database by transaction batches and read target final state log information of corresponding transaction batches from the disk when a preset trigger condition is met;
[0014] A status verification module, configured to compare the transaction data with the target final state log information item by item to determine whether the transaction status of each transaction in the transaction data is consistent with the transaction status in the corresponding final state log information;
[0015] An exception recording module, configured to record that there is an exception in a certain transaction data when the transaction status in any transaction data in the transaction data is inconsistent with the transaction status in the corresponding final state log information.
[0016] In a third aspect, an embodiment of the present application further provides an electronic device, including: a memory, a processor, and a computer program stored on the memory and executable on the processor, where when the computer program is executed by the processor, the steps of the method described in the first aspect are implemented.
[0017] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the method described in the first aspect are implemented.
[0018] With at least one of the above technical solutions adopted in the embodiments of the present application, since the final state log information of the transaction and the transaction data itself have the characteristics of being homologous and having an immutable state, therefore, using the final state log information stored on the disk as control group data to check the transaction status in the transaction data stored in the database can timely and accurately detect abnormalities in the transaction status recorded in the database, thereby avoiding the risk of fund settlement. BRIEF DESCRIPTION OF THE DRAWINGS
[0019] The drawings described herein are used to provide a further understanding of the present application, and constitute a part of the present application. The schematic embodiments of the present application and their descriptions are used to explain the present application, and do not constitute an improper limitation to the present application. In the drawings:
[0020] Figure 1 is a flowchart of a transaction status verification method provided by an embodiment of the present application.
[0021] Figure 2 is a schematic diagram of an application scenario of a transaction status verification method provided by an embodiment of the present application.
[0022] Figure 3 It is a detailed process schematic diagram of step 101 in a transaction status verification method provided by an embodiment of the present application.
[0023] Figure 4 It is a schematic diagram of the implementation principle of step 101 in a transaction status verification method provided by an embodiment of the present application.
[0024] Figure 5 It is a detailed process schematic diagram of step 104 in a transaction status verification method provided by an embodiment of the present application.
[0025] Figure 6 It is a schematic diagram of the structure of a transaction status verification device provided by an embodiment of the present application.
[0026] Figure 7 It is a schematic diagram of the structure of an electronic device provided by an embodiment of the present application. Detailed implementation manners
[0027] To make the objectives, technical solutions and advantages of the present application clearer, the technical solutions of the present application will be clearly and completely described below in conjunction with specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts shall fall within the protection scope of the present application.
[0028] To timely and accurately detect abnormalities in the transaction status recorded in the database, an embodiment of the present application provides a transaction status verification method and device, and the method can be executed by an electronic device or software installed in the electronic device. Among them, the electronic device includes but is not limited to: any one of intelligent terminal devices such as smart phones, personal computers (PCs), laptop computers, tablet computers, e-readers, Internet TVs, wearable devices, etc.; among them, the server can be a back-end server device of an insurance company, and the server includes but is not limited to: a single server, a server cluster, a cloud server or a cloud server cluster, etc.
[0029] The following first describes a transaction status verification method provided by an embodiment of the present application.
[0030] As Figure 1 shown, a transaction status verification method provided by an embodiment of the present application may include:
[0031] Step 101, during the execution of a transaction by a target application, if the transaction reaches a preset final state, print final state log information and store it on the disk, and store the transaction data in the database.
[0032] Among them, the target application can be multiple applications of a trading platform, and the trading platform can be any online trading platform (such as an online clearing platform).
[0033] Among them, the final state log information can include, but is not limited to, at least one of the following:
[0034] Trading batch number;
[0035] Trading initiator number;
[0036] Trading serial number;
[0037] Trading category;
[0038] Trading final state.
[0039] Figure 2 Shows a schematic diagram of an application scenario of a trading status verification method provided by an embodiment of the present application. As Figure 2 Shown, the user can access the online clearing platform through channel 21 (such as a client) to conduct transaction 22. When the transaction reaches the preset final state, on the one hand, print the final state log information and store it on disk 26; on the other hand, store the transaction data in database 25; in addition, the transaction funds can also be transferred into the reserve fund 23, and the reserve fund information is stored in database 24. In this way, the final state log information stored on disk 26 can be used as the control group data to check whether there is an abnormal transfer in the trading status of the transaction data stored in database 25; optionally, the reserve fund information stored in database 24 and the transaction data stored in database 25 can also be compared to check the transaction amount.
[0040] In the case where the target application includes multiple applications, step 101 may specifically include: during the execution of the transaction by the multiple applications, if the transaction reaches the corresponding preset final state, print the final state log information respectively to obtain multiple copies of final state log information; merge the multiple copies of final state log information and store them on disk.
[0041] As an example, assuming that the trading platform is an online clearing platform, the target application includes, but is not limited to, an online trading application, a compensation trading application, and a customs declaration application. Correspondingly, the preset final states include an online final state, a compensation final state, and a customs declaration final state. The multiple copies of final state log information include: online final state log information, compensation final state log information, and customs declaration final state log information.
[0042] The meanings of several terms involved in the above example are as follows:
[0043] Trading final state: The immutable final state when an online payment transaction is completed.
[0044] Online final state: The online transaction reaches the successful final state or the failed final state.
[0045] Compensation final state: If the online transaction fails to reach the final state due to reasons such as failure or timeout, compensation query is performed to obtain the final state.
[0046] Single - closing final state: If the final state cannot be obtained through transaction compensation query, the transaction is forced to close and the presumed final state is assigned.
[0047] Final - state log information: The log information output when the transaction reaches the final state.
[0048] Optionally, the disk for storing the final - state log information can be the disk of the server corresponding to the target application, or rather, the disk for storing the final - state log information is located in the server corresponding to the target application.
[0049] Based on the above example, a detailed implementation process of step 101 is shown in Figure 3 .
[0050] As Figure 3 shown, step 101 may specifically include three stages (this process is also the transaction process of the transaction):
[0051] The first stage (online - transaction stage):
[0052] Step 311, receive an online request for the transaction.
[0053] Step 312, store the online request in the database (store it in the corresponding database).
[0054] Step 313, transfer the online request (such as transfer to the clearing system), and the online transaction reaches the final state (i.e., the online final state).
[0055] Step 315, update the transaction data to the database.
[0056] Step 316, print the online - final - state log information.
[0057] Step 314, return a response to the user.
[0058] The second stage (compensation - transaction stage):
[0059] Step 321, perform a compensation operation for the transaction.
[0060] Step 322, perform a compensation query.
[0061] If the compensation fails, execute step 323; otherwise, execute step 324.
[0062] Step 323, end.
[0063] Step 324, update the transaction data to the database.
[0064] Step 325, print the compensation end-state log information.
[0065] Step 326, send an end-state notification to the user.
[0066] The third stage (closing order stage):
[0067] Step 331, perform a closing order operation on the transaction.
[0068] Step 332, after inferring the end state, update the transaction data to the database.
[0069] Step 333, print the closing order end-state log information.
[0070] Step 334, send an end-state notification to the user.
[0071] Optionally, after storing the end-state log information on the disk and storing the transaction data in the database, further, collect the end-state log information from the disk; extract the transaction data from the database; pool the collected end-state log information and the extracted transaction data by transaction batches to a big data platform; to back up the end-state log information and transaction data. Further still, after pooling the collected end-state log information and the extracted transaction data to the big data platform, the end-state log information stored on the disk can be deleted to save disk storage space.
[0072] For example, as Figure 4 shown, the end-state log information (such as online end-state log information, compensation end-state log information, and closing order end-state log information) printed by Application 1, Application 2, Application 3... Application N (i.e., the target application) can be collected separately through a log collection program to form control group data 41. Additionally, corresponding transaction data is extracted from Database 1, Database 2, Database 3... Database N as data to be verified 42, and these two parts of data are grouped together to the big data platform 43.
[0073] It can be understood that to establish a transaction state verification mechanism for the transaction data stored in the database, control group data with non-abnormal state transitions needs to be constructed. Since the end-state log information of the transaction and the transaction data itself have the characteristics of being homologous and having an immutable state, the end-state log information is selected as the control group data in the embodiments of the present application. During the execution of the application for transaction processing, when the transaction reaches the end state, structured end-state log information is printed and stored on the disk of the application server.
[0074] Step 102, when a preset trigger condition is met, read the target transaction data from the database by transaction batches, and read the target end-state log information of the corresponding transaction batches from the disk.
[0075] Among them, the preset trigger conditions may include at least one of the following: reaching a preset verification period, reaching a preset time, and so on. More specifically, the preset trigger condition may include: reaching the timing time of a preset timing verification task.
[0076] Step 103: Compare the transaction data with the target final state log information one by one to determine whether the transaction status of each transaction in the transaction data is consistent with the transaction status in the corresponding final state log information.
[0077] Step 104: When the transaction status of any transaction data in the transaction data is inconsistent with the transaction status in the corresponding final state log information, record that there is an abnormality in this transaction data.
[0078] In specific implementation, the final state log information (control group data) and transaction data (data to be verified) can be queried separately by transaction batches. Based on the final state log information, check one by one whether the transaction final states in the transaction data are consistent with those in the control data group. If they are inconsistent, record the abnormal transaction data.
[0079] Optionally, issue an alarm for the transaction data with abnormalities to facilitate timely verification and processing, thereby avoiding the risk of fund settlement.
[0080] Figure 5 The detailed process of transaction status verification for the network settlement platform is given. As Figure 5 shown, this process may include:
[0081] Step 50: Trigger the verification task, read the transaction data 51, and read the online final state log information 521, compensation final state log information 522, and order closing final state log information 523, and merge the online final state log information 521, compensation final state log information 522, and order closing final state log information 523 to obtain the merged data 52.
[0082] Step 53: Group and verify the transaction data 51 and the merged data 52 to confirm whether the recorded transaction final states are consistent; if all are consistent, execute Step 56.
[0083] Step 54: Record the transaction data with abnormalities (differences in transaction final states).
[0084] Step 55: Issue an alarm for the abnormal transaction data and execute Step 56 after the verification is completed.
[0085] Step 56: End.
[0086] A transaction status verification method provided by an embodiment of the present application. Since the final state log information of a transaction has the characteristics of being homologous with the transaction data itself and having an immutable state, therefore, using the final state log information stored on the disk as the control group data to verify the transaction status in the transaction data stored in the database can timely and accurately detect abnormalities in the transaction status recorded in the database, thereby avoiding the risk of fund settlement.
[0087] The above describes a transaction status verification method provided by an embodiment of the present application. Corresponding to the above method embodiment, an embodiment of the present application also provides a transaction status verification device, which will be introduced below.
[0088] As Figure 6 shown, a transaction status verification device 600 provided by an embodiment of the present application may include: a data storage module 601, a data reading module 602, a status verification module 603, and an exception recording module 604.
[0089] The data storage module 601 is used to, during the execution of a transaction by a target application, if the transaction reaches a preset final state, print the final state log information and store it on the disk, and store the transaction data in the database.
[0090] Among them, the target application can be multiple applications of a trading platform, and the trading platform can be any online trading platform. The final state log information may include, but is not limited to, at least one of the following:
[0091] Transaction batch number;
[0092] Transaction initiator number;
[0093] Transaction serial number;
[0094] Transaction category;
[0095] Transaction final state.
[0096] In the case where the target application includes multiple applications, the data storage module 601 is specifically used to: during the execution of a transaction by the multiple applications, if the transaction reaches the corresponding preset final state, print the final state log information respectively to obtain multiple copies of final state log information; merge the multiple copies of final state log information and store them on the disk.
[0097] As an example, assuming that the trading platform is a network settlement platform, the target applications include, but are not limited to, an online trading application, a compensation trading application, and a customs declaration application. Correspondingly, the preset final states include an online final state, a compensation final state, and a customs declaration final state, and the multiple copies of final state log information include: online final state log information, compensation final state log information, and customs declaration final state log information.
[0098] The meanings of several terms involved in the above example are as follows:
[0099] Transaction final state: The immutable final state where a network payment transaction has been completed.
[0100] Online final state: An online transaction reaches a successful final state or a failed final state.
[0101] Compensation final state: When an online transaction fails to reach the final state due to reasons such as a fault or timeout, a compensation query is performed to obtain the final state.
[0102] Bill closing final state: When the final state cannot be obtained through a transaction compensation query, the transaction is forcibly closed and a presumed final state is assigned.
[0103] Final state log information: The log information output when a transaction reaches the final state.
[0104] Optionally, the disk storing the final state log information can be the disk of the server corresponding to the target application, or rather, the disk storing the final state log information is located in the server corresponding to the target application.
[0105] Optionally, the apparatus 600 may further include: a data aggregation module, configured to, after storing the final state log information to the disk and storing the transaction data to the database, collect the final state log information from the disk, extract the transaction data from the database, and aggregate the collected final state log information and the extracted transaction data by transaction batches to a big data platform for backing up the final state log information and the transaction data. Further, the apparatus 600 may further include: a deletion module, configured to, after aggregating the collected final state log information and the extracted transaction data to the big data platform, delete the final state log information stored on the disk to save the storage space of the disk.
[0106] It can be understood that to establish a transaction status verification mechanism for the transaction data stored in the database, it is necessary to construct control group data whose status will not abnormally transition. Since the final state log information of a transaction and the transaction data itself have the characteristics of being of the same origin and having an immutable status, the final state log information is selected as the control group data in the embodiments of the present application. During the execution of a transaction process by an application, when the transaction reaches the final state, structured final state log information is printed and stored on the disk of the application server.
[0107] The data reading module 602 is configured to, when a preset trigger condition is satisfied, read target transaction data from the database by transaction batches and read target final state log information of the corresponding transaction batches from the disk.
[0108] Wherein, the preset trigger condition may include at least one of the following: reaching a preset verification period, reaching a preset time, etc. More specifically, the preset trigger condition may include: reaching the timing time of a preset timed verification task.
[0109] A status verification module 603 is configured to compare the transaction data with the target final state log information item by item to determine whether the transaction status of each transaction in the transaction data is consistent with the transaction status in the corresponding final state log information.
[0110] An exception recording module 604 is configured to record that there is an exception in a transaction data item when the transaction status in any transaction data item in the transaction data is inconsistent with the transaction status in the corresponding final state log information.
[0111] In specific implementation, the final state log information (control group data) and the transaction data (data to be verified) can be queried separately by transaction batches. Taking the transaction data as a benchmark, check item by item whether the transaction final state in the transaction data is consistent with the transaction final state in the control data group. If not, record the abnormal transaction data item.
[0112] Optionally, the apparatus 600 may further include: an alarm module, configured to alarm for the transaction data with exceptions, so as to facilitate timely verification and processing, and thus avoid the risk of fund settlement.
[0113] For a transaction status verification apparatus provided in an embodiment of the present application, since the final state log information of a transaction and the transaction data itself have the characteristics of the same source and unchangeable status, therefore, using the final state log information stored on the disk as the control group data to verify the transaction status in the transaction data stored in the database can timely and accurately detect the exceptions in the transaction status recorded in the database, and thus avoid the risk of fund settlement.
[0114] It should be noted that since the content executed by the apparatus embodiment is similar to that of the method embodiment, therefore, the description of the apparatus embodiment in this article is relatively brief, and for related parts, please refer to the method embodiment part.
[0115] Figure 7 shows a schematic structural diagram of an electronic device provided in an embodiment of the present application. Please refer to Figure 7 On the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. Among them, the memory may include a memory, such as a high-speed random access memory (Random-Access Memory, RAM), and may also include a non-volatile memory, such as at least one disk memory, etc. Of course, the electronic device may also include other hardware required for other services.
[0116] The processor, network interface, and memory can be interconnected through an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of representation, Figure 7 only a bidirectional arrow is used in
[0117] Memory, used to store programs. Specifically, the program can include program code, and the program code includes computer operation instructions. The memory can include a memory and a non-volatile memory, and provide instructions and data to the processor.
[0118] The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming a transaction status verification device at the logical level. The processor executes the program stored in the memory and is specifically used to execute the following steps:
[0119] During the execution of a transaction by the target application, if the transaction reaches a preset final state, print the final state log information and store it on the disk, and store the transaction data in the database;
[0120] Under the condition of meeting the preset trigger condition, read the target transaction data from the database by transaction batch, and read the target final state log information of the corresponding transaction batch from the disk;
[0121] Compare the transaction data with the target final state log information item by item to determine whether the transaction status of each transaction in the transaction data is consistent with the transaction status in the corresponding final state log information;
[0122] In the case where the transaction status of any transaction data in the transaction data is inconsistent with the transaction status in the corresponding final state log information, record that there is an abnormality in this transaction data.
[0123] The above is as in this application Figure 1The method executed by the transaction status verification device disclosed in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, the steps of the above method can be completed through the integrated logic circuit of the hardware in the processor or instructions in software form. The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in combination with the embodiments of the present application can be directly embodied as being executed and completed by a hardware decoding processor, or completed by a combination of the hardware and software modules in the decoding processor. The software module can be located in a mature storage medium in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. This storage medium is located in the memory, and the processor reads the information in the memory and combines its hardware to complete the steps of the above method.
[0124] The embodiments of the present application also propose a computer-readable storage medium that stores one or more programs. The one or more programs include instructions that, when executed by an electronic device including multiple application programs, can enable the electronic device to execute Figure 1 the method executed by the transaction status verification device in the illustrated embodiment, and specifically used to execute the transaction status verification method provided in the embodiments of the present application.
[0125] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0126] This application is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate a means for implementing the functions specified in one process Figure 1 one process or multiple processes and / or blocks Figure 1 or a means for implementing the functions specified in multiple blocks.
[0127] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing devices to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including an instruction means that implements the functions specified in one process Figure 1 one process or multiple processes and / or blocks Figure 1 or a means for implementing the functions specified in multiple blocks.
[0128] These computer program instructions can also be loaded onto a computer or other programmable data processing devices, such that a series of operation steps are executed on the computer or other programmable devices to generate a computer-implemented process, so that the instructions executed on the computer or other programmable devices provide steps for implementing the functions specified in one process Figure 1 one process or multiple processes and / or blocks Figure 1 or a means for implementing the functions specified in multiple blocks.
[0129] It should be noted that each embodiment in this application is described in a related manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for the apparatus embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can refer to the partial description of the method embodiment.
[0130] It should also be noted that the term "comprising", "including", or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, commodity, or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or elements inherent to such a process, method, commodity, or device. Without further limitation, an element defined by the statement "including one..." does not exclude the existence of another identical element in the process, method, commodity, or device including the element.
[0131] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, various modifications and changes can be made to the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the scope of the claims of the present application.
Claims
1. A transaction status verification method, characterized in that, The method includes: During the process of a target application executing a transaction, if the transaction reaches a preset final state, print the final state log information and store it on disk, and store the transaction data in a database; Under the condition of meeting a preset trigger condition, read target transaction data from the database by transaction batch, and read the target final state log information of the corresponding transaction batch from the disk; Compare the transaction data with the target final state log information item by item to determine whether the transaction status of each transaction in the transaction data is consistent with the transaction status in the corresponding final state log information; In the case where the transaction status in any one of the transaction data is inconsistent with the transaction status in the corresponding final state log information, record that there is an abnormality in this transaction data.
2. The method according to claim 1, characterized in that, The target application includes multiple applications of a transaction platform. Among them, during the process of the target application executing a transaction, if the transaction reaches a preset final state, printing the final state log information and storing it on disk includes: During the process of the multiple applications executing a transaction, if the transaction reaches the corresponding preset final state, print the final state log information respectively to obtain multiple copies of final state log information; Merge the multiple copies of final state log information and store them on disk.
3. The method according to claim 2, wherein Among them, The transaction platform is a network clearing platform; The multiple applications include: an online transaction application, a compensation transaction application, and a customs declaration application; The multiple copies of final state log information include: online final state log information, compensation final state log information, and customs declaration final state log information.
4. The method according to claim 1, wherein The disk is located in the server corresponding to the target application.
5. The method according to claim 1, wherein The preset trigger condition includes: Reaching the scheduled time of a preset scheduled verification task.
6. The method according to claim 1, wherein The method further includes: Collect the final state log information from the disk; Extract the transaction data from the database; Collect the collected final state log information and the extracted transaction data by transaction batch to a big data platform.
7. The method according to any one of claims 1-6, characterized in that, The method further includes: Alarm for the transaction data with abnormalities.
8. The method according to any one of claims 1-6, characterized in that, The final state log information includes at least one of the following: Transaction batch number; Transaction initiator number; Transaction serial number; Transaction category; Transaction final state.
9. A transaction status verification device, characterized in that, The device includes: A data storage module, used for during the process of a target application executing a transaction, if the transaction reaches a preset final state, print the final state log information and store it on disk, and store the transaction data in a database; A data reading module, used for under the condition of meeting a preset trigger condition, read target transaction data from the database by transaction batch, and read the target final state log information of the corresponding transaction batch from the disk; A status verification module, used for comparing the transaction data with the target final state log information item by item to determine whether the transaction status of each transaction in the transaction data is consistent with the transaction status in the corresponding final state log information; An abnormality recording module, used for in the case where the transaction status in any one of the transaction data is inconsistent with the transaction status in the corresponding final state log information, record that there is an abnormality in this transaction data.
10. An electronic device, including: A processor; And A memory arranged to store computer-executable instructions that, when executed, cause the processor to perform the following operations: During the execution of a transaction by a target application, if the transaction reaches a preset final state, print the final state log information and store it on disk, and store the transaction data in a database; Under the condition of meeting a preset trigger condition, read target transaction data from the database by transaction batch, and read the target final state log information of the corresponding transaction batch from the disk; Compare the transaction data with the target final state log information item by item to determine whether the transaction status of each transaction in the transaction data is consistent with the transaction status in the corresponding final state log information; If the transaction status in any transaction data in the transaction data is inconsistent with the transaction status in the corresponding final state log information, record that there is an abnormality in this transaction data.
11. A computer-readable storage medium storing one or more programs that, when executed by an electronic device including a plurality of application programs, cause the electronic device to perform the following operations: During the execution of a transaction by a target application, if the transaction reaches a preset final state, print the final state log information and store it on disk, and store the transaction data in a database; Under the condition of meeting a preset trigger condition, read target transaction data from the database by transaction batch, and read the target final state log information of the corresponding transaction batch from the disk; Compare the transaction data with the target final state log information item by item to determine whether the transaction status of each transaction in the transaction data is consistent with the transaction status in the corresponding final state log information; If the transaction status in any transaction data in the transaction data is inconsistent with the transaction status in the corresponding final state log information, record that there is an abnormality in this transaction data.