A transaction processing method, apparatus, device and medium

Abstract

The present application relates to the technical field of data processing, and particularly relates to a transaction processing method and device, equipment and medium. It can be applied to the financial scene of electronic payment. In the present application, transaction request information of a to-be-processed transaction is acquired, the transaction request information comprising a request serial number, a request system identifier and transaction detail information; the transaction detail information is parsed to extract a transaction identifier, a transaction number, a merchant identifier, a business type and a business module code of the to-be-processed transaction; a detail anti-duplicate key is constructed according to the transaction identifier, the transaction number, the merchant identifier, the business type and the business module code, a request anti-duplicate key is constructed according to the request serial number, the request system identifier and the business module code, and the two kinds of anti-duplicate keys are fused for database anti-duplicate verification. The method can simultaneously cover the duplicate verification scene of the transaction dimension and the request dimension, avoid the missed judgment and misjudgment of single dimension verification, effectively prevent the repeated transactions from falling into the database, and improve the accuracy of transaction processing.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a transaction processing method, apparatus, device, and medium. Background Technology

[0002] With the deep integration of internet technology and the financial payment industry, electronic transactions have permeated various online and offline scenarios, becoming a core form of transaction in market economic activities. As a core process of electronic transaction systems, order processing is responsible for receiving, verifying, confirming, and subsequently transferring transaction data. Its accuracy and efficiency directly affect the legitimate rights and interests of both parties, the stability of the transaction order, and the overall reliability of the transaction system.

[0003] Currently, the scale of electronic transactions continues to expand, and transaction scenarios are becoming increasingly complex. The situation where a single transaction request contains multiple transaction details is becoming more and more common, placing higher demands on anti-duplicate mechanisms in transaction order processing. As a key technology for ensuring the uniqueness of transactions in order processing, the core function of the anti-duplicate mechanism is to prevent the same transaction or transaction details from being repeatedly initiated and processed, thereby preventing problems such as accounting chaos, abnormal funds, and waste of resources. In existing electronic transaction systems, most anti-duplicate mechanisms only use the transaction request serial number as the sole basis for verification, performing single-point anti-duplicate judgment only on the entire transaction request. When the same transaction request is submitted repeatedly, or transaction details are split and repeatedly initiated, traditional anti-duplicate mechanisms cannot effectively identify this, resulting in low accuracy in transaction processing. Therefore, how to improve the accuracy of transaction processing in multi-detail transaction scenarios has become an urgent technical problem to be solved. Summary of the Invention

[0004] This invention provides a transaction processing method, apparatus, device, and medium to solve the problem of low accuracy in transaction processing in scenarios with multiple detailed transactions.

[0005] Firstly, a transaction processing method is provided, the transaction processing method comprising: Obtain the transaction request information of the pending transaction, wherein the transaction request information includes the request serial number, the request system identifier, and the transaction details; The transaction details are parsed to extract the transaction identifier, transaction number, merchant identifier, business type, and business module code of the transaction to be processed. A detailed anti-duplicate key is constructed based on the transaction identifier, the transaction number, the merchant identifier, the business type, and the business module code; a request anti-duplicate key is constructed based on the request serial number, the request system identifier, and the business module code. The detail anti-duplicate key and the request anti-duplicate key are merged to obtain a merged anti-duplicate key. The merged anti-duplicate key is then subjected to database anti-duplicate verification to obtain the database anti-duplicate verification result. If the database anti-duplicate verification result is successful, the transaction to be processed will be written to the database.

[0006] Secondly, a transaction processing apparatus is provided, the transaction processing apparatus comprising: The acquisition module is used to acquire transaction request information of the transaction to be processed, including the request serial number, the request system identifier, and transaction details. The parsing module is used to parse the transaction details information and extract the transaction identifier, transaction number, merchant identifier, business type and business module code of the transaction to be processed; The construction module is used to construct a detailed anti-duplicate key based on the transaction identifier, the transaction number, the merchant identifier, the business type and the business module code, and to construct a request anti-duplicate key based on the request serial number, the request system identifier and the business module code; The fusion module is used to fuse the detail anti-duplicate key and the request anti-duplicate key to obtain the fused anti-duplicate key, and to perform database anti-duplicate verification on the fused anti-duplicate key to obtain the database anti-duplicate verification result. The database write-in module is used to write the transaction to the database if the database anti-duplicate verification result is successful.

[0007] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the transaction processing method described above.

[0008] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the transaction processing method described above.

[0009] This application obtains transaction request information for pending transactions, including request serial number, request system identifier, and transaction details. The transaction details are parsed to extract the transaction identifier, transaction number, merchant identifier, business type, and business module code of the pending transaction. A detailed anti-duplicate key is constructed based on the transaction identifier, transaction number, merchant identifier, business type, and business module code; a request anti-duplicate key is constructed based on the request serial number, request system identifier, and business module code. These two anti-duplicate keys are then merged for database anti-duplicate verification. This approach simultaneously covers duplicate verification scenarios at both the transaction and request dimensions, avoiding missed or false judgments that may occur with single-dimensional verification. It effectively prevents duplicate transactions from being stored in the database, improves the accuracy of transaction processing, and can be widely applied in fintech scenarios. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of an application environment for a transaction processing method according to an embodiment of the present invention; Figure 2 This is a schematic flowchart of a transaction processing method provided in an embodiment of the present invention; Figure 3 yes Figure 2 A flowchart illustrating a specific implementation method following step S22; Figure 4 yes Figure 2 Another flowchart illustrating a specific implementation method following step S22; Figure 5 yes Figure 2 Another flowchart illustrating a specific implementation method following step S22; Figure 6 yes Figure 2 A flowchart illustrating a specific implementation of step S23; Figure 7 yes Figure 2 Another flowchart illustrating a specific implementation of step S23; Figure 8 yes Figure 2 A flowchart illustrating a specific implementation method following step S25; Figure 9 This is a schematic diagram of a transaction processing device according to an embodiment of the present invention; Figure 10This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0012] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0013] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0014] It should also be understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0015] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0016] Furthermore, in the description of this invention and the appended claims, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0017] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of the invention include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0018] It should be understood that the sequence number of each step in the following embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0019] To illustrate the technical solution of the present invention, specific embodiments are described below.

