Transaction verification method, program product, electronic equipment and storage medium

Abstract

The invention provides a transaction verification method, a program product, electronic equipment and a storage medium, and the method comprises the steps: receiving a transaction request, and obtaining a timestamp of the transaction request; determining a request failure timestamp according to the timestamp of the transaction request, and adding the request failure timestamp into the transaction request; matching a predefined interception rule with a method corresponding to the transaction request to obtain a matching result; the interception rule is used for matching a method needing time sequence detection; under the condition that the matching result represents matching, the transaction request is sent to the transaction party according to the request failure timestamp and the current time; after the request failure timestamp is reached, a verification request is sent to the transaction party, and transaction verification information sent by the transaction party is received; the verification request is used for acquiring the transaction state of the transaction request. The refined flow management effectively improves the problem of sequential disorder of verification requests in the prior art, and improves the accuracy of verification information.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a transaction verification method, a program product, an electronic device and a storage medium. Background Art

[0002] With the rapid development of financial technology, the stability and security of the payment system, as an important part of the financial infrastructure, are of vital importance. The payment system must not only handle a large number of transaction requests, but also ensure that each transaction can be completed safely and reliably. Traffic control is an important part of the payment system, but existing technologies mainly rely on load balancing, current limiting and other mechanisms, which can only achieve coarse-grained traffic control and cannot effectively handle the problem of disordered timing of transaction requests and verification requests. Summary of the invention

[0003] The purpose of the embodiments of the present application is to provide a transaction verification method, program product, electronic device and storage medium, which are used to improve the problem of effectively processing the disorder of transaction request and verification request timing and improve the accuracy of transaction verification.

[0004] In a first aspect, an embodiment of the present application provides a transaction verification method, including: receiving a transaction request and obtaining a timestamp of the transaction request; determining a request expiration timestamp based on the timestamp of the transaction request, and adding the request expiration timestamp to the transaction request; the request expiration timestamp is used to determine whether the transaction request has timed out; matching a method corresponding to the transaction request using a predefined interception rule to obtain a matching result; the interception rule is used to match a method that requires timing detection; when the matching result indicates a match, sending the transaction request to the transaction party based on the request expiration timestamp and the current time; sending a verification request to the transaction party after reaching the request expiration timestamp, and receiving transaction verification information sent by the transaction party; the verification request is used to obtain the transaction status of the transaction request.

[0005] In the above implementation process, by determining the request expiration timestamp of the transaction request, the transaction request can be processed within the predetermined time. This helps to improve the timeliness of the transaction request and avoid transaction failures caused by processing delays. Using pre-defined interception rules, the system can accurately identify transaction requests that require timing detection. More refined traffic management effectively improves the problem of timing disorder of verification requests in the prior art and improves the accuracy of verification information.

[0006] Optionally, in an embodiment of the present application, determining a request expiration timestamp based on a timestamp of a transaction request includes: obtaining a target transaction channel corresponding to the transaction request; based on the target transaction channel, obtaining a processing duration corresponding to the target transaction channel; and adding the processing duration to the timestamp of the transaction request to obtain a request expiration timestamp.

[0007] In the above implementation process, by determining the processing time corresponding to the target transaction channel and then obtaining the request expiration timestamp, the processing time of the transaction request can be managed more effectively, the occurrence of timeout transactions can be reduced, and the success rate of transactions can be improved. The processing time of different payment channels is also taken into account to improve the user experience.

[0008] Optionally, in an embodiment of the present application, the interception rule includes a pointcut expression, and a pre-defined interception rule is used to match the method corresponding to the transaction request to obtain a matching result, including: defining a pointcut expression using the Spring AOP expression language in the Spring framework; the pointcut expression includes at least one of a matching method name, a matching method label, a matching return type, a matching annotation, and a matching class name; the pointcut expression is used to match the method corresponding to the transaction request to obtain a matching result; the matching result indicates whether the transaction request matches the method defined in the interception rule that requires timing detection.

[0009] In the above implementation process, by using Spring AOP expression language in the Spring framework to define the pointcut expression, it is possible to intercept and process specific method calls without modifying the business logic code. For example, transaction requests that require timing detection are intercepted to implement timing detection of transaction requests and ensure the consistency and reliability of transactions.

[0010] Optionally, in an embodiment of the present application, when the matching result indicates that the match is passed, the transaction request is sent to the transaction party based on the request expiration timestamp and the current time, including: when the matching result indicates that the match is passed, determining whether the current time is later than the request expiration timestamp; if the current time is later than the request expiration timestamp, discarding the transaction request; if the current time is not later than the request expiration timestamp, sending the transaction request to the transaction party.

