CN115239494A

CN115239494A - Payment transaction processing method and device

Info

Publication number: CN115239494A
Application number: CN202210877182.5A
Authority: CN
Inventors: 石毅
Original assignee: Bank of China Ltd
Current assignee: Bank of China Ltd
Priority date: 2022-07-25
Filing date: 2022-07-25
Publication date: 2022-10-25

Abstract

The invention discloses a payment transaction processing method and a device, which relate to a distributed type, wherein the method comprises the following steps: after payment transaction initiation of a transaction initiation system is received, determining micro-services to be mobilized and a mobilizing sequence according to transaction types; receiving and storing processing results returned by each micro service, and processing according to the service requirements of the transaction type in a payment service scene according to the position and sequence of the abnormal micro service in the payment transaction when the micro service is determined to be abnormal according to the processing results; and storing the processing result returned by each micro-service in a main database. The invention can ensure the consistency of the transaction processing result and the account, and avoid the condition that the transaction processing fails but the customer account is deducted; by the design scheme of asynchronously writing the stock transaction information, the reliability of transaction information transmission is ensured, and the concurrency performance of the system is improved.

Description

Payment transaction processing method and device

Technical Field

The invention relates to the field of distributed technologies, in particular to a payment transaction processing method and device.

Background

In traditional monolithic applications, data consistency is generally guaranteed through transactions. A transaction at the data plane means that a group of atomic operations must all be performed successfully in a specified order. If any one atomic operation fails, the set of atomic operations is rolled back to the original state.

In a traditional business environment, the atomic data operations are all completed on the same database instance, and in a distributed system, a transaction may span two or more system database instances, so that a traditional transaction management mechanism is not suitable for a distributed real-time payment system.

That is, the deficiency of the prior art is that there is no technical scheme for guaranteeing transaction consistency in the distributed real-time payment system, and the situation that the customer account is deducted when transaction processing fails can be avoided.

Disclosure of Invention

The embodiment of the invention provides a payment transaction processing method, which is used for solving the problem that a technical scheme for ensuring transaction consistency does not exist in a distributed real-time payment system and the condition that a customer account is deducted when transaction processing fails can be avoided, and the method comprises the following steps:

after payment transaction initiation of a transaction initiation system is received, determining micro-services to be mobilized and a mobilizing sequence according to transaction types;

receiving and storing processing results returned by each micro service, and processing according to the service requirements of the transaction type in a payment service scene according to the position and sequence of the abnormal micro service in the payment transaction when the micro service is determined to be abnormal according to the processing results;

and storing the processing result returned by each micro-service in a main database.

The embodiment of the invention also provides a payment transaction processing device, which is used for solving the problem that the condition that a client account is deducted when transaction processing fails is avoided because a technical scheme for ensuring transaction consistency does not exist in a distributed real-time payment system, and the device comprises:

the receiving module is used for determining the microservice to be mobilized and the mobilizing sequence according to the transaction type after receiving payment transaction initiation of the transaction initiation system;

the processing module is used for receiving and storing processing results returned by the micro-services, and processing the micro-services according to the position and sequence of the abnormal micro-services in the payment transaction and the service requirements of the transaction type in the payment service scene when the micro-services are determined to be abnormal according to the processing results;

and the storage module is used for storing the processing results returned by the micro services in a main database.

The embodiment of the invention also provides computer equipment which comprises a memory, a processor and a computer program which is stored on the memory and can run on the processor, wherein the processor realizes the payment transaction processing method when executing the computer program.

An embodiment of the present invention further provides a computer-readable storage medium, where a computer program is stored, and when the computer program is executed by a processor, the method for processing a payment transaction is implemented.

An embodiment of the present invention further provides a computer program product, where the computer program product includes a computer program, and when executed by a processor, the computer program implements the above payment transaction processing method.

