Design and Implementation of a Payment Center Architecture

01. Project Goals

The payment center architecture consolidates common transaction, payment, and finance functions across businesses, aiming to (1) establish a unified order‑payment‑finance system that abstracts and encapsulates shared logic to reduce integration and duplicate development costs; (2) build a secure, stable, and scalable system that balances rapid business growth with payment stability; and (3) aggregate core transaction data to support applications, property companies, and users.

02. Specific Call Flow

Based on the project goals, the author consulted three project teams (procurement, O2O, and fee collection) and adapted the payment center call process to their own scenarios. The overall interaction involves the business system, the payment center, and third‑party channels, as illustrated in the diagram below:

The step‑by‑step flow is:

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

The merchant parameters are provided to the payment center to activate the merchant account and payment channel, receiving merchant and payment identifiers.

The identifiers are passed to the application side, completing the registration process.

The application sends the merchant ID, payment ID, order number, amount, and invoke method to the payment center.

The payment center resolves the identifiers, assembles request parameters, and initiates the payment with the third‑party.

The payment result is returned to the application (only the initiation success notification, not the final payment outcome).

The third‑party payment redirects the user to a checkout page or mini‑program to complete the payment and notifies the payment center of the result.

The payment center processes the data and notifies the application.

The application finalizes the order and informs the user.

Additional considerations include handling order numbers versus internal serial numbers, generating unique serial numbers for third‑party interactions, and using the payment center’s serial number to determine refund eligibility.

03. Payment Center Architecture Design

The system is divided into four major modules:

Payment Center Backend : Handles account management and supports property company onboarding.

Payment Messages : Provides notifications to the application side.

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

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

Key components include the cash register, account management UI, request parser, and database design for the transaction core (illustrated in the diagrams below).

04. Anticipated Issues

Potential problems include data monitoring (alerting on anomalies), data consistency (ensuring applications sync with the payment center), and stability (handling third‑party payment failures and rapid retry logic within 15 seconds).