Electronic payment processing method and apparatus, electronic device, and storage medium

Abstract

The application provides a processing method and device of electronic payment, electronic equipment and computer readable storage medium; the method comprises the following steps: receiving at least one payment request of at least one client; performing a deduction operation on a user account corresponding to each payment request, sending a deduction success message to the client, and sending a deposit success message to a merchant system corresponding to the payment request; generating a corresponding deposit request based on each payment request, and storing the deposit request into an asynchronous cache database and a distributed message queue respectively; reading a to-be-processed deposit request from the distributed message queue, and performing a deposit operation on a merchant account corresponding to the read deposit request; when the distributed message queue is in an unavailable state, continue to read a to-be-processed deposit request from the asynchronous cache database, and perform a deposit operation on a merchant account corresponding to the read deposit request. The application can improve the data throughput performance of the electronic payment scene and improve the real-time performance of the electronic payment.

Description

Technical Field

[0001] This application relates to Internet technology, and more particularly to a method, apparatus, electronic device, and computer-readable storage medium for processing electronic payments. Background Technology

[0002] In banking or third-party payment systems, large-scale transfer transactions targeting frequently accessed accounts often occur. During these transactions, the data recorded in these accounts is frequently updated by business requests. All business requests must queue and wait for the account record lock for the frequently accessed accounts to complete the transfer. This causes a backlog of business requests, leading to timeouts and failures, reducing the throughput of the payment system, and severely impacting the processing of other business operations. Summary of the Invention

[0003] This application provides an electronic payment processing method, apparatus, electronic device, and computer-readable storage medium, which can improve the data throughput performance and real-time performance of electronic payment scenarios.

[0004] The technical solution of this application embodiment is implemented as follows:

[0005] This application provides an electronic payment processing method, including:

[0006] Receive at least one payment request from at least one client;

[0007] Perform a deduction operation on the user account corresponding to each payment request, send a deduction success message to the client, and send an account receipt success message to the merchant system corresponding to the payment request;

[0008] A corresponding invoice request is generated based on each payment request, and the invoice requests are stored in an asynchronous cache database and a distributed message queue, respectively.

[0009] Read pending payment requests from the distributed message queue and perform payment operations on the merchant accounts corresponding to the read payment requests;

[0010] When the distributed message queue is unavailable, the system continues to read pending payment requests from the asynchronous cache database and performs payment operations on the merchant accounts corresponding to the read payment requests.

[0011] This application provides an electronic payment processing method, including:

[0012] Display the page for electronic payment in the client;

[0013] In response to receiving an electronic payment operation for the merchant system on the page, a payment request is sent to the merchant system, and a successful deduction message is displayed in real time;

[0014] The successful deduction message is sent by the backend server after performing the deduction operation on the user account corresponding to the payment request, and the crediting operation for the merchant account in the merchant system is performed based on an asynchronous cache database and a distributed message queue.

[0015] This application provides an electronic payment processing device, comprising:

[0016] A receiving module for receiving at least one payment request from at least one client;

[0017] The deduction module is used to perform deduction operations on the user account corresponding to each payment request, send a deduction success message to the client, and send an account receipt success message to the merchant system corresponding to the payment request.

[0018] The generation module is used to generate a corresponding invoice request based on each payment request, and store the invoice requests in an asynchronous cache database and a distributed message queue respectively;

[0019] The first invoicing module is used to read invoicing requests to be processed from the distributed message queue and perform invoicing operations on the merchant accounts corresponding to the read invoicing requests.

[0020] The second invoicing module is used to continue reading pending invoicing requests from the asynchronous cache database and perform invoicing operations on the merchant accounts corresponding to the read invoicing requests when the distributed message queue is unavailable.

[0021] In the above scheme, the electronic payment processing device further includes a rate limiting module, and the status of the received payment request includes "processing" and "pending processing"; the rate limiting module is used for:

[0022] When the number of connections occupied by a payment request being processed exceeds the first connection threshold, or when the number of connection pools occupied by a payment request being processed exceeds the first connection pool threshold, the payment requests to be processed will be rate-limited, and the merchant account corresponding to the payment requests to be processed will be added to the rate-limiting list.

[0023] In the above solution, the current limiting module is further used for:

[0024] When multiple pending payment requests correspond to merchant accounts in the rate limiting list, the multiple pending payment requests are merged and the merged payment requests are stored in a temporary queue corresponding to the merchant account.

[0025] When an invoice request in any temporary queue times out and the number of invoice requests is less than the request count threshold, the merchant account corresponding to any temporary queue is removed from the rate limiting list, and an invoice operation is performed on the merchant account corresponding to the invoice request in any temporary queue.

[0026] In the above scheme, the first accounting module is further used for:

[0027] When the number of incoming payment requests in any temporary queue exceeds the threshold, an incoming payment operation is performed on the merchant account corresponding to the incoming payment request in any temporary queue.

[0028] In the above scheme, the first accounting module is further used for:

[0029] Based on the memory usage of the incoming billing requests being processed, determine the number of connections and connection pool size used by other incoming billing requests;

[0030] Among them, the other incoming payment requests are incoming payment requests that are being processed and correspond to the same merchant account as the incoming payment requests that are pending processing;

[0031] When the number of connections occupied by the other invoice requests does not exceed the second connection threshold, and the number of connection pools occupied by the other invoice requests does not exceed the second connection pool threshold, the merchant account information carried in the invoice requests to be processed is written into the memory of any idle process.

[0032] The idle process performs an invoice processing operation on the merchant's account.

[0033] In the above solution, the current limiting module is also used for

[0034] When the number of connections occupied by the other invoice requests exceeds the second connection threshold, or when the number of connection pools occupied by the other invoice requests exceeds the second connection pool threshold, the pending invoice requests are rate-limited, and the merchant accounts corresponding to the pending invoice requests are added to the rate-limiting list.

[0035] In the above solution, the current limiting module is further used for:

[0036] Determine the number of pending posting requests containing preset command words;

[0037] When the number of pending invoice requests containing preset command words exceeds the command word threshold, rate limiting is applied to the pending invoice requests containing preset command words, and the merchant account corresponding to the pending invoice requests containing preset command words is added to the rate limiting list.

[0038] In the above scheme, the deduction module is further used for:

[0039] For each payment request, the corresponding user account is retrieved from the user database;

[0040] The transfer amount carried in the payment request is deducted from the balance of the user's account as retrieved, and a user account transaction record is generated;

[0041] A transaction order is generated based on the user account transaction history.

[0042] In the above scheme, the first accounting module is further used for:

[0043] Lock the order numbers of the transactions in the merchant database;

[0044] Based on the order number, the merchant account transaction record corresponding to the read invoice request is searched in the merchant database;

[0045] If the merchant account transaction record is not found, the transfer amount is added to the balance of the merchant account corresponding to the read inflow request, and a merchant account transaction record is generated.

[0046] The transaction number is then unlocked.

[0047] In the above scheme, the first accounting module is further used for:

[0048] The transactions corresponding to each payment request are verified based on the merchant account transaction history and the user account transaction history to ensure that the deduction from the user account and the payment to the merchant account are correct in each transaction.

[0049] In the above scheme, the receiving module is further configured to:

[0050] The relevant information of the payment request is stored in a log so that recovery processing can be performed based on the log when the asynchronous cache database, the user database, or the merchant database is unavailable.

[0051] In the above scheme, the first accounting module is further used for:

[0052] Change the status of the merchant account in the asynchronous cache database from pending payment to paid payment.

[0053] This application provides an electronic payment processing device, comprising:

[0054] The first display module is used to display the page for electronic payment in the client.

[0055] The second display module is used to respond to receiving an electronic payment operation for the merchant system on the page, send a payment request for the merchant system, and display a successful deduction message in real time;

[0056] The successful deduction message is sent by the backend server after performing the deduction operation on the user account corresponding to the payment request, and the crediting operation for the merchant account in the merchant system is performed based on an asynchronous cache database and a distributed message queue.

[0057] This application provides an electronic device, including:

[0058] Memory, used to store executable instructions;

[0059] The processor, when executing executable instructions stored in the memory, implements any of the electronic payment processing methods provided in the embodiments of this application.

