Payment system-oriented payment performance optimization method, system, equipment and medium

Abstract

The invention provides a payment system-oriented payment performance optimization method, system and device and a medium, and belongs to the technical field of computers. The method comprises the steps of advancing a security verification process in a payment system to be executed before payment scheduling through a rule engine and a BPMN-based process engine, intercepting an illegal request and dynamically selecting a payment path; distributing an independent thread pool for each bank by using a Java thread pool, obtaining a payment instruction, and distributing the payment instruction to the corresponding thread pool for parallel processing according to a bank code; a message queue architecture is adopted, a scheduling layer, a front layer and a bank docking layer of the payment system are decoupled through a multi-stage buffer process, and a timed task polling is utilized to process payment result write-back. Through security verification preposition, bank exclusive thread pool scheduling and multi-level message queue decoupling, the concurrent processing capability, the resource utilization rate and the stability of the payment system are remarkably improved, and meanwhile, the user experience is optimized.

Description

Technical Field

[0001] The present invention belongs to the field of computer technology, and more specifically relates to a payment performance optimization method, system, device and medium for a payment system. Background Art

[0002] With the booming development of e-commerce and internet finance, payment volume has seen explosive growth. Consumers are frequently shopping on various e-commerce platforms, and online financial transactions are becoming increasingly active, posing unprecedented challenges to payment systems with high concurrency. Against this backdrop, traditional payment system architectures and data processing methods are gradually exposing numerous flaws when handling large-scale, simultaneous payment requests from users, severely impacting user experience and payment efficiency.

[0003] In traditional payment systems, security verification processes are typically executed sequentially during the payment scheduling process, using a serial processing approach. This serial processing model results in a lengthy payment process. In high-concurrency scenarios, a large number of payment requests accumulate, significantly increasing system response latency. Users must wait for payment results for extended periods, and transactions may even time out and fail. Furthermore, because the security verification process cannot proactively intercept illegal requests, some of these requests will be passed through to subsequent payment processes, wasting system resources and further reducing system performance.

[0004] Furthermore, traditional payment systems often use single-threaded or simple multi-threaded processing when processing payment instructions, without providing differentiated processing for different banks. When faced with high-concurrency payment scenarios, the system is prone to problems such as thread resource contention and task backlogs, which can even cause system crashes, seriously impacting the stability and reliability of the payment system.

[0005] Furthermore, traditional payment systems are highly coupled between layers. The scheduling layer, front-end layer, and bank interface layer interact directly with each other, lacking effective buffering and isolation mechanisms. This tightly coupled architecture makes the system inflexible and fault-tolerant in the face of traffic surges or bank interface failures.

[0006] Traditional payment systems typically use a synchronous approach to writing back payment results. This means that after a payment is completed, the system immediately waits for the bank to return the payment result and writes it back. However, the response time of the bank interface is uncertain. In high-concurrency scenarios, a large number of payment requests simultaneously waiting for the bank to return the results can cause system resources to be occupied for a long time, reducing overall system throughput and even causing confusion in the payment instruction status, affecting subsequent business processing.

[0007] In summary, traditional payment systems face numerous challenges when handling highly concurrent payment requests, including response delays, transaction failures, system crashes, low resource utilization, high coupling, and inefficient payment result writeback. Therefore, effectively improving the concurrent processing capabilities of payment systems, optimizing payment processes, and enhancing system stability and reliability have become pressing challenges in the current payment technology landscape. Summary of the Invention

[0008] In response to the above problems, the purpose of the present invention is to provide a payment performance optimization method, system, device and medium for payment systems. Through pre-security verification, bank-specific thread pool scheduling and multi-level message queue decoupling, the concurrent processing capability, resource utilization and stability of the payment system are significantly improved, while optimizing the user experience.

[0009] To achieve the above-mentioned purpose, the present invention is implemented through the following technical solutions: In a first aspect, an embodiment of the present application provides a payment performance optimization method for a payment system, comprising: Through the rule engine and BPMN-based process engine, the security verification process in the payment system is advanced to execution before payment scheduling, intercepting illegal requests and dynamically selecting payment paths; Use the Java thread pool to allocate an independent thread pool for each bank, obtain payment instructions and distribute them to the corresponding thread pool for parallel processing according to the bank code; Adopting a message queue architecture, the scheduling layer, front-end layer and bank docking layer of the payment system are decoupled through a multi-stage buffering process, and payment result write-back is processed through scheduled task polling.

