Limit control method of digital wallet, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a quota control method of a digital wallet, electronic equipment and a storage medium. The method comprises the following steps: acquiring a transaction request initiated by a digital wallet; when the transaction request is a forward transaction request, according to a transaction scene in the transaction information, an institution level limit parameter and a user limit parameter are determined from a multi-dimensional limit parameter library, the multi-dimensional limit parameter library comprises the institution level limit parameter and the user limit parameter corresponding to the transaction scene, and the user limit parameter comprises the institution level limit parameter and the user limit parameter corresponding to the transaction scene; the institution level limit parameter is determined based on the user risk level and the institution type corresponding to the digital wallet, and the user limit parameter is predetermined for the user; according to the mechanism level limit parameter and the user limit parameter, performing verification processing on transaction information in the transaction request to obtain a limit verification result; and if the quota verification result represents that the transaction request passes verification, performing multi-dimensional quota control on the current transaction operation indicated by the transaction request. According to the method, the flexibility and accuracy of limit control are improved.

Description

Technical Field

[0001] The present application relates to the field of big data technology, and in particular to a limit control method, electronic device, and storage medium for a digital wallet. Background Art

[0002] With the rapid development of financial technology, digital wallets have become an essential component of the modern payment system. However, the increasingly complex financial environment and the proliferation of telecom fraud schemes have placed higher demands on the risk management capabilities of digital wallets. Limit control, a core tool for financial risk management, is a pressing issue as users' expectations for a better payment experience continue to rise. How to achieve differentiated and refined limit management while ensuring fund security has become a pressing issue.

[0003] Traditional digital wallet limit control methods typically place limit verification and limit accumulation in the same module. This involves determining within a single function whether the "current accumulated value + verification amount" is less than the limit. If so, the transaction is allowed; otherwise, the transaction is rejected and an error indicating the limit has been exceeded is thrown. While simple, this approach suffers from logical confusion and high code maintenance costs. While it may initially meet basic financial risk control needs, as financial transactions become increasingly complex and diverse, existing approaches face limitations in flexibility and precision, further limiting the accuracy of digital wallet risk control. Summary of the Invention

[0004] The embodiments of the present application provide a limit control method, electronic device, and storage medium for a digital wallet to address the problems of low flexibility and accuracy in limit control in existing methods, thereby improving the accuracy of risk control for digital wallets.

[0005] In a first aspect, an embodiment of the present application provides a limit control method for a digital wallet, comprising:

[0006] Obtaining a transaction request initiated by a digital wallet; wherein the transaction request includes transaction information;

[0007] When the transaction request is a forward transaction request, the institution-level limit parameters and user limit parameters are determined from the multi-dimensional limit parameter library based on the transaction scenario in the transaction information. The multi-dimensional limit parameter library includes the institution-level limit parameters and user limit parameters corresponding to the transaction scenario. The institution-level limit parameters in the multi-dimensional limit parameter library are determined based on the user's risk level and the institution type corresponding to the digital wallet, while the user limit parameters in the multi-dimensional limit parameter library are pre-determined by the user.

[0008] Verify the transaction information in the transaction request based on the institution-level limit parameters and user limit parameters to obtain the limit verification result;

[0009] If the limit verification result indicates that the transaction request has passed the verification, multi-dimensional limit control is performed on the current transaction operation indicated by the transaction request.

[0010] In a second aspect, an embodiment of the present application provides a limit control device for a digital wallet, comprising:

[0011] An acquisition module, configured to acquire a transaction request initiated by a digital wallet; wherein the transaction request includes transaction information;

[0012] a determination module configured to, when the transaction request is a forward transaction request, determine, based on the transaction scenario in the transaction information, an institution-level limit parameter and a user limit parameter from a multi-dimensional limit parameter library. The multi-dimensional limit parameter library includes institution-level limit parameters and user limit parameters corresponding to the transaction scenario. The institution-level limit parameter in the multi-dimensional limit parameter library is determined based on the user's risk level and the institution type corresponding to the digital wallet, while the user limit parameter in the multi-dimensional limit parameter library is pre-determined by the user.

[0013] A processing module, configured to verify the transaction information in the transaction request according to the institution-level limit parameters and the user limit parameters, and obtain a limit verification result;

[0014] The control module is configured to perform multi-dimensional limit control on the current transaction operation indicated by the transaction request if the limit verification result indicates that the transaction request has been verified.

[0015] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a memory, a processor;

[0016] Memory stores computer-executable instructions;

[0017] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the above first aspect and / or various possible implementations of the first aspect.

[0018] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed, they are used to implement the first aspect and / or various possible implementation methods of the first aspect as described above.

[0019] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed, implements the above first aspect and / or various possible implementation methods of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0021] Figure 1 A flowchart of the limit control method for a digital wallet provided in this application;

[0022] Figure 2 A flowchart of a limit control method corresponding to a forward transaction request provided in this application;

[0023] Figure 3 A flowchart of a limit control method corresponding to a transaction rollback request provided in this application;

[0024] Figure 4 A flow chart of the execution of parameter generation rules in a quota rollback component provided by this application;

[0025] Figure 5 A schematic diagram of a process for determining a current limit verification identifier provided for this application;

[0026] Figure 6 A schematic diagram of the structure of the limit control device of the digital wallet provided in this application;

[0027] Figure 7 This is a schematic diagram of the structure of the electronic device provided in this application.

[0028] The above drawings illustrate specific embodiments of the present application, which will be described in more detail below. These drawings and the textual description are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION

[0029] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0030] First, let’s explain the terms involved in this application:

[0031] Digital wallet: A digital wallet, also known as a wallet, is a software application or hardware device used to store, manage, and trade digital assets (such as electronic currency and digital RMB). A digital wallet provides a secure environment where users can safely store, send, and receive digital assets and conveniently conduct various financial transactions, such as payments and transfers.

[0032] A limit is a cap placed on the amount or quantity of a specific type of financial transaction. The purpose of a limit is to control the flow of funds and ensure transaction security and compliance. Limits can be set based on various factors, such as time of day, transaction type, and user identity. By using limits, banks, financial institutions, or payment service providers can manage risk, prevent illegal activities such as fraud and money laundering, and protect user funds.