[0060] This application provides a computer-readable storage medium storing executable instructions for inducing a processor to execute and implement any of the electronic payment processing methods provided in this application.

[0061] The embodiments of this application have the following beneficial effects:

[0062] After deducting funds from a user's account, the asynchronous processing of notification sending and payment processing enables the client and merchant systems to perceive the electronic payment processing results in real time, improving the user and merchant experience. For payment requests, a distributed message queue and asynchronous cache database are used in collaboration, which alleviates high concurrency contention while effectively ensuring the persistence and security of payment request-related data. Attached Figure Description

[0063] Figure 1 This is a schematic diagram illustrating the implementation of asynchronous services provided by related technologies;

[0064] Figure 2 This is a schematic diagram illustrating the transmission of requests in a message queue provided by related technologies;

[0065] Figure 3 This is a schematic diagram of the accounting principle provided by the relevant technology;

[0066] Figure 4A This is a schematic diagram of the architecture of the transaction system provided in the embodiments of this application;

[0067] Figure 4B This is a schematic diagram of the architecture of the asynchronous payment system provided in the embodiments of this application;

[0068] Figure 5 This is a schematic diagram of the accounting principle provided in the embodiments of this application;

[0069] Figure 6A This is a flowchart illustrating the electronic payment processing method provided in an embodiment of this application;

[0070] Figure 6B This is a schematic diagram of the interactive flow of the electronic payment processing method provided in the embodiments of this application;

[0071] Figure 6C This is a schematic diagram of the electronic payment page provided in an embodiment of this application;

[0072] Figure 6D This is a schematic diagram of the payment success notification page provided in an embodiment of this application;

[0073] Figure 7 This is an interactive diagram illustrating the accounting process provided in this application embodiment;

[0074] Figure 8 This is a schematic diagram of dynamic current limiting provided in an embodiment of this application;

[0075] Figure 9A This is a flowchart illustrating the electronic payment processing method provided in an embodiment of this application;

[0076] Figure 9B This is a schematic diagram illustrating the processing of an invoice request provided in an embodiment of this application;

[0077] Figure 10 This is a transaction diagram of popular merchants provided in the embodiments of this application;

[0078] Figure 11 This is a schematic diagram of the page for processing invoice requests provided in an embodiment of this application;

[0079] Figure 12A This is a schematic diagram of the structure of the server 400 provided in the embodiment of this application;

[0080] Figure 12B This is a schematic diagram of the structure of the terminal 500 provided in the embodiments of this application. Detailed Implementation

[0081] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0082] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0083] If the application documents contain similar descriptions such as "first / second", the following explanation shall be added: In the following description, the terms "first / second / third" are used only to distinguish similar objects and do not represent a specific order of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0084] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0085] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0086] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0087] 1) MySQL: A relational database management system.

[0088] 2) Real-time payment system: A system that can promptly complete payments to users' bank cards.

[0089] 3) Asynchronous payment system: A system used to delay the payment of funds to the merchant's account. Specifically, the actual payment is made only after a successful payment message is sent to the client.

[0090] 4) User Identification (UID): Users, merchants and other users all have their own UID, which is their unique identifier.

[0091] 5) Command words: These are operations performed on a merchant's account, such as increasing the merchant's balance.

[0092] 6) Queries per second (QPS): This is the number of successful requests a single process makes to the server per second.

[0093] 7) Throughput (TPS, Transactions Per Second): The number of transactions a server can process per unit of time, which is the number of transactions per second.

[0094] 8) Concurrency: A situation where there are multiple payment requests that need to be processed within a certain period of time. These multiple payment requests can come from the same or different users.

[0095] 9) Message Queues (MQ): A distributed message queue service that provides a reliable message-based asynchronous communication mechanism. It stores messages sent and received between different distributed applications (or different components of the same application) in a reliable and efficient CMQ queue, preventing message loss. CMQ supports simultaneous read and write operations by multiple processes without interference, and does not require each application or component to be constantly running. Message queues implemented using cloud technology are called Cloud Message Queues (CMQ).

[0096] 10) Process: is an instance of a running program, and also a container for threads.

[0097] 11) Thread: The basic unit of execution within a process. All tasks of a process are executed within a thread. Multiple threads can run concurrently within a process, each executing different tasks in parallel. One thread handles one request; for each request, an idle thread is retrieved from the thread pool.

[0098] 12) Connection Pool: A memory space used to store database connections as objects. When database access is needed, an established, idle connection object is retrieved from the connection pool; after use, the connection is returned to the connection pool for the next request.

[0099] 13) Hot accounts: These are accounts that make deductions or deposits at high frequency (exceeding the frequency threshold); the corresponding data is hot data and will be updated frequently.

[0100] 14) Asynchronous: This means that after a request is sent, there is no need to wait for a response, and the next request can be triggered at any time without waiting.

[0101] 15) Rate limiting: Protect the system by limiting the rate of concurrent access requests or the rate of requests within a time window. Once the rate limit is reached, the system can refuse service, make the service queue or wait, or degrade the service.

[0102] 16) Lock contention: When multiple threads use the same lock, if another thread acquires the lock before the current thread, the current thread will be blocked while acquiring the lock.

[0103] Commercial payments are typically processed and credited in real time through real-time payment systems. However, in actual operation, real-time payment systems may encounter the following problems:

[0104] 1. A merchant's sudden promotion caused a surge in requests, making the real-time payment system overloaded.

[0105] 2. When the real-time payment system malfunctions, bank payments become unavailable.

[0106] 3. The QPS traffic is uneven within one second, with requests concentrated in the first few tens of milliseconds. Due to the rate limiting of the resource manager, only some requests can penetrate the resource manager to reach the database, while other requests are rejected by the resource manager. Only after some requests are processed will they continue to be processed. However, because the QPS exceeds the limit at this time, new requests cannot come in. Furthermore, due to the QPS timeout setting, if the remaining requests are not processed within a certain time, they will no longer be processed, resulting in a low overall TPS.

[0107] Because most merchants use daily / monthly settlement methods, they don't care about the real-time balance in their accounts. Therefore, related technologies address the issue of excessively concentrated requests by deducting funds from user accounts in real time and delaying the crediting of funds to merchant accounts. For flash sale scenarios, related technologies introduce asynchronous services to make some payments near real-time, transforming parallel requests into serial requests and alleviating the pressure on the payment system caused by high concurrency.

