Credit card management method and device, equipment, storage medium and product

Abstract

The invention discloses a credit card management method and device, equipment, a storage medium and a product. The specific scheme is as follows: verifying at least one locking code of a plurality of credit cards according to a preset management constraint condition of a plurality of credit card management levels to obtain a target control parameter corresponding to each credit card; when it is detected that the received target transaction data belongs to credit card transaction, target credit card information is determined, and a target control parameter corresponding to the target credit card information is called; and when the target transaction data and the target control parameter meet a preset condition, returning transaction completion response data indicating that the target transaction corresponding to the target transaction data is completed. According to the method, the locking code and the target control parameter are adopted, effective risk management and control of credit card transaction are realized, and the credit card use experience of a user is improved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method, apparatus, device, storage medium, and product for managing credit cards. Background Technology

[0002] With the rapid development of the credit card business, the need for risk control has become increasingly complex. In order to achieve precise control over authorization, new credit card issuance, and other related businesses, specific locking codes are usually added to credit cards when potential risks are detected in the system.

[0003] However, the current method of managing lock codes mainly relies on manual operation, which is inefficient and prone to errors. Furthermore, the credit card management method based on lock codes is not intelligent enough. It not only fails to automatically and effectively control the risk of credit card transactions, but also wastes lock code resources, resulting in a poor user experience. Summary of the Invention

[0004] This invention provides a method, device, equipment, storage medium, and product for managing credit cards, which enables effective risk control of credit card transactions and improves the user's credit card experience.

[0005] According to one aspect of the present invention, a method for managing credit cards is provided, the method comprising:

[0006] Based on the pre-set management constraints of multiple credit card management levels, at least one lock code of multiple credit cards is verified to obtain the target control parameters corresponding to each credit card;

[0007] When the received target transaction data is detected to be a credit card transaction, the target credit card information is determined and the target control parameters corresponding to the target credit card information are retrieved;

[0008] When the target transaction data and target control parameters meet the preset conditions, return the transaction completion response data corresponding to the target transaction data, indicating that the target transaction has been completed.

[0009] According to another aspect of the present invention, a credit card management device is provided, the device comprising:

[0010] The control parameter determination module is used to verify at least one lock code of multiple credit cards based on the management constraints of multiple credit card management levels set in advance, and to obtain the target control parameters corresponding to each credit card.

[0011] The control parameter retrieval module is used to determine the target credit card information and retrieve the target control parameters corresponding to the target credit card information when it is detected that the received target transaction data belongs to a credit card transaction.

[0012] The response data determination module is used to return transaction completion response data corresponding to the target transaction data when the target transaction data and target control parameters meet preset conditions.

[0013] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0014] At least one processor; and

[0015] A memory that is communicatively connected to at least one processor; wherein,

[0016] The memory stores a computer program that can be executed by at least one processor, such that the at least one processor is able to perform the credit card management method according to any embodiment of the present invention.

[0017] According to another aspect of the present invention, a computer-readable storage medium is provided that stores computer instructions for causing a processor to execute and implement the credit card management method of any embodiment of the present invention.

[0018] According to another aspect of the present invention, a computer program product is provided, comprising a computer program, characterized in that the computer program, when executed by a processor, implements a credit card management method as described in any embodiment of the present invention.

[0019] The technical solution of this invention verifies at least one lock code of multiple credit cards based on pre-set management constraints for multiple credit card management levels, obtaining target control parameters corresponding to each credit card. This ensures the rationality and integrity of the lock code and facilitates risk management of credit cards through target control parameters. When it is detected that the received target transaction data belongs to a credit card transaction, the target credit card information is determined, and the target control parameters corresponding to the target credit card information are retrieved. The target transaction data belonging to the credit card transaction is verified through the target control parameters. When the target transaction data and the target control parameters meet the preset conditions, the transaction completion response data corresponding to the target transaction data is returned, indicating that the target transaction has been completed. Based on this, reasonable control and risk management of credit card transactions are achieved. This invention, by verifying the lock code, ensures the rationality and integrity of the lock code, avoiding the problems of error and low efficiency caused by manual management of lock codes. By determining the target control parameters corresponding to the lock code, and returning transaction completion response data indicating that the target transaction has been completed when the target control parameters and target transaction data meet preset conditions, the problem of insufficient intelligence in credit card management in existing technologies is solved. Intelligent management of credit card transactions based on lock codes and target control parameters is realized, and risk control of credit card transactions is automatically and effectively carried out, thereby improving the user's credit card experience.

[0020] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0022] Figure 1 This is a flowchart of a credit card management method provided in an embodiment of the present invention;

[0023] Figure 2 This is a flowchart of a method for allocating lock codes and reason codes according to an embodiment of the present invention;

[0024] Figure 3 This is an example diagram of a table for adding reason codes provided in an embodiment of the present invention;

[0025] Figure 4 This is an example table diagram of reason code deletion provided in an embodiment of the present invention;

