Transaction-level synchronous and asynchronous conversion method, system and equipment

By deploying a centralized storage and real-time broadcast mechanism within the intra-bank trading system, and utilizing a unique transaction identifier and key mechanism, the problem of synchronous and asynchronous communication conversion between different trading systems was solved, achieving compatibility and security of the trading system under different communication modes.

CN121900988APending Publication Date: 2026-04-21CHINA CITIC BANK CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511784514.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-12-01
Publication Date
2026-04-21

AI Technical Summary

Technical Problem

How to achieve synchronous-asynchronous communication conversion between different trading systems, ensuring that intra-bank trading systems are suitable for both synchronous and asynchronous communication modes, and can normally receive response information from trading systems in asynchronous communication mode.

Method used

Deploy centralized storage in the intra-bank transaction system, forward inter-bank transaction results to all payment nodes through a real-time broadcast mechanism, and use a unique transaction identifier and key mechanism to ensure the security and accuracy of transaction results.

Benefits of technology

It enables cross-bank transactions between the intra-bank trading system and other banks' trading systems, ensuring that synchronous communication mode is not affected, while also adapting to asynchronous communication mode, ensuring accurate processing and security of transaction results.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121900988A_ABST
    Figure CN121900988A_ABST
Patent Text Reader

Abstract

The invention relates to a transaction-level synchronous and asynchronous conversion method, system and equipment. The method comprises the following steps: deploying centralized storage in an intra-bank transaction system in a synchronous communication mode, when a first payment node of the intra-bank transaction system receives an inter-bank transaction result responded by other bank transaction systems, judging whether the inter-bank transaction result belongs to the transaction result of the inter-bank transaction initiated by the payment node or not, and if not, sending the inter-bank transaction result to the first payment node; if yes, the inter-bank transaction result is written into centralized storage, the centralized storage forwards the inter-bank transaction result to all payment nodes of an intra-bank transaction system through a real-time broadcasting mechanism, each payment node judges whether the inter-bank transaction result broadcasted by the centralized storage belongs to the transaction result of the inter-bank transaction initiated by the payment node or not, and if yes, the inter-bank transaction result is written into the centralized storage; if yes, the inter-bank transaction result is processed, and if not, the inter-bank transaction result is discarded. According to the method provided by the invention, the intra-row transaction system is not only suitable for intra-row synchronous communication, but also suitable for inter-row asynchronous communication, and the vacancy that transaction-level synchronous and asynchronous conversion cannot be carried out in the prior art is made up.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The embodiments in this specification relate to the field of financial technology, and in particular to a transaction-level synchronous-asynchronous conversion method, system, and device. Background Technology

[0002] In current interbank transactions, different trading systems need to communicate with each other. However, since these trading systems may be developed by different institutions, intrabank trading systems use synchronous communication, while interbank trading systems that conduct interbank transactions with intrabank trading systems use asynchronous communication. Therefore, how to achieve the conversion between synchronous and asynchronous communication modes, so as to ensure that intrabank trading systems can successfully send interbank transactions to interbank trading systems using asynchronous communication modes, and at the same time ensure that the same node of the intrabank trading system can normally receive response information from interbank trading systems using asynchronous communication modes, so that intrabank trading systems are suitable for both intrabank synchronous communication and interbank asynchronous communication, is a technical problem that urgently needs to be solved. Summary of the Invention

[0003] To address the problems existing in the prior art, embodiments of this specification provide a transaction-level synchronous-asynchronous conversion method, system, and device. A centralized storage is deployed within an intra-bank transaction system in synchronous communication mode. When the first payment node of the intra-bank transaction system receives a cross-bank transaction result from another bank's transaction system, it determines whether the cross-bank transaction result belongs to the cross-bank transaction initiated by this payment node. If not, the cross-bank transaction result is written to the centralized storage. The centralized storage forwards the cross-bank transaction result to all payment nodes of the intra-bank transaction system through a real-time broadcast mechanism. Each payment node determines whether the cross-bank transaction result broadcast by the centralized storage belongs to the cross-bank transaction initiated by this payment node. If yes, the cross-bank transaction result is processed; otherwise, it is discarded.