[0108] like Figure 1 and Figure 2 As shown, Figure 1 This is a diagram illustrating the implementation of asynchronous services provided by related technologies. Figure 2 This is a diagram illustrating request passing in a message queue provided by related technologies. Figure 1 In the middle, from network users (also Figure 2 User requests from the publisher (in the context of the message queue) are sent to a message queue, processed asynchronously by an asynchronous queue component, and then... Figure 2 The consumer consumes (i.e., processes) the request. The management console manages the message queues; it can create different message queues according to different business needs, and can also configure, monitor, manage, and rebuild requests. A global proxy is used to detect message queues. If the asynchronous queue component encounters a problem, technical support from the relevant database administrator is required to resolve the issue, which is not conducive to management and maintenance, has poor controllability, and the problems that arise are highly likely to pose uncontrollable risks to the business.

[0109] See Figure 3 , Figure 3This is a schematic diagram of the payment processing principle provided by relevant technologies. The left and right sides of the dotted line correspond to different locations; for example, the left side corresponds to Guangzhou, and the right side to Shanghai. The access layer receives payment requests from clients and distributes pending payment requests to the transaction manager. The transaction manager is used to create transactions and assign transaction identifiers to them. Figure 3 In this system, Transaction Manager 1 and Transaction Manager 2 are used to receive payment requests, complete the deduction operation from user accounts, and generate posting requests based on the payment requests. The asynchronous posting service is used to implement postings to merchant accounts, and the merchant database is used to store information such as the balance of each merchant account. Figure 3 Taking the left side as an example to illustrate the billing process, Transaction Manager 1 sends the billing request to Message Queue 1 to wait for processing. Then, Asynchronous Billing Service 1 calls the billing interface of Merchant Resource Manager 1 to process the billing requests in Message Queue 1 in sequence, completes the billing of the merchant account, and updates the balance information of the corresponding merchant account in the merchant database.

[0110] This near real-time (asynchronous) billing approach means that merchants experience almost no latency under normal high-concurrency conditions. However, when a merchant's account is constantly under high concurrency, new pending billing requests will be continuously inserted into the message queue. Because these pending requests cannot be processed in a timely manner, the near real-time effect is not achieved, thus degrading the merchant's experience.

[0111] To address the technical problems of difficult management of asynchronous queue components and the inability to achieve near real-time operation under continuous high concurrency in related technologies, embodiments of this application provide an electronic payment processing method, apparatus, electronic device, and computer-readable storage medium, which can improve TPS and reduce operational and maintenance pressure.

[0112] See Figure 4A , Figure 4A This is a schematic diagram of the architecture of a transaction system provided in this application embodiment. The transaction system includes a terminal and an asynchronous payment system, wherein the asynchronous payment system includes a banking system and a merchant system. The terminal (generally a user terminal) sends a payment request to the bank database in the banking system of the asynchronous payment system. The bank database completes the deduction operation on the user account related to the payment request and generates an inflow request based on the payment request. Then, the inflow request is sent to the merchant database in the merchant system through the bank database to complete the inflow operation on the merchant account related to the payment request.

[0113] See Figure 4B , Figure 4BThis is a schematic diagram of the architecture of an asynchronous payment system provided in this application embodiment. The asynchronous payment system includes an access layer, multiple subsystems (subsystem 1, subsystem 2...subsystem n are shown), multiple merchant resource managers, and multiple merchant databases. The access layer connects to multiple subsystems (different subsystems can be used to handle different types of requests), each subsystem connects to a merchant resource manager, and the merchant resource manager connects to the merchant databases. Subsystems include a transaction manager, a distributed message queue, an asynchronous payment service, an asynchronous cache database, a user resource manager, and a user database. User resource managers can be divided into federated resource managers, order resource managers, bank resource managers, etc., depending on their functions. User databases can be divided into federated databases, user order databases, bank databases, etc., depending on their type. The federated resource manager is used to process data related to users, new orders, and new banks; the order resource manager is used to process data related to existing orders; and the bank resource manager is used to process data related to existing banks in the database.

[0114] As an example, the transaction manager and distributed message queue run on the transaction server, the user resource manager and user database run on the user server, the merchant resource manager and merchant database run on the merchant server, and the asynchronous cache database runs on the asynchronous server, which provides asynchronous billing services. These servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0115] See Figure 5 , Figure 5 This is a schematic diagram illustrating the accounting principle provided in an embodiment of this application. The following will be combined with... Figure 5The implementation process of the electronic payment processing method provided in this application embodiment is described. In a transaction (e.g., a flash sale scenario), a deduction operation needs to be performed on the user account first, followed by an invoice operation on the merchant account. Payment requests for the same merchant system enter transaction manager 1 through the access layer. Transaction manager 1 calls the user resource manager in the user server to perform the deduction operation on the user account. During this process, if the number of connections occupied by the user resource manager for the payment request exceeds the connection threshold, or the number of connections occupied exceeds the connection pool threshold, the merchant accounts corresponding to these payment requests are added to the rate limiting list. After the deduction is completed, transaction manager 1 generates an invoice request and synchronously sends it to the asynchronous server. The asynchronous server calls asynchronous invoice service 1 to write the relevant information of the invoice request (such as merchant account, user account, request initiation time, etc.) into asynchronous cache database 1 to achieve persistence of the invoice request information. In the event of an anomaly in the distributed message queue, payment can be completed based on the relevant data stored in asynchronous cache database 1.

[0116] Simultaneously, the payment request is asynchronously sent by Transaction Manager 1 to Distributed Message Queue 1 for processing. Asynchronous Payment Service 1 reads the payment request from Distributed Message Queue 1 to determine if the merchant account corresponding to the payment request belongs to the rate-limiting list. If not, the Merchant Resource Manager is directly invoked to process the payment request. If so, multiple payment requests corresponding to the merchant account are stored in a temporary queue in the asynchronous server's memory for processing. When a payment request in the temporary queue times out or the number of payment requests exceeds the request threshold, the Merchant Resource Manager is invoked to process the payment request. Specifically, if a payment request times out and the number of payment requests does not exceed the request threshold, the merchant account is removed from the rate-limiting list, and the Merchant Resource Manager is invoked to process the payment request. During the Merchant Resource Manager's processing of payment requests, if the payment request consumes too many Merchant Resource Manager processes (connections), triggering rate limiting, the merchant account will be added back to the rate-limiting list. If the billing request does not trigger rate limiting in the Merchant Resource Manager, the Merchant Resource Manager will update the balance and other information of the merchant account in the merchant database according to the billing request, complete the billing, and change the status of the merchant account in the asynchronous cache database to "billed".

[0117] It should be noted that, Figure 5 The numerical sequence number indicates the direction of data flow.

[0118] As can be seen, the embodiments of this application use a distributed message queue to smooth out high-concurrency requests. On this basis, by using the above-mentioned rate limiting measures when performing deduction operations on user accounts and crediting operations on merchant accounts, the number of high-concurrency requests is further reduced, the lock waiting time of user database and merchant database is reduced, and the contention for concurrent locks is alleviated.

[0119] See Figure 6A and Figure 7 , Figure 6A This is a flowchart illustrating the electronic payment processing method provided in an embodiment of this application. Figure 7 This is an interactive diagram of the accounting entry provided in the embodiments of this application. The following will be combined with Figure 6A The steps shown and Figure 7 This illustrates that the server in the asynchronous payment system executes the electronic payment processing method provided by the embodiments of this application.

[0120] In step 101, the transaction server receives at least one payment request from at least one client.

[0121] In some embodiments, such as Figure 7 As shown, the transaction manager in the transaction server receives at least one payment request from at least one client through the access layer of the asynchronous payment system. Each client can send one or more different payment requests to the asynchronous payment system for the same merchant system, or multiple different payment requests for multiple merchant systems. Each payment request carries information such as user account information, merchant account information, and transfer amount.

[0122] After receiving a payment request, the transaction manager determines that the user resource manager, user database, merchant resource manager, and merchant database in the asynchronous payment system are all in an available state. It then stores relevant information about the payment request (such as time, user account, merchant account, transfer amount, etc.) in the remote log for later use. Figure 7 When the asynchronous cache database, user database, or merchant database in the system is unavailable, recovery processing is performed based on logs, such as replaying transaction-related payment requests.

[0123] Next, the transaction manager calls the user resource manager on the user server to perform the deduction operation for the user account corresponding to each payment request. Before performing the deduction operation on the corresponding user account based on the payment request, it is necessary to determine whether the merchant account of the merchant system targeted by the payment request is on the rate-limiting list, and whether concurrent payment requests for the same merchant account will trigger rate-limiting by the user resource manager. Here, the merchant account is the account of the merchant system targeted by the payment request, and the status of the payment request received by the user resource manager includes "processing" and "pending processing".

[0124] In some possible examples, rate limiting in User Explorer is triggered when the number of connections used by payment requests for the same merchant account being processed in User Explorer exceeds the first connection threshold, or when the number of connection pools used by payment requests for the same merchant account being processed exceeds the first connection pool threshold.

[0125] If the merchant account targeted by the payment request is on the rate-limiting list, or if concurrent payment requests for the same merchant account trigger rate limiting in User Explorer, then User Explorer will rate-limit payment requests for that merchant account. This means that pending payment requests for that merchant account, as well as any newly received payment requests, will be delayed. Furthermore, when concurrent payment requests for the same merchant account trigger rate limiting in User Explorer, that merchant account will also be added to the rate-limiting list.

[0126] If the merchant account targeted by the payment request is not in the rate limiting list, and concurrent payment requests for the same merchant account do not trigger rate limiting in the User Explorer, then the payment requests will be processed in the order they are received.

[0127] In this way, high-concurrency requests can be smoothed out at the user resource manager level, reducing the number of high-concurrency requests entering the next level and alleviating the pressure on operations and maintenance.

[0128] In step 102, the user server performs a deduction operation on the user account corresponding to each payment request.

[0129] In one possible example, the user server performs a deduction operation on the user account corresponding to each payment request, which can be achieved through steps 1021 to 1023 below.

[0130] In step 1021, the corresponding user account is queried from the user database for each payment request.

