How Tencent’s PC & Mobile Payment Architecture Evolved to Support Billions

PC Payment Architecture

Evolution History of the Basic Payment Platform

The platform’s evolution is divided into three stages, each with specific availability safeguards.

Mobile Payment 1.0 – OMP, circuit breaking, degradation, rate limiting.

Mobile Payment 2.0 – health‑check platform, announcements, automatic switching.

Mobile Payment 3.0 – striping, fast/slow separation, cache‑based local queries.

Three Key Roles in the Payment System

The system involves three essential participants: users, merchants, and the platform. In an online shopping scenario, a user places an order with a merchant, the merchant creates the order on the payment platform, the platform presents a checkout page, the user confirms payment, and the platform notifies the merchant to ship.

Tenpay Basic Payment Platform and Its Development

The platform consists of two main brands—WeChat Pay and QQ Wallet—built on layered systems: an access gateway for routing and overload protection, order and settlement layers, a distributed account system, bank integration, and continuous risk‑control and anti‑money‑laundering services.

Tenpay was founded in 2005, initially serving the PC era with services like YiDianTong and Quick Pay, laying a solid foundation for later mobile payment expansion.

Mobile payment began in 2011 after the first payment licenses were issued; Tenpay was among the first to obtain a license. In 2013, WeChat Pay launched its first version, prompting a major system redesign to handle traffic spikes during holidays and flash sales.

From 2014 onward, the order system was rebuilt with caching and asynchronous processing. Between 2015‑2016, offline payment scenarios grew, leading to a multi‑active city‑level architecture. By 2016‑2017, a two‑region, four‑center, cross‑city multi‑active core architecture was introduced, followed by striping and fast/slow separation in 2017‑2018, and ongoing availability optimizations after 2019.

Architecture Evolution Path

Since 2015, the platform has progressed through five generations:

Generation 1: Centralized, single‑node data service with stateless applications; all state stored in the database.

Generation 2: Split the monolith into several subsystems with vertical partitioning.

Generation 3: Horizontal partitioning with a distributed account system.

Generation 4: Set‑based architecture enabling rapid, standardized scaling and disaster recovery, similar to container units.

Generation 5: Focus on operability, maintainability, and rapid elasticity, illustrated by a global availability view.

Mobile Payment Architecture

1.0 Era

Challenges included insufficient architecture to support rapid growth. Solutions involved OMP (single‑machine payment processing), circuit breaking, degradation, and rate limiting. OMP acts as a front‑door router, consolidating payment logic on one machine, simplifying capacity estimation and scaling.

Circuit breaker states: Closed (normal), Open (all downstream calls fail), Half‑Open (limited trial requests to restore service).

Rate limiting uses per‑machine or global strategies with algorithms such as counters, leaky bucket, and token bucket, addressing traffic bursts and uneven load.

2.0 Era

With richer offline scenarios, the platform introduced a city‑level multi‑active architecture comprising three layers: a stateless access layer (CGI on cloud), a bank‑integration layer with health checks and automatic failover, and a complex order layer that isolates sets to enable seamless switching on failures.

The account layer provides multi‑set distributed accounts, initially switched manually.

A health‑check platform collects real‑time health metrics from each layer, performs policy analysis, and feeds back actions to the live flow, achieving platform‑wide negative feedback with minimal impact.

When a set fails, health metrics trigger traffic arbitration, masking the faulty set and routing traffic to a healthy set, enabling full‑link automatic switching.

3.0 Era

As mobile payments became ubiquitous, the platform faced challenges from natural disasters and cross‑city latency (e.g., 40 ms ping between Shenzhen and Shanghai). A cross‑city multi‑active solution introduced striping to align user routing with their home city, fast/slow separation to isolate latency‑sensitive traffic, and read/write separation for consistent data access.

Data is primarily read‑heavy; a primary DB in one city updates data, while caches in all cities receive near‑real‑time synchronization via a message bus and asynchronous DB replication, ensuring consistency across regions.

Reflection & Evolution

System architecture continuously evolves: virtualization, cloudification, cloud‑native.

Goal remains constant: rapid, stable support for business growth.

Core philosophy unchanged: Tencent’s massive‑service approach.

Evolution leads to a cloud‑native availability assurance system.