Blockchain-based E-commerce Transaction Verification System

Abstract

The present invention relates to the technical field of transaction verification, specifically an e-commerce transaction verification system based on blockchain. The system includes a transaction identity verification module, a fund flow monitoring module, an order payment status confirmation module, an abnormal transaction comparison module, and a risk control strategy adjustment module. In the present invention, through the use of timestamp, device identifier, hash calculation of user public key, and blockchain technology for identity verification, the accuracy of authorization or veto of transaction requests is ensured. The fund flow is dynamically monitored and trend analyzed, including the measurement of the fund flow path and the evaluation of the fund transfer change rate, effectively monitoring the stable flow of funds. By integrating multi-source data analysis, the ability to identify abnormal transactions is improved, the real-time and accuracy of risk management are enhanced, the security and transparency of transactions are improved, the ability to quickly respond to abnormal behaviors is enhanced, bringing a higher level of trust and security guarantee to users and platforms.

Description

Technical Field

[0001] The present invention relates to the technical field of transaction verification, and particularly to an e-commerce transaction verification system based on blockchain. Background Art

[0002] The technical field of transaction verification includes various methods and systems for ensuring the legality, integrity, and security of electronic transactions, including transaction identity authentication, transaction data signature, transaction traceability, transaction consistency verification, and anti-tampering mechanisms. This field involves cryptographic security protocols, identity authentication mechanisms, distributed ledger management, trusted execution environments, and multi-signature technologies, and combines technical means such as public key infrastructure PKI, zero-knowledge proof ZKP, and hash chains to achieve data verification. Transaction verification technology is widely used in financial payments, e-commerce, digital asset transactions, and other high-security transaction scenarios to ensure the validity of the identities of both trading parties, the integrity of transaction data, and the non-repudiation of data.

[0003] Among them, an e-commerce transaction verification system refers to a technical solution for ensuring the authenticity and reliability of orders, payments, logistics, and transaction-related data in online transaction scenarios. The system covers technical links such as order generation and encrypted storage, payment authorization and transaction signature, hash evidence storage of logistics tracking data, on-chain verification of transaction data, and automatic settlement of smart contracts. The system usually performs transaction identity authentication through a public-private key encryption mechanism, uses a Merkle tree structure and a block hash algorithm for data integrity verification, uses smart contracts to execute preset transaction verification rules, and combines multi-party secure computing technology to ensure transaction privacy.

[0004] Traditional systems have deficiencies in processing large-scale data and real-time transaction monitoring. In the face of complex and high-speed transaction scenarios, they will cause processing delays and data synchronization problems. For example, in a financial payment system, due to limitations in technical processing capabilities, it is unable to immediately identify and respond to rapidly changing fraud behaviors or abnormal fund flows. In user identity verification and transaction data consistency verification of traditional systems, they mostly rely on existing databases and predefined rules, which limits the flexibility and efficiency of the system in the face of new or complex fraud patterns, and may lead to incorrect risk assessments or misjudgments of normal transactions in actual operations, affecting the user experience and the overall security of the system. Summary of the Invention

[0005] The purpose of the present invention is to solve the deficiencies existing in the prior art, and to propose an e-commerce transaction verification system based on blockchain.

[0006] To achieve the above purpose, the present invention adopts the following technical solution: An e-commerce transaction verification system based on blockchain, the system includes:

[0007] The transaction identity authentication module obtains an e-commerce transaction verification request, performs a hash calculation on the transaction identity data, calls the user identity hash record stored in the blockchain, determines whether there is a match, and obtains a transaction identity matching result;

[0008] Based on the transaction identity matching result, the fund flow monitoring module obtains the payment transaction fund flow, calculates the fund flow trend, matches the fund flow stability, calculates the fund transfer change rate, and obtains the fund flow stability information;

[0009] Based on the fund flow stability information, the order payment status confirmation module obtains the payment transaction status, calculates the payment status deviation, determines the payment status synchronization situation, and obtains the payment status consistency comparison information;

[0010] Based on the payment status consistency comparison information, the abnormal transaction comparison module calls the fund flow path record, compares the changes in the transaction account and the cash withdrawal behavior within a short period of time, calculates the abnormal fund flow rate, and obtains the abnormal transaction comparison information;

[0011] Based on the abnormal transaction comparison information, the risk control strategy adjustment module calls the order risk data measurement, matches the transaction abnormality degree, evaluates the transaction risk level, determines whether it is necessary to execute transaction restriction measures, and obtains the order transaction verification information.

[0012] The improvements of the present invention are that the transaction identity matching result specifically includes an identity matching status, a transaction authorization status, and an identity hash comparison result; the fund flow stability information includes a fund path stability, a fund transfer change rate, and a historical transaction matching degree; the payment status consistency comparison information includes a payment data synchronization situation, an account confirmation status, and a payment platform feedback consistency; the abnormal transaction comparison information specifically includes an account transaction abnormality rate, a device transaction activity, and an abnormal distribution of fund withdrawals; and the order transaction verification information includes a transaction risk level, a restriction measure execution status, and an abnormal transaction mark.

[0013] The improvements of the present invention are that the transaction identity authentication module includes:

[0014] The identity information extraction sub-module obtains an e-commerce transaction verification request, calls the user public key, device identifier, transaction timestamp, and order amount, parses and extracts the user identity data, and obtains a transaction identity data set;

[0015] Based on the transaction identity data set, the identity hash calculation sub-module uses hash calculation to obtain a transaction identity hash value;

[0016] The identity matching judgment sub-module, based on the transaction identity hash value, calls the identity hash records stored in the blockchain, compares the transaction identity hash value with the identity hash records, and determines whether they match. If they match, the e-commerce transaction request is authorized; if they do not match, the e-commerce transaction request is rejected, and a transaction identity matching result is obtained.

[0017] The improvement of the present invention is that the fund flow monitoring module includes:

[0018] The fund flow extraction sub-module, based on the transaction identity matching result, obtains the fund flow of the payment transaction, calls the fund inflow account, transfer path, and fund splitting situation, extracts the fund transfer situation between accounts, organizes the transaction path, calculates the fund distribution ratio of each path, and obtains the fund flow path data;