[0131] In some embodiments, the user database on the user server stores user account information and historical transaction information for each user. Therefore, the user resource manager can query the corresponding user account in the user database based on the user account information carried in the payment request.

[0132] In step 1022, the transfer amount carried in the payment request is deducted from the balance of the queried user account, and a user account transaction record is generated.

[0133] Account transaction history refers to the transaction records.

[0134] In step 1023, a transaction order is generated based on the user account transaction history.

[0135] In some embodiments, transaction orders generated based on user account transaction history can be used to prevent duplicate transaction records, so it is not necessary to lock the user account when performing deduction operations on the user account.

[0136] It should be noted that steps 1021 to 1023 of the deduction operation are all atomic operations, meaning that they will not be interrupted by any other tasks or events before they are completed.

[0137] In step 103, the user server sends a payment success message to the client and a credit successful message to the merchant system corresponding to the payment request.

[0138] In some embodiments, after performing a deduction operation on a user account, the Merchant Resource Manager returns a successful deduction message to the Transaction Manager. Before performing a crediting operation on the merchant account of the merchant system corresponding to the payment request, the asynchronous payment system sends a successful deduction message to the user's client and a crediting success message to the merchant system corresponding to the payment request based on the successful deduction message. This reduces notification latency and improves the transfer experience for both users and merchants. Especially when the asynchronous payment system experiences fluctuations or the user server and merchant server are not in the same city, sending a crediting success message to the merchant in advance can prevent the phenomenon of successful crediting but delayed receipt of the crediting success message.

[0139] In step 104, the transaction server generates a corresponding receipt request based on each payment request and stores the receipt requests in the asynchronous cache database and the distributed message queue, respectively.

[0140] In some embodiments, there is a one-to-one correspondence between inbound and payment requests. Therefore, inbound requests also carry information such as user account information, merchant account information, and transfer amount. Because the transaction manager smooths out high-concurrency inbound requests, the number of inbound requests generated based on payment requests is also controlled accordingly. By calling the asynchronous inbound service in the asynchronous server to store inbound requests in real time to the asynchronous cache database, the persistence and security of inbound request-related data are effectively guaranteed, which is more secure and controllable than message queues. At the same time, asynchronously storing inbound requests in a distributed message queue can transform high-concurrency inbound requests into serial inbound requests, reducing the performance bottleneck caused by concurrent lock contention.

[0141] See Figure 8 , Figure 8This is a schematic diagram of dynamic rate limiting provided in an embodiment of this application. In some embodiments, after generating an invoice request corresponding to a payment request, the asynchronous invoice service checks whether the merchant accounts corresponding to multiple invoice requests to be processed are in the rate limiting list. When a merchant account is in the rate limiting list, the multiple invoice requests to be processed are merged, and the merged invoice requests are stored in a temporary queue in the memory of the asynchronous server. The asynchronous server has multiple temporary queues in its memory, each storing invoice requests corresponding to different merchant accounts; that is, each temporary queue corresponds one-to-one with a merchant account. When an invoice request in any temporary queue times out and the number of invoice requests is less than the request count threshold, the merchant account corresponding to any temporary queue is removed from the rate limiting list, and the merchant resource manager in the merchant server is invoked to perform an invoice operation on the merchant account corresponding to the invoice request in any temporary queue. When the number of invoice requests in any temporary queue exceeds the request count threshold, the merchant resource manager is invoked to perform an invoice operation on the merchant account corresponding to the invoice request in any temporary queue.

[0142] As can be seen, the asynchronous billing service reduces the number of requests entering the merchant resource manager at the same time in the next stage by merging the billing requests corresponding to the merchant accounts in the rate limiting list and storing them in a temporary queue. This is equivalent to a second peak smoothing of high-concurrency requests, which helps to alleviate the phenomenon of concurrent lock contention and effectively relieves the pressure on operation and maintenance.

[0143] In step 105, the asynchronous server determines whether the distributed message queue is available. If yes, it executes steps 106 and 107; otherwise, it executes steps 108 and 109.

[0144] In some embodiments, to ensure the consistency and security of transactions, when the distributed message queue is available, the payment request is read from the distributed message queue to complete the payment operation for the merchant account, i.e., steps 106 and 107 are executed; when the distributed message queue is unavailable, the payment request is read from the asynchronous cache database to complete the payment operation for the merchant account, i.e., steps 108 and 109 are executed.

[0145] In step 106, the asynchronous server reads pending invoice requests from the distributed message queue.

[0146] In some embodiments, as described in step 104, when a merchant account is in the rate-limiting list, the asynchronous billing service in the asynchronous server reads the billing requests to be processed from the distributed message queue and merges multiple billing requests to be processed. When the merged billing request triggers a timeout or the number of billing requests exceeds the request number threshold, the merchant resource manager in the merchant server is called to process the billing requests to be processed. When a merchant account is not in the rate-limiting list, the asynchronous billing service reads the billing requests to be processed from the distributed message queue and then calls the merchant resource manager to process the billing requests to be processed.

[0147] In some embodiments, the Merchant Resource Manager can be invoked to process pending invoicing requests. Figure 9A Steps 1061 to 1065 are implemented. Figure 9A This is a flowchart illustrating the electronic payment processing method provided in the embodiments of this application.

[0148] In step 1061, based on the memory information occupied by the invoicing request being processed, the number of connections and the number of connection pools occupied by other invoicing requests are determined.

[0149] In some embodiments, other billing requests are billing requests being processed by the Merchant Resource Manager and corresponding to the same merchant account as the pending billing requests. Each process of the Merchant Resource Manager corresponds to one connection, and each connection can have multiple requests. Each process can run multiple threads concurrently to handle multiple requests within the process. Processes in the Merchant Resource Manager exchange information through shared memory. Each process has its own dedicated shared memory, and each process writes information related to the requests it is currently processing into its own dedicated shared memory. It can also access the shared memory to obtain information stored in the dedicated shared memory of other processes to determine the requests that other processes are currently processing. Therefore, the number of billing requests currently being processed by each process can be determined through shared memory (i.e., memory information), as well as the number of connections and the number of connection pools occupied by billing requests corresponding to the same merchant account.

[0150] For example, incoming payment request 1 for merchant A's account occupies process 1, incoming payment request 2 occupies process 2, and incoming payment request 3 occupies process 4. Processes 1 and 2 correspond to connection pool 1, and process 4 corresponds to connection pool 2. Therefore, incoming payment requests for merchant A's account occupy a total of 3 processes, which means they occupy 3 connections and 2 connection pools.

[0151] In step 1062, it is determined whether the number of connections occupied by other billing requests exceeds the second connection number threshold, and whether the number of connection pools occupied by other billing requests exceeds the second connection pool number threshold; if the number of connections exceeds the second connection number threshold, or the number of connection pools exceeds the second connection pool number threshold, step 1063 is executed; if the number of connections does not exceed the second connection number threshold, and the number of connection pools does not exceed the second connection pool number threshold, steps 1064 and 1065 are executed.

[0152] In step 1063, the incoming payment requests to be processed are rate-limited, and the merchant accounts corresponding to the incoming payment requests to be processed are added to the rate-limiting list.

[0153] When the number of connections used by incoming payment requests for the same merchant account exceeds the second connection threshold, or the number of connections used exceeds the second connection pool threshold, rate limiting (i.e., delayed processing) will be applied to pending incoming payment requests for the same merchant account and to any newly received incoming payment requests. The merchant account will then be added to the rate limiting list.

[0154] As can be seen, when a payment request triggers rate limiting in the User Resource Manager, the merchant account corresponding to the payment request is added to the rate limiting list. When the merged payment request times out and the number of payment requests does not exceed the request threshold, the merchant account already added to the rate limiting list is removed. When a payment request triggers rate limiting in the Merchant Resource Manager, the merchant account corresponding to the payment request is added to the rate limiting list again. Thus, throughout the payment process, dynamic rate limiting is implemented based on the status of the payment and payment requests, reducing the number of threads running in the User Resource Manager and Merchant Resource Manager, reducing the lock waiting time in the merchant database, reducing the merchant database load, and improving the throughput of the asynchronous payment system.

[0155] In step 1064, the merchant account information carried in the pending invoice request is written into the memory of any idle process.

