Designing a Secure Payment Funds Account System: Architecture, Accounting Rules, and Best Practices

Account and Funds Account System Overview

An account records the balance and transaction details of a subject (user, merchant, bank, etc.). Key fields include account ID, currency, balance (stored in the smallest unit), status, and a monotonically increasing balance version number.

A funds account system is a virtual ledger similar to a bank account. It tracks user and merchant balances, transaction flows, and provides traceability. The system must meet high availability, strong security, and compliance requirements.

Key Design Principles

All ledger entries are immutable; cancellations are recorded as opposite transactions.

Balance version numbers are sequential and serve as the source of truth for transaction ordering.

Double‑entry bookkeeping: every debit has a matching credit, ensuring "debits equal credits".

Core Components

The system consists of a balance module , a transaction ledger , and optional vouchers that store transaction metadata in the business layer.

Implementation Overview

The solution is deployed in a Tencent Cloud native environment (TKE) and focuses on merchant accounts only. Simplicity is emphasized: unnecessary entities are omitted while meeting real‑time settlement requirements.

Fund Flow Design

Fund flow includes multiple account types (e.g., merchant, fee, bank) and records both incoming and outgoing movements. Separate fee accounts can be used for income and expense streams. Bank account integration ensures alignment with external financial flows.

Storage Selection

Requirements: high performance, strong consistency, transparent sharding, elastic scaling, cross‑region disaster recovery, and native distributed transaction support. After evaluating MySQL, NoSQL KV stores, and Tencent Distributed SQL (TDSQL), TDSQL was chosen for its native 2‑phase commit (2PC), strong consistency, and automatic horizontal sharding using account_id as the sharding key.

Architecture Design

The architecture separates the fund service (business‑level logic) from the account service (core balance management). Each service has its own database and a set of daemon processes for asynchronous tasks, achieving high cohesion and low coupling.

Security Measures (STRIDE Model)

Spoofing : API signatures and login tickets for authentication.

Tampering : HMAC‑SHA256 MAC verification on critical fields.

Repudiation : Immutable transaction logs.

Information Disclosure : Strict permission controls and key management.

Denial of Service : Rate limiting at service and database layers.

Elevation of Privilege : Role‑based access control (RBAC) and module authentication.

Permission Control

Database access is limited to the owning service, machine‑level isolation is enforced via TKE network policies, and business‑level checks use ticket verification and module authentication.

Anti‑Tamper and Key Management

Critical fields are protected with an HMAC‑SHA256 MAC stored in the database (e.g., data_mac). Keys are managed by a cloud KMS that provides hardware‑based true random numbers, automatic rotation, and fine‑grained access control.

Rate Limiting and Hot‑Key Mitigation

Both single‑node and distributed rate limiting protect the database from traffic spikes.

Hot‑key issues are addressed by: recording only the ledger without immediate balance updates, batching multiple credits into a single update, or splitting a hot account into multiple sub‑accounts.

Idempotency Design

All account‑related APIs enforce idempotency by requiring a unique transaction identifier with a unique index in the database, preventing duplicate balance changes on retries.

Consistency Between Balance and Ledger

Strong consistency is achieved using database transactions. The system adopts pessimistic locking (row‑level exclusive lock) for write‑heavy scenarios to ensure that balance updates and ledger inserts succeed atomically.

Distributed Transactions and Final Consistency

Cross‑account transfers involve accounts that may reside on different shards. TDSQL’s native 2PC protocol provides atomicity and consistency across shards. The implementation follows a CP approach (consistency + partition tolerance) to guarantee financial correctness.

Reconciliation and Auditing

Automated reconciliation checks verify:

Balance correctness against the latest ledger version.

Ledger continuity (each entry’s start balance matches the previous entry’s end balance).

Total‑to‑total matching between internal records and external bank statements.

Timeliness of settlement (e.g., detecting overdue un‑settled orders).

Any inconsistency triggers alerts for immediate investigation.

Accounting System Integration

A real‑time accounting framework generates T+1 reports, financial statements, and audit trails, aligning virtual account movements with actual bank balances.

R&D Process Guidelines

Strict production machine and database permission management.

Two‑person code review.

Full unit and integration test coverage.

Deployments performed exclusively via the release system.

Availability Engineering

Availability is addressed at three layers:

Program/Node : TKE provides auto‑recovery, load balancing, health monitoring, and private network isolation.

Service : Rate limiting, hot‑key handling, and graceful degradation.

Storage : TDSQL offers 99.999% uptime, cross‑region replication, automatic failover, and online capacity scaling.

Offline batch jobs are scheduled with Airflow for reliability.

Performance Testing

Load testing is performed before production to validate that availability targets are met and to uncover potential security or consistency issues.