Payment message matching method and device, equipment, storage medium and program product

Abstract

The embodiment of the invention provides a payment message matching method and device, equipment, a storage medium and a program product. The method can be used in financial technical field. The method comprises the following steps: after a server side of a first mechanism receives a payment query message sent by a server side of a second mechanism, firstly identifying a target index from the payment query message by adopting a preset target index extraction strategy, then determining a main key of a target payment message from a preset payment message index table by utilizing the target index, and sending the main key to the server side of the second mechanism; the method comprises the following steps: firstly, determining a target payment message from a preset payment message record table through a main key, generating a payment check message according to the target payment message and a payment query message, and finally, returning the payment check message to a server of a second mechanism, thereby improving the matching efficiency of the payment message.

Description

Technical Field

[0001] The present application relates to the financial field, and in particular to a payment message matching method, device, equipment, storage medium and program product. Background Art

[0002] In the existing institutional service end, the outbound and inbound transactions are mainly realized through payment messages. In order to ensure the accuracy and timeliness of transactions, the system needs to query and verify the payment messages.

[0003] At present, the information of all payment messages is centrally stored in the main table. When the institutional server receives a query message, it will directly match the relevant payment message in the main table. Similarly, when the institutional server needs to send a query request, it will also look up the relevant information in the main table to generate a query message.

[0004] However, this payment message matching method that relies on the master table is inefficient and can easily slow down the operation process. Summary of the invention

[0005] The embodiments of the present application provide a payment message matching method, apparatus, device, storage medium and program product to achieve the effect of improving the payment message matching efficiency.

[0006] In a first aspect, an embodiment of the present application provides a payment message matching method, which is applied to a service end of a first institution, and the method includes:

[0007] Receiving a payment query message sent by a server of the second institution;

[0008] Using a preset target index extraction strategy to identify a target index from the payment query message;

[0009] Using the target index, determining a primary key of the target payment message from a preset payment message index table, wherein the payment message index table stores index information and a primary key of at least one payment message;

[0010] Determine the target payment message from a preset payment message record table by using the primary key, wherein the payment message record table stores at least one primary key of the payment message and transaction information;

[0011] Generate a payment inquiry reply message according to the target payment message and the payment inquiry message;

[0012] The payment inquiry message is returned to the server of the second institution.

[0013] In a possible implementation, the preset target index extraction strategy includes:

[0014] Determining a specific field in the payment query message as a target index;

[0015] The specific field includes at least one of the following fields: a payment message identification number, a payment remitting bank, and a payment receiving bank.

[0016] In a possible implementation manner, before receiving the payment query message sent by the service end of the second institution, the method further includes:

[0017] In response to a user's payment operation, generating a payment message;

[0018] Determine the index information and primary key of the payment message according to the target index extraction strategy;

[0019] storing the transaction information of the payment message in the payment message record table based on the primary key;

[0020] The index information and primary key of the payment message are stored in the payment message index table.

[0021] In a possible implementation, the method further includes:

[0022] The primary key of the target payment message, the query type in the payment query message, and the query result in the payment reply message are stored in a preset payment query reply message record table.

[0023] In a possible implementation manner, the payment inquiry reply message includes:

[0024] The query result of the payment query message and the transaction information in the target payment message.

[0025] In a possible implementation manner, the payment query message is a payment remittance query message.

[0026] Correspondingly, the payment message index table is a payment remittance message index table, and the payment remittance message index table stores index information and a primary key of at least one payment remittance message;

[0027] The payment message record table is a payment remittance message record table, and the payment remittance message record table stores at least one primary key and transaction information of a payment remittance message;

[0028] The payment inquiry reply message is a payment remittance inquiry reply message, and the payment remittance inquiry reply message includes a payment remittance query result and transaction information of the payment remittance message.

[0029] In a possible implementation manner, the payment query message is a payment remittance query message.

[0030] Correspondingly, the payment message index table is a payment inward remittance message index table, and the payment inward remittance message index table stores index information and a primary key of at least one payment inward remittance message;

[0031] The payment message record table is a payment inward remittance message record table, and the payment inward remittance message record table stores at least one primary key and transaction information of a payment inward remittance message;

[0032] The payment inquiry reply message is a payment inward remittance inquiry reply message, and the payment inward remittance inquiry reply message includes a payment inward remittance query result and transaction information of the payment inward remittance message.

[0033] In a second aspect, an embodiment of the present application provides a payment message matching device, including:

[0034] A receiving module, used for receiving a payment query message sent by a service end of the second institution;

[0035] A processing module, configured to adopt a preset target index extraction strategy to identify a target index from the payment query message;

[0036] The processing module is further used to determine the primary key of the target payment message from a preset payment message index table using the target index, wherein the payment message index table stores index information and a primary key of at least one payment message;

[0037] The processing module is further used to determine the target payment message from a preset payment message record table by using the primary key, wherein the payment message record table stores a primary key and transaction information of at least one payment message;

[0038] The processing module is further used to generate a payment inquiry reply message according to the target payment message and the payment inquiry message;

[0039] The sending module is used to return the payment inquiry message to the service end of the second institution.

[0040] In a third aspect, an embodiment of the present application provides a server, including: a memory, a processor;

[0041] The memory stores computer-executable instructions;

[0042] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the above first aspect and / or various possible implementations of the first aspect.

[0043] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the first aspect above and / or various possible implementations of the first aspect.

[0044] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the above first aspect and / or various possible implementation methods of the first aspect.

