Quota control method, system, device and storage medium

Abstract

The application discloses a quota control method, system, device and storage medium, and relates to the technical field of computer data processing, and comprises the following steps: collecting a transaction order, and acquiring a quota code satisfying a preset hit condition according to a scene type of the transaction order; checking protocol information associated with the transaction order based on a preset protocol inspection strategy corresponding to the quota code to obtain a protocol checking result; if the protocol checking result is that the transaction is allowed to be performed, determining a quota threshold corresponding to the transaction order based on a preset quota threshold acquisition strategy; and performing quota checking and processing on the transaction order based on the quota threshold. The application realizes quota control through strategy configuration, does not need to be modified by hard coding, simplifies redundant logic, and effectively improves control flexibility and operation and maintenance efficiency.

Description

Technical Field

[0001] This application relates to the field of computer data processing technology, and in particular to quota control methods, systems, devices, and storage media. Background Technology

[0002] In existing protocol limit management scenarios, traditional limit verification methods often involve modifying code and adding control logic. Whenever a new type of protocol limit check rule is added on the business side, developers need to intrude into the existing business code to write custom judgment and verification logic, which has many obvious drawbacks.

[0003] On the one hand, frequent modifications to business code can significantly increase code invasiveness, easily disrupting the original system's operating logic and increasing system vulnerabilities. On the other hand, the scattered writing of various limit verification logics can easily lead to a large amount of redundant and repetitive functional code, increasing system complexity and failing to meet the requirements of code robustness.

[0004] Therefore, there is an urgent need for a quota control method that can effectively reduce code intrusion, simplify redundant verification logic, and significantly improve the flexibility, versatility, and overall operational efficiency of protocol quota control.

[0005] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The main purpose of this application is to provide a limit checking method, system, device, and storage medium, which aims to solve the technical problem of how to reduce code intrusion and simplify redundant verification logic in protocol limit management scenarios, so as to improve the flexibility, versatility, and overall operation and maintenance efficiency of protocol limit management.

[0007] To achieve the above objectives, this application proposes a quota control method, which includes: Collect transaction orders and, based on the scenario type of the transaction orders, obtain the limit codes that meet the preset hit conditions; Based on the preset protocol checking strategy corresponding to the limit code, the protocol information associated with the transaction order is verified to obtain the protocol verification result; If the protocol verification result indicates that the transaction is allowed, then the limit threshold corresponding to the transaction order is determined based on the preset limit threshold acquisition strategy. Based on the aforementioned limit threshold, limit checks and processing are performed on the transaction orders.

[0008] In one embodiment, the step of obtaining a limit code that meets preset matching conditions based on the scenario type of the transaction order includes: Extract the business code and transaction mode from the transaction order; Based on the preset matching rules corresponding to the scenario type, the business code and the transaction mode are used to determine whether the transaction order meets the conditional expression in the preset hit conditions; If the conditions are met, the limit code corresponding to the transaction order is obtained.

[0009] In one embodiment, the step of verifying the protocol information associated with the transaction order based on the preset protocol checking strategy corresponding to the limit code to obtain the protocol verification result includes: The preset protocol inspection strategy is parsed to obtain the protocol mode, protocol dimension, protocol elements, and protocol processing entity class; If the protocol processing entity class is empty, then a general protocol verification process is executed according to the protocol mode, protocol dimension and protocol elements to obtain the corresponding protocol verification result; If the protocol processing entity class is not empty, then the protocol processing entity class is called to verify the protocol information, and the protocol verification result is determined based on the returned result.

[0010] In one embodiment, the step of performing a general protocol verification process based on the protocol mode, protocol dimension, and protocol elements to obtain the corresponding protocol verification result includes: Based on the protocol dimension and the protocol element, determine the target verification information that matches the transaction order; Based on the target verification information, query the protocol mode; When the protocol mode is whitelist mode, check whether the protocol information exists in the preset whitelist and is in a valid state; If the protocol information exists in the preset whitelist and is in a valid state, then the protocol verification result is determined to allow the transaction; When the protocol mode is blacklist mode, if the protocol information is not in the preset blacklist, the protocol verification result is determined to allow the transaction.

[0011] In one embodiment, the step of calling the protocol processing entity class to verify the protocol information and determining the protocol verification result based on the returned result includes: Based on the entity class processed by the protocol, a target independent protocol table matching the scenario type of the transaction order is determined; The target independent protocol table is invoked to verify the protocol information and generate a verification return result. If the verification returns a successful result, then the protocol verification result is determined to allow the transaction. If the verification returns a result indicating that the verification failed, then the protocol verification result is determined to be that the transaction is not allowed.

[0012] In one embodiment, the step of determining the limit threshold corresponding to the transaction order based on a preset limit threshold acquisition strategy includes: Detect whether a threshold processing entity class exists in the transaction order; If the threshold processing entity class does not exist, the limit threshold is extracted based on the currency, threshold type, and threshold element corresponding to the limit code. If the threshold processing entity class exists, the transaction order is subjected to threshold processing according to the preset acquisition rules to generate the limit threshold.