[0156] When the merchant account corresponding to the pending payment request is not subject to rate limiting, select an idle process in the Merchant Resource Manager and write the merchant account information (such as time, merchant account, etc.) carried in the pending payment request into the dedicated shared memory of the idle process.

[0157] In step 1065, an invoice operation is performed on the merchant account based on the idle process.

[0158] For details on performing the posting operation on the merchant account, please refer to the relevant explanation of step 107 below.

[0159] In some embodiments, the Merchant Resource Manager is used not only to process incoming payment requests but also to process deduction requests. For example, Merchant A needs to periodically transfer funds to a material supplier. In this case, the Merchant Resource Manager performs a deduction operation on the merchant's account to complete the payment. The Merchant Resource Manager handles different types of requests. When there are too many requests of the same type, i.e., too many requests containing the same command word such as "incoming payment," it will consume too much of the Merchant Resource Manager's process time, causing requests containing other command words, such as deduction requests, to not be processed in a timely manner, thus affecting the merchant's experience. Therefore, the Merchant Resource Manager needs to determine the number of pending requests (such as incoming payment requests) containing a preset command word (such as "incoming payment"). When the number of pending requests containing the preset command word exceeds a command word threshold (such as 100, 300, etc.), the pending requests containing the preset command word are rate-limited, and the merchant account corresponding to the pending requests containing the preset command word is added to the rate-limiting list.

[0160] Thus, in the Merchant Resource Manager, a third peak-shaving effect is achieved by using the second connection count threshold, the second connection pool count threshold, and the command word threshold. This prevents incoming payment requests or requests of the same type for the same merchant account from consuming all processes in the Merchant Resource Manager, thus preventing other business requests from being responded to. Especially when the merchant server capacity is insufficient, this can effectively improve the processing efficiency and system performance of the asynchronous payment system.

[0161] It should be noted that the method of rate limiting via command words can also be applied to User Explorer.

[0162] In step 107, the merchant server performs an invoice operation on the merchant account corresponding to the read invoice request.

[0163] In some embodiments, an invoicing operation is performed on the merchant account corresponding to the invoicing request, that is, the amount requested in the invoicing request is added to the merchant account corresponding to the invoicing request through the merchant resource manager in the merchant server.

[0164] In one possible example, the merchant server performs an invoice operation on the merchant account corresponding to the read invoice request, which can be achieved through steps 1071 to 1074 below.

[0165] In step 1071, the transaction order number in the merchant database is locked.

[0166] Since the transaction order is stored in the user database, the merchant database on the merchant server can only prevent duplicate processing of the payment request by locking the transaction order number.

[0167] In step 1072, the merchant account transaction record corresponding to the read invoice request is searched in the merchant database based on the order number.

[0168] In step 1073, when no merchant account transaction record is found, the transfer amount is added to the balance of the merchant account corresponding to the read inflow request, and a merchant account transaction record is generated.

[0169] If no transaction history for the merchant account corresponding to the received payment request is found, it means that the amount corresponding to the received payment request was not previously added to the merchant account. The transaction amount will then be added to the merchant account balance based on the transfer amount carried in the payment request to complete the payment operation.

[0170] In step 1074, the order number of the transaction order is unlocked.

[0171] Once the transaction number is unlocked, a posting operation can be performed on the merchant account based on the next posting request.

[0172] In some embodiments, after the posting operation is completed, the status of the merchant account corresponding to the processed posting request in the asynchronous cache database is changed from pending posting to posted. For example, the asynchronous cache database stores three posting requests (request a, request b, and request c) for merchant A. After performing a posting operation on merchant A's account based on request a, the status of merchant A corresponding to request a is updated to posted, while the status of merchant A corresponding to requests b and c remains pending posting.

[0173] In some embodiments, after modifying the status of the merchant account in the asynchronous cache database, it is also necessary to verify the transaction corresponding to each incoming payment request based on the merchant account transaction history and the user account transaction history to ensure that the deduction from the user account is correct and the incoming payment to the merchant account is correct in each transaction, thereby ensuring the accuracy of the transfer.

[0174] In step 108, the asynchronous server continues to read pending invoice requests from the asynchronous cache database.

[0175] In step 109, the merchant server performs an invoice operation on the merchant account corresponding to the read invoice request.

[0176] In some embodiments, the asynchronous billing service in the asynchronous server sends the read pending billing requests to the merchant resource manager of the merchant server, and performs the billing operation through the merchant resource manager.

[0177] It should be noted that the processing of the payment request in step 109 is the same as in step 106, and will not be repeated here. In this embodiment, the merchant database, user database, and asynchronous cache database can all be MySQL databases.

[0178] As can be seen, this embodiment of the application sends notifications to both the user's client and the merchant system simultaneously after deducting funds from the user's account, reducing notification latency and improving the transfer experience for both users and merchants. Storing the payment request in a distributed message queue reduces contention during high concurrency. Simultaneously, storing the payment request in an asynchronous cache database effectively ensures the persistence and security of data related to the payment request, allowing the payment process to be completed using the relevant data stored in the asynchronous cache database when the distributed message queue is unavailable. Dynamic rate limiting of high-concurrency requests through the user resource manager, asynchronous payment service, and merchant resource manager improves the performance of the asynchronous payment system without scaling up the merchant server, maximizing the throughput of the asynchronous payment system, ensuring payment stability for key merchants during peak periods, and significantly reducing operational pressure.

[0179] The following describes the electronic payment processing method provided in this application embodiment from the perspective of initiating a payment request from the client.

[0180] See Figure 6B , Figure 6B This is a schematic diagram of the interactive flow of the electronic payment processing method provided in the embodiments of this application, which will be combined with... Figure 6B The steps shown illustrate the process by which a user's terminal implements the electronic payment processing method provided in the embodiments of this application.

[0181] In step 201, a page for electronic payment is displayed on the client.

[0182] In some possible examples, the electronic payment page can be accessed through a client on the user's terminal (such as a third-party payment client or a bank client) or a payment mini-program.

[0183] As an example, clients can be of various types, such as instant messaging clients, short video clients, online shopping clients, etc.

[0184] In step 202, in response to receiving an electronic payment operation for the merchant system on the electronic payment page, a payment request is sent to the merchant system, and a successful deduction message is displayed in real time.

[0185] See Figure 6C and Figure 6D , Figure 6C This is a schematic diagram of the electronic payment page provided in an embodiment of this application. Figure 6D This is a schematic diagram of the payment success notification page provided in an embodiment of this application. Figure 6C In the process, when the transfer button 601 is triggered, i.e., when an electronic payment request is received for the merchant system (**supermarket), the backend server performs a deduction operation from the user's account, and then... Figure 6D The notification page shown displays that the user's transfer has been received and that the supermarket has received the money, indicating that the deduction was successful in real time.

[0186] In some embodiments, the deduction success message is sent by the backend server after performing the deduction operation on the user account corresponding to the payment request. At the same time, the backend server (i.e., the user server mentioned above) sends an account crediting success message to the merchant system. The account crediting operation for the merchant account in the merchant system is executed asynchronously relative to the sending of the account crediting success message. That is, the sending of the account crediting success message can be performed before the execution of the account crediting operation. For details, see above. The account crediting operation can be performed based on an asynchronous cache database and a distributed message queue.

[0187] Because the asynchronous payment system uses a distributed message queue, i.e., an asynchronous queue, it can smooth out high-concurrency requests and reliably send the corresponding payment request to the next stage (asynchronous payment service) for processing. At the same time, it stores payment requests in an asynchronous cache database, ensuring the persistence and security of payment request data. Therefore, after a successful deduction from a user's account, a notification can be sent synchronously to the user's account and the merchant's system in real time, thereby improving the transfer experience for users and merchants.

[0188] Furthermore, when performing deduction operations on user accounts and deposit operations on merchant accounts in the merchant system, this embodiment of the application reduces concurrent lock contention and improves the throughput of the asynchronous payment system by rate limiting payment requests and deposit requests, respectively. For a detailed explanation of rate limiting, please refer to the preceding text; it will not be repeated here.