[0045] The matching method, device, equipment, storage medium and program product of the payment message provided by the embodiment of the present application relate to the field of financial technology. In this scheme, first, the service end of the first institution receives the payment query message from the service end of the second institution, and identifies the target index through the preset target index extraction strategy, so as to realize the rapid positioning of relevant information. Then, the target index is used to determine the primary key of the target payment message from the preset payment message index table to improve the accuracy and efficiency of data retrieval. Subsequently, the target payment message is obtained from the preset payment message record table through the primary key to ensure the accurate matching of data. Next, a payment query message is generated according to the target payment message and the payment query message to provide a timely and accurate response. Finally, the generated payment query message is returned to the service end of the second institution to ensure the rapid transmission and processing of information. Through the above steps, the method achieves the effect of 2d782eb3fb79c87bbd3b3591a7b70146. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0047] Figure 1 A schematic diagram of a payment message matching method provided in this application;

[0048] Figure 2 Schematic diagram of the payment message matching method provided in this application Figure 1 ;

[0049] Figure 3 Schematic diagram of the payment message matching method provided in this application Figure 2 ;

[0050] Figure 4 Schematic diagram of the payment message matching method provided in this application Figure 3 ;

[0051] Figure 5 A schematic diagram of the structure of the payment message matching device provided in this application;

[0052] Figure 6 A schematic diagram of the structure of the server provided for this application.

[0053] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0054] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0055] In existing institutional servers, transactions are transferred in and out through the transmission of payment messages. Payment messages are data packets containing transaction details, which are used to transmit transaction information between different financial institutions. In order to ensure the accuracy and timeliness of transactions, the institutional server must have efficient query and reply capabilities. These operations not only involve the verification and confirmation of existing transactions, but also the retrieval and analysis of historical transactions. Therefore, the processing efficiency of payment messages directly affects the performance and user experience of the entire institutional server.

[0056] Currently, the information of all payment messages is centrally stored in a master table. This master table is the core data storage structure of the institution's server, containing detailed information of each transaction, such as transaction amount, transaction date, payer, recipient and other key data. When the institution's server receives a payment query message, it directly searches the master table for payment messages that match the query conditions. This process involves traversing and comparing the data in the master table to verify and confirm the validity and accuracy of the query request. Specifically, the institution's server confirms the target payment message of the query by matching fields such as transaction amount, date, payer and recipient. Similarly, when the institution's server needs to generate a query request, it will look for relevant information in the master table, which includes extracting the necessary transaction data from the master table to build a complete query message.

[0057] However, the existing payment message matching methods are inefficient, mainly in the following aspects: First, with the increase in transaction volume, the amount of data stored in the master table is huge, which makes query operations slow and prolongs the response time of the institution's server. Secondly, all payment message operations rely on the master table, and frequent read and write access will cause performance bottlenecks on the institution's server, especially during peak trading hours, affecting the timeliness of transactions. In addition, as the number of payment messages increases, the expansion of the master table increases the complexity of data management and may lead to data redundancy and consistency issues. Finally, the existing solutions are insufficient in scalability, making it difficult to flexibly respond to growing transaction needs, and increasing the institution's server maintenance costs. These problems have a combined impact on the overall efficiency of payment message matching and are in urgent need of improvement.

[0058] In view of the above technical problems, the inventor found in the process of studying the matching method of payment messages that the existing technical solution stores all the information of the payment message in the same master table, so the server of the institution needs to query and compare one by one in the master table when processing the payment query message, resulting in low matching efficiency. For this reason, the inventor considers whether it is possible to optimize the storage and query mechanism of the payment message to reduce the query time and reduce the load, thereby improving the processing efficiency of the server. Specifically, when the server of the institution receives the payment query message sent by the server of other institutions, it first adopts the preset target index extraction strategy to identify the target index from the payment query message. Then, according to the target index, the primary key of the target payment message is determined from the preset payment message index table. Through this primary key, the target payment message can be found from the preset payment message record table. Subsequently, according to the payment query message and the target payment message, a payment reply message is generated and returned to the server of other institutions. This index extraction and primary key positioning strategy reduces the computing burden on the institution's server and optimizes resource utilization, allowing the server to maintain efficient processing capabilities even in high transaction volumes, thereby significantly improving the matching efficiency and response speed of payment messages.

[0059] Figure 1 A schematic diagram of a payment message matching method provided in this application, such as Figure 1 As shown, the application scenario of the solution provided by the present application includes a server 101 of a first institution and a server 102 of a second institution. A database system 1011 is deployed in the server 101 of the first institution, and a payment message index table 10111 and a payment message record table 10112 are stored in the database system 1011.

[0060] Specifically, the types of the server 101 of the first institution and the server 102 of the second institution include but are not limited to servers, computer equipment, etc., and this application does not make specific limitations on this.

[0061] The types of database system 1011 include, but are not limited to, relational database management systems, distributed database management systems, etc., and this application does not make any specific limitations on this.

[0062] In the specific application process, the server 101 of the first institution receives the payment query message sent by the server 102 of the second institution, and first uses the preset target index extraction strategy to identify the target index from the payment query message. Then, the server 101 of the first institution uses the target index to determine the primary key of the target payment message from the payment message index table 10111 stored in the database system 1011, and then determines the target payment message from the payment message record table 10112 stored in the database system 1011 through the primary key. Finally, a payment reply message is generated based on the target payment message and the payment query message, and returned to the server 102 of the second institution.

[0063] It is worth noting that although Figure 1 Only one server 101 of the first institution and one server 102 of the second institution are shown, but it should be understood that there may be two or more servers 101 of the first institution and servers 102 of the second institution. It should also be understood that in actual applications, the server 101 of the first institution may include more database systems 1011. The server 101 of the first institution is connected to the server 102 of the second institution via a communication network.

[0064] It should be noted that the payment message matching method, device, equipment, storage medium and program product of the present application can be used in the field of financial technology, and can also be used in any field outside the field of financial technology. The application field of the payment message matching method, device, equipment, storage medium and program product of the present application is not limited.

[0065] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0066] Figure 2 Schematic diagram of the payment message matching method provided in this application Figure 1 ,like Figure 2 As shown, the method is applied to the server of the first institution, and the specific process of the method may include:

[0067] S201. Receive a payment query message sent by a server of the second institution.