[0013] In one embodiment, the step of performing limit checks and processing on the transaction order based on the limit threshold includes: The cumulative value of the transaction order is obtained according to the preset cumulative limit type, cumulative limit mode and processing cycle; Based on a preset limit check flag, determine whether the cumulative value exceeds the limit threshold; If the limit is exceeded, the transaction order is determined to be disallowed and the corresponding over-limit return code is returned; If the limit is not exceeded, the transaction order is determined to be a permitted transaction, and the cumulative value is updated according to the preset limit accumulation flag; When a limit accumulation processing entity class is detected in the transaction order, the limit accumulation processing entity class is called to perform the corresponding limit check and accumulation processing.

[0014] Furthermore, to achieve the above objectives, this application also proposes a quota control system, which includes: The quota code acquisition module is used to collect transaction orders and acquire quota codes that meet preset hit conditions according to the scenario type of the transaction orders. The protocol detection module is used to verify the protocol information associated with the transaction order based on the preset protocol checking strategy corresponding to the limit code, and obtain the protocol verification result. The threshold acquisition module is used to determine the limit threshold corresponding to the transaction order based on a preset limit threshold acquisition strategy if the protocol verification result indicates that the transaction is allowed. The transaction processing module is used to perform limit checks and processing on the transaction orders based on the limit threshold.

[0015] In addition, to achieve the above objectives, this application also proposes a quota control device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the quota control method described above.

[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the quota control method described above.

[0017] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the quota control method described above.

[0018] This application proposes a limit control method, system, device, and storage medium. The method includes: collecting transaction orders and obtaining limit codes that meet preset hit conditions based on the scenario type of the transaction orders; verifying the protocol information associated with the transaction orders based on a preset protocol check strategy corresponding to the limit codes, and obtaining a protocol check result; if the protocol check result allows the transaction, determining the limit threshold corresponding to the transaction orders based on a preset limit threshold acquisition strategy; and performing limit checks and processing on the transaction orders based on the limit threshold. This solution configurates and modularizes the limit control process, unifying and centrally managing the limit check logic that was originally scattered in various business codes, thus decoupling business codes from limit control functions and significantly reducing code intrusion. Simultaneously, through the dynamic matching and execution of preset limit codes, protocol check strategies, and limit threshold acquisition strategies, it avoids repeatedly writing similar check code for different scenarios, simplifies redundant check logic, and effectively improves control flexibility and operational efficiency. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating an embodiment of the quota control method in this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the quota control method of this application; Figure 3 This is a flowchart illustrating Embodiment 3 of the quota control method of this application; Figure 4This is a schematic diagram of the module structure of the quota control system according to an embodiment of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the quota control method in the embodiments of this application.

[0022] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0024] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0025] The main solution of this application embodiment is as follows: collect transaction orders, and obtain limit codes that meet preset hit conditions according to the scenario type of the transaction orders; verify the protocol information associated with the transaction orders based on the preset protocol checking strategy corresponding to the limit codes, and obtain the protocol verification result; if the protocol verification result is that the transaction is allowed, determine the limit threshold corresponding to the transaction orders based on the preset limit threshold acquisition strategy; and perform limit checks and processing on the transaction orders based on the limit threshold.

[0026] In this embodiment, for ease of description, the quota control system will be used as the implementing entity for the following description.

[0027] Existing technologies typically implement new protocol limit checks by modifying code and adding control logic. Each time a new limit control is added, the code needs to be modified and control logic added, which is highly intrusive to the code and increases the risk of system vulnerabilities. In addition, the code has a high degree of duplication, which increases the complexity of the system and does not meet the requirements of code robustness.

[0028] This application provides a solution that enables differentiated adaptation for different types of new quota control: for general quota scenarios, only new parameter configurations are needed to reuse the original processing logic, achieving zero code modification and no impact on existing business; for reusable new quota scenarios, branches can be added to the general processing logic, with a small scope of modification and controllable impact; for personalized quota scenarios with low reusability, a dedicated processing class is configured independently, decoupled from the general logic, without affecting existing code, effectively reducing code intrusion and redundancy, and improving system robustness and quota expansion flexibility.

[0029] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions. The following description uses a personal computer as an example to illustrate this embodiment and the subsequent embodiments.

[0030] Explanation of proper nouns used in this embodiment: Quota code: To distinguish each type of protocol quota to be processed, a three-digit code value is defined for the quota.

[0031] Limit threshold: The upper limit of the limit control, that is, the upper limit of the limit within the limit control period (day, month, year, etc.).

[0032] Based on this, the embodiments of this application provide a limit control method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the quota control method of this application.

[0033] In this embodiment, the quota control method includes steps S10 to S40: Step S10: Collect transaction orders and obtain the limit code that meets the preset hit conditions according to the scenario type of the transaction orders; It should be noted that the preset matching conditions include, but are not limited to, multi-dimensional matching conditions and condition combination expressions corresponding to the transaction scenario.