[0004] The specific technical solutions of the embodiments in this specification are as follows:

[0005] On the one hand, embodiments of this specification provide a transaction-level synchronous-asynchronous conversion method, the method comprising:

[0006] When the intra-bank transaction system detects the cross-bank transaction result from the other bank's transaction system, the first payment node of the intra-bank transaction system obtains the cross-bank transaction result from the other bank's transaction system. The intra-bank transaction system uses a synchronous communication mode, while the other bank's transaction system uses an asynchronous communication mode.

[0007] The first payment node determines whether the interbank transaction result is the transaction result of the interbank transaction sent by the first payment node;

[0008] If the interbank transaction result is not the result of the interbank transaction sent by the first payment node, then the first payment node writes the interbank transaction result into the centralized storage of the intrabank transaction system;

[0009] The centralized storage forwards the interbank transaction results to all payment nodes of the intrabank transaction system through a real-time broadcast mechanism.

[0010] Each payment node determines whether the interbank transaction result broadcast in the centralized storage belongs to the interbank transaction result sent by its own payment node;

[0011] If so, then process the cross-bank transaction result;

[0012] If not, then discard the cross-bank transaction result;

[0013] If the interbank transaction result is the result of an interbank transaction sent by the first payment node, then the first payment node will process the interbank transaction result.

[0014] Furthermore, the intra-bank transaction system's monitoring of the inter-bank transaction results from other banks' transaction systems further includes:

[0015] The intra-bank transaction system monitors the MQ queue of the other-bank transaction system to see if there are cross-bank transaction results from the intra-bank transaction system.

[0016] The first payment node of the intra-bank transaction system obtaining the inter-bank transaction result from the other-bank transaction system further includes:

[0017] The first payment node retrieves the cross-bank transaction result from the MQ queue of the other bank's transaction system.

[0018] Furthermore, the first payment node's determination of whether the interbank transaction result is the transaction result of the interbank transaction sent by the first payment node further includes:

[0019] The first payment node determines whether the first unique identifier of the interbank transaction result matches the second unique identifier in the waiting response information of the first payment node. The second unique identifier in the waiting response information of the first payment node is the unique identifier of the interbank transaction sent by the first payment node.

[0020] If a match is found, the interbank transaction result is the result of the interbank transaction sent by the first payment node;

[0021] If there is no match, the interbank transaction result is not the result of the interbank transaction sent by the first payment node.

[0022] Furthermore, the first payment node writing the interbank transaction result into the centralized storage of the intra-bank transaction system further includes:

[0023] The first payment node extracts the first unique transaction identifier of the interbank transaction result;

[0024] A first key is generated based on the unique identifier of the first transaction;

[0025] The interbank transaction result is encrypted using the first key to obtain the ciphertext of the interbank transaction result;

[0026] The encrypted result of the interbank transaction is written into the centralized storage.

[0027] Furthermore, the centralized storage, through a real-time broadcast mechanism, forwards the interbank transaction results to all payment nodes of the intra-bank transaction system, which further includes:

[0028] The centralized storage forwards the encrypted results of the interbank transaction to all payment nodes of the intrabank transaction system through a real-time broadcast mechanism.

[0029] Furthermore, each payment node's determination of whether the interbank transaction result broadcast in the centralized storage belongs to the interbank transaction result sent by its own payment node further includes:

[0030] Each payment node generates its own second key based on the second transaction unique identifier in its waiting response information from other banks;

[0031] Each payment node determines whether its second key can successfully decrypt the ciphertext of the interbank transaction result;

[0032] If decryption is successful, the cross-bank transaction result belongs to the cross-bank transaction result sent by the payment node;

[0033] If decryption fails, the result of the interbank transaction is not considered part of the interbank transaction result sent by the payment node.

[0034] Furthermore, processing the interbank transaction result further includes:

[0035] Process the decrypted interbank transaction results.

[0036] On the other hand, embodiments of this specification also provide a transaction-level synchronous-asynchronous conversion system, the system including an intra-bank trading system with an internal synchronous communication mode and an inter-bank trading system with an internal asynchronous communication mode;