[0011] In the above implementation process, by judging whether the current time is later than the request expiration timestamp, the transaction request is timed and detected without modifying the business logic code, thus ensuring the timeliness and effectiveness of the transaction and improving the system stability and user experience.

[0012] Optionally, in an embodiment of the present application, after receiving the transaction verification information sent by the transaction party, the method also includes: if the transaction verification information indicates that the transaction status of the transaction request is that the transaction does not exist, then polling the verification interface according to preset rules through an asynchronous task, and recording the transaction verification information obtained each time the verification interface is called.

[0013] In the above implementation process, by using asynchronous tasks to poll the verification interface according to preset rules and record the transaction verification information obtained by each call to the verification interface, the system can automatically and continuously verify the status of the transaction until the transaction is confirmed or the polling limit condition is reached. This method improves the performance of the payment system, ensures the eventual consistency of the transaction, and reduces the impact on the main business process through asynchronous processing.

[0014] Optionally, in an embodiment of the present application, a verification interface is polled according to preset rules through an asynchronous task, and transaction verification information obtained each time the verification interface is called is recorded, including: generating a polling task based on a transaction request and a verification interface; sending the polling task to a message queue; asynchronously pulling the polling task from the message queue through a back-end server, executing the call of the verification interface according to preset rules, and recording the transaction verification information obtained each time the verification interface is called.

[0015] In the above implementation process, by sending the generated polling tasks to the predefined message queue and executing the polling tasks, the system can efficiently and reliably handle a large number of polling tasks, ensure the accuracy and timeliness of the transaction status, while maintaining the responsiveness and scalability of the system.

[0016] Optionally, in the embodiment of the present application, the method further includes: the preset rule includes at least one of a preset time period, a number of polling times and a polling interval time.

[0017] In the above implementation process, the use of resources can be effectively controlled through preset rules to avoid excessive pressure on system resources due to frequent polling; and through reasonable polling interval and number settings, the system can still maintain stable verification operations and improve overall reliability.

[0018] In the second aspect, the embodiment of the present application also provides a transaction verification device, including: a request acceptance module, used to receive a transaction request and obtain a timestamp of the transaction request; an expiration time determination module, used to determine a request expiration timestamp based on the timestamp of the transaction request, and add the request expiration timestamp to the transaction request; the request expiration timestamp is used to determine whether the transaction request has timed out; a matching module, used to match a method corresponding to the transaction request using a predefined interception rule to obtain a matching result; the interception rule is used to match a method that requires timing detection; a request sending module, used to send the transaction request to the transaction party according to the request expiration timestamp and the current time when the matching result indicates a match; a verification module, used to send a verification request to the transaction party after reaching the request expiration timestamp, and receive transaction verification information sent by the transaction party; the verification request is used to obtain the transaction status of the transaction request.

[0019] In a third aspect, an embodiment of the present application further provides a computer program product, including computer program instructions, which, when executed by a processor, execute the method provided by the first aspect or any one of the implementations of the first aspect.

[0020] In a fourth aspect, an embodiment of the present application further provides an electronic device, comprising: a processor and a memory, the memory storing computer program instructions, and the computer program instructions, when executed by the processor, execute the method provided by the first aspect or any one of the implementations of the first aspect.

[0021] In a fifth aspect, an embodiment of the present application further provides a computer-readable storage medium, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the method provided by the first aspect or any one of the implementations of the first aspect is executed.

[0022] The present application provides a transaction verification method, a program product, an electronic device, and a storage medium, which can process a transaction request within a predetermined time by determining the request expiration timestamp of the transaction request. This helps to improve the timeliness of the transaction request and avoid transaction failures caused by processing delays. Using predefined interception rules, the system can accurately identify transaction requests that require timing detection, and more refined traffic management effectively improves the problem of timing disorder of verification requests in the prior art and improves the accuracy of verification information. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0024] Figure 1 A flowchart of a transaction verification method provided in an embodiment of the present application;

[0025] Figure 2 A schematic diagram of the structure of a transaction verification device provided in an embodiment of the present application;

[0026] Figure 3 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0027] The following embodiments of the technical solution of the present application are described in detail in conjunction with the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present application, and are therefore only used as examples, and cannot be used to limit the scope of protection of the present application.

[0028] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by technicians in the technical field to which this application belongs; the terms used herein are only for the purpose of describing specific embodiments and are not intended to limit this application.

[0029] In the description of the embodiments of the present application, the technical terms "first", "second", etc. are only used to distinguish different objects, and cannot be understood as indicating or implying relative importance or implicitly indicating the number, specific order or primary and secondary relationship of the indicated technical features. In the description of the embodiments of the present application, the meaning of "multiple" is two or more, unless otherwise clearly and specifically defined.

