Financial transaction gateway routing method, apparatus, device, and medium

Abstract

The application relates to the technical field of security protection, and discloses a financial transaction gateway routing method, device, equipment and medium, which comprises the following steps: obtaining an external request and generating an authentication combination key and a flow limiting dimension based on the external request; performing multi-level authentication verification on the authentication combination key; after the multi-level authentication verification is passed, performing dynamic flow limiting inspection on the external request according to the flow limiting dimension; after the dynamic flow limiting inspection is passed, analyzing the external request to obtain a transaction feature vector and a transaction message, and matching a preset test case library according to the transaction feature vector; if the transaction feature vector hits a test case in the preset test case library, a simulation response is returned; and if the transaction feature vector does not hit a test case in the preset test case library, the transaction message is forwarded according to a target routing rule. The application can be applied to a financial scene, can improve multi-level protection, and meets the transaction circulation demand of high security and low risk.

Description

Technical Field

[0001] This invention relates to the field of security protection technology, and in particular to a financial transaction gateway routing method, apparatus, device, and medium. Background Technology

[0002] With the advancement of digital transformation in finance, financial transaction gateway routing systems have become core tools for financial transaction flow. They support authentication, rate limiting, and routing forwarding of requests through multi-channel and multi-type transaction data, and are widely used in financial scenarios such as online payment, UnionPay transactions, merchant settlement, and personal transfers.

[0003] Existing financial transaction gateway routing systems primarily achieve basic security protection through a single authentication process and fixed rate limiting rules. However, this protection method suffers from insufficient layers and crude control, making it difficult to cope with the diverse risks in complex financial scenarios. For example, in high-frequency trading scenarios for merchants, when faced with batch transaction requests initiated by merchants, the system can only manage them through a single interface authentication and fixed traffic limits. It cannot identify hidden risks such as unauthorized access and malicious traffic attacks, and is prone to overlooking issues such as unauthorized merchant transactions and interface crashes caused by high-concurrency traffic, leading to security risks such as fund security and data leakage.

[0004] The inventors realized that existing financial transaction gateway routing systems cannot build multi-layered security protection mechanisms, make it difficult to accurately control risks throughout the entire transaction process, and fail to meet the high-security, low-risk transaction flow requirements of the financial sector. Summary of the Invention

[0005] This invention provides a financial transaction gateway routing method, apparatus, computer equipment, and medium to solve the problem that existing financial transaction gateway routing systems cannot meet the requirements of high security and low risk transaction flow.

[0006] Firstly, a financial transaction gateway routing method is provided, including: Obtain external requests and generate authentication combination keys and rate limiting dimensions based on the external requests; Perform multi-level authentication and verification on the authentication key combination; After the multi-level authentication and verification are passed, the external request is dynamically rate-limited according to the rate-limiting dimension. After the dynamic rate limiting check passes, the external request is parsed to obtain the transaction feature vector and transaction message, and a preset test case library is matched according to the transaction feature vector; If the transaction feature vector matches a test case in the preset test case library, a simulated response is returned; If the transaction feature vector does not match a test case in the preset test case library, the transaction message is forwarded according to the target routing rules.

[0007] Secondly, a financial transaction gateway routing device is provided, comprising: The acquisition module is used to acquire external requests and generate authentication combination keys and rate limiting dimensions based on the external requests; The verification module is used to perform multi-level authentication verification on the authentication key combination. The inspection module is used to perform dynamic rate limiting checks on the external request based on the rate limiting dimension after the multi-level authentication and verification are passed. The matching module is used to parse the external request to obtain the transaction feature vector and transaction message after the dynamic rate limiting check passes, and to match the transaction feature vector with a preset test case library. The return module is used to return a simulated response if the transaction feature vector matches a test case in the preset test case library; The forwarding module is used to forward the transaction message according to the target routing rules if the transaction feature vector does not match a test case in the preset test case library.

[0008] 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 above-described financial transaction gateway routing method.

[0009] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the aforementioned financial transaction gateway routing method.

[0010] In the aforementioned financial transaction gateway routing method, apparatus, computer equipment, and storage medium, the following steps are taken: An external request is acquired, and an authentication key and rate limiting dimension are generated based on the external request; multi-level authentication verification is performed on the authentication key; after the multi-level authentication verification passes, dynamic rate limiting checks are performed on the external request according to the rate limiting dimension; after the dynamic rate limiting check passes, the external request is parsed to obtain a transaction feature vector and a transaction message, and a preset test case library is matched based on the transaction feature vector; if the transaction feature vector matches a test case in the preset test case library, a simulated response is returned; if the transaction feature vector does not match a test case in the preset test case library, a target routing rule is applied. The transaction message is then forwarded. In this invention, an authentication key and a rate limiting dimension can be generated based on the external request, and the authentication key is subject to multi-level authentication verification to prevent unauthorized access. After the verification passes, the external request is dynamically rate-limited based on the rate limiting dimension to prevent traffic attacks. Only after both authentication verification and rate limiting checks pass will a preset test case library be matched based on the transaction feature vector. When the transaction feature vector matches a test case, a simulated response is returned. When the transaction feature vector does not match a test case, the transaction message is forwarded according to the target routing rules. This not only enables permission checks and traffic checks, but also allows for security testing through matching test cases to prevent anomalies and meet the requirements of high security and low risk transaction flow. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of the present invention, the 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.