[0037] The in-bank transaction system includes multiple payment nodes and centralized storage;

[0038] When the intra-bank transaction system and the inter-bank transaction system conduct inter-bank transactions, the above method is executed.

[0039] On the other hand, embodiments of this specification also provide a computer device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the above-described method.

[0040] On the other hand, embodiments of this specification also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0041] Using the embodiments in this specification, a transaction system with synchronous communication mode within the same bank can conduct cross-bank transactions with a transaction system with asynchronous communication mode from other banks. This ensures that the synchronous communication mode within the same bank is not affected, and also ensures that the system can interface with the asynchronous communication mode of other banks. This makes the transaction system within the same bank suitable for both synchronous communication within the same bank and asynchronous communication across banks, thus filling the gap in the prior art that cannot perform transaction-level synchronous-asynchronous conversion. Attached Figure Description

[0042] To more clearly illustrate the technical solutions in the embodiments of this specification or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0043] Figure 1 The diagram shown is a schematic representation of an implementation system for a transaction-level synchronous-asynchronous conversion method as described in this specification.

[0044] Figure 2 The diagram shows a cross-bank transaction process between an intra-bank transaction system using asynchronous communication mode and an inter-bank transaction system using asynchronous communication mode in the prior art.

[0045] Figure 3 The diagram shown is a flowchart of the transaction-level synchronous-asynchronous conversion method in the embodiments of this specification;

[0046] Figure 4 The diagram shown is a flowchart illustrating how the first payment node determines whether the interbank transaction result is the result of an interbank transaction sent by the first payment node in an embodiment of this specification.

[0047] Figure 5The diagram shown is a schematic representation of the process by which the first payment node writes the interbank transaction result into the centralized storage of the intrabank transaction system in an embodiment of this specification.

[0048] Figure 6 The diagram shows a flowchart illustrating how each payment node determines whether the interbank transaction result broadcast in the centralized storage belongs to the interbank transaction result sent by this payment node in an embodiment of this specification.

[0049] Figure 7 The diagram shown is a detailed flowchart of interbank transactions as described in this specification.

[0050] Figure 8 The diagram shown is a structural schematic of the computer device in an embodiment of this specification.

[0051] [Explanation of Figure Markers]:

[0052] 101. In-house trading system;

[0053] 102. Other banks' trading systems;

[0054] 802. Computer equipment;

[0055] 804. Processing equipment;

[0056] 806. Storage resources;

[0057] 808. Drive mechanism;

[0058] 810. Input / Output Module;

[0059] 812. Input devices;

[0060] 814. Output devices;

[0061] 816. Presentation equipment;

[0062] 818. Graphical User Interface;

[0063] 820. Network interface;

[0064] 822. Communication link;

[0065] 824. Communication bus. Detailed Implementation

[0066] The technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the embodiments of this specification, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of the embodiments of this specification.

[0067] It should be noted that the terms "first," "second," etc., in the description, claims, and accompanying drawings of the embodiments herein 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 embodiments of the embodiments 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 non-exclusive inclusion; for example, a process, method, apparatus, product, or device that includes 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 devices.

[0068] It should be noted that the acquisition, storage, use, and processing of data in the technical solutions of the embodiments in this specification all comply with the relevant provisions of national laws and regulations.

[0069] It should be noted that in the embodiments of this specification, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, they do not mean that the applicant has used or necessarily used the solution.

[0070] like Figure 1 The diagram illustrates a system implementation of a transaction-level synchronous / asynchronous conversion method according to an embodiment of this specification, including an intra-bank trading system 101 and an inter-bank trading system 102. The intra-bank trading system 101 and the inter-bank trading system 102 can communicate via a network, which may include a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof, and is connected to a website, user equipment (e.g., computing devices), and a backend system.