[0033] Daily cumulative limit: This refers to the upper limit on the cumulative transaction amount or number allowed by a wallet in a single day. It limits the total amount or number of transactions a user can make each day. When a user's transactions reach the daily cumulative limit, subsequent transactions may be rejected or require additional authorization steps.

[0034] Annual Cumulative Limit: The annual cumulative limit is the maximum amount or number of transactions allowed within a wallet within a year. It limits the total amount or number of transactions a user can make each year. When a user's transactions reach the annual cumulative limit, subsequent transactions may be rejected or require additional authorization.

[0035] Institutional General Limits: These are the institution-level limit parameters, which refer to the upper limits on single, daily, and annual transaction amounts for wallets of different levels, as well as the upper limits on single, daily, and annual transaction amounts for transfer and consumption scenarios, as specified by regulatory authorities or operating institutions. These limits are generally immutable, and no limit may exceed the institution's general limit.

[0036] User-defined limit: that is, user limit parameters, which are limits set by users based on their actual conditions.

[0037] Refund: In the commercial and consumer fields, it refers to an act in which consumers ask merchants to return the payment for services to themselves.

[0038] Account cancellation: refers to when a financial transaction needs to be cancelled after it is successful. At this time, the reverse operation transaction is unconditionally performed (for example, the original transaction is a deduction and the reverse operation is a deposit). The original transaction can be cancelled through an account cancellation transaction. The account cancellation transaction can only be initiated on the day the erroneous transaction occurs.

[0039] Compensation: refers to the need to restore any operations produced to the business state before the operation after an error occurs in the process.

[0040] Backward compensation: Branch transaction compensation method. The branch compensation logic will be called when the global transaction is rolled back. Its compensation service will leave corresponding database operation information and is generally automatically called by the system.

[0041] Reversal: Reversing submitted or processed information to ensure the accuracy and consistency of transaction information. Reversals are typically initiated manually by business personnel.

[0042] Whether to set a limit: This is the limit verification flag, consisting of four digits, each of which can be 0 or 1. 0 represents no limit, 1 represents a limit, and the following digits represent the balance limit, single transaction limit, daily cumulative limit, and annual cumulative limit, respectively. For example, 0000 means no limit, and 1111 means all limits are subject to limits.

[0043] Limit Accumulation Direction Indicator: This indicator can have four values: Debit Increase, Debit Decrease, Credit Increase, and Credit Decrease. This indicates the direction of the limit accumulation generated when the transaction entity acts as the debit or credit party. If Debit Increase indicates the transaction entity acts as the debit party, the resulting transaction amount will be accumulated as a debit amount in the transaction entity's master file.

[0044] Conventional digital wallet limit control methods typically integrate limit verification and limit accumulation into the same module. Within a single function, they determine whether the "current accumulated value + the verified amount" is less than the limit. If so, the transaction is allowed; otherwise, the transaction is rejected with an "exceeded limit" error. While simple, this approach suffers from issues like confusing logic and high code maintenance costs. While it may have initially met basic financial risk control needs, its limitations are becoming increasingly apparent as financial transactions become increasingly complex and diverse. For example, in some fraud cases, the simplicity and single-dimensional nature of existing limit control methods have made them ineffective in addressing the diverse challenges of telecommunications fraud and effectively protecting user funds. Furthermore, to enhance user experience, digital wallet service providers typically require differentiated and refined management of user wallet limits. Existing methods are unable to meet the diverse and refined limit control requirements of the current financial environment. Consequently, existing methods suffer from limited flexibility and precision in limit control, which in turn limits the accuracy of digital wallet risk control.

[0045] To address the aforementioned issues, the digital wallet limit control method provided in this application achieves refined and personalized limit control by constructing a multi-dimensional limit parameter library containing both institution-level limit parameters and user limit parameters. This library comprehensively considers the user's risk level, the type of institution associated with the digital wallet, and the user's individual needs. During transaction request processing, the digital wallet first obtains a transaction request initiated by the digital wallet. Then, based on the transaction scenario in the transaction information, the corresponding limit parameters are determined from the multi-dimensional limit parameter library. The transaction information in the transaction request is rigorously verified. If the verification passes, multi-dimensional limit control is applied to the current transaction operation indicated by the transaction request, thereby ensuring transaction security and compliance. This method not only improves the flexibility and accuracy of limit control but also significantly enhances transaction processing efficiency. It effectively addresses the issues of logical confusion, high code maintenance costs, and difficulty in flexibly addressing multi-dimensional limit control requirements that plague traditional digital wallet limit control methods when handling reversible financial transactions. This makes limit control clearer, more organized, and easier to maintain and expand.

[0046] The following specific embodiments describe in detail the technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0047] The execution entity of the limit control method for a digital wallet provided in the embodiments of the present application can be a server. The server can be a mobile phone, computer, tablet, or other device. The embodiments of the present application do not impose any particular restrictions on the implementation method of the execution entity, as long as the execution entity can obtain a transaction request initiated by the digital wallet; wherein the transaction request includes transaction information; when the transaction request is a forward transaction request, based on the transaction scenario in the transaction information, the institution-level limit parameter and user limit parameter are determined from a multi-dimensional limit parameter library. The multi-dimensional limit parameter library includes the institution-level limit parameter and user limit parameter corresponding to the transaction scenario. The institution-level limit parameter in the multi-dimensional limit parameter library is determined based on the user's risk level and the institution type corresponding to the digital wallet, and the user limit parameter in the multi-dimensional limit parameter library is pre-determined by the user; based on the institution-level limit parameter and user limit parameter, the transaction information in the transaction request is verified to obtain a limit verification result; if the limit verification result indicates that the transaction request has passed verification, multi-dimensional limit control is performed on the current transaction operation indicated by the transaction request.

[0048] Figure 1This is a flow chart of the limit control method for a digital wallet provided in this application. The execution subject of this method can be a server or other server storing the limit control method for a digital wallet. This embodiment is not particularly limited here. Figure 1 As shown, the method may include:

[0049] S101. Obtain a transaction request initiated by a digital wallet; wherein the transaction request includes transaction information.

[0050] A transaction request may be an information package initiated by a user through a digital wallet, requesting a transaction (such as a transfer or payment), which includes specific transaction information such as the transaction amount, transaction object, transaction time, transaction scenario, and limit information. It should be noted that the limit information described in this embodiment refers to various types of information related to the transaction limit, such as whether a limit is set, the limit accumulation direction, the user's current accumulated limit value, and the transaction date.