[0034] In this embodiment, different transaction scenarios correspond to different limit processing rules. This embodiment pre-configures and binds limit codes to corresponding matching conditions based on the scenario dimension. After a transaction order is collected, limit codes that meet the preset matching conditions are filtered out according to the actual transaction scenario corresponding to the order. This embodiment supports multi-condition configuration, allowing multiple matching conditions to be configured for a single limit code, and setting corresponding condition expressions. The limit code is deemed effective only when the transaction order data satisfies the combination logic of the condition expressions, and the corresponding limit processing flow must be executed. If subsequent business scenarios require the addition of new limit processing rules, no modification to the business code is needed; only the corresponding limit code and the matching matching conditions and condition expressions need to be added for rapid expansion.

[0035] Optionally, step S10 may also include steps S11 to S13: Step S11: Extract the business code and transaction mode from the transaction order; It should be noted that the business code is an identifier field used to uniquely distinguish the type of transaction business. The transaction mode is an identifier field used to define the transaction execution method and transaction channel. In this embodiment, the combination of the business code and the transaction mode fields uniquely identifies a type of transaction scenario, thereby achieving accurate classification of transaction scenarios.

[0036] Step S12: Based on the preset matching rules corresponding to the scenario type, use the business code and the transaction mode to determine whether the transaction order meets the condition expression in the preset hit conditions; The preset matching rules refer to a set of rules configured for a specific transaction scenario, which includes a limit code, multiple independent hit conditions, and conditional expressions.

[0037] The conditional expression is a logical combination rule for multiple independent hit conditions in a single scenario, supporting logical combinations such as AND and OR, used to accurately determine whether the corresponding limit code is triggered. For example, the conditional expression can be configured as "1 AND 2", meaning that a transaction order must simultaneously meet the first hit condition and the second hit condition to be matched and approved. The preset hit condition can be a comparison rule between specific business parameter fields in the transaction order and preset thresholds or enumerated values.

[0038] In this embodiment, firstly, based on the business code and transaction mode, the corresponding limit code and associated set of matching conditions are indexed from a preset configuration table; then, the conditional expression is parsed to determine the business parameter fields that need to be verified, and it is determined whether the business parameter fields conform to the logical operation result in the conditional expression. The business parameter fields include, but are not limited to, fields such as transaction status identifier and merchant type.

[0039] Step S13: If the conditions are met, obtain the limit code corresponding to the transaction order.

[0040] In this embodiment, if a transaction order satisfies the conditional expression corresponding to the current transaction scenario, it is determined that the limit rule has been hit, and the target limit code corresponding to the transaction scenario and the combination of conditions is obtained.

[0041] For example, the combination of business code and transaction mode uniquely identifies a type of transaction scenario. CG1 is the limit code configured under this type of transaction. Only when the transaction order simultaneously meets the two preset hit conditions: condition 1 (OVSTAG EQ Y) and condition 2 (MCHTYP IN NEKCFG), and matches the corresponding "AND" logical condition expression, can the CG1 limit code be successfully hit and the subsequent limit processing process be entered.

[0042] Through the above steps, multi-condition, configurable quota codes can be accurately matched based on transaction scenarios. Quota rules can be flexibly added and iterated without intruding on business code, effectively reducing code invasiveness and logical redundancy, and improving the adaptability and scalability of quota management.

[0043] Step S20: Based on the preset protocol checking strategy corresponding to the limit code, verify the protocol information associated with the transaction order to obtain the protocol verification result; It should be noted that the aforementioned agreement information refers to the transaction-related agreement data activated by the user, including but not limited to key information such as activation status, agreement validity period, and agreement-compatible transaction dimensions, which serves as the basis for determining whether the user's current transaction is compliant.

[0044] In this embodiment, the purpose of the protocol check is to verify whether the user's current protocol information allows the execution of this transaction. The core of the routine check is to determine whether the user's protocol status is valid and whether the protocol is within its validity period. Since the core logic of the protocol check for most limit codes is consistent and does not require differentiated customization, this embodiment sets up a general protocol check code to enable the general code to adapt to multiple limit code configurations and avoid code redundancy. Only for special limit codes with complex check elements and no general reuse scenarios, personalized processing logic is configured separately to balance generality and specificity.

[0045] Optionally, step S20 may also include steps S21 to S23: Step S21: parse the preset protocol inspection strategy to obtain the protocol mode, protocol dimension, protocol elements and protocol processing entity class; Among them, the protocol mode includes, but is not limited to, whitelist mode or blacklist mode; the protocol dimension is the verification dimension of the limit protocol, including but not limited to card dimension, customer dimension, etc.; the protocol element is the auxiliary condition field required to complete the protocol verification; the protocol processing entity class is an independent processing class used to carry personalized protocol verification logic, which is used to adapt to special verification needs that have no reuse value and are specific to the scenario.