[0189] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0190] See Figure 10 , Figure 10 This is a transaction diagram of popular merchants provided in the embodiments of this application. Figure 10 In this scenario, Merchant A conducts a flash sale at the top of the hour. After the sale begins, a large number of users (user 1 to user n) place orders and make payments. The merchant database will simultaneously receive n inflow requests to update the balance of Merchant A's account in the database. At this time, a hotspot occurs in the update of Merchant A's account balance, and the number of active connections in the Merchant Resource Manager used to process inflow requests rises rapidly. Since connections and database locks are limited, when the number of connections is exhausted, the upper-layer business service's call to the payment system will fail, causing all transactions involving the merchants in the merchant database to be unable to proceed.

[0191] To address the aforementioned issues, this application's embodiments combine asynchronous services and dynamic rate limiting to optimize the payment system.

[0192] After a user places an order, the client generates a payment request for the merchant's system. For example... Figure 7 As shown, the payment request reaches the transaction manager through the access layer of the asynchronous payment system. After determining that the user resource manager, user database, merchant resource manager, and merchant database in the asynchronous payment system are all available, the transaction manager records the relevant information of the payment request in the remote log so that the relevant data can be read from the remote log for recovery during disaster recovery.

[0193] Then, the transaction manager calls the user resource manager to complete the deduction from the user account. During this process, if the number of connections used by payment requests for the same merchant account in the user resource manager exceeds the first connection threshold, or the number of connections used exceeds the first connection pool threshold, rate limiting is applied to pending payment requests and subsequent newly received payment requests for the same merchant account. This means processing is delayed, and the merchant account is added to the rate-limiting list. In this way, high-concurrency requests (receipt requests) can be smoothed out in the user resource manager initially, reducing the request volume at the next level and alleviating operational pressure.

[0194] The process of deducting funds from a user's account is as follows. Because the payment request carries information such as the user's account information, the merchant's account information, and the transfer amount, the user resource manager can retrieve the relevant user account data from the user database based on the user account information in the payment request. Then, the transfer amount is deducted from the user's account balance, generating a user account transaction record and a transaction slip. The transaction slip helps prevent duplicate transaction records; therefore, locking the user account is not required when deducting funds. Finally, a successful deduction message is sent to the user's account, and a successful receipt message is sent to the merchant's system. In this way, after completing the deduction from the user's account, both the user and the merchant are notified simultaneously before proceeding with the deduction from the merchant's account, reducing notification time and improving the transfer experience for both users and merchants.

[0195] Subsequently, the transaction manager generates an invoice request carrying merchant account information based on the payment request, stores the invoice request in the asynchronous cache database and the distributed message queue respectively, and completes the subsequent payment process based on the invoice request in the distributed message queue.

[0196] The transaction manager stores payment requests in real-time to an asynchronous cache database by calling the merchant's asynchronous service. When the distributed message queue is unavailable (e.g., due to a broken link), the payment request can be read from the asynchronous cache database to complete the payment process. This effectively ensures the persistence and security of payment requests. It should be noted that if the link between the transaction manager and the merchant's asynchronous service frequently fails, payment requests will not be stored in the asynchronous cache database.

[0197] The process by which the transaction manager calls the asynchronous posting service to process posting requests in the distributed asynchronous queue can be found in [reference needed]. Figure 8 ,exist Figure 8 In the process, the asynchronous billing service determines whether the merchant account corresponding to the billing request in the distributed message queue is in the rate-limiting list. If the merchant account is not in the rate-limiting list, the merchant resource manager is called to process the billing request.

[0198] If the merchant account is in the rate-limiting list, the asynchronous billing service merges billing requests in the distributed message queue and stores the merged requests in a temporary in-memory queue. When a billing request in the temporary queue times out and the number of billing requests is less than the request threshold, the merchant account corresponding to the billing request is removed from the rate-limiting list, and the merchant resource manager is invoked to process the billing requests in the temporary queue. When the number of billing requests in the temporary queue exceeds the request threshold, the merchant resource manager is invoked to process the billing requests in the temporary queue.

[0199] As can be seen, the asynchronous billing service reduces the number of requests entering the next level of merchant resource manager at the same time by merging the billing requests corresponding to merchant accounts in the rate limiting list and storing them in a temporary queue. This is equivalent to a second peak smoothing of high-concurrency requests (billing requests), which helps to alleviate the phenomenon of concurrent lock contention and effectively relieves the pressure on operation and maintenance.

[0200] See Figure 9B , Figure 9B This is a schematic diagram illustrating the processing of an invoice request provided in an embodiment of this application. The following will be combined with... Figure 9B Steps 301 to 304 describe the process by which the Merchant Resource Manager processes the billing request.

[0201] In step 301, before processing the billing request S, the Merchant Resource Manager uses process I to collect shared memory information and checks whether the merchant account corresponding to the billing request S is being throttled.

[0202] In the Merchant Resource Manager, each process has its own dedicated shared memory, and these shared memory resources constitute the Merchant Resource Manager's shared memory. If the Merchant Resource Manager will process an invoice request S through an idle process I, then before process I processes the invoice request S, it will interact with other processes besides process I. Figure 9BThe dedicated shared memory of processes B, C, ..., N records the requests currently being processed by each process. It determines the number of connections and connection pools occupied by other incoming payment requests being processed for the merchant account corresponding to the incoming payment request S. If the number of connections exceeds the second connection threshold or the number of connection pools exceeds the second connection pool threshold, the merchant account is added to the rate limiting list, and the incoming payment requests corresponding to the merchant account are rate-limited. That is, the pending incoming payment requests corresponding to the merchant account and subsequent newly received incoming payment requests are delayed.

[0203] In step 302, if the merchant account is not subject to rate limiting, the Merchant Resource Manager writes the merchant account information into the dedicated shared memory of process I through process I.

[0204] If the number of connections used by the incoming payment request corresponding to the merchant account does not exceed the second connection threshold, and the number of connections in the connection pool used by the incoming payment request corresponding to the merchant account does not exceed the second connection pool threshold, then no rate limiting will be applied to the merchant account, and the relevant information of the merchant account (such as time, merchant account, etc.) will be written into the dedicated shared memory of process I through process I.

[0205] In step 303, the Merchant Resource Manager processes the billing request S through process I.

[0206] See Figure 11 , Figure 11 This is a schematic diagram of the page for processing invoice requests provided in an embodiment of this application. Figure 11 In the process, process number (proc_no) 20 is processing an invoice request for merchant account (UID) "101300000005000882", with request (sscmd) number "999506".

[0207] The Merchant Resource Manager processes the incoming payment request S through process I as follows: It locks the transaction number in the merchant database; it searches the merchant database for the corresponding merchant account transaction history based on the transaction number; if no transaction history is found, it adds the transfer amount to the balance of the merchant account corresponding to the incoming payment request and generates a new transaction history; finally, it unlocks the transaction number.

[0208] In step 304, the Merchant Resource Manager cleans up the dedicated shared memory of process I through process I.

[0209] After processing the payment request S, process I cleans up the relevant information of the merchant account in process I's dedicated shared memory.

[0210] In some embodiments, if the number of incoming payment requests containing preset command words corresponding to the same merchant account exceeds the command word threshold, the incoming payment requests containing preset command words corresponding to the same merchant account will also be subject to rate limiting.

[0211] In some embodiments, after the transaction is credited to the merchant's account, the status of the merchant's account corresponding to the transaction in the asynchronous cache database is changed to "credited". This completes the entire payment process.

[0212] As can be seen, in the Merchant Resource Manager, the third peak reduction of high-concurrency requests (accounting requests) is achieved through the second connection number threshold, the second connection pool number threshold, and the command word threshold. This prevents accounting requests for the same merchant account or requests containing the same command word from occupying all the processes of the Merchant Resource Manager and being unable to respond to other business requests.

[0213] The following describes an exemplary structure of the electronic payment processing device provided in the embodiments of this application. Taking the electronic payment processing device as a server as an example, based on the understanding above, the electronic payment processing device can be a server of the type described above, such as a transaction server, user server, asynchronous server, or merchant server. The following is a detailed description.

[0214] See Figure 12A , Figure 12A This is a schematic diagram of the structure of the server 400 provided in this embodiment of the application. Figure 12A The server 400 shown includes at least one processor 410, memory 440, and at least one network interface 420. The various components in server 200 are coupled together via a bus system 430. It is understood that the bus system 430 is used to implement communication between these components. In addition to a data bus, the bus system 430 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2 The general labeled all buses as Bus System 430.