[0020] The transaction processing method provided in one embodiment of the present invention can be applied to, for example, Figure 1 In this application environment, the client communicates with the server via a network. The server can be a server cluster consisting of one or more servers, used to receive transaction request information sent by the client, parse the transaction details to obtain the transaction identifier, transaction number, merchant identifier, and business type, query the transaction number, and if the transaction number already exists, construct an anti-duplicate key based on the merchant identifier, business type, and transaction number, perform anti-duplicate verification on the anti-duplicate key, and obtain the anti-duplicate verification result. If the anti-duplicate verification result is successful, obtain the business module code corresponding to the transaction details, construct a detail anti-duplicate key based on the transaction identifier, transaction number, merchant identifier, business type, and business module code, construct a request anti-duplicate key based on the request serial number, request system identifier, and business module code, perform database anti-duplicate verification on the detail anti-duplicate key and request anti-duplicate key, and obtain the database anti-duplicate verification result. If the database anti-duplicate verification result is successful, the transaction is written to the database, and the transaction write-to-database response is fed back to the client. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will now be described in detail through specific embodiments.

[0021] Please see Figure 2 , Figure 2 A flowchart of a transaction processing method provided in an embodiment of the present invention includes the following steps S21, S22, S23, S24, and S25.

[0022] S21: Obtain the transaction request information of the pending transaction. The transaction request information includes the request serial number, the request system identifier, and the transaction details.

[0023] In step S21, the transaction request information is the raw data received by the server from the terminal device or other access system to trigger the transaction processing flow. The request serial number is a global sequence number that uniquely identifies this transaction request information. The request system identifier is an encoding used to identify the identity of the upstream system that sent the transaction request information. The transaction details information contains the specific content of this transaction, such as the transaction type, transaction amount, account information of both parties, transaction timestamp, description of goods or services, and other key business data.

[0024] In this embodiment, the transaction processing method can be applied to financial payment scenarios, such as e-commerce platform shopping payments, offline merchant QR code payments, and interpersonal money transfers. In the e-commerce platform shopping payment scenario, after a user places an order and confirms payment on the platform, the terminal device will send a transaction request containing a request serial number, a request system identifier, and transaction details to the server.

[0025] The system retrieves transaction request information for pending transactions. This information includes a request serial number, a request system identifier, and transaction details. This information can be received via API interfaces, message queues, or file import. For example, in a payment scenario, the pending transaction might be a payment request initiated by a user after selecting goods on an e-commerce platform. The terminal device sends the integrated transaction request information to the transaction server via a pre-defined API interface. The server can then extract the unique request serial number identifying the payment request, the request system identifier identifying the e-commerce platform, and the transaction details including the transaction identifier, transaction number, merchant identifier, business type, and business module code. The request serial number can be a globally unique string in UUID format, such as "a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8," and the request system identifier is the system code of a delivery system, "PAY-EC-2026." The transaction identifier is “T202604231528001”, the transaction order number is “OD202604231528001”, the merchant identifier is “MCH2026001”, the business type is “PAYMENT”, and the business module code is “ECOMMERCE”.

[0026] It should be noted that after obtaining the transaction request information of the transaction to be processed, the process also includes: performing non-empty verification on the request serial number, the request system identifier, and the transaction details information to obtain the verification results of the request serial number, the request system identifier, and the transaction details information; if the verification results of the request serial number, the request system identifier, and the transaction details information are all successful, then the transaction details information is parsed.

[0027] In this embodiment, when performing a non-empty check on the request serial number, it can be determined whether it is an empty string or a null value. If it is empty, the check result for the request serial number is determined to be a failure. When performing a non-empty check on the request system identifier, it can be determined whether it is an empty string or a null value. If it is empty, the check result for the request system identifier is determined to be a failure.

[0028] When performing non-empty validation on transaction details, it's possible to determine whether the fields in the transaction details information conform to preset field rules. This includes checking if the field type matches a preset type, if the field value is within a preset range, and if the field format conforms to a preset standard. For example, if the actual data for the "Transaction Amount" field is "1234.56," which is a decimal, but the preset type is integer, then the field type does not conform to the preset type. If the actual data is "1234," then the field type is integer and conforms to the preset type. Similarly, if the value of the "Transaction Amount" field is "5000," and its preset range is "0 to 10000," then the field value is within the preset range. Furthermore, if the format of the "Transaction Date" field is "2025 / 02 / 19," and its preset standard is YYYY-MM-DD, then the field format does not conform to the preset standard. If the "Transaction Date" field is formatted as "2025-02-19," then the field format conforms to the preset standard "YYYY-MM-DD." If the fields of the transaction details information meet the preset field rules, the transaction details information verification result is determined to be successful; otherwise, it is determined to be a verification failure.

[0029] By performing non-empty checks on the request serial number, request system identifier, and transaction details, illegal requests that do not meet the basic requirements can be intercepted early in the transaction processing flow, thus avoiding subsequent invalid business processing.

[0030] In this embodiment, the transaction request information includes a request serial number, a request system identifier, and transaction details. The request serial number serves as a globally unique sequence number, ensuring the traceability and uniqueness of each transaction request and effectively preventing duplicate transaction processing. The request system identifier clearly identifies the initiator of the transaction, facilitating the server's differentiated management of transactions from different upstream systems. The transaction details form the business foundation for transaction processing, enabling the server to accurately understand the transaction intent. This structured approach to obtaining transaction request information ensures the integrity and accuracy of transaction data.

[0031] S22: Parse the transaction details and extract the transaction identifier, transaction number, merchant identifier, business type, and business module code of the transaction to be processed.