[0071] The intra-bank transaction system 101 uses synchronous communication, while the inter-bank transaction system 102 uses asynchronous communication. Synchronous communication means that intra-bank system node A initiates an inter-bank transaction, and payment system node A of the intra-bank transaction system sends the inter-bank transaction to the inter-bank transaction system. After the inter-bank transaction system responds, payment system node A processes the response information and then returns it to intra-bank system node A. In other words, the node that initiates the inter-bank transaction and the node that receives the inter-bank transaction response are the same node. Asynchronous communication, on the other hand, means that the inter-bank transaction system uses different nodes for receiving the inter-bank transaction and returning the inter-bank transaction response.

[0072] The method described in this specification aims to achieve the conversion between synchronous and asynchronous communication modes, thereby ensuring that the intra-bank trading system can successfully send inter-bank transactions to the asynchronous communication mode of other banks through synchronous communication mode, and also ensuring that the same node of the intra-bank trading system can normally receive the response information of the asynchronous communication mode of other banks' trading systems. Thus, the intra-bank trading system is suitable for both intra-bank synchronous communication and inter-bank asynchronous communication.

[0073] For example, in the prior art, the interbank transaction process between an intra-bank transaction system using asynchronous communication mode and an inter-bank transaction system using asynchronous communication mode can be as follows: Figure 2 As shown, it includes the following steps:

[0074] 1. Intra-bank system node A sends the inter-bank transaction request to the payment system MQ queue of the intra-bank transaction system;

[0075] 2. Each payment system node in the intra-bank transaction system listens for changes in messages in the payment system MQ queue. In this example, payment system node A receives an inter-bank transaction request initiated by intra-bank system node A.

[0076] 3. Payment system node A forwards interbank transaction requests to the MQ queue of another bank's transaction system;

[0077] 4. Other banks' transaction systems listen to the MQ queue to obtain cross-bank transaction requests initiated by the internal transaction system. The other banks' transaction systems communicate with other banks (or other financial institutions) to conduct cross-bank transactions.

[0078] 5. The People's Bank of China system obtains the transaction response result and sends it to the People's Bank of China MQ queue.

[0079] 6. The payment system nodes of the intra-bank transaction system listen to the MQ queues of other banks' transaction systems to obtain the response information of cross-bank transactions. In this example, payment system node B obtains the cross-bank transaction response information (which is a different node from payment system node A that sent the cross-bank transaction request).

[0080] 7. Payment system node B sends the response information to the payment system MQ queue;

[0081] 8. The internal system node listens to the payment system MQ queue to obtain response information. In this example, the internal system node B obtains the response information (which is a different node from the internal system node A that sent the interbank transaction).

[0082] During this process, intra-bank system node A, which initiates the inter-bank transaction, cannot receive the response information of the inter-bank transaction. However, in synchronous communication mode, the response information of the inter-bank transaction request sent by intra-bank system node A must be returned to intra-bank system node A.

[0083] To address the aforementioned issues, this specification provides a transaction-level synchronous-asynchronous conversion method. Figure 3 The diagram shown is a flowchart illustrating a transaction-level synchronous-asynchronous conversion method according to an embodiment of this specification. This diagram depicts the processing of interbank transactions, but based on conventional or non-creative labor, it may include more or fewer operational steps. The order of steps listed in the embodiment is merely one possible execution order among many and does not represent the only possible execution order. In actual system or device products, the methods shown in the embodiment or the accompanying drawings can be executed sequentially or in parallel. Specifically, as shown... Figure 3 As shown, the method is executed by an intra-bank trading system in synchronous communication mode and may include:

[0084] Step 301: When the intra-bank transaction system detects the cross-bank transaction result of the intra-bank transaction system in response to the cross-bank transaction system of the other bank transaction system, the first payment node of the intra-bank transaction system obtains the cross-bank transaction result from the other bank transaction system. The internal communication mode of the intra-bank transaction system is synchronous communication mode, and the internal communication mode of the other bank transaction system is asynchronous communication mode.

[0085] Step 302: The first payment node determines whether the interbank transaction result is the transaction result of the interbank transaction sent by the first payment node;

[0086] Step 303: If the interbank transaction result is not the transaction result of the interbank transaction sent by the first payment node, then the first payment node writes the interbank transaction result into the centralized storage of the intrabank transaction system;