[0019] The fund flow trend calculation sub-module, based on the fund flow path data, uses the formula:

[0020] ;

[0021] Performs operations to obtain the fund change rate and obtains the fund flow trend information;

[0022] Wherein, represents the fund change rate, represents the path at time of the fund amount, represents the fund amount at the previous time point, represents the adjacent time interval, represents the total number of transaction paths;

[0023] The fund flow stability evaluation sub-module, based on the fund flow trend information, calls the measurement of the transaction fund path, matches the fund flow stability, calculates the fund transfer change rate, determines the fund fluctuation range, and obtains the fund flow stability information.

[0024] The improvement of the present invention is that the order payment status confirmation module includes:

[0025] The payment information extraction sub-module, based on the fund flow stability information, obtains the payment transaction status, calls the feedback status of the payment platform, bank statement records, collection account confirmation records, and user payment vouchers, and analyzes the payment information data to obtain the payment status data set;

[0026] The payment status deviation calculation sub-module, based on the payment status data set, uses the formula:

[0027] ;

[0028] Performs operations to obtain the payment status deviation rate;

[0029] Among them, represents the payment status deviation rate, represents the status value returned by the payment platform, represents the status value of the bank statement record, represents the current transaction timestamp, represents the time average of the payment data, represents the number of payment records;

[0030] The payment synchronization situation judgment sub-module compares the payment status deviation rate with a preset deviation threshold to judge the payment status synchronization situation and obtains the payment status consistency comparison information.

[0031] The improvement of the present invention is that the abnormal transaction comparison module includes:

[0032] The multi-order payment status acquisition sub-module obtains the payment situations of multiple orders with the same device and IP address based on the payment status consistency comparison information, calls the fund flow path record, extracts the order payment data under the same device and IP address, screens the transaction records with close time intervals, and obtains the multi-order payment records;

[0033] The short-term account change comparison sub-module compares the transaction account change situation and the cash withdrawal behavior within a short time based on the multi-order payment records, calculates the account balance change rate, extracts the transaction frequency and cash withdrawal interval data, and obtains the account short-term transaction fluctuation information;

[0034] The abnormal fund flow rate calculation sub-module uses the formula based on the account short-term transaction fluctuation information:

[0035] ;

[0036] Performs an operation to obtain the abnormal fund flow ratio and obtains the abnormal transaction comparison information;

[0037] Among them, represents the abnormal fund flow ratio, represents the cycle the total number of transactions within, represents the cycle the total number of cash withdrawals within, represents the cycle the account balance at the end, represents the standard deviation of the transaction time interval, represents the standard deviation of the cash withdrawal time interval.

[0038] The improvement of the present invention is that the risk control strategy adjustment module includes:

[0039] Based on the abnormal transaction comparison information, the abnormal transaction matching sub-module calls the order risk data measurement, matches the degree of transaction abnormality, compares the abnormal transaction characteristics with the set transaction abnormality classification criteria, extracts the transaction abnormality category, and obtains the transaction abnormality classification information;

[0040] Based on the transaction abnormality classification information, the transaction risk level calculation sub-module uses the formula:

[0041] ;

[0042] Performs operations to obtain the transaction risk value and obtains the transaction risk level information;

[0043] Among them, represents the transaction risk value, represents the risk coefficient corresponding to the transaction abnormality category, represents the abnormal transaction frequency, represents the total transaction volume within the transaction time window, represents the transaction amount fluctuation range, represents the transaction amount benchmark value;

[0044] Based on the transaction risk level information, the transaction restriction determination sub-module determines whether the transaction risk value exceeds the set threshold. If it exceeds, the transaction is marked as high risk and transaction restriction measures are executed. If it does not exceed, the transaction proceeds normally and the order transaction verification information is obtained.

[0045] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0046] In the present invention, by using the hash calculation of the timestamp, device identifier, user public key and blockchain technology for identity verification, the accuracy of the authorization or veto of the transaction request is ensured, the fund flow is dynamically monitored and trend analyzed, including the measurement of the fund flow path and the evaluation of the fund transfer change rate, effectively monitoring the stable flow of funds, and accurately evaluating the consistency of the payment transaction status to ensure a high degree of consistency between the payment behavior and the system record. By integrating multi-source data analysis, the ability to identify transaction abnormalities is improved, the real-time and accuracy of risk management are enhanced, the security and transparency of transactions are improved, the ability to quickly respond to abnormal behaviors is enhanced, and a higher level of trust and security guarantee is brought to users and the platform. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 is the system flow chart of the present invention;

[0048] Figure 2 is the flow chart of the transaction identity verification module of the present invention;

[0049] Figure 3It is the flowchart of the fund flow monitoring module of the present invention;

[0050] Figure 4 It is the flowchart of the order payment status confirmation module of the present invention;

[0051] Figure 5 It is the flowchart of the abnormal transaction comparison module of the present invention;

[0052] Figure 6 It is the flowchart of the risk control strategy adjustment module of the present invention. Detailed implementation manners

[0053] In order to make the objectives, technical solutions and advantages of the present invention clearer and more understandable, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0054] In the description of the present invention, it should be understood that the orientation or positional relationships indicated by the terms "length", "width", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc. are based on the orientation or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and thus should not be construed as a limitation of the present invention. In addition, in the description of the present invention, "a plurality of" means two or more unless otherwise specifically defined.

[0055] Please refer to Figure 1 , the present invention provides a technical solution: an e-commerce transaction verification system based on blockchain, and the system includes:

[0056] The transaction identity verification module obtains an e-commerce transaction verification request, calls the user public key, device identifier, transaction timestamp, and order amount, performs a hash calculation on the transaction identity data to obtain a transaction identity hash value, calls the user identity hash record stored in the blockchain, and compares it with the transaction identity hash value to determine whether they match. If they match, the e-commerce transaction request is authorized; if they do not match, the e-commerce transaction request is rejected, and a transaction identity matching result is obtained;