[0030] In the payment system, there is an abnormal traffic that needs special attention, that is, the timing disorder of transaction requests and verification requests. This abnormal scenario will cause the transaction verification result to be inconsistent with the transaction request status. There are many reasons for this problem, such as thread pseudo-death in stand-alone deployment mode, node failure restart, network fluctuation, or in cluster deployment mode, transaction requests are assigned to faulty nodes, while verification requests are assigned to healthy nodes, and the tomcat connection pool is full, transaction requests are suspended by the queue of cluster A-node, verification requests are sent by B-node first, etc., which not only affects the user experience, but also leads to economic losses and security risks.

[0031] For example, in a stand-alone deployment mode, the thread of the transaction request is suspended, but the thread of the verification request is normal, so the original transaction information cannot be found during verification; or the node fails and restarts, the transaction request is lost, and the original transaction information cannot be found during verification; or the network fluctuates when requesting a third-party transaction party, and the transaction information cannot be found during verification.

[0032] In cluster deployment mode (the problems in stand-alone mode still occur in cluster mode): some problems may occur. In cluster deployment, transaction requests are assigned to faulty nodes, and query requests are assigned to healthy nodes. Therefore, transaction requests cannot be sent to the transaction party, and verification cannot find transaction information. Or if the tomcat connection pool is full, the transaction request is suspended by the queue of cluster A-node, and the verification request is sent by B-node first, then the timing disorder scenario will cause the transaction verification result to be no such transaction, and the transaction request will be recorded as failed.

[0033] It can be seen that through load balancing, current limiting and other methods, only coarse-grained flow control can be achieved, and the above-mentioned timing disorder problem cannot be perceived and processed, that is, it cannot meet the payment system's demand for refined management of flow. The transaction request may be issued at a certain time in scenarios such as the thread's suspended animation or the recovery of the faulty node. At that time, the transaction party successfully processes the transaction, which will directly lead to inconsistency between the transaction and the accounting result status.

[0034] The embodiments of the present application provide a transaction verification method, a program product, an electronic device, and a storage medium, which can process a transaction request within a predetermined time by determining the request expiration timestamp of the transaction request. This helps to improve the timeliness of the transaction request and avoid transaction failures caused by processing delays. Using predefined interception rules, the system can accurately identify transaction requests that require timing detection, and more refined traffic management effectively improves the problem of timing disorder of verification requests in the prior art and improves the accuracy of verification information.

[0035] See also Figure 1 A flow chart of a transaction verification method provided by an embodiment of the present application is shown. The transaction verification method provided by an embodiment of the present application can be applied to an electronic device, which may include a physical device such as a server, a PC, a tablet computer or a smart phone, or a virtual device such as a virtual machine or a container. The electronic device may be a single device, or a combination of multiple devices or a cluster of a large number of devices. Among them, a payment system is configured or installed in the electronic device, and the payment system can ensure the security of the transaction and provide the function of transaction records. Users can query and monitor their own transaction history. At the same time, the payment system will also record all transaction activities, such as transaction requests initiated by users to transaction parties. The payment system is also used to query the transaction verification information corresponding to the transaction request. The transaction verification method may include:

[0036] Step S110: receiving a transaction request and obtaining a timestamp of the transaction request.

[0037] Step S120: Determine a request expiration timestamp according to the timestamp of the transaction request, and add the request expiration timestamp to the transaction request; the request expiration timestamp is used to determine whether the transaction request has timed out.

[0038] Step S130: Use predefined interception rules to match the method corresponding to the transaction request to obtain a matching result; the interception rule is used to match the method that requires timing detection.

[0039] Step S140: When the matching result indicates a match, the transaction request is sent to the transaction party according to the request expiration timestamp and the current time.

[0040] Step S150: after reaching the request expiration timestamp, a verification request is sent to the transaction party, and the transaction verification information sent by the transaction party is received; the verification request is used to obtain the transaction status of the transaction request.

[0041] In step S110, a transaction request is an instruction initiated by a user of a payment system to request the payment system to execute a specific transaction. A transaction request generally includes the following information: transaction amount, payment method, transaction party (i.e., transaction recipient or payee) and / or target transaction channel corresponding to the transaction request.

[0042] The timestamp of the transaction request can be automatically generated by the server. For example, when the payment system receives the transaction request, a timestamp is automatically generated. The timestamp of the transaction request can be generated on the client side and sent to the server together with the transaction request. The server directly receives the timestamp of the transaction request. Alternatively, the timestamp can be automatically recorded in the database. For example, when the transaction request is stored in the database, the database can automatically generate a timestamp for each record.