[0010] In an optional embodiment, the security verification process in the payment system is advanced to be executed before payment scheduling by using a rule engine and a BPMN-based process engine, including: Disassemble the payment system's serial payment process and identify security verification steps that can be executed in parallel or in advance; the security verification steps include user identity verification, account status check, and credit limit verification; Utilize a BPMN-based process engine to manage payment process nodes in a configurable manner, and advance the security verification process to execution before payment scheduling.

[0011] In an optional embodiment, the security verification process in the payment system is advanced to be executed before payment scheduling by using a rule engine and a BPMN-based process engine, including: Disassemble the payment system's serial payment process and identify security verification steps that can be executed in parallel or in advance; the security verification steps include user identity verification, account status check, and credit limit verification; Utilize a BPMN-based process engine to manage payment process nodes in a configurable manner, and advance the security verification process to execution before payment scheduling.

[0012] In an optional embodiment, the method of using a Java thread pool to allocate an independent thread pool for each bank, obtaining payment instructions and distributing the payment instructions to the corresponding thread pool for parallel processing according to the bank code includes: Use Java's ThreadPoolExecutor to allocate an independent thread pool for each bank; Obtain payment instructions, store them in the database, and mark their status as pending instructions; The scheduler parses the bank code in the payment instruction, matches the corresponding independent thread pool according to the bank code, and creates a bank thread group mapping table; Distribute payment instructions to the task queue of an independent thread pool; Pull batches of pending instructions from the database through an independent thread pool, and call the bank-enterprise direct connection interface to execute payments; After the payment is completed, the instruction status is updated to the database, and an asynchronous notification is triggered through the message queue to inform the business system for subsequent processing.

[0013] In an optional embodiment, the method of allocating an independent thread pool to each bank using a Java thread pool, obtaining payment instructions and distributing the payment instructions to corresponding thread pools for parallel processing according to bank codes further includes: The number of threads is dynamically adjusted in real time based on indicators such as the bank's payment request volume and response latency through a custom thread management component. For high-concurrency banks, multiple threads are enabled for parallel processing when resources permit. Monitor the status of each independent thread pool and automatically pause the independent thread pool when it is detected that the number of bank connection failures exceeds the threshold.

[0014] In an optional embodiment, the message queue architecture is used to decouple the scheduling layer, front-end layer, and bank connection layer of the payment system through a multi-stage buffering process, including: Build message queues MQ1 and MQ2 through ActiveMQ or RocketMQ; The scheduling layer and the front-end layer communicate via MQ1, and the front-end layer and the bank docking layer communicate via MQ2, thus achieving decoupling of each module. The multi-stage buffering process includes: The scheduling module regularly retrieves payment instructions to be sent from the database, assembles them into payment messages, and writes them into MQ1.

[0015] The bank-enterprise direct connection front-end system monitors MQ1 to obtain payment messages and transfers the payment messages to MQ2. The anti-duplicate check module consumes MQ2 regularly, stores the payment message in the database and performs anti-duplicate check by querying the bank-enterprise direct connection database. After passing the anti-duplicate check, it is sent to the corresponding bank interface to execute the payment operation.

[0016] In an optional embodiment, the process of using a scheduled task polling to process payment result writeback includes: The verification module periodically calls the bank interface to query the bank payment results; Write the bank payment result into the temporary payment result table, recording the original response data and timestamp; Extract the bank payment results from the temporary payment result table, write them into MQ2, and trigger the anti-duplicate module to perform verification; After verification, the bank payment result is written into MQ1 and sent back to the scheduling module; The scheduling module marks the corresponding payment instruction in the database as a processed instruction.

