Building a Payment Middle Platform: 5 Core Modules and Real-World Scenarios

Why a Payment Middle Platform

When a SaaS provider expands from a single business line to multiple lines, each line needs payment capabilities such as checkout, reconciliation, settlement, and profit sharing. Developing these separately leads to duplicated effort and higher operational cost. A payment middle platform abstracts common payment functions into a reusable service that can be shared across all lines, reducing development and operational overhead.

How to Build It

Identify the SaaS provider’s payment touch‑points: POS terminals, mini‑programs, web pages, facial‑recognition devices, QR‑code plates, and mobile apps. The platform must support merchant onboarding, payment‑account configuration, routing, multi‑dimensional reconciliation, profit‑sharing, and settlement.

Core Modules

1. Merchant Account Configuration

Provides a unified UI/API for operators or agents to onboard merchants, submit licensing information to third‑party payment providers, and configure payment accounts. Supports both direct‑connect (merchant obtains its own payment‑merchant‑id) and service‑provider modes (merchant’s account is attached to the SaaS provider or an agent). Allows batch configuration of multiple stores and assignment of different payment channels per store.

2. Payment Core System

Receives payment requests from any terminal, looks up the merchant’s routing rules, and forwards the request to the appropriate upstream channel. Exposes a set of unified APIs:

Create Order – generate a payment order and obtain a pre‑payment token from the upstream channel.

Query Order – poll order status while it is in a non‑final state (e.g., “PAYING”, “REFUNDING”).

Cancel Order – invoke upstream cancellation when payment fails or times out.

Refund – submit a refund request and later query its result.

Callback Handling – process asynchronous notifications from upstream channels, update internal order status, and push the result to downstream business systems.

The core also encapsulates channel‑specific logic (e.g., WeChat Pay, Alipay) behind a common interface, making it easy to add new channels.

3. Reconciliation

Aggregates transaction data by store, date, cashier, and POS device. Generates multi‑dimensional reconciliation reports and optionally downloads raw reconciliation files from upstream providers for finance verification.

4. Profit Sharing

Based on pre‑defined ratios, the platform splits a portion of transaction revenue to agents or partners that use the default payment channel, creating a “sleep‑after‑income” stream for both the SaaS provider and its agents.

5. Settlement

All funds are collected into a unified settlement account. On the settlement day, the platform distributes the net revenue to merchants, agents, and the SaaS provider according to configured percentages.

Typical Payment Scenarios

3.1 B‑scan‑C (Barcode Scan)

The merchant’s POS scanner reads the customer’s QR code (WeChat, Alipay, etc.). The platform forwards the request to the upstream channel, which validates the password or processes a password‑free transaction.

3.2 C‑scan‑B (Dynamic QR)

The merchant generates a dynamic QR code that embeds the order amount. The customer scans it, confirms payment in their app, and the platform obtains a pre‑payment token from the upstream channel before completing the transaction.

3.3 JSAPI (Mini‑Program / Public Account)

Customers initiate payment via a static QR plate or a mini‑program, manually entering the order amount before confirming payment. This is common for small merchants and street vendors.

3.4 APP Payment

When a merchant’s own mobile app initiates payment, the platform first requests a pre‑payment token from the upstream channel, then launches the third‑party SDK (e.g., Alipay, WeChat) to complete the transaction inside the app.

Payment Flow Details

All terminals follow the same logical steps:

Order Creation – terminal sends a request with merchant ID, amount, and optional metadata.

Routing – the core looks up the merchant’s payment‑account configuration and selects the appropriate channel.

Channel Invocation – the platform calls the upstream API (e.g., /v3/pay/transactions/jsapi for WeChat) to obtain a pre‑payment token.

Customer Interaction – the token is returned to the terminal, which presents the QR code or SDK UI to the customer.

Result Notification – the upstream channel sends an asynchronous callback; the platform updates order status and triggers downstream notifications.

Post‑Processing – depending on the outcome, the platform may invoke query, cancel, or refund APIs, and later include the transaction in reconciliation and settlement.

Benefits

Shared payment capability across multiple business lines saves manpower and accelerates feature delivery.

Decouples payment logic from individual business systems, enabling rapid integration of new channels.

Supports multi‑channel fee optimization and profit‑sharing, creating additional revenue streams for the SaaS provider and its agents.