[0032] In step S22, parsing the transaction details is to extract structured fields, including transaction identifier, transaction number, merchant identifier, business type, and business module code. The transaction identifier is a unique identifier generated internally by the transaction system to uniquely identify the business attributes of each pending transaction. The transaction number is a unique business voucher number generated by the upstream system corresponding to the transaction, facilitating transaction reconciliation and related queries between upstream and downstream systems. The merchant identifier is the unique identity code of the merchant initiating the transaction in the system, used to locate merchant information. The business type clarifies the business scope to which the transaction belongs, including the major and minor business categories. The business module code is a unique identifier for the functional module.

[0033] In this embodiment, the transaction details information is split into multiple independent basic data units according to a preset transaction data protocol. For each basic data unit, regular expressions are used to perform pattern matching to identify the values ​​of the fields corresponding to the transaction identifier, transaction number, merchant identifier, business type, and business module code, thereby obtaining the transaction identifier, transaction number, merchant identifier, business type, and business module code of the transaction to be processed.

[0034] For example, in an e-commerce platform shopping payment scenario, parsing the transaction details can yield a transaction identifier such as "PAY_EC_20260417", a transaction number of "EC202604171528001234", a merchant identifier of "MCH_88902376", a business type of "online product purchase", and a business module code that can be a payment settlement code, etc.

[0035] In this embodiment, the unstructured transaction details are split into multiple independent basic data units by using a preset transaction data protocol. Regular expressions are used to perform pattern matching on each basic data unit, which can efficiently and accurately identify and extract the values ​​of core structured fields such as transaction identifier, transaction number, merchant identifier, business type and business module code, thereby improving the automation and processing efficiency of the entire transaction processing flow.

[0036] Among them, such as Figure 3 As shown, after step S22, that is, after parsing the transaction details and extracting the transaction identifier, transaction number, merchant identifier, business type and business module code of the transaction to be processed, the following steps are included: S31: Check if the transaction number already exists. If the transaction number already exists, construct a duplicate key for the transaction number based on the merchant identifier, business type, and transaction number. S32: Perform anti-duplicate verification on the single-number anti-duplicate key to obtain the anti-duplicate verification result; S33: If the order number anti-duplicate verification result is successful, then construct the detailed anti-duplicate key based on the transaction identifier, transaction order number, merchant identifier, business type and business module code, and construct the request anti-duplicate key based on the request serial number, request system identifier and business module code.

[0037] In this embodiment, checking whether the transaction number already exists is to avoid situations where there are multiple one-to-one transaction numbers, i.e., multiple transaction details correspond to one transaction number. If the transaction number already exists, an anti-duplicate key is constructed based on the merchant identifier, business type, and transaction number. The anti-duplicate key is then validated to obtain the anti-duplicate verification result. The anti-duplicate key is composed of information from three dimensions: merchant identifier, business type, and transaction number. It is used to uniquely identify transaction number records to prevent the same transaction number from being mistakenly identified as the same transaction by different merchants and different business types.

[0038] In this embodiment, the system checks whether the transaction number already exists. This involves quickly comparing historical records using a distributed cache or database index. If the transaction number already exists, a unique key is constructed based on the merchant identifier, business type, and transaction number. This key is then validated against duplicate transaction records to obtain the validation result. When constructing the unique key, a standardized concatenation format of "MCH_{Merchant Identifier}_BUS_{Business Type}_SN_{Transaction Number}" can be used to ensure key uniqueness and traceability. During validation, the transaction amounts of transactions with the same unique key are summed. This sum is then compared to a configured many-to-one amount. If the sum equals the configured many-to-one amount, the validation is considered successful; otherwise, it is considered a failure. If the order number anti-duplicate verification result is successful, a detailed anti-duplicate key is constructed based on the transaction identifier, transaction order number, merchant identifier, business type, and business module code. A request anti-duplicate key is constructed based on the request serial number, request system identifier, and business module code. The detailed anti-duplicate key is composed of multiple dimensions of information, including the transaction identifier, merchant identifier, transaction order number, business type, and business module code, and is used to uniquely identify a transaction detail record to prevent the same transaction detail from being processed repeatedly in different scenarios. The request anti-duplicate key is composed of three dimensions of information: request serial number, request system identifier, and business module code, and is used to uniquely identify a single transaction request operation to prevent the same request from being submitted and executed repeatedly at different times or in different processing stages.

[0039] In this embodiment, a standardized order number anti-duplicate key is constructed based on merchant identifier, business type and transaction order number. Combined with the order number anti-duplicate verification method that compares the accumulated amount with the configured many-to-one amount, it can accurately identify scenarios where multiple transactions correspond to the same transaction order number, effectively avoid the incorrect accumulation or omission of transaction amount due to duplicate order numbers, and ensure the accuracy and consistency of transaction data.

[0040] Among them, such as Figure 4 As shown, after step S22, that is, after parsing the transaction details and extracting the transaction identifier, transaction number, merchant identifier, business type and business module code of the transaction to be processed, the following steps are included: S41: After confirming that the order number anti-duplicate verification result is successful, construct a merchant tag verification object based on the request system identifier, merchant identifier, and business type; S42: Perform tag verification on the merchant tag verification object and obtain the tag verification result; S43: If the tag verification result is successful, then construct a detailed anti-duplicate key based on the transaction identifier, transaction number, merchant identifier, business type and business module code, and construct a request anti-duplicate key based on the request serial number, request system identifier and business module code.

[0041] In this embodiment, after confirming that the order number anti-duplicate verification result is successful, a merchant tag verification object is constructed based on the request system identifier, merchant identifier, and business type. When constructing the merchant tag verification object, a hash algorithm can be used to combine and encode the three elements to generate a unique merchant tag key. This merchant tag key is then used as the merchant tag verification object. Specifically, when using a hash algorithm to combine and encode the three elements, the request system identifier, merchant identifier, and business type are concatenated into a string in a fixed order. This string is then subjected to a SHA-256 hash operation to obtain a 64-bit hexadecimal hash value, which is the merchant tag key.