[0057] Based on the transaction identity matching result, the fund flow monitoring module obtains the payment transaction fund flow, calls the fund inflow account, transfer path, and fund splitting situation, calculates the fund flow trend, calls the transaction fund path measurement, matches the fund flow stability, and calculates the fund transfer change rate to obtain the fund flow stability information;

[0058] The order payment status confirmation module obtains the payment transaction status based on the stable information of capital flow, calls the feedback status of the payment platform, bank statement records, collection account confirmation records and user payment vouchers, calculates the payment status deviation, judges the payment status synchronization situation, and obtains the payment status consistency comparison information;

[0059] The abnormal transaction comparison module obtains the payment situations of multiple orders with the same device and IP address based on the payment status consistency comparison information, calls the capital flow path records, compares the changes in the trading account and cash withdrawal behavior within a short period of time, calculates the abnormal capital flow rate, and obtains the abnormal transaction comparison information;

[0060] The risk control strategy adjustment module calls the order risk data measurement based on the abnormal transaction comparison information, matches the abnormal degree of the transaction, evaluates the transaction risk level, judges whether it is necessary to execute transaction restriction measures, and obtains the order transaction verification information.

[0061] The transaction identity matching result specifically includes the identity matching status, transaction authorization status and identity hash comparison result. The stable information of capital flow includes the capital path stability, capital transfer change rate and historical transaction matching degree. The payment status consistency comparison information includes the payment data synchronization situation, account confirmation status and payment platform feedback consistency. The abnormal transaction comparison information specifically includes the account transaction abnormal rate, device transaction activity and abnormal distribution of capital cash withdrawal. The order transaction verification information includes the transaction risk level, restriction measure execution status and abnormal transaction mark.

[0062] Please refer to Figure 2 , the transaction identity verification module includes:

[0063] The identity information extraction sub-module obtains the e-commerce transaction verification request, calls the user public key, device identifier, transaction timestamp, and order amount, parses and extracts the user identity data, and obtains the transaction identity data set;

[0064] After receiving an e-commerce transaction verification request, the identity information extraction sub-module parses the request data and extracts the user public key, device identifier, transaction timestamp, and order amount. Each piece of data is obtained through specific methods. For example, the user public key is sourced from the public key field in the user digital certificate, the device identifier can be based on the device unique identification code (such as IMEI or MAC address), the transaction timestamp is recorded by the system as the server time when the transaction occurs and stored in the standard UTC format, and the order amount is parsed from the payment amount field in the transaction request. During the parsing process, to ensure data accuracy, data format verification is required. For example, for the user public key, it should be detected whether it conforms to the RSA or ECC public key format, the device identifier should match the expected hexadecimal format, the transaction timestamp should ensure that its time format is synchronized with the server time, the order amount needs to be parsed into a floating point number and ensure that it is within a reasonable range, such as between 0.01 and 100000.00. After the data verification passes, the information is assembled into a transaction identity data set and stored in a temporary storage space. For example, a user conducts a transaction using the IMEI code "358240051111110", the transaction time is "2025-02-14T12:30:45Z", and the order amount is "99.99". Then the specific storage content of the transaction identity data set is {user public key: "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...", device identifier: "358240051111110", transaction timestamp: "2025-02-14T12:30:45Z", order amount: "99.99"}. After completing the data extraction, the transaction identity data set is returned as the input for subsequent processing.

[0065] Based on the transaction identity data set, the identity hash calculation sub-module obtains the transaction identity hash value by using hash calculation;

[0066] After receiving the transaction identity dataset, the identity hash calculation sub-module sequentially obtains the user public key, device identifier, transaction timestamp, and order amount, and generates a transaction identity hash value through hash calculation. Specifically, each field is standardized. For example, the transaction timestamp is converted to integer seconds, and the order amount is formatted to two decimal places. Then, all fields are concatenated in a fixed order, such as "user public key + device identifier + transaction timestamp + order amount". The concatenated string is used as the input for hash calculation. During the hash calculation process, the SHA-256 algorithm is used to calculate the data digest. The SHA-256 algorithm performs multiple rounds of bit operations, permutations, and merges on the input data to ensure the generation of a hash value with a fixed length. For example, for the sample data, if the hash part of the user public key is "ABC123" (actually longer), the concatenated string is "ABC1233582400511111102025021412304599.99". After performing SHA-256 calculation on this string, the resulting hash value is "5f4dcc3b5aa765d61d8327deb882cf99" (sample). This hash value will be stored as the transaction identity hash value and used as the input for subsequent identity matching judgment.

[0067] Based on the transaction identity hash value, the identity matching judgment sub-module calls the identity hash records stored in the blockchain, compares the transaction identity hash value with the identity hash records, and determines whether they match. If they match, the e-commerce transaction request is authorized; if they do not match, the e-commerce transaction request is rejected, and the transaction identity matching result is obtained.

[0068] After receiving the transaction identity hash value, the identity matching judgment sub-module calls the identity hash records stored in the blockchain, queries the historical records that match the transaction identity hash value, calls the blockchain node interface, retrieves the transaction records corresponding to the hash value, and uses binary search or hash indexing to improve the query efficiency. For example, it queries whether "5f4dcc3b5aa765d61d8327deb882cf99" exists in the data structure stored in the blockchain. If it matches, it means that this transaction identity already exists in the system's trusted identity list, and the system returns the matching result and authorizes the e-commerce transaction request. If no matching record is found, the system rejects the transaction request and records the reason for failure. As shown in Table 1, sample data for the transaction identity hash comparison is recorded, where "matching status" being "yes" indicates that the transaction is allowed, and "no" indicates that the transaction is rejected.

[0069] Table 1 Transaction Identity Hash Comparison Result Table:

[0070] ;

[0071] As shown in Table 1, the transaction identity hash value "5f4dcc3b5aa765d61d8327deb882cf99" matches the blockchain storage record, and the transaction request is authorized. However, the hash value "d41d8cd98f00b204e9800998ecf8427e" does not match, so the transaction is rejected. Finally, the transaction identity matching result is output.