[0068] In this step, payment transactions between institutions need to be processed and confirmed efficiently and accurately. In order to achieve this goal, communication and data exchange between institutions are essential. This application takes the service end of the first institution and the service end of the second institution as an example to describe in detail the query process of the payment message.

[0069] Specifically, the server of the first institution receives the payment query message sent by the server of the second institution in real time.

[0070] In one possible implementation, the first institution refers to a financial institution or payment service provider that sends a payment message, and the second institution refers to a financial institution or payment service provider that receives a payment message. In this case, when the service end of the second institution receives the payment message sent from the service end of the first institution, in order to verify the accuracy and completeness of the payment message, the service end of the second institution will send a payment query message to the service end of the first institution. The service end of the first institution needs to receive and process the payment query message in real time. This interactive process ensures the accurate transmission and confirmation of transaction information, improves the security and reliability of payment transactions, and also enhances the trust and collaboration efficiency between the two institutions.

[0071] Among them, the payment query message includes detailed transaction information, including but not limited to the payment message identification number, payment remitting bank, payment receiving bank, payment amount, transaction date, transaction time, currency type, payer information, payee information, transaction purpose, protocol version, etc.

[0072] Specifically, the payment message identification number is a unique identifier used to identify a specific payment transaction to ensure that there is no confusion or duplication in the service end. The payment remittance bank refers to the information of the financial institution or payment service provider that initiates the payment, identifying the source of the funds. The payment receiving bank refers to the information of the financial institution or payment service provider that receives the payment, identifying the recipient of the funds. The payment amount refers to the amount of funds involved, ensuring that both parties have a consistent understanding and record of the transaction amount. The transaction date refers to the specific date when the transaction is initiated, used to record the time point of the transaction. The transaction time refers to the specific time when the transaction is initiated, usually marked in hours, minutes, and seconds, to help accurately locate it in the transaction record. The currency type refers to the type of currency used in the transaction, ensuring that both parties have a consistent understanding of the currency of the transaction amount, especially in cross-border transactions. The payer information refers to the detailed information of the payee, including name, account number or identifier, to ensure that the funds are transferred from the correct account. The payee information refers to the detailed information of the payee, including name, account number or identifier, to ensure that the funds are transferred to the correct account. The transaction purpose is used to describe the purpose or nature of the transaction, such as the purchase of goods, payment of services, or fund transfer, to help financial institutions conduct compliance checks. The protocol version refers to the communication protocol version used, which ensures that both systems exchange data under the same technical standards and avoids misunderstandings or errors caused by inconsistent protocols.

[0073] By including this detailed transaction information, the payment query message can provide both parties with sufficient data to verify and confirm the accuracy and completeness of the transaction, thereby supporting an efficient and secure payment processing process.

[0074] It is worth noting that the types of payment query messages include payment outward remittance query messages and payment inward remittance query messages.

[0075] Among them, the payment remittance query message means that after the first institution's service end sends the payment remittance message to the second institution's service end, in order to verify the accuracy of the payment information, the second institution's service end will further send the payment remittance query message to the first institution's service end after receiving the payment remittance message. This process ensures the accuracy and consistency of payment information in cross-institution transmission, and enhances the security and reliability of transactions.

[0076] The payment inward remittance query message refers to the situation in which, in the payment process, after the second institution's server has sent an outward payment remittance message to the first institution's server, the second institution's server will further send a payment inward remittance query message to the first institution's server in order to confirm the processing progress and status of the outward payment remittance message.

[0077] S202: Using a preset target index extraction strategy, identify a target index from the payment query message.

[0078] In this step, after receiving the payment query message sent from the service end of the second institution, the service end of the first institution needs to quickly and accurately determine the target payment message to be queried.

[0079] To achieve this goal, the present application proposes a preset target index extraction strategy, wherein the core of the target index extraction strategy is to parse the payment query message and identify the key target index therefrom.

[0080] By extracting the target index, the server of the first institution can quickly construct query conditions for efficiently locating the target payment message in the data table storing the payment message. Compared with traditional query methods, which usually rely on retrieving records one by one in the data table, resulting in high computational overhead and slow response time, the preset target index extraction strategy significantly narrows the scope of data to be searched by extracting the target index before querying.

[0081] In an optional implementation, the preset target index extraction strategy includes:

[0082] Determine a specific field in the payment query message as a target index;

[0083] The specific field includes at least one of the following fields: a payment message identification number, a payment remitting bank, and a payment receiving bank.

[0084] Specifically, the preset target index extraction strategy determines specific fields in the payment query message as the target index to achieve efficient payment message query and processing. This strategy aims to use the most recognizable and relevant fields in the payment query message to quickly locate the target payment message, thereby improving query efficiency and response speed.

[0085] The specific field includes at least one of the following fields: a payment message identification number, a payment remitting bank, and a payment receiving bank.

[0086] The payment message identification number is used to identify each payment transaction. By using this field as the target index, the server of the first institution can directly locate the specific payment message, avoiding unnecessary searches in large amounts of data, thereby shortening the query time.

[0087] Payment remittance bank refers to the information of the financial institution or payment service provider that initiated the payment. Using the payment remittance bank as one of the target indexes can help the server quickly narrow the scope when querying, especially when processing payment query messages from multiple institutions. This field can effectively limit the query to a specific initiating institution.

[0088] The receiving bank refers to the information of the financial institution or payment service provider that receives the payment. Similar to the payment remitting bank, the receiving bank acts as a target index to help the server quickly locate transactions involving a specific receiving institution.

[0089] By using the above-mentioned specific fields as target indexes, the server can quickly identify key information related to the query request in the payment query message.