[0026] Figure 5 This is a flowchart illustrating a method for determining target control parameters provided in an embodiment of the present invention;

[0027] Figure 6 This is a flowchart illustrating the process of determining control parameters provided in an embodiment of the present invention;

[0028] Figure 7 This is a schematic diagram of the structure of a credit card management device provided in an embodiment of the present invention;

[0029] Figure 8 This is a schematic diagram of the structure of an electronic device that implements the credit card management method of this invention. Detailed Implementation

[0030] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0032] Example 1

[0033] Figure 1 This is a flowchart of a credit card management method provided in Embodiment 1 of the present invention. This embodiment is applicable to the intelligent management of credit card transactions based on lock codes and target control parameters. The method can be executed by a credit card management device, which can be implemented in hardware and / or software. This credit card management device can be configured in electronic devices such as mobile phones, computers, or servers. Figure 1 As shown, the method includes:

[0034] S110. Based on the pre-set management constraints of multiple credit card management levels, verify at least one lock code of multiple credit cards to obtain the target control parameters corresponding to each credit card.

[0035] Lock codes are special codes used to mark the risk status of credit cards or restrict transactions, primarily used in credit card risk control. Lock codes can achieve risk management at different credit card management levels. Optionally, lock codes are used to identify the status of customers, accounts, or cards. Their meaning is usually defined by the corresponding business system and added to customers, accounts, or cards in the corresponding business scenarios to control business transaction behavior. For example, the value range of a lock code can be AZ or az, and the business transaction behavior can be credit card authorization, credit card issuance, or card replacement.

[0036] Optionally, credit card management levels can include: customer level, account level, card level, and dedicated installment account level. Lock codes for different credit card management levels are managed independently, and each level targets different dimensions or business scopes. Customer-level credit card management corresponds to the customer-level lock code, customer name, and customer identity information. Card-level credit card management corresponds to the card lock code, credit card number, credit card activation date, and credit card PIN. Account-level management corresponds to the account-level lock code and the account information associated with the credit card. For example, the relationship between customer-level, account-level, and card-level management can be illustrated as follows: a customer can have multiple credit cards linked to their name, and each credit card can be associated with multiple accounts. Dedicated installment account level can be a specific installment account level for a particular business transaction.

[0037] Management constraints can be pre-set, corresponding to each credit card management level. Optionally, management constraints can be set based on the expected number of outstanding payments, which varies across different credit card management levels. The expected number of outstanding payments can be used as a standard value to represent the number of outstanding payments for a corresponding credit card. The number of outstanding payments, i.e., the number of outstanding periods (CD value) for the credit card account, is higher when there are transaction records and decreases after repayment. Optionally, the number of outstanding payments can range from 0 to 9. For example, a CD value of 1 indicates one outstanding payment period.

[0038] The target control parameters include at least one business control parameter applicable to the business. The lock code corresponds to the target control parameter. The target control parameter determines whether the corresponding credit card transaction can be completed.

[0039] Specifically, based on the pre-set management constraints of multiple credit card management levels, at least one lock code of multiple credit cards is verified to obtain the target control parameters corresponding to each credit card, provided that the integrity and rationality of the lock code are determined.

[0040] Optionally, in this embodiment of the invention, the target control parameters corresponding to each credit card can be obtained by: determining the first credit card for which the target control parameters are to be determined based on the expected number of non-payments and at least one credit card with a lock code in each credit card management level of the management constraints; for the first credit card, determining the target control parameters associated with the first credit card based on the priority of at least one lock code associated with the first credit card; wherein, the target control parameters include at least one business control parameter applicable to the business.

[0041] The expected number of overdue payments can be used to represent the standard value for the number of periods of non-payment on a corresponding credit card. The expected number of overdue payments varies depending on the credit card management level. For example, at the customer level, the expected number of overdue payments could be 2, while at the account level, it could be 8.

[0042] The first credit card for which the target control parameters are to be determined can be a credit card determined based on the number of non-payments corresponding to at least one credit card with a lock code and the corresponding expected number of non-payments.

[0043] Regarding the priority of locking codes, a queue exists for locking codes at each credit card management level (customer level, account level, card level, and special installment account level), recording all added locking codes. Locking codes in the queue are sorted by priority, with the first locking code in the queue being the highest priority locking code currently in effect for its corresponding credit card management level. Each locking code corresponds to a control parameter. The control parameter corresponding to the highest priority locking code takes precedence over other locking codes. The target control parameter can be the control parameter corresponding to the currently effective locking code (the first effective locking code). For example, if a control parameter of the highest priority locking code is set to "N - No Control," then the control parameter of a lower-priority locking code with the same value becomes effective, and that control parameter becomes the target control parameter. Conversely, if the control parameter of a lower-priority locking code is also set to "N - No Control," then the next lower priority locking code's value for that control parameter is checked until the effective control parameter becomes the target control parameter.

