Transaction processing method and device

By identifying transaction categories and calculating credit limit thresholds, the challenges faced by credit service providers in managing shared credit limits are addressed, enabling flexible and secure credit allocation and improving transaction success rates and resource utilization.

CN122089466APending Publication Date: 2026-05-26CHONGQING ANT CONSUMER FINANCE CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202610121107.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-10-23
Publication Date
2026-05-26

AI Technical Summary

Technical Problem

Users' needs for credit limits are becoming increasingly diverse, which poses challenges and pressures to credit service providers, as existing technologies are struggling to effectively manage and allocate shared credit limits.

Method used

By identifying the transaction category, detecting whether it is within a shared credit limit set, querying the credit limit allocation parameters, calculating the credit limit threshold, and processing the transaction after the detection is passed, the transaction trigger detection is carried out using the credit limit threshold and the credit limit used to ensure credit limit security.

Benefits of technology

It enables flexible management and secure use of shared credit limits, improves transaction success rate and resource utilization, and meets diverse user needs.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122089466A_ABST
    Figure CN122089466A_ABST
Patent Text Reader

Abstract

The invention provides a transaction processing method and device, and the method comprises the steps: carrying out the transaction type recognition of a transaction request of a user, obtaining a transaction type, and carrying out the recognition of a transaction type under the condition that the transaction type is in a transaction type set sharing a credit line, and carrying out transaction trigger detection on the transaction request by combining the quota distribution parameters under the transaction categories, the shared credit quota and the credit quota corresponding to the quota credit quota record of the transaction categories, so as to realize quota sharing and credit quota sharing of each transaction category through the shared credit quota.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] This patent application is a divisional application of Chinese patent application No. CN202511518073.4, filed on October 23, 2025, entitled "Transaction Processing Method and Apparatus". Technical Field

[0002] This invention relates to the field of data processing technology, and in particular to a transaction processing method and apparatus. Background Technology

[0003] With the continuous development and promotion of Internet technology, the application scope of online services provided by Internet technology is becoming wider and wider, providing users with convenient service methods. For example, credit service providers offer users feasible ways to conduct transactions through credit limits. A credit limit refers to the credit limit approved for a user based on a comprehensive consideration of the user's asset status and other factors, which facilitates users to respond to sudden funding needs in a timely manner. However, the increasingly diversified needs of users for using credit limits have also brought certain challenges and pressures to credit service providers. Summary of the Invention

[0004] One or more embodiments of the present invention provide a transaction processing method, comprising: identifying a transaction category based on a user-submitted transaction request; detecting whether the transaction category belongs to a set of transaction categories with a shared credit limit; transactions under each transaction category in the set of transaction categories are based on the shared credit limit, and each transaction category corresponds to a credit limit disbursement record for its own shared credit limit; if so, querying the credit limit allocation parameters under the transaction category, and calculating a credit limit threshold for the transaction category based on the credit limit allocation parameters and the shared credit limit; and performing transaction trigger detection on the transaction request based on the credit limit threshold and the credit limit disbursement record corresponding to the transaction category, and processing the transaction after the detection passes.

[0005] One or more embodiments of the present invention provide a transaction processing apparatus, comprising: a category identification module configured to identify a transaction category based on a user-submitted transaction request; a detection module configured to detect whether the transaction category is within a set of transaction categories sharing a credit limit. Transactions under each transaction category in the set of transaction categories are based on the shared credit limit, and each transaction category corresponds to a credit limit disbursement record for its own shared credit limit; if so, a parameter query module configured to query credit limit allocation parameters under the transaction category and calculate a credit limit threshold for the transaction category based on the credit limit allocation parameters and the shared credit limit; and a trigger detection module configured to perform transaction trigger detection on the transaction request based on the credit limit threshold and the credit limit disbursement record corresponding to the transaction category, and to process the transaction after the detection is successful.

[0006] One or more embodiments of the present invention provide a transaction processing device, comprising: a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to: identify a transaction category based on a user-submitted transaction request; detect whether the transaction category is within a set of transaction categories sharing a credit limit. Transactions under each transaction category in the set of transaction categories are based on the shared credit limit, and each transaction category corresponds to a credit limit disbursement record for its own shared credit limit; if so, query the credit limit allocation parameters under the transaction category, and calculate a credit limit threshold for the transaction category based on the credit limit allocation parameters and the shared credit limit; and perform transaction trigger detection on the transaction request based on the credit limit threshold and the credit limit disbursement record corresponding to the transaction category, and process the transaction upon successful detection.

[0007] One or more embodiments of the present invention provide a computer-readable storage medium for storing computer-executable instructions, which, when executed, perform the following steps: Identifying a transaction category based on a user-submitted transaction request to obtain a transaction category; Detecting whether the transaction category belongs to a set of transaction categories with a shared credit limit. Transactions under each transaction category in the set of transaction categories are based on the shared credit limit, and each transaction category corresponds to its own credit limit disbursement record for the shared credit limit; If yes, querying the credit limit allocation parameters under the transaction category, and calculating the credit limit threshold for the transaction category based on the credit limit allocation parameters and the shared credit limit; Based on the credit limit threshold and the disbursement credit limit corresponding to the credit limit disbursement record of the transaction category, performing transaction trigger detection on the transaction request, and processing the transaction after the detection passes. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in one or more embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Figure 1 A schematic diagram illustrating the implementation environment of a transaction processing method provided in one or more embodiments of the present invention; Figure 2 A flowchart of a transaction processing method provided in one or more embodiments of the present invention; Figure 3 A flowchart illustrating a transaction processing method for a credit payment scenario, provided for one or more embodiments of the present invention; Figure 4 A schematic diagram of an embodiment of a transaction processing apparatus provided by one or more embodiments of the present invention; Figure 5 This is a schematic diagram of the structure of a transaction processing device provided in one or more embodiments of the present invention. Detailed Implementation

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

[0010] The transaction processing method provided by one or more embodiments of the present invention can be applied to the implementation environment of credit payment, as described below. Figure 1 The implementation environment includes at least: Server 101; in addition, the implementation environment may also include user terminal 102; Server 101 is used to identify the transaction category of a transaction request and obtain the transaction category. When the transaction category is in a set of transaction categories with shared credit limits, it calculates the credit limit threshold of the transaction category based on the credit limit allocation parameters under the transaction category and the shared credit limit. Based on the credit limit threshold, it performs transaction trigger detection on the transaction request and processes the transaction after the detection is passed. Server 101 can be one or more servers, a server cluster composed of several servers, or a cloud server of a cloud computing platform. User terminal 102 is used to submit transaction requests; user terminal 102 may specifically be a mobile phone, personal computer, tablet computer, e-book reader, wearable device, device for information interaction based on AR (Augmented Reality) / VR (Virtual Reality), and laptop computer, etc.

[0011] In this implementation environment, server 101 identifies the transaction category of the transaction request. If the transaction category is within the set of transaction categories with shared credit limits, it calculates the credit limit threshold for the transaction category based on the credit limit allocation parameters under the transaction category and the shared credit limit. Based on the credit limit threshold, the transaction request is triggered for transaction trigger detection. After the detection passes, the transaction is processed. In this way, the credit limit is shared for each transaction category. The transaction request can be submitted to server 101 by user terminal 102.

[0012] One or more embodiments of a transaction processing method provided by the present invention are as follows: Reference Figure 2 The transaction processing method provided in this embodiment can be applied to a server, and specifically includes steps S201 to S204.

[0013] Step S201: Obtain the transaction category by identifying the transaction category based on the transaction request submitted by the user.

[0014] The transaction category mentioned in this embodiment refers to the category of the transaction. The transaction category can be a transaction scenario, such as an education scenario, a medical scenario, or a specific product transaction scenario. A medical scenario can be a medical scenario for a specific medical project, such as a dental medical project. A specific product transaction scenario is an electronic product transaction scenario.

