Payment platform: detailed explanation from gateway layer to data analysis layer

1. Payment architecture process

1. Gateway layer

2. Payment Processing Layer

The payment processing layer is the core of the payment platform, responsible for processing payment requests and interacting with major payment platforms, banks and other external systems. Its functions include:

Payment information verification: Verify the legitimacy of the payment request, such as order number, amount, merchant information, etc.

Payment request initiation: Based on the user's payment method, different payment platform APIs are called to initiate a payment request.

Payment status inquiry: Check payment status regularly or as needed to ensure payment is completed.

Refunds and cancellations: Supports payment refunds or cancellations of unfinished transactions.

3. Payment service layer

• Integration of multiple payment channels: such as bank card payment, third-party payment (Alipay, WeChat Pay, PayPal, etc.), wallet payment, cross-border payment, etc.
• Payment business logic: manages the business logic of the payment process, handles callbacks for payment success or failure, and ensures data consistency.
• Payment risk control: Real-time monitoring of payment requests to prevent fraud is performed through risk identification and prevention systems (such as risk control engines, anti-fraud mechanisms, etc.).

4. Payment Settlement Layer

The payment clearing layer is mainly responsible for transaction settlement and fund transfer, ensuring that the payment finally reaches the merchant or user account accurately. It includes:

• Funds clearing: Match the payment results with the merchant account, and clear and settle the funds.
• Multi-currency and cross-border payments: Support clearing of different currencies and handle exchange rate conversion and settlement of cross-border payments.
• Account management: manage the account flow of transactions, generate financial statements, and ensure the compliance and transparency of capital flow.

5. Payment security layer

The payment security layer is responsible for ensuring the security of the payment process to prevent user information leakage or funds from being stolen. It mainly includes:

• Encryption and Signature: Use SSL/TLS encryption technology and digital signature to encrypt payment data to prevent data leakage.
• Authentication and authorization: Through multi-factor authentication (such as dynamic verification code, fingerprint recognition, etc.) and permission control, ensure that only authorized users and systems can perform payment operations.
• Anti-fraud system: prevent fraud through real-time monitoring, transaction behavior analysis, risk control rules and other means.

6. Logging and Monitoring Layer

• Transaction log: records detailed information of each transaction, including payment request, response, reasons for success and failure, etc.
• Real-time monitoring: The operating status of the payment system can be checked in real time through the monitoring system to detect potential problems in a timely manner.
• Alarm and analysis: When an exception or error occurs, an alarm is automatically triggered and the problem is troubleshooted through data analysis.

7. Data Analysis Layer

• Payment data analysis: By analyzing transaction data, we help merchants understand the usage of payment channels and payment methods and make optimizations.
• User behavior analysis: Analyze users' payment habits and preferences to provide data support for marketing, product optimization, etc.
• Risk control analysis: By analyzing payment behaviors, potential risk points can be identified and data support can be provided for risk control models.

8. External interface and API layer

• Merchant interface: Provide merchants with a convenient API interface to facilitate them to access the payment system, obtain payment status, initiate refunds, and other operations.
• Third-party payment access: connect with various third-party payment service providers (such as Alipay, WeChat Pay, etc.) through open API.

(ii) The following are possible questions and answers:

Is the payment service request response of this middle platform synchronous or asynchronous? Or a mixed mode?

WeChat Mini Program payment generally adopts a combination of synchronous and asynchronous methods.

Synchronization phase

• When a user initiates a payment request, the mini program calls the WeChat payment API (wx.requestPayment).
• The WeChat payment service will immediately return the payment initiation result (success or fail), which reflects the execution status of the payment request:

Synchronous success (payment request initiated successfully): indicates that the payment process has been initiated, but the final status of the payment (success or failure) needs to be confirmed asynchronously later.

Synchronization failure: If the user cancels the payment or the request parameters are incorrect, an error message will be returned immediately without the user having to wait.

Asynchronous phase

• The final result of the payment (success or failure) is sent to the merchant via asynchronous notification.
• The merchant system needs to implement the payment result callback interface and receive the payment result notification pushed by the WeChat payment server.
• Merchants can actively confirm payment results through the order query interface (orderQuery).