[0042] When performing tag verification on a merchant tag verification object, the merchant tag verification object is compared with the merchant tag objects in the preset cache. If a match is found, the verification passes; otherwise, an exception alarm is triggered and subsequent processes are terminated. If the tag verification result is successful, a detailed anti-duplicate key is constructed based on the transaction identifier, transaction number, merchant identifier, business type, and business module code. A request anti-duplicate key is constructed based on the request serial number, request system identifier, and business module code.

[0043] In this embodiment, by pre-constructing merchant tag verification objects targeting the request source, merchant, and business dimensions, legitimacy verification is completed early in the transaction processing flow. This allows for the early interception of illegal transaction requests, significantly reducing the consumption of system resources by invalid computations and improving the processing efficiency of legitimate transactions. Simultaneously, a unique merchant tag key is generated using a hash algorithm, enabling verification to be completed simply by comparing hash values, further enhancing verification efficiency.

[0044] Among them, such as Figure 5 As shown, after step S22, that is, after parsing the transaction details and extracting the transaction identifier, transaction number, merchant identifier, business type and business module code of the transaction to be processed, the following steps are included: S51: Build a wash order configuration cache key based on merchant identifier and business type; S52: Based on the wash order configuration cache key, query the corresponding wash order configuration from the preset cache. The wash order configuration includes the configuration mode. S53: Determine whether the order washing configuration is a valid order washing configuration. If it is a valid order washing configuration, match the corresponding order washing rules according to the configuration mode and execute the order washing operation according to the order washing rules. S54: After completing the wash operation, construct the wash result object, which includes whether the wash operation was successful, whether the transaction was cancelled, and a reference to the original transaction details. S55: After constructing the transaction result object, construct detailed anti-duplicate keys based on the transaction identifier, transaction number, merchant identifier, business type, and business module code, and construct request anti-duplicate keys based on the request serial number, request system identifier, and business module code.

[0045] In this embodiment, when constructing the wash transaction configuration cache key based on the merchant identifier and business type, the merchant identifier and business type are concatenated in the format "MID_BIZTYPE", such as "M123456789_PAYMENT", as the unique identifier of the wash transaction configuration cache key. Based on the wash transaction configuration cache key, the corresponding wash transaction configuration is queried from the preset cache. The wash transaction configuration includes configuration modes. The wash transaction configuration is a standardized data set obtained through the preset cache to guide various transaction wash transaction operations. The configuration mode is the core classification standard of the wash transaction rules determined based on the wash transaction configuration, including date switching mode and transaction cancellation mode.

[0046] It should be noted that the transaction cleanup configuration also includes source merchant identifier, source business type, target merchant identifier, target business type, and effective date. Among them, the source merchant identifier and source business type are the merchant identifier and business type in the transaction details information, and the target merchant identifier and target business type are the target values ​​to be replaced by the source merchant identifier and source business type.

[0047] When determining whether a transaction washout configuration is valid, the system checks if it contains all core fields. These core fields include the source merchant ID, source business type, target merchant ID, target business type, configuration mode, and effective date. If all core fields are present, the configuration is considered valid; otherwise, it is considered invalid.

[0048] If the transaction washout configuration is valid, the corresponding washout rules are matched according to the configuration mode, and the washout operation is executed according to the rules. When the configuration mode is date switching mode, the current system date is obtained and compared with the effective date in the washout configuration. The washout operation is only executed if the current system date is greater than or equal to the effective date. When the configuration mode is transaction cancellation mode, the merchant identifier and business type in the transaction details are matched and verified with the source merchant identifier and source business type in the washout configuration. If the verification is successful, the washout operation is executed.

[0049] When performing a transaction cleansing operation, the source merchant identifier and source business type in the transaction details are replaced with the corresponding target merchant identifier and target business type in the transaction cleansing configuration. After the transaction cleansing operation is completed, a transaction cleansing result object is constructed. The transaction cleansing result object includes whether the transaction cleansing was successful, whether the transaction was canceled, and a reference to the original transaction details. The value for whether the transaction cleansing was successful is "yes" or "no," where "yes" indicates that the transaction matched the transaction cleansing configuration and the transaction cleansing operation was completed, and "no" indicates that the transaction cleansing configuration was not matched or the transaction cleansing operation was not performed. The value for whether the transaction was canceled is "yes" or "no," depending on the mode of the transaction cleansing configuration. The cancel transaction mode has a value of "yes," and the date switching mode has a value of "no." The reference to the original transaction details is used to associate the original details of the transaction to be cleaned, containing core information of the original transaction, such as the original transaction number, source merchant identifier, source business type, and transaction amount, enabling traceability of the transaction chain before and after the transaction cleansing.

[0050] After constructing the transaction result object, a detailed anti-duplicate key is built based on the transaction identifier, transaction number, merchant identifier, business type, and business module code. A request anti-duplicate key is built based on the request serial number, request system identifier, and business module code.

[0051] In this embodiment, a wash transaction operation is performed, and a wash transaction result object is constructed. Based on the wash transaction result object, a detailed anti-duplicate key and a request anti-duplicate key are constructed. Specifically, anti-duplicate construction is performed on pending transactions whose wash transaction hit value is "yes" to reduce invalid verification operations and improve verification efficiency.

[0052] By accurately replacing the source merchant identifier and source business type in the transaction details with the target value, the consistency of the transaction context and the integrity of the business logic are ensured, thus guaranteeing the traceability and compliance of the transaction data.

[0053] S23: If the order number anti-duplicate verification result is successful, obtain the business module code corresponding to the transaction details information, construct the detail anti-duplicate key based on the transaction identifier, transaction order number, merchant identifier, business type and business module code, and construct the request anti-duplicate key based on the request serial number, request system identifier and business module code.