[0072] Please refer to Figure 3 , the fund flow monitoring module includes:

[0073] Based on the transaction identity matching result, the fund flow extraction sub-module obtains the fund flow of payment transactions, calls the fund inflow account, transfer path, and fund splitting situation, extracts the fund transfer situation between accounts, organizes the transaction path, calculates the fund distribution ratio of each path, and obtains the fund flow path data;

[0074] After receiving the transaction identity matching result, the fund flow extraction sub-module calls the fund inflow account, transfer path, and fund splitting situation in sequence to obtain the fund transfer situation between accounts. First, it parses the transaction matching result to confirm the starting account of the fund flow, and identifies the target receiving account based on the transaction record. The system calls the transaction database to retrieve the fund flow path involved in the current transaction, and obtains the initiating account, receiving account, and transaction amount of each transaction. For example, if user A transfers 500 yuan to user B, and at the same time user B transfers 300 yuan to user C, the initial fund flow path parsed by the system is A→B (500 yuan), B→C (300 yuan). In the case of fund splitting, if there are 200 yuan left in account B and deposited into different accounts D and E, the system further parses B→D (100 yuan), B→E (100 yuan). After completing the extraction of the fund transfer path, the system organizes all transaction paths, stores the fund flow situation in the form shown in Table 2, and calculates the fund distribution ratio of each path. The fund distribution ratio is calculated as the ratio of the transaction amount of the path to the total inflow amount. For example, the total inflow of account B is 500 yuan, and the fund distribution ratios to accounts C, D, and E are 0.6, 0.2, and 0.2 respectively. The calculated fund flow path data is stored in the database for subsequent calculation of the fund flow trend.

[0075] Table 2 Fund Flow Path Data Table:

[0076] ;

[0077] As shown in Table 2, when A transfers 500 yuan to account B, after the fund flows to account B, the funds in account B are further distributed to accounts C, D, and E. Among them, account C obtains 60% of the funds, and accounts D and E each obtain 20% of the funds, completing the organization of the fund flow path data.

[0078] The fund flow trend calculation sub-module, based on the fund flow path data, uses the formula:

[0079] ;

[0080] Performs operations to obtain the fund change rate and gets the fund flow trend information;

[0081] Among them, represents the fund change rate, represents the path at time the amount of funds, represents the amount of funds at the previous time point, represents the adjacent time interval, represents the total number of transaction paths;

[0082] After receiving the fund flow path data, the fund flow trend calculation sub-module calculates the fund change rate and obtains the fund flow trend information. The specific calculation process is as follows: First, parse the fund flow path data, determine the amount of funds of each transaction path at different time points, and record the corresponding timestamps. For example, at time T1, the amount of funds Q_BC,1 of path B→C is 300 yuan, and at time T2, the amount of funds Q_BC,2 of path B→C increases to 450 yuan. Calculate the fund change rate of this path using the formula for the operation. Let T1 = 10:00 and T2 = 11:00, then , substitute into the calculation yuan / hour, indicating that the fund flow rate of this path within 1 hour is 150 yuan / hour. If the total number of transaction paths n = 3, the system calculates the fund change rates of other paths and sums them to obtain the global fund change rate. The fund change rate data of all paths are recorded as shown in Table 3.

[0083] Table 3: Table of fund flow trend calculation results:

[0084] ;

[0085] As shown in Table 3, the fund change rates of each transaction path have been calculated, and the system stores the fund change rate information for use by the subsequent fund flow stability evaluation sub-module.

[0086] Based on the fund flow trend information, the fund flow stability evaluation sub-module calls the measurement of the transaction fund path, matches the fund flow stability, calculates the fund transfer change rate, judges the fund fluctuation range, and obtains the fund flow stability information.

[0087] After receiving the capital flow trend information, the capital flow stability evaluation sub-module first calculates the measurement of the transaction capital path and matches the capital flow stability. The specific implementation process is as follows: The system calls the historical transaction data to obtain the standard deviation of the capital change rate of each path to measure the stability of the capital flow. For example, for the path B→C, the capital change rates in the recent three hours are 150 yuan / hour, 140 yuan / hour, and 160 yuan / hour respectively, and then calculate the standard deviation as . If the standard deviation is lower than the set threshold, such as 20 yuan / hour, it is determined that the capital flow of this path is relatively stable. The same calculation is performed for all paths and classified within the preset capital fluctuation range. For example, the fluctuation range of 0-20 yuan / hour is the stable range, 20-50 yuan / hour is the slight fluctuation range, and greater than 50 yuan / hour is the severe fluctuation range. Finally, the capital flow stability information is obtained.

[0088] Please refer to Figure 4 , the order payment status confirmation module includes:

[0089] Based on the capital flow stability information, the payment information extraction sub-module obtains the payment transaction status, calls the feedback status of the payment platform, bank transaction records, receiving account confirmation records, and user payment vouchers, and parses the payment information data to obtain the payment status data set;

[0090] After receiving the capital flow stability information, the payment information extraction sub-module obtains the payment transaction status in sequence, and calls the feedback status of the payment platform, bank transaction records, receiving account confirmation records, and user payment vouchers to parse the payment information data. First, it parses the feedback status of the payment platform to obtain status codes such as payment success, failure, or processing in progress, and matches the unique transaction number of the payment request. For example, the transaction number "20250214001" corresponds to the payment platform return status "success". Subsequently, it calls the bank transaction records to query the payment amount, payment account, receiving account, and transaction time according to the transaction number. If this transaction records a successful transfer of 1000 yuan to the target account at "2025-02-14 12:45:30", the corresponding transaction data is stored. Then, the system parses the receiving account confirmation record to check whether the target account actually receives this sum of money. If the receiving account confirmation record shows that the arrival time is "2025-02-14 12:46:15", the arrival status is recorded as "confirmed". Obtain the user payment vouchers, such as e-receipts, payment screenshots, or transaction text messages, and extract the data from the voucher content to ensure the integrity of the payment information. As shown in Table 4, finally, the payment status data set is obtained for subsequent calculation of payment status deviation.

