Transaction processing method of hotspot account and related equipment

Abstract

The invention discloses a transaction processing method of a hotspot account and related equipment, and relates to the field of transaction settlement. The method is applied to a transaction processing server of a transaction processing system of a target transaction account, under the condition that it is detected that the current moment meets a preset triggering condition, a target fragment processed by the transaction processing server this time is determined from a database, and to-be-processed transaction details of a hotspot account are stored in the target fragment; the transaction identification number of the to-be-processed transaction detail is in a preset number range corresponding to the target fragment; obtaining transaction details to be processed from the target fragment in batches; and according to the to-be-processed transaction details obtained in batches, the balances of the target transaction account and the hotspot account are updated. According to the invention, the load pressure of the transaction platform is reduced, and the security and accuracy of the balance updating of the hotspot account can be ensured.

Description

Technical Field

[0001] This application relates to the field of transaction settlement technology, and in particular to a transaction processing method and related equipment for hot accounts. Background Technology

[0002] In trading platforms, "hot accounts" refer to accounts that exhibit extremely high trading frequency, large trading amounts, and numerous transactions within a specific timeframe, or that have a significant impact on the trading platform's performance, risk control, clearing, and settlement. Due to their high concurrency and large trading volumes, the trading activities of these hot accounts can place significant load pressure on the trading platform.

[0003] To alleviate the load on trading platforms, existing technologies propose a divide-and-conquer approach. This involves distributing the balance of a primary hot account across multiple caches (shadow accounts). When a transaction request for the hot account occurs, the balance in the caches (shadow accounts) is processed first. After a certain period, the balances from all caches are aggregated, and the primary hot account's balance is updated. Based on this, caching replaces updating the primary hot account's balance in the database, thereby reducing the update frequency of the primary hot account per unit time and alleviating the load on the trading platform.

[0004] However, if a deduction is made for a particular shadow account and the shadow account has insufficient balance, multiple shadow accounts need to be linked to make the deduction. At this time, it is necessary to ensure that the data between the shadow accounts are synchronized. Otherwise, due to the delay between accounts, the shadow accounts may be deducted repeatedly, resulting in inaccurate balances after the transaction.

[0005] Therefore, there is an urgent need for a method to handle transactions of popular accounts, in order to alleviate the load pressure on trading platforms while improving the accuracy of account adjustments for popular accounts during transactions. Summary of the Invention

[0006] In view of the above problems, this application provides a method and related equipment for processing transactions of frequently used accounts, so as to alleviate the load pressure on the trading platform while improving the accuracy of account adjustments for frequently used accounts during transactions. The specific solution is as follows:

[0007] The first aspect of this application provides a transaction processing method for hot accounts, applied to a transaction processing server of a transaction processing system for a target transaction account. The transaction processing system for hot accounts further includes at least: a transaction acceptance server and a database, wherein the database includes multiple shards.

[0008] The transaction processing method for the aforementioned hot accounts includes:

[0009] If the preset triggering conditions are met at the current time, the target shard for the transaction processing server to process is determined from the database. The target shard stores the pending transaction details of hot accounts, and the transaction identifier number of the pending transaction details is within the preset number range corresponding to the target shard.

[0010] The transaction details to be processed are obtained in batches from the target shard;

[0011] Based on the batch-acquired transaction details to be processed, update the balances of the target transaction account and the hot account.

[0012] In one possible implementation, the process of determining the target shard for the current transaction processing server from the database includes:

[0013] Before the current time, obtain the total number of times all transaction processing servers in the transaction processing system of the hot account have triggered the preset trigger condition, and determine the corresponding number of times the transaction processing server triggers the current trigger at the current time;

[0014] Based on preset processing rules, the target shard corresponding to the current trigger count is determined. The preset processing rules are: shards are triggered sequentially according to the sorting of all shards in the database, and only one shard is processed each time.

[0015] In one possible implementation, the process of determining the target shard for the current transaction processing server from the database includes:

[0016] The target shard is selected from the preset designated shard corresponding to the transaction processing server by querying the database.

[0017] In one possible implementation, the process of obtaining the transaction details to be processed from the target shard in batches includes:

[0018] Read the total number of pending transaction details in the target shard;

[0019] When the total number is greater than zero, the transaction details to be processed in the target segment are obtained in batches according to the upper limit of the number of times they are obtained at one time, so as to obtain the transaction details to be processed corresponding to each batch, and the batch number of the corresponding batch is marked on the transaction details to be processed. The number of transaction details to be processed corresponding to each batch is less than or equal to the upper limit of the number of times they are obtained at one time.

[0020] In one possible implementation, updating the balances of the target transaction account and the hot account based on the batch-acquired transaction details to be processed includes:

[0021] Based on the transaction type corresponding to the transaction details to be processed, the transaction details to be processed for each batch are classified to obtain a set of outgoing transaction details to be processed and a set of incoming transaction details to be processed. The transaction type is either an outgoing transaction or an incoming transaction.

[0022] Based on the set of pending inflow details, a set of target outflow details for the target transaction account is generated; based on the set of target outflow details, the target transaction account is adjusted to obtain outflow details with successful adjustments; based on the outflow details with successful adjustments, the target transaction account and the hot account are adjusted to update the balances of the target transaction account and the hot account.

[0023] Based on the set of pending outgoing transaction details, a set of target incoming transaction details for the target transaction account is generated; based on the set of target incoming transaction details, the target transaction account is adjusted to obtain incoming transaction details with successful adjustments; based on the incoming transaction details with successful adjustments, the balances of the target transaction account and the hot account are adjusted, and the balances of the target transaction account and the hot account are updated.

[0024] A second aspect of this application provides a transaction processing system for hot accounts, comprising: at least one transaction acceptance server, a database, and at least one transaction processing server, wherein the database comprises multiple shards;