[0087] Step 3031: The centralized storage forwards the interbank transaction result to all payment nodes of the intrabank transaction system through a real-time broadcast mechanism;

[0088] Step 3032: Each payment node determines whether the interbank transaction result broadcast in the centralized storage belongs to the interbank transaction result sent by this payment node;

[0089] Step 3033: If yes, then process the cross-bank transaction result;

[0090] Step 3034: If not, discard the cross-bank transaction result;

[0091] Step 304: If the interbank transaction result is the result of the interbank transaction sent by the first payment node, then the first payment node will process the interbank transaction result.

[0092] Using the embodiments in this specification, a transaction system with synchronous communication mode within the same bank can conduct cross-bank transactions with a transaction system with asynchronous communication mode from other banks. This ensures that the synchronous communication mode within the same bank is not affected, and also ensures that the system can interface with the asynchronous communication mode of other banks. This makes the transaction system within the same bank suitable for both synchronous communication within the same bank and asynchronous communication across banks, thus filling the gap in the prior art that cannot perform transaction-level synchronous-asynchronous conversion.

[0093] In this embodiment of the specification, the intra-bank transaction system's monitoring of the inter-bank transaction results from other banks' transaction systems further includes:

[0094] The intra-bank transaction system monitors the MQ queue of the other-bank transaction system to see if there are cross-bank transaction results from the intra-bank transaction system.

[0095] The first payment node of the intra-bank transaction system obtaining the inter-bank transaction result from the other-bank transaction system further includes:

[0096] The first payment node retrieves the cross-bank transaction result from the MQ queue of the other bank's transaction system.

[0097] In the embodiments described in this specification, the first payment node is not a designated payment node. Any payment node that listens to the MQ queue of another bank's transaction system and finds the cross-bank transaction result of the intra-bank transaction system can be the first payment node.

[0098] Then the first payment node determines whether the interbank transaction result is the transaction result of the interbank transaction sent by the first payment node. Specifically, for example... Figure 4 As shown, the process by which the first payment node determines whether the interbank transaction result is the result of an interbank transaction sent by the first payment node further includes:

[0099] Step 401: The first payment node determines whether the first unique identifier of the interbank transaction result matches the second unique identifier in the waiting response information of the first payment node from other banks;

[0100] In this step, the second transaction unique identifier in the waiting response information of the first payment node is the transaction unique identifier of the interbank transaction sent by the first payment node;

[0101] Step 402: If a match is found, the interbank transaction result is the transaction result of the interbank transaction sent by the first payment node;

[0102] Step 403: If there is no match, the interbank transaction result is not the transaction result of the interbank transaction sent by the first payment node.

[0103] In the embodiments of this specification, the unique identifier of a transaction can be composed of three elements: subsystem type, initiating direct participant number, and message identifier. It should be noted that, in addition to the three elements of a transaction forming the unique identifier, other unique identifiers capable of identifying interbank transactions can also be used; this embodiment of the specification does not impose any restrictions.

[0104] In the embodiments of this specification, the centralized storage can be a Redis server or other storage server, and this specification does not limit the embodiments.

[0105] In this specification embodiment, because centralized storage broadcasts interbank transaction results to all payment nodes, to avoid leakage of interbank transaction results, according to one embodiment of this specification, such as... Figure 5 As shown, the process by which the first payment node writes the interbank transaction result into the centralized storage of the intra-bank transaction system further includes:

[0106] Step 501: The first payment node extracts the first unique transaction identifier of the interbank transaction result;

[0107] Step 502: Generate a first key based on the first transaction unique identifier;

[0108] Step 503: Encrypt the interbank transaction result using the first key to obtain the ciphertext of the interbank transaction result;

[0109] Step 504: Write the encrypted result of the interbank transaction into the centralized storage.

[0110] In the embodiments of this specification, the first payment node can use the unique identifier of the first transaction as a basis to generate a corresponding 128-bit MD5 value, use the MD5 value as a key, use the SM4 algorithm to encrypt the interbank transaction result, obtain the ciphertext of the interbank transaction result, and write the ciphertext of the interbank transaction result into centralized storage.