[0012] Figure 1 This is a schematic diagram of an application environment for a financial transaction gateway routing method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a financial transaction gateway routing method according to an embodiment of the present invention; Figure 3 yes Figure 2 A schematic diagram of a specific implementation method for step S10; Figure 4 yes Figure 2 A schematic diagram of a specific implementation method for step S20; Figure 5 yes Figure 2 A schematic diagram of a specific implementation method for step S30; Figure 6 yes Figure 2A schematic diagram of a specific implementation of step S40; Figure 7 yes Figure 2 A schematic diagram of a specific implementation method for step S60; Figure 8 This is another flowchart illustrating the financial transaction gateway routing method in one embodiment of the present invention; Figure 9 This is a schematic diagram of a financial transaction gateway routing device in one embodiment of the present invention; Figure 10 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 11 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0013] 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. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] The financial transaction gateway routing method provided in this invention can be applied to a three-layer architecture of a financial transaction gateway, which includes a gateway layer, an application layer, and a business layer. This three-layer architecture can be configured as follows: Figure 1 In the server-side diagram, the client communicates with the server via a network. The server can receive external requests sent by the client and return simulated responses 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. This method, by acquiring external transaction requests and generating authentication key combinations and rate limiting dimensions, performing multi-level authentication verification, dynamic rate limiting checks, matching transaction feature vectors with a pre-defined test case library, and routing / simulating responses, can construct a multi-layered security protection mechanism of permission verification, traffic control, and pre-emptive risk screening. It accurately manages risks throughout the entire transaction process, effectively avoids unauthorized access, traffic attacks, and illegal transactions, shortens transaction processing time, and meets the compliance and risk control requirements of the financial industry. It is suitable for financial scenarios with extremely high requirements for transaction security, accuracy, and compliance, such as online payment, UnionPay transactions, merchant settlement, and personal transfers.

[0015] In financial transaction scenarios, traditional routing models rely solely on a single authentication step and fixed forwarding rules to facilitate transaction flow. This results in issues such as lax permission verification, loose traffic control, and a lack of proactive risk screening mechanisms. Furthermore, it is difficult to address the diverse risks inherent in complex financial scenarios, and it is prone to compliance risks such as unauthorized access, fund security breaches, and data leaks. Additionally, it is susceptible to fraudulent activities such as malicious requests and illegal transactions, making it difficult to meet the high-security, low-risk transaction requirements of the financial sector. The routing method of this invention automatically completes full-process security control after receiving external transaction requests, without manual intervention. It can automatically complete permission verification, traffic control, and risk investigation. For example, when a merchant initiates a batch transaction request, the system first obtains the external request, generates an authentication key and a rate limiting dimension based on the request information, and performs multi-level authentication verification on the authentication key, including interface whitelist, institutional permissions, and merchant authorization. After the verification is passed, dynamic rate limiting is checked according to the rate limiting dimension. After the rate limiting is passed, the request is parsed to obtain the transaction feature vector and transaction message. The transaction feature vector is matched with a preset test case library to investigate the risk of violations. If no test case is hit, the request is forwarded to the corresponding business processing end according to the target routing rules. If a test case is hit, a simulated response is returned, thus realizing the security, accuracy, and compliance of financial transactions.

[0016] Please see Figure 2 As shown, Figure 2 A flowchart illustrating the financial transaction gateway routing method provided in this embodiment of the invention includes the following steps: S10: Obtain external requests and generate authentication combination keys and rate limiting dimensions based on the external requests.

[0017] External requests refer to various financial transaction requests, including but not limited to merchant payment requests, personal transfer requests, and UnionPay / NetUnion channel transaction requests. These requests contain key fields such as gateway identifiers, institution information, and message information, providing data sources for generating authentication key combinations and rate limiting dimensions. After obtaining external requests, authentication key combinations for permission verification and rate limiting dimensions for traffic control can be generated, providing basic data support for subsequent multi-level authentication and dynamic rate limiting. This achieves dual pre-emptive control of permissions and traffic, reducing the risk of unauthorized access and traffic overload from the source. The authentication key combination is a unique identifier extracted from the external transaction request, used to uniquely identify the requested permission attribute. It can be composed of gateway identifiers, routing identifiers, sending or receiving institution numbers, and message types in a fixed format. Its core function is to serve as the core basis for subsequent multi-level authentication verification, ensuring the uniqueness and accuracy of permission verification, avoiding permission confusion, and preventing the risk of unauthorized access from the source. The rate limiting dimension refers to the core information set extracted from external transaction requests to define the scope of traffic control. It includes key fields such as URL path, interface code, sending or receiving agency, and message type. Its core function is to provide accurate control basis for subsequent dynamic rate limiting, realize differentiated control of transaction traffic of different types and channels, and prevent high-concurrency traffic attacks and node overload risks.

[0018] For example, a merchant (Merchant ID M001) initiates a batch payment request (external request) through the NetsUnion channel. The request message contains the gateway identifier GW001, the routing identifier ROUTE-EPCC-001, the sending organization number ORG001, the message type MSG-PAY-001, the URL path / api / epcc / batchpay, and the interface code BATCHPAY001. After receiving the request, the system extracts the above key fields. Among them, the gateway identifier, routing identifier, sending organization number, and message type are used to concatenate and generate the authentication combination key, and the URL path, interface code, sending organization, and message type are used to combine to form the rate limiting dimension, which prepares for subsequent multi-level authentication verification and dynamic rate limiting checks.