[0025] The transaction processing server obtains the pending transaction details of the hot accounts and stores the pending transaction details in the database.

[0026] The database stores the transaction details to be processed into a shard corresponding to a preset number range containing transaction identifier numbers;

[0027] The transaction processing server processes the pending transaction details in the segment according to the transaction processing method for hot accounts in the first aspect or any implementation thereof, so as to update the balance of the target transaction account and the hot account.

[0028] In one possible implementation, the process by which the transaction processing server obtains the pending transaction details of hot accounts includes:

[0029] Retrieve pending transaction orders;

[0030] Based on the pending transaction orders, determine the upstream and downstream accounts of the target transaction account. The upstream account is the account that transfers funds to the target transaction account, and the downstream account is the account that receives funds transferred out of the target transaction account.

[0031] Determine whether the upstream account and the downstream account are hot accounts;

[0032] If the upstream account is the hot account, then generate pending transaction details based on the pending transaction orders, and mark the transaction type of the pending transaction details as incoming transactions;

[0033] If the upstream account is not the hot account and the downstream account is the hot account, then a pending transaction detail is generated based on the pending transaction order, and the transaction type of the pending transaction detail is marked as an outgoing transaction.

[0034] If neither the upstream account nor the downstream account is a hot account, then the accounts of the upstream account and the downstream account are adjusted according to the pending transaction orders.

[0035] A third aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the transaction processing method for hot accounts described in the first aspect or any implementation thereof.

[0036] A fourth aspect of this application provides an electronic device, including at least one processor and a memory connected to the processor, wherein:

[0037] The memory is used to store computer programs;

[0038] The processor is used to execute the computer program so that the electronic device can implement the transaction processing method for hot accounts as described in the first aspect or any implementation thereof.

[0039] The fifth aspect of this application provides a computer storage medium carrying one or more computer programs, which, when executed by an electronic device, enable the electronic device to implement the transaction processing method for hot accounts described in the first aspect or any implementation thereof.

[0040] The transaction processing method for hot accounts provided in this application caches the pending transaction details of hot accounts in database shards, and the transaction processing server periodically performs batch processing on the cached pending transaction details in the shards. This application reduces the frequency of updates to hot account balances due to a large number of transactions in a short period by caching transaction details in the database. Simultaneously, it aggregates and updates the balances of hot accounts all at once through batch processing. Furthermore, the use of sharded storage and sharded processing avoids the situation where the transaction server centrally processes a large number of transaction details stored in the database, thus reducing the load pressure on the trading platform.

[0041] Furthermore, since this application caches the transaction details of frequently accessed accounts, rather than their balances, individual transactions do not directly update the balances. Instead, the balances are updated only after the details are aggregated. This avoids the inaccurate balance updates caused by balance splitting. Based on this, even if transaction details fail to be cached or experience caching delays that prevent timely synchronization to the database shards, the transaction processing server, when batch aggregating the transaction details, distinguishes processed transaction details by labeling the acquired pending transaction details. The aforementioned cached or delayed transaction details are filtered out of the database and will not affect the balances of frequently accessed accounts, ensuring the security and accuracy of frequently accessed account balance updates. Attached Figure Description

[0042] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0043] Figure 1 An example diagram of an application scenario provided in this application embodiment;

[0044] Figure 2 A schematic diagram of the structure of a transaction processing system for hot accounts provided in this application embodiment;

[0045] Figure 3 A schematic diagram illustrating the process of obtaining pending transaction details of hot accounts provided in an embodiment of this application;

[0046] Figure 4 A flowchart illustrating a transaction processing method for a hot account provided in this application embodiment;

[0047] Figure 5 An example diagram illustrating the association between sharding and a transaction processing server provided in an embodiment of this application;

[0048] Figure 6 A flowchart illustrating a batch processing of pending transaction details provided in this application embodiment;

[0049] Figure 7 Example diagram of another application scenario provided by the embodiments of this application;

[0050] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0051] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0052] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0053] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0054] This application can be applied to the financial field of payment and settlement. The following section takes the transaction settlement of popular accounts as an example to introduce several application scenarios that have been implemented in products.

[0055] First, we introduce one possible application scenario for this application. (Refer to...) Figure 1 This application provides an example of an application scenario in the e-commerce field. To protect the rights and interests of both buyers and sellers, payment platforms often use transit accounts to store funds in transit. Taking a shopping process as an example, when a user makes a purchase on an e-commerce platform and generates a transaction order, the user is the account that actively transfers funds in the transaction (i.e., the outgoing account), while the merchant on the e-commerce platform is the account that passively receives funds in the transaction (i.e., the incoming account). Based on this, after a user makes a purchase and pays through a third-party payment platform on an e-commerce platform, the funds first enter the transit account of the third-party payment platform. Only after the user confirms receipt will the funds be transferred from the transit account to the merchant's account. With various shopping festivals, live-streaming e-commerce, and other promotional activities, the transaction volume of third-party payment platforms surges in a short period of time. This causes the transit account of the payment platform to become a hot account (or a dual-frequency hot account). The frequent inflows and outflows of funds into the transit account greatly increase the load on the payment platform, which may lead to platform paralysis, transaction instability, and other problems.

[0056] If we follow the divide-and-conquer approach described in the background section, the transit account is split into multiple sub-accounts, each used to store funds in transit and process incoming transactions. However, since the transit account is only for temporarily storing funds in transit, after the user confirms receipt, the sub-account still needs to credit each fund in transit to the merchant. Although the transit account is split, the payment platform's inflow and outflow frequency still follows the user and merchant's behavior and is not reduced. Furthermore, splitting the transit account into multiple sub-accounts introduces the risk of high concurrency alongside high-frequency inflows and outflows, and the load on the payment platform remains unchanged. Moreover, untimely synchronization between sub-accounts can lead to the same transaction being executed repeatedly, affecting the accuracy of transit account inflows and outflows.

