Mastering Payment Systems: 300+ Hand‑Drawn Diagrams Simplify Complex Core Processes

1. Payment System Core Business

Payment platforms, especially licensed acquiring institutions, provide many services. Besides common payment, refund, and withdrawal, they also offer personal bill queries and merchant bill downloads.

Here we introduce the most core services perceived by customers (both individuals and merchants).

A licensed payment institution generally provides the following core customer‑facing capabilities:

Payment (Acquiring) : Transfer user funds from the user to the payment platform’s account.

Reversal : Directly close orders that have not succeeded; return funds to the user for orders that have succeeded.

Refund : Return the user's payment back to the user.

Clearing : External channels transfer money to the payment platform.

Settlement : The payment platform settles money to the merchant.

Recharge : Users top up their balance accounts on the platform.

Transfer : Transfer between user or merchant accounts.

Payroll : Help merchants transfer money to individual users’ accounts, either to cards or balances.

Allocation : Internal transfers between multiple bank accounts for liquidity management.

Withdrawal : Users withdraw money from the platform’s balance account to an external bank card.

In some cross‑border scenarios, the payment system also needs to provide foreign exchange services, e.g., a Chinese merchant selling on an overseas brand like Temu receives USD from the US user but needs to obtain RMB in China.

Additionally, there are many auxiliary capabilities such as merchant onboarding, merchant self‑service, and personal self‑service.

Each business in a payment system involves multiple sub‑domains and many operational steps. For example, the payment sub‑process includes gateway signature verification, decryption, merchant platform permission check, risk control check, product center validation, and finally persisting the order in the acquiring domain.

2. The Essence of Payment

Payment essentially means helping merchants deduct users’ money into the payment platform’s account.

Special cases include balance payments and marketing. Balance is a virtual account opened by the platform and does not call external channels. Marketing often uses internal marketing systems for verification, with funded and unfunded types.

Accounting aspects are not illustrated here; they are detailed in later accounting chapters.

3. Payment Fund Flow

The fund flow is detailed in later accounting chapters; here is a brief description.

First, the virtual fund flow, i.e., the internal fund flow of the payment platform, using an instant settlement model:

Explanation: Payment platform bookkeeping uses double‑entry accounting. After a channel deduction succeeds, both “payment gateway transitional account” and “channel pending settlement” are recorded. For simplicity, only the transitional account is shown.

There are also split‑payment and profit‑sharing models. For example, merchant A joins through a large merchant B; merchant A receives 98 units, merchant B receives a 1‑unit fee, and the platform settles directly to both.

Physical fund flow is the transfer between external banks.

4. The Essence of Refund

Refund essentially means first deducting the money from the merchant and then transferring it to the user.

Balance refunds do not call external channels.

The full process is long: after receiving a merchant’s refund request, the system checks historical contracts, refund eligibility, expiration, minimum amount, etc., then creates a refund order. In the refund fund preparation stage, unless otherwise agreed, the platform generally does not advance funds. The platform must deduct the merchant’s pending settlement amount in real time, which differs from the payment process. Some platforms may have a separate refund account, requiring sufficient balance.

5. Refund Fund Flow

After refund verification passes, funds are prepared and collected into a refund transitional account. After successful channel call, they move to channel pending settlement.

For simplicity, only a single‑sided account is drawn; actual bookkeeping uses double‑entry.

Additional processes such as clearing file reconciliation, channel settlement, and bank position updates are not illustrated.

6. External Channel Clearing

When external channels successfully complete payment or refund, a clearing process occurs: the channel aggregates the day’s transaction data, generates a clearing file, the payment platform parses it, reconciles with internal transactions, and upon successful reconciliation moves funds from pending settlement to due settlement, then after the channel actually pays, the platform records the bill and finally transfers from due settlement to bank position.

More details are in later accounting sections.

Explanation: The diagram shows a three‑party wallet scenario where both the payment platform and external channel have bank accounts, resulting in inter‑bank transfers.

In special cases, the external channel is a bank where the payment platform directly opens an account, leading to internal transfers within the bank.

7. Merchant Settlement

In acquiring institutions (payment platforms), settlement means accurately and timely settling the money collected from merchants according to agreed settlement rules.

Before settlement, a clearing step splits the payment amount according to contracts, e.g., a 100‑unit payment may be split into 1‑unit platform fee and 99‑unit merchant amount.

Depending on the contract, settlement can be to a balance or to a card, and settlement cycles (T+n) define when funds are settled (e.g., T+0 same‑day, T+2 on the third day).

8. Recharge

Recharge means users top up the payment platform’s balance account. Because balance involves fund security, it generally requires a licensed operator.

Many licensed institutions encourage users to recharge because:

Balance payments have a very high success rate.

Funds retained increase user engagement frequency.

In overseas markets, large liquidity enables interest or investment returns.

The core of recharge has two points:

The payment platform calls the channel to transfer user account money to the platform’s account.

The platform adds the corresponding amount to the user’s balance account.

9. Transfer / Payroll / Allocation

Transfer, payroll, and allocation all essentially move funds from one account to another, with subtle differences:

Transfer : Typically person‑to‑person, including balance‑to‑balance or balance‑to‑card.

Payroll : Typically merchant‑to‑person, e.g., salary disbursement.

Allocation : Internal transfers between multiple bank accounts of the payment platform for liquidity management.

Special transfers include red packets (one‑to‑one or one‑to‑many) and AA collection (many‑to‑one).

Example: User A transfers 100 units from their balance to user B’s bank card:

Explanation:

The platform first deducts user A’s balance.

Then it calls the external channel to transfer the funds, and the bank moves the platform’s reserve funds to user B’s account.

10. Withdrawal

Withdrawal is also a transfer: the user moves money from the platform’s balance account to their external channel account.

The difference from ordinary transfer is that withdrawal is the user moving their own balance to an external bank account, e.g., Alipay or WeChat balance withdrawal to a bank.

11. Foreign Exchange

Foreign exchange appears to simply swap one currency for another, but it is highly complex, involving free‑flow and controlled currencies, spot, forward, swap trades, and cross‑border e‑commerce settlement. The foreign exchange market is the world’s largest financial market.

12. Acquiring Evolution

1) No acquiring institution model : Simple cash‑for‑goods like a small shop.

Pros: simple. Cons: cannot complete online transactions.

2) In‑bank acquiring model : Issuing card and acquiring are the same bank.

Pros: low fees, high success. Cons: limited business scope, e.g., merchants cannot deploy all bank POS machines.

3) Separate issuing and acquiring banks

Usually the user’s issuing bank and merchant’s acquiring bank differ, but this model is largely obsolete due to high maintenance costs.

4) Clearing institution model

Issuing and acquiring banks connect via a clearing institution (e.g., China UnionPay, VISA, Mastercard), forming a star topology.

5) Third‑party payment (e‑wallet) model

Internet payment rise creates a star structure centered on third‑party payment providers.

13. Payment Consultation

Before payment, the system calls the checkout to view available payment methods, known as payment consultation.

The above images show different checkout forms for e‑commerce (JD) and payment platforms (WeChat Pay).

Payment consultation involves:

Basic checks: payment status, user, merchant.

Asset consultation: bound cards, balance, marketing (e.g., coupons, red packets).

Channel consultation: currency, amount, channel switches.

Limit consultation: per‑transaction, daily, monthly limits.

Assembling payment methods: combine assets and channels into user‑friendly options.

Sorting payment methods: recommend order based on user experience and marketing strategy.

Finally, the assembled payment methods are returned to the user for selection.

14. Payment Acceptance

After the user selects a payment method and confirms payment, the acceptance stage begins, performing:

Repeat all consultation checks (balances may have changed, orders may have expired).

Risk assessment via risk control.

If card payment via external channel, route to the optimal channel.

Submit payment request to the payment engine for actual deduction.

Poll the acquiring platform for transaction result.

Why poll from the acquiring platform instead of the payment engine? Because the acquiring result is the final user‑visible outcome; the engine may succeed but the acquiring platform could close the order, prompting a refund.

15. Common Channel Types

Channels (also called “paths”) are unified as “channels”. They are classified from a fund‑flow perspective into four categories: payment channels, outflow channels, foreign‑exchange channels, and information channels.

1) Payment channels : Move user funds into the payment platform’s reserve account (e.g., recharge, online payment).

2) Outflow channels : Move funds out of the platform (e.g., merchant withdrawals, internal liquidity transfers).

3) Foreign‑exchange channels : Currency conversion and cross‑border fund transfers.

4) Information channels : No fund flow, e.g., KYC, card binding.

5) Payment‑type Channels

Various classifications evolve over time. Examples include:

6) Card channels

Debit/Credit Card Payment : Traditional method where funds are directly deducted from the bank account. Credit cards involve pre‑authorization, request, 2D/3D scenarios. Pre‑paid cards are virtual and not perceived by the platform.

Western countries heavily use credit cards.

Tokenized payments replace clear‑text card data with tokens in the request.

Four‑party model: merchant, acquiring bank, card association, issuing bank.

7) Online banking channels

Redirect to bank website; low success, rarely used in China.

8) Quick‑pay channels

Users bind cards in advance; no need to re‑enter card info, high success rate.

9) Withholding channels

Automatic deduction after user authorizes; used for periodic payments like utilities, subscriptions.

10) Third‑party wallet channels

Examples: Alipay, WeChat Pay, PayPal, GCash. Wallets may also bind bank cards.

Interaction modes: jump to external app or non‑jump (backend token payment).

11) Virtual Account (VA) channels

Users receive a virtual account number to pay without a card, common in Southeast Asia.

VA can also be used for merchant collection, which is a different scope.

12) OTC (Over‑The‑Counter) channels

Similar to VA but the payment code is generated by retail stores (e.g., 7‑Eleven) where users pay cash to the store.

13) Credit‑pay channels

Based on user credit, the platform grants a quota for purchase‑now‑pay‑later (BNPL). Examples: Alipay Huabei, JD Baitiao.

Unlike credit‑card installments, credit‑pay is based on third‑party financial institution accounts without a card.

16. Account Classification