[0019] In some embodiments, such as Figure 3 As shown, step S10, which involves obtaining the external request and generating the authentication key and rate limiting dimension based on the external request, specifically includes the following steps: S11: Extract the gateway identifier, routing identifier, sending or receiving agency number, and message type from the external request, and concatenate them into the authentication key in a fixed format; S12: Extract the URL path, interface code, sending or receiving agency, and message type from the external request, and combine them to form the rate limiting dimension.

[0020] The authentication key can be formed by extracting key fields related to permissions from external requests and concatenating them in a fixed format. This ensures that the authentication key for each external request is unique, avoids confusion in permission verification, and guarantees the accuracy of permission verification from the source. The sending or receiving institution number refers to the unique number of the institution initiating the transaction (sending institution) or the institution receiving the transaction (receiving institution), and the message type refers to the category of the transaction message (such as payment message, refund message, query message, etc.).

[0021] For example, based on the batch payment request of merchant M001 mentioned above, the gateway identifier GW001, the routing identifier ROUTE-EPCC-001, the sending agency number ORG001, and the message type MSG-PAY-001 are extracted and concatenated into an authentication key in a fixed format of "gateway identifier-routing identifier-sending / accepting agency number-message type": GW001-ROUTE-EPCC-001-ORG001-MSG-PAY-001. This key uniquely corresponds to the merchant's batch payment request and is used for subsequent multi-level authentication and verification.

[0022] Rate limiting dimensions are used to dynamically limit external requests. They are formed by extracting key fields related to traffic control from external requests and combining them to generate rate-limiting resource names and determine the rate-limiting scope. This achieves precise traffic control, prevents interference between different types and channels of transaction traffic, and mitigates the risk of high-concurrency traffic attacks. Specifically, the URL path refers to the access path of the transaction request, and the interface code is the unique identifier of the business interface corresponding to the transaction.

[0023] For example, based on the batch payment request of merchant M001 mentioned above, the URL path / api / epcc / batchpay, interface code BATHPAY001, sending institution ORG001, and message type MSG-PAY-001 are extracted and combined to form the rate limiting dimension: {URL path: / api / epcc / batchpay, interface code: BATHPAY001, sending institution: ORG001, message type: MSG-PAY-001}. This dimension clarifies the specific scope of rate limiting and provides a basis for subsequent dynamic rate limiting.

[0024] S20: Perform multi-level authentication verification on the authentication key combination.

[0025] Multi-level authentication verification can include interface whitelist verification, institutional permission verification, and merchant authorization verification. After obtaining the authentication key, it can be used to perform multi-level verification, including interface whitelist verification, institutional permission verification, and merchant authorization verification. This avoids risks such as unauthorized access and transactions, ensuring the legality and compliance of external requests. If the multi-level authentication verification fails, the external request is directly rejected, terminating subsequent processes and preventing the spread of risks.

[0026] In some embodiments, such as Figure 4 As shown, in step S20, which involves performing multi-level authentication verification on the authentication key, the specific steps include the following: S21: Obtain the local permission cache based on the authentication combination key; S22: Verify whether the interface corresponding to the external request is in the preset interface whitelist based on the local permission cache; S23: Verify, based on the local permission cache, whether the organization corresponding to the external request has the access permission to the corresponding interface; S24: Verify whether the merchant number associated with the external request is within the preset authorization range based on the local permission cache.

[0027] The local permission cache stores all legitimate interface whitelists, institutional permissions, and merchant authorization information. It has the advantages of fast read speed and efficient query. The corresponding permission information can be quickly located through the authentication key combination, thereby avoiding frequent database access and improving authentication efficiency. At the same time, it can also ensure the real-time and accuracy of permission information, providing data support for subsequent multi-level verification.

[0028] The interface whitelist is the first level of permission verification. The default interface whitelist includes all legitimate business interfaces that are allowed to access the financial transaction gateway. Verifying whether an interface is on the whitelist can directly block illegal interface requests, avoid security risks caused by malicious interface access, and protect transaction security from the interface level.

[0029] For example, based on local permission caching, it verifies whether the interface code BATCHPAY001 corresponding to the above merchant M001 request is in the preset interface whitelist. If the interface is in the whitelist, it proceeds to the next level of verification; if it is not in the whitelist, the request is directly rejected, indicating that the interface is illegal and access is denied.

[0030] Institutional permission verification is the second level of permission verification. Even if the interface is on the whitelist, it is still necessary to verify whether the institution that initiates the transaction (sending institution) or the institution that receives the transaction (accepting institution) has the access permission to the interface, so as to prevent institutions from accessing core interfaces without authorization and to prevent permission risks at the institutional level.

[0031] For example, after the interface code BATCHPAY001 passes verification (is within the whitelist), the system further verifies whether the sending organization ORG001 has access to the interface. It checks the permission association record between "ORG001" and "BATCHPAY001" in the local permission cache. If the organization has access, it proceeds to the next level of verification; otherwise, the request is rejected, and the organization is prompted that it does not have access to the interface.