[0057] To address the aforementioned problems, this application provides a method and related equipment for processing transactions of frequently accessed accounts. The method and related equipment for processing transactions of frequently accessed accounts according to this application will be described in detail below with reference to the accompanying drawings.

[0058] See Figure 2 This application provides a schematic diagram of a transaction processing system for hot accounts. The system may include at least one transaction acceptance server, a database, and at least one transaction processing server. The database includes multiple shards. The transaction acceptance server is used to obtain pending transaction details for hot accounts and store these details in the database. The database stores the pending transaction details in shards corresponding to a preset number range containing transaction identifiers. The transaction acceptance server is used to implement a transaction processing method for hot accounts, performing batch processing on the transaction details stored in the database shards. The transaction acceptance server and transaction processing server in the hot account transaction processing system may be, but are not limited to, computer systems or software programs with data processing capabilities, or cloud services provided to cloud-side servers.

[0059] It is understood that the transaction processing system for hot accounts can be deployed on a third-party payment platform or other financial transaction platform to process transactions between hot accounts received by the target transaction account. The target transaction account can be a high-frequency hot account, a low-frequency hot account, or a dual-frequency hot account. In this embodiment of the application, a dual-frequency hot account is used as the target transaction account as an example, such as a transition account, to illustrate this application.

[0060] This embodiment of the application utilizes a transaction acceptance server to receive transaction details from all parties, stores the transaction details of frequently accessed accounts in a database for aggregation, and then a transaction processing server performs batch processing on the transaction details stored in the database. This reduces the frequency of processing for frequently accessed accounts, mitigates high concurrency issues, and lowers the load on the payment platform. Furthermore, to avoid the transaction acceptance server centrally processing large amounts of transaction data in the database, this embodiment of the application stores a large number of transaction details in different shards, thereby reducing the amount of data processed in each batch and improving processing efficiency.

[0061] In this embodiment, the transaction processing server can be an online server capable of processing user requests in real time and providing online services, responsible for receiving transaction orders / transaction requests from clients. Optionally, the transaction processing server only accepts transaction orders sent by popular accounts, or it can accept transaction requests sent by any account. If the transaction processing server can accept transaction requests from any account, it determines whether the transaction order is from a popular account by identifying the account type of the client sending the order, or the account types of both the sending and receiving accounts in the transaction order, and then selects the corresponding transaction processing method for popular accounts to process the order.

[0062] In one possible implementation, the transaction processing server obtains the pending transaction details of hot accounts, including: obtaining pending transaction orders; determining the upstream and downstream accounts of the target transaction account based on the pending transaction orders, where the upstream account is the account transferring funds to the target transaction account and the downstream account is the account receiving funds transferred out of the target transaction account; determining whether the upstream and downstream accounts are hot accounts; if the upstream account is a hot account, generating pending transaction details based on the pending transaction orders and marking the transaction type of the pending transaction details as incoming transactions; if the upstream account is not a hot account and the downstream account is a hot account, generating pending transaction details based on the pending transaction orders and marking the transaction type of the pending transaction details as outgoing transactions; if neither the upstream nor the downstream account is a hot account, adjusting the accounts of the upstream and downstream accounts respectively based on the pending transaction orders.

[0063] Reference Figure 3This application provides a flowchart illustrating the process of obtaining pending transaction details for hot accounts, detailing how the transaction acceptance server obtains these details. The transaction acceptance server accepts pending transaction orders in real time. These orders record the transaction parties (outgoing and incoming accounts), the subject matter of the transaction (goods, services, assets, etc.), quantity, price, and other key terms, serving as the basis for transaction execution, settlement, and clearing. In this embodiment, upon receiving a transaction order, the transaction acceptance server first performs basic information verification, such as checking the order number, amount, and other numerical values ​​for compliance, and verifying the accuracy of the incoming and outgoing accounts, to ensure the accuracy of the transaction order and reduce security risks to the payment system.

[0064] Assuming the transaction order information verification results are compliant and pose no security risks, based on the fund flow, determine the upstream and downstream accounts for the target transaction account within the pending transaction orders. The upstream account is the account transferring funds to the target transaction account, i.e., the payer / outgoing party; the downstream account is the account receiving funds transferred out of the target transaction account, i.e., the receiver / receiving party. Figure 1 For example, in a transaction order, user 1 purchases goods from merchant 1. User 1 pays merchant 1 through a transit account. In the processing of this transaction order, the flow of funds is as follows: user 1 transfers funds into the transit account, and the transit account then transfers funds out to merchant 1. Therefore, in this transaction order, the outgoing account, i.e., user 1, is the upstream account of the transit account; the incoming account, i.e., merchant 1, is the downstream account of the transit account.

[0065] Furthermore, the account types of the upstream and downstream accounts identified in the transaction order are determined to identify transaction orders belonging to "hot accounts." Specifically, a list of hot accounts can be pre-configured statically in conjunction with the business model. By identifying whether the upstream and downstream accounts in the received transaction order are on this list, it can be determined whether the transaction details belong to a hot account. In another possible implementation, a Redis server or big data analytics tool can be deployed in the transaction processing system for the aforementioned hot accounts to count the account transactions of upstream and downstream accounts within a unit of time. Based on the number of transaction orders per account within a unit of time, hot accounts can be dynamically marked in real time.

[0066] In this embodiment, the system first identifies whether the upstream account of the target transaction account in the transaction order is a hot account. If so, the transaction order belongs to the pending transaction orders of the hot account. Transaction details are generated based on the transaction order, and the transaction type of the transaction details is marked as an incoming transaction. In this example, a TC tag can be used. If the upstream account of the target transaction account in the transaction order is not a hot account, the system then identifies whether the downstream account is a hot account. If so, the transaction order belongs to the pending transaction orders of the hot account. Transaction details are generated based on the transaction order, and the transaction type of the transaction details is marked as an outgoing transaction. In this example, a TD tag can be used.