[0090] It is worth noting that the above specific fields can be used in combination or individually to achieve a more flexible and efficient query strategy. At the same time, these specific fields are not limited to any one or any combination of the payment remittance message identification number, the payment remittance bank and the payment remittance bank, but can also include other key information. This flexibility enables the server to select the most suitable field combination according to the specific query requirements and transaction environment, thereby optimizing the query process. In this way, the server can better adapt to diverse business scenarios and improve the efficiency and accuracy of queries.

[0091] Optionally, if the type of the payment query message is an outgoing payment query message, a specific field in the outgoing payment query message is determined as a target index. The specific field includes at least one of the following fields: an outgoing payment message identification number, a payment remittance bank, and an incoming payment bank. If the type of the payment query message is an incoming payment query message, a specific field in the incoming payment query message is determined as a target index. The specific field includes at least one of the following fields: an incoming payment message identification number, a payment remittance bank, and an incoming payment bank.

[0092] The payment message matching method provided in the embodiment of the present application determines the specific field in the payment query message as the target index through a preset target index extraction strategy, significantly improving the query efficiency and accuracy, and the server can quickly locate the relevant payment message, reduce unnecessary data retrieval, and flexibly adapt to different query requirements and transaction environments. At the same time, the method reduces the server load, so that it can still run efficiently under high load conditions, and improves security and compliance through accurate field matching, enhancing the overall reliability of payment message queries.

[0093] S203: using the target index, determine the primary key of the target payment message from a preset payment message index table, where the payment message index table stores index information and a primary key of at least one payment message.

[0094] In this step, based on step S202, the server of the first institution adopts a preset target index extraction strategy, and after identifying the target index from the payment query message, searches for the primary key of the target payment message in the preset payment message index table based on the target index, thereby laying the foundation for further identifying the target payment message.

[0095] It is worth noting that the payment message index table stores index information of at least one payment message and a corresponding primary key. Among them, the index information of the payment message is extracted based on the information included in the payment message. In one possible implementation, the index information of the payment message is the payment message identification number, the payment remittance bank, and the payment remittance bank. In another possible implementation, the index information of the payment message is the payment message identification number and the transaction time. Therefore, the index information of the payment message is determined according to the specific usage scenario and actual needs, and this application does not make specific limitations on this.

[0096] The primary key is used to uniquely identify each payment message, ensuring the uniqueness of each payment message in the database. When storing the payment message in the corresponding data table, the database will automatically generate a unique primary key to accurately distinguish and manage each message.

[0097] When executing this step, the server searches in a preset payment message index table based on the target index identified in step S202. By matching the index information in the payment message index table, the server can quickly determine the primary key of the payment message corresponding to the target index.

[0098] It is worth noting that the determined primary key can be used to obtain the complete data of the target payment message. The specific implementation method can refer to step S204 and will not be repeated here. This process not only improves the query speed, but also reduces the consumption of server-side resources, so that the server can still maintain efficient operation under high load conditions. At the same time, the accuracy and reliability of the query can also be improved through the index matching method. Specifically, the use of the payment message index table can reduce the possibility of mismatching and ensure that each query can return the correct payment message, so that it can flexibly adapt to different query requirements and transaction environments, and enhance the overall reliability and security of payment message query and processing.

[0099] In one possible implementation, if the type of the payment query message is a payment remittance query message, the target index is used to determine the primary key of the target payment remittance message from a preset payment remittance message index table, and the payment remittance message index table stores index information and primary key of at least one payment remittance message.

[0100] In another possible implementation, if the type of the payment query message is a payment remittance query message, the target index is used to determine the primary key of the target payment remittance message from a preset payment remittance message index table, and the payment remittance message index table stores index information and primary key of at least one payment remittance message.

[0101] S204. Determine the target payment message from a preset payment message record table using the primary key. The payment message record table stores at least one primary key and transaction information.

[0102] In this step, the target payment message is determined from the preset payment message record table through the primary key determined in step S203.

[0103] The payment message record table is intended to comprehensively record the complete information of each payment message. Specifically, the payment message record table stores at least one primary key of a payment message and transaction information.

[0104] The primary key is a field or combination of fields used to uniquely identify each payment message, which ensures that the server can accurately locate and retrieve a specific payment message. The existence of the primary key enables the server to quickly and accurately find the required target payment message when processing a large number of payment query messages, thereby avoiding the inefficient operation of scanning the entire database one by one.

[0105] The transaction information is the core content of the payment message, including but not limited to the payment message identification number, payment remitting bank, payment receiving bank, payment amount, transaction date, transaction time, currency type, payer information, payee information, transaction purpose, protocol version, etc. It is worth noting that the meaning of the specific content in the transaction information can be referred to step S201, which will not be repeated here.

[0106] When executing this step, the server uses the primary key to search in the payment message record table. In this way, the server can efficiently retrieve the payment message corresponding to the primary key and determine it as the target payment message. This process not only improves the efficiency of target payment message retrieval, but also ensures the accuracy and completeness of the target payment message. Through this method, the server can maintain efficient performance in a complex query environment, can quickly respond to query requests, and provide reliable target payment message support.

[0107] In a possible implementation, if the type of the payment query message is a payment remittance query message, the target payment remittance message is determined from a preset payment remittance message record table through a primary key, and the payment remittance message record table stores at least one primary key and transaction information.

[0108] In another possible implementation, if the type of the payment query message is a payment remittance query message, the target payment remittance message is determined from a preset payment remittance message record table through a primary key, and the payment remittance message record table stores at least one primary key and transaction information.

[0109] S205. Generate a payment inquiry reply message according to the target payment message and the payment inquiry message.

[0110] In this step, the service end of the first institution further generates a payment inquiry message according to the target payment message obtained in step S204 and the payment inquiry message received in step S201.

[0111] The target payment message is the specific transaction record retrieved by the server from the payment message record table in step S204. It contains all the detailed information related to the transaction and can be used as the basic data for the generated payment inquiry reply message.

[0112] The payment query message is a payment query message sent by the server of the second institution, which contains information used to query a specific payment transaction and is intended to help the server of the first institution locate the target payment message in order to obtain relevant transaction information.