[0054] In step S23, the business module code serves as a unique identifier for the functional module. A detailed anti-duplicate key is constructed based on the transaction identifier, transaction number, merchant identifier, business type, and business module code. This anti-duplicate key is a combination of multiple dimensions of information, including the transaction identifier, merchant identifier, transaction number, business type, and business module code, used to uniquely identify a transaction detail record and prevent the same transaction detail from being processed repeatedly in different scenarios. Similarly, a request anti-duplicate key is constructed based on the request serial number, request system identifier, and business module code. This anti-duplicate key is a combination of these three dimensions of information, used to uniquely identify a single transaction request operation, preventing the same request from being submitted and executed repeatedly at different times or in different processing stages.

[0055] In this embodiment, when constructing the detailed anti-duplicate key based on the transaction identifier, transaction number, merchant identifier, business type, and business module code, the fields can be concatenated into "DTL_{Transaction Identifier}_{Transaction Number}_{Merchant Identifier}_{Business Type}_{Business Module Code}". When constructing the request anti-duplicate key, it is concatenated into "REQ_{Request Serial Number}_{Request System Identifier}_{Business Module Code}". Through the standardized key-value structure, both the semantic clarity and traceability of the fields are ensured, and the efficiency and stability of key-value generation and comparison are improved.

[0056] In this embodiment, the detail anti-duplicate key is constructed based on transaction identifier, merchant identifier, transaction number, business type, and business module code. It can accurately identify duplicate transaction detail submissions by the same transaction entity in the same business scenario, effectively avoiding the risk of duplicate transaction execution due to identical transaction elements. The request anti-duplicate key is generated based on request serial number, request system identifier, and business module code. It can ensure that each specific transaction request operation has a unique identifier throughout the entire processing flow, preventing the same request from being submitted and processed multiple times at different time points or in different processing stages.

[0057] Among them, such as Figure 6 As shown, step S23, which involves constructing detailed anti-duplicate keys based on the transaction identifier, transaction number, merchant identifier, business type, and business module code, includes the following steps: S61: Dynamic disturbance factor for obtaining transaction details; S62: Divide the transaction identifier, transaction number, merchant identifier, business type and business module code into blocks to obtain the sequence transaction sub-block corresponding to the transaction identifier, the sequence order number sub-block corresponding to the transaction number, the sequence merchant sub-block corresponding to the merchant identifier, the sequence type sub-block corresponding to the business type and the sequence code sub-block corresponding to the business module code. S63: Cross-concatenate the transaction sub-block, order number sub-block, merchant sub-block, type sub-block, and code sub-block in the order to obtain the concatenated sub-block; S64: Combine the dynamic disturbance factor with the spliced ​​sub-blocks to obtain the detailed anti-duplicate key.

[0058] In this embodiment, a dynamic perturbation factor is obtained for transaction details. This dynamic perturbation factor is a millisecond-level random number or hash value generated with the timestamp, ensuring the uniqueness of anti-duplicate keys generated by the same input at different times. The transaction identifier, transaction number, merchant identifier, business type, and business module code are segmented into blocks, resulting in sequence transaction sub-blocks corresponding to the transaction identifier, sequence order number sub-blocks corresponding to the transaction number, sequence merchant sub-blocks corresponding to the merchant identifier, sequence type sub-blocks corresponding to the business type, and sequence code sub-blocks corresponding to the business module code. During segmentation, adaptive segmentation can be performed based on the length and semantic weight of each field. For example, the transaction identifier can be segmented by the first two and last six digits, the transaction number by year, month, day, hour, minute, and second, the merchant identifier by region code and main code, the business type by category and subcategory code, and the business module code by system layer and functional layer two-level identifiers. Other methods can also be used for segmentation; this example is not limited to the above segmentation methods.

[0059] The transaction sub-block, order number sub-block, merchant sub-block, type sub-block, and code sub-block are cross-concatenated in that order to obtain the concatenated sub-block. The cross-concatenation uses a polling-style bit-level interleaving strategy, that is, taking the first, second, and so on, up to the last bit, from each sub-block. If a sub-block is short of bits, it is padded with a preset padding character. For example, the first bit of the transaction sub-block is interleaved with the first bit of the order number sub-block, the first bit of the merchant sub-block, the first bit of the type sub-block, and the first bit of the code sub-block to form the first-level interleaving sequence; then the second bit of each sub-block is taken and the process is repeated until all sub-block bits are exhausted, resulting in the concatenated sub-block.

[0060] The dynamic perturbation factor is combined with the concatenated sub-blocks to obtain the detailed anti-duplicate key. For example, the millisecond-level timestamp hash value is embedded as a perturbation factor and concatenated with the concatenated sub-blocks at the string level to form the detailed anti-duplicate key.

[0061] In this embodiment, a polling-based bit-level interleaving strategy is used to splice multi-dimensional identifier sub-blocks, and a dynamic perturbation factor is combined to generate detailed anti-duplicate keys, which can effectively improve the complexity and uniqueness of anti-duplicate keys and enhance the reliability of transaction detail processing.

[0062] Among them, such as Figure 7 As shown, step S23, which involves constructing a request anti-duplicate key based on the request serial number, request system identifier, and business module code, includes the following steps: S71: Extract functional features from the business module code to obtain the module functional feature vector; S72: Concatenate the request serial number, the request system identifier, and the module function feature vector to obtain the request anti-duplicate key.

[0063] In this embodiment, functional features are extracted from the business module code to obtain a module functional feature vector. This extraction can be performed using a semantic encoding-based embedding model, mapping the module code to a high-dimensional dense vector. This vector represents the positional relationship of the business module code in the business semantic space. For example, "PAY-001" can be mapped to the vector [0.82, -0.41, 0.67, …], and "REFUND-002" to the vector [−0.35, 0.79, −0.12, …]. The semantic encoding-based embedding model can be a lightweight encoder based on the Transformer architecture, such as DistilBERT (Distilled Bidirectional Encoder Representations from Transformers) or TinyBERT (Tiny Bidirectional Encoder Representations from Transformers). Other models can also be used for functional feature extraction; this embodiment does not limit the specific model used.

[0064] The request serial number, request system identifier, and module function feature vector are concatenated to obtain the request anti-duplicate key. This concatenation process supports vector serialization compression, converting the module function feature vector into an encoded string of a preset length before concatenating it with the serial number and system identifier string. For example, the module function feature vector can be converted into a Base64 encoded string.