[0032] Merchant authorization verification is the third level of permission verification. For transaction requests initiated by merchants, it is necessary to verify whether the merchant number is within the preset authorization range to prevent unauthorized merchants from initiating illegal transactions through legitimate institutions and legitimate interfaces. This eliminates the risk of unauthorized access from the merchant level and further strengthens permission security protection.

[0033] For example, after the access permission verification of the interface of institution ORG001 is passed, it is verified whether the merchant number M001 associated with the request is within the preset authorization range. The list of authorized merchants associated with "ORG001" in the local permission cache is checked. If M001 is in the authorization list, the multi-level authentication verification is passed; if it is not in the authorization list, the request is rejected, the merchant is not authorized, and the transaction is rejected.

[0034] S30: After the multi-level authentication verification is passed, the external request is dynamically rate-limited according to the rate-limiting dimension.

[0035] After multi-level authentication and verification are passed, dynamic control of transaction traffic can be achieved based on rate limiting. This avoids traffic overload on a single routing node or a single business interface, prevents risks such as high-concurrency traffic attacks and malicious request flooding, ensures the stable operation of the financial transaction gateway, and prevents legitimate requests from being blocked due to traffic overload, achieving a balance between security and efficiency. If the dynamic rate limiting check fails (exceeding the rate limiting threshold), the request is temporarily blocked and allowed to proceed after the traffic load decreases; if the dynamic rate limiting check passes, the subsequent process begins.

[0036] In some embodiments, such as Figure 5 As shown, in step S30, that is, performing dynamic rate limiting checks on the external request based on the rate limiting dimension, the specific steps include the following: S31: Generate a rate-limited resource name based on the rate-limiting dimension; S32: Read the rate limiting threshold corresponding to the rate limiting resource name from the configuration center based on the rate limiting resource name; S33: If the rate limiting threshold is 0, then the rate limiting resource name will not be rate-limited; S34: If the rate limiting threshold is not 0, then a rate limiter is created based on the rate limiting threshold, and a dynamic rate limiting check is performed on the rate limiting resource name based on the rate limiter.

[0037] The rate-limited resource name is a unique identifier for dynamic rate limiting. It is generated based on key fields in the rate limiting dimension (URL path, interface code, sending / accepting agency, message type) according to fixed rules. This ensures that each rate limiting dimension corresponds to a unique rate-limited resource name, achieving precise rate limiting and avoiding interference between transaction traffic of different types and channels, thus ensuring the targeted nature of rate limiting control.

[0038] For example, based on the rate limiting dimension of merchant M001 above {URL path: / api / epcc / batchpay, interface code: BATCHPAY001, sending institution: ORG001, message type: MSG-PAY-001}, the rate limiting resource name is generated according to the rule of "interface code-sending institution-message type": BATCHPAY001-ORG001-MSG-PAY-001. This resource name uniquely corresponds to the NetsUnion batch payment request traffic of this merchant.

[0039] The configuration center stores the rate limiting thresholds corresponding to all rate-limited resource names. These thresholds can be dynamically adjusted based on business needs, traffic peaks, and risk levels. Updates to rate limiting rules can be implemented without modifying code, improving the flexibility of rate limiting management and adapting to traffic control needs in different scenarios. The corresponding rate limiting threshold can be quickly located by the rate-limited resource name, ensuring the accuracy of rate limiting checks.

[0040] For example, based on the rate-limited resource name BATCHPAY001-ORG001-MSG-PAY-001, the corresponding rate-limiting threshold is read from the configuration center. Assuming that the configuration center presets the rate-limiting threshold for this resource name to be 500 times / minute, that is, within a unit of time (1 minute), the merchant's batch payment requests through UnionPay are allowed to be a maximum of 500 times.

[0041] A rate limiting threshold of 0 is a special configuration, meaning that transaction requests corresponding to this rate-limited resource name do not require rate limiting control. This is suitable for core business scenarios and urgent transactions, ensuring that such transactions can be processed quickly, improving transaction efficiency, while not affecting rate limiting control for other transactions, achieving differentiated adaptation of rate limiting rules. For example, if an urgent transfer request from a core institution ORG002 has a rate limiting resource name BATCHTRANS001-ORG002-MSG-TRANS-001, and the rate limiting threshold read from the configuration center is 0, then transaction requests for this resource name will not be rate-limited, and all urgent transfer requests can directly pass the rate limiting check, ensuring efficient processing of urgent transactions.

[0042] When the rate limiting threshold is not 0, a corresponding rate limiter needs to be created. The rate limiter implements dynamic traffic control based on the rate limiting threshold, and counts the number of transaction requests corresponding to the rate-limited resource name in real time within a unit of time. If the number of requests does not exceed the rate limiting threshold, it is allowed; if it exceeds the threshold, it is blocked until the number of requests within a unit of time drops to within the threshold range, thereby achieving dynamic and accurate traffic control and preventing the risk of traffic overload.

[0043] For example, the above-mentioned rate-limited resource name is BATCHPAY001-ORG001-MSG-PAY-001, and the rate-limiting threshold is 500 times / minute (not 0). The system creates a corresponding rate limiter and counts the number of batch payment requests for this merchant within 1 minute in real time. If the number of requests within 1 minute is 480 (not exceeding 500), the rate-limiting check passes; if the number of requests is 520 (exceeding 500), the rate limiter blocks the excess 20 requests and allows them to pass in the next minute.