[0051] In one example, when a user initiates a transaction, a digital wallet automatically generates a transaction request and sends it to a server or other execution entity (hereinafter referred to as the server) via the network. The server obtains these transaction requests by monitoring network requests or interface calls.

[0052] S102. When the transaction request is a forward transaction request, determine the institution-level limit parameters and user limit parameters from a multi-dimensional limit parameter library based on the transaction scenario in the transaction information. The multi-dimensional limit parameter library includes the institution-level limit parameters and user limit parameters corresponding to the transaction scenario. The institution-level limit parameters in the multi-dimensional limit parameter library are determined based on the user's risk level and the institution type corresponding to the digital wallet, and the user limit parameters in the multi-dimensional limit parameter library are predetermined by the user.

[0053] In this step, a positive transaction request can refer to a request initiated by a user or digital wallet to complete a transaction. For example, a positive transaction request typically involves deducting a certain amount from a digital wallet to pay a merchant or other user. This request is a normal transaction operation that a user wishes to perform, such as making a purchase, paying for a service, or transferring money to another user.

[0054] Among them, institutional limit parameters refer to limit parameters set based on the user's risk level (such as low risk, medium risk, etc.) and the type of institution corresponding to the digital wallet (such as bank, payment platform, etc.), which determine the limit in a specific transaction scenario. Institutional limit parameters can include the single limit value, daily limit value, and annual limit value corresponding to the transaction scenario. User limit parameters refer to limit parameters set for specific users. They can be determined based on user preferences or security considerations. User limit parameters can include user-defined single limit value, daily limit value, or annual limit value.

[0055] In one example, the server first parses the transaction request and identifies the current transaction scenario (e.g., shopping payment, transfer, etc.). Then, based on the transaction scenario and pre-set rules, it queries and determines the corresponding institution-level limit parameters and user limit parameters from a multi-dimensional limit parameter library. These parameters may include single transaction limit values, daily limit values, annual limit values, transaction frequency limits, etc., corresponding to the current transaction scenario.

[0056] S103. Verify the transaction information in the transaction request according to the institution-level limit parameter and the user limit parameter to obtain a limit verification result.

[0057] The limit verification result may refer to the result of the limit verification on the transaction request, indicating whether the transaction is within the permitted limit range.

[0058] In one example, the server verifies the transaction information in the transaction request based on the obtained institution-level limit parameters and user limit parameters. For example, it checks whether the transaction amount exceeds the set upper limit and whether the transaction frequency is abnormal. After the verification is completed, a limit verification result is generated, indicating whether the transaction request meets the limit requirements.

[0059] S104. If the limit verification result indicates that the transaction request has passed verification, multi-dimensional limit control is performed on the current transaction operation indicated by the transaction request.

[0060] Furthermore, if the limit verification result indicates that the transaction request meets the limit requirements, the server will continue to execute the transaction and perform multi-dimensional limit control during the execution process, such as approving the transaction and recording the transaction log to facilitate subsequent risk analysis and limit adjustment. Multi-dimensional limit control can further refer to limit control at multiple levels, such as single transaction limit, daily limit, and annual limit.

[0061] In one example, if the limit verification result indicates that the transaction request has been verified, the limit accumulation is performed, and the amount of this transaction is accumulated to the transaction scenario limit corresponding to the user master file, and the transaction flow information of the current transaction is generated, which records the transaction date, transaction amount, whether a limit is set, etc. of the current transaction, until the transaction is successfully completed. Among them, the structure of the user master file can include multiple field names and field values ​​corresponding to each field name. For example, the user master file includes a wallet ID (a 16-bit numeric combination), a wallet level (such as a first-class wallet / second-class wallet / third-class wallet / fourth-class wallet), an institution-wide limit label (such as C0001-C1000), a single / daily / annual consumption limit (corresponding amount), a single / daily / annual transfer limit (corresponding amount), a single / daily / annual wallet top-up limit (corresponding amount), a single / daily / annual bank deposit limit (corresponding amount), a daily / annual consumption limit (corresponding amount), and other wallet attributes. Transaction flow information may include wallet ID (16-digit numeric combination), transaction serial number (32-bit unique ID), transaction date (yyyyMMdd), whether limit is set (four digits, each digit can be 0 / 1), transaction scenario (transfer / consumption / wallet top-up / bank deposit), transaction amount (amount), and other flow attributes.

[0062] The limit control method for a digital wallet provided in an embodiment of the present application obtains a transaction request initiated by a digital wallet and, based on the transaction scenario, determines the institution-level limit parameters and user limit parameters from a multi-dimensional limit parameter library to verify and process the transaction request. By using the multi-dimensional limit parameter library, the precision of digital wallet limit control is achieved, which can improve transaction security, prevent over-limit transactions and potential fraud, and enhance the user experience, allowing users to conduct transactions in a secure environment. Furthermore, the method is highly flexible and scalable, and can dynamically adjust limit parameters based on different transaction scenarios and user risk levels to meet the personalized needs of different institutions and users, thereby improving user experience and the speed of business expansion.

[0063] Based on the above embodiment, the method described in S103 of verifying the transaction information in the transaction request according to the institution-level limit parameter and the user limit parameter to obtain the limit verification result may include: verifying the transaction amount in the transaction information according to the institution-level limit parameter to obtain a first verification result; wherein the first verification result indicates whether the value of the institution-level limit parameter matches the transaction amount; if the first verification result indicates that the value of the institution-level limit parameter matches the transaction amount, then verifying the transaction amount in the transaction information according to the user limit parameter to obtain a second verification result; wherein the second verification result indicates whether the value of the user limit parameter matches the transaction amount; and obtaining the limit verification result based on the first verification result and the second verification result.

[0064] The first verification result may refer to the result of verifying the transaction amount against the institution-level limit parameters, indicating whether the transaction amount is within the institution's permitted range. The second verification result may refer to the result of verifying the transaction amount against the user limit parameters, indicating whether the transaction amount is within the user-defined range.