[0113] The payment inquiry reply message is a response message generated by the server of the first institution based on the contents of the target payment message and the payment inquiry message.

[0114] In one possible implementation, the content included in the payment reply message is the detailed information of the queried transaction, the transaction status, the processing result, and any relevant additional information, so as to ensure that the server of the second institution can fully understand the query result. Specifically, first, the server of the first institution integrates the detailed transaction information in the target payment message with the request information in the payment query message to obtain the integrated information to ensure the integrity and accuracy of the payment reply message. Then, the server of the first institution generates a payment reply message according to a predetermined format with the integrated information. The formatting process can ensure that the payment reply message complies with the communication protocol and standards between the first institution and the second institution, so as to facilitate the second institution's server to parse and process. Finally, the following step S206 will be executed. The specific implementation method can refer to step S206, which will not be repeated here.

[0115] Optionally, before generating the payment inquiry message, the server of the first institution will verify all data in the target payment message to ensure that all information is up-to-date and accurate, thereby avoiding the transmission of erroneous information.

[0116] In a possible implementation, if the type of the payment query message is a payment remittance query message, a payment remittance reply message is generated according to the target remittance payment message and the payment remittance query message.

[0117] In another possible implementation, if the type of the payment query message is a payment remittance query message, a payment remittance reply message is generated according to the target remittance payment message and the payment remittance query message.

[0118] S206. Return the payment inquiry message to the server of the second institution.

[0119] In this step, after the server of the first institution generates a payment inquiry message according to step S205, it will further return the payment inquiry message to the server of the second institution.

[0120] Specifically, the server of the first institution sends the payment reply message to the server of the second institution through a secure communication channel. It is worth noting that this process needs to ensure the integrity and security of the data to prevent the information from being tampered with or lost during transmission.

[0121] After sending the payment inquiry message to the server of the second institution, the server of the first institution will wait for the server of the second institution to confirm that the payment inquiry message has been successfully received, thereby further ensuring the reliability of information transmission.

[0122] Through the above steps, the server of the first institution completes a complete closed loop from receiving the payment inquiry message to providing the payment inquiry reply message. The whole process is designed to ensure the accuracy, timeliness and security of the information, so that the server of the second institution can make further business processing or decisions based on the returned payment inquiry reply message.

[0123] Through the efficient payment reply message generation and transmission mechanism, not only the response speed is improved, but also the transparency and traceability of transaction information are enhanced, providing reliable technical support for the business interaction between the two parties.

[0124] In a possible implementation, if the type of the payment query message is a payment remittance query message, the payment remittance reply message is returned to the service end of the second institution.

[0125] In another possible implementation, if the type of the payment query message is a payment remittance query message, the payment remittance inquiry reply message is returned to the service end of the second institution.

[0126] The payment message matching method provided in the embodiment of the present application determines the target payment message through the payment query message and generates a payment reply message. Specifically, the method uses a preset target index extraction strategy to identify the target index from the payment query message, and finds the primary key of the target payment message in the payment message index table through the index. Subsequently, the target payment message is located from the payment message record table through the primary key, and the payment reply message is finally generated. The method improves matching efficiency, narrows the search scope, reduces data processing time, and ensures the accuracy and consistency of the query results.

[0127] Figure 3 Schematic diagram of the payment message matching method provided in this application Figure 2 ,like Figure 3 As shown, in this embodiment Figure 2Based on the embodiment, a processing process before the service end of the first institution receives the payment query message sent by the service end of the second institution is described in detail. The method includes:

[0128] S301. Generate a payment message in response to a user's payment operation.

[0129] In this step, before the second institution's server sends a payment query message to the first institution's server, the first institution's server needs to generate a payment message in advance and transmit the generated payment message to the second institution's server. Therefore, this step mainly describes the process of the first institution's server generating a payment message.

[0130] Specifically, the server of the first institution generates a payment message in response to the user's payment operation. The user's payment operation includes but is not limited to online shopping, inter-financial institution transfer, bill payment, etc. These operations will trigger the server of the first institution to automatically generate a payment message. It is worth noting that the payment message is a detailed record of the user's payment operation. The specific content included in the payment message can be referred to step S201, which will not be repeated here.

[0131] It is worth noting that on the service side of the first institution, payment messages are divided into payment outgoing messages and payment incoming messages.

[0132] Among them, in response to the user's payment operation, the payment message generated is a payment remittance message, and the payment remittance message will be further sent to the service end of the second institution.

[0133] The payment inward remittance message is the payment outward remittance message sent by the second institution's service end and received by the first institution's service end. Specifically, when the second institution's service end generates a payment outward remittance message in response to the user's payment operation, it sends the payment outward remittance message to the first institution's service end, and the first institution's service end determines the message as a payment inward remittance message.

[0134] In the distributed payment system of domestic and foreign currencies, the first institution and the second institution can query the payment message sent or received by the first institution. The scenarios involved are mainly:

[0135] The first institution sends a payment remittance message to the second institution. The second institution may send a payment remittance query message to the first institution in response to the payment remittance message. The first institution returns a payment remittance reply message to the second institution based on the payment remittance query message.

[0136] The second institution sends a payment remittance message to the first institution. The second institution may send a payment remittance query message to the first institution in response to the payment remittance message. The first institution returns a payment remittance reply message to the second institution based on the payment remittance query message.

[0137] S302: Determine the index information and primary key of the payment message according to the target index extraction strategy.

[0138] In this step, the server of the first institution will simultaneously record the payment message while sending the payment message generated in step S301 to the server of the second institution.

[0139] Among them, when recording the payment message, in order to improve the execution efficiency of the subsequent payment query message to determine the target payment message process, this application will determine the index information and primary key based on the payment message, and store it in the corresponding table to accelerate the subsequent payment message retrieval and management.