[0067] It should be noted that the transaction type is used to characterize the fund transfer relationship between the target trading account and the hot account. When the hot account is an upstream account, and the hot account transfers funds to the target trading account, the transaction type for the target trading account is an incoming transaction. When the hot account is a downstream account, and the target trading account transfers funds out of the hot account, the transaction type for the target trading account is an outgoing transaction.

[0068] Furthermore, the pending transaction orders marked with the incoming transaction type (TC tag) or outgoing transaction type (TD tag) are stored in the database in the form of transaction details to realize the acceptance of transaction orders. Optionally, the transaction acceptance server can send feedback information of successful acceptance to the sender of the transaction order.

[0069] It is understandable that another possibility exists for transaction orders: the upstream and downstream accounts of the target transaction account in the transaction order are not hot accounts. For the target transaction account, even if the account balance is updated at the same time as the transaction is processed, there will be no problem of frequent account updates. Therefore, in this embodiment of the application, for the case where the upstream and downstream accounts of the target transaction account in the transaction order are not hot accounts, the transaction processing server can adjust the accounts of the upstream and downstream accounts based on the transaction transaction details. Regardless of whether the adjustment is successful or not, the adjustment result will be fed back to both the upstream and downstream accounts. In this embodiment of the application, for transaction orders with successful adjustments, their transaction details can be stored in the database for archiving, which is convenient for subsequent transaction traceability. It should be noted that the archived transaction orders with successful adjustments in the database are not the object of subsequent hot account transaction processing methods.

[0070] Based on this, the identified and marked transaction details to be processed are stored in database shards. Optionally, the transaction details to be processed are stored according to the order of the shards in the database, so that the transaction details to be processed are evenly distributed across the shards. For example, if four transaction details to be processed need to be entered into the database this time, Figure 1The database has N shards. The four pending transaction details are stored sequentially in shard 1, shard 2, shard 3, and shard 4. When the pending transaction details are added to the database again, they are stored sequentially starting from shard 5.

[0071] In another possible implementation, a corresponding preset number range is pre-assigned to each shard of the database. The transaction identifier number of the pending transaction details is identified within which preset number range. The shard corresponding to the preset number range containing the transaction identifier number is used as the shard for storing the pending transaction details. The transaction identifier number is a unique identifier for each transaction and can be an order number, transaction serial number, payment order number, transaction hash value, or a custom ID defined by the business system.

[0072] The following example illustrates the data entry process. Database administrators allocate data with different hash value ranges to different shards for storage. For instance, shard 1 corresponds to a hash value range of 0-1024, shard 2 corresponds to a hash value range of 1025-2048, and so on. The hash value of the transaction serial number in the pending transaction details is calculated; if it is 1000, then the pending transaction detail is stored in shard 1. It's understandable that transaction serial numbers, order numbers, and other transaction identifiers are usually ordered and incrementing. Both the hash value and the original serial number tend to be evenly distributed. Therefore, storing data based on the distribution range of these serial numbers ensures that the pending transaction details are evenly distributed across each database shard. This even distribution of transaction details in the database facilitates subsequent data processing based on the data characteristics of each shard. Furthermore, the linear growth of database storage capacity facilitates future expansion of the number of database shards, improving the scalability of the payment platform.

[0073] Furthermore, the transaction processing server processes the pending transaction details of hot accounts after they have been added to the database. This transaction processing server can be a batch processing server, responsible for batch processing the transaction data stored in the database. (See reference...) Figure 4 , Figure 4 A flowchart illustrating a transaction processing method for a hot account provided in this application embodiment is shown below. Figure 4 As shown in the embodiment of this application, a transaction processing method for a hot account may include steps S110 to S130, which are described in detail below.

[0074] Step S110: If the preset triggering conditions are met at the current time, determine the target shard to be processed by the transaction processing server in this transaction from the database.

[0075] The transaction processing server can initiate the processing of pending transaction details in the database shards according to a preset period. For example, the preset trigger condition is set as follows: when the time interval between the current moment and the moment when the transaction processing server last ended the processing of pending transaction details reaches a preset interval, the transaction processing server is triggered to process the pending transaction details in the database shards. Based on this, the transaction processing server realizes the periodic processing of transaction details. Optionally, the trigger condition for initiating the processing of transaction details may also include: the storage amount of pending transaction details received from a certain database shard reaches a preset storage limit, etc.

[0076] In this embodiment, when a preset trigger condition is detected at the current time, the transaction processing server initiates the processing flow for the transaction details to be processed. First, the target shard for this processing is determined. Optionally, a shard in the database that is not currently being processed is queried and selected as the target shard. If multiple shards are not currently being processed, one is randomly selected as the target shard. Alternatively, based on the attribute configuration of this transaction processing server, a shard in the database that this transaction processing server can process is queried and selected as a target shard. Note that a database shard can only be processed by one transaction processing server at a time.

[0077] In one possible implementation, the target shard for the current transaction processing server is determined from the database, including: obtaining the total number of times all transaction processing servers in the transaction processing system for hot accounts have triggered preset trigger conditions before the current time, and determining the corresponding number of triggers for the current transaction processing server; and determining the target shard corresponding to the number of triggers for the current time according to preset processing rules, wherein the preset processing rules are: triggering shards sequentially according to the sorting of all shards in the database, and triggering only one shard at a time.

[0078] The transaction processing system for hot accounts calculates the number of times the transaction processing flow is triggered across all transaction processing servers. For example, before the current moment, Figure 1 The three transaction processing servers triggered the transaction processing flow a total of 3 times. Based on this, it can be determined that the current trigger is 4 times. Optionally, refer to... Figure 1 In the transaction processing system for hot accounts, deploy a Redis server for counting, and count the number of times the transaction processing process is triggered by all transaction processing servers to obtain the current trigger count.