[0065] In some embodiments, first, the transaction amount of the current transaction is compared with the institution-level limit parameters, which may include the institution's daily transaction limit, single transaction limit, etc. If the transaction amount is within the institution-level limit parameters, the first verification result indicates a match; otherwise, it indicates a mismatch. Secondly, on the premise that the first verification result matches, the transaction amount is compared with the user limit parameters, which may include the user's daily transaction limit, the user's single transaction limit, the user's specific type of transaction limit, etc. If the transaction amount is within the user limit parameters, the second verification result indicates a match; otherwise, it indicates a mismatch. Finally, based on the first verification result and the second verification result, if both match, the limit verification result indicates that the transaction request has passed the verification and can be processed subsequently; if either does not match, the limit verification result indicates that the transaction request has failed the verification and needs to be rejected or the user is prompted to modify the transaction request. It should be noted that when the user has not set the user limit parameters, the second verification result indicates a match by default.

[0066] Optionally, in certain scenarios, limit verification can be performed simultaneously at both the institution and user levels to improve processing efficiency. However, in this case, it is necessary to ensure that the verification results at both levels are simultaneously aggregated and the final conclusion is reached. For example, during large-scale e-commerce promotions, flash sales, or peak payment periods, digital wallet systems may face a large number of transaction requests, which must be processed quickly to ensure user experience and system stability. Therefore, using parallel verification can shorten transaction processing time and improve system throughput.

[0067] The flexibility and accuracy of limit control are further enhanced through a tiered limit verification mechanism. Verification of institutional limit parameters ensures that transaction amounts comply with the institution's security standards and risk management strategies, thereby preventing transactions that exceed the institution's risk tolerance. Verification of user limit parameters enables users to set transaction limits based on their individual needs and security preferences, providing personalized security. This dual verification mechanism effectively controls transaction risks at different levels, preventing potential fraud and financial loss. It also enhances user trust in digital wallets, allowing users to better control their transaction limits and be confident that their transactions are subject to strict security monitoring.

[0068] Based on the above embodiment, the method may further include: when establishing a digital wallet, configuring the institutional level limit parameters according to the user risk level and the institution type corresponding to the digital wallet, and according to the type of transaction scenario, the institutional level limit parameters include a first single transaction limit parameter, a first single day limit parameter, and a first single year limit parameter; obtaining the user limit parameters set by the user based on the transaction scenario; wherein the user limit parameters include a second single transaction limit parameter, a second single day limit parameter, and a second single year limit parameter; after associating the institutional level limit parameters and the user limit parameters with the transaction scenario of the digital wallet, they are stored in a multi-dimensional limit parameter library.

[0069] In this embodiment, user risk level refers to the risk assessment and estimation of the user based on the user's behavior, historical transaction records, account information and other relevant data, and the classification of the user into different risk levels, which is used to determine the user's permissions, limits and required security measures in financial transactions.

[0070] The single transaction limit parameter can refer to the maximum limit set for a single transaction; the daily limit parameter can refer to the maximum limit set for all transactions within a single day; and the annual limit parameter can refer to the maximum limit set for all transactions within a year.

[0071] In some implementations, when a user registers for a digital wallet or uses the digital wallet service provided by an institution for the first time, the corresponding institution-level limit parameters will be configured for different transaction scenarios (such as shopping, transfers, payments, etc.) based on the user's risk level and the institution type corresponding to the digital wallet. In addition, a user-defined limit function is provided, allowing users to set user limit parameters for different transaction scenarios based on their own needs and risk tolerance. Users can configure these parameters through the digital wallet interface or related settings. Then, the institution-level limit parameters and user limit parameters are associated with specific transaction scenarios to ensure that these parameters can be accurately applied in subsequent transaction verifications. The associated parameters will be stored in a multi-dimensional limit parameter library, which can be implemented using a database, cache or other data storage technology for fast query and update.

[0072] By configuring and storing multi-dimensional limit parameters when establishing a digital wallet, associating these parameters with transaction scenarios and storing them in a multi-dimensional limit parameter library, the corresponding limit parameters can be applied quickly and accurately during transaction verification, thereby improving the flexibility and accuracy of limit control.

[0073] On the basis of the above embodiment, the quota parameters under each dimension in the user quota parameters are less than or equal to the quota parameters under each dimension in the institution-level quota parameters.

[0074] In one example, when a user sets limit parameters, it is possible to automatically verify whether these parameters are less than or equal to the institution-level limit parameters. This verification can be achieved through a simple comparison operation.

[0075] By ensuring that user limit parameters do not exceed institutional limit parameters in all dimensions, it ensures that the limits set by users are always within the risk range allowed by the institution, preventing users from setting excessively high limits and causing potential risk exposure, and ensuring the rigor and flexibility of transaction limit management, which can provide a more robust and reliable foundation for limit control of digital wallets.

[0076] Furthermore, in addition to forward transactions, rollback transactions are also an essential part of the user transaction process. Users may need to roll back historical transactions due to various subjective or objective reasons. Therefore, the limits and accumulated data associated with the transaction must also be rolled back to their original state to effectively safeguard the user experience. Rollback transactions require verifying the consistency between the historical transaction date and the current transaction date, and then rolling back the accumulated transaction limits for the specific scenario based on the historical transaction scenario. Traditional methods for implementing limit control rollbacks require developers to set the key parameters for specific limit verification, which creates a high barrier to entry for developers. Furthermore, the relevant rollback logic needs to be redundantly integrated into the entire limit verification and limit accumulation functions. This lack of a layered design increases the cost of subsequent modification and maintenance, making it difficult to address the flexible control requirements for multi-dimensional limits, impacting user experience and the speed of business expansion.

[0077] Therefore, in order to further realize the differentiated and refined management of digital wallet limits and improve the flexibility and accuracy of limit control, based on the above embodiments, the method of the present application may also include: when the transaction request is a transaction rollback request, determining the transaction information, transaction rollback scenario, and historical transaction information of the digital wallet in the transaction request, wherein the transaction rollback scenario includes refund, account cancellation, backward compensation or reversal; according to the transaction rollback scenario, calling the target rollback component bound to the transaction rollback scenario from the plug-in limit rollback component library; wherein the limit rollback component in the plug-in limit rollback component library presets the parameter generation rules corresponding to the transaction rollback scenario; based on the parameter generation rules of the target rollback component, according to the transaction information, transaction rollback scenario, and historical transaction information in the transaction request, determining the current limit accumulation direction identifier and the current limit verification identifier; when the current limit verification identifier is a valid identifier, performing limit rollback control on the current transaction in the transaction request according to the current limit accumulation direction identifier and the transaction information in the transaction request.