Synchronous mode applicable scenarios

• The payment request is completed in one communication from initiation to return of the result, and the user obtains the payment status in real time.
• Suitable for scenarios where there is a high demand for immediate feedback.

1) Offline payment

• Such as QR code payment, NFC payment, and face recognition payment.
• Users need to get results immediately after payment to ensure that the transaction is completed.
• Examples: convenience stores, supermarkets, etc.

2) Small amount payments

• Such as public transportation and shared bicycles.
• The transaction amount is low, the payment process is simple, and real-time is the key.

3) Scenarios that do not require complex processing:

• For purchases of virtual items (such as in-game items, online recharge), the items will be shipped directly after payment.

Asynchronous Mode

1) E-commerce promotion and high-concurrency scenarios:

2) Cross-border payments

3) Large amount payments

• Such as air tickets, hotel reservations, and business-to-business transactions.
• It involves complex verification and approval processes between banks, and payment confirmation needs to be completed asynchronously.

4) Installment payment:

• Such as consumer loans and mortgage payments.
• The payment status is affected by approval and verification, and the final status needs to be confirmed asynchronously.

What are the core functional modules of the payment platform?

1. Payment Request Processing Module

1. Analyze payment information, such as payment amount, payment platform, payment method, order number, etc.

2. Based on the type of payment platform, use the factory pattern to create the corresponding payment processor, then call the payment method of the payment processor to initiate a payment request and perform error handling.

2. Payment result callback processing module

1. Receive callback and verify legitimacy

2. Change the payment status of the order based on the callback result

3. Order management module?

1. Responsible for operations such as creating, querying, updating and deleting orders, and storing order information in the database.

2. Provide an order status query interface, which is responsible for querying the order status and updating the order status during payment result callback processing.

4. Configuration Management Module

1. Store the configuration information of each platform (API key, callback address, payment parameters)

2. Provide configuration reading and updating functions

Recommended books

The following book will be very helpful to you. Send me a private message to enjoy a discount:

Payment connection?

For WeChat Mini Program payment scenarios

1. Merchants apply for and set up WeChat payment

• Merchants need to register a WeChat merchant account and activate the WeChat payment function. When registering, they need to provide the company's business license, legal person ID card, bank account and other information.
• Log in to the WeChat Pay merchant platform (pay.weixin.qq.com) and obtain the merchant ID and API key.
• Configure the payment-related information of the WeChat Mini Program, such as configuring payment parameters in the Mini Program backend, including merchant number and API key.

2. User initiates payment request

• When the user selects a product in the mini program and submits the order and clicks the "Pay" button, the front end will call the mini program payment interface to initiate a payment request.
• The applet calls the wx.requestPayment interface to initiate a payment request to the backend, and the backend requests the order information from the WeChat payment server.

3. The backend generates a prepaid order

• The backend uses the merchant number, API key, and payment parameters related to WeChat Pay to call WeChat Pay's unified order interface (**/pay/unifiedorder**) to generate a prepaid order.
• The following main parameters need to be provided for unified order request:

appid: AppID of the mini program.

mch_id: merchant ID.

nonce_str: random string.

sign: signature (generates a signature based on the request parameters).

body: Product description.

out_trade_no: merchant order number.

total_fee: total order amount (in cents).

spbill_create_ip: The client IP address of the user.

notify_url: payment result callback URL.

trade_type: payment type (JSAPI means mini program payment).

4. The front end calls the wx.requestPayment interface

• The prepayment information (including prepay_id) returned by the backend will be passed to the mini program frontend.
• The front end calls payment through the wx.requestPayment interface and passes in pre-payment information (such as timeStamp, nonceStr, package, signType, paySign).
• After the front-end call is successful, the user's WeChat payment interface will pop up and the user can confirm the payment.

5. Payment result callback

• After the payment is successful, the WeChat payment server will send a payment result notification to the merchant's notify_url.
• After receiving the payment notification, the backend verifies the signature and processes the payment result. If the payment is successful, subsequent operations such as delivery can be carried out.

6. Payment result inquiry