[0044] Specifically, based on the expected number of non-payments at each credit card management level in the management constraints and at least one credit card with a lock code, it is determined whether the number of non-payments for each credit card with a lock code exceeds the corresponding expected number of non-payments. If the number of non-payments exceeds the expected number of non-payments, the corresponding credit card is designated as the target control parameter to be determined. For the first credit card, based on the priority of the at least one lock code associated with the first credit card, the control parameter of the currently effective lock code is used as the target control parameter associated with the first credit card.

[0045] For example, based on the checkpoint mask, at least one lock code for multiple credit cards corresponding to the credit card management level that needs to be checked is determined. For instance, if the corresponding bit in the checkpoint mask is 1, then at least one lock code for multiple credit cards corresponding to the customer level is checked. Before checking at least one lock code for multiple credit cards, the completeness of the credit card information for each credit card can be verified. If information is missing, a message is displayed indicating that the necessary credit card entity information has not been entered.

[0046] Taking the customer-level credit card management system as an example, the system obtains at least one credit card with a lock code corresponding to the customer level and determines the number of non-payment transactions for each credit card. When the number of non-payment transactions for a credit card exceeds the expected number of non-payment transactions corresponding to the customer level, this credit card is designated as the first credit card for which the target control parameter is to be determined. Based on the priority of at least one lock code associated with the first credit card, the control parameter of the currently effective lock code is determined as the target control parameter for the first credit card. For example, the system iterates through at least one lock code associated with the first credit card, determining the priority and control parameter of each lock code. If the parameter is not a value of "N", then that parameter is used as the control parameter for the lock code. If there is a control parameter greater than the current maximum control parameter but not equal to "N", then the maximum control parameter is updated, and the updated maximum control parameter is determined as the target control parameter. Conversely, if the parameter is a value of "N", then the corresponding position in the control parameter list is assigned a value of 0, that is, the parameter is not used as a control parameter. By determining the target control parameter through the priority of the lock code, the risk control strategy can be dynamically adjusted, supporting the collaborative control of lock codes across different levels and avoiding the overriding of other levels by a single-level lock code.

[0047] S120. When it is detected that the received target transaction data belongs to a credit card transaction, the target credit card information is determined and the target control parameters corresponding to the target credit card information are retrieved.

[0048] The target transaction data can be transaction data related to business transactions. Credit card transactions can be understood as business transactions associated with credit cards. For example, credit card transactions include: transactions involving goods based on credit cards or business transactions initiated by credit cards. The target credit card information can be the card information, user information, and account information of the credit card corresponding to the target transaction data.

[0049] Specifically, when it is detected that the received target transaction data belongs to a credit card transaction, the target credit card information of the credit card to which the target transaction data belongs is determined. Based on the target control parameters associated with the determined credit card, the target control parameters of the credit card corresponding to the target credit card information are retrieved.

[0050] S130. When the target transaction data and target control parameters meet the preset conditions, return the transaction completion response data corresponding to the target transaction data.

[0051] The target control parameters include at least one applicable business control parameter. Each business control parameter represents the control conditions for the corresponding business transaction. The target transaction data and target control parameters meeting preset conditions means that the target transaction data meets the business transaction control conditions corresponding to the target control parameter. The target transaction is the credit card transaction corresponding to the target transaction data. Transaction completion response data can be used to indicate that the credit card transaction corresponding to the target transaction data has been completed.

[0052] Specifically, if the target transaction data meets the business transaction control conditions corresponding to the target control parameters, and the target transaction data and target control parameters meet the preset conditions, then the credit card transaction corresponding to the target transaction data is determined to be reasonable, and the transaction completion response data corresponding to the target transaction data is returned.

[0053] The technical solution of this embodiment verifies at least one lock code of multiple credit cards based on pre-set management constraints for multiple credit card management levels, obtaining target control parameters corresponding to each credit card. This ensures the rationality and integrity of the lock code and facilitates risk management of credit cards through target control parameters. When it is detected that the received target transaction data belongs to a credit card transaction, the target credit card information is determined, and the target control parameters corresponding to the target credit card information are retrieved. The target transaction data belonging to the credit card transaction is verified through the target control parameters. When the target transaction data and the target control parameters meet the preset conditions, the transaction completion response data corresponding to the target transaction data is returned, indicating that the target transaction has been completed. Based on this, reasonable control and risk management of credit card transactions are achieved. This invention ensures the rationality and integrity of the lock code by verifying it, avoiding the problem of errors and low efficiency caused by manual management of lock codes. By determining the target control parameters corresponding to the lock code, and returning transaction completion response data indicating that the target transaction has been completed when the target control parameters and target transaction data meet preset conditions, the problem of insufficient intelligence in credit card management in existing technologies is solved. Intelligent management of credit card transactions based on lock codes and target control parameters is realized, and risk control of credit card transactions is automatically and effectively carried out, thereby improving the user's credit card experience.

[0054] Example 2