[0044] S40: After the dynamic rate limiting check passes, parse the external request to obtain the transaction feature vector and transaction message, and match the preset test case library according to the transaction feature vector.

[0045] After the dynamic rate limiting check passes, external requests are parsed to extract transaction feature vectors (for risk screening) and transaction messages (for subsequent routing and forwarding). By matching the transaction feature vectors with a pre-set test case library, risks such as illegal transactions and abnormal requests are screened, achieving pre-emptive risk control before transaction forwarding and further reducing transaction risks. The pre-set test case library stores the feature conditions of various illegal and abnormal transactions for quickly identifying risky requests.

[0046] For example, after the batch payment request of merchant M001 passes the dynamic rate limiting check, the system parses the request and obtains the transaction feature vector (including merchant number M001, transaction type is batch payment, business category is UnionPay payment, transaction amount is 100,000 yuan) and transaction message (including complete transaction information, merchant information, and institution information). Then, the transaction feature vector is matched with cases in the preset test case library to check whether the request is an illegal transaction.

[0047] In some embodiments, such as Figure 6 As shown, in step S40, which involves matching the transaction feature vector to a preset test case library, the specific steps include the following: S41: Obtain key feature information based on the transaction feature vector, wherein the key feature information includes merchant number, transaction type, business category and transaction amount; S42: Traverse the preset matching conditions of each test case in the preset test case library; S43: Compare and verify the key feature information with the preset matching conditions one by one; S44: If the key feature information is consistent with all the preset matching conditions of a test case, then the match is determined to be successful; S45: If the key feature information is inconsistent with the preset matching conditions of all test cases, then it is determined that the match is not successful.

[0048] The transaction feature vector contains various transaction-related information. It is necessary to extract key features relevant to risk assessment, focusing on core risk points to improve matching efficiency and accuracy, and avoiding irrelevant information from interfering with the risk assessment results. Specifically, the merchant ID is used to identify the merchant, the transaction type distinguishes transaction categories (e.g., payment, refund, transfer), the business category distinguishes transaction channels (e.g., UnionPay, China UnionPay), and the transaction amount identifies abnormal transactions (e.g., large-amount illegal transactions). For example, based on the transaction feature vector of merchant M001, the key feature information extracted is: merchant ID M001, transaction type is batch payment, business category is UnionPay payment, and transaction amount is 100,000 yuan. These four core features are then used for subsequent matching with the test case library.

[0049] The pre-set test case library contains multiple test cases, each corresponding to a type of illegal or abnormal transaction, and includes clear pre-set matching conditions (e.g., "Merchant ID M002 + Batch Payment + Transaction Amount > 50,000 RMB" corresponds to a large-amount illegal transaction). The system iterates through the matching conditions of all test cases to ensure no risk scenario is overlooked, achieving comprehensive pre-emptive risk screening. For example, the pre-set test case library contains three core test cases: Case 1 (matching condition: Merchant ID M001 + Batch Payment + Transaction Amount > 150,000 RMB), Case 2 (matching condition: Any merchant + UnionPay payment + Transaction Amount < 1 RMB), and Case 3 (matching condition: Merchant ID M003 + Batch Payment + Business Category is UnionPay payment). The system iterates through the matching conditions of these three cases and compares them with the extracted key feature information.

[0050] The extracted key feature information (merchant ID, transaction type, business category, transaction amount) is compared one by one with the preset matching conditions for each test case to ensure the comprehensiveness and accuracy of the comparison and avoid risk requests going undetected due to omissions. The comparison rules are clearly defined: a match is considered successful only if all fields of the key feature information match all the fields of the matching conditions. For example, comparing the key feature information (M001, batch payment, UnionPay payment, 100,000 yuan) with the matching conditions of Case 1 (M001, batch payment, no business category restriction, >150,000 yuan), the transaction amount is not met, resulting in a no match; comparing it with the matching conditions of Case 2 (any merchant, UnionPay payment, no transaction type restriction, <1 yuan), neither the transaction type nor the transaction amount is met, resulting in a no match; comparing it with the matching conditions of Case 3 (M003, batch payment, UnionPay payment, no amount restriction), the merchant ID and business category are not met, resulting in a no match.

[0051] If the key feature information is completely consistent with all the preset matching conditions of a certain test case, it indicates that the external request is a violation or abnormal transaction, and the match is determined to be successful. At this time, a simulated response should be returned, and the actual transaction should not be forwarded to avoid the spread of risk. At the same time, a risk log should be recorded for subsequent investigation.

[0052] If the key feature information does not match the matching conditions of all test cases in the preset test case library, it indicates that the external request is a legitimate and normal transaction request. The match is determined to be unsuccessful, and the subsequent routing and forwarding stage is entered to forward the transaction message to the corresponding business processing end to complete the actual transaction processing.

[0053] S50: If the transaction feature vector matches a test case in the preset test case library, a simulated response is returned.

[0054] When a transaction feature vector matches a test case, it indicates that the request has a risk of being illegal or abnormal. To avoid the spread of risk, the actual transaction is not forwarded. Instead, a simulated response (a message simulating a successful transaction, a failed transaction, or a transaction in progress) is returned. This can meet the needs of the test scenario, prevent the risk of fund security and data leakage caused by illegal transactions, and at the same time, it does not affect the flow of normal transactions.

