Design and Call Flow of a Payment Center Architecture

Project Goals

The payment center architecture consolidates common transaction, payment, and financial services across businesses, aiming to (1) establish a unified order‑payment‑financial foundation to reduce integration and duplicate development costs, (2) build a secure, stable, and scalable system that balances rapid business growth with reliable payments, and (3) aggregate core transaction data to support applications, property companies, and users.

Specific Call Process

Based on the objectives, the workflow involves three project teams (collective procurement, O2O, and fee collection) and defines the interaction between business systems, the payment center, and third‑party channels.

The interaction steps are:

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

Property company provides these parameters to the payment center, which creates a merchant ID and payment identifier.

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

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

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

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

Third‑party channel presents the payment UI (e.g., cashier page or mini‑program) to the user; after payment, it notifies the payment center.

Payment center processes the callback and notifies the application.

Application finalizes the order and notifies the user.

Key Considerations

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 channel.

Refunds: refunds are performed using the payment center’s serial number to locate the original transaction, ensuring the refund amount does not exceed the paid amount.

Cashier handling: if the third‑party provides its own cashier, the payment center forwards the user; otherwise, the payment center’s own cashier is used.

Payment Center Architecture Design

The overall system consists of four major modules:

Payment Center Backend – handles account management and merchant onboarding.

Payment Messaging – notifies application sides.

Transaction Core – assembles parameters, initiates payments, processes responses, handles exceptions, and sends notifications.

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

Cashier

Channel Gateway

Includes payment account management and request parser.

Payment Account Management

Property companies select required payment channels; users choose preferred methods; the payment center processes the request and routes funds to the appropriate receiving account.

Request Parser

The parser first extracts the payment identifier to select the appropriate plugin (Alipay, WeChat, EasyPay), then determines the invoke method (mini‑program, PC, APP) to choose the executor (e.g., alipaypaymentappexecutor) and finally calls the specific operation (onpay, waponpay, refund).

Transaction Core

Database design for the transaction core:

Illustrates fund flow for split payments.

Anticipated Issues

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

Data consistency – currently only one module syncs data to the payment center; future expansion may require broader consistency mechanisms.

Stability of third‑party channels – users may switch between WeChat and Alipay; the payment center must handle rapid re‑attempts (no more than 15 seconds apart) and ensure reliable notifications.