In the embodiment of the invention, compared with the technical scheme that only the consistency under the atomic data operation under the traditional service environment can be supported in the prior art, aiming at the characteristics of the distributed real-time payment system, on one hand, the consistency compensation of transaction processing is realized by additionally processing the exception. Furthermore, due to the fact that the functions of updating the abnormal state, sending the notification and the receipt and compensating the transaction can be completed through the abnormal processing, the abnormality after the account processing is corrected and compensated by combining the particularity of the real-time payment service, and the transaction state updating and the abnormal information recording are performed on the abnormality before the account processing.

On the other hand, an asynchronous library writing mode is adopted, processing results returned by the micro services are received and stored, after exception handling is carried out, the processing results returned by the micro services are stored in a main database in a unified mode, the reliability of transaction information transmission is guaranteed, meanwhile, the waiting time of the micro services is reduced, and the concurrency of a distributed system is improved.

Therefore, the consistency of the transaction processing result and the account is ensured, and the condition that the client account is deducted due to transaction processing failure is avoided; by the design scheme of asynchronously writing the stock transaction information, the reliability of transaction information transmission is ensured, and the concurrency performance of the system is improved.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts. In the drawings:

FIG. 1 is a schematic flow chart illustrating an implementation of a payment transaction processing method according to an embodiment of the present invention;

FIG. 2 is a diagram illustrating a payment transaction architecture according to an embodiment of the present invention;

FIG. 3 is a schematic diagram of a payment transaction processing flow according to an embodiment of the present invention;

FIG. 4 is a flow diagram illustrating a process for iterative import transaction processing according to an embodiment of the present invention;

fig. 5 is a schematic structural diagram of a payment transaction processing apparatus according to an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present invention more apparent, the embodiments of the present invention are further described in detail below with reference to the accompanying drawings. The exemplary embodiments and descriptions of the present invention are provided to explain the present invention, but not to limit the present invention.

The inventor notices in the process of invention that:

the existing distributed real-time payment system is a global real-time payment system based on a cloud platform micro-service architecture. The global integrated system supports overseas institutions to be connected with local small-amount real-time payment systems, so that real-time processing of local clearing and remitting transactions is achieved, efficiency is further improved, cost is saved, management is enhanced, and overseas institutions are better supported to provide high-quality payment clearing service for customers.

Microservice is a software architecture style based on small functional blocks dedicated to a single responsibility and function, combined into complex large-scale applications in a modular fashion, with each functional block communicating with each other using a conventional API.

Because the distributed real-time payment system does not have a technical scheme for guaranteeing the transaction consistency, the condition that the client account is deducted when the transaction processing fails can be avoided. The technical scheme provided by the embodiment of the invention mainly solves the problem of how to ensure the final consistency of the transaction in the distributed real-time payment system. Unlike single applications, multiple logical operations of a transaction in a distributed system are split into remote calls between multiple services. While the distributed architecture provides better scalability and availability to the system, it also carries the risk of data inconsistency since multiple services are not in the same transaction with each other. Aiming at the problem of transaction consistency brought by a distributed architecture, the technical scheme provided by the embodiment of the invention provides a solution for ensuring the consistency of payment transaction by combining the service characteristics of the payment transaction.

Based on this, due to the business particularity of the payment transaction, the technical scheme provided by the embodiment of the invention provides a new idea for ensuring the final consistency of the transaction in the distributed payment system from the perspective of business compensation and asynchronous library writing, so as to ensure that the problem of inconsistent financial affairs caused by loss or system abnormity does not occur in the whole transaction processing process.

In order to ensure the final consistency of payment transaction processing in the distributed real-time payment system, the technical scheme provided by the embodiment of the invention mainly adopts the following two measures to ensure:

(1) A consistency compensation mechanism.

The consistency compensation mechanism is used for acquiring a complete executed path of a service according to a certain means when rollback operation is required, so that reverse operation conforming to a service rule is realized. Due to the particularity of the financial payment transaction, although a plurality of logic processing nodes are involved in the transaction processing process, the accounting node is the core operation of the whole payment process, so that a set of exception handling schemes can be designed for a distributed architecture to complete consistency compensation.