[0055] Figure 2 This is a flowchart of a method for allocating a lock code and a reason code according to Embodiment 2 of the present invention. This embodiment, based on the above embodiments, allows configuring a lock code and a corresponding reason code for the credit card before verifying the lock code. Specific implementation details can be found in the technical solution of this embodiment. Technical terms that are the same as or corresponding to those in the above embodiments will not be repeated here. Figure 2 As shown, the method includes:

[0056] S210. For each credit card, assign at least one lock code to the credit card based on multiple pre-defined credit card management levels.

[0057] The system includes multiple credit card management levels: customer level, account level, card level, and dedicated installment account level. Lock codes are used to identify the locked transactions and types of transactions for a credit card. Optionally, for each credit card management level, up to 10 lock codes can be added to form a lock code queue. The first lock code in the queue is the highest priority lock code currently in effect for that credit card management level. Optionally, the judgment and usage methods for the first lock code in the lock code queue may be hardcoded in some business procedures and / or external business systems.

[0058] Specifically, based on multiple preset credit card management levels and the threshold for the number of non-payments set for each management level, at least one locking code is added to the credit card when the number of non-payments exceeds the threshold. And / or, core business transaction information of the credit cards under each management level is retrieved through external business systems to assign at least one locking code to the credit card based on this information.

[0059] For example, taking the customer level as the credit card management level, a threshold of 4 non-payment counts is set for the corresponding customer level. When a customer's credit card non-payment count reaches 4, a customer-level lock code Z is added to the customer's credit card to control the customer's authorized use of overdraft and other business transactions. The core business transaction information of the credit card is accessed through external business systems to enable batch addition and deleting of lock codes and reason codes based on the core business transaction information, thus supporting flexible credit card risk management strategies.

[0060] S220. When it is detected that no reason code has been assigned to each lock code, retrieve the pre-set default reason code and assign it to the lock code.

[0061] The default reason code can be a preset reason code. For example, when the reason code is 6 characters, the default reason code can be 000000.

[0062] Specifically, when it is detected that no reason code has been assigned to each lock code, a pre-set default reason code can be retrieved and added to the lock code.

[0063] For example, if the lock code is A, and it is detected that no reason code has been assigned to the lock code A, then the pre-set default reason code 000000 is assigned to the lock code A, resulting in A000000.

[0064] S230. When it is detected that a reason code has been assigned to the lock code, associate the reason code with the lock code.

[0065] The reason code is used to refine the application scenario of the lock code, representing the reason for its allocation, the release condition, and its validity period. The reason code corresponds to a preset number of characters, which includes the reason for allocating the lock code and the release condition identifier. The reason code also includes a release condition and a release flag. The preset number of characters can be pre-set; it represents the number of characters in the reason code. Optionally, the preset number of characters for the reason code can be 6, meaning the reason code consists of a 6-character string. For example, the first two characters of the reason code represent the business system that allocated the reason code, the third and fourth characters represent the reason for adding the lock code, i.e., the reason for allocating the lock code, and the fifth and sixth characters represent the release condition identifier for releasing the lock code.

[0066] The release condition flag of the reason code can be used to characterize the conditions for unlocking the lock code. For example, the release condition flag can take the value 0 or 1. A release condition flag of 0 indicates that the reason code and the corresponding lock code can be unlocked through the normal release procedure. A release condition flag of 1 indicates that the reason code and the corresponding lock code can only be unlocked through the forced release procedure.

[0067] Optionally, the reason code also corresponds to an associated validity period field. The validity period field indicates the duration of the reason code's validity. The validity period field can be represented by an 8-digit number in the format YYYYMMDD. For example, the validity period field corresponding to the reason code could be 99991231, indicating that the reason code is valid indefinitely. While the reason code is within the validity period of its corresponding validity period field, it can influence the risk management of credit card transactions. If the reason code is not within the validity period of its corresponding validity period field, it automatically expires. If the expired reason code is the unique reason code for the lock code, the lock code associated with it is automatically removed; if the expired reason code is not the unique reason code for the lock code, the lock code remains valid.

[0068] It should be noted that each lock code has a default reason code of 000000. When it is detected that no reason code has been assigned to the lock code, the default reason code is added to the lock code. The default reason code is valid indefinitely.

[0069] Specifically, when it is detected that a reason code has been assigned to a lock code, the reason code is associated with the lock code to determine the specific reason for adding the lock code, the conditions for unlocking it, and the validity period information, thereby achieving automatic management of the lock code.

[0070] For example, see Figure 3 , Figure 3 Example image of a table for adding reason codes. Figure 3 If it is detected that the lock code A sent by the interface has not been assigned a reason code, then the default reason code 000000 is added to the lock code A, resulting in A000000. Since B000000 already exists in the queue, after adding the default operation code 000000 to the lock code A, the queue contains both A000000 and B000000.

[0071] exist Figure 3 If it is detected that reason code 000001 has been assigned to lock code A sent by the interface, then reason code 000001 is associated with lock code A to obtain A000001. Since A000000 and B000000 originally existed in the queue, after associating reason code 000001 with lock code A, the queue now contains A000000, A000001, and B000000.