[0111] Then, the encrypted results of the interbank transaction are forwarded to all payment nodes of the intrabank transaction system via a real-time broadcast mechanism through centralized storage.

[0112] Furthermore, such as Figure 6 As shown, each payment node's determination of whether the interbank transaction result broadcast in the centralized storage belongs to the interbank transaction result sent by its own payment node further includes:

[0113] Step 601: Each payment node generates its own second key based on the second transaction unique identifier in its waiting response information from other banks;

[0114] Step 602: Each payment node determines whether its second key can successfully decrypt the ciphertext of the interbank transaction result;

[0115] Step 603: If decryption is successful, the interbank transaction result belongs to the interbank transaction result sent by the payment node;

[0116] Step 604: If decryption fails, the interbank transaction result is not part of the interbank transaction result sent by the payment node.

[0117] In the embodiments of this specification, the payment node that receives the ciphertext of the broadcast interbank transaction result generates a 128-bit MD5 value as a key based on the second unique transaction identifier (i.e., the unique transaction identifier of the interbank transaction sent by the payment node) in its waiting response information from other banks. This key is used to encrypt the ciphertext of the received interbank transaction result. If the key is correct, it can be successfully decrypted, indicating that the interbank transaction result belongs to the interbank transaction result sent by the payment node. If it cannot be successfully decrypted, it indicates that the interbank transaction result does not belong to the interbank transaction result sent by the payment node, and the payment node cannot obtain the plaintext of the interbank transaction result, thereby ensuring the security of the interbank transaction result.

[0118] For example, the detailed process of interbank transactions using the methods described in this specification is as follows: Figure 7 As shown, it includes the following steps:

[0119] 1. Intra-bank system node A sends an inter-bank transaction request to payment system node A in synchronous communication mode;

[0120] 2. Payment system node A sends the interbank transaction request to the MQ queue of the other bank's transaction system;

[0121] 3. Other banks' transaction systems obtain cross-bank transaction requests initiated by internal transaction systems through the listener MQ queue. The other banks' transaction systems communicate with other banks (or other financial institutions) to process cross-bank transaction requests and obtain cross-bank transaction results.

[0122] 4. When another bank's transaction system receives the cross-bank transaction result, it sends it to the MQ queue;

[0123] 5. The payment system nodes of the intra-bank transaction system listen to the MQ queue to obtain the cross-bank transaction results. In this example, payment system node B obtains the cross-bank transaction results (which are different from payment system node A, which sent the cross-bank transaction request).

[0124] 6. If payment system node B determines that the cross-bank transaction result does not belong to its own cross-bank transaction request result, it will extract the first transaction unique identifier of the cross-bank transaction result, generate a 128-bit MD5 value, use the MD5 value as the key, encrypt the cross-bank transaction result using the SM4 algorithm, obtain the ciphertext of the cross-bank transaction result, and then send the ciphertext of the cross-bank transaction result to the centralized storage Redis.

[0125] 7. After receiving the ciphertext of the interbank transaction result sent by payment system node B, Redis, the centralized storage, broadcasts the ciphertext of the interbank transaction result to all payment system nodes through a broadcast mechanism.

[0126] 8. Each payment system node generates a 128-bit MD5 value using the unique identifier of the second transaction in the waiting response information from other banks. The MD5 value is used as the key to decrypt the encrypted response information sent by Redis. If it can be decrypted successfully, the cross-bank transaction result is considered to be the transaction result of the cross-bank transaction sent by the payment node. In this example, payment system node A successfully decrypted the ciphertext of the cross-bank transaction result and obtained the plaintext of the cross-bank transaction result.

[0127] 9. After processing the plaintext of the interbank transaction result, payment system node A generates the corresponding response information and forwards it to intra-bank system node A.

