Inside Payment Giants' Clearing & Settlement Design Methodology

Clearing Subsystem

After a payment is completed, the clearing system calculates each participant’s receivable and payable amounts and distributes the funds. According to the "Payment Clearing Organization Management Measures," clearing consists of payment instruction exchange and calculation. The process has two key steps: clearing (清分) , which computes principal and fees for each successful transaction, and fund transfer (划拨) , which moves the calculated amounts through designated channels.

System Overview

The clearing architecture includes an access layer, a clearing processing subsystem, an accounting service, a billing subsystem, and a front‑office accounting module (see Fig 1).

Object Relationship Model

The model maps each receivable/payable to an object (e.g., merchant, rider, insurance) and defines their relationships. Four typical models are illustrated (Fig 2): single merchant, merchant‑partner, agent‑merchant, and multi‑level agent‑partner structures.

Single merchant : simple acquiring merchant.

Merchant‑partner : platform splits revenue with merchants.

Agent‑merchant : merchant joins via an agent.

Agent‑agent‑merchant‑partner : multi‑level agent structure.

Billing Rules Subsystem

The subsystem maintains billing rules. For a single‑merchant model, it can return fee calculation modes such as percentage, fixed amount, per‑transaction ladder, or cumulative ladder. Rule matching uses condition groups (e.g., category + city) to locate applicable rules (Fig 3). Many rule templates can be generated, producing extensive rule lists (Fig 4).

Accounting Service

Different clearing tasks require distinct calculation templates. The service first selects a template based on clearing type, then computes each fee component in order. Profit‑sharing (分润) applies to fees, while settlement (分账) distributes transaction amounts (Fig 5).

Settlement System

Settlement transfers funds based on clearing results. It applies to employee payroll, merchant revenue, and acquiring institution payouts. Settlement cycles vary: ride‑hailing may settle every 3 days, home‑service monthly, e‑commerce up to 60 days.

Business Overview

Key accounts include the "merchant pending settlement account" and the "merchant settlement account" (Fig 6). Transitional accounts (e.g., pending settlement, clearing counterpart) manage in‑transit funds.

Three‑Party Settlement Products

Typical products (Fig 8) include T1, D1, D0, H0, S0, and TD settlement, each defining when funds are transferred (next workday, next calendar day, same day, hourly, per‑transaction, or cross‑day).

Implementation Patterns

Intermediate account mode : a pending settlement account records funds before they are moved to the final settlement account (Fig 9).

Freeze mode : balances are split into frozen and available; settlement releases frozen amounts (Fig 10).

Bill mode : no dedicated settlement account; a settlement bill drives payment (Fig 11).

Core Settlement Processing

Processing differs by product. Examples:

T1 settlement : settles previous workday transactions without advance funding. It filters merchants with auto‑settlement enabled, aggregates amounts by product code, and calls the billing system with parameters such as merchant code, minimum fee, product type, workday flag, and amount (Fig 16).

D1 settlement : similar to T1 but adds advance‑funding for weekend days when the upstream channel uses T1. If funding fails, settlement aborts with an “insufficient advance” error (Fig 17).

Self‑service settlement : merchants initiate settlement via the backend, optionally filtered by date, product, or balance. D0 mode processes only same‑day orders; otherwise, aggregation follows the D1/T1 logic (Fig 18).

Payment Processing

After settlement records are generated, the system creates a payment request, debits the merchant’s receiving account, and routes the payment either to a bank card or to an internal settlement account (Fig 19).

Timing Diagram

The full sequence (Fig 20) shows interaction among accounting center, settlement center, task center, and billing center, covering order aggregation, settlement, payment, status update, failure handling, and retries.

Full‑Chain Clearing & Settlement Process

Four global data segments are defined: accounting data (segment 1), payment data (segment 2), clearing data (segment 3), and settlement data (segment 4) (Table 3).

Account & Subject Setup

Multiple accounts support the clearing‑settlement flow, including pending settlement, clearing counterpart, receivable bank, and deposit accounts (Fig 26, Table 4).

In‑Transit Funds

Payment in‑transit : imbalance between platform payment records and channel clearing records. Debit balance means platform excess; credit balance means channel excess; zero means perfect match (Fig 27).

Fund in‑transit : imbalance between receivable bank account and settlement records, indicating short or long funds (Fig 28).

Customer in‑transit : pending settlement account balance shows over‑ or under‑settlement to merchants.

Illustrative Receipt Example

Scenario: two payments of ¥10 each, T+1 settlement for both platform and channel. Steps:

Payment recording creates payment data; the accounting service debits the "channel clearing counterpart" account and credits the "pending settlement merchant" account (Fig 29).

Channel clearing file reconciliation generates clearing data; a channel‑single‑side record creates a credit balance in the "channel clearing counterpart" account (Fig 30).

Platform performs a supplemental entry (补单) to correct the missing payment, generating a debit entry that offsets the previous credit (Fig 31).

Settlement aggregates amounts, generates settlement records, and updates accounts. After settlement, the pending settlement account returns to zero, confirming that all in‑transit accounts are cleared (Fig 37).

The example demonstrates that a well‑designed multi‑account framework enables accurate, efficient end‑to‑end clearing and settlement for payment platforms.