• Merchants can query the order payment status through WeChat Pay's order query interface (**/pay/orderquery**) as needed to confirm whether the payment is successful.

Precautions

1. Signature Verification

• All requests and return data of WeChat Pay need to be signed and verified. Merchants need to ensure the correctness of the signature algorithm to avoid data tampering during the payment process.
• You need to use the merchant's API key to generate a signature. When signing, make sure the order and encoding of the parameters are correct.

2. Order number management

• Merchants must ensure that the order number of each order is unique. The merchant order number (out_trade_no) is unique in the WeChat payment system and cannot be repeated.
• The order number should be generated by the merchant. It is recommended to use a combination of timestamp and random number to ensure uniqueness.

3. Amount accuracy

• The unit of amount for WeChat payment is "fen", which means that when transferring the amount, you need to convert RMB yuan into fen.
• For example, if the user pays 10 yuan, the parameter passed should be 1000 (10 × 100).

4. API call frequency limit

• WeChat Pay API calls have frequency limits, and merchants cannot frequently call certain interfaces in a short period of time, such as the unified order interface, order query interface, etc. Merchants need to reasonably plan the frequency of interface calls to avoid being restricted by the WeChat Pay platform.

5. Payment success callback processing

• When merchants receive payment callbacks, they need to verify the signature of the payment notification to ensure that the notification comes from the WeChat payment server.
• If the payment is successful, subsequent operations can be performed, such as delivery, provision of services, etc.; if the payment fails, corresponding error handling can be performed.

6. Abnormal payment scenarios

• During the payment process, you may encounter abnormal situations such as network instability and payment interruption. Merchants need to prepare processing strategies to ensure a smooth payment experience for users. For example, they can provide payment result query functions or abnormal order processing mechanisms.

7. User experience after successful payment

• The payment interface within the mini program should be simple and clear. Users do not need to perform too many operations when confirming payment, so as to avoid payment failures due to complicated operations.
• The mini program should prompt users whether the payment is successful or failed, and provide guidance on subsequent operations.

8. Refund Process

• If a refund is required for the user, the merchant can call the WeChat Pay refund interface (**/secapi/pay/refund**) to make a refund.
• The refund request needs to provide the transaction_id or out_trade_no of the original transaction, as well as the refund amount and other information.

1) When initiating a payment request, ensure that each payment request has a unique identifier, such as order_id or a specially generated transaction_id, to identify the uniqueness of each payment request.

2) Use payment request idempotency interface: WeChat Pay itself provides some interfaces to support idempotency. For example, when you initiate a unified order request, you can generate a unique merchant order number (out_trade_no) for each payment request. If a payment request for the order number already exists, WeChat Pay will return an error message, and the merchant can determine whether the request is repeated based on this return value.

3) Payment request record and status judgment:

On the server side, the payment status (e.g. pending, paid, payment failed, payment in progress, etc.) should be saved for each payment request (identified by order_id or transaction_id). When receiving the same payment request, you can determine whether to reprocess it based on the saved status, or directly return the completed payment status.

• Request processing steps: payment request initiated -> save order status -> request WeChat payment interface -> wait for payment result callback
• Payment callback processing: Receive payment callback -> query the database payment status -> if the order has been paid, return success; if it is the first callback, process the payment success logic.

Do I need to manually perform idempotency protection and transaction processing in WeChat Mini Program payment scenarios?

Background on the Idempotence Problem

• During the payment process, especially through network requests and asynchronous operations, problems such as network instability or system retries may occur, resulting in the same payment request being submitted multiple times, or the same payment result being processed multiple times.
• WeChat Pay's notification interface (such as payment result callback) may also be triggered multiple times due to network reasons. Merchants need to ensure that each payment notification is processed only once to avoid repeated operations (for example: repeated shipments, repeated deductions, etc.).

How to achieve idempotence

• Order number uniqueness: The merchant's order number out_trade_no should be unique and cannot be repeated in the merchant system. Each order must have a unique identifier to ensure that the system can identify and distinguish different transaction requests.
• Idempotent processing of payment results:

Payment notification processing: The payment result callback interface of WeChat Pay will send payment notifications to the merchant's notify_url. Merchants need to ensure idempotence for the processing of each payment notification. A common practice is that merchants can record the out_trade_no or transaction_id of the payment notification. When processing the payment notification, first determine whether the notification has been processed. If it has been processed, skip it directly.

Database redundancy check: When processing payment callbacks, merchants should first check the payment status of the order. If the order has been paid successfully, the subsequent processing should be skipped. If the payment is not successful, continue to perform the operations after the payment is successful.

• Idempotence key points:

In important operations such as order creation, successful payment, and refund, the idempotence of the operation needs to be guaranteed. That is, each operation can only be performed once to prevent repeated processing.

Redundancy checks are performed through unique identifiers in the database (such as order numbers, payment transaction numbers) to ensure that operations with the same payment status are only executed once.

How is the network security of this middle-office payment service guaranteed?

Network security protection technology

• Firewall: By setting access rules, unauthorized network access is blocked, malicious attacks and illegal intrusions from external networks are prevented, and only legal network traffic is allowed to enter the middle-office payment service system.
• Intrusion detection and prevention system: Real-time monitoring of abnormal activities and potential threats in the network, such as malware intrusion, hacker attacks, etc., and timely issuance of alarms and taking corresponding defense measures, such as blocking the attack source, isolating infected devices, etc., to protect the security of the payment system.
• VPN (Virtual Private Network): Provides a secure encrypted channel for users or branches who remotely access the middle office payment service, ensuring the confidentiality and integrity of data during transmission and preventing data from being stolen or tampered with.

Data encryption technology

• Transmission encryption: Encryption protocols such as SSL/TLS are used to encrypt payment data during network transmission, so that the data is transmitted in ciphertext form. Even if it is intercepted, it is difficult to crack, ensuring the security of users' sensitive data such as payment information and account information.
• Storage encryption: Encrypt the payment data stored in the database, use symmetric encryption algorithm or asymmetric encryption algorithm to convert the data into ciphertext for storage. Only authorized keys can decrypt and access the data, preventing the data from being stolen or leaked during storage.

Authentication and access control

• Multi-factor identity authentication: Combining multiple identity authentication methods, such as passwords, dynamic passwords, fingerprint recognition, facial recognition, etc., to increase the security of user identity authentication and prevent account theft and illegal login.
• Access Control List (ACL): According to the user's role and permissions, set detailed access control policies to limit different users' access rights to the middle-office payment service system resources, ensure that only authorized users can access and operate the corresponding functions and data, and prevent unauthorized access and data leakage.
• Single sign-on (SSO): With a single sign-on system, users only need to log in once in one system to access other mutually trusted related systems, reducing the number of times users have to repeatedly enter their usernames and passwords in different systems. It also facilitates centralized management of user identities and permissions, improving security and user experience.

Security audit and monitoring

• Log audit: records all operations and events in the middle-office payment service system, including user logins, transaction records, system configuration changes, etc. Through log analysis and auditing, abnormal behaviors and security vulnerabilities can be discovered in a timely manner, providing a basis for tracing and investigating security incidents.
• Real-time monitoring: Real-time monitoring of the operating status, network traffic, transaction data, etc. of the payment system. By setting thresholds and alarm rules, abnormal transactions, traffic anomalies, performance problems, etc. in the system can be discovered in a timely manner, and corresponding measures can be taken in a timely manner to ensure the stable operation of the payment system and data security.
• Risk assessment and early warning: Regularly conduct risk assessments on the middle-office payment service system to identify potential security risks and threats, and formulate corresponding risk response strategies based on the assessment results. At the same time, establish a risk early warning mechanism, timely release security risk early warning information, and remind relevant personnel to take preventive measures to reduce security risks.

Safety management system and training

• Security strategies and systems: Develop comprehensive network security strategies and management systems, clearly define the security requirements, operating procedures, personnel responsibilities, etc. of payment services, regulate employee behavior and operations, and ensure that various security measures are effectively implemented.
• Personnel training and education: Strengthen network security training and education for employees, improve their security awareness and prevention skills, make them understand common network security threats and prevention methods, and avoid security accidents caused by employee negligence or improper operation.
• Emergency response and recovery plan: Develop emergency plans and disaster recovery plans, clarify the emergency response process and division of responsibilities when security incidents occur, ensure that security incidents can be responded to quickly and effectively, minimize losses, and restore the normal operation of the system in a timely manner after the incident is handled.