In accounting systems, accounts are mainly:

Customer accounts (visible to customers): personal and merchant accounts.

Internal accounts (not visible): positions, fee income, transitional accounts, etc.

17. Bookkeeping Direction

Explanation:

Account type and debit/credit direction: same sign = increase (DD+), opposite sign = decrease (DC‑), etc.

Example: User withdraws 100 units – Debit user balance (liability) 100, Credit withdrawal transitional account 100.

18. Real‑time vs Buffered Bookkeeping

Customer‑facing accounts (recharge, withdrawal, merchant withdrawal, refund) require real‑time bookkeeping for user experience and risk control.

High‑throughput accounts may need buffered bookkeeping: record logs first, then batch process, with strict loss‑prevention controls.

Other techniques include account splitting.

19. Accounting Subjects and Entries

Accounting subjects classify elements like assets, liabilities, equity, revenue, expense, often in multiple levels.

Most payment systems use three‑level subjects; some complex systems use five levels.

20. Bookkeeping Scheme

Define transaction codes for different scenarios to drive bookkeeping.

Different companies may have simpler or more complex schemes.

21. Accounting Day and Day‑Cut

Accounting day defines the date for transaction settlement, handling time‑zone differences and cut‑over logic (T+n).

Day‑cut tasks include trial balance, parent‑child subject balance, general ledger balance, period aggregation, and accounting day change.

22. Reconciliation Difference Handling

Reconciliation results:

Balanced: all fields match.

Long‑payment: platform amount less than channel (or vice versa for refunds).

Short‑payment: platform amount greater than channel.

Differences are first placed in a pending list; if still unresolved after T+2, they go to discrepancy handling.

23. Three‑Layer Bank Channel Reconciliation

Layer 1: Information flow detail reconciliation (transaction‑by‑transaction).

Layer 2: Bill reconciliation (aggregate statements).

Layer 3: Account‑actual reconciliation (internal position vs bank balance).

24. Payment Bookkeeping

Even a simple payment involves multiple bookkeeping entries at different nodes, decided by finance.

Only normal scenarios are shown; discrepancy cases are omitted.

25. Merchant Settlement Bookkeeping

Merchant settlement is independent from user payment.

Different companies may have varying internal account structures.

26. Simple Double‑Entry Bookkeeping

Payment platforms use double‑entry bookkeeping. Example: user pays 500 units via bank.

Internal accounts include assets, liabilities, etc.

Key principles: every debit has a corresponding credit; assets increase on debit, decrease on credit; liabilities increase on credit, decrease on debit.

27. Channel Routing

Routing selects the optimal channel based on success rate, cost, user experience, and channel status.

Improve success rate.

Optimize cost.

Enhance user experience.

Load balancing.

28. Minimal Payment Flow

The diagram shows the simplest flow; real interactions are far more complex.

Core purpose: help merchants collect money; licensed entities are “acquiring institutions”. Non‑licensed entities act as “acquiring relays”.

Payments also involve refunds, reversals, and cross‑border foreign exchange.

29. Minimal Clearing & Settlement Flow

Shows information flow; banks and payment platforms interact via clearing institutions; settlement to merchants may be to internal balance or directly to card.

30. Minimal Same‑Currency Acquiring Flow

All currencies (product price, order, user payment, merchant settlement) are the same; no foreign exchange involved.

31. Minimal Cross‑Border Acquiring Flow

Cross‑border: payment currency differs from settlement currency, requiring foreign exchange locking and conversion before settlement.

32. Slightly Complex Cross‑Border Example

Example: User pays $50 via PayPal on an overseas e‑commerce platform (Pinduoduo). The diagram simplifies many intermediate entities.

33. Minimal Information & Fund Flow

Information flow: user recharge triggers requests to bank. Real fund flow: bank balance changes. Virtual fund flow: platform internal balances change.

34. Minimal Settlement Flow with Clearing

Funds ultimately flow to merchant’s bank account; multiple internal accounts handle fees, taxes, profit sharing, etc.

35. Minimal Cross‑Border Settlement Protocol

Shows typical agreements among payment platform, cross‑border settlement institution, and e‑commerce platform.

36. Minimal Cross‑Border Fund Scheme

Typical flow: user pays USD, platform receives USD, converts to CNH, then settles CNY to Chinese merchant.

37. Core System Dependency Diagram

Blue line indicates the main payment chain; many other dependencies exist.

38. Payment Security

Key focus areas:

Sensitive information storage (personal IDs, card data, passwords, merchant credentials, channel certificates).

Secure transmission between clients, servers, merchants, banks (encryption).

Integrity and non‑repudiation of transaction data.

Fraud prevention (cash‑out, money‑laundering, risk control).

Service availability (DDoS protection).

39. Asset‑Loss Prevention

Asset loss is a critical risk; robust prevention systems are essential.

Prevention involves risk identification, control measures, monitoring, and response.

Full lifecycle includes design, implementation, operation, and incident handling.

Risk categories: operational, technical, compliance, etc.

40. Conclusion

One picture is worth a thousand words; the selected 60 high‑resolution diagrams aim to help everyone learn payment system design and implementation.