[0055] For example, the bulk payment request (transaction amount of 160,000 yuan) of the above merchant M001 matches Case 1 (large-amount illegal transaction). The system does not forward the transaction message, but returns a simulated response: "Transaction is being processed, please check later". At the same time, it records the risk log and marks the request as a large-amount illegal transaction, which is convenient for staff to investigate later.

[0056] S60: If the transaction feature vector does not match a test case in the preset test case library, the transaction message is forwarded according to the target routing rules.

[0057] When the transaction feature vector does not match the test case, it indicates that the request is a legitimate and normal transaction request. According to the target routing rules, the parsed transaction message should be accurately forwarded to the corresponding business processing end (such as the NetsUnion business processing node, UnionPay business processing node, merchant settlement node) to ensure that the transaction can be processed normally, and at the same time achieve accurate transaction routing to improve transaction flow efficiency.

[0058] For example, if the batch payment request (transaction amount of 100,000 yuan) of the above merchant M001 does not match the test case, the system will forward the transaction message to the Netlink EPCC business processing node according to the target routing rules, and the node will complete the subsequent processing of the batch payment (such as fund deduction and transaction accounting).

[0059] In some embodiments, such as Figure 7 As shown, in step S60, that is, forwarding the transaction message according to the target routing rules, the specific steps include the following: S61: Extract the business type, interface code, routing identifier, and transaction institution information from the transaction message; S62: Match routing rules based on the business type, the interface code, the routing identifier, and the transaction institution information to obtain the target routing rule; S63: Confirm the target forwarding link according to the target routing rules, and forward the transaction message to the corresponding service processing terminal according to the target forwarding link.

[0060] Matching target routing rules requires extracting core information from transaction messages, such as business type (e.g., batch payment, single refund), interface code, routing identifier, and transaction institution information. This information is the core basis for determining target routing rules and target forwarding links, ensuring the accuracy of route matching and avoiding transaction failures due to incorrect route matching.

[0061] From the transaction message of merchant M001 above, the core information is extracted as follows: the business type is batch payment, the interface code is BATCHPAY001, the routing identifier is ROUTE-EPCC-001, the transaction institution information is the sending institution ORG001, and the accepting institution is the Netlink EPCC node.

[0062] The preset routing rules contain multiple sets of routing matching conditions. Each set of rules corresponds to a business scenario and a transaction channel. By extracting the business type, interface code, routing identifier, and transaction institution information, the preset routing rules are matched to determine a unique target routing rule, ensuring the accuracy of routing matching and adapting to multi-channel and multi-type transaction needs.

[0063] For example, based on the extracted core information (batch payment, BATCHPAY001, ROUTE-EPCC-001, ORG001), the preset routing rules are matched to determine the target routing rule as: "Batch payment business + interface BATCHPAY001 + route identifier ROUTE-EPCC-001 + sending agency ORG001 → forwarded to the Netlink EPCC business processing node".

[0064] The target routing rule contains the corresponding target forwarding link (i.e. the transmission path of the transaction message). After confirming the target forwarding link, the transaction message is forwarded to the corresponding business processing terminal according to the link, ensuring that the transaction message can reach the processing node accurately and efficiently to complete the subsequent transaction processing, while ensuring the security and stability of the transaction link.

[0065] For example, based on the target routing rules, the target forwarding link is confirmed to be "financial transaction gateway → Netlink EPCC access node → Netlink EPCC business processing node". The system forwards the transaction message of merchant M001 to the Netlink EPCC business processing node according to this link to complete the subsequent processing of batch payment.

[0066] In some embodiments, such as Figure 8 As shown, the method further includes the following steps: S70: A transaction message processor obtained by matching the routing identifier, and a corresponding network packet information is determined based on the transaction message processing; S80: Write the network packet information into the thread context to complete the binding of the current transaction request with the network packet.

[0067] Each routing identifier corresponds one-to-one with a transaction message processor. Different transaction types and channels correspond to different transaction message processors. Each transaction message processor belongs to a network packet. By matching the routing identifier to the corresponding transaction message processor, the network packet information corresponding to the transaction request can be determined. For example, the batch payment request of merchant M001 mentioned above has a routing identifier of ROUTE-EPCC-001. By matching this routing identifier, the corresponding transaction message processor (the dedicated processor for batch payments through UnionPay) is obtained. This processor belongs to the "UnionPay Transaction Packet". Therefore, the network packet information corresponding to this transaction request is determined to be the "UnionPay Transaction Packet".

[0068] By writing the determined network group information into the thread context, the transaction request is bound to the network group throughout the entire process and the link is transparently transmitted. Subsequently, based on the network group information, the transaction request can be subjected to group-level traffic isolation, cluster load balancing, group-specific rate limiting control, full-link transaction monitoring, and log-level isolation and aggregation. At the same time, the network group can be used for fault location, abnormal circuit breaking, priority scheduling, and operation and maintenance gray-scale management, so as to achieve refined service governance by channel, by business, and by group, and further improve the operational stability, observability, and risk management capabilities of the financial transaction gateway.