[0079] Based on the current trigger count (e.g., the 4th trigger), and according to the shard order in the database, the shard triggered in the 4th trigger is determined to be the target shard under the sequential triggering rule. For example, if the database contains 3 shards, namely shard 1, shard 2, and shard 3, and shard 1 is triggered the first time, shard 2 the second time, and so on, then shard 1 will be triggered in the 4th trigger.

[0080] In this example, the target shard can be determined sequentially each time. In another possible implementation, the target shard to be processed by the transaction processing server in this processing can be calculated by taking the remainder of the total number of shards for this trigger count. Refer to the following formula (1) to determine the calculation formula for the total number of shards for this trigger count.

[0081] (1)

[0082] Where a%b represents the result of taking the remainder of the current trigger count and the total number of shards, a represents the current trigger count, b represents the total number of shards in the database, and n represents the quotient of a and b.

[0083] Understandably, in the above modulo calculation, each time 'a' increments by 1, the resulting 'a%b' also increments by 1. This ensures that the next triggered shard is the shard following the one triggered in the previous step, i.e., shards are triggered sequentially. For example, following the example above, 4-1×3=1 determines that the target shard for the 4th processing is shard 1, and 5-1×3=1 determines that the target shard for the 5th processing is shard 2. This avoids the problem of triggering the same shard each time, which would prevent the pending transaction details of the shard from being processed in a timely manner.

[0084] In another possible implementation, a transaction processing server corresponding to each shard is pre-specified, see below. Figure 5 This application provides an example diagram illustrating the association between shards and transaction processing servers. Transaction processing server Batch1 is associated with shard 1, meaning shard 1 is a pre-defined shard for transaction processing server Batch1. Similarly, shard 8 is a pre-defined shard for transaction processing servers Batch15 and Batch16. Based on this, the pre-defined shard corresponding to the transaction processing server is queried from the database and used as the target shard.

[0085] Step S120: Obtain the transaction details to be processed in batches from the target shard.

[0086] The system retrieves pending transaction details from the target shard in batches, and adjusts the balances of hot accounts based on these details. Optionally, it retrieves pending transaction details from the target shard in reverse order, according to the maximum number of details to retrieve per batch. After processing the current batch of pending transaction details, it retrieves the next batch of pending transaction details from the target shard, until all pending transaction details in the target shard have been processed.

[0087] In one possible implementation, the process of batch retrieving pending transaction details from the target shard includes: reading the total number of pending transaction details in the target shard; if the total number is greater than zero, retrieving pending transaction details in the target shard in batches according to the upper limit of the number to be retrieved in a single batch, obtaining the pending transaction details corresponding to each batch, and marking the batch number of the batch corresponding to each pending transaction detail, wherein the number of pending transaction details corresponding to each batch is less than or equal to the upper limit of the number to be retrieved in a single batch.

[0088] Optionally, a paginated reading method can be used to read the total number of pending transaction details in the target shard. If the total number is zero, it means that there are no transaction details to be processed in the target shard, and the transaction processing server can end the current processing. If the total number is not zero, it means that there are transaction details to be processed in the target shard, and the pending transaction details are retrieved and processed.

[0089] Specifically, pending transaction details are retrieved from the target slice in batches, with the number of pending transaction details in each batch being less than or equal to the maximum number that can be retrieved in a single batch. For example, if the target slice contains 41 pending transaction details and the maximum number that can be retrieved in a single batch is 10, then it can be retrieved in 5 batches, resulting in 5 batches of pending transaction details. The first 4 batches each contain 10 pending transaction details, and the last batch contains 1 pending transaction detail. Further, step S130 is executed for each batch of pending transaction details.

[0090] In this embodiment of the application, when obtaining transaction details to be processed in batches, the transaction details to be processed in the segment are marked with their corresponding batch information, such as batch number, to ensure that the transaction details to be processed in the segment are not processed repeatedly and to improve the accuracy of subsequent adjustments.

[0091] Step S130: Update the balances of the target transaction account and the hot account based on the batch-acquired pending transaction details.

[0092] The pending transaction details include information such as the transacting parties, transaction time, transaction amount, transaction direction, and transaction channel. Based on the pending transaction details obtained in batches in step S120, the balances of frequently used accounts are updated in batches according to each batch of pending transaction details.

[0093] Optionally, based on the order of the pending transaction details in the batch and the transaction amounts of the hot accounts recorded in each pending transaction detail, the balances of the corresponding trading parties (upstream account, downstream account) are deducted / increased sequentially. In this embodiment, multiple batches of pending transaction details can be processed in parallel, or each batch of pending transaction details can be processed once, and after the processing of that batch is completed, the next batch of pending transaction details can be obtained from the shard, until all pending transaction details in the shard have been processed. Alternatively, the transfer-in / transfer-out amounts of multiple pending transaction details can be merged into a target update amount, and a balance update operation can be performed based on this target update amount to update the balances of both trading parties, reducing the adjustment frequency of the target trading account.

[0094] Optionally, based on the transaction type tagged for each pending transaction detail in the acquired batch, pending transaction details of the incoming transaction type are categorized into a pending incoming transaction detail set, and pending transaction details of the outgoing transaction type are categorized into a pending outgoing transaction detail set. Further, based on the pending incoming transaction detail set, adjustments are made to the accounts of both upstream and downstream parties, as well as the transitional account; similarly, based on the pending outgoing transaction detail set, adjustments are made to the accounts of both upstream and downstream parties, as well as the transitional account.