[0072] exist Figure 3 If it is detected that reason code 000001 has already been assigned to lock code A sent by the interface, then reason code 000001 is associated with lock code A to obtain A000001. Since A000001 and B000000 already exist in the queue, that is, A000001 already exists in the queue, A000001 cannot be added to the queue again.

[0073] In this embodiment of the invention, the method further includes: reading the reason code associated with the credit card; when the reason code meets the release condition, obtaining the release identifier bit of the reason code; when the release identifier bit is the first identifier bit, deleting the reason codes whose release identifier bits are the first identifier bit and the second identifier bit; when the release identifier bit is the third identifier bit, deleting all reason codes whose release identifier bits are the first identifier bit, the second identifier bit and the third identifier bit.

[0074] The release condition can be a pre-set condition that must be met to release the reason code. The release flags are used to represent the release reason code. The first, second, and third flags can be identifier characters corresponding to the release reason code. Optionally, the first flag can be 1, the second flag can be 0, and the third flag can be 2.

[0075] Specifically, the process reads the reason code associated with the credit card. When the reason code meets the release conditions, it retrieves the release flag. If the release flag is the first flag, the release method initiated is forced release of the reason code, and reason codes with the first and second flags can be deleted. If the release flag is the third flag, the release method initiated is forced unlocking of the lock code, and all reason codes with the first, second, and third flags can be deleted. Furthermore, after successful release of the reason code, the corresponding lock code is deleted.

[0076] Optionally, this embodiment of the invention may include three release methods: general release reason code, forced release reason code, and forced release lock code. This will be described with the first flag bit set to 1, the second flag bit to 0, and the third flag bit to 2. When the reason code meets the release condition, if the release flag bit is 0 or empty, the initiated release method is general release reason code, which can only delete reason codes with a release flag bit of 0. When the reason code meets the release condition, if the release flag bit is 1, the initiated release method is forced release reason code, which can delete both reason codes with a release flag bit of 1 and reason codes with a release flag bit of 0; that is, any reason code with a release flag bit of 1 or 0 can be deleted. When the release flag bit is 2, the initiated release method is forced release lock code, which can release all reason codes associated with the lock code at once, and after successful release, the lock code associated with the reason code is also deleted.

[0077] For example, see Figure 4 , Figure 4 Example table diagram for reason code deletion. If the lock code sent to the interface is A, and there is no reason code (i.e., the release flag corresponding to the reason code is empty), then a default reason code is added to lock code A, resulting in A000000. Since the original queue already includes A000000 and B000000, when the release condition is met, the reason code with a release flag of 0 is deleted, and the queue now includes B000000.

[0078] If the detected reason code is A000001, and the original queue already contains A000000, and there is no reason code matching the one sent by the interface, then the reason code in the original queue cannot be deleted.

[0079] If the detected error is A000001 with the release flag set to 1, the original queue contained: A000000, A000001, and B000000. Since the release method initiated when the release flag is 1 is a forced release reason code, reason codes with release flags of 1 and 0 can be deleted from the queue. The current queue contains: A000000 and B000000.

[0080] When the interface detects A000001 with a release flag of 0, the original queue included A000001 and B000000. If the release flag is 0, the release method is a standard release reason code. Whether A000001 is released depends on whether its release flag is 0 or 1. If it's 0, the reason code is released; if it's 1, it is not released.

[0081] The detected value is A000001 sent from the interface, with the release flag set to 2. The original queue included A000000, A000001, and B000000. When the release flag is set to 2, the release method initiated is a forced release of the lock code, which allows the release of all reason codes for that lock code. The current queue includes B000000.

[0082] It should be noted that the release operation for reason codes includes not only release based on the release flag when the release conditions are met, but also automatic release when the reason code does not fall within the validity period of the corresponding validity period field. This operation can be implemented using a program that batch processes reason codes and lock codes. This program periodically scans all lock codes with expiration dates to check if they have expired. Once it detects that the validity period of a lock code's reason code has expired, it will automatically trigger the release process to update the reason code and lock code. By adding and releasing reason codes as described above, the automation level of risk control can be improved. By setting a validity period for reason codes and automatically releasing them upon expiration, manual record keeping and manual release operations can be reduced, lowering labor costs and enhancing the level of intelligence.

[0083] Optionally, for each credit card, when the reason code of the credit card is detected to meet the release condition, the lock code and reason code of the credit card to be deleted are recorded in the traceability table.

[0084] The traceability table can be used to record the lock code and reason code for deletion, which facilitates subsequent traceability.

[0085] Specifically, for each credit card, when the reason code of the credit card is detected to meet the unlocking conditions, the corresponding reason code and lock code can be deleted, and the deleted lock code and reason code of the credit card can be recorded in the traceability table to provide fine tracking and recording.