[0046] Step S22: If the protocol processing entity class is empty, then execute the general protocol verification process according to the protocol mode, protocol dimension and protocol elements to obtain the corresponding protocol verification result. Since the protocol check logic for most quota codes is uniform and undifferentiated, and no separate code needs to be developed, a general verification process is used to complete the protocol check when the current quota code is not configured with a protocol processing entity class.

[0047] Specifically, after parsing and obtaining the protocol mode, protocol dimension, and protocol elements corresponding to the current limit code, the user protocol subject to be verified is identified based on the protocol dimension. All verification conditions are then completed by combining the configured multiple protocol elements. The compliance of the user protocol is verified according to a preset whitelist or blacklist verification mode, primarily checking whether the protocol status is normal and whether the protocol is within its validity period. After verification, the protocol verification result is output. For example, if the verification passes, it indicates that the current transaction order is allowed to proceed; otherwise, an error is reported or the limit code is ignored.

[0048] Step S23: If the protocol processing entity class is not empty, the protocol processing entity class is called to verify the protocol information, and the protocol verification result is determined based on the returned result.

[0049] In this embodiment, when a protocol processing entity class is identified as being configured with the current quota code, the customized verification logic of that entity class is invoked to independently complete the protocol information verification and rule judgment in this scenario, and output the corresponding personalized verification results, including different conclusions such as verification passed, verification failed, and ignoring the current quota processing. The personalized processing logic is completely decoupled from the general processing logic and runs independently, without intruding on or affecting existing general code and original business logic, achieving flexible adaptation to special quota scenarios, and the scope of code modification is minimal and the impact is completely controllable.

[0050] Through the above steps, this solution implements a layered processing mechanism that allows for the unified reuse of general logic and the independent development of special logic for protocol verification scenarios. In most scenarios, protocol verification can be completed simply by configuring parameters without code modification. A small number of special scenarios can be developed independently with a controllable impact, effectively reducing code invasiveness and redundancy, and improving the universality, flexibility and robustness of protocol limit verification.

[0051] Step S30: If the protocol verification result indicates that the transaction is allowed, then the limit threshold corresponding to the transaction order is determined based on the preset limit threshold acquisition strategy. It should be noted that the limit threshold is an upper limit standard used to restrict the transaction amount and the number of transactions.

[0052] In this embodiment, some transaction scenarios require upper limits on transaction amounts and transaction frequency. Therefore, the corresponding limit thresholds need to be obtained before checking the limit and number of transactions. This solution supports multi-form and multi-dimensional threshold configuration capabilities. The limit threshold can be a globally fixed configuration value preset by the system or a personalized limit defined by the user. It supports threshold configuration from multiple dimensions such as card, user, and protocol. The threshold acquisition logic is uniform and universal in normal scenarios and can be directly implemented through configuration parameters. For personalized threshold acquisition rules in special scenarios, this solution supports configuring a dedicated personalized threshold processing class to achieve customized acquisition without modifying the main business code. At the same time, each limit code is configured with a corresponding controlled currency to limit the settlement currency corresponding to the current limit threshold, ensuring the accuracy of the currency for amount limit verification.

[0053] Optionally, step S30 may include steps S31 to S33: Step S31: Detect whether there is a threshold processing entity class in the transaction order; The threshold processing entity class is an independent processing class that carries personalized threshold acquisition rules. It is used to adapt to special limit threshold acquisition needs that cannot be covered by general threshold logic, are scenario-specific, and have low reusability, thereby realizing the differentiated extension of limit threshold acquisition logic.

[0054] Step S32: If the threshold processing entity class does not exist, then extract the limit threshold according to the currency, threshold type and threshold element corresponding to the limit code; In this embodiment, if there is no threshold processing entity class, a general threshold acquisition logic is adopted. Specifically, firstly, the limit currency, threshold type, and various threshold elements corresponding to the current limit code are parsed. The threshold acquisition dimension is determined according to the threshold type, including global configuration dimension, card dimension, user dimension, protocol dimension, etc. If the threshold type is processed according to the protocol threshold, the protocol threshold data parsed in the protocol check process is directly reused, and the corresponding currency limit value is matched. Finally, the standard limit threshold corresponding to the current transaction scenario is accurately extracted, which is suitable for most common limit acquisition scenarios.

[0055] Step S33: If the threshold processing entity class exists, then the transaction order is subjected to threshold processing according to the preset acquisition rules to generate the limit threshold.

[0056] In this embodiment, if a threshold processing entity class is configured, it indicates that the threshold acquisition rules for the current transaction scenario are special and cannot be implemented through general configuration. Therefore, the preset acquisition rules of this threshold processing entity class are further invoked, and combined with the transaction order scenario attributes, a personalized threshold adapted to the current transaction is flexibly matched, calculated, and generated from the system's global limit threshold or user-defined limit threshold, thus meeting the threshold acquisition requirements of special business scenarios.

[0057] Through the above steps, this solution achieves a layered acquisition mechanism that combines general configuration acquisition of limit thresholds with personalized customization acquisition. In normal scenarios, only the currency, threshold type, and threshold elements need to be configured to complete the threshold acquisition without code development. In special scenarios, personalized implementation is achieved through independent entity classes, decoupling from existing code, effectively reducing code intrusion and logical redundancy, and accommodating threshold acquisition needs of multiple dimensions, multiple currencies, and multiple modes, greatly improving the flexibility and versatility of limit threshold acquisition.