[0095] In one possible implementation, updating the balance of the hot account based on the acquired pending transaction details includes: classifying the pending transaction details for each batch according to the transaction type tagged in the pending transaction details, obtaining a set of pending outgoing transaction details and a set of pending incoming transaction details, where the transaction type is either outgoing or incoming transaction; generating a target outgoing transaction detail set for the target transaction account based on the set of pending incoming transaction details; adjusting the accounts of the target transaction account based on the target outgoing transaction detail set, obtaining successfully adjusted outgoing transaction details; adjusting the accounts of the target transaction account and the hot account based on the successfully adjusted outgoing transaction details, and updating the balances of the target transaction account and the hot account; generating a target incoming transaction detail set for the target transaction account based on the set of pending outgoing transaction details; adjusting the target transaction account based on the target incoming transaction detail set, obtaining successfully adjusted incoming transaction details; adjusting the accounts of the target transaction account and the hot account based on the successfully adjusted incoming transaction details, and updating the balances of the target transaction account and the hot account.

[0096] Reference Figure 6 This application provides a flowchart illustrating the process of processing pending transaction details in batches, using the processing of a batch of pending transaction details as an example.

[0097] First, query the data shards that this transaction processing server can handle, i.e., the target shard. Start a data processing transaction, assemble the SQL statement, and in the target shard, query the pending transaction details page by page, i.e., the transaction details marked with transaction type. Retrieve the number of pending transaction details in the target shard page by page, and check if it is 0. If it is, it means there are no pending transaction details in the target shard, so roll back the data processing transaction, end the current batch processing task, and wait for the next trigger to start and process new pending data. If it is not 0, it means there are pending transaction details in the target shard, so obtain a batch of pending transaction details and update the batch information of the pending transaction details in the database to prevent the same pending transaction detail from being divided into duplicate batches or processed by other transaction processing servers.

[0098] Furthermore, based on the transaction type, the pending transaction details of the currently read batch are categorized. Referring to the above, each pending transaction detail is labeled with either an incoming transaction (TC) or an outgoing transaction (TD). All pending transaction details in this batch are divided into: a set of pending transaction details belonging to incoming transactions, i.e., the pending incoming transaction details set, and a set of pending transaction details belonging to outgoing transactions, i.e., the pending outgoing transaction details set.

[0099] Based on this, a target outflow detail set for the target trading account is generated from the set of pending inflow details, and a target inflow detail set for the target trading account is generated from the set of pending outflow details. Based on the target outflow detail set and the target inflow detail set, adjustments are made to the accounts of hot accounts and target trading accounts to ensure strict equality of inflow and outflow funds in the target trading accounts and to ensure the accuracy, compliance and efficiency of fund transfers.

[0100] It is understandable that during the transaction process between upstream and downstream accounts through the target trading account, there are two fund transfers: funds transferred from the upstream account to the target trading account (recorded as incoming funds in the target trading account), and funds transferred from the target trading account to the downstream account (recorded as outgoing funds in the target trading account). The target trading account is essentially a temporary transit point for funds, and its core function is to ensure the complete transfer of funds from the upstream account to the downstream account.

[0101] If the upstream account is a hot account, and the processing of the incoming transaction details is still based on the logic of "upstream account - target transaction account - downstream account" for adjusting the accounts, there is a risk of account crash when the upstream account performs batch fund transfer operations to the target transaction account, since both the upstream account and the target transaction account are hot accounts. This would affect the normal execution of fund transfer operations from the target transaction account to the downstream account, resulting in "artificially increased funds" in the target transaction account, that is, there are only incoming funds but no corresponding outgoing funds, and the accuracy of the adjustment cannot be guaranteed.

[0102] Therefore, in this embodiment, the set of incoming transaction details to be processed is first regarded as the target outgoing transaction detail set of the target transaction account. From the perspective of the outgoing party, the target transaction account only adjusts the funds transferred from the target transaction account to the downstream account within this set. Adjustment failures are allowed during the adjustment process, and the successfully adjusted outgoing transaction details in the set are recorded. For example, if the target outgoing transaction detail set contains 10 transaction details, and only 5 of them have successfully adjusted outgoing transactions, then only these 5 successfully adjusted transaction details are recorded as the basis for subsequent adjustments to funds transferred from the upstream account to the target transaction account. The transaction amounts of the successfully adjusted outgoing transaction details are summarized, and this transaction amount corresponds to the incoming amount in the target transaction account. Based on this, adjustments are made between the target transaction account and the upstream account to ensure consistency between the incoming and outgoing funds in the final target transaction account, thus avoiding financial losses.

[0103] When downstream accounts are frequently used accounts, the target transaction account follows the traditional "receive first, pay later" transaction logic, simplifying the reconciliation process. However, because both the downstream and target transaction accounts are frequently used accounts, there is a risk of account crashes when the target transaction account makes bulk payments to downstream accounts. This could disrupt the normal execution of fund transfers from upstream accounts to the target transaction account, resulting in "inflated liabilities" for the target transaction account—meaning funds have been transferred out, but the corresponding inflows have not been received, making the accuracy of the reconciliation impossible to guarantee.

[0104] Therefore, in this embodiment, the set of outgoing transaction details to be processed is first regarded as the target incoming transaction details set for the target transaction account. From the perspective of the receiving party, the target transaction account only adjusts the accounts for funds transferred from upstream accounts to the target transaction account within this set. Adjustment failures are allowed during the adjustment process, and the successfully adjusted incoming transaction details in the set are recorded. Correspondingly, based on the successfully adjusted incoming transaction details, the total incoming amount of the target transaction account is summarized. Based on this, adjustments are made between the target transaction account and downstream accounts to ensure that the outgoing funds of the final target transaction account are consistent with the total incoming amount, thus avoiding financial losses.

