Industry Insights 15 min read

How Baidu’s Transaction Middle‑Platform Asset System Enables C2C Payments and Guarantees Consistency

This article details the design and implementation of Baidu's transaction middle‑platform asset system, covering its C2C payment model, core asset management capabilities, consistency guarantees, double‑entry accounting, hot‑account handling, sharding and archiving strategies, and compliance with national financial regulations.

Baidu Geek Talk
Baidu Geek Talk
Baidu Geek Talk
How Baidu’s Transaction Middle‑Platform Asset System Enables C2C Payments and Guarantees Consistency

Baidu's transaction middle‑platform asset system extends the existing transaction platform to provide a unified solution for managing C‑end user cash and virtual assets (such as virtual coins) across internal services, supporting secure, reliable asset management that complies with national clearing regulations.

System Overview

The system consolidates user asset information, handling recharge, consumption, refund, gifting, withdrawal, and tax calculation, while offering platform‑wide settlement, reconciliation, and financial reporting capabilities.

Business Scenarios

It currently serves more than 20 business lines, including video rewards, Q&A tipping, legal services, and Baijiahao virtual currency, covering three core asset categories: virtual‑coin, cash, and asset‑type balances.

Asset Types

Virtual‑coin: Supports multi‑dimensional accounts (iOS, Android, recharge, gifting) with basic operations (creation, increase, decrease) and advanced features such as purchase, refund, transfer, consumption, reverse consumption, balance queries, transaction logs, cross‑line conversion, and expiration handling.

Cash: Provides end‑to‑end flow from payment to consumption, settlement, tax calculation, and withdrawal, supporting multiple withdrawal methods (Alipay, WeChat, Du Xiaoman, bank cards) and various settlement cycles.

Asset: Focuses on asset management for content monetization, offering multi‑dimensional accounts and configurable settlement for business partners.

Asset Business Process

For cash‑type assets, users perform actions such as recharge, reward, and consumption; the business side invokes either the transaction system or the asset system directly. The asset system processes requests based on configuration, supports timed or user‑initiated withdrawals, and routes funds to the appropriate withdrawal channels.

Consistency Guarantees

Payment consistency: Upgraded the payment interface to full‑parameter signing, reducing the risk of tampering and simplifying downstream integration.

Change consistency: Ensured eventual consistency and performed data reconciliation across systems.

Hot accounts (high‑concurrency balances) use distributed locks for non‑hot accounts and a cache‑first approach for hot accounts, with asynchronous batch synchronization to the database.

Double‑Entry Accounting

Implemented financial double‑entry bookkeeping: each transaction debits one account and credits another, ensuring atomicity, idempotent APIs, and traceable balance changes. Principles include "debit must have a credit" (except recharge/withdrawal) and maintaining per‑currency sum consistency.

Account balance counters are updated alongside detailed transaction records.

Four account types (reward cash, general reward, reward withdrawal, reward withdrawal debt) are defined, each with specific inflow/outflow rules.

Hot‑Account Handling

Hot accounts are processed by inserting only detailed records and marking them as "unaggregated"; an asynchronous aggregator computes the actual balance and updates the cached balance. Three balance views are maintained: ledger balance, actual balance (ledger + unaggregated), and cache balance.

Storage Design

Data volume (asset logs 2‑5× order volume) exceeds single‑node MySQL capacity, so the system employs both database sharding (16‑shard, 1024 tables) and table partitioning. Hot‑account data skew is mitigated by archiving records older than three months to a separate historical database.

To support complex multi‑dimensional queries after sharding, Elasticsearch is synchronized in near real‑time via Canal reading MySQL binlogs.

Regulatory Compliance

Traditional B2C payment models cannot satisfy C2C scenarios due to lack of identity verification for both parties. Baidu introduced a personal register solution, adding individual information to the banking system, enabling personal‑ledger payments that meet national clearing requirements.

Conclusion

The asset system is designed to accelerate the development of all payment‑related scenarios within Baidu, addressing payment, settlement, and disbursement challenges while complying with financial regulations. Ongoing iteration will continue to refine functionality and address emerging business needs.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Distributed Systemsdatabase shardingConsistencyTransaction Platformasset managementfinancial complianceC2C payments
Baidu Geek Talk
Written by

Baidu Geek Talk

Follow us to discover more Baidu tech insights.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.