[0043] The timestamp of a transaction request records the precise time when the transaction request was submitted, which is crucial for transactions that need to be processed in a specific time sequence. By comparing the timestamp of a transaction request with the current time, the system can determine whether the transaction has exceeded the scheduled processing time. This helps identify and process transactions that have not been completed in a timely manner due to various reasons (such as system delays, network problems, etc.).

[0044] In step S120, a method for determining a request expiration timestamp based on the timestamp of the transaction request is, for example, to predetermine a maximum processing time. When a transaction request is received, the system obtains the current timestamp and adds it to the maximum processing time to calculate the request expiration timestamp. This timestamp indicates the latest time point for processing the transaction request, so the request expiration timestamp is used to determine whether the transaction request has timed out. For example, if the transaction request is still not sent to the transaction party after the request expiration timestamp due to a network problem, then the transaction request is considered to have timed out.

[0045] After determining the request expiration timestamp, add a field to store the request expiration timestamp in the transaction request data structure. This field will be processed and stored together with the transaction request. When the transaction request is transmitted and processed in the system, the expiration timestamp will be recorded and transmitted together. In this way, the system component that processes the transaction request can access the request expiration timestamp to determine whether the request has timed out.

[0046] In step S130, a series of interception rules are defined in the AOP configuration of the payment system. These interception rules can be expressions, which are used to match specific methods in the transaction request processing process, such as methods that require timing detection. Since the payment system will obtain a variety of transaction requests or other requests, these interception rules will intercept the transaction requests that require timing detection.

[0047] After receiving a transaction request, the AOP framework checks whether the processing method of the transaction request matches the defined interception rules. If the request processing method matches the interception rules, the AOP framework will execute the relevant aspect logic, such as before advice (@Before), after advice (@After), or around advice (@Around). Before advice (@Before) is a kind of advice that runs before the request processing method is executed. In the payment system, before advice can be used to record the start time of the transaction request, set or determine the expiration timestamp of the request, and add it to the transaction request. In this way, every time a transaction request starts to be processed, the system can know the validity period of the request. After advice (@After) is run after the request processing method is executed, regardless of whether the method is executed successfully or an exception is thrown. In the payment system, after advice can be used to perform some cleanup work or perform additional processing after the method is executed, such as recording the end time of the processing of the transaction request. Around advice (@Around) surrounds the execution of the request processing method and can add logic before and after the method is executed. In payment systems, around notifications can be used to control the entire life cycle of a transaction request, such as performing permission checks before method execution or verifying results after method execution.

[0048] The interception rule can be based on method signature, for example, intercepting all methods starting with "processPayment"; it can also be annotation matching, if the method is marked with a specific annotation, it means matching; it can also be matched by class name, for example, intercepting methods of all classes under a specific package path; it can also be matched by method parameter, intercepting methods with specific parameters. It can also be matched by pointcut expression, which will be introduced in detail later.

[0049] In step S140, when the AOP framework matches the corresponding transaction request processing method according to the interception rule, the matching result will be confirmed. If the matching result indicates a match, it means that the transaction request needs to be timed and detected. Before the transaction request is processed, the system will compare the current time with the request expiration timestamp. If the current time is earlier than the expiration timestamp, it means that the transaction request is still valid. Then the transaction request is sent to the transaction party. The transaction party can be a bank or other institution, for example, the transaction request is sent to the transaction party's server.

[0050] For example, the following steps can be performed to send a transaction request to the transaction party: Validate the transaction request to ensure that the transaction request contains all necessary information and meets the predetermined format and security requirements. Routing selection: Select the appropriate routing path based on the destination of the transaction request. This may involve selecting the best network path or using a specific transaction party interface. Send the request: Send the transaction request to the transaction party through the selected route. This may involve calling an external API, sending an HTTP request, or other communication mechanism. Confirm the send: After sending the transaction request, the system will wait for the transaction party's confirmation response. This may include receiving a confirmation message or status code to ensure that the transaction request has been successfully received and processed.

[0051] If the current time exceeds the request expiration timestamp, it means that the transaction request has timed out. In this case, the system will execute the predefined timeout handling strategy, which includes rejection: the system may refuse to further process the timed-out transaction request and return an error response to the request initiator. Log: The system will record the details of the timeout event, including the request ID, timestamp, expiration timestamp, and measures taken. It can also generate a warning to notify relevant personnel.

[0052] In step S150, the current time is constantly checked against the request expiration timestamp in the transaction request by monitoring the transaction expiration timestamp. When it is detected that the current time reaches or exceeds the request expiration timestamp, the system will trigger the verification process. Once the expiration timestamp is reached, the system will automatically send a verification request to the transaction party (such as a bank or a third-party payment platform). The purpose of the verification request is to verify the status of the transaction and confirm whether the transaction has been completed.

