Method, device and equipment for realizing non-intrusive transaction limit and medium
By responding to transaction events in a microserver and using database triggers to update transaction limits, the problem of code redundancy in different payment channels is solved, achieving non-intrusive transaction limit management, simplifying business logic and ensuring data consistency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-10
- Publication Date
- 2026-03-27
AI Technical Summary
Existing technologies require writing identical code in microservices across different payment channels, leading to redundancy and intrusion in business code.
By responding to transaction events through a microserver, inserting transaction tables into the database, and using triggers to monitor transaction table insertion events, the daily cumulative amount and number of transactions are updated. Based on transaction status change events, the amount and number of transactions are rolled back, thus achieving non-intrusive transaction limits.
It enables unified management of transaction limits across multiple payment channels, eliminating the need to repeatedly write the same logic in business code, simplifying business logic and ensuring data consistency.
Smart Images
Figure CN121745941A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of financial technology, and in particular to a method, apparatus, device, and medium for implementing non-intrusive transaction limits. Background Technology
[0002] The bank payment system is divided into a gateway module, a routing module, a channel business processing module, and a batch processing module. The various services communicate with each other using the Dubbo RPC protocol.
[0003] The payment service integrates with multiple payment channels, such as UnionPay, SuperNet, and 2D. Each channel sets up its own microservice project to complete the corresponding functions, including receiving requests from the routing layer, generating transaction logs, calling the channel's payment service, and updating transaction status. For asynchronous transactions, each microservice queries the final state of the transaction through scheduled tasks.
[0004] To achieve the requirement of tracking daily transaction limits and automatically shutting down corresponding services when transaction amounts exceed the limit, Redis is typically used in a distributed architecture to temporarily store the cumulative amount of each successful transaction. However, since the payment channel functions in this architecture are implemented in different microservices, using Redis technology would require writing identical code in each microservice, resulting in completely repetitive and redundant code across different channels. Summary of the Invention
[0005] This invention provides a method, apparatus, device, and medium for implementing non-intrusive transaction limits, which solves the technical problem that existing technologies require writing identical code in microservices across different channels, and that intrusion into business code occurs.
[0006] According to one aspect of the present invention, a method for implementing non-intrusive transaction limits is provided, comprising: In response to transaction events from various payment channels, insert the corresponding transaction table into the database. When a transaction table insertion event is detected in the database, the daily cumulative amount and daily cumulative number of transactions in the database are updated based on the data in the transaction table; If the transaction status in the transaction table is checked from each payment channel, and a change to transaction failure is detected in the transaction table, the daily cumulative amount and the daily cumulative number of transactions are rolled back based on the transaction status change event.
[0007] Optionally, when a transaction table insertion event is detected in the database, the daily cumulative amount and daily cumulative number of transactions in the database are updated based on the data in the transaction table, and then the process further includes: Check whether the daily cumulative amount has reached the limit, and whether the daily cumulative number of transactions has reached the limit. If the daily cumulative amount reaches the limit, or the daily cumulative number of transactions reaches the limit, the merchant permission table will be updated to close the current merchant's payment authorization.
[0008] Optionally, when querying the transaction status in the transaction table from each payment channel, if a change in the transaction status to transaction failure is detected, the daily cumulative amount and the daily cumulative number of transactions are rolled back based on the transaction status change event, and the process further includes: Verify whether the daily cumulative amount after the rollback is less than the limit, and whether the daily cumulative number of transactions is less than the limit. If the daily cumulative amount is less than the limit and the daily cumulative number of transactions is also less than the limit, then the merchant permission table will be updated and the current merchant's payment authorization will be reactivated.
[0009] Optionally, it also includes: Create a scheduled task in the database, which includes updating the merchant permission table at 0:00 every day to enable payment authorization for each merchant.
[0010] Optionally, before inserting the corresponding transaction table into the database in response to a transaction event from each payment channel, the method further includes: Construct a daily cumulative amount table based on merchants in the database. The daily cumulative amount table includes at least the merchant number, date, daily cumulative amount, and daily cumulative number of transactions.
[0011] According to another aspect of the present invention, an apparatus for implementing non-intrusive transaction limits is provided, comprising a microserver, the microserver being configured to insert a transaction table corresponding to a transaction event into a database in response to a transaction event of each payment channel; When a transaction table insertion event is detected in the database, the daily cumulative amount and daily cumulative number of transactions in the database are updated based on the data in the transaction table; If the transaction status in the transaction table is checked from each payment channel, and a change to transaction failure is detected in the transaction table, the daily cumulative amount and the daily cumulative number of transactions are rolled back based on the transaction status change event.
[0012] Optionally, the microserver is also used to verify whether the daily cumulative amount has reached the limit and whether the daily cumulative number of transactions has reached the limit. If the daily cumulative amount reaches the limit, or the daily cumulative number of transactions reaches the limit, the merchant permission table will be updated to close the current merchant's payment authorization.
[0013] Optionally, the microserver is also used to verify whether the daily cumulative amount after rollback is less than the limit, and whether the daily cumulative number of transactions is less than the limit. If the daily cumulative amount is less than the limit and the daily cumulative number of transactions is also less than the limit, then the merchant permission table will be updated and the current merchant's payment authorization will be reactivated.
[0014] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the method for implementing non-intrusive transaction limits as described in any embodiment of the present invention.
[0015] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the method for implementing non-intrusive transaction limits as described in any embodiment of the present invention.
[0016] The technical solution of this invention uses a microserver to respond to transaction events of each payment channel, inserts the corresponding transaction table into the database, and uses triggers to monitor whether a transaction table insertion event has occurred in the database. If it has, the daily cumulative amount and daily cumulative number of transactions in the database are updated based on the data in the transaction table. The daily cumulative amount and daily cumulative number of transactions are then rolled back according to the transaction status change event. This allows a single microserver to update and roll back information for transaction events occurring in multiple payment channels. Furthermore, this transaction limit method is implemented using database coding, which does not intrude on the business code.
[0017] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description
[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0019] Figure 1 This is a flowchart of a method for implementing non-intrusive transaction limits according to Embodiment 1 of the present invention; Figure 2This is a flowchart of a method for implementing non-intrusive transaction limits according to Embodiment 2 of the present invention; Figure 3 This is an architectural diagram of a device for implementing non-intrusive transaction limits according to Embodiment 3 of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device that implements the method for achieving non-intrusive transaction limits according to embodiments of the present invention. Detailed Implementation
[0020] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.
[0021] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0022] Example 1 Figure 1 The flowchart illustrates a method for implementing non-intrusive transaction limits according to Embodiment 1 of the present invention. Figure 1 As shown, the method includes: S101. In response to transaction events from each payment channel, insert the corresponding transaction table into the database.
[0023] The payment channels include UnionPay, NetsUnion, and G20. When a merchant initiates a payment transaction, the routing layer responds to the merchant's request, calculates the optimal payment channel, sends the payment instruction to the payment channel, and generates a transaction table. The microserver receives the transaction tables from each payment channel and inserts them into the database. The transaction table can be a transaction log table, including merchant ID, channel type, single transaction amount, transaction date, and transaction status.
[0024] It should be noted that this embodiment uses a microserver to connect to multiple payment channels to track and process merchant transaction limits. The business logic is implemented in each payment channel, while the tracking and processing of transaction limits for multiple merchants is implemented in the microserver, thus achieving decoupling from the business logic.
[0025] S102. When a transaction table insertion event is detected in the database, the daily cumulative amount and daily cumulative number of transactions in the database are updated based on the data in the transaction table.
[0026] In this embodiment, a trigger can be set in the database to monitor the insertion events of the transaction table in the database. Based on the monitoring of the transaction table insertion events, the daily cumulative amount and daily cumulative number of transactions of the corresponding merchant can be updated.
[0027] For example, by listening for transaction table insert events through Oracle triggers, the daily cumulative amount and number of transactions can be automatically updated without the need for business code intervention. The real-time update of the daily cumulative amount and number of transactions can be completed through database layer coding, which ensures data consistency and simplifies business logic.
[0028] It should be noted that in this embodiment, a daily cumulative control table can be created in the database for tracking and processing merchant transaction limits. The daily cumulative control table includes fields such as merchant number, date, daily cumulative amount, and daily cumulative number of transactions, which are used to count the daily cumulative transaction amount and cumulative number of transactions for different merchants.
[0029] S103. Query the transaction status in the transaction table from each payment channel. If the transaction status in the transaction table is detected to have changed to transaction failure, roll back the daily cumulative amount and the daily cumulative number of transactions based on the transaction status change event.
[0030] It should be noted that this embodiment can also include a trigger to periodically query the transaction status field in the transaction table obtained from each payment channel. If a change in the transaction status field is detected, the daily cumulative amount and daily cumulative number of transactions need to be rolled back. The transaction status can include "transaction successful" and "transaction failed." When a transaction status change to "transaction failed," the daily cumulative amount and daily cumulative number of transactions in the daily cumulative control table need to be rolled back to the data before the last update.
[0031] The technical solution of this invention uses a microserver to respond to transaction events of each payment channel, inserts the corresponding transaction table into the database, and uses triggers to monitor whether a transaction table insertion event has occurred in the database. If it has, the daily cumulative amount and daily cumulative number of transactions in the database are updated based on the data in the transaction table. The daily cumulative amount and daily cumulative number of transactions are then rolled back according to the transaction status change event. This allows a single microserver to update and roll back information for transaction events occurring in multiple payment channels. Furthermore, this transaction limit method is implemented using database coding, which does not intrude on the business code.
[0032] Example 2 Figure 2 This is a flowchart illustrating a method for implementing non-intrusive transaction limits according to Embodiment 2 of the present invention. Figure 2 As shown, the method includes: S201. Construct a daily cumulative amount table based on merchants in the database. The daily cumulative amount table shall include at least the merchant number, date, daily cumulative amount, and daily cumulative number of transactions.
[0033] To track the transaction limits of each merchant, this embodiment first uses a dedicated microserver to connect to multiple payment channels to track and process the merchant's transaction limits. Furthermore, a daily cumulative control table is created in the microserver's database for tracking merchant transaction limits. This table includes fields such as merchant ID, date, daily cumulative amount, and daily cumulative number of transactions, used to calculate the daily cumulative transaction amount and cumulative number of transactions for different merchants.
[0034] S202. In response to transaction events of each payment channel, insert the corresponding transaction table into the database.
[0035] The payment channels include UnionPay, NetsUnion, and second-generation payment gateways. When a merchant initiates a payment transaction, the routing layer responds to the merchant's request, calculates the optimal payment channel, sends the payment instruction to the payment channel, and generates a transaction table. The microserver receives the transaction tables from each payment channel and inserts them into the database. The transaction table can be a transaction log table, including merchant ID, channel type, single transaction amount, transaction date, and transaction status.
[0036] Because the business code in the provincial power system is implemented in each payment channel, while the transaction limit tracking and processing for multiple merchants is implemented in the micro server, decoupling from the business code is achieved.
[0037] S203. When a transaction table insertion event is detected in the database, the daily cumulative amount and daily cumulative number of transactions in the database are updated based on the data in the transaction table.
[0038] In this embodiment, an Oracle trigger can be used to listen for transaction table insertion events and automatically update the daily cumulative amount and number of transactions. Specifically, the daily cumulative amount is accumulated based on the amount of the current transaction in the transaction table, and the daily cumulative number of transactions is incremented by one. This method requires no business code intervention; the real-time update of the daily cumulative amount and number of transactions can be achieved through database layer coding, ensuring data consistency while simplifying business logic.
[0039] S204. Check whether the daily cumulative amount has reached the limit and whether the daily cumulative number of transactions has reached the limit.
[0040] S205. If the daily cumulative amount reaches the limit, or the daily cumulative number of transactions reaches the limit, then update the merchant permission table to close the current merchant's payment authorization.
[0041] In the trigger of the insertion event in the monitoring transaction table, after accumulating the daily cumulative amount and the daily cumulative number of transactions, it can be checked whether either the daily cumulative amount or the daily cumulative number of transactions exceeds the merchant's configured limit. Specifically, it checks whether the daily cumulative amount has reached the limit and whether the daily cumulative number of transactions has reached the limit. If so, the merchant permission table is updated, and the current merchant's payment on behalf permission is disabled. The permission table includes a field for displaying whether the user's current payment on behalf permission is enabled or disabled. When the current merchant's payment on behalf permission is disabled, the merchant can no longer process payments through the payment on behalf channel.
[0042] S206. Query the transaction status in the transaction table from each payment channel. If the transaction status in the transaction table is detected to have changed to transaction failure, roll back the daily cumulative amount and the daily cumulative number of transactions based on the transaction status change event.
[0043] In this embodiment, an Oracle trigger can also be set to periodically query the transaction status field in the transaction table obtained from each payment channel. If a change in the transaction status field is detected, the daily cumulative amount and daily cumulative number of transactions need to be rolled back. The transaction status can include transaction normal and transaction failed. When a transaction status change to transaction failed is detected, the daily cumulative amount and daily cumulative number of transactions in the daily cumulative control table need to be rolled back to the data before the last update.
[0044] S207. Verify whether the daily cumulative amount after the rollback is less than the limit, and whether the daily cumulative number of transactions is less than the limit.
[0045] S208. If the daily cumulative amount is less than the limit and the daily cumulative number of transactions is also less than the limit, then update the merchant permission table and re-enable the current merchant's payment authorization.
[0046] In the update event trigger of the monitoring transaction table, after rolling back the daily cumulative amount and daily cumulative number of transactions, it is possible to check whether either the daily cumulative amount or the daily cumulative number of transactions exceeds the merchant's configured limit. That is, check whether the daily cumulative amount has reached the limit and whether the daily cumulative number of transactions has reached the limit. If so, update the merchant permission table and reopen the current merchant's payment permission.
[0047] S209. Create a scheduled task in the database, wherein the scheduled task includes updating the merchant permission table at 0:00 every day to enable payment authorization for each merchant.
[0048] It should be noted that at the end of the day, the daily cumulative amount and the daily cumulative number of transactions need to be reset to zero to begin tracking payment restrictions for the next day. In this embodiment, a scheduled task is created in the database. This scheduled task includes updating the merchant permission table at 0:00 every day to enable payment restrictions for each merchant, allowing the microserver to track payment restrictions for merchants daily.
[0049] In embodiments of the present invention, a microserver responds to transaction events from each payment channel, inserts the corresponding transaction table into the database, and uses triggers to monitor whether a transaction table insertion event has occurred in the database. If it has, the daily cumulative amount and daily cumulative number of transactions in the database are updated based on the data in the transaction table. The daily cumulative amount and daily cumulative number of transactions are then rolled back according to the transaction status change event. This allows a single microserver to update and roll back information for transaction events occurring in multiple payment channels. Furthermore, this transaction limit method is implemented using database coding, which does not intrude on the business code.
[0050] Example 3 Figure 3 This is a schematic diagram of a device for implementing non-intrusive transaction limits according to Embodiment 3 of the present invention. Figure 3 As shown, the device includes a microserver, which is used to insert the corresponding transaction table into the database in response to transaction events of each payment channel. When a transaction table insertion event is detected in the database, the daily cumulative amount and daily cumulative number of transactions in the database are updated based on the data in the transaction table; If the transaction status in the transaction table is checked from each payment channel, and a change to transaction failure is detected in the transaction table, the daily cumulative amount and the daily cumulative number of transactions are rolled back based on the transaction status change event.
[0051] Additionally, it should be noted that the system also includes a routing layer and various payment channels. The routing layer is used to respond to payment transactions issued by merchants, calculate the optimal payment channel, and send the payment instruction to the corresponding payment channel. After receiving the payment instruction, the payment channel will initiate a transaction and generate a transaction table.
[0052] In one embodiment, the microserver is further configured to verify whether the daily cumulative amount has reached the limit and whether the daily cumulative number of transactions has reached the limit. If the daily cumulative amount reaches the limit, or the daily cumulative number of transactions reaches the limit, the merchant permission table will be updated to close the current merchant's payment authorization.
[0053] In one embodiment, the microserver is also used to verify whether the daily cumulative amount after rollback is less than the limit, and whether the daily cumulative number of transactions is less than the limit. If the daily cumulative amount is less than the limit and the daily cumulative number of transactions is also less than the limit, then the merchant permission table will be updated and the current merchant's payment authorization will be reactivated.
[0054] The apparatus for implementing non-intrusive transaction limits provided in the embodiments of the present invention can execute the apparatus for implementing non-intrusive transaction limits provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.
[0055] Example 4 Figure 4 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.
[0056] like Figure 4As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.
[0057] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.
[0058] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as a method for implementing non-intrusive transaction limits.
[0059] In some embodiments, a method for implementing non-intrusive transaction limits may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the method for implementing non-intrusive transaction limits described above may be performed. Alternatively, in other embodiments, processor 11 may be configured by any other suitable means (e.g., by means of firmware) to perform a method for implementing non-intrusive transaction limits.
[0060] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0061] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0062] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.
[0063] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).
[0064] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.
[0065] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.
[0066] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.
[0067] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.
Claims
1. A method for implementing non-intrusive transaction limits, characterized in that, include: In response to transaction events from various payment channels, insert the corresponding transaction table into the database. When a transaction table insertion event is detected in the database, the daily cumulative amount and daily cumulative number of transactions in the database are updated based on the data in the transaction table; If the transaction status in the transaction table is checked from each payment channel, and a change to transaction failure is detected in the transaction table, the daily cumulative amount and the daily cumulative number of transactions are rolled back based on the transaction status change event.
2. The method for implementing non-intrusive transaction limits according to claim 1, characterized in that, When a transaction table insertion event is detected in the database, the daily cumulative amount and daily cumulative number of transactions in the database are updated based on the data in the transaction table. This process also includes: Check whether the daily cumulative amount has reached the limit, and whether the daily cumulative number of transactions has reached the limit. If the daily cumulative amount reaches the limit, or the daily cumulative number of transactions reaches the limit, the merchant permission table will be updated to close the current merchant's payment authorization.
3. The method for implementing non-intrusive transaction limits according to claim 2, characterized in that, When querying the transaction status from each payment channel, if a transaction status change to "transaction failed" is detected, the daily cumulative amount and the daily cumulative number of transactions are rolled back based on the transaction status change event. This process then includes: Verify whether the daily cumulative amount after the rollback is less than the limit, and whether the daily cumulative number of transactions is less than the limit. If the daily cumulative amount is less than the limit and the daily cumulative number of transactions is also less than the limit, then the merchant permission table will be updated and the current merchant's payment authorization will be reactivated.
4. The method for implementing non-intrusive transaction limits according to claim 1, characterized in that, Also includes: Create a scheduled task in the database, which includes updating the merchant permission table at 0:00 every day to enable payment authorization for each merchant.
5. The method for implementing non-intrusive transaction limits according to claim 1, characterized in that, Before inserting the corresponding transaction table into the database in response to transaction events from each payment channel, the process also includes: Construct a daily cumulative amount table based on merchants in the database. The daily cumulative amount table includes at least the merchant number, date, daily cumulative amount, and daily cumulative number of transactions.
6. A device for implementing non-intrusive transaction limits, characterized in that, Includes a microserver, which is used to respond to transaction events of each payment channel and insert the corresponding transaction table into the database; When a transaction table insertion event is detected in the database, the daily cumulative amount and daily cumulative number of transactions in the database are updated based on the data in the transaction table; If the transaction status in the transaction table is checked from each payment channel, and a change to transaction failure is detected in the transaction table, the daily cumulative amount and the daily cumulative number of transactions are rolled back based on the transaction status change event.
7. The apparatus for implementing non-intrusive transaction limits according to claim 6, characterized in that, The microserver is also used to verify whether the daily cumulative amount has reached the limit and whether the daily cumulative number of transactions has reached the limit. If the daily cumulative amount reaches the limit, or the daily cumulative number of transactions reaches the limit, the merchant permission table will be updated to close the current merchant's payment authorization.
8. The apparatus for implementing non-intrusive transaction limits according to claim 6, characterized in that, The microserver is also used to verify whether the daily cumulative amount after rollback is less than the limit, and whether the daily cumulative number of transactions is less than the limit. If the daily cumulative amount is less than the limit and the daily cumulative number of transactions is also less than the limit, then the merchant permission table will be updated and the current merchant's payment authorization will be reactivated.
9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, which enables the at least one processor to perform the method for implementing non-intrusive transaction limits as described in any one of claims 1-5.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the method for implementing non-intrusive transaction limits as described in any one of claims 1-5.