[0058] Step S40: Based on the limit threshold, perform limit checks and processing on the transaction order.

[0059] In this embodiment, this step targets the limit code configured with limit processing rules, completing the entire process of limit control logic. The core steps include: calculating historical transaction cumulative data and overlaying it with the current transaction data; determining whether the overlaid cumulative value exceeds a preset limit threshold; executing corresponding transaction release or blocking processing according to the limit-exceeding rules; and updating the limit cumulative for transactions that do not exceed the limit. This step supports multiple types of limit control, such as amount and transaction frequency, and distinguishes between daily, monthly, and yearly cumulative periods and multi-dimensional cumulative subjects. It is also compatible with general configuration processing and personalized processing, adapting to various limit-based business scenarios.

[0060] Optionally, step S40 may include steps S41 to S45: Step S41: Obtain the cumulative value of the transaction order according to the preset limit accumulation type, limit accumulation mode and processing cycle; Among them, the limit accumulation type refers to the limit accumulation dimension, including but not limited to card dimension, customer dimension, and document dimension; the limit accumulation mode includes two modes: natural cycle accumulation and rolling cycle accumulation; the processing cycle supports conventional control cycles such as daily, monthly, and yearly.

[0061] In this embodiment, the cumulative statistics subject is determined according to the cumulative limit type pre-configured by the current limit code, the periodic statistics rules are determined according to the cumulative limit mode, and the daily, monthly, and yearly limit or time limit statistics rules that need to take effect are selected by combining the periodic check flags of various limits and times. The historical transaction cumulative values ​​of users under the corresponding dimensions and periods are retrieved to provide basic data for subsequent over-limit judgment.

[0062] Step S42: Determine whether the cumulative value exceeds the limit threshold; In this embodiment, the historical cumulative value is superimposed with the amount or number of transactions of the current transaction to obtain the latest cumulative value. The latest cumulative value is then compared with the limit thresholds for the corresponding currency and dimension obtained in step S30 to determine whether the current transaction triggers the over-limit rule. At the same time, based on various check flags such as single transaction, daily, monthly, and yearly, multi-dimensional over-limit verification judgments for single transaction limit, periodic limit, and periodic number of transactions are completed respectively.

[0063] Step S43: If the limit is exceeded, the transaction order is determined to be disallowed and the corresponding over-limit return code is returned. In this embodiment, if the cumulative value after this transaction exceeds the limit threshold, the current transaction is determined to be excessive. The interception logic is executed according to the preset limit cumulative excess handling rules, the pre-configured limit cumulative excess return code is retrieved, an error message is returned, and the current transaction process is terminated, thereby realizing the excess interception and control.

[0064] Step S44: If the limit is not exceeded, the transaction order is determined to be an allowed transaction, and the cumulative value is updated according to the preset limit accumulation flag. In this embodiment, if the cumulative value does not exceed the limit threshold, the transaction is allowed to proceed normally. Simultaneously, the cumulative limit flags and cumulative transaction count flags for each dimension and period are read, and data updates are completed as needed. This solution achieves differentiated capabilities by either checking only the limit without accumulation or checking for simultaneous automatic accumulation. Specifically, based on preset daily, monthly, and yearly cumulative limit flags and daily, monthly, and yearly cumulative transaction count flags, it selectively updates the cumulative amount and cumulative transaction count for the corresponding period, adapting to diverse business management needs.

[0065] For example, if the limit code is configured to be accumulated by parent account dimension and natural date accumulation mode, and the daily limit check and daily limit accumulation flag are enabled, the system will calculate the cumulative transaction amount under the parent account dimension by natural day, add the current transaction and determine whether it exceeds the limit. If it exceeds the limit, a preset error code will be output to block the transaction; if it does not exceed the limit, it will be allowed normally and the cumulative amount for the day will be updated.

[0066] Step S45: When a limit accumulation processing entity class is detected in the transaction order, the limit accumulation processing entity class is called to perform the corresponding limit check and accumulation processing.

[0067] In this embodiment, for niche quota scenarios that cannot be covered by conventional configuration logic, have special business rules, and low reusability, the system configures a separate quota accumulation processing entity class. If the current quota code is configured with this quota accumulation processing entity class, the above-mentioned general configuration verification and accumulation logic will no longer be executed. Instead, the customized rules of the dedicated entity class will be called to complete the quota check, over-limit judgment, transaction processing, and accumulation update. The personalized logic is deployed independently without modifying the general main code, and the impact is controllable.