[0128] In some other embodiments of this specification, after a payment node receives the ciphertext of the interbank transaction result broadcast from the centralized storage, if the payment node has multiple interbank transaction waiting-for-other-bank response messages with different second transaction unique identifiers in these messages, generating a key for each second transaction unique identifier in the waiting-for-other-bank response message and decrypting the ciphertext of the interbank transaction result multiple times using these keys would increase the computational load. To address this, according to one embodiment of this specification, the payment node pre-calculates the transaction response times of multiple interbank transactions it sends, obtaining the average response time. Upon receiving the ciphertext of the interbank transaction result broadcast from the centralized storage, the payment node calculates the estimated transmission time based on the reception time of the ciphertext and the average response time. Using this estimated transmission time as the time center point, a corresponding time range is calculated within a predetermined time window. All interbank transactions sent within this time range are extracted, and the second transaction unique identifiers from the waiting-for-other-bank response messages of these interbank transactions are extracted to generate a key. This key is then used to decrypt the received ciphertext of the interbank transaction result, thereby improving decryption efficiency and reducing computational load to some extent.

[0129] Based on the same inventive concept, embodiments of this specification also provide a transaction-level synchronous-asynchronous conversion system, the system including an intra-bank transaction system with an internal synchronous communication mode and an inter-bank transaction system with an internal asynchronous communication mode;

[0130] The in-bank transaction system includes multiple payment nodes and centralized storage;

[0131] When the intra-bank transaction system and the inter-bank transaction system conduct inter-bank transactions, the above method is executed.

[0132] The beneficial effects obtained by the above system are the same as those obtained by the above method, and will not be repeated in the embodiments of this specification.

[0133] like Figure 8 The diagram shown is a structural schematic of a computer device according to an embodiment of this specification. The methods of this invention can be applied to the computer device in this embodiment. The computer device 802 may include one or more processing devices 804, such as one or more central processing units (CPUs), each of which can implement one or more hardware threads.

[0134] The computer device 802 may also include any storage resource 806 for storing any kind of information such as code, settings, data, etc.

[0135] Non-limiting, for example, storage resource 806 may include any one or more of the following: any type of RAM, any type of ROM, flash memory device, hard disk, optical disk, etc.

[0136] More generally, any storage resource can use any technology to store information.

[0137] Furthermore, any storage resource can provide volatile or non-volatile retention of information.

[0138] Furthermore, any storage resource can represent a fixed or removable component of the computer device 802.

[0139] In one scenario, when processing device 804 executes associated instructions stored in any storage resource or combination of storage resources, computer device 802 can perform any operation of the associated instructions. Computer device 802 also includes one or more drive mechanisms 808 for interacting with any storage resource, such as hard disk drive mechanisms, optical disk drive mechanisms, etc.

[0140] Computer device 802 may also include an input / output module 810 (I / O) for receiving various inputs (via input device 812) and providing various outputs (via output device 814). A specific output mechanism may include a presentation device 816 and an associated graphical user interface (GUI) 818. In other embodiments, the input / output module 810 (I / O), input device 812, and output device 814 may be omitted, and the device may function solely as a computer device within a network. Computer device 802 may also include one or more network interfaces 820 for exchanging data with other devices via one or more communication links 822. One or more communication buses 824 couple the components described above together.

[0141] Communication link 822 can be implemented in any way, such as via a local area network (LAN), a wide area network (WAN) (e.g., the Internet), a point-to-point connection, or any combination thereof. Communication link 822 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc., governed by any protocol or combination of protocols.

[0142] This specification also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0143] This specification also provides computer-readable instructions, wherein when a processor executes the instructions, the program therein causes the processor to perform the above-described method.

[0144] It should be understood that in the various embodiments of this specification, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this specification.

[0145] It should also be understood that, in the embodiments of this specification, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the embodiments of this specification, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0146] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this specification can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of the embodiments in this specification.

[0147] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0148] In the embodiments provided in this specification, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through some interfaces, devices, or units, or they may be electrical, mechanical, or other forms of connection.

[0149] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments described in this specification, depending on actual needs.

[0150] Furthermore, the functional units in the various embodiments of this specification can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0151] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this specification, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this specification. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0152] This specification describes the principles and implementation methods of the embodiments using specific examples. The above descriptions of the embodiments are only for the purpose of helping to understand the methods and core ideas of the embodiments in this specification. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the embodiments in this specification. Therefore, the content of this specification should not be construed as a limitation on the embodiments in this specification.