[0053] After receiving the verification request, the transaction party will return the transaction status information, such as whether the transaction is successful, whether it is cancelled, whether it is pending, etc. The payment system needs to be able to process and parse this returned information.

[0054] Based on the transaction verification information returned by the transaction party, the payment system will update the status of the transaction. If the transaction is successful, it may be necessary to update the account balance, inventory information, etc. If the transaction fails or is in a pending state, further manual intervention or automatic retry of the transaction request may be required.

[0055] In the above implementation process, by determining the request expiration timestamp of the transaction request, the transaction request can be processed within the predetermined time. This helps to improve the timeliness of the transaction request and avoid transaction failures caused by processing delays. Using pre-defined interception rules, the system can accurately identify transaction requests that require timing detection. More refined traffic management effectively improves the problem of timing disorder of verification requests in the prior art and improves the accuracy of verification information.

[0056] Optionally, in an embodiment of the present application, a request expiration timestamp is determined based on a timestamp of a transaction request, including: obtaining a target transaction channel corresponding to the transaction request; based on the target transaction channel, obtaining a processing time corresponding to the target transaction channel; and adding the processing time to the timestamp of the transaction request to obtain a request expiration timestamp.

[0057] Each transaction request may be processed through different payment channels, such as credit card gateways, third-party payment platforms (such as WeChat or Alipay), etc. The system first needs to determine which target transaction channel this transaction request will be processed through. The target transaction channel corresponding to the transaction request can be obtained based on the payment method in the transaction request, the merchant's configuration, or the routing rules of the payment system.

[0058] Different payment channels may have different processing time requirements. For example, some channels may guarantee that transactions are completed within a few minutes, while other channels may take longer. The system needs to obtain the processing time corresponding to the channel (or the maximum processing time) based on the determined target transaction channel. The processing time corresponding to the target transaction channel can be obtained from the regulations of the channel provider, the statistics of historical data processing time, or the mapping relationship pre-stored in the configuration file or database. Alternatively, the time can also be obtained dynamically by calling a service, such as obtaining it in the form of an access interface.

[0059] Determine the processing time of the target transaction channel, add this time to the timestamp of the transaction request, and calculate the request expiration timestamp. This expiration timestamp represents the deadline by which the transaction request must be processed. If the transaction request is not successfully processed before this time, the transaction request will be considered timed out.

[0060] In the implementation process of the above embodiment: by determining the processing time corresponding to the target transaction channel and then obtaining the request expiration timestamp, the processing time of the transaction request can be managed more effectively, the occurrence of timeout transactions can be reduced, and the success rate of transactions can be improved. The processing time of different payment channels is also taken into account to improve the user experience.

[0061] Optionally, in the embodiment of the present application, the interception rule includes a cut-point expression, and the predefined interception rule is used to match the method corresponding to the transaction request to obtain a matching result, including:

[0062] The Spring AOP expression language is used in the Spring framework to define a pointcut expression; the pointcut expression includes at least one of matching method name, matching method tag, matching return type, matching annotation and matching class name.

[0063] In AOP (Aspect Oriented Programming), pointcut matching is implemented using pointcut expressions, which define which methods need to be intercepted by the aspect. You can first create an aspect class and use the @Aspect annotation to annotate the class as an aspect. The aspect class will contain the pointcut definition and the advice logic. In the Spring framework, pointcut expressions can be written using the Spring AOP expression language. Aspects are usually implemented by defining a class that contains pointcuts and advice. For example, in the aspect class, use the @Pointcut annotation to define the pointcut. Pointcut expressions are written in the Spring AOP expression language to specify which methods need to be intercepted. Pointcut expressions can specify at least one of matching a specific method name, matching method tags, matching return types, matching annotations, and matching class names. Taking the method name as an example, you can use execution(String methodName(..)) to match methods whose method names match a specific pattern.

[0064] The pointcut expression is used to match the method corresponding to the transaction request to obtain a matching result; the matching result indicates whether the transaction request matches the method that needs to be time-series detected defined in the interception rule.

[0065] The process of applying aspect logic to the target object after defining the pointcut expression. In Spring, this is usually implemented at runtime through dynamic proxies. When a transaction request call occurs, the AOP framework will check whether there is a matching pointcut. If it matches, it means that the transaction request needs to be timed, and the corresponding advice (such as @Before, @AfterReturning, etc.) will be executed.

[0066] In the implementation process of the above embodiment: by using Spring AOP expression language in the Spring framework to define the pointcut expression, it is possible to intercept and process specific method calls without modifying the business logic code, such as intercepting transaction requests that require timing detection, implementing timing detection of transaction requests, and ensuring the consistency and reliability of transactions.