[0078] In this step, a rollback request can refer to situations where a previously initiated forward transaction request needs to be reversed or canceled. This can occur when a transaction fails, the user cancels a transaction, or an error or fraudulent activity is discovered. A rollback request can be used to return the previously deducted amount to the user's digital wallet, restoring the state before the transaction.

[0079] A transaction rollback scenario specifically refers to the circumstances or types of transaction rollbacks, such as refunds, account cancellations, backward compensation, or reversals. A plug-in limit rollback component library can refer to a modular library containing multiple limit rollback components, each corresponding to a specific transaction rollback scenario and pre-configured parameter generation rules. Parameter generation rules can be used to generate the parameters required for limit rollback processing based on transaction information, rollback scenarios, and historical transaction information.

[0080] The current limit accumulation direction indicator can indicate the direction of the limit adjustment (e.g., increase or decrease) during the rollback process corresponding to the current transaction request. The current limit verification indicator can be an indicator used to indicate whether limit control is performed on the rollback transaction request. It can include multi-dimensional limit verification indicators, such as daily limit verification indicators and annual limit verification indicators. When multi-dimensional limit verification indicators exist, as long as one of the limit verification indicators is valid, limit rollback control will be performed.

[0081] The target fallback component invoked will generate rules based on its preset parameters, combining the transaction information in the transaction request, the transaction fallback scenario, and historical transaction information to generate the current limit accumulation direction identifier and the current limit verification identifier. If the current limit verification identifier indicates that a limit is required, the transaction request will be subject to limit fallback control based on the current limit accumulation direction identifier (such as increase or decrease) and the transaction information in the transaction request (such as the transaction amount), such as adjusting the user's available limit, updating the institution's daily limit or annual limit information, etc.

[0082] Optionally, components in the plug-in limit fallback component library can be dynamically loaded and unloaded as needed to flexibly cope with different transaction fallback scenarios.

[0083] In addition, after the current transaction in the transaction request is subject to limit rollback control, the historical information of each transaction rollback can also be recorded, including rollback time, rollback amount, rollback reason, etc., for subsequent query and audit.

[0084] By accurately identifying transaction rollback scenarios and dynamically adjusting parameter generation rules, transaction rollback requests can be processed more quickly and accurately, improving transaction processing efficiency and the accuracy of limit control. Furthermore, the plug-in limit rollback component library makes limit control more flexible and scalable. When new rollback scenarios arise, simply develop a new limit rollback component and add it to the library, eliminating the need for large-scale modifications to the existing system.

[0085] On the basis of the above embodiments, based on the parameter generation rules of the target fallback component, the method for determining the current limit accumulation direction identifier and the current limit verification identifier according to the transaction information in the transaction request, the transaction fallback scenario, and the historical transaction information may include: determining the original transaction information corresponding to the transaction fallback scenario according to the transaction information in the transaction request and the historical transaction information, the original transaction information including the original lending direction, the original transaction date, and the original limit verification identifier; determining the current limit accumulation direction identifier according to the transaction fallback scenario and the original lending direction; determining the current limit verification identifier according to the original transaction date and the original limit verification identifier.

[0086] In this embodiment, the original transaction information is key data extracted from historical transaction information. It may include the original debit / credit direction, which distinguishes between outgoing (credit) and incoming (debit) transactions and determines the direction of increase or decrease during rollback; the original transaction date, which determines whether the daily / yearly limit needs to be rolled back (if the transaction is on the same day, the daily limit will be rolled back); and the original limit verification flag, which indicates whether the original transaction was verified for the daily / yearly limit.

[0087] Furthermore, the current limit accumulation direction indicator is dynamically generated based on the rollback scenario and the original debit and credit direction. For example, the outgoing direction indicator for a refund scenario is "Credit Reduction," and the incoming direction indicator for a reversal scenario is "Debit Reduction." The current limit verification indicator is generated based on the original transaction date and the original verification indicator. For example, if the original daily limit verification is valid and the current date is the same as the original date, the "Daily Limit Rollback Required" indicator is generated; if the original annual limit verification is valid and the year is the same, the "Annual Limit Rollback Required" indicator is generated.

[0088] Through a plug-in design, the rollback logic is decoupled into independent components, and limit rollback parameters are automatically generated based on scenario-based rules. This solves the technical challenges of traditional methods, which often involve strong coupling of rollback logic with the main process and high development and maintenance costs. Specifically, through intelligent matching of the original transaction date with the verification identifier, only the accumulated limit value within the validity period is rolled back, achieving precise rollback control. Developers no longer need to manually write rollback logic; they only need to configure component rules to support new scenarios. This reduces the development threshold and the cost of subsequent maintenance and modification, facilitates flexible control of multi-dimensional limits, and improves user experience and the speed of business expansion.

[0089] Based on the above embodiment, the method for determining the current limit verification identifier according to the original transaction date and the original limit verification identifier may include: determining the original daily limit verification identifier and the original annual limit verification identifier in the original limit verification identifier; when the original daily limit verification identifier is a valid identifier, if the current transaction date and the original transaction date are the same date, then the current daily limit verification identifier is generated; when the original annual limit verification identifier is a valid identifier, if the current transaction date and the original transaction date are the same year, then the current annual limit verification identifier is generated; wherein, the current limit verification identifier includes the current daily limit verification identifier and the current annual limit verification identifier.

[0090] In this embodiment, the current transaction date is determined by the transaction information in the transaction request. The valid flag may refer to the flag status that requires limit rollback. Only when the original verification flag is in the valid state, further determination of the date condition is required.

[0091] In one example, for a daily limit rollback, if the original transaction occurred on May 10, 2023 and the limit verification flag was valid, meaning the limit control included the daily limit, and the current transaction date is also May 10, 2023, then a valid current daily limit verification flag is generated. For a yearly limit rollback, if the original transaction occurred in 2023 and the limit verification flag was valid, meaning the limit control included the yearly limit, and the current transaction date is also 2023, then a valid current yearly limit verification flag is generated.

[0092] In addition, special processing logic can be designed for transactions across years, such as determining whether annual limit rollback is required based on the actual time of the transaction (rather than just the year), or performing special limit accumulation and verification processing for transactions across years.

[0093] By processing the original daily limit verification identifier and the original annual limit verification identifier separately, and generating the corresponding current limit verification identifier based on the relationship between the current transaction date and the original transaction date, it is possible to accurately determine whether the current transaction requires a daily limit or annual limit rollback, thereby achieving differentiated and refined management of digital wallet limits and improving the flexibility and accuracy of limit control.

