Design and Call Flow of a Payment Center Architecture

The payment center architecture consolidates common transaction, payment, and finance functions across multiple business lines, aiming to establish a unified order‑payment‑finance system, reduce integration and development costs, provide a secure and scalable platform, and supply core transaction data for downstream services.

Based on consultations with three project teams (procurement, O2O, and fee collection), the article describes the end‑to‑end call flow involving the business system, the payment center, and third‑party channels, including merchant onboarding, parameter provisioning, and the sequence of payment initiation, result handling, and user redirection.

Key steps include: the property company opening a third‑party merchant account; passing merchant and payment identifiers to the application; the application sending payment requests with order details to the payment center; the payment center translating identifiers, invoking the third‑party API, and returning the initiation result; the third‑party handling user payment and notifying the payment center; and finally the payment center processing the callback and informing the application.

Special considerations cover order number handling (the payment center records any incoming order or serial number and generates a unique serial number for the third‑party), refund processing (refunds are tied to the payment‑center‑generated serial number), and cash‑desk logic (using the third‑party cash desk when available, otherwise the payment center’s own).

The overall system is divided into four major modules: the payment center backend (account management), payment messaging (notifications to applications), transaction core (core transaction processing, parameter assembly, exception handling), and channel gateway (request parsing, certificate whitelist, third‑party API calls). Additional components such as cash desk, channel gateway, account management, request parser, and transaction core database design are illustrated with diagrams.

Potential future issues identified include data monitoring and alerting, data consistency when only a single module is deployed, and stability concerns due to third‑party payment reliability, with recommendations for rapid retry logic and monitoring.