How does payment service achieve fault tolerance?

Transaction Processing Mechanism

• Atomicity guarantee: A transaction processing mechanism is used to ensure the atomicity of payment operations, that is, a series of related payment operations are either all successful or all failed, to avoid inconsistent payment data due to interruptions or failures. For example, in database operations, transactions are used to wrap payment-related inserts, updates, and other operations. If any of the operations fails, the entire transaction is rolled back to ensure data consistency.
• Consistency maintenance: Through strict transaction control and data verification, the data consistency of the payment system is ensured in various situations. For example, when processing a payment order, not only the order status must be updated, but also the related account balance, inventory and other information must be updated synchronously. All these operations are completed in one transaction to prevent data inconsistency.

Idempotent Design

• Unique key verification: Idempotence is achieved through unique keys to prevent problems such as duplicate payments or duplicate refunds. For example, on the order side, duplicate payment verification is often performed by associating the order number with paymentno; on the payment side, the transaction order uses the external order number + merchant number as the unique key, and the payment order uses the transaction order number + operation code as the unique key.
• Reentrant processing: For requests that have been successfully processed, when the same request is received again, it can be correctly identified and a successful result can be directly returned without repeatedly executing the same business logic, avoiding data duplication or status abnormalities caused by retry operations.

Retry mechanism

• Asynchronous retry: When a payment request fails due to network jitter, temporary service unavailability, etc., the request is put into the message queue (MQ) for asynchronous retry, and the retry interval is gradually extended to avoid excessive pressure on the faulty service. For example, the first retry interval is 1 minute, the second interval is 3 minutes, the third interval is 5 minutes, and so on, until the maximum number of retries is reached.
• Best Effort Notification: Use the best effort notification strategy to ensure that the payment results can be accurately notified to the relevant parties. If the payment is successful, if the notification to the downstream system fails, multiple retries will be made until the downstream system successfully receives the notification or the maximum number of retries is reached.

Timeout settings

• Interface timeout: Set a reasonable timeout for all payment interface calls to prevent requests from being stuck in long waits, which can cause the entire service to be unavailable. Once an interface call exceeds the set timeout, the call is considered to have failed and will be processed according to the corresponding fault tolerance strategy, such as retry or fast failure.
• Global timeout control: In the entire payment business process, set a global timeout to ensure that the payment operation can be completed within a reasonable time. If the global timeout is exceeded, the system will automatically perform corresponding processing, such as canceling the payment, rolling back related operations, etc., to avoid long-term blocking of a certain link that affects user experience and system performance.

Current limiting and overload protection

• Traffic limiting: By limiting the number of calls within a unit time period or the degree of concurrent calls of the system, the system can be prevented from being overwhelmed by high traffic during peak traffic periods. Common traffic limiting methods include fixed window traffic limiting, sliding window traffic limiting, leaky bucket algorithm traffic limiting, token bucket algorithm traffic limiting, etc., to ensure that the system can process payment requests within the tolerance range and ensure the stability and availability of the system.
• Fuse mode: Use the fuse mode to prevent applications from constantly trying to perform operations that may fail. When a service fails or the call failure rate reaches a certain threshold, the fuse will automatically open and temporarily cut off calls to the service to avoid resource exhaustion and system avalanche caused by continuous requests for failed services. At the same time, the fuse will periodically check whether the service has returned to normal. If it has, it will automatically close and allow it to be called again.

Bulkhead Isolation

• Resource isolation: Isolate resources or failure units like a bulkhead to ensure that a problem in one part does not affect other parts. For example, in a multi-threaded or multi-process environment, separate thread pools or processes are assigned to different payment business functions. When a function fails or has performance problems, it will not affect other normal business functions, thereby improving the overall stability and availability of the system.
• Data isolation: Different payment data is classified and stored in isolation to prevent the spread of faults due to mutual influence between data. For example, transaction data, account data, log data, etc. are stored in different databases or data tables, and appropriate access control and data isolation mechanisms are adopted to ensure data security and independence.

