Joint‑Venture Settlement Platform Overview and Billing Architecture

The offline store business model is divided into self‑operated, joint‑venture, and lease modes; this document focuses on the joint‑venture mode where merchants use store space managed by the platform.

Merchant Onboarding Settlement Overview : In joint‑venture mode, merchants retain ownership of goods and profit sharing is required after order completion. Various commercial forms such as supply‑sale, store‑sale, and tenant models increase settlement complexity.

Supply‑Sale Model – an order belongs to a distributor but a portion of the revenue must be shared with the supplier. Example settlement details:

Order ID

Merchant ID

Merchant Type

Payer Merchant ID

Settlement Amount

9000001

1001

Distributor

1000

$1600

9000001

2001

Supplier

1001

$1200

Store Model – each physical store may have its own settlement account. Example settlement details:

Order ID

Merchant ID

Store ID

Payer Merchant ID

Settlement Amount

8000002

1001

0001

1000

$1600

8000003

1001

0002

1000

$1200

Tenant Model – multi‑tenant SaaS architecture with a single database and schema. Example settlement details:

Order ID

Tenant ID

Merchant ID

Store ID

Payer Merchant ID

Settlement Amount

8000002

1

1001

0001

$1000

$1600

8000003

2

1001

0002

$1000

$1200

When a merchant joins, the system must maintain the merchant’s settlement bank information. A unified "settlement subject" is introduced to decouple business logic from the settlement platform; all billing, settlement, and invoicing data flow through this abstract subject.

The creation of a settlement subject is triggered after contract and qualification approval, allowing the settlement platform to generate an account according to predefined rules.

Joint‑Venture Billing Overview

The billing system’s responsibility is to correctly split order revenue among participants. Billing is usually triggered asynchronously via MQ, and the billing formula (e.g., Goods Payment = Item Price – Coupon) requires data from multiple upstream systems.

To reduce coupling, the billing engine provides a generic, configurable framework consisting of:

Message Validation & Task Generation (101)

Command Receiver (102)

Billing Engine (103) – includes Business Rule Service, Data Snapshot Service, and Fee Calculation Service.

Business Rule Matcher (103‑01)

Business Rule Configuration Service (103‑02)

Data Snapshot Service (103‑03)

Data Strategy Service (103‑04)

Fee Element Dictionary Service (103‑05)

Fee Calculation Executor (103‑06)

Billing Formula Configuration Service (103‑07)

After billing, the results are sent to the Settlement Center (104) for further processing.

Settlement Process

Based on contract‑defined settlement cycles, settlement orders are generated. When billing data arrives, it is linked to the appropriate settlement order. Different fees may use different settlement subjects, as shown in the configuration table:

Tenant ID

Business ID

Fee ID

Settlement Subject

1

1001

31

900001

2

1001

32

900002

At the end of the settlement period, the order is closed, and the system calculates receivable/payable amounts, splits them according to the settlement subject, and generates payment documents.

Payment Collection (收付费) Overview

Non‑order fees (e.g., warranty deposits, penalties) are handled by a separate payment‑collection system, which creates payment‑collection documents, undergoes approval, and finally generates payment orders. The payment system simply routes funds based on the settlement subject.

Reconciliation System Overview

Because order data is spread across multiple micro‑services (logistics, payment, settlement, invoicing), a reconciliation system aggregates these data to provide a complete financial view. Two approaches are discussed:

Offline data warehousing for multidimensional queries.

Real‑time MQ‑based data stitching.

The proposed solution uses binlog capture to stream database changes to MQ, processes them with a Storm topology, stores monthly indices in Elasticsearch, and provides unified query APIs.

Architecture Diagrams

These diagrams illustrate the core components and interaction sequences of the joint‑venture settlement, billing, payment collection, and reconciliation subsystems.