[0215] The processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0216] The memory 440 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 440 may optionally include one or more storage devices physically located away from the processor 410.

[0217] Memory 440 may include volatile memory or non-volatile memory, or both. Non-volatile memory may be read-only memory (ROM), and volatile memory may be random access memory (RAM). The memory 440 described in this application embodiment is intended to include any suitable type of memory.

[0218] In some embodiments, memory 440 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0219] Operating system 441 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;

[0220] The network communication module 442 is used to reach other computing devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc.

[0221] In some embodiments, the electronic payment processing device 443 provided in this application can be implemented in software. Figure 12A An electronic payment processing device 443 stored in memory 440 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: a receiving module 4431, a deduction module 4432, a generation module 4433, a first entry module 4434, and a second entry module 4435. These modules are logically connected and can therefore be arbitrarily combined or further divided according to their implemented functions. The functions of each module will be described below.

[0222] The receiving module 4431 is used to receive at least one payment request from at least one client; the deduction module 4432 is used to perform a deduction operation on the user account corresponding to each payment request, send a deduction success message to the client, and send an account receipt success message to the merchant system corresponding to the payment request; the generation module 4433 is used to generate a corresponding account receipt request based on each payment request, and store the account receipt requests in an asynchronous cache database and a distributed message queue respectively; the first account receipt module 4434 is used to read the account receipt requests to be processed from the distributed message queue and perform an account receipt operation on the merchant account corresponding to the read account receipt request; the second account receipt module 4435 is used to continue reading the account receipt requests to be processed from the asynchronous cache database and perform an account receipt operation on the merchant account corresponding to the read account receipt request when the distributed message queue is unavailable.

[0223] In some embodiments, the electronic payment processing device further includes a rate limiting module 4436, and the status of the received payment request includes processing and pending processing; the rate limiting module 4436 is used to: when the number of connections occupied by the payment request being processed exceeds a first connection number threshold, or the number of connection pools occupied by the payment request being processed exceeds a first connection pool number threshold, to rate limit the pending payment request and add the merchant account corresponding to the pending payment request to the rate limiting list.

[0224] In some embodiments, the rate limiting module 4436 is further configured to: when the merchant accounts corresponding to multiple pending payment requests are in the rate limiting list, merge the multiple pending payment requests and store the merged payment requests in a temporary queue corresponding to the merchant account; when a payment request in any temporary queue triggers a timeout and the number of payment requests is less than the number of requests threshold, delete the merchant account corresponding to any temporary queue from the rate limiting list and perform payment operation on the merchant account corresponding to the payment request in any temporary queue.

[0225] In some embodiments, the first accounting module 4434 is further configured to: perform an accounting operation on the merchant account corresponding to the accounting request in any temporary queue when the number of accounting requests in any temporary queue is greater than the number of requests threshold.

[0226] In some embodiments, the first invoicing module 4434 is further configured to: determine the number of connections and the number of connection pools occupied by other invoicing requests based on the memory information occupied by the invoicing request being processed; wherein, the other invoicing requests are invoicing requests being processed and correspond to the same merchant account as the invoicing request to be processed; when the number of connections occupied by other invoicing requests does not exceed the second connection number threshold and the number of connection pools occupied by other invoicing requests does not exceed the second connection pool number threshold, write the merchant account information carried in the invoicing request to be processed into the memory of any idle process; and perform an invoicing operation on the merchant account based on the idle process.

[0227] In some embodiments, the rate limiting module 4436 is further configured to: when the number of connections occupied by other invoice requests exceeds the second connection number threshold, or when the number of connection pools occupied by other invoice requests exceeds the second connection pool number threshold, to perform rate limiting on the invoice requests to be processed, and to add the merchant account corresponding to the invoice requests to be processed to the rate limiting list.

[0228] In some embodiments, the rate limiting module 4436 is further configured to: determine the number of pending invoice requests containing a preset command word; when the number of pending invoice requests containing a preset command word exceeds the command word threshold, rate limiting is applied to the pending invoice requests containing the preset command word, and the merchant account corresponding to the pending invoice request containing the preset command word is added to the rate limiting list.

[0229] In some embodiments, the deduction module 4432 is further configured to: query the corresponding user account from the user database based on each payment request; deduct the transfer amount carried in the payment request from the balance of the queried user account and generate a user account transaction record; and generate a transaction order based on the user account transaction record.

[0230] In some embodiments, the first payment module 4434 is further configured to: lock the order number of the transaction order in the merchant database; search for the merchant account transaction record corresponding to the read payment request in the merchant database based on the order number; when no merchant account transaction record is found, add the transfer amount from the balance of the merchant account corresponding to the read payment request and generate the merchant account transaction record; and unlock the order number of the transaction order.

[0231] In some embodiments, the first payment module 4434 is further configured to: verify the transaction corresponding to each payment request based on the merchant account transaction history and the user account transaction history, so as to determine that the deduction from the user account is correct and the payment to the merchant account is correct in each transaction.

[0232] In some embodiments, the receiving module 4431 is further configured to: store relevant information of the payment request in a log so as to perform recovery processing based on the log when the asynchronous cache database, user database or merchant database is unavailable.

[0233] In some embodiments, the first payment module 4434 is further configured to: change the status of the merchant account in the asynchronous cache database from pending payment to paid.

[0234] It should be noted that, for the electronic payment processing device in this application embodiment, all of the above modules can be implemented, and some modules can be implemented in a targeted manner according to the actual deployment situation to realize the roles of transaction server, user server, asynchronous server or merchant server.

[0235] For example, when an electronic payment processing device implements a receiving module and a generating module, it acts as a transaction server; when it implements a deduction module, it acts as a user server; and when it implements a first invoice module and a second invoice module, it acts as an asynchronous server and a merchant server.

[0236] Of course, depending on the specific application scenario, the server may only implement the functional modules for any one of the following servers: transaction server, user server, asynchronous server, or merchant server.

[0237] See Figure 12B , Figure 12B This is a schematic diagram of the structure of the terminal 500 provided in the embodiments of this application. Taking the terminal 500 as an example, which is the processing device for electronic payment, Figure 12B The terminal 500 shown includes at least one processor 510, a memory 550, at least one network interface 520, and a user interface 530. The various components in the terminal 500 are coupled together via a bus system 540. The user interface 530 includes one or more output devices 531 capable of presenting media content, and also includes one or more input devices 532.

[0238] In some embodiments, the memory includes an operating system 551, a network communication module 552, a presentation module 553, and an input processing module 554. The electronic payment processing device 555 provided in this application embodiment can be implemented in software. Figure 12BAn electronic payment processing device 555 stored in a memory 550 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: a first display module 5551 and a second display module 5552. These modules are logically linked and can therefore be arbitrarily combined or further separated according to their implemented functions. Of course, the electronic payment processing device 555 provided in this embodiment can also be implemented in hardware, which will not be elaborated upon here.

[0239] The following continues to describe an exemplary structure of the electronic payment processing apparatus 555 provided in the embodiments of this application, implemented as a software module. In some embodiments, such as Figure 12B As shown, the software modules stored in the electronic payment processing device 555 in the memory 550 may include: a first display module 5551 and a second display module 5552.

[0240] The first display module 5551 is used to display a page for electronic payment on the client; the second display module 5552 is used to respond to receiving an electronic payment operation for the merchant system on the page, send a payment request for the merchant system, and display a successful deduction message in real time; wherein, the successful deduction message is sent by the backend server after performing a deduction operation on the user account corresponding to the payment request, and the crediting operation for the merchant account of the merchant system is performed based on an asynchronous cache database and a distributed message queue.

[0241] It should be noted that for any technical details not covered in the electronic payment processing device 555 provided in this application embodiment, please refer to... Figures 3 to 9B The meaning is understood in accordance with the description of any of the accompanying drawings.

[0242] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the electronic payment processing method described above in this application.

[0243] This application provides a computer-readable storage medium storing executable instructions, wherein the executable instructions, when executed by a processor, will cause the processor to execute the electronic payment processing method provided in this application.