Graceful degradation

• Functional downgrade: When there is a problem with the payment system, such as a sudden increase in the number of concurrent transactions and the system cannot cope with it, the normal operation of the core payment function is prioritized, and some non-core functions are downgraded. For example, the relevant entrances to payment inquiries are closed to reduce the system load pressure and ensure that the main payment order process is not affected.
• Data downgrade: When system resources are tight or a failure occurs, the payment data processing is appropriately downgraded to ensure the basic availability of the system. For example, temporarily lower the consistency requirements of the data, update the data asynchronously, or return partial data instead of complete data, and then synchronize and complete the data after the system returns to normal.

Data backup and recovery

• Regular backup: Regularly perform full and incremental backups of payment data to ensure data security and recoverability. Backup data can be stored in local or remote storage devices to prevent data loss due to natural disasters, hardware failures, etc.
• Disaster recovery mechanism: Establish a complete disaster recovery mechanism to quickly restore system operation from backup data when a major failure or disaster causes system data loss or damage. The disaster recovery plan should include data recovery process, system reconstruction steps, emergency response measures, etc. to ensure that the normal operation of payment services is restored in the shortest possible time.

Is the payment service designed as a distributed transaction? If so, how is it handled?

Payment services usually involve distributed transactions. This is because payment business processes often involve multiple different systems or services, such as payment gateways, banking systems, account systems, order systems, etc. These systems need to ensure data consistency and operational integrity. The following are some common methods for handling distributed transactions:

Based on the two-phase commit (2PC) protocol

• Preparation phase: The transaction coordinator sends the transaction content to all participants (related systems) and asks whether the transaction can be submitted. Participants perform local transaction operations but do not submit them, and then feedback the operation results (approval or rejection) to the coordinator. For example, in the payment service, the payment gateway completes the payment request processing, the account system completes the fund deduction operation preparation, and the order system completes the order status update preparation, and they all feedback the prepared results to the coordinator.
• Commit phase: If the coordinator receives consent feedback from all participants, it will send a commit transaction instruction to all participants, and the participants will formally commit the local transaction; if any participant responds with a rejection, the coordinator will send a rollback transaction instruction to all participants. This ensures that either all systems complete the operation successfully or all are rolled back, maintaining the atomicity of the transaction. However, the 2PC protocol has problems such as synchronous blocking (participants are blocked while waiting for instructions from the coordinator) and single point failure (coordinator failure may cause transaction blocking).

Based on compensation mechanism

• Forward operation: Each system first executes its own local transaction, and does not rely on the transaction results of other systems to operate. For example, the payment service first processes the payment and deducts the funds from the user's account; the order system simultaneously updates the order status to "paid".
• Compensation transaction design: If a problem is found in an operation later, such as a successful payment but a failed order system update, a compensation transaction will be executed. For the above example, the compensation transaction may be to return the deducted funds to the user's account and update the order status to "payment failed". The compensation mechanism is more flexible and will not cause long-term blocking like 2PC, but it requires developers to carefully design compensation transactions to ensure that the executed operations can be correctly undone.

Eventual consistency based on Message Queuing (MQ)

• Message production and sending: When a payment operation is triggered, the relevant event message is sent to the message queue. For example, after the payment is successful, a "payment successful" message is sent to MQ. These messages contain enough information for the downstream system to perform subsequent processing.
• Message consumption and local transaction processing: Downstream systems (such as order systems, points systems, etc.) obtain messages from the message queue and then perform corresponding transaction processing locally. Taking the order system as an example, after receiving the "payment successful" message, the order status is updated to "paid". If the local transaction fails during the message consumption process, the message queue can ensure that the message is not lost, and will resend the message to the consumer under certain conditions until the consumption is successful, thereby achieving eventual consistency. This method has good asynchronicity and loose coupling, but there may be situations such as message delays that cause data consistency to be delayed.

Application of distributed transaction framework