[0015] In practice, the transaction category is obtained by identifying the transaction category based on the transaction request submitted by the user. Specifically, the transaction category can be obtained by identifying the transaction category based on the transaction request submitted by the user through the credit payment channel. More specifically, the transaction scenario can be obtained by identifying the transaction scenario based on the merchant identifier carried in the transaction request. More specifically, the transaction scenario can be obtained by identifying the transaction scenario based on the merchant category corresponding to the merchant identifier. The credit payment channel refers to a payment channel that makes payments based on a credit limit. The credit limit can be a credit limit approved for the user to use for transactions. Specifically, the credit payment channel can be a payment channel that makes payments based on a shared credit limit. In this embodiment, credit can be replaced with credit granting. The server can be a credit platform corresponding to the credit payment channel, a third-party credit platform, or a payment platform. The user's credit payment channel can be activated to the user after the user submits an activation instruction through an application or a credit service within the application. The application can be a payment application or a third-party application, and the credit service can be a subroutine, which can be a credit subroutine or a credit granting subroutine.

[0016] It should be noted that the above-mentioned operation of identifying the transaction category based on the transaction request submitted by the user can be replaced by identifying the transaction category based on the submitted transaction request or by identifying the transaction category based on the transaction request submitted through the credit payment channel, and can be combined with other processing steps provided in this embodiment to form a new implementation method.

[0017] Step S202: Detect whether the transaction category is in the set of transaction categories with shared credit limits.

[0018] The transaction category is obtained by identifying the transaction category based on the transaction request submitted by the user. In this step, the transaction category is determined to share the shared credit limit by detecting whether the transaction category is in the set of transaction categories with shared credit limit, thereby determining the availability of the shared credit limit for the transaction category.

[0019] The shared credit limit mentioned in this embodiment refers to the credit limit shared by users in one or more transaction categories for transactions. The shared credit limit can be the credit limit shared by users in each transaction category within the transaction category set; the transaction category set refers to a collection of one or more transaction categories.

[0020] The shared credit limit can exist in a corresponding set of transaction categories. The shared credit limit provides a dedicated credit limit for transactions under each transaction category in the set of transaction categories, and each transaction category shares the shared credit limit. Optionally, transactions under each transaction category in the set of transaction categories are based on the shared credit limit, and each transaction category has its own credit limit usage record. On the one hand, the credit limit disbursement record for each transaction category can be a record of the credit limit disbursed for each transaction category. In this case, the credit limit disbursed for each transaction category can be obtained from the credit limit disbursement record. The credit limit disbursed refers to the credit limit already disbursed, specifically the total credit limit already used under each transaction category. On the other hand, the credit limit disbursement record for each transaction category can be the credit limit disbursement flow for each transaction under each transaction category. The credit limit disbursement flow can be generated based on the transaction amount, transaction time, transaction location, transaction device type, and / or transaction mode of each transaction. In this case, the credit limit disbursement for each transaction category can be calculated based on the transaction amount contained in the credit limit disbursement record for each transaction category. Specifically, the sum of the transaction amounts contained in the credit limit disbursement record for each transaction category can be calculated as the credit limit disbursement for each transaction category.

[0021] In practice, it can detect whether the transaction category is in the set of transaction categories with shared credit limits. Shared credit limits can include the credit limits that users can use in each transaction category.

[0022] Optionally, the shared credit limit is recorded through a shared credit account included in the shared data model, and the credit limit disbursement records for the transaction categories are recorded through the credit sub-accounts of the shared credit account. Specifically, the shared data model can be constructed based on the shared credit account and / or the credit sub-accounts of the shared credit account, and the credit sub-accounts of the shared credit account can correspond one-to-one with each transaction category in the transaction category set of the shared credit limit. The shared credit account can be a credit account that records the shared credit limit, and the credit sub-accounts of the shared credit account can be sub-accounts that record the credit limit disbursement records for the corresponding transaction categories.

[0023] In practice, when a transaction falls within a set of transaction categories sharing a credit limit, it indicates that a transaction may occur under that category. To improve resource utilization and reduce server space usage, credit sub-accounts corresponding to the transaction category can be dynamically attached. Optionally, credit sub-accounts can be dynamically attached to the credit platform after the transaction category is checked to see if it falls within a set of transaction categories sharing a credit limit. Here, dynamic attachment refers to dynamic loading. Specifically, the credit sub-account corresponding to the previous transaction category can be dynamically switched based on the credit sub-account corresponding to the transaction category. The previous transaction category refers to the transaction category obtained by identifying the transaction category of the previous transaction request.

[0024] In practical applications, unused credit limits under a transaction category may fail to meet transaction conditions, leading to transaction failure. To address this, and to improve transaction success rates, in addition to the aforementioned method of dynamically attaching credit sub-accounts corresponding to transaction categories, alternatively, the shared data model associated with shared credit limits can be dynamically attached to the credit platform upon detecting a transaction request. This dynamic attachment of the entire shared data model to the credit platform upon detecting a transaction request allows for transactions to be performed based on other transaction categories within the shared data model after a transaction fails under a specific category, thereby improving the user's transaction success rate.

[0025] In practical applications, each user's demand for shared credit limits may differ. To meet the diverse needs of each user for shared credit limits and improve the flexibility in determining shared credit limits, this embodiment provides an optional implementation method that determines the shared credit limit based on each transaction category and / or user data. Specifically, the shared credit limit can be calculated based on the user credit limits for each transaction category determined based on each transaction category and / or user data. Further, the shared credit limit can be determined in the following manner: Credit limits for each transaction category are determined based on transaction category and user data, thereby obtaining the user credit limit for each transaction category; The shared credit limit is determined based on the user's credit limit for each transaction category.

[0026] User data refers to user-related data; user data may include browsing behavior data, historical transaction behavior data of users through credit payment channels, user asset data and / or user attribute data; browsing behavior data may be user browsing behavior data in the credit service and / or browsing behavior data in the application to which the credit service belongs, user asset data may include asset type and / or asset value; user attribute data may include years of growth, salary and / or occupation, and user attribute data may also be other types of data.

[0027] Specifically, in the process of determining the credit limit for each transaction category based on transaction category and user data, and obtaining the user credit limit for each transaction category, the transaction category and user data can be input into the credit limit decision model to obtain the user credit limit for each transaction category. In the process of determining the shared credit limit based on the user credit limit for each transaction category, the average value of the user credit limit for each transaction category can be used as the shared credit limit, or the user credit limit for each transaction category can be weighted to obtain a weighted credit limit, and the average value of the weighted credit limit can be used as the shared credit limit.

[0028] In the specific implementation process, a shared credit limit can be first activated for users. This shared credit limit can be a credit limit shared for transactions under one or more transaction categories. Once users have obtained the shared credit limit, each transaction category can be determined based on the shared credit limit, and a transaction category set can be constructed based on each transaction category. In one optional implementation method provided in this embodiment, each transaction category is obtained through any of the following methods: Each transaction category is determined based on the user's configuration instructions for the transaction category of the shared credit limit; Based on the user's asset type, category matching is performed among multiple candidate transaction categories to obtain each transaction category; Obtain multiple intermediate transaction categories submitted by users for the shared credit limit, and determine each transaction category among the multiple intermediate transaction categories based on the credit limit unit in which the shared credit limit is located.

[0029] The credit limit unit can be a credit limit range or a credit limit interval.