[0067] Optionally, in the embodiment of the present application, when the matching result indicates that the match is passed, the transaction request is sent to the transaction party according to the request expiration timestamp and the current time, including:

[0068] When the matching result indicates that the match is passed, it is determined whether the current time is later than the request expiration timestamp. For example, in the logic of the pre-notification, the current time and the request expiration timestamp are compared to determine whether the current time is later than the request expiration timestamp.

[0069] If the current time is later than the request expiration timestamp, the transaction request is discarded. If the current time is later than the request expiration timestamp: it means that the transaction request has timed out and the request should be discarded. This can be achieved by throwing an exception or returning a specific error code to prevent the transaction request from continuing to execute. For timed-out transaction requests, the system can record logs, generate monitoring alarms, or perform other necessary error handling operations.

[0070] If the current time is not later than the request expiration timestamp, the transaction request is sent to the transaction party. If the current time is not later than the request expiration timestamp: it means that the transaction request has not timed out and can continue to be executed. At this time, the transaction request is sent to the transaction party for processing.

[0071] In the implementation process of the above embodiment: by judging whether the current time is later than the request expiration timestamp, the transaction request is subjected to timing detection without modifying the business logic code, thereby ensuring the timeliness and validity of the transaction and improving the stability of the system and the user experience.

[0072] Optionally, in the embodiment of the present application, after receiving the transaction verification information sent by the transaction party, the method further includes:

[0073] If the transaction verification information indicates that the transaction status of the transaction request is that the transaction does not exist, the verification interface is polled according to preset rules through an asynchronous task, and the transaction verification information obtained each time the verification interface is called is recorded.

[0074] Receive transaction verification information sent by the transaction party through callback interface, polling request or message queue, parse the received transaction verification information to determine the status of the transaction. If the verification information indicates that the transaction status is "transaction does not exist", proceed to the next step. Define an asynchronous task processor in the system to perform polling verification operations. This processor can use the @Async annotation of the Spring framework to implement asynchronous execution.

[0075] Enable asynchronous execution in Spring configuration to ensure that the system can execute tasks asynchronously without affecting the execution of the main thread. Implement polling logic in the asynchronous task processor. Polling logic includes setting the preset time period of polling, the number of polling, the interval time of polling, and the termination condition of polling. This is also the preset rule that the polling verification interface needs to follow. After each call to the verification interface, the system needs to record the verification results. For example, this can be achieved through database operations to store the time, status and other relevant information of each verification.

[0076] When the transaction status is "transaction does not exist", the asynchronous task is triggered and the verification interface is polled according to the preset rules. After each poll, the system needs to process the results returned by the verification interface. If the transaction status changes to exist, the polling is stopped and subsequent processing is performed; if the transaction status is still not existent, the polling continues according to the preset rules.

[0077] In an optional embodiment, during the polling process, the system needs to handle possible timeouts and abnormal situations. If the maximum number of polling times is reached or the predetermined polling time limit is exceeded, the polling needs to be stopped and corresponding compensation measures need to be taken. In addition, the status of the polling task can be monitored in real time, and notifications can be sent to relevant personnel or systems when key events (such as polling start, success, failure, timeout, etc.) occur.

[0078] In the implementation process of the above embodiment: by polling the verification interface according to preset rules through asynchronous tasks, and recording the transaction verification information obtained by calling the verification interface each time, the system can automatically and continuously verify the status of the transaction until the transaction is confirmed or the polling limit condition is reached. This method improves the performance of the payment system, ensures the final consistency of the transaction, and reduces the impact on the main business process through asynchronous processing.

[0079] Optionally, in an embodiment of the present application, a polling task is generated according to the transaction request and the verification interface; the polling task is sent to the message queue. When the transaction request is initially verified as "transaction does not exist", a polling task can be generated according to the transaction request and the verification interface. This task will contain all necessary information, such as the unique identifier of the transaction request, the URL of the verification interface, the preset polling interval and the maximum number of polling times, etc. A data structure (which can be an object or a database table) can be designed to save the detailed information of the polling task to ensure that the status and results of each polling can be tracked and recorded.

[0080] Send the generated polling tasks to the predefined message queue. This step usually involves configuring the connection information of the message queue and ensuring that the messages can be serialized and sent correctly. Configure the message queue service in the system to ensure that it can handle the expected load and set the corresponding queue properties, such as queue name, message persistence, visibility timeout, etc.