[0091] Table 4 Payment status data set:

[0092] ;

[0093] As shown in Table 4, the transaction number 20250214001 shows successful payment in both the payment platform, bank statement, and receipt account confirmation record. The payment voucher is an electronic receipt, indicating the completion of the transaction. However, the payment status of transaction number 20250214002 is still being processed, and the bank statement does not show the entry. The system stores this payment status dataset for subsequent calculations.

[0094] The payment status deviation calculation sub-module, based on the payment status dataset, uses the formula:

[0095] ;

[0096] to calculate the payment status deviation rate through operations.

[0097] Among them, represents the payment status deviation rate, represents the status value returned by the payment platform, represents the status value of the bank statement record, represents the current transaction timestamp, represents the time average of the payment data, represents the number of payment records;

[0098] The payment status deviation calculation sub-module calculates the payment status deviation rate based on the payment status dataset. The specific calculation process is as follows: The system first parses the status feedback from the payment platform, the bank statement record status, the receipt account confirmation record, and the user payment voucher, and calculates the deviation value between each status. For the status feedback from the payment platform and the bank statement status , status value markers are defined. For example, "success" is marked as 1, "processing" is marked as 0.5, and "failure" or "not recorded" is marked as 0. Calculate the status deviation value of each payment record. For example, for transaction number 20250214001, the payment platform status is "success" (1), and the bank statement status is "recorded" (1), then its status deviation is: ;

[0099] For transaction number 20250214002, the payment platform status is "processing" (0.5), and the bank statement status is "not recorded" (0), then its status deviation is: ;

[0100] Calculate the average value of the status deviation values of all transaction records, where the total number of payment records is , that is ;

[0101] Calculate the sum of squares of the transaction time deviation. Extract the transaction timestamps of all payment records , and calculate the time average . The transaction time of transaction number 20250214001 is 12:45:30, and the transaction time of transaction number 20250214002 is 12:46:15, then the time average is calculated as follows:

[0102] ;

[0103] Calculate the sum of squares of the deviations of each transaction time:

[0104] ;

[0105] Calculate the square root of the time deviation term:

[0106] ;

[0107] Calculate the payment status deviation rate :

[0108] ;

[0109] The final payment status deviation rate Calculation is completed, and the calculation results are stored in the database, as shown in Table 5.

[0110] Table 5 Payment Status Deviation Calculation Result Table:

[0111] ;

[0112] As shown in Table 5, the payment status deviation rate of transaction number 20250214001 is 31.82, and the payment status deviation rate of transaction number 20250214002 is 32.07. After the calculation is completed, the system stores the payment status deviation rate data for subsequent judgment of payment synchronization status. During the calculation of the payment status deviation rate, the numerical marking reference values of the payment platform status and the bank statement status are set to 0 (failure), 0.5 (processing), and 1 (success) respectively. The setting basis of this marking value is the three common status classifications in the payment process, and its value is associated with the payment progress. When the payment platform feedback status is "processing", there is a risk of payment delay, so the marking value 0.5 is set. If the feedback status is "success" and the bank statement is credited, the setting value is 1. If the payment fails or is not credited, the setting value is 0. This marking value is used as the input for the payment status deviation calculation and directly affects the deviation rate calculation result. At the same time, in the time deviation calculation, the time average As a reference value for measuring the deviation degree of different payment transactions, the calculation method of this reference value is the arithmetic mean of all payment times. In the calculation process of the payment status deviation rate, the calculation of the sum of squared time deviations is used to measure the degree of time dispersion. The larger the deviation value, the greater the difference in payment timeliness. The calculation method of this sum of squared time deviations adopts the mean square deviation calculation to ensure the accuracy of time stability analysis.

[0113] Based on the payment status deviation rate, the payment synchronization situation judgment sub-module compares with the preset deviation threshold to judge the payment status synchronization situation and obtains the payment status consistency comparison information.

[0114] After receiving the payment status deviation rate, the payment synchronization situation judgment sub-module performs a comparison with the preset deviation threshold to judge the payment status synchronization situation. The system first sets the payment status synchronization deviation threshold. For example, the threshold is set to 30. Subsequently, it compares the payment status deviation rates of each transaction. For example, the payment status deviation rate of transaction number 20250214001 is 31.75, which is greater than the threshold 30, so it is determined as "out of sync". The payment status deviation rate of transaction number 20250214002 is 32.25, which is also greater than the threshold, so it is determined as "out of sync". The system stores the payment status consistency comparison information and outputs the comparison result. The payment status synchronization deviation threshold is set to 30. The setting basis of this value is the payment time synchronization error range between the bank and the payment platform. In actual transaction scenarios, there is a certain error in the payment times of different banks and payment platforms, usually fluctuating within the range of 0 - 60 seconds. After calculating the sum of squared time deviations and combining with the average deviation level measured by the system, the deviation rate of 30 is determined as the judgment threshold. When the payment status deviation rate exceeds this value, it indicates that there are significant differences in the payment platform status, bank transaction records, receiving account records, and user payment vouchers. The setting of this threshold mainly affects the judgment of payment status consistency. If the deviation rate is lower than the threshold, it is determined that the payment status is consistent; otherwise, it is determined that the payment status is out of sync, which affects the payment status reconciliation and exception handling processes.

[0115] Please refer to Figure 5 , the abnormal transaction comparison module includes:

[0116] Based on the payment status consistency comparison information, the multi-order payment status acquisition sub-module acquires the payment situations of multiple orders of the same device and IP address, calls the fund flow path record, extracts the order payment data under the same device and IP address, filters the transaction records with close time intervals, and obtains the payment records of multiple orders;