[0244] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EP ROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0245] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0246] As an example, executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0247] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0248] In summary, this embodiment of the application sends notifications to both the user's client and the merchant system simultaneously after deducting funds from the user's account, reducing notification latency and improving the transfer experience for both users and merchants. Storing the payment request in a distributed message queue reduces contention during high concurrency. Simultaneously, storing the payment request in an asynchronous cache database effectively ensures the persistence and security of related data, allowing the payment process to be completed using the data stored in the asynchronous cache database when the distributed message queue is unavailable. Dynamic rate limiting of high-concurrency requests through the user resource manager, asynchronous payment service, and merchant resource manager improves the performance of the asynchronous payment system without scaling up the merchant server, maximizing the throughput of the asynchronous payment system, ensuring payment stability for key merchants during peak periods, and significantly reducing operational pressure.

[0249] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method for processing electronic payments, characterized in that, include: Receive at least one payment request from at least one client; Perform a deduction operation on the user account corresponding to each payment request, send a deduction success message to the client, and send an account receipt success message to the merchant system corresponding to the payment request; A corresponding invoice request is generated based on each payment request, and the invoice requests are stored in an asynchronous cache database and a distributed message queue, respectively. Read pending payment requests from the distributed message queue and perform payment operations on the merchant accounts corresponding to the read payment requests; When the distributed message queue is unavailable, the system continues to read pending payment requests from the asynchronous cache database and performs payment operations on the merchant accounts corresponding to the read payment requests.

2. The method according to claim 1, characterized in that, The status of received payment requests includes "processing" and "pending". Before performing the deduction operation on the user account corresponding to each payment request, the method further includes: When the number of connections occupied by a payment request being processed exceeds the first connection threshold, or when the number of connection pools occupied by a payment request being processed exceeds the first connection pool threshold, the payment requests to be processed will be rate-limited, and the merchant account corresponding to the payment requests to be processed will be added to the rate-limiting list.

3. The method according to claim 2, characterized in that, After reading the pending invoice requests from the distributed message queue, the method further includes: When multiple pending payment requests correspond to merchant accounts in the rate limiting list, the multiple pending payment requests are merged and the merged payment requests are stored in a temporary queue corresponding to the merchant account. When an invoice request in any temporary queue times out and the number of invoice requests is less than the request count threshold, the merchant account corresponding to any temporary queue is removed from the rate limiting list, and an invoice operation is performed on the merchant account corresponding to the invoice request in any temporary queue.

4. The method according to claim 3, characterized in that, After storing the incoming payment request obtained from the merged processing into a temporary queue corresponding to the merchant account, the method further includes: When the number of incoming payment requests in any temporary queue exceeds the threshold, an incoming payment operation is performed on the merchant account corresponding to the incoming payment request in any temporary queue.

5. The method according to claim 2, characterized in that, After reading the pending invoice requests from the distributed message queue, the method further includes: Based on the memory usage of the incoming billing requests being processed, determine the number of connections and connection pool size used by other incoming billing requests; Among them, the other incoming payment requests are incoming payment requests that are being processed and correspond to the same merchant account as the incoming payment requests that are pending processing; When the number of connections occupied by the other invoice requests does not exceed the second connection threshold, and the number of connection pools occupied by the other invoice requests does not exceed the second connection pool threshold, the merchant account information carried in the invoice requests to be processed is written into the memory of any idle process. The idle process performs an invoice processing operation on the merchant's account.

6. The method according to claim 5, characterized in that, After determining the number of connections and connection pool size used by other inbound requests, the method further includes: When the number of connections occupied by the other invoice requests exceeds the second connection threshold, or when the number of connection pools occupied by the other invoice requests exceeds the second connection pool threshold, the pending invoice requests are rate-limited, and the merchant accounts corresponding to the pending invoice requests are added to the rate-limiting list.

7. The method according to claim 2, characterized in that, After reading the pending invoice requests from the distributed message queue, the method further includes: Determine the number of pending posting requests containing preset command words; When the number of pending invoice requests containing preset command words exceeds the command word threshold, rate limiting is applied to the pending invoice requests containing preset command words, and the merchant account corresponding to the pending invoice requests containing preset command words is added to the rate limiting list.

8. The method according to claim 1, characterized in that, The step of performing the deduction operation on the user account corresponding to each payment request includes: For each payment request, the corresponding user account is retrieved from the user database; The transfer amount carried in the payment request is deducted from the balance of the user's account as retrieved, and a user account transaction record is generated; A transaction order is generated based on the user account transaction history.

9. The method according to claim 8, characterized in that, The step of performing the posting operation on the merchant account corresponding to the read posting request includes: Lock the order numbers of the transactions in the merchant database; Based on the order number, the merchant account transaction record corresponding to the read invoice request is searched in the merchant database; If the merchant account transaction record is not found, the transfer amount is added to the balance of the merchant account corresponding to the read inflow request, and a merchant account transaction record is generated. The transaction number is then unlocked.

10. The method according to claim 9, characterized in that, After performing the posting operation on the merchant account corresponding to the read posting request, the method further includes: The transactions corresponding to each payment request are verified based on the merchant account transaction history and the user account transaction history to ensure that the deduction from the user account and the payment to the merchant account are correct in each transaction.

11. The method according to claim 10, characterized in that, After receiving at least one payment request from at least one client, the method further includes: The relevant information of the payment request is stored in the log so that recovery processing can be performed based on the log when the asynchronous cache database, the user database, or the merchant database is unavailable. After performing the posting operation on the merchant account corresponding to the read posting request, the method further includes: Change the status of the merchant account in the asynchronous cache database from pending payment to paid payment.

12. A method for processing electronic payments, characterized in that, include: Display the page for electronic payment in the client; In response to receiving an electronic payment operation for the merchant system on the page, a payment request is sent to the merchant system, and a successful deduction message is displayed in real time; The successful deduction message is sent by the backend server after performing the deduction operation on the user account corresponding to the payment request. The crediting operation for the merchant account in the merchant system is performed based on an asynchronous cache database and a distributed message queue. Both the asynchronous cache database and the distributed message queue store crediting requests generated based on the payment request.

13. An electronic payment processing device, characterized in that, include: A receiving module for receiving at least one payment request from at least one client; The deduction module is used to perform deduction operations on the user account corresponding to each payment request, send a deduction success message to the client, and send an account receipt success message to the merchant system corresponding to the payment request. The generation module is used to generate a corresponding invoice request based on each payment request, and store the invoice requests in an asynchronous cache database and a distributed message queue respectively; The first invoicing module is used to read invoicing requests to be processed from the distributed message queue and perform invoicing operations on the merchant accounts corresponding to the read invoicing requests. The second invoicing module is used to continue reading pending invoicing requests from the asynchronous cache database and perform invoicing operations on the merchant accounts corresponding to the read invoicing requests when the distributed message queue is unavailable.

14. The apparatus according to claim 13, characterized in that, The device also includes a rate limiting module, and the status of received payment requests includes processing and pending processing; The rate limiting module is used to rate limit the pending payment requests when the number of connections occupied by the payment requests being processed exceeds the first connection threshold, or the number of connection pools occupied by the payment requests being processed exceeds the first connection pool threshold, and to add the merchant account corresponding to the pending payment requests to the rate limiting list.

15. The apparatus according to claim 14, characterized in that, The rate limiting module is also used to merge the multiple incoming payment requests when the merchant accounts corresponding to the multiple incoming payment requests to be processed are in the rate limiting list, and to store the merged incoming payment requests into a temporary queue corresponding to the merchant account. When an invoice request in any temporary queue times out and the number of invoice requests is less than the request count threshold, the merchant account corresponding to any temporary queue is removed from the rate limiting list, and an invoice operation is performed on the merchant account corresponding to the invoice request in any temporary queue.

16. An electronic device, characterized in that, include: Memory, used to store executable instructions; A processor, when executing executable instructions stored in the memory, implements the electronic payment processing method according to any one of claims 1 to 11 or claim 12.

17. A computer-readable storage medium, characterized in that, It stores executable instructions for causing a processor to perform the electronic payment processing method as described in any one of claims 1 to 11 or claim 12.

18. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the electronic payment processing method according to any one of claims 1 to 11 or claim 12.

Images