[0065] In this embodiment, by combining the functional semantic features of the business module itself to generate anti-duplicate keys, it is possible to more accurately distinguish duplicate requests initiated by different functional modules, thereby significantly reducing the false positive rate and false negative rate in distributed high-concurrency scenarios.

[0066] S24: Merge the detail anti-duplicate key and the request anti-duplicate key to obtain the merged anti-duplicate key, perform database anti-duplicate verification on the merged anti-duplicate key, and obtain the database anti-duplicate verification result.

[0067] In step S24, the detail anti-duplicate key and the request anti-duplicate key are merged. The merging process can employ hash concatenation or a weighted merging strategy. Database anti-duplicate verification checks whether a historical record exists in the database that completely matches the merged anti-duplicate key. The database anti-duplicate verification result includes verification success and verification failure.

[0068] In this embodiment, the detail anti-duplicate key and the request anti-duplicate key are merged. A SHA-256 hash function is used to perform a one-way mapping on the concatenated string results of the two keys, generating a fixed-length, irreversible 256-bit digest value. This digest value is then used as the merged anti-duplicate key. When performing database anti-duplicate verification on the merged key, an exact match query is performed in the database using this digest value as a unique index. If a corresponding record exists, the database anti-duplicate verification result is determined to be a failure; otherwise, it is considered a successful verification.

[0069] In this embodiment, anti-duplicate information is combined from two dimensions: the transaction request level and the transaction detail level. This can not only intercept scenarios where the same request submits details repeatedly, but also identify abnormal situations where the same transaction details are repeatedly inserted in different requests. At the same time, by generating a fixed-length summary value as a fusion anti-duplicate key, storage usage is reduced. Combined with a unique index for precise matching queries, the execution efficiency of database anti-duplicate verification is effectively improved.

[0070] S25: If the database anti-duplicate verification result is successful, then the transaction to be processed will be written to the database.

[0071] In step S25, the data storage process involves persistently writing the transaction details into the database.

[0072] In this embodiment, when the database anti-duplicate verification result is successful, the system writes the transaction details information into the transaction table according to the preset field structure and simultaneously generates a related transaction log record. During the writing process, the system adopts a transaction control mechanism to ensure that the data writing operations between the main transaction table and the transaction log table either all succeed or all fail, avoiding data inconsistencies.

[0073] In this embodiment, by introducing database anti-duplicate verification before the data is written to the database, especially by combining a dual verification mechanism of detail anti-duplicate keys and request anti-duplicate keys, the uniqueness of the transaction data can be strictly checked again before the transaction data is finally persisted, which effectively ensures the accuracy and consistency of the transaction data.

[0074] Among them, such as Figure 8 As shown, after step S25, that is, after the transaction to be processed is written to the database, the following steps are included: S81: Extract the details of transactions to be recorded from the transaction data stored in the database, and filter out the target transactions that meet the preset recording requirements; S82: For any target transaction, construct accounting details according to preset standards; S83: Validate the accounting details to determine if there are any valid details that need to be recorded. If there are valid details that need to be recorded, call the preset accounting interface to perform online accounting.

[0075] In this embodiment, after the transaction to be processed is stored in the database, the transaction details to be recorded are extracted from the stored transaction data. Target transactions that meet the preset recording requirements are selected, namely, transactions with actual fund transfers, successful execution, and no recording anomalies. For any target transaction, recording details are constructed according to preset standards. The recording details include at least the following parameters: transaction number, original transaction number, associated transaction number, transfer amount, business type, business subtype, transaction type, settlement date, business occurrence time, merchant tax rate, and designated merchant number. This ensures that all parameter information is complete, accurate, and consistent with the stored transaction data.

[0076] An intermediate parameter object is constructed to temporarily record relevant parameters during transaction processing. This object includes at least the transaction processing status of the transaction to be posted, the anti-duplicate verification result, and transaction cleanup configuration parameters. This ensures seamless integration between transaction data, transaction processing data, and posting data, preventing data gaps. The intermediate parameter objects are then batch-inserted into a pre-defined intermediate database or cache for batch temporary storage. This facilitates subsequent unified verification and filtering of parameters, improving posting processing efficiency and adapting to scenarios involving simultaneous processing of multiple transactions to be posted. The posting details are validated to determine if valid details exist. If valid details exist, a pre-defined financial posting interface is invoked to perform online posting, synchronizing the posting details to the financial ledger and generating compliant financial records. After the posting operation is completed, the posting result returned by the accounting posting interface is retrieved to determine success. If successful, the posting completion status is recorded, and the posting result is synchronized to the transaction management system and log system, completing the closed loop of this posting process. If the accounting process fails, the reason for the failure will be recorded, triggering a retry mechanism or manual intervention process to ensure that the accounting process is compliant and traceable.

[0077] In this application, transaction request information of pending transactions is obtained, including request serial number, request system identifier, and transaction details. The transaction details are parsed to extract the transaction identifier, transaction number, merchant identifier, business type, and business module code of the pending transaction. A detail anti-duplicate key is constructed based on the transaction identifier, transaction number, merchant identifier, business type, and business module code, and a request anti-duplicate key is constructed based on the request serial number, request system identifier, and business module code. The two anti-duplicate keys are then merged for database anti-duplicate verification. This approach can simultaneously cover duplicate verification scenarios at both the transaction and request dimensions, avoiding missed or false judgments that may occur with single-dimensional verification, effectively preventing duplicate transactions from being stored in the database, and improving the accuracy of transaction processing.

[0078] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0079] In one embodiment, a transaction processing apparatus is provided, which corresponds one-to-one with the transaction processing methods described in the above embodiments. For example... Figure 9 As shown, the transaction processing device 90 includes an acquisition module 91, a parsing module 92, a construction module 93, a fusion module 94, and a database storage module 95.