• DTM framework (implemented in Go language): DTM is an open source framework designed specifically for distributed transaction processing. It is widely used in the Go language ecosystem and provides an effective solution for processing complex distributed transaction scenarios.
• TCC mode implementation:

Try phase: In the payment scenario, participants will perform some preparatory operations. For example, the payment service may first try to freeze the corresponding funds in the user's account to ensure that the funds are temporarily unavailable in the subsequent transaction process; at the same time, the order system may pre-occupy inventory and mark the number of goods that are about to be sold so that they can no longer be occupied by other orders. These operations are preliminary business logic processing completed in the Try phase, and their execution results will be recorded for judgment and processing in subsequent stages.

Confirm phase: When all the parts involved in the distributed transaction have successfully completed their respective preparation operations in the Try phase, they enter the Confirm phase. At this point, the payment service will formally deduct the previously frozen funds to complete the actual transfer of funds; the order system will confirm the reduction of inventory, actually subtract the reserved inventory quantity from the available inventory, and complete the inventory processing in the commodity sales link. The entire process ensures that all related business operations proceed in an orderly manner as expected, and realizes the submission operation of the distributed transaction.

Cancel stage: If any problem occurs in the Try stage or the subsequent Confirm stage, such as a network failure during the payment process that causes the fund freeze operation to fail to be confirmed, or the order system finds that the actual inventory of the product is insufficient and cannot be sold after pre-occupied inventory, the Cancel stage will be triggered. In this stage, the payment service will unfreeze the funds that were previously attempted to be frozen but not successfully confirmed and deducted, and restore them to a usable state; the order system will also release the pre-occupied inventory and return these products to the saleable inventory pool. Through such a cancellation operation, the business status can be rolled back to the state before the distributed transaction was initiated, ensuring the consistency and stability of the system.

• SAGA mode implementation:

Forward transaction chain orchestration: In the payment business process, multiple services may be involved in collaborative operations to form a transaction chain. For example, first the payment gateway receives the payment request and performs preliminary verification, then forwards the request to the payment service for fund processing, then the order system updates the order status based on the payment result, and finally the points system may also add corresponding points to the user based on the payment situation. These steps form a forward transaction chain in sequence, and each step is processed as a transaction step in the SAGA mode.

Compensation transaction design: When a problem occurs in a certain link of this transaction chain, a compensation operation is required. For example, if the payment service fails to process funds due to a failure, then a corresponding compensation transaction needs to be designed. For the transaction chain mentioned above, possible compensation transactions include: the payment gateway cancels the record of the preliminary verification result of the payment request (if there are relevant records that need to be cleared); the payment service rolls back part of the funds that may have been deducted (if some funds have been operated before the failure); the order system rolls back the updated order status to the state before payment; the points system revokes the points that may have been added (if points have been added). Through such a series of compensation transaction designs, the business status can be effectively rolled back to the appropriate state when problems occur, ensuring the overall consistency of the system.

• XA mode implementation:

Transaction manager coordination: When the XA mode is applied in the payment scenario, there will be a transaction manager responsible for coordinating the resource managers (such as databases, message queues, etc.) involved in the distributed transaction. The transaction manager will send instructions to prepare transactions to each resource manager, similar to the preparation phase operations in other distributed transaction modes.

Commit and rollback operations: When all resource managers report that they are ready to commit the transaction, the transaction manager will issue a command to commit the transaction. At this time, each resource manager will formally execute the commit operation and complete operations such as updating their own business data, just like completing the final commit of the distributed transaction in other modes. However, if any resource manager reports that it cannot be committed or fails during the preparation phase or other stages, the transaction manager will issue a command to roll back the transaction, so that each resource manager will roll back the business data to the state before the transaction was initiated, ensuring the atomicity and consistency of the entire distributed transaction.

Through these different distributed transaction modes and their specific implementation methods, the DTM framework can well handle distributed transaction problems in payment services and other complex business scenarios. At the same time, its implementation based on the Go language also makes it easier and faster to integrate and use in Go language projects.

This article is reproduced from the WeChat public account " Wang Zhongyang Go ", the author is " Wang Zhongyang Go ", you can follow it through the following QR code.

Please contact the " Wang Zhongyang Go " public account for reprinting this article.