[0068] Through the above steps, this solution implements a two-tier architecture that combines configurable general processing for quota checks and accumulation with personalized processing for entity classes. Most daily / monthly / yearly, and multi-dimensional quota / occurrence scenarios can be implemented simply by configuring the dimensions, period, check flags, accumulation flags, and over-limit rules on the page, without requiring any code development. Special scenarios are adapted through independent entity classes, completely avoiding the problem of frequent hard-coding modifications in traditional models. It also supports configurable differentiated capabilities for checks, approvals, and accumulations, compatible with various business scenarios such as "checking without accumulation, accumulating while checking, and intercepting and allowing over-limit access," greatly reducing code intrusion and redundancy, and improving the flexibility, versatility, and scalability of quota management.

[0069] The above-described method collects transaction orders and, based on the transaction order's scenario type, obtains a limit code that meets preset hit conditions. Based on the preset protocol check strategy corresponding to the limit code, the protocol information associated with the transaction order is verified to obtain a protocol verification result. If the protocol verification result allows the transaction, a limit threshold corresponding to the transaction order is determined based on a preset limit threshold acquisition strategy. Based on the limit threshold, limit checks and processing are performed on the transaction order. This solution configurates and modularizes the limit control process, unifying and centrally managing the limit verification logic that was originally scattered across various business codes. This decouples business code from limit control functions, significantly reducing code intrusion. Simultaneously, through the dynamic matching and execution of preset limit codes, protocol check strategies, and limit threshold acquisition strategies, it avoids repeatedly writing similar verification code for different scenarios, simplifies redundant verification logic, and effectively improves control flexibility and operational efficiency.

[0070] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 Further elaborating on step S22, the quota control method also includes steps S221 to S225: Step S221: Based on the protocol dimension and the protocol element, determine the target verification information that matches the transaction order; In this embodiment, the protocol dimension defines the core subject dimension of this protocol verification, such as the customer dimension, card dimension, etc., and the protocol elements are various auxiliary matching conditions required for verification.

[0071] This embodiment first identifies the core user protocol subject corresponding to this verification based on the parsed protocol dimension, and then extracts the corresponding field information from the transaction order and user protocol information in combination with the configured protocol elements, and integrates them to form the complete set of target verification information required for this protocol verification.

[0072] Step S222: Query the protocol mode based on the target verification information; In this embodiment, the target verification information is used as the query basis to retrieve the preset protocol check configuration corresponding to the current limit code, match and query the protocol mode corresponding to the limit code, and determine whether the current verification is a whitelist mode verification or a blacklist mode verification.

[0073] Step S223: When the protocol mode is whitelist mode, check whether the protocol information exists in the preset whitelist and is in a valid state; In this embodiment, the whitelist mode is an admission-based verification rule, where only compliant protocols within the preset whitelist can pass verification. The system queries the user's corresponding protocol data based on the target verification information, performing dual verification to determine whether the protocol has been entered into the whitelist database corresponding to the current limit code. Simultaneously, it verifies whether the protocol status is normal and whether the protocol is within its validity period, excluding abnormal states such as expired, cancelled, or frozen protocols.

[0074] Step S224: If the protocol information exists in the preset whitelist and is in a valid state, then the protocol verification result is determined to allow the transaction. In this embodiment, if the user agreement matches the whitelist and its status is complete and valid, the agreement verification is compliant, and the transaction is allowed. If the agreement does not match the whitelist or its status is invalid or expired, the agreement verification fails, the subsequent processing of the current limit code is ignored, and the overall transaction is not blocked.

[0075] Step S225: When the protocol mode is blacklist mode, check whether the protocol information does not exist in the preset blacklist, and then determine that the protocol verification result is allowed to conduct the transaction.

[0076] In this embodiment, the blacklist mode is an interception-based verification rule, where only abnormal protocols within the blacklist are blocked. The system verifies whether the user's protocol information is not entered into the blacklist corresponding to the current limit code. If the protocol is not in the blacklist, the protocol verification is deemed compliant, and the transaction is allowed to continue; if the protocol is on the blacklist, the verification is deemed to have failed, and the current limit processing is terminated or the transaction is blocked.

[0077] For example, the CG1 limit code is configured in whitelist mode, and the protocol check processing type is to return the protocol flag. When the transaction order matches the corresponding scenario configuration and the protocol information exists in the whitelist and is valid, the protocol verification passes; when the protocol does not exist or the protocol status is invalid or expired, the system does not report an error, but only ignores the verification and subsequent processing of the current CG1 limit code, without affecting the overall transaction process.

[0078] Through the methods described in the above embodiments, the whitelist and blacklist protocol verification modes are broken down into refined processes. Standardized general verification is completed based on configurable protocol dimensions, protocol elements, and protocol modes. This further standardizes the execution logic of general protocol verification. While ensuring the accuracy and completeness of verification, no code development or code intrusion is required throughout the process. Different protocol verification rules can be adapted simply by configuring parameters, which further improves the standardization and scenario adaptability of protocol limit verification.