[0080] The acquisition module 91 is used to acquire the transaction request information of the transaction to be processed. The transaction request information includes the request serial number, the request system identifier, and the transaction details. The parsing module 92 is used to parse the transaction details and extract the transaction identifier, transaction number, merchant identifier, business type and business module code of the transaction to be processed; Module 93 is used to construct detailed anti-duplicate keys based on transaction identifier, transaction number, merchant identifier, business type and business module code, and to construct request anti-duplicate keys based on request serial number, request system identifier and business module code; The fusion module 94 is used to fuse the detail anti-duplicate key and the request anti-duplicate key to obtain the fused anti-duplicate key, and to perform database anti-duplicate verification on the fused anti-duplicate key to obtain the database anti-duplicate verification result. The database write-in module 95 is used to write the transaction to the database if the database anti-duplicate verification result is successful.

[0081] In one embodiment, the transaction processing apparatus 90 further includes: The query module is used to check whether the transaction number already exists. If the transaction number already exists, a duplicate key is constructed based on the merchant identifier, business type and transaction number. The first verification module is used to perform anti-duplicate verification on the single number anti-duplicate key and obtain the anti-duplicate verification result. The first execution module is used to construct a detailed anti-duplicate key based on the transaction identifier, transaction number, merchant identifier, business type and business module code if the anti-duplicate verification result is successful, and to construct a request anti-duplicate key based on the request serial number, request system identifier and business module code.

[0082] In one embodiment, the transaction processing apparatus 90 further includes: The second construction module is used to construct a merchant tag verification object based on the request system identifier, merchant identifier, and business type after determining that the order number anti-duplicate verification result is successful. The second verification module is used to perform tag verification on the merchant tag verification object and obtain the tag verification result. The second execution module is used to construct a detailed anti-duplicate key based on the transaction identifier, transaction number, merchant identifier, business type and business module code if the tag verification result is successful, and to construct a request anti-duplicate key based on the request serial number, request system identifier and business module code.

[0083] In one embodiment, the transaction processing apparatus 90 further includes: The third module is used to build a cache key for order washing configuration based on merchant identifier and business type. The second query module is used to query the corresponding wash order configuration from the preset cache based on the wash order configuration cache key. The wash order configuration includes the configuration mode. The matching module is used to determine whether the order washing configuration is a valid order washing configuration. If it is a valid order washing configuration, the corresponding order washing rule is matched according to the configuration mode, and the order washing operation is executed according to the order washing rule. The fourth module is used to construct a wash order result object after the wash order operation is completed. The wash order result object includes whether the wash order was hit, whether the transaction was canceled, and a reference to the original transaction details. The third execution module is used to construct the wash order result object, and then construct detailed anti-duplicate keys based on the transaction identifier, transaction number, merchant identifier, business type and business module code, and construct request anti-duplicate keys based on the request serial number, request system identifier and business module code.

[0084] In one embodiment, the construction module 93 is specifically used for: Dynamic disturbance factors for obtaining transaction details; The transaction identifier, transaction number, merchant identifier, business type and business module code are divided into blocks to obtain the sequence transaction sub-block corresponding to the transaction identifier, the sequence order number sub-block corresponding to the transaction number, the sequence merchant sub-block corresponding to the merchant identifier, the sequence type sub-block corresponding to the business type and the sequence code sub-block corresponding to the business module code. The concatenated sub-blocks are obtained by cross-concatenating the transaction sub-block, order number sub-block, merchant sub-block, type sub-block, and code sub-block in that order. The dynamic disturbance factor is combined with the spliced ​​sub-blocks to obtain the detailed anti-duplicate key.

[0085] In one embodiment, the construction module 93 is specifically used for: Functional features are extracted from the business module code to obtain the module functional feature vector; The request serial number, the request system identifier, and the module function feature vector are concatenated to obtain the request anti-duplicate key.

[0086] In one embodiment, the transaction processing apparatus 90 further includes: The assembly module is used to assemble accounting requests based on the preset accounting configuration table and transaction details. The update module is used to perform online accounting based on the accounting request. If the accounting is successful, the transaction status of the pending transaction is updated to success. If the accounting fails, the transaction status of the pending transaction is updated to failure. If the accounting returns to processing, the transaction status of the pending transaction is updated to processing.

[0087] It should be noted that the information interaction and execution process between the above-mentioned units are based on the same concept as the method embodiments of the present invention. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0088] Figure 10 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Figure 10 As shown, the computer device of this embodiment includes: at least one processor ( Figure 10 Only one is shown in the diagram), a memory, and a computer program stored in the memory and executable on at least one processor, wherein the processor executes the computer program to implement the steps in any of the above-described transaction processing method embodiments.

[0089] This computer device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that... Figure 10 The examples of computer devices are merely examples and do not constitute a limitation on computer devices. Computer devices may include more or fewer components than shown in the illustration, or combinations of certain components, or different components, such as network interfaces, displays, and input devices.

[0090] The processor referred to can be a CPU, but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0091] Memory includes non-volatile and / or volatile readable storage media, internal memory, etc., wherein internal memory may be the RAM of a computer device, providing an environment for the operation of the operating system and computer-readable instructions stored in the readable storage media. The readable storage media may be the hard disk of a computer device, or in other embodiments, it may be an external storage device of the computer device, such as a plug-in hard disk, a Smart MediaCard (SMC), a Secure Digital (SD) card, a Flash Card, etc., provided on the computer device. Furthermore, memory may include both internal storage units and external storage devices of the computer device. Memory is used to store the operating system, applications, bootloader, data, and other programs, such as program code of computer programs. Memory can also be used to temporarily store data that has been output or will be output.

[0092] Those skilled in the art will understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the functions described above can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this invention. The specific working process of the units and modules in the above device can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here. If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present invention can implement all or part of the processes in the methods of the above embodiments by instructing related hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the above method embodiments. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium can include at least: any entity or device capable of carrying computer program code, a recording medium, a computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0093] The present invention can implement all or part of the processes in the above embodiments of the method, or it can be accomplished by a computer program product. When the computer program product is run on a computer device, the computer device executes the steps in the above method embodiments.