[0094] The following uses the above-mentioned method as an example to explain the limit control method of a digital wallet in detail. The limit control method of a digital wallet of the present application includes:

[0095] First, when a user opens a digital wallet, the system assigns the user institution-level limit parameters based on factors such as the opening institution and the user's risk level, and determines the user limit parameters for the corresponding transaction scenarios set by the user based on his or her own situation.

[0096] Figure 2A flow chart of a limit control method corresponding to a forward transaction request provided in this application, such as Figure 2 As shown, when the transaction request is a forward transaction request, it will pass the verification of the institutional level limit and the user-defined limit in turn; when all the verifications are passed, the corresponding scenario will be accumulated and updated to the user's main file. Specifically,

[0097] ① Obtain various information related to the transaction limit from the transaction information, such as whether the limit is marked, the limit accumulation direction mark, the transaction scenario, the user's current limit accumulation value, the transaction date, etc.

[0098] ② Perform institutional limit verification. Check the transaction limit values ​​for each transaction scenario set for the corresponding institutional limit in the multi-dimensional limit parameter library. Based on the current transaction scenario, the corresponding single transaction limit value, as well as the daily and annual limit values, are obtained and verified against the current transaction amount. If the verification fails, the transaction ends and a failure is returned. If it passes, the user-defined limit verification is performed.

[0099] ③ Verify user-defined limits. If the user has not set a user limit parameter, limit accumulation is performed. If the user has set a user limit parameter, the user's set limit parameter value is identified based on the transaction scenario and compared with the current transaction amount. If the verification fails, the transaction ends and a failure is returned; if it passes, limit accumulation is performed. Limit verification based on different transaction scenarios can include transfers, spending, wallet top-ups, bank deposits, and other scenarios.

[0100] ④ Accumulate the limit and add the amount of this transaction to the transaction scenario limit corresponding to the user's main file.

[0101] ⑤ Carry out subsequent preset transaction steps, such as generating transaction flow information for the transaction, which records the transaction date, transaction amount, whether a limit mark is set, etc., until the transaction is successfully completed.

[0102] When a user's historical transactions need to be rolled back due to various subjective or objective reasons, the limits and accumulated data associated with the transaction should also be rolled back to the original state, thereby effectively protecting the user experience. Figure 3 A flowchart of a limit control method corresponding to a transaction rollback request provided in this application, such as Figure 3 As shown, when the transaction request is a transaction rollback request, after the transaction is connected, the wallet main file is queried, the historical details are further queried, and the corresponding limit rollback component is selected based on this. Finally, the subsequent transaction steps are carried out based on the selected limit rollback component until the transaction is successfully completed.

[0103] Among them, the current rollback transaction scenarios mainly include refunds, account wipes, backward compensation, and corrections. Different limit rollback components need to be written according to different transaction scenarios. Subsequent development and maintenance personnel can directly call the corresponding limit rollback components, which can greatly reduce the development threshold and the cost of subsequent maintenance. The rollback transaction will set various parameters related to the limit rollback according to the corresponding limit rollback component, and can automatically and accurately roll back the limit of the corresponding transaction scenario without making changes to other modules of the program. Furthermore, when the transaction request is a transaction rollback request, it is necessary to determine the transaction rollback scenario, which mainly includes four scenarios: refund, account wipes, backward compensation, and correction; then, according to the transaction rollback scenario, select the corresponding target rollback component, and according to the limit rollback parameters set in the component (the current limit accumulation direction identifier and the current limit verification identifier), perform the transaction rollback until the transaction is successfully completed.

[0104] Figure 4 A flow chart of the execution of parameter generation rules in a quota fallback component provided by this application, such as Figure 4 As shown, the method for generating various parameters for limit fallback based on the parameter generation rules in the limit fallback component includes: 1) setting the identifier of the cumulative direction of the current limit according to the specific fallback scenario and the direction of debit and credit. Specifically, the cumulative direction identifier of the limit corresponding to the payee in the refund scenario is credit reduction; the identifier corresponding to the creditor in the refund scenario is debit reduction; the identifier corresponding to the payee in the account cancellation scenario is credit reduction; the identifier corresponding to the creditor in the account cancellation scenario is debit reduction; the identifier corresponding to the payee in the compensation scenario is credit reduction; the identifier corresponding to the creditor in the compensation scenario is debit reduction; the identifier corresponding to the payee in the reversal scenario is credit reduction; the identifier corresponding to the payee in the reversal scenario is debit reduction. 2) Based on the original transaction time and whether the original transaction was marked with a limit, calculate whether the limit is marked for this transaction. Finally, the limit fallback parameters calculated above are set into the normal transaction information, and the chain limit module will perform limit fallback for the precise transaction scenario based on the relevant information.

[0105] Further, Figure 5 A flow chart of determining a current limit verification identifier provided for this application is as follows: Figure 5As shown, the method for calculating the limit verification flag for this transaction to determine the current limit verification flag may include: 1) obtaining the limit verification flag and the original transaction date of the original transaction. 2) calculating the daily limit verification flag for the current limit verification flag. The specific method is to check the daily limit verification flag of the limit verification flag of the original transaction. If the original daily limit verification flag is 1, it is necessary to determine whether the current transaction date and the original transaction date are the same day. If they are the same day, the current limit verification flag is 1, indicating that the daily limit needs to be rolled back. Otherwise, the current limit verification flag is 0, indicating that the daily limit does not need to be rolled back. 3) calculating the annual limit verification flag of the current limit verification flag. The specific method is to check the annual limit verification flag of the limit verification flag of the original transaction. If the original annual limit verification flag is 1, it is necessary to determine whether the current transaction date and the original transaction date are the same year. If they are the same year, the current limit verification flag is 1, indicating that the annual limit needs to be rolled back. Otherwise, the current limit verification flag is 0, indicating that the annual limit does not need to be rolled back.