[0081] The backend server asynchronously pulls the polling task from the message queue, executes the call of the verification interface according to the preset rules, and records the transaction verification information obtained by each call to the verification interface. For example, the backend server needs to have one or more consumer services, which will listen to the message queue and asynchronously pull the polling task. Once the consumer service obtains the polling task from the message queue, it will execute the call of the verification interface according to the preset rules. This may involve building an HTTP request, processing authentication, sending a request and receiving a response, etc.

[0082] After each call to the verification interface, the consumer service needs to record the obtained transaction verification information. This usually involves storing the verification results in the database, including verification time, transaction status, interface response data, etc. Based on the verification results, the system may need to execute further logic, such as updating the transaction status, triggering other business processes, sending notifications, etc.

[0083] When executing the verification interface call, you need to consider the handling of exceptions and errors, such as interface timeout, network error, verification interface return error code, etc. These situations require corresponding handling strategies, which may include retry mechanisms, error logging, alarm notifications, etc. Real-time monitoring of polling task processing, including task execution time, success rate, error rate, etc. Set alarm thresholds to promptly notify operation and maintenance personnel or developers when abnormal situations occur.

[0084] In the implementation process of the above embodiment: by sending the generated polling tasks to the predefined message queue and executing the polling tasks, the system can efficiently and reliably process a large number of polling tasks, ensure the accuracy and timeliness of the transaction status, while maintaining the responsiveness and scalability of the system.

[0085] See also Figure 2 The structure diagram of the transaction verification device provided in the embodiment of the present application is shown; the embodiment of the present application provides a transaction verification device 200, including:

[0086] The request receiving module 210 is used to receive a transaction request and obtain a timestamp of the transaction request;

[0087] The expiration time determination module 220 is used to determine the request expiration timestamp according to the timestamp of the transaction request, and add the request expiration timestamp to the transaction request; the request expiration timestamp is used to determine whether the transaction request has timed out;

[0088] The matching module 230 is used to match the method corresponding to the transaction request using a predefined interception rule to obtain a matching result; the interception rule is used to match the method that needs to be time-series detected;

[0089] A sending request module 240, configured to send a transaction request to a transaction party according to a request expiration timestamp and a current time when the matching result indicates a match;

[0090] The verification module 250 is used to send a verification request to the transaction party after reaching the request expiration timestamp, and receive transaction verification information sent by the transaction party; the verification request is used to obtain the transaction status of the transaction request.

[0091] Optionally, in an embodiment of the present application, the transaction verification device 200, the expiration time determination module 220, is specifically used to obtain a target transaction channel corresponding to a transaction request; based on the target transaction channel, obtain a processing time corresponding to the target transaction channel; add the timestamp of the transaction request to the processing time to obtain a request expiration timestamp.

[0092] Optionally, in an embodiment of the present application, the transaction verification device 200, the interception rule includes a pointcut expression, and the matching module 230 is specifically used to define the pointcut expression using the Spring AOP expression language in the Spring framework; the pointcut expression includes at least one of a matching method name, a matching method label, a matching return type, a matching annotation, and a matching class name; the pointcut expression is used to match the method corresponding to the transaction request to obtain a matching result; the matching result indicates whether the transaction request matches the method defined in the interception rule that requires timing detection.

[0093] Optionally, in an embodiment of the present application, the transaction verification device 200, the sending request module 240, is specifically used to determine whether the current time is later than the request expiration timestamp when the matching result indicates that the match is passed; if the current time is later than the request expiration timestamp, the transaction request is discarded; if the current time is not later than the request expiration timestamp, the transaction request is sent to the transaction party.

[0094] Optionally, in an embodiment of the present application, the transaction verification device 200 further includes: a polling module, which is used to poll the verification interface according to preset rules through an asynchronous task if the transaction verification information represents that the transaction status of the transaction request is that the transaction does not exist, and record the transaction verification information obtained each time the verification interface is called.

[0095] Optionally, in an embodiment of the present application, the transaction verification device 200, the polling module, is specifically used to generate a polling task based on a transaction request and a verification interface; send the polling task to a message queue; asynchronously pull the polling task from the message queue through a back-end server, execute the call of the verification interface according to preset rules, and record the transaction verification information obtained each time the verification interface is called.

[0096] Optionally, in the embodiment of the present application, the transaction verification device 200, the preset rule includes at least one of a preset time period, a number of polling times and a polling interval time.

[0097] It should be understood that the device corresponds to the transaction verification method embodiment described above and can execute the various steps involved in the method embodiment described above. The specific functions of the device can be found in the description above. To avoid repetition, the detailed description is appropriately omitted here. The device includes at least one software function module that can be stored in a memory in the form of software or firmware or fixed in the operating system (OS) of the device.