[0069] As can be seen, the above scheme can generate authentication key combinations and rate limiting dimensions based on external requests, and perform multi-level authentication verification on the authentication key combinations to prevent unauthorized access. After the verification passes, the external requests are dynamically rate-limited according to the rate limiting dimensions to prevent traffic attacks. Only after both authentication verification and rate limiting checks pass will a preset test case library be matched based on the transaction feature vector. When the transaction feature vector matches a test case, a simulated response is returned. When the feature transaction vector does not match a test case, the transaction message is forwarded according to the target routing rules. This not only enables permission checks and traffic checks, but also allows for security testing through matching test cases to prevent anomalies.

[0070] 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.

[0071] In one embodiment, a financial transaction gateway routing device is provided, which corresponds one-to-one with the financial transaction gateway routing method described in the above embodiments. For example... Figure 9 As shown, the financial transaction gateway routing device includes an acquisition module 101, a verification module 102, a checking module 103, a matching module 104, a return module 105, and a forwarding module 106. Detailed descriptions of each functional module are as follows: The acquisition module 101 is used to acquire external requests and generate authentication combination keys and rate limiting dimensions based on the external requests; Verification module 102 is used to perform multi-level authentication verification on the authentication combination key; The inspection module 103 is used to perform dynamic rate limiting checks on the external request according to the rate limiting dimension after the multi-level authentication verification is passed. The matching module 104 is used to parse the external request after the dynamic rate limiting check passes to obtain the transaction feature vector and transaction message, and match the transaction feature vector with a preset test case library. Return module 105 is used to return a simulated response if the transaction feature vector matches a test case in the preset test case library; The forwarding module 106 is used to forward the transaction message according to the target routing rules if the transaction feature vector does not match a test case in the preset test case library.

[0072] In one embodiment, the acquisition module 101 is specifically used for: Extract the gateway identifier, routing identifier, sending or receiving agency number, and message type from the external request, and concatenate them into the authentication key in a fixed format; The URL path, interface code, sending or receiving agency, and message type are extracted from the external request and combined to form the rate limiting dimension.

[0073] In one embodiment, the verification module 102 is specifically used for: Retrieve local permission cache based on the authentication key combination; Verify whether the interface corresponding to the external request is in the preset interface whitelist based on the local permission cache; The local permission cache is used to verify whether the organization corresponding to the external request has the access permission to the corresponding interface; The local permission cache is used to verify whether the merchant ID associated with the external request is within the preset authorization range.

[0074] In one embodiment, the inspection module 103 is specifically used for: Generate rate-limited resource names based on the rate-limiting dimensions; Based on the rate-limiting resource name, read the rate-limiting threshold corresponding to the rate-limiting resource name from the configuration center; If the rate limiting threshold is 0, then the rate limiting resource name will not be rate-limited; If the rate limiting threshold is not 0, a rate limiter is created based on the rate limiting threshold, and a dynamic rate limiting check is performed on the rate-limited resource name based on the rate limiter.

[0075] In one embodiment, the matching module 104 is specifically used for: Key feature information is obtained based on the transaction feature vector, wherein the key feature information includes merchant number, transaction type, business category and transaction amount; Iterate through the preset matching conditions of each test case in the preset test case library; The key feature information is compared and verified one by one with the preset matching conditions; If the key feature information matches all the preset matching conditions of a test case, then the match is determined to be successful; If the key feature information is inconsistent with the preset matching conditions of all test cases, then the match is determined to be unsuccessful.

[0076] In one embodiment, the forwarding module 106 is specifically used for: Extract the business type, interface code, routing identifier, and transaction institution information from the transaction message; The target routing rule is obtained by matching routing rules based on the business type, the interface code, the routing identifier, and the transaction institution information; The target forwarding link is determined according to the target routing rules, and the transaction message is forwarded to the corresponding service processing terminal according to the target forwarding link.

[0077] In one embodiment, the financial transaction gateway routing device further includes: The confirmation module is used to obtain the transaction message processor based on the routing identifier and to determine the corresponding network packet information based on the transaction message processing. The writing module is used to write the network packet information into the thread context, thereby completing the binding of the current transaction request with the network packet.

[0078] This invention provides a financial transaction gateway routing device that can generate authentication combination keys and rate limiting dimensions based on external requests. It performs multi-level authentication verification on the authentication combination keys to prevent unauthorized access. After successful verification, it dynamically limits the external request based on the rate limiting dimensions to prevent traffic attacks. Only after both authentication verification and rate limiting checks pass will it match a preset test case library based on the transaction feature vector. When the transaction feature vector matches a test case, a simulated response is returned; when the transaction feature vector does not match a test case, the transaction packet is forwarded according to the target routing rules. This not only enables permission checks and traffic checks but also allows for security testing through test case matching to prevent anomalies.

[0079] Specific limitations regarding the financial transaction gateway routing device can be found in the limitations of the financial transaction gateway routing method described above, and will not be repeated here. Each module in the aforementioned financial transaction gateway routing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0080] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 10As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a financial transaction gateway routing method on the server side.

[0081] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 11 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements the functions or steps of a financial transaction gateway routing method on the client side.

