Should a commerce mini program be first-party retail, a multi-merchant marketplace, or lead generation?
Conclusion: choose the commercial relationship before designing the storefront. First-party retail, a multi-merchant marketplace and lead generation differ in who sells, contracts, collects funds, invoices, fulfils and handles disputes. Accounts, orders, payment, settlement and support should reflect those facts. Calling a transaction flow an “information service” does not change what the business actually does.
Who this is for
This framework is for decision-makers planning a WeChat mini program or a China-facing web or app marketplace. The difficult choice is rarely the visual design. It is whether the operating company buys or controls the offer and sells to the customer, enables independent merchants to transact, or only introduces two parties that contract and pay elsewhere.
China's E-Commerce Law distinguishes platform operators, on-platform merchants and businesses selling through their own sites or other online services. Where an operator combines first-party and marketplace offers, it must clearly distinguish them. The product model should therefore match the contracts, offer ownership and fulfilment responsibility—not a convenient label in the interface.
Compare the three models
| Model | Customer relationship | Product and operating focus | Sensible starting point |
|---|---|---|---|
| First-party retail | The operating company normally sells, collects, invoices, fulfils and supports | Catalogue, purchasing or stock, unified orders, delivery, refunds and finance reconciliation | The company controls supply and wants one price, service and brand promise |
| Multi-merchant marketplace | Merchants independently offer goods or services while the platform provides the trading venue and rules | Merchant onboarding, stores, rules, split orders, payment and settlement, commission, disputes and exit | Independent sellers need to trade under ongoing platform governance |
| Lead generation or matching | The platform publishes opportunities or introduces parties; contract, payment and fulfilment occur through another agreed channel | Listing review, lead allocation, contact consent, service evidence and charging basis | Early value comes from matching demand and supply, without owning the transaction |
A supplier portal does not automatically make a business a marketplace. Suppliers may maintain product data while the operating company remains the buyer and seller. Conversely, a simple interface can still be a marketplace if multiple parties publish offers and independently transact. Legal classification and licensing depend on the actual activity and sector and should be confirmed by counsel.
Seven decisions management must make
Who sells to the customer?
Use a consistent legal entity across the offer, checkout, payment, contract, invoice and after-sales journey. A mixed first-party and third-party basket must identify each seller before purchase and explain split orders, delivery charges and support ownership.
Who controls the offer, price and availability?
First-party retail generally centralises price and availability promises. A marketplace must define which fields merchants control, which changes require review, who funds promotions and what triggers restriction. A lead service needs listing validity, evidence and contact-release rules. Access permissions cannot compensate for undecided commercial policy.
Where does the money go?
The collection path must match the seller and an eligible payment product. WeChat Pay's Platform Payment product supports merchant onboarding, combined or ordinary payments, frozen funds, release and revenue sharing for qualifying platform scenarios. Eligibility, required evidence and fee allocation remain subject to the declared operating scenario and WeChat Pay review. Do not collect every independent merchant's sales into a first-party merchant account and reconstruct settlement in a spreadsheet.
Who invoices and fulfils?
Record the seller, fulfiller, invoice issuer, shipping warehouse or service location on each order. One payment may cover several sub-orders, but each sub-order still needs its own revenue, refund, delivery and accountability trail. A lead service should retain evidence of lead acceptance and contact so its own service can be measured.
Who approves cancellation, refund and compensation?
First-party retail can use one support policy. A marketplace needs merchant response deadlines, platform intervention rules, funding sources for refunds and compensation, and allocation of delivery cost. A lead service should say whether it participates in downstream contractual disputes.
How are merchants admitted and removed?
The E-Commerce Law requires platform operators to verify and register specified merchant identity, address, contact and licence information and keep it current. China's Measures for the Supervision and Administration of Online Transactions also set retention requirements for merchant identity and transaction information. The product therefore needs evidence versions, review, expiry, change, suspension, exit and historical-order preservation—not merely an approval toggle.
How does the operator earn revenue?
Separate first-party margin, commission, technology fees, membership, advertising and lead fees. Define the charged party, recognition event, refund effect, invoice and reconciliation. Otherwise gross merchandise value, merchant proceeds and platform revenue become misleadingly mixed.
Scope the first release around one model
A first-party release usually needs catalogue and price, available stock, basket, order, payment and refund, delivery or redemption, invoice details, service and reconciliation. Suppliers can connect through purchasing or supplier collaboration without being turned into marketplace merchants.
A marketplace also needs merchant records and verification, store and catalogue authority, rule acceptance, orders split by merchant, payment and settlement states, commission, refunds, merchant statements, platform intervention, enforcement and exit. Sector licences, deposits, campaigns and ratings should be prioritised by demonstrated need.
A lead service should prioritise publication eligibility, listing expiry, category and location, review, privacy consent, allocation, contact evidence, reporting and the fee basis. Adding in-platform contracting, payment or centralised after-sales later is a change in operating model and deserves a fresh assessment.
Implementation and acceptance
Map three real transactions across customer, operator, merchant or supplier, payment provider, logistics and invoicing. Have business, finance and legal owners confirm the entity and settlement model. Validate payment-product eligibility, sector category, scenario and evidence before freezing scope. Complete one primary model first; if mixed operation is essential, model and label each branch separately. Test normal fulfilment, partial refund, merchant exit and a disputed order end to end.
- Every offer and order identifies its seller, fulfiller, collection arrangement and invoice issuer.
- First-party and third-party offers remain clearly distinguishable through purchase and support.
- Marketplace orders split correctly and payment, refund, commission, settlement and accounting balances reconcile.
- Merchant evidence, reviewer, version, expiry, changes and exit remain traceable.
- Refund, compensation, platform intervention and merchant timeout have explicit states and authority.
- Retries cannot duplicate collection, refund or settlement.
- A lead flow cannot silently become collection on behalf of merchants.
- Reporting separates gross transaction value, merchant proceeds, platform revenue, refunds and pending settlement.
Common mistakes
Collect centrally and settle merchants manually. The payment record no longer aligns with the seller and makes refunds and disputes difficult to attribute.
Call every third party a supplier. Supplying the operator and selling independently to consumers are different relationships with different contracts, money flows and software scope.
Treat terms as a substitute for operations. Rules become actionable only when linked to onboarding evidence, catalogue governance, transaction records, complaints and exit.
Build all three models in release one. Mixed operation multiplies offer ownership, basket splitting, service, payment and finance rules. One validated primary model is easier to control and accept.
Ongoing ownership
Review seller presentation, expiring merchant evidence, unsettled orders and refund differences monthly. Reassess rules, charges, access and exit quarterly. Before adding a sector, region, merchant type or payment product, determine whether it changes the seller, licence, settlement or support boundary; then treat it as either configuration or a governed change.
For the merchant evidence and review workflow behind a marketplace model, continue with How should a B2C platform design merchant onboarding review?.
Sources
- National People's Congress: E-Commerce Law of the People's Republic of China (promulgated 31 August 2018; accessed 11 September 2026)
- State Administration for Market Regulation: Measures for the Supervision and Administration of Online Transactions (accessed 11 September 2026)
- WeChat Pay: Platform Payment product overview (page updated 28 February 2026; accessed 11 September 2026)
- WeChat Pay: Platform Payment onboarding preparation (page updated 19 May 2026; accessed 11 September 2026)
This article is a product-scope framework, not legal, tax or payment advice. Legal, finance and payment owners should confirm current requirements for the actual sector, region and commercial arrangements.