[0017] In a second aspect, the embodiments of the present application further provide a payment performance optimization system for a payment system, comprising: The payment request pre-processing module is used to advance the security verification process in the payment system to before payment scheduling through the rule engine and the BPMN-based process engine, intercept illegal requests and dynamically select the payment path; A multi-threaded payment instruction processing module, which uses the Java thread pool to allocate an independent thread pool for each bank, obtains payment instructions, and distributes them to the corresponding thread pool for parallel processing based on the bank code; The asynchronous payment result notification module adopts a message queue architecture to decouple the scheduling layer, front-end layer, and bank docking layer of the payment system through a multi-stage buffering process, and uses scheduled task polling to process payment result writeback.

[0018] In a third aspect, an embodiment of the present application further provides an electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein when the processor executes the program, the steps of the payment performance optimization method for a payment system as described in any one of the above items are implemented.

[0019] In a fourth aspect, an embodiment of the present application further provides a storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps of the payment performance optimization method for a payment system as described in any one of the above items are implemented.

[0020] It can be seen from the above technical solutions that the present invention has the following advantages: The payment performance optimization method for the payment system provided in this application intercepts illegal requests and dynamically selects routes through pre-security verification, combines the elastic scheduling of the bank's exclusive thread pool with the decoupling of multi-level message queues, and significantly optimizes the resource utilization and fault tolerance of the payment link. At the same time, an asynchronous result write-back mechanism is used to reduce system coupling, ultimately achieving a synergistic optimization effect of improved payment efficiency, enhanced system stability, and improved user experience in high-concurrency scenarios.

[0021] This application leverages a rules engine and BPMN process engine to pre-empt security steps like user identity verification, account status checks, and credit limit verification before payment scheduling, enabling early interception of illegal requests and dynamic selection of payment paths. This design effectively reduces the resource usage of invalid requests on subsequent payment processes, avoiding process rollbacks due to security verification failures. Furthermore, a dynamic routing mechanism directs legitimate requests to the optimal payment channel, significantly improving system resource utilization and transaction success rates.

[0022] This application allocates a separate thread pool for each bank and distributes payment instructions based on bank codes, enabling fine-grained parallel processing of payment tasks. This mechanism avoids the resource contention inherent in traditional single-thread pool architectures. Specifically for high-concurrency banks, dynamic thread count adjustment (e.g., scaling based on real-time request volume) maximizes CPU and network resource utilization. Furthermore, thread pool status monitoring and automatic isolation of faulty banks effectively prevent the spread of single-point failures, ensuring overall system stability.

[0023] This application uses ActiveMQ / RocketMQ to build a dual-buffered queue (MQ1+MQ2) across the scheduling layer, front-end layer, and bank layer, achieving complete decoupling between modules. The scheduling layer asynchronously pushes payment messages to the front-end layer via MQ1. The front-end layer then forwards the messages to the bank interface via MQ2 after anti-duplicate checks. This multi-stage buffering design not only smooths the impact of traffic peaks on the bank system but also reduces direct dependencies between modules through asynchronous communication. If a bank interface anomalies occur, messages are persistently stored in the queue and automatically retried after the fault is resolved, significantly improving the system's fault tolerance.

[0024] This application uses a custom thread management component to monitor bank payment request volume, response latency, and other metrics in real time, enabling automatic and elastic scaling of the number of threads (e.g., multi-threaded parallel processing in high-concurrency scenarios). Furthermore, a mechanism is established to detect a threshold for bank connection failures. Upon detecting an anomaly, the corresponding thread pool is automatically paused, preventing the faulty bank from continuously consuming system resources. This adaptive scheduling strategy, combined with a circuit breaker mechanism, ensures payment priority for core banks while minimizing the risk of system overload.

[0025] This application uses a scheduled task to poll the bank interface for payment results, and employs a dual-security mechanism of "temporary table storage + anti-duplicate verification" to achieve asynchronous result writeback and data consistency. The payment result is first written to a temporary table and timestamped. After verification by the anti-duplicate module, it is transmitted back to the scheduling layer via MQ, ultimately updating the payment instruction status. This design avoids thread blocking caused by synchronously waiting for bank responses, while also eliminating the risk of duplicate payments through anti-duplicate checks, effectively improving system throughput while ensuring result accuracy. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the technical solution of the present invention, the following is a brief introduction to the drawings required for the description. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0027] Figure 1 A flow chart of the payment performance optimization method for a payment system provided in this application.