[0079] Based on the first embodiment of this application, in the third embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2Further elaborating on step S23, the quota control method also includes steps S231 to S234: Step S231: Based on the protocol processing entity class, determine the target independent protocol table that matches the scenario type of the transaction order; In this embodiment, the protocol processing entity class is bound to an independent, personalized protocol data table, which is different from the common configuration form used for general protocol verification. The system matches and retrieves the target independent protocol table adapted to the current transaction scenario type based on the currently active protocol processing entity class identifier. This independent protocol table stores personalized configuration data such as protocol verification rules specific to the special scenario, special access conditions, and differentiated compliance standards, providing dedicated data support for subsequent customized protocol verification.

[0080] Step S232: Call the target independent protocol table, verify the protocol information, and generate a verification return result; In this embodiment, the exclusive verification rules and judgment logic from the target independent protocol table are loaded. Combined with the user agreement information and transaction scenario attributes corresponding to the transaction order, personalized protocol verification calculations that cannot be covered by general verification logic are performed. Compared with standardized general verification, this step can adapt to the protocol access determination of complex, special, and non-standard scenarios, and finally output exclusive personalized verification return results.

[0081] Step S233: If the verification result is successful, then the protocol verification result is determined to allow the transaction. In this embodiment, when the protocol processing entity class passes the verification according to the rules of the independent protocol table, it means that the current user protocol meets the access conditions of the special scenario, the protocol information is compliant and valid, the system determines that the protocol verification result is allowed to proceed with the transaction, and the transaction can normally enter the limit threshold acquisition, limit check and other processes.

[0082] Step S234: If the verification result is that the verification fails, then the protocol verification result is determined to be that the transaction is not allowed.

[0083] In this embodiment, when the personalized verification result is unsuccessful, it indicates that the user agreement does not meet the exclusive agreement access requirements of the current special scenario, and there is a compliance risk or failure to meet business control rules. The system directly determines that the agreement verification fails, terminates the subsequent processing of the current limit code, and intercepts the corresponding over-limit and illegal transactions.

[0084] By binding a dedicated protocol table to an independent entity class, the method described above enables isolated and customized execution of special protocol verification rules. The personalized verification logic is completely decoupled from the general verification logic. No modification to the existing main code is required. It can adapt to niche, complex, and low-reusability special quota scenarios simply by independent configuration and dedicated class development. While ensuring clean, low-intrusion, and high-robust system code, it greatly expands the scenario coverage of protocol quota management and takes into account both the system's generality and adaptability to special scenarios.

[0085] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the quota control method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0086] This application also provides a quota control system; please refer to [reference needed]. Figure 4 The quota control system includes: The limit code acquisition module 10 is used to collect transaction orders and acquire limit codes that meet preset hit conditions according to the scenario type of the transaction orders. The protocol detection module 20 is used to verify the protocol information associated with the transaction order based on the preset protocol checking strategy corresponding to the limit code, and obtain the protocol verification result. The threshold acquisition module 30 is used to determine the limit threshold corresponding to the transaction order based on a preset limit threshold acquisition strategy if the protocol verification result indicates that the transaction is allowed. The transaction processing module 40 is used to perform limit checks and processing on the transaction order based on the limit threshold.

[0087] The quota control system provided in this application, employing the quota control method described in the above embodiments, can solve the technical problem of how to reduce code intrusion and simplify redundant verification logic in protocol quota control scenarios, thereby improving the flexibility, versatility, and overall operational efficiency of protocol quota control. Compared with the prior art, the beneficial effects of the quota control system provided in this application are the same as those of the quota control method provided in the above embodiments, and other technical features of the quota control system are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0088] This application provides a quota control device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the quota control method in the first embodiment described above.

[0089] The following is for reference. Figure 5The diagram illustrates a structural schematic suitable for implementing the quota control device in the embodiments of this application. The quota control device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5 The quota control device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0090] like Figure 5 As shown, the quota control device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the quota control device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the quota control device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows quota control devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0091] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0092] The quota control device provided in this application, employing the quota control method described in the above embodiments, can solve the technical problem of how to reduce code intrusion and simplify redundant verification logic in protocol quota control scenarios, thereby improving the flexibility, versatility, and overall operational efficiency of protocol quota control. Compared with the prior art, the beneficial effects of the quota control device provided in this application are the same as those of the quota control method provided in the above embodiments, and other technical features of this quota control device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0093] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0094] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0095] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the limit control method in the above embodiments.

[0096] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0097] The aforementioned computer-readable storage medium may be included in the quota control device; or it may exist independently and not be assembled into the quota control device.

[0098] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the quota control device, the quota control device performs the following actions: collects transaction orders and, based on the scenario type of the transaction order, obtains a quota code that meets preset hit conditions; verifies the protocol information associated with the transaction order based on a preset protocol check strategy corresponding to the quota code, and obtains a protocol check result; if the protocol check result indicates that the transaction is allowed, it determines the quota threshold corresponding to the transaction order based on a preset quota threshold acquisition strategy; and performs quota checks and processing on the transaction order based on the quota threshold.

[0099] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0100] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0101] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0102] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described quota control method. This solves the technical problem of how to reduce code intrusion and simplify redundant verification logic in protocol quota control scenarios, thereby improving the flexibility, versatility, and overall operational efficiency of protocol quota control. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the quota control method provided in the above embodiments, and will not be elaborated upon here.