[0117] After receiving the payment status consistency comparison information, the multi-order payment status acquisition sub-module obtains the payment status of multiple orders for the same device and IP address, and calls the fund flow path record. The system first analyzes the historical payment transaction data, and filters all transaction records under the same device and the same IP address according to the device unique identifier (such as IMEI code, MAC address) and IP address. For example, for the device IMEI code "358240051111110" corresponding to the IP address "192.168.1.10", the system filters out all orders completed under this device and IP address. Subsequently, it calls the fund flow path record to analyze the payment amount, payment time, and fund flow direction of all associated transactions. For example, a certain user submits three orders at 12:00, 12:02, and 12:05 on February 14, 2025, with the amounts of each order being 200 yuan, 300 yuan, and 500 yuan respectively. Then it records the payment path of the transaction, sorts it by time, and calculates the time interval between adjacent orders. The system filters out the transaction records with close time intervals. The screening threshold for the transaction time interval is set to 300 seconds. This threshold is obtained based on the statistical data of the payment system's historical data, and the value range is 100 - 600 seconds, which is mainly affected by factors such as the payment system's confirmation time and bank statement processing time. If a certain transaction interval is less than this threshold, it is determined as consecutive transactions within a short period. For example, orders with a time interval less than 5 minutes are determined as consecutive transactions within a short period and are stored in the multi-order payment record, as shown in Table 6, and the multi-order payment record is obtained.

[0118] Table 6 Multi-order payment record form:

[0119] ;

[0120] As shown in Table 6, for the device IMEI code "358240051111110" under the IP address "192.168.1.10", the transaction time intervals are relatively short. The time intervals of the three orders are 120 seconds and 180 seconds respectively. The system stores this multi-order payment record for subsequent comparison of short-term account changes.

[0121] Based on the multi-order payment record, the short-term account change comparison sub-module compares the transaction account changes and cash withdrawal behaviors within a short period, calculates the account balance change rate, extracts the transaction frequency and cash withdrawal interval data, and obtains the short-term transaction fluctuation information of the account;

[0122] After receiving multiple order payment records, the short-term account change comparison sub-module performs a comparison of the changes in the trading account and cash withdrawal behavior within a short period of time, calculates the account balance change rate, and extracts the trading frequency and cash withdrawal interval data. The specific execution process is as follows: The system first analyzes the fund flow of the trading account and calculates the change in the account balance. For example, if the initial balance of an account is 10,000 yuan and the account balance changes to 9,800 yuan, 9,500 yuan, and 9,000 yuan after transactions are completed at 12:00, 12:02, and 12:05 on February 14, 2025 respectively, then calculate the account balance change rate after each transaction. The balance change rate is calculated based on the amount change within the time interval. For example, the balance change rate is calculated as: ; Substitute the values for calculation. The balance change rate of the first transaction is yuan per second, and the balance change rate of the second transaction is yuan per second. Store the calculated account balance change rate and extract the cash withdrawal record. For example, if an account withdraws 4,000 yuan at 12:10, then calculate the cash withdrawal interval. The cash withdrawal interval is the difference between the time of the last transaction and the cash withdrawal time, that is minutes. Store the cash withdrawal interval data and obtain the short-term trading fluctuation information of the account. To ensure the rationality of the cash withdrawal interval, the system sets the benchmark value of the cash withdrawal interval to 300 seconds. This benchmark value is set based on the average cash withdrawal processing time, and its value range is generally between 240 - 600 seconds. If the cash withdrawal interval is less than 300 seconds, then mark that the account has the behavior of high-frequency trading and cash withdrawal within a short period of time.

[0123] The abnormal fund flow rate calculation sub-module, based on the short-term trading fluctuation information of the account, uses the formula:

[0124] ;

[0125] Perform the operation to obtain the abnormal fund flow ratio and get the abnormal transaction comparison information;

[0126] Among them, represents the abnormal fund flow ratio, represents the cycle the total number of transactions within, represents the cycle the total number of cash withdrawals within, represents the cycle the account balance at the end of, represents the standard deviation of the trading time interval, represents the standard deviation of the cash withdrawal time interval.

[0127] After receiving the short-term trading fluctuation information of the account, the abnormal fund flow rate calculation sub-module calculates the abnormal fund flow ratio. First, count the total number of transactions and the total number of cash withdrawals For example, if an account has 3 transactions and 1 cash withdrawal from 12:00 to 12:10, then , , the account balance at the end of the system calculation period , if the account balance at the end of the period is 5,000 yuan, then , then calculate the standard deviation of the trading time interval and the standard deviation of the cash withdrawal time interval , the trading time interval data is 120 seconds and 180 seconds, and the cash withdrawal time interval data is 300 seconds. The standard deviation is calculated as follows:

[0128] ;

[0129] (Since there is only one cash withdrawal, the standard deviation is 0);

[0130] Substitute into the formula , then the calculation is as follows:

[0131] ;

[0132] The calculation results are stored as shown in Table 7. Finally, obtain the abnormal transaction comparison information. Set the threshold of the abnormal fund flow ratio to 0.005. This threshold is set based on the normal fluctuation range of the trading account, and the value range is 0.002 - 0.008. If it is higher than this threshold, it is determined that the account may have abnormal fund flow behavior.

[0133] Table 7 Calculation Results Table of Abnormal Fund Flow Rate:

[0134] ;

[0135] As shown in Table 7, the abnormal fund flow ratio of user A is 0.0022. Since it is lower than the threshold of 0.005, this account is not determined to be an abnormal fund flow account, and the system stores the calculation results for subsequent transaction risk analysis.

[0136] Please refer to Figure 6 , the risk control strategy adjustment module includes:

[0137] Based on the abnormal transaction comparison information, the transaction anomaly matching sub-module calls the order risk data measurement, matches the degree of transaction anomaly, compares the abnormal transaction characteristics with the set transaction anomaly classification criteria, extracts the transaction anomaly category, and obtains the transaction anomaly classification information;