[0028] Figure 2 A schematic diagram of the structure of the payment performance optimization system for the payment system provided in this application.

[0029] Figure 3 This is a schematic diagram of the structure of the electronic device provided in this application. DETAILED DESCRIPTION

[0030] The various embodiments of the present disclosure will be described more fully below in detail in the specific steps of the payment performance optimization method for a payment system. The present disclosure can have various embodiments, and adjustments and changes can be made therein. However, it should be understood that there is no intention to limit the various embodiments of the present disclosure to the specific embodiments disclosed herein, and that the present disclosure should be construed to encompass all adjustments, equivalents, and / or alternatives falling within the spirit and scope of the various embodiments of the present disclosure.

[0031] Hereinafter, the terms "include" or "may include" as used in various embodiments of the present disclosure indicate the presence of disclosed functions, operations, or elements, and do not limit the addition of one or more functions, operations, or elements. In addition, as used in various embodiments of the present disclosure, the terms "include," "have," and their cognates are intended only to indicate specific features, numbers, steps, operations, elements, components, or combinations of the foregoing, and should not be understood as excluding the presence of one or more other features, numbers, steps, operations, elements, components, or combinations of the foregoing, or the possibility of adding one or more features, numbers, steps, operations, elements, components, or combinations of the foregoing.

[0032] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0033] See also Figure 1 FIG. 1 is a flow chart of a payment performance optimization method for a payment system in a specific embodiment. The method includes: S1: Through the rule engine and BPMN-based process engine, the security verification process in the payment system is advanced to be executed before payment scheduling, intercepting illegal requests and dynamically selecting the payment path.

[0034] In the specific implementation, a rules engine is first deployed in the security verification phase to identify and intercept illegal requests, repeated submissions, and risky transactions. A BPMN-based process engine is then used to configure the payment scheduling process, dynamically selecting different payment paths based on bank characteristics, payment type, and amount range. Then, a rules engine is deployed in the security verification phase to identify and intercept illegal requests, repeated submissions, and risky transactions. Finally, a BPMN-based process engine is used to configure the payment scheduling process, dynamically selecting different payment paths based on bank characteristics, payment type, and amount range.

[0035] For example, a rules engine (such as Drools) is deployed in the payment system's front-end risk control module to perform real-time identity authentication, limit verification, and risk identification for user-initiated payment requests. Pre-set rules (such as those for illegal IP access, abnormal transaction frequency, and abnormal account status) are used to intercept illegal requests, duplicate submissions, and risky transactions, reducing the number of invalid requests entering the core payment process. Simultaneously, a lightweight process engine based on BPMN (Business Process Model and Markup Language) is introduced to define payment process nodes in a configurable manner. Multiple payment routing templates are pre-created based on bank interface specifications (such as message formats and response mechanisms of different banks), payment types (such as quick payments and cross-border payments), and amount ranges (such as small payments ≤ 1,000 yuan and large payments > 10,000 yuan). Once a legitimate request passes pre-checks, the process engine automatically parses the bank code, payment type, and amount information in the request to dynamically match the optimal routing. For example, large payments automatically trigger a manual review node while small payments are directly routed to the bank's express channel, achieving intelligent scheduling and resource optimization of the payment process.

[0036] S2: Use the Java thread pool to allocate an independent thread pool for each bank, obtain payment instructions, and distribute the payment instructions to the corresponding thread pool according to the bank code for parallel processing.

[0037] In a specific implementation, firstly, Java's ThreadPoolExecutor is used to allocate an independent thread pool for each bank; then, the payment instruction is obtained, stored in the database, and its status is marked as a pending instruction.

[0038] At this time, the bank code in the payment instruction is parsed by the scheduler, the corresponding independent thread pool is matched according to the bank code, and a bank thread group mapping table is created; the payment instruction is distributed to the task queue of the independent thread pool; the independent thread pool is used to batch pull the pending instructions from the database, and the bank-enterprise direct connection interface is called to execute the payment.

[0039] After the payment is completed, the instruction status is updated to the database, and an asynchronous notification is triggered through the message queue to inform the business system for subsequent processing.