[0030] Specifically, in the process of determining each transaction category based on the user's transaction category configuration instruction for the shared credit limit, the transaction category carried by the user's transaction category configuration instruction for the shared credit limit can be used as each transaction category; in the process of obtaining each transaction category by matching the user's asset type among multiple candidate transaction categories, the user's asset type and multiple candidate transaction categories can be matched and detected to obtain the matching degree, the multiple candidate transaction categories can be sorted based on the matching degree, and the candidate transaction category whose ranking is before the preset ranking in the ranking result can be determined as each transaction category.

[0031] In addition, any two or three of the three methods provided above can be used to determine each transaction category. For example, the transaction category can be determined from the multiple intermediate transaction categories submitted by the user for the shared credit limit based on the user's asset type and the credit limit unit in which the shared credit limit is located.

[0032] Based on this, in an optional implementation of this embodiment, during the process of determining each transaction category among multiple intermediate transaction categories according to the credit limit unit where the shared credit limit is located, the intermediate transaction categories whose historical transaction count of the cluster corresponding to the credit limit unit is greater than the historical transaction count of the remaining clusters are taken as each transaction category; specifically, the following operations can be performed: Cluster users’ historical transactions under each intermediate transaction category based on credit limit units; The intermediate transaction categories are defined as those whose historical transaction counts are greater than those of the remaining clusters.

[0033] Among them, the number of historical transactions in a cluster refers to the number of historical transactions contained in the cluster; the number of historical transactions in the remaining clusters refers to the number of historical transactions contained in the other clusters besides the cluster.

[0034] Specifically, in the process of clustering a user's historical transactions under each intermediate transaction category based on the credit limit unit, for each intermediate transaction category, the historical transactions that match the credit limit unit can be taken as the cluster corresponding to the credit limit unit, and the historical transactions that do not match the credit limit unit can be taken as the remaining cluster. Here, the historical transactions that match the credit limit unit under the intermediate transaction category can be either the transaction amount of the historical transaction is within the credit limit unit or the transaction amount of the historical transaction is within the transaction amount threshold mapped by the credit limit unit.

[0035] Step S203: Query the credit allocation parameters under the transaction category, and calculate the credit threshold of the transaction category based on the credit allocation parameters and the shared credit limit.

[0036] The above-mentioned detection of whether the transaction category is within the set of transaction categories with shared credit limits involves the following steps: If the transaction category is within the set of transaction categories with shared credit limits, the credit limit allocation parameters under the transaction category are queried, and the credit limit threshold of the transaction category is calculated based on the credit limit allocation parameters and the shared credit limit; if the transaction category is not within the set of transaction categories with shared credit limits, the transaction request can be processed based on the user's general credit limit.

[0037] The credit limit allocation parameter mentioned in this embodiment refers to the credit limit allocation parameter for the transaction category. The credit limit allocation parameter can be a credit limit allocation ratio or a credit limit utilization ratio. For example, if the transaction category is education, the credit limit allocation ratio under the transaction category is a%. The credit limit threshold refers to the upper limit or threshold for credit limit utilization under the transaction category. Specifically, the credit limit threshold can be the upper limit of the credit limit that can be used for transactions under the transaction category.

[0038] In practice, when the transaction category falls within a set of transaction categories sharing a credit limit, the credit allocation parameters for that transaction category can be queried. The credit limit threshold for the transaction category can be calculated by combining the credit allocation parameters and the shared credit limit. Specifically, the product of the credit allocation parameters and the shared credit limit can be used as the credit limit threshold for the transaction category. When the transaction category does not fall within a set of transaction categories sharing a credit limit, no action is taken, a transaction failure notification is sent to the user, or the user's general credit limit is queried, and the transaction request is processed based on the general credit limit. After querying the user's general credit limit, it can also be checked whether the unused credit limit of the general credit limit is greater than or equal to the transaction amount. If so, the transaction request is processed based on the general credit limit. Optionally, the operation of calculating the credit limit threshold for the transaction category based on the credit allocation parameters and the shared credit limit is performed if the credit allocation parameters are less than a preset threshold. The transaction amount can be transaction funds or transaction resources. The general credit limit can be the credit limit used regardless of the transaction category, and the unused credit limit can be any unused credit limit.

[0039] In practical applications, there may be a need to add new transaction categories. To address this, different credit limit allocation parameters can be set for different transaction categories, allowing for flexible adjustment of these parameters. For example, a lower credit limit allocation parameter can be set for new transaction categories to reduce the transaction risk associated with transactions using shared credit limits under these new categories. In one optional implementation of this embodiment, if the credit limit allocation parameter is greater than or equal to a preset parameter threshold, the following operation is performed: The total credit limit is calculated based on the transaction amount and the corresponding credit limit for each transaction category. If the total expenditure limit matches the shared credit limit, the transaction request will be processed based on the shared credit limit.

[0040] Optionally, the credit limit allocation parameters are determined based on the number of transaction users and / or the transaction lifecycle of transactions under the transaction category through credit payment channels. Specifically, they can be obtained after inputting the number of transaction users and / or the transaction lifecycle of transactions under the transaction category through credit payment channels into the decision tree for credit limit allocation decision. The number of transaction users refers to the number of users who conduct transactions, and the transaction lifecycle can be the transaction duration of transactions under the transaction category through credit payment channels.

[0041] Specifically, the total spending limit can be calculated by summing the transaction amount with the corresponding credit limit for each transaction category. If the total spending limit is less than or equal to the shared credit limit, the transaction request will be processed based on the shared credit limit. If the total spending limit is greater than the shared credit limit, no processing will be performed or a transaction failure reminder indicating that the spending limit has exceeded the limit will be issued to the user.

[0042] In practical applications, users may conduct transactions through different transaction modes. To address this and meet diverse user needs, and improve the efficiency of querying credit limit allocation parameters, this embodiment provides an optional implementation where, during the query of credit limit allocation parameters under a transaction category, the credit limit allocation parameters are queried based on the transaction mode, transaction category, and / or credit payment channel of the transaction request, or the credit limit allocation configuration under the transaction category is queried, and the credit limit allocation parameters are read from the credit limit allocation configuration. Specifically, the following operations can be performed: Determine the transaction mode of the transaction request, and query the quota allocation configuration under the transaction category based on the transaction type and transaction mode; Read the quota allocation parameters from the quota allocation configuration.

[0043] Optionally, the transaction modes include: a first transaction mode where transactions are conducted through a transaction service, a second transaction mode where transactions are conducted based on a near-field communication (NFC) connection, or a third transaction mode where the user terminal scans the merchant's payment identifier. Transaction modes may also include transaction modes conducted via QR code scanning, online transaction modes, and / or transaction modes conducted based on a NFC connection. Optionally, the credit limit allocation configuration also includes an account identifier for the credit sub-account storing credit limit disbursement records for each transaction category. The account identifier is used to query the credit limit disbursement rules mapped by the credit limit allocation configuration for disbursement of the shared credit limit.

[0044] Specifically, the system can query the credit limit allocation configuration of the credit payment channel under the transaction category based on the transaction type, transaction mode of the transaction request, and / or credit payment channel, and read the credit limit allocation parameters from the credit limit allocation configuration. The credit limit allocation parameters may include the credit limit allocation ratio, and the credit limit allocation configuration may include the credit limit allocation ratio, the account identifier of the shared credit account, and / or the account identifier of the credit sub-account of the transaction category. The transaction type, transaction mode, and / or credit payment channel identifier can be recorded in the transaction configuration. One or more transaction configurations can be associated with the credit limit allocation configuration, and the credit limit allocation configuration can be associated with credit limit disbursement rules. The credit limit disbursement rules can be generated based on the account identifier of the credit sub-account, whether overdraft is allowed, the overdraft limit, supported currencies, and / or the disbursement account activation flag. The disbursement account activation flag indicates whether to automatically activate a credit sub-account for the user when the user has a shared credit limit but no credit sub-account.