[0138] After receiving the abnormal transaction comparison information, the abnormal transaction matching sub-module calls the order risk data measurement and matches the degree of transaction abnormality. The system first extracts the abnormal transaction liquidity ratio in the abnormal transaction comparison information, compares it with the historical abnormal transaction data, and calculates the degree of abnormality of the current transaction. For example, if the abnormal fund liquidity ratio of an account is 0.0022, analyze the historical transaction data to obtain the range of the abnormal fund liquidity ratio for normal transactions. If the normal transaction ratio distribution range is between 0.0001 and 0.001, then the current transaction has a relatively high degree of abnormality. The system classifies the degree of transaction abnormality, sets low risk (0.0001 - 0.001), medium risk (0.001 - 0.002), and high risk (above 0.002), and classifies the current transaction as high risk. Subsequently, the system compares the abnormal transaction characteristics, such as frequent small transactions, cash withdrawals in a short period, frequent changes in IP addresses, etc., and matches them according to the abnormal transaction classification criteria. If the current transaction contains the characteristics of frequent small transactions, identify that the transaction belongs to the "frequent small transactions" abnormal category, and store the transaction abnormal classification information, as shown in Table 8, and finally obtain the transaction abnormal classification information.

[0139] Table 8 Transaction Abnormal Classification Information Table:

[0140] ;

[0141] The classification threshold is determined by calculating based on the account transaction behavior pattern and the fund flow standard. Extract the distribution range of the fund liquidity ratio from the transaction historical data, and calculate its mean and standard deviation. For example, in 10,000 normal transaction samples, the mean of the abnormal fund liquidity ratio is 0.00055, and the standard deviation is 0.00045. Then, use the mean + 2 times the standard deviation (0.00145) as the upper limit of medium risk, and the mean + 3 times the standard deviation (0.002) as the starting value of high risk, and set the risk level accordingly. This setting method ensures that the threshold is calculated based on the real transaction behavior data.

[0142] The transaction risk level calculation sub-module is based on the transaction abnormal classification information and uses the formula:

[0143] ;

[0144] Perform operations to obtain the transaction risk value and obtain the transaction risk level information;

[0145] Among them, represents the transaction risk value, represents the risk coefficient corresponding to the transaction abnormal category, represents the abnormal transaction frequency, represents the total trading volume within the transaction time window, represents the trading amount fluctuation range, represents the trading amount benchmark value;

[0146] After receiving the transaction anomaly classification information, the transaction risk level calculation sub-module calculates the transaction risk value and obtains the transaction risk level information. First, the system analyzes the risk coefficient corresponding to the transaction anomaly category , which is calculated from the actual loss rate caused by the transaction history of each category. For example, the risk coefficient of high-frequency trading risk is set to 3.0, and this value comes from the proportion of capital losses caused by this type of transaction. For example, in the past 10,000 transactions, the proportion of losses caused by high-frequency trading is 3%, and the system takes this loss proportion as the risk coefficient , and obtains the abnormal transaction frequency , that is, the number of abnormal transactions within a unit time. For example, if a certain account has 3 abnormal transactions within 1 hour, then , then obtains the total trading volume within the transaction time window , for example, if this account has a total of 10 transactions within 1 hour, then , calculates the trading amount fluctuation range and the trading amount benchmark value , the trading amount fluctuation range is set as the maximum change range of the past trading amount. For example, in the past 10 transactions, the highest trading amount is 1000 yuan and the lowest trading amount is 500 yuan, then the fluctuation range , the benchmark value is set as the historical trading average. For example, if the average amount of the past 10 transactions is 700 yuan, then , substitutes the parameters into the formula:

[0147] ;

[0148] Calculates the transaction risk value , as shown in Table 9, and finally obtains the transaction risk level information

[0149] Table 9 Transaction Risk Level Calculation Result Table:

[0150] ;

[0151] The above calculation parameters are obtained from the statistical analysis of historical transaction data and are set based on the actual influence range of abnormal transactions. The risk coefficient corresponds to the historical loss rate, the trading amount benchmark value comes from the historical average, and the fluctuation range is calculated through the highest and lowest trading amounts

[0152] Based on the transaction risk level information, the transaction restriction determination sub-module determines whether the transaction risk value exceeds the set threshold. If it exceeds, it marks the transaction as high-risk and executes transaction restriction measures. If it does not exceed, the transaction proceeds normally and obtains the order transaction verification information

[0153] After receiving the transaction risk level information, the transaction restriction determination sub-module determines whether the transaction risk value exceeds the set threshold, executes corresponding measures, and sets the transaction risk threshold. This threshold is set through the historical risk control data in the transaction system and is calculated based on the risk distribution of past abnormal transactions. For example, the low-risk transaction threshold is set to 100, the medium-risk transaction threshold is 150, and the high-risk transaction threshold is 200. This setting is based on the risk value distribution of historical transactions. For example, if the average risk value of the past 10,000 transactions is 120 and the standard deviation is 40, then the set thresholds are obtained by adding 1 times, 1.5 times, and 2 times the standard deviation respectively, that is , and then compare the transaction risk value. For example, the transaction risk value of transaction number 20250214001 is 200.9, which is higher than the set threshold of 200. The system marks this transaction as high-risk and executes transaction restriction measures. The restriction measures include delayed processing, manual review, temporary account freezing, etc. The system records the transaction restriction status and stores the order transaction verification information.

[0154] The above is only the preferred embodiment of the present invention and does not limit the present invention in other forms. Any person skilled in the art may use the technical content disclosed above to make changes or modifications into equivalent embodiments with equivalent changes and apply them to other fields. However, as long as it does not depart from the technical solution content of the present invention, any simple modification, equivalent change, and modification made to the above embodiments based on the technical essence of the present invention still fall within the protection scope of the technical solution of the present invention.

Claims