[0086] Optionally, whenever a change operation (addition, deletion, or modification) to the lock code and reason code is performed, a logic block for recording the reason code in a log table can be automatically triggered. This records the corresponding addition, deletion, or modification of the reason code lock code in the traceability table, providing a solid data foundation for subsequent historical tracing. Specifically, when a change in the lock code's status is detected, the specific information of the change is encapsulated in the configuration information maintenance log table. The entity object of the configuration information maintenance log table not only contains key metadata such as the date of the change operation, transaction code, and log number, but also meticulously records the specific content of the change operation, such as business level, business code, reason for change, forced release instruction, validity period, and operator remarks, ensuring the comprehensiveness and accuracy of the information.

[0087] To enhance information security and standardization, string formatting and masking techniques can be used to process operator comments, limiting their length while ensuring data consistency and readability. Furthermore, obtaining and formatting the timestamps of change operations ensures accurate recording of each lock code and reason code change, providing a time-based reference for subsequent work.

[0088] Optionally, the `insert` method can be called to persist the encapsulated configuration information maintenance log table entity object to the database. This enables real-time updates and storage of the configuration information maintenance log, ensuring the traceability of lock codes and reason codes, and providing strong support for the stable operation and compliance management of the business system. It not only guarantees data integrity but also improves operational transparency and historical traceability.

[0089] The technical solution of this embodiment achieves multi-level lock code management by assigning at least one lock code to a credit card based on multiple pre-set credit card management levels. This enables refined risk control for different business scenarios based on lock codes at different levels, improving the flexibility and accuracy of risk control. When it is detected that no reason code has been assigned to each lock code, a pre-set default reason code is retrieved and assigned to the lock code. When it is detected that a reason code has already been assigned to a lock code, the reason code is associated with the lock code. This achieves the assignment of reason codes to lock codes, supports refined management and automatic unlocking of lock codes, reduces manual intervention, and improves efficiency.

[0090] Example 3

[0091] Figure 5 This is a flowchart illustrating a method for determining target control parameters according to an embodiment of the present invention. This embodiment is an example of the above embodiments. For specific implementation details, please refer to the technical solution of this embodiment. Technical terms that are the same as or corresponding to those in the above embodiments will not be repeated here.

[0092] like Figure 5 As shown, the method includes:

[0093] S310. Based on the checkpoint mask, determine at least one lock code and number of non-payments for multiple credit cards corresponding to the credit card management level to be checked, and check them.

[0094] The checkpoint mask (bitmap) is used to determine the credit card management level that needs to be checked. For example, if the corresponding bit of the checkpoint mask is set to 1, then at least one lock code and the number of outstanding payments for multiple credit cards corresponding to a customer level can be checked.

[0095] For details, see Figure 6 In scenarios based on credit card transactions, the credit card management level to be checked can be determined first based on the checkpoint mask. If the checkpoint mask determines that the customer-level lock code and the corresponding number of non-payments need to be checked, then the customer-level lock code and number of non-payments (CD value) can be obtained and checked to ignore illegal data in the customer-level lock code and number of non-payments.

[0096] If the checkpoint mask determines that the account-level lock code and the corresponding number of non-payments on the credit card need to be checked, then the account-level lock code, number of non-payments (CD value), and peak number of non-payments can be obtained and checked to ignore illegal data in the account-level lock code and number of non-payments.

[0097] If the checkpoint mask determines that a card-level lock code needs to be checked, then the card-level lock code can be obtained and checked to ignore illegal data in the card-level lock code.

[0098] It should be noted that before checking the lock code for the corresponding credit card management level, you can first verify the completeness of the credit card information. This ensures that the credit card information is intact before performing the above checks. Conversely, if the credit card information is missing, an error message will be displayed indicating that the necessary credit card information has not been entered.

[0099] S320. Obtain the control parameters of multiple credit cards corresponding to the credit card management level to be checked, and perform legality verification on the control parameters to obtain the verified control parameters associated with each credit card.

[0100] Specifically, the system performs validity checks on the control parameters of multiple credit cards corresponding to the credit card management level to be checked, replacing non-numeric characters with 0. If a control parameter does not exist, an error is reported. If a control parameter is greater than the current maximum control parameter, the maximum control parameter is updated, and the control parameter list is updated to obtain the verified control parameters associated with each credit card.

[0101] S330. When the number of times a credit card has not been repaid reaches the expected number of times it has not been repaid, retrieve the verified control parameters of the credit card and update the verified control parameters according to the priority of at least one lock code associated with the credit card to obtain the target control parameters.

[0102] S310 to S330 correspond to S110 in the above embodiment, which is the process of determining the target control parameters.

[0103] For details, see Figure 6 If it is necessary to check the number of non-payments at the customer level, and the number of non-payments at the customer level is greater than or equal to the expected number of non-payments at the customer level (2), then the number of non-payments at the customer level is checked, and the maximum control parameter and the control parameter list are updated based on the corresponding verified control parameters. The maximum control parameter corresponds to the target control parameter in the above embodiment.

[0104] If it is necessary to check the peak number of non-payments at the account level, and the peak number of non-payments at the account level is greater than or equal to the expected number of non-payments at the account level (8), then check the peak number of non-payments at the account level, and update the maximum control parameter and control parameter list based on the corresponding verified control parameters.