[0045] In practical application scenarios, when there is a need to add new transaction categories to credit payment channels, service users can add transaction categories through the credit service or dedicated service application to which the credit payment channel belongs. Through the configuration page of the credit service or dedicated service application, users can input the new transaction category, the transaction mode supported by the new transaction category, and / or the channel identifier of the credit payment channel supported by the new transaction category. The service user's terminal device can construct the new transaction configuration based on the new transaction category, the transaction mode supported by the new transaction category, and / or the channel identifier of the credit payment channel supported by the new transaction category. The existing credit limit allocation configuration obtained by the query can be associated with the new transaction configuration according to the query command submitted by the service user; or, after constructing the new transaction configuration, the new credit limit allocation configuration set by the service user on the configuration page can also be associated with the new transaction configuration.

[0046] It should be noted that the above step of checking whether the transaction category belongs to the set of transaction categories with shared credit limits, and if so, querying the credit limit allocation parameters under the transaction category and calculating the credit limit threshold for the transaction category based on the credit limit allocation parameters and the shared credit limit, can be replaced by querying the credit limit allocation parameters under the transaction category and calculating the credit limit threshold for the transaction category when the transaction category belongs to the set of transaction categories with shared credit limits; or it can be replaced by querying the credit limit allocation parameters under the transaction category and calculating the credit limit threshold for the transaction category based on the credit limit allocation parameters and the shared credit limit; or it can be replaced by root The threshold for a transaction category is calculated based on the credit allocation parameters and / or shared credit limit under the transaction category. Alternatively, it can be replaced by calculating the threshold for the transaction category based on the credit allocation parameters and / or shared credit limit if the transaction category is in a set of transaction categories with shared credit limits. The operation of calculating the threshold for the transaction category based on the credit allocation parameters and / or shared credit limit under the transaction category can be replaced by calculating the threshold for the transaction category based on the credit payment channel's credit allocation parameters and / or shared credit limit under the transaction category, and this, together with other processing steps provided in this embodiment, forms a new implementation.

[0047] Step S204: Based on the credit limit threshold and the credit limit corresponding to the credit limit expenditure record of the transaction category, perform transaction trigger detection on the transaction request, and process the transaction after the detection is passed.

[0048] The above query query the credit limit allocation parameters under the transaction category, calculate the credit limit threshold for the transaction category based on the credit limit allocation parameters and the shared credit limit, so as to avoid the shared credit limit being overdrawn and improve the security of the shared credit limit. In this step, the transaction request is triggered by combining the credit limit threshold and the credit limit corresponding to the credit limit withdrawal record of the transaction category, and the transaction is processed after the detection is passed; and the credit limit corresponding to the credit limit withdrawal record of the transaction category can be updated.

[0049] The credit limit usage record for a transaction category mentioned in this embodiment refers to the credit limit usage of a user within a transaction category. Specifically, on one hand, the credit limit usage record for a transaction category can be a record of the credit limit used within that transaction category. In this case, the credit limit corresponding to the credit limit usage record for a transaction category can be obtained from the credit limit usage record for that transaction category. The credit limit used refers to the credit limit that has been used, specifically the total credit limit used within the transaction category. On the other hand, the credit limit usage record for a transaction category can be a transaction flow record for each transaction within the transaction category. The transaction flow record can be generated based on the transaction amount, transaction time, transaction location, transaction device type, and / or transaction mode of each transaction. In this case, the credit limit corresponding to the credit limit usage record for a transaction category can be calculated based on the transaction amount contained in the credit limit usage record for that transaction category. Specifically, the sum of the transaction amounts contained in the credit limit usage record for a transaction category can be calculated as the credit limit corresponding to the credit limit usage record for that transaction category.

[0050] The credit limit used for a transaction category can be the credit limit that has already been used or utilized under that transaction category, and the credit limit used can be the cumulative credit limit. In addition, the credit limit used for a transaction category may also include other types of data.

[0051] In practical implementation, different credit limit allocation parameters can be set for different transaction categories to obtain the credit limit threshold for each transaction category. This threshold ensures that transaction requests meet transaction requirements and guarantees the security of the shared credit limit for the overall set of transaction categories. In one optional implementation of this embodiment, during the transaction trigger detection process based on the credit limit threshold and the credit limit corresponding to the transaction category's credit limit usage record, if the expected usage limit calculated based on the credit limit and / or the transaction amount carried by the transaction request is less than or equal to the credit limit threshold, the transaction trigger detection result is determined to be a successful detection; if the calculated expected usage limit is greater than the credit limit threshold, the detection result is determined to be a failed detection. Specifically, the following operations can be performed: The expected spending limit is calculated based on the credit limit and the transaction amount carried in the transaction request; If the expected spending limit is less than or equal to the limit threshold, the detection result of the transaction trigger detection is determined to be a successful detection.

[0052] Specifically, in the process of calculating the expected spending limit based on the credit limit and the transaction amount carried in the transaction request, the credit limit and the transaction amount carried in the transaction request can be aggregated to obtain the expected spending limit, or the sum of the credit limit and the transaction amount can be calculated as the expected spending limit; if the expected spending limit is greater than the limit threshold, the detection result of the transaction trigger detection can be determined as detection failure.

[0053] In practical applications, in addition to independently performing transaction trigger detection for each transaction category's credit limit and limit threshold, to improve the comprehensiveness of transaction detection, this embodiment provides an optional implementation where, after calculating the expected credit limit based on the credit limit and the transaction amount carried in the transaction request, and determining the transaction trigger detection result as passed if the expected credit limit is less than or equal to the limit threshold, after performing transaction trigger detection on the transaction request based on the limit threshold and the credit limit corresponding to the credit limit usage record of each transaction category, transaction relationship parsing is also performed on the global expected credit limit and shared credit limit. If the parsed transaction relationship is a participating transaction relationship, transaction processing is performed. The global expected credit limit can be calculated based on the transaction amount and the credit limit corresponding to the credit limit usage record of each transaction category. Specifically, after performing transaction trigger detection on the transaction request, the following operations can also be performed: The overall expected spending limit is calculated based on the transaction amount and the corresponding spending credit limit for each transaction category. Perform transaction relationship analysis on the global expected spending limit and shared credit limit. If the analysis result indicates a participating transaction relationship, execute the transaction processing operation.

[0054] Among them, the transaction relationship refers to the transaction relationship in which transaction requests can be processed through the global expected expenditure limit and the shared credit limit.

[0055] Specifically, in calculating the global expected spending limit based on the transaction amount and the corresponding credit limits for each transaction category, the global expected spending limit can be obtained by aggregating the transaction amount and the corresponding credit limits for each transaction category, or by calculating the sum of the transaction amount and the corresponding credit limits for each transaction category. In resolving the transaction relationship between the global expected spending limit and the shared credit limit, the two can be compared. If the comparison result shows that the global expected spending limit is less than or equal to the shared credit limit, the transaction relationship is determined to be a participating transaction relationship. If the comparison result shows that the global expected spending limit is greater than the shared credit limit, the transaction relationship is determined to be a non-participating transaction relationship. If the resolved transaction relationship is a non-participating transaction relationship, a transaction failure reminder can be sent to the user, no action can be taken, or the user's general credit limit can be queried, and the transaction can be processed based on the general credit limit.

[0056] In practical applications, after performing transaction trigger detection on a transaction request, there may be cases where the detection fails. To address this, and in order to meet the user's transaction needs in cases where the detection fails, and to improve the transaction success rate for users in such cases, in the first optional implementation of this embodiment, after performing transaction trigger detection on the transaction request based on the credit limit corresponding to the credit limit disbursement record based on the credit limit threshold and transaction type, the following operations are also performed: If the detection fails, the transaction request will be processed based on the user's general credit limit.