[0040] At the same time, in this step, real-time health monitoring of the thread pool is also performed, including: The number of threads is dynamically adjusted in real time based on indicators such as the bank's payment request volume and response latency through a custom thread management component. For high-concurrency banks, multiple threads are enabled for parallel processing when resources permit. Monitor the status of each independent thread pool and automatically pause the independent thread pool when it is detected that the number of bank connection failures exceeds the threshold.

[0041] For example, Java's ThreadPoolExecutor is first used to create a separate thread pool for each bank (for example, ThreadGroup-A for China Merchants Bank and ThreadGroup-B for Agricultural Bank of China). A bank code-thread pool mapping table is established and stored in the system configuration center. After a payment instruction passes pre-processing risk control, the system stores the instruction information (including bank code, payment amount, payee and payee, etc.) in the database payment task table and marks the status as "pending." A scheduler (such as a SpringTask scheduled task) periodically scans the database, parses the bank code of the pending instruction, and dispatches the instruction to the task queue of the corresponding thread pool based on the mapping table. The worker threads in the thread pool batch-retrieve instructions (50-100 at a time) using a database cursor and call the bank's payment service through the bank-enterprise direct connection interface. This process uses a 3-second timeout and a two-try mechanism. Once the payment is completed, the thread immediately updates the instruction status in the database ("success" or "failure") and triggers an asynchronous notification via the message queue. At the same time, the system monitors the thread pool status in real time through a custom thread management component: it dynamically adjusts the number of threads (the number of core threads is scalable from 5 to 20) based on the bank's request volume and response delay, and automatically increases thread parallel processing for high-concurrency banks; if the number of connection failures of a bank exceeds the threshold (such as 5 times in a row), the corresponding thread pool is automatically paused and an alarm is triggered, supporting manual start and stop intervention by operation and maintenance personnel.

[0042] S3: Adopts a message queue architecture and decouples the scheduling layer, front-end layer, and bank docking layer of the payment system through a multi-stage buffering process. It uses scheduled task polling to process payment result writeback.

[0043] In a specific implementation, message queues MQ1 and MQ2 are constructed through ActiveMQ or RocketMQ; MQ1 is used for communication between the scheduling layer and the front-end layer, and MQ2 is used for communication between the front-end layer and the bank docking layer, thereby achieving decoupling of each module.

[0044] The multi-stage buffering process includes: The scheduling module regularly retrieves payment instructions to be sent from the database, assembles them into payment messages, and writes them into MQ1.

[0045] The bank-enterprise direct connection front-end system monitors MQ1 to obtain payment messages and transfers the payment messages to MQ2. The anti-duplicate check module consumes MQ2 regularly, stores the payment message in the database and performs anti-duplicate check by querying the bank-enterprise direct connection database. After passing the anti-duplicate check, it is sent to the corresponding bank interface to execute the payment operation.

[0046] When processing payment result writeback, the verification module first periodically calls the bank interface to query the bank payment results. The bank payment results are then written to a temporary payment result table, recording the original response data and timestamp. The bank payment results are then extracted from the temporary payment result table and written to MQ2, triggering the anti-duplicate module to perform verification. Once verification is successful, the bank payment results are written to MQ1 and returned to the dispatch module. Finally, the dispatch module marks the corresponding payment instruction in the database as processed.

[0047] For example, a two-tier message queue architecture is constructed using ActiveMQ or RocketMQ: MQ1 is used for communication between the scheduling layer and the front-end layer, and MQ2 is used for interaction between the front-end layer and the bank interface layer. During the instruction sending phase, the scheduling module (such as a Quartz scheduled task) extracts 100 pending instructions from the main database's "Pending Instructions Table" every 10 seconds, assembles them into bank-compatible XML / JSON messages, and writes them to MQ1. The bank-enterprise direct connection front-end system listens to MQ1, consumes messages in real time, and performs format validation (such as XML Schema validation and digital signature checking) before transferring them to MQ2. The anti-duplicate check module periodically pulls messages from MQ2 every 5 seconds, queries the bank-enterprise direct connection database for anti-duplicate validation based on the "instruction ID + bank code." If a message passes, it is written to the "Pending Instructions Table" and sent via the bank's dedicated line. During the result transmission phase, the verification module polls the bank's interface for query results every 15 seconds, writing the raw response data to the front-end system's "temporary payment result table." The front-end system extracts the results from the temporary table and transmits them back to the anti-duplicate module via MQ2 for consistency verification. Once verified, the results are transmitted back to the dispatch module via MQ1, which updates the main database instruction status to "processed." If MQ is interrupted, the system retrieves the results by scanning the temporary table. This multi-stage buffering mechanism of "dual MQ + temporary table" decouples system modules and ensures data reliability, improving stability and responsiveness in high-concurrency scenarios.

