Designing Scalable Payment Systems: Architecture, Modules, and Business Flow

21CTO Community Guide: In internet product operations many face rising traffic costs while user activity and retention continue to drop, prompting the need to integrate a payment system to close the commercial loop and enable monetization.

Understanding payment product design from classification, module functions, and business flow

The payment product module sits between the payment gateway and payment channels, encapsulating various channels into a unified interface. From a micro‑service perspective, the payment product acts as a proxy service that receives requests from business systems, performs unified processing, and forwards them to the appropriate channels.

Payment product placement in a reference architecture:

Product Classification

Different companies may classify payment products slightly differently, but generally they fall into the following categories:

1. Quick Pay After binding a card, users only need to enter a payment password (or a small‑amount no‑password option) to complete the transaction, providing a seamless experience for low‑value payments.

2. Online Banking Pay Users are redirected to the bank’s online banking page to enter card and identity information, interrupting the flow; typically used on PC web.

3. Protocol Pay Also known as collection or deduction, used for recurring payments such as utilities; implemented via bank or third‑party collection interfaces.

4. Platform Pay Payments through third‑party platforms like WeChat or Alipay, requiring users to install and bind cards on the platform.

5. Foreign Card Pay Supports overseas cards, e.g., Alipay Global or PayPal.

6. Mobile Bill Pay Small‑amount, subscription‑type payments using mobile phone bills.

7. Virtual Currency Pay Company‑specific virtual currencies such as JD Beans or Q Coins.

8. Account Pay Balance or wallet payments after users recharge a local account.

9. Credit Pay Credit‑based payments like JD Baitiao or Ant Credit Pay.

10. Payout Opposite of collection; the platform transfers money to users.

Module Functions

Payment products expose various interfaces to provide payment capabilities:

Signing and Termination Users must sign contracts before using quick pay or collection services; signing can be performed on the channel side or the merchant side.

Payment Initiated either on the merchant server (quick pay) or via redirection to the bank gateway (online banking), or locally for wallet/virtual‑currency payments.

Reversal and Refund Some channels distinguish reversal (cancelling unsettled same‑day transactions) from refund (post‑settlement).

Query Signing Status Check the status of a contract.

Query Order Status Retrieve payment or refund order status.

Pre‑Authorization Reserve an amount with the issuing bank.

Pre‑Authorization Reversal Cancel a pre‑authorization before settlement.

Pre‑Authorization Completion Settle a pre‑authorized transaction.

Pre‑Authorization Completion Reversal Fully reverse a completed pre‑authorization.

Reconciliation Provide reconciliation files via FTP/HTTP.

Balance Query Query merchant account balance (not end‑user balance).

Business Process

Each operation (except reconciliation and order query) typically follows seven steps: parameter validation, payment routing, risk assessment, order generation, channel invocation, order update, and message notification. Complex services may also involve asynchronous notification handling.

1. Parameter Validation

Validate field correctness (user ID, merchant ID, price, return URL, etc.).

Check account status for tradeability.

Validate order existence and status.

Verify signature (e.g., MD5 or RSA using merchant key).

2. Payment Routing

Select the optimal channel based on user‑chosen method, fees, and channel availability.

3. Risk Assessment

Risk engine returns one of three actions: block transaction, enhanced verification (e.g., SMS code), or allow transaction.

4. Order Generation

Persist order data; high traffic may make DB writes a bottleneck.

5. Channel Invocation

Call third‑party or bank interfaces; some return results synchronously, others asynchronously.

6. Order Update

Update order status based on synchronous or asynchronous responses.

7. Message Notification

Publish messages to downstream systems (risk, credit BI, etc.) for near‑real‑time processing.

8. Asynchronous Notification

Use callback URLs (HTTP/HTTPS) to receive channel results, with retry strategies and exponential back‑off.

Overall Payment System Architecture

Different companies design payment systems according to their business stage. Below are typical architectures from major internet firms.

Alipay

Key points: dual‑system accounting (single‑sided for online performance, double‑entry for finance) and flexible transaction handling via messaging.

JD Finance

Built on NetBank Online, incorporates talent from both NetBank and Alipay.

Qunar

Meituan

These diagrams are public; their fidelity to actual systems may vary.

Reference Architecture

A typical payment system consists of three layers:

Support Layer – infrastructure such as monitoring, logging, SMS platform, security mechanisms, and reporting.

Core Layer – payment core module and payment service module.

Product Layer – applications for end users, merchants, and operations built on the core services.

Support Systems

Operations monitoring

Log analysis

SMS platform

Security mechanisms (SSL, anti‑fraud)

Statistical reporting

Additional components include remote connection management, distributed computing, messaging, full‑text search, file transfer, storage, and machine learning.

Payment Core System

User initiates payment from an application.

Application calls the appropriate payment product based on selected tool.

Payment routing selects the optimal channel considering fees and stability.

Channel invokes bank or third‑party interfaces to complete fund transfer.

Payment Service System

Supports the core system with three sub‑systems:

Basic services – customer info, coupon management, channel management, account & accounting, order system.

Fund system – accounting, fund management, settlement & profit sharing.

Risk & credit system – risk assessment and credit services such as JD Baitiao and Ant Credit Pay.

Payment Applications

Applications vary by target audience: end‑user apps, merchant portals, operations dashboards, BI, and risk‑control back‑ends.

Summary

This article described the overall architecture of payment systems and will later dive into detailed design of each module.

Author: Fenghuangpai Lao Xiong