1. An e-commerce transaction verification system based on blockchain, characterized in that, The system includes: The transaction authentication module obtains an e-commerce transaction verification request, performs a hash calculation on the transaction identity data, calls the user identity hash record stored in the blockchain, and determines whether they match to obtain a transaction identity matching result; Based on the transaction identity matching result, the fund flow monitoring module obtains the payment transaction fund flow, calculates the fund flow trend, matches the fund flow stability, calculates the fund transfer change rate, and obtains the fund flow stability information; The fund flow monitoring module includes: Based on the transaction identity matching result, the fund flow extraction sub-module obtains the payment transaction fund flow, calls the fund inflow account, transfer path, and fund splitting situation, extracts the fund transfer situation between accounts, arranges the transaction path, calculates the fund distribution ratio of each path, and obtains the fund flow path data; Based on the fund flow path data, the fund flow trend calculation sub-module uses the formula: ； Performs an operation to obtain the fund change rate and obtains the fund flow trend information; Among them, represents the rate of change of funds, represents the path at time the amount of funds, represents the amount of funds at the previous time point, represents the adjacent time interval, represents the total number of trading paths; Based on the fund flow trend information, the fund flow stability evaluation sub-module calls the measurement of the transaction fund path, matches the fund flow stability, calculates the fund transfer change rate, determines the fund fluctuation range, and obtains the fund flow stability information; Based on the fund flow stability information, the order payment status confirmation module obtains the payment transaction status, calculates the payment status deviation, determines the payment status synchronization situation, and obtains the payment status consistency comparison information; Based on the payment status consistency comparison information, the abnormal transaction comparison module calls the fund flow path record, compares the transaction account changes and cash withdrawal behaviors within a short period of time, calculates the abnormal fund flow rate, and obtains the abnormal transaction comparison information; The abnormal transaction comparison module includes: Based on the payment status consistency comparison information, the multi-order payment status acquisition sub-module obtains the payment situations of multiple orders with the same device and IP address, calls the fund flow path record, extracts the order payment data under the same device and IP address, and filters the transaction records with close time intervals to obtain the multi-order payment records; among them, when filtering the transaction records with close time intervals, the screening threshold for the transaction time interval is set to 300 seconds. If a certain transaction interval is less than this threshold, it is determined as continuous transactions within a short period of time, that is, the transaction records with close time intervals; Based on the multi-order payment records, the short-term account change comparison sub-module compares the transaction account changes and cash withdrawal behaviors within a short period of time, calculates the account balance change rate, extracts the transaction frequency and cash withdrawal interval data, and obtains the short-term transaction fluctuation information of the account; Based on the short-term transaction fluctuation information of the account, the abnormal fund flow rate calculation sub-module uses the formula: ； Performs an operation to obtain the abnormal fund flow ratio and obtains the abnormal transaction comparison information; Among them, represents the abnormal fund flow ratio, represents the cycle the total number of transactions within, represents the cycle the total number of withdrawals within, represents the cycle the account balance at the end, represents the standard deviation of the trading time interval, represents the standard deviation of the withdrawal time interval; Based on the abnormal transaction comparison information, the risk control strategy adjustment module calls the measurement of order risk data, matches the transaction abnormality degree, evaluates the transaction risk level, determines whether it is necessary to execute transaction restriction measures, and obtains the order transaction verification information.

2. The blockchain-based e-commerce transaction verification system according to claim 1, wherein The specific results of the transaction identity matching include the identity matching status, the transaction authorization status, and the identity hash comparison result. The stable information of fund flow includes the stability of the fund path, the change rate of fund transfer, and the historical transaction matching degree. The comparison information of payment status consistency includes the synchronization of payment data, the account confirmation status, and the consistency of feedback from the payment platform. The comparison information of abnormal transactions is specifically the abnormal rate of account transactions, the activity of device transactions, and the abnormal distribution of fund withdrawals. The verification information of order transactions includes the transaction risk level, the execution status of restriction measures, and the abnormal transaction mark.

3. The blockchain-based e-commerce transaction verification system according to claim 1, wherein The transaction identity verification module includes: The identity information extraction sub-module obtains an e-commerce transaction verification request, invokes the user public key, device identifier, transaction timestamp, and order amount, parses and extracts user identity data, and obtains a transaction identity data set; The identity hash calculation sub-module obtains a transaction identity hash value by using hash calculation based on the transaction identity data set; The identity matching judgment sub-module, based on the transaction identity hash value, invokes the identity hash record stored in the blockchain, compares the transaction identity hash value with the identity hash record, and judges whether the two match. If they match, the e-commerce transaction request is authorized; if they do not match, the e-commerce transaction request is rejected, and the transaction identity matching result is obtained.

4. The blockchain-based e-commerce transaction verification system according to claim 1, wherein, The order payment status confirmation module includes: The payment information extraction sub-module obtains the payment transaction status based on the stable information of fund flow, invokes the feedback status of the payment platform, bank statement records, collection account confirmation records, and user payment vouchers, parses the payment information data, and obtains a payment status data set; The payment status deviation calculation sub-module, based on the payment status data set, uses the formula: ； to calculate and obtain the payment status deviation rate; Among them, represents the payment status deviation rate, represents the status value returned by the payment platform, represents the status value of the bank transaction record, represents the current transaction timestamp, represents the time average of the payment data, represents the number of payment records; The payment synchronization situation judgment sub-module compares the payment status deviation rate with a preset deviation threshold to judge the payment status synchronization situation and obtains the comparison information of payment status consistency.

5. The blockchain-based e-commerce transaction verification system according to claim 1, wherein The risk control strategy adjustment module includes: The abnormal transaction matching sub-module, based on the comparison information of abnormal transactions, invokes the measurement of order risk data, matches the degree of transaction abnormality, compares the abnormal transaction characteristics with the set transaction abnormality classification criteria, extracts the transaction abnormality category, and obtains the transaction abnormality classification information; The transaction risk level calculation sub-module, based on the transaction abnormality classification information, uses the formula: ； to calculate and obtain the transaction risk value and obtain the transaction risk level information; Among them, represents the transaction risk value, represents the risk coefficient corresponding to the transaction anomaly category, represents the abnormal transaction frequency, represents the total trading volume within the trading time window, represents the trading amount fluctuation range, represents the trading amount benchmark value; The transaction restriction determination sub-module, based on the transaction risk level information, judges whether the transaction risk value exceeds the set threshold. If it exceeds, the transaction is marked as high risk and the transaction restriction measures are executed; if it does not exceed, the transaction proceeds normally, and the verification information of order transactions is obtained.

Images