[0105] Specifically, the transaction processing server deployed on the target trading account opens separate thread pools for outgoing and incoming payments. In the outgoing payment thread pool, the target trading account, from the perspective of the outgoing party, completes parallel reconciliation between the target trading account and downstream accounts based on the target outgoing payment details set. During this process, failures may occur. In such cases, the failed outgoing transaction details are deleted, and the total outgoing amount of all successfully outgoing transactions is aggregated to obtain the total outgoing amount for the target trading account. Based on this total outgoing amount, reconciliation is performed on the hot account (upstream account) to complete the incoming payments for both the target trading account and the hot account.

[0106] Similarly, in the inflow thread pool, the target transaction account, from the perspective of the inflow party, completes parallel reconciliation between the target transaction account and the upstream account based on the target inflow detail set. During this process, failures may occur. In such cases, the transaction details of the failed inflows are deleted, and the total inflow amount of all successfully inflowed transactions is summarized to obtain the total inflow amount. Based on this total inflow amount, reconciliation is performed on the hot account (downstream account) to complete the outflow of funds from the target transaction account and the inflow of funds from the hot account.

[0107] In particular, for scenarios where payment fails to be issued or received, adjustments can be made according to the actual business needs of the payment platform. For example, if payment fails to be issued, the transaction can be marked as a final failure. Alternatively, if payment attempts fail multiple times, the transaction can be marked as a final failure. Or, if the platform merchant resends the transaction details data after the first failed receipt attempt, the transaction can be marked as a final failure after multiple failed receipt attempts.

[0108] Once both inflows and outflows to the target transaction account are completed, the processing of this batch of pending transaction details is finished. The target shard is then queried again to retrieve the next batch of pending transaction details. Optionally, before retrieving the next batch of pending transaction details, it is first determined whether the number of pending transaction details in the current batch is less than the maximum number that can be retrieved in a single batch, for example, 1000. If it is less than the maximum number that can be retrieved in a single batch, it means that the pending transaction details on the target shard have been processed and do not need to be retrieved again. The current batch processing task ends, waiting for the next trigger. If it is equal to the maximum number that can be retrieved in a single batch, it means that there are still pending transaction details in the target shard, and the next batch of pending transaction details needs to be retrieved again. This transaction detail processing process is repeated until all pending transaction details on the target shard have been processed. Then, the current batch processing task ends, waiting for the next trigger.

[0109] In summary, the transaction processing method for hot accounts provided in this application caches the pending transaction details of hot accounts in database shards, and the transaction processing server periodically performs batch processing on the cached pending transaction details in the shards. This application reduces the frequency of updates to hot account balances due to a large number of transactions in a short period by caching transaction details in the database. Simultaneously, it aggregates and updates the balances of hot accounts all at once through batch processing. Furthermore, the use of sharded storage and sharded processing avoids the situation where the transaction server centrally processes a large number of transaction details stored in the database, thus reducing the load pressure on the trading platform.

[0110] Furthermore, since this application caches the transaction details of frequently accessed accounts, rather than their balances, individual transactions do not directly update the balances. Instead, the balances are updated only after the details are aggregated. This avoids the inaccurate balance updates caused by balance splitting. Based on this, even if transaction details fail to be cached or experience caching delays that prevent timely synchronization to the database shards, the transaction processing server, when batch aggregating the transaction details, distinguishes processed transaction details by labeling the acquired pending transaction details. The aforementioned cached or delayed transaction details are filtered out of the database and will not affect the balances of frequently accessed accounts, ensuring the security and accuracy of frequently accessed account balance updates.

[0111] Reference Figure 7 The following is an example diagram illustrating another application scenario provided in this application embodiment. Figure 7 The example shown is from a freight matching platform, illustrating the practical application of the transaction processing method for the aforementioned hot accounts. In the freight matching platform's transaction scenario, the guarantee register acts as a transitional account, temporarily storing orders for each acquiring transaction. Order details include: advance payment register, shipper register, marketing fee register, platform service fee register, driver register, moving service provider register, and special registers such as insurance. Among these, the information corresponding to the advance payment register, shipper register, and marketing fee register corresponds to the upstream accounts of the transitional accounts described above, while the platform service fee register, driver register, moving service provider register, and special registers such as insurance correspond to the downstream accounts of the transitional accounts described above.

[0112] Based on this, for each transaction on the merchant's side, such as a shipper paying moving fees, the guarantee register will generate a maximum of 7 fund transfer interface calls. These 7 fund transfer interface calls include: advance payment account → guarantee account, shipper account → guarantee account, marketing account → guarantee account, guarantee account → platform service account, guarantee account → driver account, guarantee account → mover account, and guarantee account → insurance account. Based on the inflow and outflow relationships between the guarantee register and upstream and downstream accounts, the corresponding outflow and inflow fund transfer interface calls for the guarantee register are determined. In this example, the inflow fund transfer interface calls belonging to the guarantee register include: advance payment account → guarantee account, shipper account → guarantee account, and marketing account → guarantee account; the outflow fund transfer interface calls belonging to the guarantee register include: guarantee account → platform service account, guarantee account → driver account, guarantee account → mover account, and guarantee account → insurance account.

[0113] In this example, a transaction processing system for hot accounts is deployed for the guarantee register. The transaction acceptance server in the system receives each acquiring transaction and stores the acquiring transactions in the database shards, ensuring that the stored acquiring transactions are evenly distributed across the shards.

[0114] Furthermore, the transaction processing server periodically triggers the processing of acquiring transactions, acquiring transactions from the corresponding target segments in batches. Based on the outgoing and incoming transaction categories of the seven fund transfer interfaces in the acquiring details of each transaction, specifically based on incoming fund transfer interfaces belonging to the guarantee register, the server summarizes the total amount or details of incoming fund transfers in the guarantee register; and based on outgoing fund transfer interfaces belonging to the guarantee register, the server summarizes the total amount or details of outgoing fund transfers in the guarantee register. This summary is then updated to the platform service fee register, driver register, moving service provider register, and special registers such as insurance, reducing the frequency of fund transfers in transit accounts and alleviating the load pressure on the freight matching platform.