Claims

1. A transaction-level synchronous-asynchronous conversion method, characterized in that, The method includes: When the intra-bank transaction system detects the cross-bank transaction result from the other bank's transaction system, the first payment node of the intra-bank transaction system obtains the cross-bank transaction result from the other bank's transaction system. The intra-bank transaction system uses a synchronous communication mode, while the other bank's transaction system uses an asynchronous communication mode. The first payment node determines whether the interbank transaction result is the transaction result of the interbank transaction sent by the first payment node; If the interbank transaction result is not the result of the interbank transaction sent by the first payment node, then the first payment node writes the interbank transaction result into the centralized storage of the intrabank transaction system; The centralized storage forwards the interbank transaction results to all payment nodes of the intrabank transaction system through a real-time broadcast mechanism. Each payment node determines whether the interbank transaction result broadcast in the centralized storage belongs to the interbank transaction result sent by its own payment node; If so, then process the cross-bank transaction result; If not, then discard the cross-bank transaction result; If the interbank transaction result is the result of an interbank transaction sent by the first payment node, then the first payment node will process the interbank transaction result.

2. The method according to claim 1, characterized in that, The intra-bank transaction system's monitoring of the inter-bank transaction results from other banks' transaction systems further includes: The intra-bank transaction system monitors the MQ queue of the other-bank transaction system to see if there are cross-bank transaction results from the intra-bank transaction system. The first payment node of the intra-bank transaction system obtaining the inter-bank transaction result from the other-bank transaction system further includes: The first payment node retrieves the cross-bank transaction result from the MQ queue of the other bank's transaction system.

3. The method according to claim 1, characterized in that, The first payment node's determination of whether the interbank transaction result is the result of the interbank transaction sent by the first payment node further includes: The first payment node determines whether the first unique identifier of the interbank transaction result matches the second unique identifier in the waiting response information of the first payment node. The second unique identifier in the waiting response information of the first payment node is the unique identifier of the interbank transaction sent by the first payment node. If a match is found, the interbank transaction result is the result of the interbank transaction sent by the first payment node; If there is no match, the interbank transaction result is not the result of the interbank transaction sent by the first payment node.

4. The method according to claim 1, characterized in that, The first payment node writes the interbank transaction result into the centralized storage of the intra-bank transaction system, which further includes: The first payment node extracts the first unique transaction identifier of the interbank transaction result; A first key is generated based on the unique identifier of the first transaction; The interbank transaction result is encrypted using the first key to obtain the ciphertext of the interbank transaction result; The encrypted result of the interbank transaction is written into the centralized storage.

5. The method according to claim 4, characterized in that, The centralized storage, through a real-time broadcast mechanism, forwards the interbank transaction results to all payment nodes of the intra-bank transaction system, further including: The centralized storage forwards the encrypted results of the interbank transaction to all payment nodes of the intrabank transaction system through a real-time broadcast mechanism.

6. The method according to claim 4, characterized in that, Each payment node's determination of whether the interbank transaction result broadcast in the centralized storage belongs to the interbank transaction result sent by its own payment node further includes: Each payment node generates its own second key based on the second transaction unique identifier in its waiting response information from other banks; Each payment node determines whether its second key can successfully decrypt the ciphertext of the interbank transaction result; If decryption is successful, the cross-bank transaction result belongs to the cross-bank transaction result sent by the payment node; If decryption fails, the result of the interbank transaction is not considered part of the interbank transaction result sent by the payment node.

7. The method according to claim 6, characterized in that, Processing the results of the interbank transaction further includes: Process the decrypted interbank transaction results.

8. A transaction-level synchronous-asynchronous conversion system, characterized in that, The system includes an intra-bank trading system with synchronous internal communication mode and an inter-bank trading system with asynchronous internal communication mode. The in-bank transaction system includes multiple payment nodes and centralized storage; When the intra-bank transaction system conducts inter-bank transactions with the inter-bank transaction system, the method described in any one of claims 7 shall be executed.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 7.

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