Aggregate Payment and the Service Provider Model: Unified Channels, Sub-Merchants, and Split Settlement

Aggregate Payment and the Service Provider Model: Unified Channels, Sub-Merchants, and Split Settlement

Platform businesses almost always hit the same wall: users want Alipay, others want WeChat, and enterprise customers want UnionPay. That means three integrations, three callback systems, three reconciliations and three refund rule sets. The harder question is whose account the money lands in.

There are three distinct paths to solving this, and the boundaries matter, because choosing wrongly is not merely a technical problem but potentially a compliance one. For single-channel details, see WeChat Pay APIv3 integration in practice and Alipay Open Platform integration.

1. Boundaries of the Three Models

Direct integration: the merchant contracts separately with Alipay, WeChat Pay and UnionPay, and funds settle into its own accounts. Technically three independent systems, with the cleanest fund relationships.

Service provider model: you integrate as a service provider and create sub-merchant accounts in bulk for merchants under you. When a user pays, funds go directly to the sub-merchant account, and the service provider handles only technology and operations. This fits platforms, SaaS providers and chain brand headquarters.

Aggregate payment: a third party wraps multiple channels into one interface and one callback, so you integrate a single counterparty. It solves integration efficiency and does not change fund ownership.

The three are additive rather than alternative. A platform might be a WeChat Pay service provider creating sub-merchant accounts, while also using an aggregate provider for unified technical access.

2. The Second Clearing Red Line

One concept must be stated plainly: a platform that collects users' money and then settles it to merchants itself is performing secondary clearing, which constitutes unlicensed payment business. Regulators have run dedicated cleanup campaigns against non-compliant aggregate payment services, and the core principle is that aggregate payment institutions may not perform fund clearing.

The test is simple: did the money pass through your account?

• User pays, money enters the platform account, platform transfers to the merchant: second clearing, non-compliant;
• User pays, money enters the merchant's sub-merchant account directly, platform only provides services: the compliant service provider model;
• User pays, money enters the platform account and the platform holds a payment license: licensed operation, an entirely different category.

So the first question a platform should answer is not which aggregate provider to choose but whose account the money should ultimately land in. Split settlement exists precisely so funds can be distributed without entering the platform account.

3. Implementing the Service Provider Model

With WeChat Pay and Alipay, the path roughly runs:

1. The service provider entity completes onboarding and permission applications.
2. Onboarding materials are submitted for each merchant: business license, legal representative information, settlement account, business scenario.
3. Once approved, the merchant receives a sub-merchant number.
4. The sub-merchant number is passed as a parameter at order creation, and funds settle to the sub-merchant settlement account.
5. The service provider uses unified endpoints for queries, refunds and reconciliation.

Points that break: onboarding materials must be genuine and consistent with the business scenario, since a wrong industry category changes rates or restricts features; the settlement account must belong to the merchant, on a corporate or legal representative account, because binding the service provider's account is second clearing; and sub-merchants carry their own rates and permissions, which cannot be assumed to match the parent.

4. Two Split Settlement Paths

When an order must be split among several parties, such as platform commission, supplier payment, distribution commission and service provider share, split settlement is required. Two approaches dominate domestically:

Channel-side splitting: use WeChat Pay or Alipay split settlement products to distribute funds to designated receivers after a successful payment. Compliance is strongest because funds never touch the platform account. The constraints are that receivers must complete onboarding or binding first, and split ratios and timing windows follow platform rules.

Licensed institution clearing: a licensed payment institution collects and distributes funds on instruction. It fits scenarios with many receivers, complex rules, and a need for cross-channel consistency, at higher cost and integration complexity.

Decision rule: few receivers, simple rules, mainly WeChat and Alipay means channel-side splitting; many receivers, cross-channel, complex rules means licensed institution clearing.

5. Designing the Unified Access Layer

Even with aggregate payment, build a unified abstraction in your own code, or future channel changes will ripple across the entire application. This layer must unify at least four things:

The critical design is separating internal order numbers from channel transaction numbers: internal numbers are generated by you and globally unique, while channel numbers are recorded only as attributes. Changing channels then leaves the order system untouched.

The other requirement is payment routing: when one order can complete through several channels, route by availability, cost and success rate. Routing policy must be configurable and grayscale-releasable, never hardcoded.

6. Three Traps in Unified Callbacks

Trap one: inconsistent payload formats. Notification structures, success response formats and retry policies all differ by channel, so the unified entry must verify and respond per channel rather than with a single code path.

Trap two: inconsistent amount units. WeChat Pay uses cents while Alipay uses yuan, and aggregate layers hide the difference further. Normalize to an integer minor unit such as cents to avoid floating point error.

Trap three: callback and query disagreeing. Some aggregate providers deliver callbacks with noticeable delay or drop them entirely. A scheduled query fallback is mandatory; never rely solely on callbacks.

7. Selection Criteria

• Self-operated business, single entity means direct integration, with the simplest fund relationships and the best rates.
• Platform business collecting for many merchants means the service provider model, compliant with funds reaching merchants directly.
• Fast multi-channel launch with limited engineering capacity means aggregate payment, but verify the provider's license and clearing path.
• Many receivers and complex rules means licensed institution clearing.

Whichever path you choose, confirm in both contract and implementation that the fund flow is user to merchant, not user to platform to merchant. The latter is second clearing.

8. Launch Checklist

The fund flow is diagrammed and confirmed free of second clearing; merchant onboarding materials match the business category; settlement accounts belong to the merchant; split settlement receivers have completed onboarding; the unified callback layer verifies per channel; amounts are stored as integer minor units; the scheduled query fallback is live; the reconciliation table is normalized and covers every channel.

For reconciliation after splitting, see the reconciliation and bill download handbook. For refunds and settlement, see the refund and settlement operations handbook. For an aggregate provider's positioning, see Ping++. For cross-border channel combinations, see the cross-border payment selection matrix. More options are collected under the Payment category.

Source: 16IDC original. Product capabilities, pricing and eligibility requirements follow pay.weixin.qq.com and related official documentation and contract terms.