[0057] Optionally, the general credit limit is recorded through the general credit account included in the general data model, the shared credit limit is recorded through the shared credit account included in the shared data model, and the credit limit disbursement record for each transaction category is recorded through the credit sub-account of the shared credit account. Optionally, the credit sub-account is switched based on the credit sub-account corresponding to the general credit account before the transaction request is processed and executed based on the user's general credit limit. Specifically, the credit sub-account of the shared credit account can be the credit sub-account corresponding to the transaction category before the transaction request is processed and executed based on the credit sub-account of the general credit account.

[0058] Specifically, in the process of processing transaction requests based on a user's general credit limit, if the transaction amount is less than or equal to the user's unused general credit limit, the transaction can be processed based on the unused credit limit. Alternatively, a general credit limit threshold can be calculated based on the credit limit allocation parameters of the transaction category and the user's general credit limit. If the transaction amount meets the general credit limit threshold or is less than or equal to the general credit limit threshold, the transaction can be processed based on the general credit limit.

[0059] In practical application scenarios, after the transaction request is processed and executed based on the user's general credit limit, since this transaction should originally be based on the unused credit limit under the transaction category, to ensure the security of using a shared credit limit after the transaction is executed using the general credit limit, in an optional implementation of this embodiment, after the transaction request is processed and executed based on the user's general credit limit, the credit limit allocation parameters are updated according to the transaction amount, transaction device type, user's browsing behavior data in the credit service, and / or asset type. Specifically, the following operations may also be performed: The parameter change coefficient is calculated based on the transaction amount and transaction device type of the transaction request, and the parameter correction value is calculated based on the user's browsing behavior data in the credit service and the asset type. The allocation parameters are updated based on the parameter change coefficient, parameter correction value, and quota allocation parameters to obtain the updated quota allocation parameters.

[0060] Among them, the parameter change coefficient refers to the change coefficient for changing the quota allocation parameters under the transaction category; the transaction device type refers to the device type of the merchant's equipment used by the merchant during the transaction process, including handheld type, desktop type and / or floor-standing type; the parameter correction value refers to the correction value for correcting the quota allocation parameters.

[0061] Specifically, transaction amount and transaction device type can be numerically mapped in the first numerical range, and a parameter change coefficient can be calculated based on the mapped values. User browsing behavior data and asset type in credit services can be numerically mapped in the second numerical range, and a parameter correction value can be calculated based on the mapped values. The ratio of the parameter change coefficient to the credit limit allocation parameter is calculated, and the sum of the ratio and the parameter correction value is used as the updated credit limit allocation parameter. The first and second numerical ranges can be the same or different. The critical values ​​at the same position in the second and first numerical ranges can be the same or different. The critical value of the second numerical range can be greater than the critical value at the same position in the first numerical range. For example, the first numerical range is (0, 0.5], and the second numerical range is (0.5, 1]. Both the parameter change coefficient and the parameter correction value can be values ​​between (0, 1).

[0062] It should be noted that the above optional implementation method can be replaced by calculating the parameter change coefficient based on the transaction amount and / or transaction device type of the transaction request, and / or calculating the parameter correction value based on the user's browsing behavior data in the credit service and / or asset type; updating the allocation parameters based on the parameter change coefficient and / or parameter correction value and the credit allocation parameters to obtain the updated credit allocation parameters.

[0063] In addition to the above-mentioned implementation method of processing transaction requests based on the user's general credit limit, based on the shared data model associated with the shared credit limit being dynamically mounted on the credit platform after detecting a transaction request, transaction processing can also be performed based on the credit allocation parameters under the transaction category of the target credit sub-account among the remaining credit sub-accounts included in the shared credit account; in the second optional implementation method provided in this embodiment, after performing transaction trigger detection and execution on the transaction request based on the credit limit corresponding to the credit limit disbursement record of the credit limit threshold and the transaction category, the following operations are also performed: If the detection fails, the target credit sub-account will be selected from the remaining credit sub-accounts of the shared credit account contained in the dynamically mounted shared data model. Transaction processing is performed based on the credit limit allocation parameters under the transaction category to which the target credit sub-account belongs.

[0064] Specifically, in the process of selecting target credit sub-accounts from the remaining credit sub-accounts of the shared credit account included in the dynamically mounted shared data model, the target credit sub-account can be selected from the remaining credit sub-accounts of the shared credit account based on the ranking of the credit limit allocation parameters, which must be in descending order. Alternatively, the unused credit limit can be calculated based on the credit limit disbursement records of the remaining credit sub-accounts, and then selected from the remaining credit sub-accounts. Credit sub-accounts whose unused credit limit ranks before a preset position are designated as target credit sub-accounts. During transaction processing based on the credit limit allocation parameters of the transaction category to which the target credit sub-account belongs, a credit limit disbursement threshold can be calculated based on the credit limit allocation parameters of the transaction category to which the target credit sub-account belongs and the shared credit limit. If the expected credit limit calculated based on the disbursement credit limit and transaction amount corresponding to the credit limit disbursement records of the target credit sub-account is less than or equal to the credit limit disbursement threshold, transaction processing is performed based on the unused credit limit corresponding to the target credit sub-account.

[0065] Based on this, after executing transaction processing according to the credit limit allocation parameters under the transaction category of the target credit sub-account, in order to improve the flexibility of updating the shared credit limit and ensure that the shared credit limit continuously meets the actual needs and behavioral habits of users, in an optional implementation of this embodiment, after executing transaction processing according to the credit limit allocation parameters under the transaction category of the target credit sub-account, if the number of transactions and / or transaction amount of transactions based on the credit limit allocation parameters under the transaction categories of the remaining credit sub-accounts meet the credit limit change conditions, the number of transactions, transaction amount, user browsing behavior data in the credit service, and / or asset type are input into the credit limit prediction model to predict the credit limit, obtain the predicted credit limit, and update the shared credit limit. Specifically, the following operations can be performed: Check whether the number of transactions and / or transaction amount based on the credit limit allocation parameters under the transaction category to which the remaining credit sub-account belongs meet the conditions for credit limit change; If the conditions are met, the number of transactions and / or transaction amount, along with the user's browsing behavior data in the credit service and asset type, are input into the credit limit prediction model to predict the credit limit, obtain the predicted credit limit, and update the shared credit limit.

[0066] The conditions for changing the credit limit can be that the number of transactions exceeds the threshold and / or the transaction amount exceeds the preset transaction amount.

[0067] In addition to the two transaction processing methods provided above for cases where transaction trigger detection fails, the third optional implementation of this embodiment, after performing transaction trigger detection on the transaction request based on the credit limit corresponding to the credit limit disbursement record based on the credit limit threshold and transaction type, also performs the following operations: If the detection fails, the transaction request will be processed according to the transaction method corresponding to the user's transaction participation indicator under the transaction category.

[0068] Among them, transaction participation metrics may include the number of transactions and / or the number of failed transactions by users through credit payment channels and / or under transaction categories. Transaction participation metrics may also be the percentage of failed transactions.

[0069] Specifically, if the transaction participation index is greater than the preset index threshold, the transaction can be processed based on the user's resource account. If the transaction participation index is less than or equal to the preset index threshold, the general credit limit threshold can be calculated based on the credit limit allocation parameters and the user's general credit limit. If the transaction amount meets the general credit limit threshold, the transaction can be processed based on the general credit limit.

[0070] Based on this, in an optional implementation of this embodiment, the following operations are performed during the transaction processing of the transaction request: The general credit limit threshold is calculated based on the credit limit allocation parameters and the user's general credit limit. If the transaction amount meets the general credit limit threshold, the transaction is processed based on the general credit limit; or, the transaction is processed based on the user's resource account.