[0094] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0095] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0096] In the embodiments provided by this invention, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

[0098] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0099] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A transaction processing method, characterized in that, The transaction processing method includes: Obtain the transaction request information of the pending transaction, wherein the transaction request information includes the request serial number, the request system identifier, and the transaction details; The transaction details are parsed to extract the transaction identifier, transaction number, merchant identifier, business type, and business module code of the transaction to be processed. A detailed anti-duplicate key is constructed based on the transaction identifier, the transaction number, the merchant identifier, the business type, and the business module code; a request anti-duplicate key is constructed based on the request serial number, the request system identifier, and the business module code. The detail anti-duplicate key and the request anti-duplicate key are merged to obtain a merged anti-duplicate key. The merged anti-duplicate key is then subjected to database anti-duplicate verification to obtain the database anti-duplicate verification result. If the database anti-duplicate verification result is successful, the transaction to be processed will be written to the database.

2. The transaction processing method as described in claim 1, characterized in that, After parsing the transaction details and extracting the transaction identifier, transaction number, merchant identifier, business type, and business module code of the transaction to be processed, the process further includes: Check if the transaction number already exists. If the transaction number already exists, construct a duplicate key for the transaction number based on the merchant identifier, the business type, and the transaction number. Perform a duplicate number verification on the duplicate number anti-duplicate key to obtain the duplicate number verification result. If the order number anti-duplicate verification result is successful, then the detailed anti-duplicate key is constructed based on the transaction identifier, the transaction order number, the merchant identifier, the business type and the business module code, and the request anti-duplicate key is constructed based on the request serial number, the request system identifier and the business module code.

3. The transaction processing method as described in claim 2, characterized in that, After parsing the transaction details and extracting the transaction identifier, transaction number, merchant identifier, business type, and business module code of the transaction to be processed, the process further includes: After confirming that the order number anti-duplicate verification result is successful, a merchant tag verification object is constructed based on the request system identifier, merchant identifier, and business type. Perform tag verification on the merchant tag verification object to obtain the tag verification result; If the tag verification result is successful, then a detailed anti-duplicate key is constructed based on the transaction identifier, the transaction number, the merchant identifier, the business type, and the business module code; and a request anti-duplicate key is constructed based on the request serial number, the request system identifier, and the business module code.

4. The transaction processing method as described in claim 1, characterized in that, After parsing the transaction details and extracting the transaction identifier, transaction number, merchant identifier, business type, and business module code of the transaction to be processed, the process further includes: Construct a wash order configuration cache key based on the merchant identifier and business type; Based on the order washing configuration cache key, the corresponding order washing configuration is queried from the preset cache, and the order washing configuration includes a configuration mode; Determine whether the order washing configuration is a valid order washing configuration. If it is a valid order washing configuration, match the corresponding order washing rule according to the configuration mode, and perform the order washing operation according to the order washing rule. After completing the wash order operation, a wash order result object is constructed. The wash order result object includes whether the wash order was hit, whether the transaction was canceled, and a reference to the original transaction details. After constructing the transaction result object, a detailed anti-duplicate key is constructed based on the transaction identifier, the transaction number, the merchant identifier, the business type, and the business module code. A request anti-duplicate key is constructed based on the request serial number, the request system identifier, and the business module code.

5. The transaction processing method as described in claim 1, characterized in that, The step of constructing detailed anti-duplicate keys based on the transaction identifier, the transaction number, the merchant identifier, the business type, and the business module code includes: The dynamic disturbance factor for obtaining the transaction details information; The transaction identifier, transaction number, merchant identifier, business type, and business module code are divided into blocks to obtain the sequence transaction sub-block corresponding to the transaction identifier, the sequence order number sub-block corresponding to the transaction number, the sequence merchant sub-block corresponding to the merchant identifier, the sequence type sub-block corresponding to the business type, and the sequence code sub-block corresponding to the business module code. The transaction sub-block, the order number sub-block, the merchant sub-block, the type sub-block, and the code sub-block are cross-concatenated in the order to obtain the concatenated sub-block; The dynamic disturbance factor is combined with the spliced ​​sub-blocks to obtain the detailed anti-duplicate key.

6. The transaction processing method as described in claim 1, characterized in that, The step of constructing a request anti-duplicate key based on the request serial number, the request system identifier, and the business module code includes: Functional features are extracted from the code of the business module to obtain the module functional feature vector; The request serial number, the request system identifier, and the module function feature vector are concatenated to obtain the request anti-duplicate key.

7. The transaction processing method as described in claim 1, characterized in that, After the transaction is written to the database, the process also includes: Extract the details of transactions to be recorded from the transaction data stored in the database, and filter out the target transactions that meet the preset recording requirements; For any target transaction, a detailed accounting record is constructed according to preset standards; The accounting details are verified to determine whether there are any valid details that need to be recorded. If there are valid details that need to be recorded, the preset accounting interface is called to perform online accounting.

8. A transaction processing apparatus, characterized in that, The transaction processing device includes: The acquisition module is used to acquire transaction request information of the transaction to be processed, including the request serial number, the request system identifier, and transaction details. The parsing module is used to parse the transaction details information and extract the transaction identifier, transaction number, merchant identifier, business type and business module code of the transaction to be processed; The construction module is used to construct a detailed anti-duplicate key based on the transaction identifier, the transaction number, the merchant identifier, the business type and the business module code, and to construct a request anti-duplicate key based on the request serial number, the request system identifier and the business module code; The fusion module is used to fuse the detail anti-duplicate key and the request anti-duplicate key to obtain the fused anti-duplicate key, and to perform database anti-duplicate verification on the fused anti-duplicate key to obtain the database anti-duplicate verification result. The database write-in module is used to write the transaction to the database if the database anti-duplicate verification result is successful.

9. A computer device, characterized in that, The computer device includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the transaction processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the transaction processing method as described in any one of claims 1 to 7.

Images