[0048] In this embodiment, by integrating machine learning algorithms and automated process optimization technologies, intelligent decision-making on resource allocation is achieved, significantly improving operational efficiency; the use of distributed computing architecture and real-time data monitoring systems effectively reduces system latency and enhances abnormal response capabilities; combining edge computing with dynamic load balancing technology effectively reduces energy consumption while ensuring data security; ultimately, through multi-technology collaborative innovation, the comprehensive beneficial effects of cost reduction and efficiency improvement, quality control, improved user experience, and sustainable system expansion are achieved, providing a replicable technical paradigm for the industry's digital transformation.

[0049] like Figure 2 As shown, the following is an embodiment of the payment performance optimization system for a payment system provided by an embodiment of the present disclosure. This system and the payment performance optimization method for a payment system in the above-mentioned embodiments belong to the same inventive concept. For details not fully described in the embodiment of the payment performance optimization system for a payment system, please refer to the embodiment of the payment performance optimization method for a payment system.

[0050] A payment performance optimization system for a payment system includes a payment request pre-processing module, a multi-threaded payment instruction processing module, and an asynchronous payment result notification module.

[0051] The payment request pre-processing module is used to advance the security verification process in the payment system to before payment scheduling through the rule engine and the BPMN-based process engine, intercept illegal requests and dynamically select the payment path.

[0052] The multi-threaded payment instruction processing module is used to use the Java thread pool to allocate an independent thread pool for each bank, obtain payment instructions, and distribute the payment instructions to the corresponding thread pool for parallel processing according to the bank code.

[0053] The asynchronous payment result notification module adopts a message queue architecture to decouple the scheduling layer, front-end layer, and bank docking layer of the payment system through a multi-stage buffering process, and uses scheduled task polling to process payment result writeback.

[0054] The payment performance optimization system for payment systems provided in this embodiment significantly improves execution efficiency and resource utilization by integrating innovative technologies and optimized processes, while reducing operating costs and human error. Its precise data analysis and real-time feedback mechanism enhance scientific decision-making and ensure high-quality and reliable results. Furthermore, its modular design provides the system with flexible adaptability, enabling rapid response to changing needs and substantially improving user experience. Overall, this system demonstrates significant value in improving overall performance, promoting sustainable development, and enhancing competitive advantage.

[0055] Figure 3 A schematic diagram of the hardware structure of an electronic device for implementing various embodiments of the present invention.

[0056] The payment performance optimization method for a payment system provided in the embodiments of the present application can be applied to electronic devices. Those skilled in the art will understand that the electronic device structure involved in the embodiments of the present invention does not constitute a limitation on the electronic device, and the electronic device may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently. In the embodiments of the present invention, the electronic device includes but is not limited to a laptop computer, a desktop computer, a workbench, a personal digital assistant, a server, a blade server, a mainframe computer, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smart phones, wearable devices and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of the present application described and / or required herein.

[0057] The electronic device may include a processor, an external memory interface, an internal memory, a universal serial bus (USB) interface, a charging management module, a power management module, a battery, a wireless communication module, an audio module, a speaker, a microphone, a sensor module, a button, a camera, a display, and a SIM card interface, etc.

[0058] A processor may include one or more processing units, such as a central processing unit (CPU), an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors.

[0059] The processor can be the nerve center and command center of the electronic device. The controller can generate operation control signals based on the instruction opcode and timing signal to complete the control of instruction fetching and execution.