In a distributed real-time payment system, a payment service combination service generally needs to include a plurality of micro services such as message parsing, report checking, debit recognition, credit recognition, accounting and the like. The exception handling function designed in the technical scheme provided by the embodiment of the invention runs through the whole process of service processing, and the exception handling module mainly completes the functions of updating an exception state, sending a notification and a receipt and compensating a transaction. Due to the particularity of the real-time payment transaction, only the abnormality after the accounting processing needs to be compensated, and the abnormality in other scenes does not need to be compensated, and only the updating of the transaction state and the recording of the abnormal information need to be finished, so that the monitoring is facilitated.

(2) And (4) asynchronously writing the library.

The reliable asynchronous message storage mechanism can ensure that the transaction information is not lost without any reason, and can continue to execute subsequent operations after the message is sent without waiting for the feedback of the message receiver.

In the distributed real-time payment system, each micro service represents a business processing logic unit, and the sequential arrangement and execution of the micro services are realized through a combined service layer, so that the complete processing of a payment transaction is completed. After each micro service finishes the service processing, the processed transaction is sent to a message queue, and at the moment, the current micro service can continue to process the next transaction. And after monitoring the messages of the message queue, the upper-layer service uniformly stores and updates the transaction information to the master library.

Fig. 1 is a schematic flow chart of an implementation of a payment transaction processing method, which may include:

step 101, after receiving payment transaction initiation of a transaction initiation system, determining micro-services to be mobilized and a mobilizing sequence according to transaction types;

102, receiving and storing processing results returned by each micro-service, and processing according to the position and sequence of the abnormal micro-service in the payment transaction and the service requirement of the transaction type in the payment service scene when the micro-service is determined to be abnormal according to the processing results;

and 103, storing the processing results returned by the micro services in a main database.

First, the features involved in the scheme will be explained in a unified manner.

Micro-service architecture: an architecture design method suitable for distributed application development. In contrast to single application, all functions are not packaged into an independent single application program, but are split into a plurality of micro-service units according to functions based on a single responsibility principle, and each micro-service unit completes relatively independent service logic.

Micro-service: a software architecture style is based on small functional blocks dedicated to single responsibility and function, and is combined into a complex large Application program by a modularized mode, and all the functional blocks use a conventional API (Application Programming Interface) to communicate with each other.

And (3) combined service: the existing microservices of the system are flexibly assembled to meet various business processing requirements. A composite service may contain multiple microservices.

Affairs: in a series of rigorous operations in an application, all operations must complete successfully, otherwise all changes made in each operation are undone. Has four basic elements of atomicity, consistency, isolation and durability.

A master library: the MDB (master database) is a place for centrally storing and managing historical filing data, and permanently keeps standardized data which has long-term retention value and sharing requirement and is verified by data quality inspection. In the distributed real-time payment system, the main library is mainly used for storing payment transaction contents and transaction states.

And (3) synchronously writing a library: and maintaining the connection during the database writing process, and disconnecting after all the operations are finished and a return result is received.

Asynchronous writing of the library: after the data is put in the designated message queue and the feedback is received, the connection can be disconnected without waiting for the completion of all the operations.

Kalfa: a high throughput distributed publish-subscribe messaging system that can handle all the activity flow data of a consumer in a web site.

In implementation, the processing according to the service requirement of the transaction type in the payment service scene includes:

if the micro service has a preset abnormal code, processing according to a transaction flow set by the abnormal code;

if the micro service is the current transaction needing to be stopped, terminating the calling of the following micro service in the combined service and updating the transaction state;

if the micro-service occurs that the current transaction needs to be stopped, if the micro-service is accounted, the accounting is called to carry out compensation;

if the micro service is that the current transaction is stopped, sending a notice to the transaction initiating system to inform that the current transaction fails.

Specifically, an exception handling module may be added to perform payment transaction processing, but may also be named by another name, or may also use an existing function module to perform processing. The exception handling module is used as a part of the main process and covers the whole process of the transaction combination service. The main functions may include exception code identification, updating of transaction status, invoking accounting for ongoing compensation, sending notifications and receipt.