[0071] In practical applications, the transaction category may be a newly added transaction category for credit payment channels. The credit limit allocation parameters for this transaction category may be relatively low to ensure the security of the credit payment channel within this category. If the usage duration of the credit payment channel in this transaction category exceeds a certain threshold, the demand for this transaction category may gradually increase. Therefore, changing the credit limit allocation parameters for the credit payment channel in this transaction category can better meet the actual usage needs of users. In an optional implementation of this embodiment, transaction anomaly detection is performed on the user transaction data of the credit payment channel within the transaction category to obtain transaction anomaly indicators. If the transaction anomaly indicators meet the conditions for credit limit change, the credit limit allocation parameters for the transaction category are changed. This can be achieved in the following way: Obtain user transaction data under transaction categories for credit payment channels; Transaction anomaly detection is performed on user transaction data to obtain transaction anomaly indicators. If the transaction anomaly indicators meet the conditions for quota change, the quota allocation parameters for the transaction category are changed.

[0072] User transaction data can be batch user transaction data under a transaction category within a credit payment channel, i.e., batch user transaction data. For example, user transaction data includes transaction success rate, transaction amount, and / or transaction time. Transaction anomaly indicators refer to indicators that characterize the degree of anomaly in transactions.

[0073] Specifically, it can acquire batch user transaction data for credit payment channels under transaction categories, calculate transaction anomaly indicators for credit payment channels under transaction categories based on batch user transaction data, and if the transaction anomaly indicator is less than the preset indicator, increase the credit limit allocation ratio for credit payment channels under transaction categories. If the transaction anomaly indicator is greater than or equal to the preset indicator, no action is taken, the credit limit allocation ratio for credit payment channels under transaction categories is decreased, or the transaction category is removed from the set of transaction categories sharing credit limits. In this way, the credit limit allocation ratio can be adjusted to flexibly fit the service scenario and meet the diverse needs of users.

[0074] As mentioned above, each transaction category has its own shared credit limit usage records. These records can be stored in the corresponding credit sub-accounts for each transaction category. These records may include the credit limit used, the time and / or the location of use, and the account statement for each sub-account. Each sub-account's account statement can be a usage item for each transaction under the corresponding transaction category based on a credit payment channel. This usage item may include the sub-account's account identifier, the transaction amount, the sub-account's account status, the transaction time, and / or any unused credit limit recorded by the sub-account before the transaction. In this case, each sub-account may record only one credit limit used and one or more account statements. Alternatively, each sub-account's account statement may not be recorded within the sub-account itself; at least one account statement for each sub-account can be associated with that sub-account through its account identifier. Shared credit limits for each transaction category can be recorded in a shared credit account. If the shared credit limit is the initial credit limit, which can be the credit limit granted to the user after opening a credit payment channel under each transaction category, then the shared credit account can be a shared credit account for multiple users with the same shared credit limit, and the shared credit account can record the shared credit limit. If the shared credit limit is not the initial credit limit, the shared credit account can be a credit account opened individually for the user, and this shared credit account can record the user's shared credit limit for each transaction category under the credit payment channel.

[0075] In addition to recording the shared credit limit, the shared credit account can also record the account identifier and / or account status. The shared credit account can also be associated with account transaction records, which may include change information on changes to the shared credit limit of the shared credit account. The change information may include the account identifier, the changed limit, the account status, the time of the limit change, and / or the shared credit limit before the limit change. The changed limit may be an increase or a decrease. A corresponding credit account can be set up for each credit payment channel, and this credit account can record the account identifier, the channel identifier of the credit payment channel, and / or the account status of the credit account.

[0076] It should be noted that the above-mentioned operation of detecting transaction triggers for transaction requests based on the credit limit corresponding to the credit limit usage record based on the credit limit threshold and transaction type, and processing the transaction after the detection is passed, can be replaced by detecting transaction triggers for transaction requests based on the credit limit corresponding to the credit limit usage record based on the credit limit threshold and / or transaction type, or it can be replaced by detecting transaction triggers for transaction requests based on the credit limit threshold and / or transaction type, and forming a new implementation method with other processing steps provided in this embodiment.

[0077] It should also be noted that the user data obtained by this invention, such as browsing behavior data and asset types, is authorized by the user and does not involve user privacy.

[0078] It should be added that each optional implementation method and each feasible execution method in steps S201 to S204 provided in this embodiment can be executed independently as needed, or they can be combined and referenced with each other. At the same time, each specific execution step in each optional implementation method or each feasible execution method can also be executed independently or combined as needed. The execution conditions of "if" or "under what circumstances" involved in each step or operation can be directly deleted, and subsequent operations can be executed. This embodiment does not make specific limitations on this.

[0079] It should also be added that, depending on the actual application scenario, step S201 and any of the subsequent steps S202 to S204 can be deleted, or any feature in any step can be deleted. For example, the user in step S201 can be deleted, and the execution order of steps S201 to S204 can also be arbitrary.

[0080] The following description uses the application of a transaction processing method provided in this embodiment in a credit payment scenario as an example to further illustrate the transaction processing method provided in this embodiment. (See also...) Figure 3 The transaction processing method applied to credit payment scenarios includes the following steps.

[0081] Step S301: Obtain the transaction category by identifying the transaction category based on the transaction request submitted by the user through the credit payment channel.

[0082] Step S302: Detect whether the transaction category is in the set of transaction categories with shared credit limits; Optionally, transactions within each transaction category in the transaction category set are based on a shared credit limit, and each transaction category has its own shared credit limit usage records.

[0083] If not, no action needs to be taken. If so, proceed with steps S303 to S307 below.

[0084] Step S303: Determine the transaction mode of the transaction request, and based on the transaction category and the transaction mode of the transaction request, query the credit limit allocation configuration of the credit payment channel under the transaction category.

[0085] Step S304: Read the credit allocation ratio from the credit allocation configuration, and calculate the credit threshold for the transaction category based on the credit allocation ratio and the shared credit limit.

[0086] Step S305: Based on the credit limit corresponding to the credit limit disbursement record of the credit limit threshold and transaction type, perform transaction trigger detection on the transaction request.

[0087] Step S306: After the transaction trigger detection passes, calculate the global expected spending limit based on the transaction amount carried in the transaction request and the spending credit limit corresponding to the spending record of each transaction category.

[0088] Step S307: Detect the transaction relationship between the global expected spending limit and the shared credit limit. If the detected transaction relationship is a participating transaction relationship, process the transaction based on the shared credit limit.

[0089] It should be noted that any one or more of steps S301 to S307 can be replaced by the corresponding technical means provided in steps S201 to S204 as needed for implementation and deployment. Any one or more of steps S301 to S307 can also be combined into a new implementation method as needed for implementation and deployment. Furthermore, any one or more of steps S301 to S307 can also be combined with one or more of the steps provided in steps S201 to S204 to form a new implementation method, or combined with one or more of the optional implementation methods provided in steps S201 to S204 to form a new implementation method, as needed for actual deployment. These will not be elaborated on here.

[0090] An embodiment of a transaction processing device provided by the present invention is as follows: In the above embodiments, a transaction processing method is provided, and correspondingly, a transaction processing apparatus is also provided, which will be described below with reference to the accompanying drawings.

[0091] Reference Figure 4 The diagram illustrates an embodiment of a transaction processing apparatus provided in this embodiment.

[0092] Since the apparatus embodiments correspond to the method embodiments, the descriptions are relatively simple. For relevant parts, please refer to the corresponding descriptions of the method embodiments provided above. The apparatus embodiments described below are merely illustrative.