[0098] See also Figure 3 The electronic device 300 provided in the embodiment of the present application includes: a processor 310 and a memory 320, wherein the memory 320 stores machine-readable instructions executable by the processor 310, and when the machine-readable instructions are executed by the processor 310, the above method is executed.

[0099] Figure 3 Each component shown in can be implemented by hardware, software or a combination thereof. The electronic device 300 may be a physical device, such as a server, a PC, etc., or a virtual device, such as a virtual machine, a virtualized container, etc. Moreover, the electronic device 300 is not limited to a single device, but may also be a combination of multiple devices or a cluster consisting of a large number of devices.

[0100] An embodiment of the present application further provides a storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the above method is executed.

[0101] Among them, the storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable red-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, disk or optical disk.

[0102] In several embodiments provided by the embodiments of the present application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely schematic. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the devices, methods and computer program products according to the multiple embodiments of the embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of the code, and a part of the module, program segment or code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than the order marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or action, or can be implemented with a combination of dedicated hardware and computer instructions.

[0103] In addition, the functional modules in each embodiment of the present application can be integrated together to form an independent part, or each module can exist separately, or two or more modules can be integrated to form an independent part.

[0104] The above description is only an optional implementation manner of the embodiments of the present application, but the protection scope of the embodiments of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or replacements within the technical scope disclosed in the embodiments of the present application, which should be covered within the protection scope of the embodiments of the present application.

Claims

1. A transaction verification method, characterized in that: include: Receiving a transaction request and obtaining a timestamp of the transaction request; Determine a request expiration timestamp according to the timestamp of the transaction request, and add the request expiration timestamp into the transaction request; Using predefined interception rules to match the method corresponding to the transaction request to obtain a matching result; The interception rule is used to match the method that needs to perform timing detection; In the case where the matching result indicates a match, sending the transaction request to the transaction party according to the request expiration timestamp and the current time; After reaching the request expiration timestamp, a verification request is sent to the transaction party, and transaction verification information sent by the transaction party is received; the verification request is used to obtain the transaction status of the transaction request.

2. The method according to claim 1, characterized in that The determining the request expiration timestamp according to the timestamp of the transaction request includes: Obtaining a target transaction channel corresponding to the transaction request; Based on the target transaction channel, obtaining a processing time corresponding to the target transaction channel; The timestamp of the transaction request is added to the processing duration to obtain the request expiration timestamp; the request expiration timestamp is used to determine whether the transaction request has timed out.

3. The method according to claim 1, characterized in that The interception rule includes a cut-point expression, and the method corresponding to the transaction request is matched with the predefined interception rule to obtain a matching result, including: The pointcut expression is defined in the Spring framework using the Spring AOP expression language; the pointcut expression includes at least one of a matching method name, a matching method tag, a matching return type, a matching annotation, and a matching class name; The point cut expression is used to match the method corresponding to the transaction request to obtain a matching result; the matching result indicates whether the transaction request matches the method that needs to be time-series detected defined in the interception rule.

4. The method according to claim 1, characterized in that: If the matching result indicates that the match is successful, the transaction request is sent to the transaction party according to the request expiration timestamp and the current time, including: If the matching result indicates a successful match, determining whether the current time is later than the request expiration timestamp; If the current time is later than the request expiration timestamp, the transaction request is discarded; If the current time is not later than the request expiration timestamp, the transaction request is sent to the transaction party.

5. The method according to claim 1, characterized in that After receiving the transaction verification information sent by the transaction party, the method further includes: If the transaction verification information indicates that the transaction status of the transaction request is that the transaction does not exist, the verification interface is polled according to preset rules through an asynchronous task, and the transaction verification information obtained each time the verification interface is called is recorded.

6. The method according to claim 5, characterized in that The asynchronous task polls the verification interface according to preset rules and records the transaction verification information obtained each time the verification interface is called, including: generating a polling task according to the transaction request and the verification interface; and sending the polling task to a message queue; The polling task is asynchronously pulled from the message queue by a back-end server, the call of the verification interface is executed according to the preset rule, and the transaction verification information obtained by calling the verification interface each time is recorded.

7. The method according to claim 5, characterized in that The method further includes: the preset rule includes at least one of a preset time period, a number of polling times and a polling interval time.

8. A computer program product, characterized in that The method comprises computer program instructions, and when the computer program instructions are executed by a processor, the method according to any one of claims 1 to 7 is executed.

9. An electronic device, characterized in that: include: A processor and a memory, wherein the memory stores computer program instructions, and when the computer program instructions are executed by the processor, the method according to any one of claims 1 to 7 is executed.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, and when the computer program instructions are executed by a processor, the method according to any one of claims 1 to 7 is executed.

Images