1. And (3) abnormal code identification:

to facilitate management of the exception scenarios that may occur for each microservice, five-bit digital encoding may be used to represent each exception scenario. If the micro service is abnormal, the abnormal code is fed back to the abnormal processing module, the module judges whether the transaction stops processing according to the abnormal code, and abnormal information is recorded, so that follow-up retrieval is facilitated.

2. Updating the transaction state:

if the current transaction is identified to be required to stop processing, the exception handling module terminates the calling of the following micro-service in the combined service, updates the transaction state and facilitates the front end to monitor and manage the queue.

3. And calling accounting to compensate:

if the current transaction needs to be stopped from processing, the exception handling module checks the accounting state of the current transaction, and if the current transaction is accounted, the accounting is required to be called for forward compensation; if not billed, the operation is skipped without compensation.

Banking refers to the process initiated by an operator to revoke transactions that have been successfully billed. And the automatic flushing rule refers to a revocation process of uncertain transactions initiated by the system. Generally speaking, there are three main types of orthogonal easy states: success, failure and uncertainty. The automatic correcting mechanism can be adopted only when the accounting of a certain party returns overtime, a bank party cannot determine the accounting result, and the possibility of unilateral accounting exists.

There are two main common forms of auto-righting: automatic punching and straightening in real time and automatic punching and straightening in batches.

1. Automatically punching and correcting in real time; 2. the automatic batch correction means that when a certain party returns to timeout, the system does not immediately correct the transaction, only records some keywords in the transaction to a specific database or file, and focuses on the automatic correction completed by the certain party at a certain time.

In practical applications, the time for performing the batch automatic correction may be a single time point or a plurality of time points. A frequency can be set for a plurality of time points through parameters, and the automatic forward flushing program periodically initiates batch automatic forward flushing once according to the frequency. The batch automatic correction is mainly applied to batch-to-real-time deduction services, and since the services cannot interact with an operator in real time in the processing process, the delayed correction can be selected.

4. Sending notification and receipt:

if the micro service is that the current transaction is stopped, sending a notice to a transaction initiating system to inform that the current transaction fails;

if the current transaction stops processing, the exception handling module sends a notice to the transaction initiating system to inform that the current transaction fails.

In implementation, the processing result returned by each microservice is received and stored in a Kafka integration mode.

In implementation, the method for storing the processing result returned by each microserver in a database comprises the following steps:

firstly, the processing result returned by the micro-service is put into the message queue, and then the database background module reads the processing result of the message queue in sequence and stores the processing result into the main database.

Specifically, in the distributed real-time payment system, the main library is stored in an asynchronous library writing mode, namely, the micro-service firstly puts the transaction information into a message queue, and then a db-background module reads the transaction information of the message queue in sequence and stores the transaction information into the main library. The mode has the advantages of high concurrency and high reliability.

Reading the processing result of the message queue, and when the processing result is stored in the master database, further comprising:

and when the processing result of the message queue of the micro service is read, adding the version number of the micro service to avoid the processing result of the micro service master database behind the payment transaction business process from being covered by the processing result of the micro service master database ahead.

The method for realizing the asynchronous writing library mainly comprises the following two aspects:

and realizing asynchronous message sending and receiving: the transmission and the reception of the messages are realized in a Kafka integrated mode in a distributed real-time payment system.

Realizing the unified writing of the messages into the master library: and db-background micro-service is realized, and the message queues of the main library are uniformly subscribed. When each micro service transacts to the write master library message queue push, the version number specific to the current micro service is added. By the method, the db-background service can sequentially execute library writing operation, and the situation that the transaction information of the rear micro-service library in the business process is covered by the transaction information of the front micro-service library is avoided.

Fig. 2 is a schematic diagram of a payment transaction architecture, as shown in the figure, at least one functional architecture that can implement payment transaction processing is shown, and the whole distributed real-time payment system can be divided into four layers:

an external access layer: interfacing with an initiating system of a payment transaction. Each external access layer service is connected with a transaction initiating channel, and after the external access layer receives payment transaction, different combined services are invoked according to transaction types.

And (3) combining service layers: according to the payment business scene, the micro services are combined and arranged, such as payment transaction remittance, remittance and the like. When the combined service sequentially calls up the micro-services in the chain, each micro-service returns a processing result after finishing processing, and the processing is uniformly carried out by the exception handling module.

A microservice layer: each micro service realizes a business processing logic unit, and the combined service layer calls up the related micro service according to the needs.

Other system access layers in the bank: some of the microservices involve interaction with inline systems, which interface as an interface layer with each system in the row separately.

Fig. 3 is a schematic diagram of a payment transaction processing flow, wherein transaction information is stored in a database at the end of each microservice execution. In the distributed real-time payment system, a main library is stored in an asynchronous library writing mode, namely, the micro-service firstly puts the transaction information into a message queue, and then a db-background module reads the transaction information of the message queue in sequence and stores the transaction information into the main library. The mode has the advantages of high concurrency and high reliability.

The following is an example.

Fig. 4 is a schematic diagram illustrating a process flow of a repeated remittance transaction, and as shown in the figure, taking the receipt of the repeated remittance transaction as an example, a transaction flow including exception handling and asynchronous library writing may include:

step 401, the overseas local clearing system initiates a remittance transaction request with repeated existing transactions, and submits the transactions to an external access layer;

step 402, the external access layer receives the transaction request, invokes the composite service of the remittance transaction, and sends the transaction content to the message queue of the memory base. Meanwhile, the db-background module monitors that the message queue of the memory master library has unprocessed messages, and takes out the messages to complete the operation of the memory master library;

step 403, the combined service of the imported transaction will sequentially call up each micro-service according to the arranged sequence, and at first, the report-replay check micro-service will be called;

step 404, comparing the unique number of the current transaction with the unique number of the existing transaction in the database by the repeat check micro-service, finding that the transaction with the same number is processed, and feeding back an abnormal code representing the repeat by the repeat check micro-service to the combined service layer;

step 405, after receiving the exception code, the exception handling module of the combined service layer recognizes the current transaction report again, stops the startup of the subsequent micro-services in the chain, and sequentially performs the following operations:

A. and setting the state of the current transaction as a re-reporting state.

B. And judging whether the current transaction is billed. The accounting is not required to be invoked because the current transaction has not yet been executed to the accounting microservice.

C. And generating a receipt of current payment transaction failure, and feeding back the receipt to the overseas local clearing system.

D. And sending the transaction content of the updated state to a message queue of the main storage. Meanwhile, the db-background module monitors that the message queue of the main storage has unprocessed messages, and takes out the messages to finish the operation of the main storage.

Embodiments of the present invention further provide a payment transaction processing apparatus, as described in the following embodiments. Because the principle of solving the problem of the device is similar to the payment transaction processing method, the implementation of the device can refer to the implementation of the payment transaction processing method, and repeated parts are not described again.

Fig. 5 is a schematic structural diagram of a payment transaction processing apparatus, which may include:

a receiving module 501, configured to determine, according to a transaction type, a micro-service to be invoked and an invoking sequence after a payment transaction of a transaction initiating system is initiated;

the processing module 502 is configured to receive and store processing results returned by each micro-service, and when it is determined that the micro-service is abnormal according to the processing results, process the micro-service according to the position and sequence of the abnormal micro-service in the payment transaction according to the service requirement of the transaction type in the payment service scene;

the storage module 503 is configured to store the processing result returned by each micro service in a master database.

In an implementation, the processing module, when processing according to the service requirement of the transaction type in the payment service scenario, includes:

In implementation, the processing module is further configured to receive and store the processing result returned by each microservice in a Kafka integrated manner.

In an implementation, the storage module is further configured to, when storing the processing result returned by each micro service in the master database, include:

In an implementation, the storage module is further configured to add the version number of the micro-service when the processing result of the message queue is read and stored in the master database and when the processing result of the message queue of the micro-service is read, so as to prevent the processing result of the micro-service master database in the following payment transaction business process from being overwritten by the processing result of the micro-service master database in the front.

The technical scheme provided by the embodiment of the invention is to provide a solution for ensuring transaction consistency in a distributed real-time payment system, which comprises the steps of performing consistency compensation on transactions and ensuring that a transaction processing result is consistent with an accounting result; how to realize the transaction information storage main base and ensure the reliability of information transmission. The method comprises the following steps:

1. a consistency compensation design.

By adding exception handling, consistency compensation for transaction processing is achieved. The exception handling mainly completes the functions of updating the exception state, sending notification and receipt and transaction compensation. And by combining the particularity of the real-time payment service, carrying out correction compensation on the abnormity generated after account processing, and updating the transaction state and recording the abnormal information of the abnormity generated before account processing.

2. The design scheme of the transaction information repository.

By adopting an asynchronous library writing mode, a db-background module is additionally arranged to uniformly write the transaction information into the main library, the reliability of transaction information transmission is ensured, meanwhile, the waiting time of each micro-service is reduced, and the concurrency of a distributed system is improved.

The technical scheme provided by the embodiment of the invention ensures the consistency of the transaction processing result and the accounting through the consistency compensation design scheme in the exception processing, and avoids the condition that the transaction processing fails but the customer account number is deducted; by the design scheme of asynchronously writing the stock transaction information, the reliability of transaction information transmission is ensured, and the concurrency performance of the system is improved. By ensuring the final consistency in the whole real-time payment transaction processing process through the aspects, a relatively simple and easy-to-implement solution is provided.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

The above-mentioned embodiments are intended to illustrate the objects, technical solutions and advantages of the present invention in further detail, and it should be understood that the above-mentioned embodiments are only exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.

Claims

1. A payment transaction processing method, comprising:

receiving and storing processing results returned by each micro-service, and processing according to the position and sequence of the abnormal micro-service in the payment transaction and the service requirement of the transaction type in the payment service scene when the micro-service is determined to be abnormal according to the processing results;

2. The method of claim 1, wherein processing per service requirement for the transaction type in a payment service scenario comprises:

if the micro service appears that the current transaction is stopped processing, a notice is sent to the transaction initiating system to notify that the current transaction fails.

3. The method of claim 1, wherein the processing results returned by each microservice are received and saved by way of Kafka integration.

4. The method of claim 1, wherein storing the processing results returned by each microservice in a database, comprises:

5. The method of claim 4, wherein reading the processing results of the message queue, when stored in the master database, further comprises:

6. A payment transaction processing apparatus, comprising:

the receiving module is used for determining the micro-service to be mobilized and the mobilizing sequence according to the transaction type after receiving payment transaction initiation of the transaction initiation system;

and the storage module is used for storing the processing results returned by the micro-services in a main database.

7. The apparatus of claim 6, wherein the processing module, when processing per service requirement for the transaction type in a payment service scenario, further comprises:

if the micro service appears that the current transaction needs to be stopped, terminating the calling of the following micro service in the combined service and updating the transaction state;

8. The apparatus of claim 6, wherein the processing module is further configured to receive and save processing results returned by each microservice in a Kafka-integrated manner.

9. The apparatus of claim 6, wherein the storage module, when storing the processing results returned by the microservices in the master database, is further configured to:

10. The apparatus of claim 9, wherein the storage module is further configured to add a version number of the micro-service when the processing result of the message queue is read and stored in the master database and when the processing result of the message queue of the micro-service is read, so as to prevent the processing result of the following micro-service master database from being overwritten by the processing result of the previous micro-service master database in the payment transaction process.

11. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any one of claims 1 to 5 when executing the computer program.

12. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program which, when executed by a processor, implements the method of any of claims 1 to 5.

13. A computer program product, characterized in that the computer program product comprises a computer program which, when being executed by a processor, carries out the method of any one of claims 1 to 5.