[0093] This embodiment provides a transaction processing apparatus, including: The category recognition module 401 is configured to identify the transaction category based on the transaction request submitted by the user to obtain the transaction category; The detection module 402 is configured to detect whether the transaction category is in a set of transaction categories with a shared credit limit; transactions under each transaction category in the set of transaction categories are based on the shared credit limit, and each transaction category has its own credit limit disbursement record for the shared credit limit; If so, the parameter query module 403 is run. The parameter query module 403 is configured to query the quota allocation parameters under the transaction category and calculate the quota threshold of the transaction category based on the quota allocation parameters and the shared credit quota. The trigger detection module 404 is configured to perform transaction trigger detection on the transaction request based on the credit limit and the credit limit corresponding to the credit limit withdrawal record of the transaction category, and to process the transaction after the detection is passed.

[0094] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of the present invention, the functions of each module or unit can be implemented in one or more software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0095] An embodiment of a transaction processing device provided by the present invention is as follows: Corresponding to the transaction processing method described above, based on the same technical concept, one or more embodiments of the present invention also provide a transaction processing device for executing the transaction processing method provided above. Figure 5 This is a schematic diagram of the structure of a transaction processing device provided in one or more embodiments of the present invention.

[0096] This embodiment provides a transaction processing device, including: like Figure 5As shown, device 500 mainly consists of a communication interface 501, a user interface 502, a processor 503, and a data storage 504. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 505. The communication interface 501 enables device 500 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 501 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 501 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 501 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 501 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide-area wireless interfaces. The user interface 502 includes receiving user input and providing output to the user. Therefore, user interface 502 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 502 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 502 may include software, circuitry, or other forms of logic capable of transmitting and receiving data from external user input / output devices. Additionally or alternatively, device 500 may support remote access from other devices via communication interface 501 or another physical interface (not shown). User interface 502 may be configured to receive user input, the position and movement of which may be indicated by indicators or cursors described herein. User interface 502 may also be configured as a display device for rendering or displaying text fragments.

[0097] Processor 503 may include one or more general-purpose processors and / or dedicated processors. Data storage 504 may include one or more volatile and / or non-volatile storage components, and may be integrated wholly or partially with processor 503. Data storage 504 may include removable and non-removable components.

[0098] Processor 503 is capable of executing program instructions 509 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 504 to perform the various functions described herein. Data storage 504 may contain a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 500, enable device 500 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Execution of program instructions 509 by processor 503 may result in processor 503 using data 506. For example, program instructions 509 may include an operating system 511 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 500 and one or more application programs 510 (e.g., a browser, social application, or game application). Similarly, data 506 may contain operating system data 508 and application data 507. Operating system data 508 is primarily accessible to operating system 511, while application data 507 is primarily accessible to one or more application programs 510. Application data 507 may reside in a file system visible or hidden from the user of device 500. Application 510 can communicate with operating system 511 through one or more application programming interfaces (APIs). These APIs facilitate application 510 in reading and / or writing application data 507, transmitting or receiving information via communication interface 501, and receiving or displaying information on user interface 502. In some terms, application 510 may be simply referred to as "app". Furthermore, application 510 can be downloaded to device 500 through one or more online app stores or app markets. However, applications can also be installed on device 500 in other ways, such as through a web browser or a physical interface on device 500 (e.g., a USB port).

[0099] In one specific embodiment, the transaction processing device includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the transaction processing device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following: The transaction category is obtained by identifying the transaction category based on the transaction request submitted by the user; Detect whether the transaction category is in the transaction category set with shared credit limit; transactions under each transaction category in the transaction category set are based on the shared credit limit, and each transaction category has its own credit limit disbursement record for the shared credit limit; If so, query the credit allocation parameters under the transaction category, and calculate the credit threshold for the transaction category based on the credit allocation parameters and the shared credit limit; Based on the credit limit threshold and the credit limit corresponding to the credit limit expenditure record of the transaction category, the transaction request is subjected to transaction trigger detection, and the transaction is processed after the detection is passed.

[0100] An embodiment of a computer-readable storage medium provided by the present invention is as follows: Corresponding to the transaction processing method described above, based on the same technical concept, one or more embodiments of the present invention also provide a computer-readable storage medium.

[0101] The computer-readable storage medium provided in this embodiment is used to store computer-executable instructions, which, when executed, perform the following steps: The transaction category is obtained by identifying the transaction category based on the transaction request submitted by the user; Detect whether the transaction category is in the transaction category set with shared credit limit; transactions under each transaction category in the transaction category set are based on the shared credit limit, and each transaction category has its own credit limit disbursement record for the shared credit limit; If so, query the credit allocation parameters under the transaction category, and calculate the credit threshold for the transaction category based on the credit allocation parameters and the shared credit limit; Based on the credit limit threshold and the credit limit corresponding to the credit limit expenditure record of the transaction category, the transaction request is subjected to transaction trigger detection, and the transaction is processed after the detection is passed.

[0102] It should be noted that the embodiments of a computer-readable storage medium in this invention and the embodiments of a transaction processing method in this invention are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and repeated details will not be repeated.

[0103] An embodiment of a computer program product provided by this invention is as follows: Corresponding to the transaction processing method described above, based on the same technical concept, one or more embodiments of the present invention also provide a computer program product.

[0104] A computer program product includes a computer program / instructions that, when executed by a processor, perform the following steps: The transaction category is obtained by identifying the transaction category based on the transaction request submitted by the user; Detect whether the transaction category is in the transaction category set with shared credit limit; transactions under each transaction category in the transaction category set are based on the shared credit limit, and each transaction category has its own credit limit disbursement record for the shared credit limit; If so, query the credit allocation parameters under the transaction category, and calculate the credit threshold for the transaction category based on the credit allocation parameters and the shared credit limit; Based on the credit limit threshold and the credit limit corresponding to the credit limit expenditure record of the transaction category, the transaction request is subjected to transaction trigger detection, and the transaction is processed after the detection is passed.

[0105] It should be noted that the embodiment of a computer program product in this invention and the embodiment of a transaction processing method in this invention are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0106] The various embodiments in this invention are described in a progressive manner. For the same or similar parts between the various embodiments, please refer to each other. Each embodiment focuses on describing the differences from other embodiments. For example, the device embodiment, equipment embodiment, and computer-readable storage medium embodiment are all similar to the method embodiment, so the description is relatively simple. For reading the relevant content of the device embodiment, equipment embodiment, and computer-readable storage medium embodiment, please refer to the description of the method embodiment.

[0107] While one or more embodiments of the present invention provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is only one of many possible execution orders and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims.

[0108] This invention uses specific terms to describe embodiments of the invention. For example, "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic related to at least one embodiment of the invention. Therefore, it should be emphasized and noted that "an embodiment," "one embodiment," or "an alternative embodiment" mentioned twice or more in different locations in this invention do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described in this invention, as well as the features of those different embodiments or examples, without contradiction.

[0109] The foregoing has described specific embodiments of the invention. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0110] In the 1930s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many improvements to the methodology today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that an improvement to the methodology cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0111] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0112] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0113] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, in implementing the embodiments of the present invention, the functions of each unit can be implemented in one or more software and / or hardware.

[0114] Those skilled in the art will understand that one or more embodiments of the present invention can be provided as a method, system, or computer program product. Therefore, one or more embodiments of the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0115] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable test processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable test processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0116] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable test processing equipment to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0117] These computer program instructions can also be loaded onto a computer or other programmable test processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0118] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0119] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0120] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0121] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of features includes not only those features but also other features not expressly listed, or features inherent to such process, method, article, or apparatus. Without further limitations, a feature defined by the phrase "comprising one..." does not exclude the presence of other identical features in the process, method, article, or apparatus that includes said feature.

[0122] One or more embodiments of the present invention can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. One or more embodiments of the present invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0123] The various embodiments in this invention are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0124] The above description is merely an embodiment of this document and is not intended to limit the scope of this document. Various modifications and variations can be made to this document by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this document should be included within the scope of the claims of this document.