[0103] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the quota control method described above.

[0104] The computer program product provided in this application can solve the technical problem of how to reduce code intrusion and simplify redundant verification logic in protocol limit management scenarios, thereby improving the flexibility, versatility, and overall operational efficiency of protocol limit management. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the limit management method provided in the above embodiments, and will not be repeated here.

[0105] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A quota control method, characterized in that, The quota control method includes: Collect transaction orders and, based on the scenario type of the transaction orders, obtain the limit codes that meet the preset hit conditions; Based on the preset protocol checking strategy corresponding to the limit code, the protocol information associated with the transaction order is verified to obtain the protocol verification result; If the protocol verification result indicates that the transaction is allowed, then the limit threshold corresponding to the transaction order is determined based on the preset limit threshold acquisition strategy. Based on the aforementioned limit threshold, limit checks and processing are performed on the transaction orders.

2. The quota control method as described in claim 1, characterized in that, The step of obtaining a limit code that meets preset matching conditions based on the scenario type of the transaction order includes: Extract the business code and transaction mode from the transaction order; Based on the preset matching rules corresponding to the scenario type, the business code and the transaction mode are used to determine whether the transaction order meets the conditional expression in the preset hit conditions; If the conditions are met, the limit code corresponding to the transaction order is obtained.

3. The quota control method as described in claim 1, characterized in that, The step of verifying the protocol information associated with the transaction order based on the preset protocol checking strategy corresponding to the limit code, and obtaining the protocol verification result, includes: The preset protocol inspection strategy is parsed to obtain the protocol mode, protocol dimension, protocol elements, and protocol processing entity class; If the protocol processing entity class is empty, then a general protocol verification process is executed according to the protocol mode, protocol dimension and protocol elements to obtain the corresponding protocol verification result; If the protocol processing entity class is not empty, then the protocol processing entity class is called to verify the protocol information, and the protocol verification result is determined based on the returned result.

4. The quota control method as described in claim 3, characterized in that, The step of performing a general protocol verification process based on the protocol mode, protocol dimension, and protocol elements to obtain the corresponding protocol verification result includes: Based on the protocol dimension and the protocol element, determine the target verification information that matches the transaction order; Based on the target verification information, query the protocol mode; When the protocol mode is whitelist mode, check whether the protocol information exists in the preset whitelist and is in a valid state; If the protocol information exists in the preset whitelist and is in a valid state, then the protocol verification result is determined to allow the transaction; When the protocol mode is blacklist mode, if the protocol information is not in the preset blacklist, the protocol verification result is determined to allow the transaction.

5. The quota control method as described in claim 3, characterized in that, The step of calling the protocol processing entity class to verify the protocol information and determining the protocol verification result based on the returned result includes: Based on the entity class processed by the protocol, a target independent protocol table matching the scenario type of the transaction order is determined; The target independent protocol table is invoked to verify the protocol information and generate a verification return result. If the verification returns a successful result, then the protocol verification result is determined to allow the transaction. If the verification returns a result indicating that the verification failed, then the protocol verification result is determined to be that the transaction is not allowed.

6. The quota control method as described in claim 1, characterized in that, The step of determining the limit threshold corresponding to the transaction order based on the preset limit threshold acquisition strategy includes: Detect whether a threshold processing entity class exists in the transaction order; If the threshold processing entity class does not exist, the limit threshold is extracted based on the currency, threshold type, and threshold element corresponding to the limit code. If the threshold processing entity class exists, the transaction order is subjected to threshold processing according to the preset acquisition rules to generate the limit threshold.

7. The quota control method as described in claim 1, characterized in that, The steps of performing limit checks and processing on the transaction order based on the limit threshold include: The cumulative value of the transaction order is obtained according to the preset cumulative limit type, cumulative limit mode and processing cycle; Determine whether the cumulative value exceeds the limit threshold; If the limit is exceeded, the transaction order is determined to be disallowed and the corresponding over-limit return code is returned; If the limit is not exceeded, the transaction order is determined to be a permitted transaction, and the cumulative value is updated according to the preset limit accumulation flag; When a limit accumulation processing entity class is detected in the transaction order, the limit accumulation processing entity class is called to perform the corresponding limit check and accumulation processing.

8. A quota control system, characterized in that, The quota control system includes: The quota code acquisition module is used to collect transaction orders and acquire quota codes that meet preset hit conditions according to the scenario type of the transaction orders. The protocol detection module is used to verify the protocol information associated with the transaction order based on the preset protocol checking strategy corresponding to the limit code, and obtain the protocol verification result. The threshold acquisition module is used to determine the limit threshold corresponding to the transaction order based on a preset limit threshold acquisition strategy if the protocol verification result indicates that the transaction is allowed. The transaction processing module is used to perform limit checks and processing on the transaction orders based on the limit threshold.

9. A quota control device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the quota control method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the quota control method as described in any one of claims 1 to 7.

Images