[0060] The processor may also include a memory for storing instructions and data. In some embodiments, the memory in the processor is a cache memory. This memory can store instructions or data that the processor has just used or is reusing. If the processor needs to use the instruction or data again, it can directly call it from the memory. This avoids repeated accesses, reduces processor latency, and thus improves system efficiency.

[0061] The external memory interface can be used to connect an external memory card, such as a MicroSD card, to expand the storage capacity of an electronic device. The external memory card communicates with the processor through the external memory interface, enabling data storage. For example, files such as music and videos can be stored on the external memory card.

[0062] Internal memory can be used to store computer-executable program code, which includes instructions. The processor executes the instructions stored in the internal memory to perform various functional applications and data processing of the electronic device. The internal memory can include a program storage area and a data storage area. The internal memory can include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0063] The wireless communication function of an electronic device can be implemented through an antenna, a wireless communication module, a modem processor, and a baseband processor.

[0064] Wireless communication modules can provide wireless communication solutions for electronic devices, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared technology (IR), etc.

[0065] Electronic devices can implement audio functions through audio modules, speakers, receivers, microphones, headphone jacks, and application processors.

[0066] Electronic devices can achieve shooting functions through ISP, camera, video codec, GPU, display and application processor.

[0067] Electronic devices can achieve display functions through GPU, display screen and application processor.

[0068] A GPU is a microprocessor for image processing that connects the display screen to the application processor. The GPU performs mathematical and geometric calculations for graphics rendering. A processor may include one or more GPUs, which execute program instructions to generate or modify display information.

[0069] The display screen is used to display images, videos, etc. The display screen includes a display panel.

[0070] The above-mentioned electronic device realizes the payment performance optimization method for the payment system of this application by integrating innovative technologies and optimization processes, significantly improving execution efficiency and resource utilization; through precise data analysis and real-time feedback mechanism, it enhances the scientific nature of decision-making and the high quality of results; through modular design, it achieves flexible adaptation, quickly responds to changes in demand and reduces operating costs; and ultimately achieves the comprehensive beneficial effects of reducing costs, increasing efficiency, improving quality and substantially improving user experience.

[0071] The storage medium provided in this application stores a program product that can implement a payment performance optimization method for a payment system.

[0072] Payment performance optimization methods for payment systems include: Through the rule engine and BPMN-based process engine, the security verification process in the payment system is advanced to execution before payment scheduling, intercepting illegal requests and dynamically selecting payment paths; Use the Java thread pool to allocate an independent thread pool for each bank, obtain payment instructions and distribute them to the corresponding thread pool for parallel processing according to the bank code; Adopting a message queue architecture, the scheduling layer, front-end layer and bank docking layer of the payment system are decoupled through a multi-stage buffering process, and payment result write-back is processed through scheduled task polling. In some possible implementations, the payment performance optimization method for a payment system disclosed herein can be implemented in the form of a program product, which includes program code. When the program product is run on a terminal device, the program code is used to enable the terminal device to execute the steps described in the above "Exemplary Method" section of this specification according to various exemplary implementations of the present disclosure.

[0073] The storage medium of the present disclosure can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but not limited to, a system, device or component of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0074] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention is not limited to the embodiments shown herein but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A payment performance optimization method for a payment system, characterized in that: include: Through the rule engine and BPMN-based process engine, the security verification process in the payment system is advanced to execution before payment scheduling, intercepting illegal requests and dynamically selecting payment paths; Use the Java thread pool to allocate an independent thread pool for each bank, obtain payment instructions and distribute them to the corresponding thread pool for parallel processing according to the bank code; Adopting a message queue architecture, the scheduling layer, front-end layer and bank docking layer of the payment system are decoupled through a multi-stage buffering process, and payment result write-back is processed through scheduled task polling.

2. The payment performance optimization method for a payment system according to claim 1, characterized in that: The security verification process in the payment system is advanced to execution before payment scheduling through the rule engine and the BPMN-based process engine, including: Disassemble the payment system's serial payment process and identify security verification steps that can be executed in parallel or in advance; the security verification steps include user identity verification, account status check, and credit limit verification; Utilize a BPMN-based process engine to manage payment process nodes in a configurable manner, and advance the security verification process to execution before payment scheduling.