[0105] If it is necessary to check the number of non-payments at the account level, and the number of non-payments at the account level is greater than or equal to the first expected number of non-payments at the account level (2), and the peak number of non-payments at the account level is less than or equal to the second expected number of non-payments at the account level (8), then check the number of non-payments at the account level, and update the maximum control parameter and control parameter list based on the corresponding verified control parameters.

[0106] If it is necessary to check the client-level lock code, and the lock code queue is not empty, then determine the first control parameter in the lock code queue whose value is not "N" based on the priority of the lock code represented by the lock code queue, and update the maximum control parameter and control parameter list based on the control parameter whose value is not "N".

[0107] If it is necessary to check the card-level lock code, and the lock code queue is not empty, then based on the priority of the lock codes represented by the lock code queue, the first control parameter in the lock code queue whose value is not "N" is determined, and the maximum control parameter and the control parameter list are updated according to this control parameter. After the maximum control parameter and the control parameter list are updated, the maximum control parameter is obtained, which is the target control parameter mentioned in the above embodiment.

[0108] The technical solution of this embodiment continuously updates the maximum control parameters and the control parameter list to determine the final updated maximum control parameters and control parameter list, thus obtaining the target control parameters. This completes a comprehensive check and determination of control parameters for the number of non-payments and lock codes at the customer, account, and card levels. This ensures effective management of the number of non-payments and lock codes at the customer, account, and card levels based on different checkpoints and control functions. By reading and comparing control parameters, the target control parameters mentioned in the above embodiment are determined, enabling reasonable control and risk prevention of business operations based on the target control parameters and lock codes.

[0109] Example 4

[0110] Figure 7 This is a schematic diagram of a credit card management device provided in Embodiment 4 of the present invention. Figure 7 As shown, the device includes: a control parameter determination module 410, a control parameter retrieval module 420, and a response data determination module 430.

[0111] The control parameter determination module 410 is used to verify at least one lock code of multiple credit cards according to the management constraints of multiple credit card management levels set in advance, and obtain the target control parameters corresponding to each credit card; the control parameter retrieval module 420 is used to determine the target credit card information and retrieve the target control parameters corresponding to the target credit card information when it is detected that the received target transaction data belongs to a credit card transaction; the response data determination module 430 is used to return the transaction completion response data corresponding to the target transaction data when the target transaction data and the target control parameters meet the preset conditions.

[0112] The technical solution of this embodiment verifies at least one lock code of multiple credit cards based on pre-set management constraints for multiple credit card management levels, obtaining target control parameters corresponding to each credit card. This ensures the rationality and integrity of the lock code and facilitates risk management of credit cards through target control parameters. When it is detected that the received target transaction data belongs to a credit card transaction, the target credit card information is determined, and the target control parameters corresponding to the target credit card information are retrieved. The target transaction data belonging to the credit card transaction is verified through the target control parameters. When the target transaction data and the target control parameters meet the preset conditions, the transaction completion response data corresponding to the target transaction data is returned, indicating that the target transaction has been completed. Based on this, reasonable control and risk management of credit card transactions are achieved. This invention ensures the rationality and integrity of the lock code by verifying it, avoiding the problem of errors and low efficiency caused by manual management of lock codes. By determining the target control parameters corresponding to the lock code, and returning transaction completion response data indicating that the target transaction has been completed when the target control parameters and target transaction data meet preset conditions, the problem of insufficient intelligence in credit card management in existing technologies is solved. Intelligent management of credit card transactions based on lock codes and target control parameters is realized, and risk control of credit card transactions is automatically and effectively carried out, thereby improving the user's credit card experience.

[0113] Optionally, based on the above embodiments, the device further includes: a lock code allocation module, used to allocate at least one lock code to each credit card based on multiple pre-set credit card management levels; wherein, the multiple credit card management levels include customer level, account level, card level and special installment account level, and the lock code is used to characterize the locked business and the locked business type of the credit card.

[0114] Optionally, the device further includes: a reason code allocation module, used to retrieve a pre-set default reason code and allocate it to the lock code when it is detected that no reason code has been allocated to each lock code; and to associate the reason code with the lock code when it is detected that a reason code has been allocated to the lock code; wherein the reason code corresponds to a character of a preset number of digits, the character of the preset number of digits includes the reason for allocating the lock code and the unlocking condition identifier for unlocking the lock code, and the reason code also includes the unlocking condition and the unlocking identifier bit.

[0115] Optionally, the control parameter determination module is used to determine the first credit card for which target control parameters are to be determined based on the expected number of non-payments and at least one credit card with a lock code in each credit card management level of the management constraints; for the first credit card, the target control parameters associated with the first credit card are determined based on the priority of at least one lock code associated with the first credit card; wherein the target control parameters include at least one business control parameter applicable to the business.