[0082] In one embodiment, 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 perform the following steps: Obtain external requests and generate authentication combination keys and rate limiting dimensions based on the external requests; Perform multi-level authentication and verification on the authentication key combination; After the multi-level authentication and verification are passed, the external request is dynamically rate-limited according to the rate-limiting dimension. After the dynamic rate limiting check passes, the external request is parsed to obtain the transaction feature vector and transaction message, and a preset test case library is matched according to the transaction feature vector; If the transaction feature vector matches a test case in the preset test case library, a simulated response is returned; If the transaction feature vector does not match a test case in the preset test case library, the transaction message is forwarded according to the target routing rules.

[0083] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Obtain external requests and generate authentication combination keys and rate limiting dimensions based on the external requests; Perform multi-level authentication and verification on the authentication key combination; After the multi-level authentication and verification are passed, the external request is dynamically rate-limited according to the rate-limiting dimension. After the dynamic rate limiting check passes, the external request is parsed to obtain the transaction feature vector and transaction message, and a preset test case library is matched according to the transaction feature vector; If the transaction feature vector matches a test case in the preset test case library, a simulated response is returned; If the transaction feature vector does not match a test case in the preset test case library, the transaction message is forwarded according to the target routing rules.

[0084] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0085] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0086] Those skilled in the art will clearly 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 above functions 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.

[0087] 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.

[0088] The above-described 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 financial transaction gateway routing method, characterized in that, include: Obtain external requests and generate authentication combination keys and rate limiting dimensions based on the external requests; Perform multi-level authentication and verification on the authentication key combination; After the multi-level authentication and verification are passed, the external request is dynamically rate-limited according to the rate-limiting dimension. After the dynamic rate limiting check passes, the external request is parsed to obtain the transaction feature vector and transaction message, and a preset test case library is matched according to the transaction feature vector; If the transaction feature vector matches a test case in the preset test case library, a simulated response is returned; If the transaction feature vector does not match a test case in the preset test case library, the transaction message is forwarded according to the target routing rules.

2. The method as described in claim 1, characterized in that, The process of obtaining external requests and generating authentication key combinations and rate limiting dimensions based on the external requests includes: Extract the gateway identifier, routing identifier, sending or receiving agency number, and message type from the external request, and concatenate them into the authentication key in a fixed format; The URL path, interface code, sending or receiving agency, and message type are extracted from the external request and combined to form the rate limiting dimension.

3. The method as described in claim 1, characterized in that, The multi-level authentication verification of the authentication key includes: Retrieve local permission cache based on the authentication key combination; Verify whether the interface corresponding to the external request is in the preset interface whitelist based on the local permission cache; The local permission cache is used to verify whether the organization corresponding to the external request has the access permission to the corresponding interface; The local permission cache is used to verify whether the merchant ID associated with the external request is within the preset authorization range.

4. The method as described in claim 1, characterized in that, The dynamic rate limiting check on the external request based on the rate limiting dimension includes: Generate rate-limited resource names based on the rate-limiting dimensions; Based on the rate-limiting resource name, read the rate-limiting threshold corresponding to the rate-limiting resource name from the configuration center; If the rate limiting threshold is 0, then the rate limiting resource name will not be rate-limited; If the rate limiting threshold is not 0, a rate limiter is created based on the rate limiting threshold, and a dynamic rate limiting check is performed on the rate-limited resource name based on the rate limiter.

5. The method as described in claim 1, characterized in that, The step of matching a preset test case library based on the transaction feature vector includes: Key feature information is obtained based on the transaction feature vector, wherein the key feature information includes merchant number, transaction type, business category and transaction amount; Iterate through the preset matching conditions of each test case in the preset test case library; The key feature information is compared and verified one by one with the preset matching conditions; If the key feature information matches all the preset matching conditions of a test case, then the match is determined to be successful; If the key feature information is inconsistent with the preset matching conditions of all test cases, then the match is determined to be unsuccessful.

6. The method as described in claim 1, characterized in that, The forwarding of the transaction message according to the target routing rules includes: Extract the business type, interface code, routing identifier, and transaction institution information from the transaction message; The target routing rule is obtained by matching routing rules based on the business type, the interface code, the routing identifier, and the transaction institution information; The target forwarding link is determined according to the target routing rules, and the transaction message is forwarded to the corresponding service processing terminal according to the target forwarding link.

7. The method as described in claim 1, characterized in that, The method further includes: The transaction message processor is obtained by matching the routing identifier, and the corresponding network packet information is determined based on the transaction message processing. The network packet information is written into the thread context to complete the binding of the current transaction request with the network packet.

8. A financial transaction gateway routing device, characterized in that, include: The acquisition module is used to acquire external requests and generate authentication combination keys and rate limiting dimensions based on the external requests; The verification module is used to perform multi-level authentication verification on the authentication key combination. The inspection module is used to perform dynamic rate limiting checks on the external request based on the rate limiting dimension after the multi-level authentication and verification are passed. The matching module is used to parse the external request to obtain the transaction feature vector and transaction message after the dynamic rate limiting check passes, and to match the transaction feature vector with a preset test case library. The return module is used to return a simulated response if the transaction feature vector matches a test case in the preset test case library; The forwarding module is used to forward the transaction message according to the target routing rules if the transaction feature vector does not match a test case in the preset test case library.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the financial transaction gateway routing 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 steps of the financial transaction gateway routing method as described in any one of claims 1 to 7.

Images