[0140] Specifically, the server of the first institution determines the index information and primary key of the payment message according to the target index extraction strategy, wherein the target index extraction strategy is a set of predefined rules or algorithms, which is intended to extract a field that can uniquely identify the payment message from the payment message.

[0141] In a possible implementation, the server of the first institution first parses the payment message and identifies the key fields, and then determines at least one field that best represents the payment message from the key fields as the index information of the payment message according to the preset target index extraction strategy, such as any one or any combination of the payment remittance message identification number, the payment remittance bank, and the payment remittance bank. Finally, in order to ensure the uniqueness and immutability of the primary key, the server of the first institution generates the primary key in a manner including but not limited to any one or any combination of the automatic generation of a unique identifier and the timestamp-based manner. Among them, the automatic generation of a unique identifier refers to the application of universal unique identifier technology to ensure that each primary key is unique worldwide. The generation of the primary key based on the timestamp refers to creating a unique identifier by combining the current date and time information. This creation method can not only ensure uniqueness, but also provide certain time sequence information. In order to further enhance the security and uniqueness of the primary key, the server can also use the above methods in combination, such as adding a randomly generated numerical value or hash value based on the timestamp. This multi-level generation strategy not only improves the uniqueness and immutability of the primary key, but also enhances the reliability and efficiency of the server when processing complex payment messages.

[0142] It is worth noting that if the payment message is an outgoing payment message, the index information and primary key of the outgoing payment message are determined according to the target index extraction strategy. If the payment message is an incoming payment message, the index information and primary key of the incoming payment message are determined according to the target index extraction strategy.

[0143] S303. Store the transaction information of the payment message into the payment message record table based on the primary key.

[0144] In this step, the service end of the first institution stores the transaction information of the payment message into the payment message record table based on the primary key of the payment message determined in step S302.

[0145] Specifically, when the server stores the transaction information of the payment message in the payment message record table, it will synchronously store the primary key determined by step S302. It is worth noting that the index information determined in step S302 is part of the payment message transaction information and does not need to be repeatedly synchronously stored. This method not only simplifies the storage process, but also avoids the generation of redundant data, thereby improving the storage efficiency of the server and the simplicity of data management.

[0146] Optionally, in order to ensure the accuracy and completeness of the transaction information, the server of the first institution verifies the transaction information in the payment message before storing it. When performing the storage operation, the server of the first institution processes the payment message according to the predefined storage format. At the same time, by using the primary key, the uniqueness and traceability of each payment message in the database are ensured.

[0147] It is worth noting that when processing a payment message, the server of the first institution will perform different storage operations depending on the type of payment message.

[0148] Specifically, if the payment message is an outward payment message, the server of the first institution stores the transaction information of the outward payment message in the outward payment message record table based on the primary key. The outward payment message record table stores at least one primary key and transaction information of the outward payment message.

[0149] Correspondingly, if the payment message is an incoming payment message, the service end of the first institution stores the transaction information of the incoming payment message in the incoming payment message record table based on the primary key. The incoming payment message record table stores at least one primary key and transaction information of the incoming payment message.

[0150] By storing different types of payment messages in corresponding record tables, the server of the first institution can effectively organize and manage transaction data. This classified storage method not only improves the efficiency of payment message retrieval, but also enhances the traceability and security of payment messages.

[0151] S304: Store the index information and primary key of the payment message into the payment message index table.

[0152] In this step, in order to improve the matching efficiency of the payment query message, the present application stores the index information and primary key of the payment message in the payment message index table.

[0153] Specifically, in order to optimize the query efficiency of payment messages and enable the server to maintain efficient performance when processing large amounts of data, it is necessary to reasonably select the storage method.

[0154] In one possible implementation, the index information and the primary key are combined into an index record for storage. In this way, the index information and the primary key are integrated into a whole to form a composite key. This composite key exists as a single record in the payment message index table, and can obtain the index information and the primary key at the same time through a single retrieval operation during query. The advantage of this implementation is that it simplifies the data structure, making the query operation more direct and efficient, especially when it is necessary to access the index information and the primary key at the same time, it can reduce the number of database accesses and improve the query speed.

[0155] In another possible implementation, the index information and the primary key are stored as two independent index records in the payment message index table. In this case, the index information and the primary key each exist as a separate record in the payment message index table. The advantage of this implementation is that it is more flexible because it allows the server to selectively access the index information or the primary key according to specific needs when querying. This provides greater convenience for certain application scenarios that need to process the index information and the primary key separately. At the same time, this implementation also helps to more conveniently perform update operations when the index information or the primary key changes, without having to modify the entire composite record.

[0156] It is worth noting that the present application does not impose any specific restrictions on the specific implementation method of storing the index information and primary key of the payment message in the payment message index table, and can be personalized according to actual needs.

[0157] At the same time, the server will regularly update and maintain the payment message index table to ensure the consistency and integrity of the data.

[0158] Optionally, in a possible implementation, after a payment message is generated, the server first stores the payment message in a payment message record table. During the storage process, the database system automatically generates a storage number and uses it as the primary key of the payment message. Next, the server determines the index information of the payment message according to a preset target index extraction strategy. Finally, the server stores the generated index information and the storage number together in the payment message index table. This process ensures that the payment message can be stored immediately after it is generated, reducing the risk of data temporary storage or loss. At the same time, by automatically generating a storage number as the primary key, the server can quickly assign a unique identifier to each payment message, thereby simplifying the complexity of primary key generation.

[0159] It is worth noting that the server of the first institution will perform different storage operations according to the type of payment message. Specifically, if the payment message is a payment remittance message, the server of the first institution will store the index information and primary key of the payment remittance message in the payment remittance message index table. Among them, the payment remittance message index table stores the index information and primary key of at least one payment remittance message.

[0160] Correspondingly, if the payment message is an incoming payment message, the server of the first institution stores the index information and primary key of the incoming payment message in the incoming payment message index table, wherein the incoming payment message index table stores the index information and primary key of at least one incoming payment message.