Claims

1. A transaction processing method, characterized in that, The method includes: The transaction category is obtained by identifying the transaction category based on the submitted transaction request; Detect whether the transaction category belongs to the set of transaction categories sharing a credit limit; If so, calculate the credit limit threshold for the transaction category based on the credit allocation parameters under the transaction category and the shared credit limit; Based on the credit limit or the credit limit corresponding to the transaction category, the transaction request is subjected to transaction trigger detection to obtain the detection result of transaction trigger detection.

2. The transaction processing method according to claim 1, characterized in that, After the step of performing transaction trigger detection on the transaction request based on the credit limit threshold or the credit limit corresponding to the transaction category to obtain the detection result of the transaction trigger detection is executed, the method further includes: If the detection result is that the detection fails, the transaction request will be processed based on the user's general credit limit; The general credit limit is recorded through a general credit account included in the general data model, and the shared credit limit is recorded through a shared credit account included in the shared data model; the credit limit disbursement records for each transaction category are recorded through the credit sub-accounts of the shared credit account.

3. The transaction processing method according to claim 2, characterized in that, The credit sub-account is dynamically attached to the credit platform after the step of detecting whether the transaction category is in the set of transaction categories with shared credit limits is executed, and before the step of calculating the credit limit threshold of the transaction category based on the credit limit allocation parameters under the transaction category and the shared credit limit is executed. The credit sub-account is switched based on the general credit account before the transaction request is processed and executed based on the user's general credit limit.

4. The transaction processing method according to claim 2, characterized in that, After the transaction processing operation based on the user's general credit limit is executed, it also includes: The parameter change coefficient is calculated based on the transaction amount and transaction device type of the transaction request, and the parameter correction value is calculated based on the user's browsing behavior data in the credit service and the asset type. The allocation parameters are updated based on the parameter change coefficient, the parameter correction value, and the quota allocation parameters to obtain the updated quota allocation parameters.

5. The transaction processing method according to claim 1, characterized in that, The shared data model associated with the shared credit limit is dynamically mounted on the credit platform after the transaction request is detected; Accordingly, after the step of performing transaction trigger detection on the transaction request based on the limit threshold or the credit limit corresponding to the transaction category to obtain the detection result of the transaction trigger detection is executed, the method further includes: If the detection result is that the detection fails, the target credit sub-account is selected from the remaining credit sub-accounts of the shared credit account included in the dynamically mounted shared data model; Transaction processing is performed based on the credit limit allocation parameters under the transaction category to which the target credit sub-account belongs.

6. The transaction processing method according to claim 5, characterized in that, After the transaction processing operation is executed according to the credit limit allocation parameters under the transaction category of the target credit sub-account, the process further includes: Check whether the number of transactions and / or transaction amount based on the credit limit allocation parameters under the transaction category to which the remaining credit sub-account belongs meet the conditions for credit limit change; If the conditions are met, the number of transactions and / or the transaction amount, along with the user's browsing behavior data in the credit service and asset type, are input into the credit limit prediction model to predict the credit limit, obtain the predicted credit limit, and update the shared credit limit.

7. The transaction processing method according to claim 1, characterized in that, The shared credit limit is determined in the following manner: Based on the transaction category and user data in the transaction category set, a credit limit decision is made for each transaction category to obtain the user credit limit for each transaction category; The shared credit limit is determined based on the user credit limit for each transaction category.

8. The transaction processing method according to claim 7, characterized in that, Each of the aforementioned transaction categories is obtained through any of the following methods: The transaction categories are determined based on the user's configuration instructions for the shared credit limit. Based on the user's asset type, the transaction categories are obtained by category matching among multiple candidate transaction categories; The system obtains multiple intermediate transaction categories submitted by the user for the shared credit limit, and determines each transaction category among the multiple intermediate transaction categories based on the credit limit unit in which the shared credit limit is located.

9. The transaction processing method according to claim 8, characterized in that, The step of determining each transaction category among the multiple intermediate transaction categories based on the credit limit unit where the shared credit limit is located includes: Based on the credit limit unit, the user's historical transactions under each intermediate transaction category are clustered; The intermediate transaction categories are defined as those whose historical transaction counts are greater than those of the remaining clusters.

10. The transaction processing method according to claim 1, characterized in that, The quota allocation parameters are obtained by querying when the transaction category is detected to be in the set of transaction categories. The quota allocation parameters are obtained by querying them in the following way: Determine the transaction mode of the transaction request, and query the quota allocation configuration under the transaction category based on the transaction category and the transaction mode; Read the quota allocation parameters from the quota allocation configuration; The transaction modes include: a first transaction mode where transactions are conducted through a transaction service, a second transaction mode where transactions are conducted based on a near-field communication connection, or a third transaction mode where a user terminal scans a merchant's payment identifier to conduct a transaction.

11. The transaction processing method according to claim 1, characterized in that, After the step of performing transaction trigger detection on the transaction request based on the credit limit threshold or the credit limit corresponding to the transaction category to obtain the detection result of the transaction trigger detection is executed, the method further includes: The global expected spending limit is calculated based on the transaction amount carried in the transaction request and the spending credit limit corresponding to the spending record of each transaction category in the transaction category set. Perform transaction relationship analysis on the global expected spending limit and the shared credit limit. If the analysis result indicates a transaction relationship, proceed with the transaction processing.

12. The transaction processing method according to claim 1, characterized in that, The operation of calculating the credit limit threshold for the transaction category based on the credit limit allocation parameters under the transaction category and the shared credit limit is performed when the credit limit allocation parameters are less than a preset parameter threshold.

13. The transaction processing method according to claim 12, characterized in that, If the quota allocation parameter is greater than or equal to the preset parameter threshold, the following operation is performed: The total spending limit is calculated based on the transaction amount and the spending limit corresponding to the spending record of each transaction category in the set of transaction categories. If the total expenditure limit matches the shared credit limit, the transaction request is processed based on the shared credit limit.

14. The transaction processing method according to claim 1, characterized in that, After the step of performing transaction trigger detection on the transaction request based on the credit limit threshold or the credit limit corresponding to the transaction category to obtain the detection result of the transaction trigger detection is executed, the method further includes: If the detection result is that the detection fails, the transaction request will be processed according to the transaction method corresponding to the user's transaction participation index under the transaction category.

15. The transaction processing method according to claim 14, characterized in that, The transaction processing of the transaction request includes: A general credit limit threshold is calculated based on the credit limit allocation parameters and the user's general credit limit. If the transaction amount meets the general credit limit threshold, the transaction is processed based on the general credit limit; or, the transaction is processed based on the user's resource account.

16. A transaction processing apparatus, characterized in that, The device includes: The category recognition module is configured to identify the transaction category based on the submitted transaction request; The detection module is configured to detect whether the transaction category belongs to a set of transaction categories sharing a credit limit; If so, run the parameter query module, which is configured to calculate the limit threshold of the transaction category based on the limit allocation parameters under the transaction category and the shared credit limit; The trigger detection module is configured to perform transaction trigger detection on the transaction request based on the limit threshold or the credit limit corresponding to the transaction category, and obtain the detection result of the transaction trigger detection.

17. A transaction processing device, characterized in that, The device includes: A processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to: The transaction category is obtained by identifying the transaction category based on the submitted transaction request; Detect whether the transaction category belongs to the set of transaction categories sharing a credit limit; If so, calculate the credit limit threshold for the transaction category based on the credit allocation parameters under the transaction category and the shared credit limit; Based on the credit limit or the credit limit corresponding to the transaction category, the transaction request is subjected to transaction trigger detection to obtain the detection result of transaction trigger detection.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store computer-executable instructions that, when executed, implement the steps of the method of claim 1.