[0106] The limit control method for a digital wallet provided in an embodiment of the present application is as follows: when a user opens a digital wallet, the user is assigned an institution-level control limit based on factors such as the opening institution and the user's risk level, and the user can set the corresponding transaction scenario limit according to his or her own situation and pre-store it; when the user makes a forward transaction request, the institution-level limit and the user-defined limit are sequentially checked, and when all the checks are passed, the corresponding scenarios are accumulated and updated to the user's main file; and according to different scenarios of transaction rollback requests, corresponding plug-in codes are written and embedded in the rollback transaction. When the user has a transaction rollback, the limit rollback plug-in will automatically calculate the limit parameters of the rollback scenario and configure it normally in the subsequent transaction process, so that the accumulated financial transaction limits of the user are correctly rolled back. Therefore, the method of this application decouples multiple limit verification modules through a layered design, with clear logic, flexible structure, facilitating expansion, and reducing maintenance costs. At the same time, corresponding limit rollback components can be written according to different rollback transaction scenarios for developers to call directly. Rollback transactions will set various parameters related to limit rollback according to the corresponding limit rollback components, and can automatically and accurately roll back the limits of the corresponding transaction scenarios without making changes to other modules of the program. This reduces the development threshold and the cost of subsequent maintenance and transformation, is conducive to meeting the requirements of flexible control of multi-dimensional limits, and improves user experience and the speed of business expansion.

[0107] Figure 6 This is a schematic diagram of the structure of the limit control device of the digital wallet provided in this application, such as Figure 6 As shown, the limit control device 60 of the digital wallet provided in this embodiment includes:

[0108] The acquisition module 601 is used to obtain a transaction request initiated by a digital wallet; wherein the transaction request includes transaction information;

[0109] Determination module 602 is configured to, when the transaction request is a forward transaction request, determine, based on the transaction scenario in the transaction information, an institution-level limit parameter and a user limit parameter from a multi-dimensional limit parameter library. The multi-dimensional limit parameter library includes institution-level limit parameters and user limit parameters corresponding to the transaction scenario. The institution-level limit parameter in the multi-dimensional limit parameter library is determined based on the user's risk level and the institution type corresponding to the digital wallet, while the user limit parameter in the multi-dimensional limit parameter library is pre-determined by the user.

[0110] Processing module 603 is used to verify the transaction information in the transaction request according to the institution-level limit parameter and the user limit parameter to obtain a limit verification result;

[0111] The control module 604 is configured to perform multi-dimensional quota control on the current transaction operation indicated by the transaction request if the quota verification result indicates that the transaction request has been verified.

[0112] In one possible implementation, the processing module 603 can also be used to: verify the transaction amount in the transaction information according to the institution-level limit parameter to obtain a first verification result; wherein the first verification result indicates whether the value of the institution-level limit parameter matches the transaction amount; if the first verification result indicates that the value of the institution-level limit parameter matches the transaction amount, then verify the transaction amount in the transaction information according to the user limit parameter to obtain a second verification result; wherein the second verification result indicates whether the value of the user limit parameter matches the transaction amount; and obtain a limit verification result based on the first verification result and the second verification result.

[0113] In one possible implementation, the determination module 602 can also be used to: when a digital wallet is established, configure the institution-level limit parameters according to the user risk level and the institution type corresponding to the digital wallet, and according to the type of transaction scenario, the institution-level limit parameters include a first single transaction limit parameter, a first single-day limit parameter, and a first single-year limit parameter; obtain the user limit parameters set by the user based on the transaction scenario; wherein the user limit parameters include a second single transaction limit parameter, a second single-day limit parameter, and a second single-year limit parameter; after associating the institution-level limit parameters and the user limit parameters with the transaction scenario of the digital wallet, they are stored in a multi-dimensional limit parameter library.

[0114] In one possible implementation, the processing module 603 may also be used for: when the transaction request is a transaction rollback request, determining the transaction information, transaction rollback scenario, and historical transaction information of the digital wallet in the transaction request, wherein the transaction rollback scenario includes refund, account cancellation, backward compensation, or reversal; based on the transaction rollback scenario, calling the target rollback component bound to the transaction rollback scenario from the plug-in limit rollback component library; wherein the limit rollback component in the plug-in limit rollback component library presets parameter generation rules corresponding to the transaction rollback scenario; based on the parameter generation rules of the target rollback component, determining the current limit accumulation direction identifier and the current limit verification identifier according to the transaction information, transaction rollback scenario, and historical transaction information in the transaction request; when the current limit verification identifier is a valid identifier, performing limit rollback control on the current transaction in the transaction request according to the current limit accumulation direction identifier and the transaction information in the transaction request.

[0115] In one possible implementation, the processing module 603 can also be used to: determine the original transaction information corresponding to the transaction rollback scenario based on the transaction information and historical transaction information in the transaction request, the original transaction information including the original lending direction, the original transaction date, and the original limit verification identifier; determine the current limit accumulation direction identifier based on the transaction rollback scenario and the original lending direction; determine the current limit verification identifier based on the original transaction date and the original limit verification identifier.

[0116] In one possible implementation, the processing module 603 can also be used to: determine the original daily limit verification identifier and the original annual limit verification identifier in the original limit verification identifier; when the original daily limit verification identifier is a valid identifier, if the current transaction date and the original transaction date are the same date, then generate the current daily limit verification identifier; when the original annual limit verification identifier is a valid identifier, if the current transaction date and the original transaction date are the same year, then generate the current annual limit verification identifier; wherein, the current limit verification identifier includes the current daily limit verification identifier and the current annual limit verification identifier.

[0117] The limit control device for a digital wallet provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effects are similar, and are not described in detail in this embodiment.

[0118] Figure 7 This is a schematic diagram of the structure of the electronic device provided in this application. Figure 7 As shown, the electronic device 70 provided in this embodiment includes: at least one processor 701 and a memory 702. Optionally, the device 70 further includes a communication component 703. The processor 701, the memory 702 and the communication component 703 are connected via a bus 704.

[0119] During the specific implementation process, at least one processor 701 executes the computer-executable instructions stored in the memory 702, so that the at least one processor 701 performs the above method.

[0120] The specific implementation process of the processor 701 can be found in the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here in this embodiment.

[0121] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASICs), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the present invention may be directly executed by a hardware processor or by a combination of hardware and software modules in the processor.

[0122] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (NVM), such as at least one disk memory.

[0123] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Buses can be classified as address buses, data buses, and control buses. For ease of illustration, the buses in the drawings of this application are not limited to just one bus or just one type of bus.

[0124] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0125] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