[0161] By storing the index information and primary keys of different types of payment messages in the corresponding index tables, the server of the first institution can manage and retrieve transaction data more efficiently. This classified storage strategy not only improves the efficiency of data access, but also enhances the organization and security of data, ensuring that specific transaction information can be quickly and accurately located and processed when needed.

[0162] The payment message matching method provided in the embodiment of the present application stores the transaction information of the payment message in the payment message record table by extracting the primary key determined by the target index extraction strategy, and stores the index information and primary key determined by the target index extraction strategy in the payment message index table in a timely manner. This synchronous storage mechanism effectively improves the data consistency and integrity of the payment message. With this mechanism, the server can quickly and efficiently retrieve the required payment message information in subsequent query and matching operations, thereby significantly improving the overall processing efficiency and response speed.

[0163] Figure 4 Schematic diagram of the payment message matching method provided in this application Figure 3 ,like Figure 4 As shown, in this embodiment Figure 2 Examples and Figure 3 Based on the embodiment, the method further comprises:

[0164] S401. Store the primary key of the target payment message, the query type in the payment query message, and the query result in the payment reply message into a preset payment query reply message record table.

[0165] In this step, after the first institution's server generates a payment inquiry reply message, in order to achieve efficient business inquiry in subsequent operations, this application proposes a method for storing payment inquiry reply records. The core of this method is to improve inquiry efficiency and data management accuracy through systematic record management, and provide support for business process optimization.

[0166] Specifically, after generating the payment inquiry reply message, the server of the first institution will store the primary key of the target payment message, the inquiry type in the payment inquiry message, and the inquiry result in the payment inquiry reply message in a preset payment inquiry reply message record table.

[0167] The primary key of the target payment message serves as the unique identifier of each payment message, ensuring the uniqueness and traceability of the record. The storage of this information enables the server to quickly locate the specific payment transaction, facilitating subsequent query and analysis.

[0168] The query type in the payment query message provides detailed information about the purpose and nature of the query. This field helps the server to classify and analyze different types of query requests and supports the optimization and adjustment of business processes. For example, the server can identify common query requirements based on the query type data, thereby optimizing the service response strategy.

[0169] The query results in the payment query reply message record the specific output of the query operation, including the success or failure status and related detailed information. Storing this information facilitates subsequent review and verification, ensuring the transparency and accuracy of the query operation.

[0170] By storing this key information in the payment query reply message record table, the server can quickly retrieve and analyze historical query records when needed. This record management method not only improves the efficiency of query operations, but also enhances the traceability and transparency of data. For business analysis and decision-making, these records provide reliable data support, help identify trends, optimize processes, and improve customer satisfaction.

[0171] It is worth noting that different types of payment query messages correspond to different types of payment reply messages.

[0172] Specifically, if the type of the payment query message is a payment remittance query message type, then the type of the payment reply message is a payment remittance reply message. In this case, the server of the first institution stores the primary key of the target payment remittance message, the query type in the payment remittance query message, and the query result in the payment remittance reply message into a preset payment remittance query reply message record table. Among them, the payment remittance reply message includes the payment remittance query result and the transaction information of the payment remittance message. Among them, the payment remittance query result may be that the transaction information is accurate, etc.

[0173] If the type of the payment query message is a payment remittance query message type, then the type of the payment reply message is a payment remittance reply message. In this case, the server of the first institution stores the primary key of the target payment remittance message, the query type in the payment remittance query message, and the query result in the payment remittance reply message into a preset payment remittance query reply message record table. The payment remittance reply message includes the payment remittance query result and the transaction information of the payment remittance message. The payment remittance query result may be that the transaction has been completed, the transaction is in progress, etc.

[0174] The payment message matching method provided in the embodiment of the present application lays a solid foundation for efficient business query and data management by systematically storing and managing payment query and reply records. This method not only improves the operating efficiency of the service end, but also provides important support for the continuous optimization of business processes.

[0175] Figure 5 A schematic diagram of the structure of the payment message matching device provided in this application, such as Figure 5 As shown, the payment message matching device 500 provided in this embodiment includes:

[0176] Receiving module 501, used to receive the payment query message sent by the service end of the second institution;

[0177] Processing module 502, used to identify the target index from the payment query message using a preset target index extraction strategy;

[0178] The processing module 502 is further used to determine the primary key of the target payment message from a preset payment message index table using the target index, where the payment message index table stores index information and a primary key of at least one payment message;

[0179] The processing module 502 is further used to determine the target payment message from a preset payment message record table by using a primary key, wherein the payment message record table stores a primary key and transaction information of at least one payment message;

[0180] The processing module 502 is further used to generate a payment inquiry reply message according to the target payment message and the payment inquiry message;

[0181] The sending module 503 is used to return the payment inquiry message to the service end of the second institution.

[0182] In a possible implementation, the preset target index extraction strategy includes: determining a specific field in the payment query message as the target index; wherein the specific field includes at least one of the following fields: a payment message identification number, a payment remittance bank, and a payment receiving bank.

[0183] In a possible implementation, the processing module 502 is further configured to:

[0184] In response to a user's payment operation, generating a payment message;

[0185] Determine the index information and primary key of the payment message according to the target index extraction strategy;

[0186] The transaction information of the payment message is stored in the payment message record table based on the primary key;

[0187] The index information and primary key of the payment message are stored in the payment message index table.

[0188] In a possible implementation, the processing module 502 is further configured to:

[0189] The primary key of the target payment message, the query type in the payment query message, and the query result in the payment query reply message are stored in a preset payment query reply message record table.

[0190] In a possible implementation, the payment reply message includes:

[0191] The query result of the payment query message and the transaction information in the target payment message.

[0192] In a possible implementation, the payment query message is a payment remittance query message.

