Scaling MaFengWo’s Payment Center: From 1.0 to 2.0 Architecture & Key Lessons

Payment Center 1.0

In the early stage, the payment center only handled basic payment, refund, and order routing by directly integrating third‑party channels such as Alipay, WeChat, and Lianlian. Each business line built its own checkout page and called the payment center for transactions.

The interaction flow was:

Business line sends an order request to the payment center.

The payment center adds payment information and forwards the request to a third‑party channel.

The channel asynchronously notifies the payment center of the result.

The payment center processes the callback and notifies the business system.

The business system completes its own logic, user notification, and page redirection.

This design allowed rapid response to business needs but soon showed drawbacks as transaction volume and scenario complexity grew, leading to high maintenance cost, poor disaster recovery, and tangled responsibilities.

Payment Center 2.0

The 2.0 overhaul introduced a unified order, payment, and finance system, solving three main problems:

Unified foundation : Abstracted common logic into shared services, reducing integration effort and duplicate development.

Secure, stable, extensible architecture : Provided a solid base for rapid business innovation while ensuring payment reliability.

Core transaction data consolidation : Offered big‑data support for users, merchants, and finance.

2.1 Core Capabilities

The upgraded center now supports platform payment, quick payment, protocol payment, credit payment, overseas payment, and offline (ToB) payment. Core transaction scenarios include simple payment & refund, split payment, and combined‑order payment for insurance and other split‑account cases.

2.2 Architectural Design

The system is divided into three layers:

Product layer : Checkout pages, payment management UI, and finance/reconciliation systems.

Core layer : Basic order, routing, and channel modules.

Support layer : Infrastructure such as monitoring, logging, and message queues.

Product Layer – Checkout

The checkout consists of H5 and PC versions, displaying order basics, details, and payment methods. It is built with a factory‑class inheritance pattern allowing each business line to customize UI by extending abstract modules.

Core Layer – Basic Order

The basic order service bridges business lines, the payment center, and settlement systems, handling order creation, closure, payment, refund, and callbacks. It supports scenarios such as one order with multiple goods, one order with multiple sub‑orders, and one order generating multiple payment records (split, combined, insurance).

Core Layer – Routing Management

Routing determines which payment account and channel to use based on business type, payment method, and channel. Account‑channel mappings moved from static files to a database, simplifying maintenance and enabling dynamic lookup during order creation and callback handling.

Payment channel abstraction uses a template‑method pattern: a base abstract class defines the standard flow (order, refund, query, notification, bill download), while each channel implements its specifics. Supported channels include Alipay, Alipay International, WeChat, JD Pay, Apple Pay, Lianlian, UnionPay 2B, etc.

Support Layer – Monitoring & Alerting

The support layer provides logging (ELK), configuration management, and a custom message bus (RabbitMQ). A dedicated monitoring system isolates its database from business databases and tracks API performance, service health, and database metrics. Alerts can be sent via SMS or email with configurable thresholds and rate‑limiting.

Monitoring runs in a multi‑process model: a parent process spawns workers that each handle a batch of checks, reporting results via Redis counters. When thresholds are exceeded, alerts are throttled to avoid notification storms.

2.3 Practical Experience

Data consistency : Modularization introduced cross‑system interactions, requiring transactional guarantees, real‑time and delayed validation, and compensation mechanisms to achieve eventual consistency.

Stability : Third‑party channel failures can cause duplicate payments. The payment center employs periodic scans to detect duplicates and automatically issue refunds, with exponential back‑off retry logic and alerting for persistent failures.

Conclusion & Outlook

MaFengWo’s payment center now supports multiple businesses, scenarios, and payment methods, but further work is needed to achieve a fully “flower‑blooming” platform. The upcoming 3.0 version will adopt micro‑service principles, decomposing the monolith into independent, high‑concurrency services, which will improve clarity but also increase operational complexity. Continuous innovation in payment methods will keep empowering all business lines.