How to Build a Scalable Payment Center Architecture for Unified Transactions

1. Project Objectives

The payment center architecture consolidates common transaction, payment, and financial services for all businesses, addressing three key goals:

Establish a unified order, payment, and finance system, abstracting and encapsulating shared logic into core services to reduce integration costs and duplicate development.

Build a secure, stable, and scalable system that supports rapid business growth while balancing fast business needs with stable payments.

Accumulate core transaction data to provide data support for applications, property companies, and end users.

2. Specific Call Process

Guided by the objectives, the process was refined after consulting the Jicai, O2O, and Shoufeiyi project teams and adapting it to our own business scenario.

The interaction diagram among the business system, payment center, and third‑party channel is shown below:

Interaction steps:

Property company opens a third‑party payment channel merchant and obtains channel parameters.

Property company provides these parameters to the payment center, activates the merchant account and payment channel, and receives merchant and payment identifiers.

Property company supplies the merchant and payment identifiers to the application side, completing registration.

The application sends a payment request (including merchant ID, payment ID, order number, amount, and invoke method) to the payment center.

The payment center resolves identifiers, assembles request parameters, forwards the request to the third‑party, and obtains the initiation result.

The payment center returns the initiation status to the application (indicating only whether the request was successfully sent, not the final payment result).

The third‑party triggers user payment via its own checkout page or mini‑program, then notifies the payment center of the result.

The payment center processes the data and notifies the application.

The application finalizes the order and notifies the user.

Key notes:

Order numbers: regardless of whether the upstream system sends an order number or a serial number, the payment center records it and generates a unique serial number for the third‑party.

The third‑party returns its own serial number after successful validation, which is used for later reconciliation, refunds, etc.

The payment center stores three identifiers (original order number, its own serial number, third‑party serial number) for future queries.

Refunds are performed based on the payment center’s serial number, ensuring the refund amount does not exceed the amount of that transaction.

If the third‑party provides its own checkout page, it is used; otherwise the payment center’s own checkout page is employed.

3. Payment Center Architecture Design

The overall system architecture consists of four major modules:

Payment Center Backend: Handles account management, property company onboarding, and payment channel activation.

Payment Messaging: Sends notifications to application sides.

Transaction Core: Core transaction processing, parameter assembly, response handling, exception management, and notifications.

Channel Gateway: Parses incoming requests, manages certificate whitelists, and invokes third‑party APIs.

Key components within the Channel Gateway include:

Payment account management – property companies select and activate required payment channels.

Request parser – determines the appropriate payment plugin (Alipay, WeChat, EasyPay, etc.), invoke method (mini‑program, PC, APP), and selects the execution method (pay, wap‑pay, refund).

The Transaction Core database schema is illustrated below:

The fund flow for split payments is shown here:

4. Anticipated Issues

Data monitoring: Detect anomalies or errors promptly and notify via DingTalk.

Data consistency: Currently only one module is planned; the application side must synchronize data from the payment center.

Stability of third‑party payments: Users may experience failures with one channel (e.g., WeChat) and switch to another (e.g., Alipay); the application must monitor and ensure that repeated attempts for the same order occur within a 15‑second interval.