Design and Call Flow of a Payment Center Architecture

Project Goals

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

Specific Invocation Process

Based on the objectives, the author consulted the business logic of three project teams (procurement, O2O, and fee collection) and adapted the payment center call flow and two key considerations to fit their own scenario.

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

The system interaction steps are:

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

Property company provides these parameters to the payment center, which creates a merchant ID, opens the payment channel, and obtains merchant and payment identifiers.

Property company passes the merchant and payment identifiers to the application side.

Payment Process

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

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

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

The third‑party payment triggers user payment via a 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 processes the order information and notifies the user.

Notes

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

The third‑party returns its own serial number after successful verification, which is used for billing, reconciliation, and refunds.

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

When the third‑party returns data, the payment center aggregates the original order number, its own serial number, and the third‑party serial number and returns all to the application, which should retain them.

Refunds use the payment‑center serial number to locate the original transaction; the refund amount cannot exceed the amount paid by that serial number.

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

Payment Center Architecture Design

The overall functional architecture consists of four major modules:

Payment Center Backend – handles account management and supports property companies in opening accounts and payment channels.

Payment Messaging – responsible for notifying the application side.

Transaction Core – supports core transaction processing, parameter assembly, result handling, exception management, and notifications.

Channel Gateway – parses incoming requests, manages certificates and whitelists, and calls third‑party APIs.

Checkout Page

Channel Gateway

Payment Account Management

Property companies select and open the required payment channels; users choose their preferred payment method, and the payment center processes the request and directs funds to the appropriate account.

Request Parser

The request parser first extracts the payment identifier to select the appropriate plugin (Alipay, WeChat, EasyPay), then determines the invocation method (mini‑program, PC, APP) to obtain the executable plugin, and finally selects the operation method (pay, wapPay, refund).

Transaction Core

Transaction core database design

Funds flow for split accounting

Anticipated Issues

Data monitoring – anomalies or errors should be promptly reported via the DingTalk group.

Data consistency – currently only one module is planned; the application side can synchronize data from the payment center.

Stability – third‑party payment services may be unstable (e.g., WeChat payment fails and Alipay is used). The application must monitor this; the payment center will re‑initiate payment for the same order if the interval between attempts does not exceed 15 seconds.