3. The payment performance optimization method for a payment system according to claim 2, characterized in that: The interception of illegal requests and dynamic selection of payment paths include: By deploying a rule engine in the security verification process, illegal requests, repeated submissions, and risky transactions can be identified and intercepted; Use the BPMN-based process engine to configure the payment scheduling process and dynamically select different payment paths based on bank characteristics, payment type, and amount range.

4. The payment performance optimization method for a payment system according to claim 3, characterized in that: The Java thread pool is used to allocate an independent thread pool for each bank, obtain payment instructions, and distribute the payment instructions to the corresponding thread pool for parallel processing according to the bank code, including: Use Java's ThreadPoolExecutor to allocate an independent thread pool for each bank; Obtain payment instructions, store them in the database, and mark their status as pending instructions; The scheduler parses the bank code in the payment instruction, matches the corresponding independent thread pool according to the bank code, and creates a bank thread group mapping table; Distribute payment instructions to the task queue of an independent thread pool; Pull batches of pending instructions from the database through an independent thread pool, and call the bank-enterprise direct connection interface to execute payments; After the payment is completed, the instruction status is updated to the database, and an asynchronous notification is triggered through the message queue to inform the business system for subsequent processing.

5. The payment performance optimization method for a payment system according to claim 4, characterized in that: The method of allocating an independent thread pool to each bank using the Java thread pool, obtaining payment instructions and distributing the payment instructions to the corresponding thread pool for parallel processing according to the bank code, further includes: The number of threads is dynamically adjusted in real time based on indicators such as the bank's payment request volume and response latency through a custom thread management component. For high-concurrency banks, multiple threads are enabled for parallel processing when resources permit. Monitor the status of each independent thread pool and automatically pause the independent thread pool when it is detected that the number of bank connection failures exceeds the threshold.

6. The payment performance optimization method for a payment system according to claim 5, characterized in that: The message queue architecture is used to decouple the payment system's scheduling layer, front-end layer, and bank docking layer through a multi-stage buffering process, including: Build message queues MQ1 and MQ2 through ActiveMQ or RocketMQ; The scheduling layer and the front-end layer communicate via MQ1, and the front-end layer and the bank docking layer communicate via MQ2, thus achieving decoupling of each module. The multi-stage buffering process includes: The scheduling module regularly retrieves payment instructions to be sent from the database, assembles them into payment messages, and writes them into MQ1. The bank-enterprise direct connection front-end system monitors MQ1 to obtain payment messages and transfers the payment messages to MQ2. The anti-duplicate check module consumes MQ2 regularly, stores the payment message in the database and performs anti-duplicate check by querying the bank-enterprise direct connection database. After passing the anti-duplicate check, it is sent to the corresponding bank interface to execute the payment operation.

7. The payment performance optimization method for a payment system according to claim 6, characterized in that: The method of using scheduled task polling to process payment result write-back includes: The verification module periodically calls the bank interface to query the bank payment results; Write the bank payment result into the temporary payment result table, recording the original response data and timestamp; Extract the bank payment results from the temporary payment result table, write them into MQ2, and trigger the anti-duplicate module to perform verification; After verification, the bank payment result is written into MQ1 and sent back to the scheduling module; The scheduling module marks the corresponding payment instruction in the database as a processed instruction.

8. A payment performance optimization system for a payment system, characterized in that: The system adopts the payment performance optimization method for a payment system as claimed in any one of claims 1 to 7; The system comprises: The payment request pre-processing module is used to advance the security verification process in the payment system to before payment scheduling through the rule engine and the BPMN-based process engine, intercept illegal requests and dynamically select the payment path; A multi-threaded payment instruction processing module, which uses the Java thread pool to allocate an independent thread pool for each bank, obtains payment instructions, and distributes them to the corresponding thread pool for parallel processing based on the bank code; The asynchronous payment result notification module adopts a message queue architecture to decouple the scheduling layer, front-end layer, and bank docking layer of the payment system through a multi-stage buffering process, and uses scheduled task polling to process payment result writeback.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the steps of the payment performance optimization method for a payment system as described in any one of claims 1 to 7 are implemented.

10. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the payment performance optimization method for a payment system as claimed in any one of claims 1 to 7 are implemented.

Images