[0193] Correspondingly, the payment message index table is a payment remittance message index table, and the payment remittance message index table stores index information and a primary key of at least one payment remittance message;

[0194] The payment message record table is a payment remittance message record table, and the payment remittance message record table stores at least one primary key and transaction information of a payment remittance message;

[0195] The payment inquiry reply message is a payment remittance inquiry reply message, which includes the payment remittance inquiry result and the transaction information of the payment remittance message.

[0196] In a possible implementation, the payment query message is a payment remittance query message.

[0197] Correspondingly, the payment message index table is a payment inward remittance message index table, and the payment inward remittance message index table stores index information and a primary key of at least one payment inward remittance message;

[0198] The payment message record table is a payment inward remittance message record table, and the payment inward remittance message record table stores at least one primary key and transaction information of a payment inward remittance message;

[0199] The payment inquiry reply message is a payment inward remittance inquiry reply message, which includes the payment inward remittance inquiry result and the transaction information of the payment inward remittance message.

[0200] The payment message matching device provided in this embodiment can execute the method provided in the above method embodiment, and its implementation principle and technical effect are similar, which will not be described in detail in this embodiment.

[0201] Figure 6 This is a schematic diagram of the server structure provided for this application. Figure 6 As shown, the server 600 provided in this embodiment includes: at least one processor 601 and a memory 602. Optionally, the server 600 also includes a communication component 603. The processor 601, the memory 602 and the communication component 603 are connected via a bus.

[0202] In a specific implementation process, at least one processor 601 executes the computer execution instructions stored in the memory 602, so that at least one processor 601 executes the above method.

[0203] The specific implementation process of the processor 601 can be found in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be repeated here.

[0204] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the invention may be directly implemented as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor.

[0205] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (Non-volatile Memory, NVM), such as at least one disk memory.

[0206] The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of the present application is not limited to only one bus or one type of bus.

[0207] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0208] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

[0209] The above-mentioned readable 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 read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.

[0210] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (Application Specific Integrated Circuits, referred to as: ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0211] The division of units is only a logical function division, and there may be other divisions in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0212] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0213] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0214] If the function is implemented in the form of 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 solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, and other media that can store program codes.

[0215] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, magnetic disk or optical disk and other media that can store program codes.

[0216] Finally, it should be noted that those skilled in the art will readily conceive of other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any variations, uses or adaptations of the present application, which follow the general principles of the present application and include common knowledge or customary technical means in the art that are not disclosed in the present application, are not limited to the precise structures described above and shown in the drawings, and may be modified and changed in various ways without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A payment message matching method, characterized in that: Applied to the server of the first institution, the method comprises: Receiving a payment query message sent by a server of the second institution; Using a preset target index extraction strategy to identify a target index from the payment query message; Using the target index, determining a primary key of the target payment message from a preset payment message index table, wherein the payment message index table stores index information and a primary key of at least one payment message; Determine the target payment message from a preset payment message record table by using the primary key, wherein the payment message record table stores at least one primary key of the payment message and transaction information; Generate a payment inquiry reply message according to the target payment message and the payment inquiry message; The payment inquiry message is returned to the server of the second institution.

2. The method according to claim 1, characterized in that The preset target index extraction strategy includes: Determining a specific field in the payment query message as a target index; The specific field includes at least one of the following fields: a payment message identification number, a payment remitting bank, and a payment receiving bank.

3. The method according to claim 1, characterized in that Before receiving the payment query message sent by the service end of the second institution, the method further includes: In response to a user's payment operation, generating a payment message; Determine the index information and primary key of the payment message according to the target index extraction strategy; storing the transaction information of the payment message in the payment message record table based on the primary key; The index information and primary key of the payment message are stored in the payment message index table.

4. The method according to claim 1, characterized in that: The method further comprises: The primary key of the target payment message, the query type in the payment query message, and the query result in the payment reply message are stored in a preset payment query reply message record table.

5. The method according to claim 1, characterized in that The payment reply message includes: The query result of the payment query message and the transaction information in the target payment message.

6. The method according to any one of claims 1 to 5, characterized in that: The payment query message is a payment remittance query message. Correspondingly, the payment message index table is a payment remittance message index table, and the payment remittance message index table stores index information and a primary key of at least one payment remittance message; The payment message record table is a payment remittance message record table, and the payment remittance message record table stores at least one primary key and transaction information of a payment remittance message; The payment inquiry reply message is a payment remittance inquiry reply message, and the payment remittance inquiry reply message includes a payment remittance query result and transaction information of the payment remittance message.

7. The method according to any one of claims 1 to 5, characterized in that: The payment inquiry message is a payment inward inquiry message. Correspondingly, the payment message index table is a payment inward remittance message index table, and the payment inward remittance message index table stores index information and a primary key of at least one payment inward remittance message; The payment message record table is a payment inward remittance message record table, and the payment inward remittance message record table stores at least one primary key and transaction information of a payment inward remittance message; The payment inquiry reply message is a payment inward remittance inquiry reply message, and the payment inward remittance inquiry reply message includes a payment inward remittance query result and transaction information of the payment inward remittance message.

8. A payment message matching device, characterized in that: include: A receiving module, used for receiving a payment query message sent by a service end of the second institution; A processing module, configured to adopt a preset target index extraction strategy to identify a target index from the payment query message; The processing module is further used to determine the primary key of the target payment message from a preset payment message index table using the target index, wherein the payment message index table stores index information and a primary key of at least one payment message; The processing module is further used to determine the target payment message from a preset payment message record table by using the primary key, wherein the payment message record table stores a primary key and transaction information of at least one payment message; The processing module is further used to generate a payment inquiry reply message according to the target payment message and the payment inquiry message; The sending module is used to return the payment inquiry message to the service end of the second institution.

9. A server, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs 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 computer-executable instructions, which are used to implement the method according to any one of claims 1 to 7 when executed by a processor.

Images