[0115] This application also provides an electronic device in its embodiments. (See reference...) Figure 8 The diagram illustrates a structural schematic suitable for implementing the electronic device in the embodiments of this application. The electronic device in the embodiments of this application may include, but is not limited to, fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 8 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0116] like Figure 8 As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage device 608 into a random access memory (RAM) 603. When the electronic device is powered on, the RAM 603 also stores various programs and data required for the operation of the electronic device. The processing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0117] Typically, the following devices can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 608 including, for example, memory cards, hard drives, etc.; and communication devices 609. Communication device 609 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 8 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have instead.

[0118] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the hotspot account transaction processing methods provided in this application.

[0119] This application also provides a computer-readable storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the hotspot account transaction processing methods provided in this application.

[0120] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0121] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0122] In the above embodiments, the implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, in the form of a computer program product.

[0123] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A method for processing transactions of frequently accessed accounts, characterized in that, The transaction processing server of the transaction processing system applied to the target transaction account, wherein the transaction processing system for the hot account further includes at least: a transaction acceptance server and a database, wherein the database includes multiple shards; The transaction processing method for the aforementioned hot accounts includes: If the preset triggering conditions are met at the current time, the target shard for the transaction processing server to process is determined from the database. The target shard stores the pending transaction details of hot accounts, and the transaction identifier number of the pending transaction details is within the preset number range corresponding to the target shard. The transaction details to be processed are obtained in batches from the target shard; Based on the batch-acquired transaction details to be processed, update the balances of the target transaction account and the hot account.

2. The transaction processing method for hot accounts according to claim 1, characterized in that, The process of determining the target shard to be processed by the transaction processing server in this transaction from the database includes: Before the current time, obtain the total number of times all transaction processing servers in the transaction processing system of the hot account have triggered the preset trigger condition, and determine the corresponding number of times the transaction processing server triggers the current trigger at the current time; Based on preset processing rules, the target shard corresponding to the current trigger count is determined. The preset processing rules are: shards are triggered sequentially according to the sorting of all shards in the database, and only one shard is processed each time.

3. The transaction processing method for hot accounts according to claim 1, characterized in that, The process of determining the target shard to be processed by the transaction processing server in this transaction from the database includes: The target shard is selected from the preset designated shard corresponding to the transaction processing server by querying the database.

4. The transaction processing method for hot accounts according to claim 1, characterized in that, The process of obtaining the transaction details to be processed in batches from the target shard includes: Read the total number of pending transaction details in the target shard; When the total number is greater than zero, the transaction details to be processed in the target segment are obtained in batches according to the upper limit of the number of times they are obtained at one time, so as to obtain the transaction details to be processed corresponding to each batch, and the batch number of the corresponding batch is marked on the transaction details to be processed. The number of transaction details to be processed corresponding to each batch is less than or equal to the upper limit of the number of times they are obtained at one time.

5. The transaction processing method for hot accounts according to claim 1, characterized in that, The step of updating the balances of the target transaction account and the hot account based on the batch-acquired transaction details to be processed includes: Based on the transaction type corresponding to the transaction details to be processed, the transaction details to be processed for each batch are classified to obtain a set of outgoing transaction details to be processed and a set of incoming transaction details to be processed. The transaction type is either an outgoing transaction or an incoming transaction. Based on the set of pending inflow details, a set of target outflow details for the target transaction account is generated; based on the set of target outflow details, the target transaction account is adjusted to obtain outflow details with successful adjustments; based on the outflow details with successful adjustments, the target transaction account and the hot account are adjusted to update the balances of the target transaction account and the hot account. Based on the set of pending outgoing transaction details, a set of target incoming transaction details for the target transaction account is generated; based on the set of target incoming transaction details, the target transaction account is adjusted to obtain incoming transaction details with successful adjustments; based on the incoming transaction details with successful adjustments, the balances of the target transaction account and the hot account are adjusted, and the balances of the target transaction account and the hot account are updated.

6. A transaction processing system for frequently accessed accounts, characterized in that, include: At least one transaction acceptance server, a database, and at least one transaction processing server, wherein the database comprises multiple shards; The transaction processing server obtains the pending transaction details of the hot accounts and stores the pending transaction details in the database. The database stores the transaction details to be processed into a shard corresponding to a preset number range containing transaction identifier numbers; The transaction processing server processes the pending transaction details in the segment according to the transaction processing method for hot accounts as described in any one of claims 1-5, so as to update the balance of the target transaction account and the hot account.

7. The transaction processing system for hot accounts according to claim 6, characterized in that, The process by which the transaction processing server obtains the pending transaction details of popular accounts includes: Retrieve pending transaction orders; Based on the pending transaction orders, determine the upstream and downstream accounts of the target transaction account. The upstream account is the account that transfers funds to the target transaction account, and the downstream account is the account that receives funds transferred out of the target transaction account. Determine whether the upstream account and the downstream account are hot accounts; If the upstream account is the hot account, then generate pending transaction details based on the pending transaction orders, and mark the transaction type of the pending transaction details as incoming transactions; If the upstream account is not the hot account and the downstream account is the hot account, then a pending transaction detail is generated based on the pending transaction order, and the transaction type of the pending transaction detail is marked as an outgoing transaction. If neither the upstream account nor the downstream account is a hot account, then the accounts of the upstream account and the downstream account are adjusted according to the pending transaction orders.

8. A computer program product, characterized in that, It includes computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the transaction processing method for hot accounts as described in any one of claims 1 to 5.

9. An electronic device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to implement the transaction processing method for hot accounts as described in any one of claims 1 to 5.

10. A computer storage medium, characterized in that, The storage medium carries one or more computer programs that, when executed by an electronic device, enable the electronic device to implement the transaction processing method for hot accounts as described in any one of claims 1 to 5.

Images