[0126] The above-mentioned readable storage medium can be implemented by any type of volatile or non-volatile memory device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0127] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be an integral part of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the readable storage medium can also exist in a device as discrete components.

[0128] The division of units is merely a logical functional division; actual implementations may employ alternative divisions, such as combining or integrating multiple units or components into another system, or omitting or disabling certain features. Furthermore, any direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units, either through an interface, electrical, mechanical, or other means.

[0129] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0130] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0131] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, and other media that can store program code.

[0132] Those skilled in the art will appreciate that all or part of the steps in the above-described method embodiments can be implemented using hardware associated with program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0133] Finally, it should be noted that those skilled in the art will readily identify other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses, or adaptations of the present invention that follow the general principles of the present invention and include common knowledge or customary techniques in the art not disclosed herein. The present invention is not limited to the precise structure described above and illustrated in the accompanying drawings, and various modifications and variations may be made without departing from the scope thereof. The scope of the present invention is limited solely by the appended claims.

Claims

1. A limit control method for a digital wallet, characterized in that: include: Obtaining a transaction request initiated by a digital wallet; wherein the transaction request includes transaction information; When the transaction request is a forward transaction request, an institution-level limit parameter and a user limit parameter are determined from a multi-dimensional limit parameter library based on the transaction scenario in the transaction information. The multi-dimensional limit parameter library includes institution-level limit parameters and user limit parameters corresponding to the transaction scenario. The institution-level limit parameter in the multi-dimensional limit parameter library is determined based on the user's risk level and the institution type corresponding to the digital wallet, and the user limit parameter in the multi-dimensional limit parameter library is pre-determined by the user. Verifying the transaction information in the transaction request according to the institution-level limit parameter and the user limit parameter to obtain a limit verification result; If the limit verification result indicates that the transaction request has been verified, multi-dimensional limit control is performed on the current transaction operation indicated by the transaction request.

2. The method according to claim 1, characterized in that The verifying the transaction information in the transaction request according to the institution-level limit parameter and the user limit parameter to obtain a limit verification result includes: Verifying the transaction amount in the transaction information according to the institution-level limit parameter to obtain a first verification result; wherein the first verification result indicates whether the value of the institution-level limit parameter matches the transaction amount; If the first verification result indicates that the value of the institution-level limit parameter matches the transaction amount, then verifying the transaction amount in the transaction information based on the user limit parameter to obtain a second verification result; wherein the second verification result indicates whether the value of the user limit parameter matches the transaction amount; The limit verification result is obtained according to the first verification result and the second verification result.

3. The method according to claim 1, characterized in that The method further comprises: When establishing a digital wallet, the institution-level limit parameters are configured according to the user's risk level and the institution type corresponding to the digital wallet, and according to the type of transaction scenario. The institution-level limit parameters include the first single transaction limit parameter, the first single daily limit parameter, and the first single annual limit parameter; Obtaining user limit parameters set by the user based on the transaction scenario; wherein the user limit parameters include a second single transaction limit parameter, a second single daily limit parameter, and a second single annual limit parameter; After associating the institution-level limit parameter, the user limit parameter and the transaction scenario of the digital wallet, they are stored in a multi-dimensional limit parameter library.

4. The method according to claim 3, characterized in that The limit parameters under each dimension of the user limit parameters are less than or equal to the limit parameters under each dimension of the institution level limit parameters.

5. The method according to any one of claims 1 to 4, characterized in that The method further comprises: When the transaction request is a transaction rollback request, determining the transaction information, transaction rollback scenario, and historical transaction information of the digital wallet in the transaction request, wherein the transaction rollback scenario includes refund, account cancellation, backward compensation, or reversal; According to the transaction rollback scenario, a target rollback component bound to the transaction rollback scenario is called from a plug-in quota rollback component library; wherein the quota rollback component in the plug-in quota rollback component library is pre-set with a parameter generation rule corresponding to the transaction rollback scenario; Determining a current limit accumulation direction identifier and a current limit verification identifier based on the parameter generation rule of the target fallback component and the transaction information in the transaction request, the transaction fallback scenario, and the historical transaction information; When the current limit verification identifier is a valid identifier, limit rollback control is performed on the current transaction in the transaction request according to the current limit accumulation direction identifier and the transaction information in the transaction request.

6. The method according to claim 5, characterized in that The parameter generation rule based on the target fallback component determines the current limit accumulation direction identifier and the current limit verification identifier according to the transaction information in the transaction request, the transaction fallback scenario, and the historical transaction information, including: Determining original transaction information corresponding to the transaction rollback scenario based on the transaction information in the transaction request and the historical transaction information, the original transaction information including the original debit / credit direction, the original transaction date, and the original limit verification identifier; Determining the current limit accumulation direction identifier according to the transaction rollback scenario and the original lending direction; The current limit verification identifier is determined according to the original transaction date and the original limit verification identifier.

7. The method according to claim 6, characterized in that The determining the current limit verification identifier according to the original transaction date and the original limit verification identifier includes: Determine the original daily limit verification mark and the original annual limit verification mark in the original limit verification mark; When the original daily limit verification flag is a valid flag, if the current transaction date and the original transaction date are the same date, a current daily limit verification flag is generated; When the original annual limit verification mark is a valid mark, if the current transaction date and the original transaction date are the same year, a current annual limit verification mark is generated; The current quota verification mark includes a current daily quota verification mark and a current annual quota verification mark.

8. A limit control device for a digital wallet, characterized in that: include: An acquisition module, configured to acquire a transaction request initiated by a digital wallet; wherein the transaction request includes transaction information; a determination module configured to, when the transaction request is a forward transaction request, determine, based on the transaction scenario in the transaction information, an institution-level limit parameter and a user limit parameter from a multi-dimensional limit parameter library, wherein the multi-dimensional limit parameter library includes institution-level limit parameters and user limit parameters corresponding to the transaction scenario, the institution-level limit parameter in the multi-dimensional limit parameter library being determined based on the user risk level and the institution type corresponding to the digital wallet, and the user limit parameter in the multi-dimensional limit parameter library being predetermined by the user; a processing module, configured to verify the transaction information in the transaction request according to the institution-level limit parameter and the user limit parameter, and obtain a limit verification result; The control module is configured to perform multi-dimensional quota control on the current transaction operation indicated by the transaction request if the quota verification result indicates that the transaction request has been verified.

9. An electronic device, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 7 when executed.

Images