[0116] Optionally, the device further includes: a reason code deletion module, used to read the reason code associated with the credit card; when the reason code meets the release conditions, to obtain the release flag bit of the reason code; when the release flag bit is the first flag bit, to delete the reason codes whose release flag bits are the first flag bit and the second flag bit; when the release flag bit is the third flag bit, to delete all reason codes whose release flag bits are the first flag bit, the second flag bit and the third flag bit.

[0117] Optionally, the device further includes a traceability table recording module, used to record the lock code and reason code of the credit card being deleted in the traceability table when the reason code of the credit card is detected to meet the release condition for each credit card.

[0118] The credit card management device provided in this embodiment of the invention can execute the credit card management method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method.

[0119] Example 5

[0120] Figure 8 This is a schematic diagram of the structure of an electronic device provided in Embodiment 5 of the present invention. The electronic device 10 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0121] like Figure 8 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0122] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0123] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as methods for managing credit cards.

[0124] In some embodiments, the credit card management method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the credit card management method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the credit card management method by any other suitable means (e.g., by means of firmware).

[0125] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0126] Computer programs for implementing the credit card management method of the present invention can be written in any combination of one or more programming languages. These computer programs can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs can be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0127] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory 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 communication unit 19, or installed from storage unit 18, or installed from ROM 12. When the computer program is executed by processor 11, it performs the functions defined in the methods of the embodiments of the present invention.

[0128] Example 6

[0129] Embodiment 6 of the present invention also provides a computer-readable storage medium storing computer instructions for causing a processor to execute a method for managing a credit card, the method comprising:

[0130] Based on pre-set management constraints for multiple credit card management levels, at least one lock code for multiple credit cards is verified to obtain target control parameters corresponding to each credit card; when it is detected that the received target transaction data belongs to a credit card transaction, the target credit card information is determined and the target control parameters corresponding to the target credit card information are retrieved; when the target transaction data and target control parameters meet the preset conditions, the transaction completion response data corresponding to the target transaction data is returned, indicating that the target transaction has been completed.

[0131] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on 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 fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0132] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0133] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0134] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0135] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0136] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for managing credit cards, characterized in that, include: Based on the pre-set management constraints of multiple credit card management levels, at least one lock code of multiple credit cards is verified to obtain the target control parameters corresponding to each credit card; When it is detected that the received target transaction data belongs to a credit card transaction, the target credit card information is determined, and the target control parameters corresponding to the target credit card information are retrieved; When the target transaction data and the target control parameters meet the preset conditions, the system returns transaction completion response data corresponding to the target transaction data, indicating that the target transaction has been completed.

2. The method according to claim 1, characterized in that, The method further includes: For each credit card, at least one lock code is assigned to the credit card based on multiple pre-defined credit card management levels; The multiple credit card management levels include customer level, account level, card level, and special installment account level. The locking code is used to identify the locked business and the type of locked business of the credit card.

3. The method according to claim 2, characterized in that, The method further includes: When it is detected that no reason code has been assigned to each of the lock codes, a pre-set default reason code is retrieved and assigned to the lock code; When it is detected that a reason code has been assigned to the lock code, the reason code is associated with the lock code; The reason code corresponds to a character of a preset length, which includes the reason for assigning the lock code and the unlocking condition identifier for unlocking the lock code. The reason code also includes an unlocking condition and an unlocking identifier bit.

4. The method according to claim 1, characterized in that, The step involves verifying at least one lock code for multiple credit cards based on pre-set management constraints for multiple credit card management levels, to obtain target control parameters corresponding to each credit card, including: Based on the expected number of non-payments and at least one locked credit card in each credit card management level of the management constraints, determine the first credit card for which the target control parameter is to be determined; For the first credit card, target control parameters associated with the first credit card are determined based on the priority of at least one lock code associated with the first credit card; The target control parameters include at least one service control parameter applicable to the service.

5. The method according to claim 3, characterized in that, The method further includes: Read the reason code associated with the credit card; When the reason code meets the release condition, obtain the release flag bit of the reason code; When the release flag is the first flag, delete the reason code where the release flag is the first flag and the second flag. When the release flag is the third flag, delete all reason codes where the release flag is the first flag, the second flag, and the third flag.

6. The method according to claim 1, characterized in that, The method further includes: For each credit card, when the reason code of the credit card is detected to meet the release condition, the lock code and reason code of the credit card to be deleted are recorded in the traceability table.

7. A device for managing credit cards, characterized in that, include: The control parameter determination module is used to verify at least one lock code of multiple credit cards based on the management constraints of multiple credit card management levels set in advance, and to obtain the target control parameters corresponding to each credit card. The control parameter retrieval module is used to determine the target credit card information and retrieve the target control parameters corresponding to the target credit card information when it is detected that the received target transaction data belongs to a credit card transaction. The response data determination module is used to return transaction completion response data corresponding to the target transaction data when the target transaction data and the target control parameters meet preset conditions.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the credit card management method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the credit card management method according to any one of claims 1-6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the credit card management method as described in any one of claims 1-6.

Images