China Payments: The Foreign Operator's Guide

China's payment market spans wallet, card and bank-transfer services with different access conditions. This guide focuses on the provider agreement and payment records a foreign merchant needs, and on the separate question of operating regulated infrastructure.

This guide covers how that system actually works — the duopoly mechanics, the clearing architecture, the realistic paths for foreign operators, and what CIPS means for B2B CNY settlement.

The Duopoly: How Alipay and WeChat Pay Work

Alipay (Ant Group) and WeChat Pay (Tencent) together account for over 90% of China's mobile payment market — a duopoly with no close parallel in any other major economy (OECD, Competition in Mobile Payment Services, 2025). Alipay is the larger of the two by most third-party estimates, though the People's Bank of China does not publish a vendor-level market-share breakdown, so the precise split should be treated as a reported estimate rather than an official figure.

Both operate as staged wallets: users pre-load RMB from a linked bank account, and transactions debit the wallet balance. This is distinct from a card-on-file model — the wallet balance mechanism is part of why domestic MDR is structurally lower in China than in most card-dominated markets.

Non-bank clearing, bank settlement and the merchant-facing API have different roles. A provider should identify the permitted product and relevant clearing/settlement route; a universal statement that every non-bank payment follows one path would hide those distinctions.

Under a PBOC draft rule published July 2025, Alipay, Tenpay (WeChat Pay's operating entity), and NetsUnion are being placed under the central bank's direct AML supervision — expanding the directly-supervised entity list from 23 to 27 firms (Caixin Global, July 2025). As a draft measure, the final scope may shift before it takes effect, but the direction is unmistakable: tighter central-bank oversight of the largest payment platforms.

In December 2024, Ant Group restructured Alipay into separate Digital Payment and Alipay Business units — a signal of MDR compression and a pivot toward merchant SaaS and credit services rather than per-transaction fee income. The structural low-cost model that built the duopoly is now a ceiling on growth rather than a competitive weapon.

MDR Rates (Approximate)

Fees: obtain a current merchant quote for the product, channel, currency and route. A reported fee range or aggregate payment statistic is not a universal acceptance price. Compare total charges, refunds and payout on the same transaction profile.

How Foreign Operators Accept Alipay and WeChat Pay

For most foreign entities, there is no realistic direct merchant path. Foreign merchants accept Alipay and WeChat Pay through licensed PSPs and gateways that hold the necessary relationships and infrastructure — not via a direct agreement with Ant Group or Tencent.

Confirmed intermediaries with documented Alipay and WeChat Pay acceptance:

• Adyen — documented support for Alipay, WeChat Pay, and UnionPay across online and POS channels
• Antom / 2C2P — 2C2P is part of Ant International's Antom platform; the Alipay+ / Antom channel is the native route for Ant-ecosystem acceptance globally
• AsiaPay — Hong Kong-headquartered gateway with 17 APAC offices; supports Alipay, WeChat Pay, and UnionPay QR
• Stripe — supports Alipay and WeChat Pay for eligible APAC entities; confirm regional availability for your specific merchant-entity structure

On PingPong: PingPong operates as a cross-border collection, payout, and FX provider for Chinese e-commerce sellers on platforms like Amazon and Tmall Global — not as a checkout-acquiring intermediary for foreign merchants wanting to accept Alipay/WeChat from Chinese consumers. The use cases are different; do not conflate them.

What to expect in practice: request an onboarding checklist and the product's current charges, refund window and payout schedule. A consumer wallet or a global acceptance logo does not establish that your entity qualifies or that setup has a guaranteed duration.

Foreign visitor transaction limits (PBOC, March 2024): The single-transaction cap for foreign-card-linked Alipay/WeChat use was raised from US$1,000 to US$5,000; the annual cumulative cap from US$10,000 to US$50,000. Relevant for inbound Chinese tourism acceptance and for testing foreign-linked accounts.

UnionPay: The Third Rail

UnionPay is China's domestic card network — the world's largest by cards issued. All POS terminals in mainland China are legally required to support UnionPay; Visa and Mastercard have very limited domestic acceptance, operating primarily for inbound foreign cardholders. For online merchants targeting Chinese consumers via card payment, UnionPay is the relevant network.

UnionPay International (UPIC) handles foreign-issued UnionPay cards used outside mainland China — a separate entity, relevant for operators serving Chinese travellers or overseas Chinese communities. If you are a foreign merchant outside China looking to capture Chinese tourist spend, UPIC acceptance via your existing acquirer (Adyen, Worldpay, and others have UPIC coverage) is the mechanism.

For foreign operators wanting UnionPay acceptance inside China: route through the same intermediaries as Alipay/WeChat Pay, or via a Chinese acquiring bank — the latter typically requires a PRC entity.

PBOC Licensing: Institution and Merchant Access

The non-bank payment regulation effective 1 May 2024 distinguishes stored-value account operation and payment-transaction processing. Its baseline paid-in registered capital is RMB 100 million, with higher requirements possible; consult current implementing rules for the business scope.

An institution itself providing payment services and a merchant buying acceptance services have different obligations. Confirm the legal entity, authorised activities, systems/data requirements and cross-border permissions instead of assuming that a provider relationship transfers a licence or that foreign applications have a standard duration.

Domestic processing, system location and personal-information handling have distinct scopes in the regulation. Map the actual transaction and data flows with the provider and counsel before selecting an implementation.

CIPS for B2B CNY Settlement

CIPS (Cross-Border Interbank Payment System) is wholesale infrastructure for cross-border RMB payments and settlement, distinct from the Swift messaging network. It is not a consumer payment method — it is interbank infrastructure for CNY flows between financial institutions across borders.

Scale as of June 2026 (CIPS Participants Announcement No. 118):

• 210 direct participants
• 1,619 indirect participants
• 130 countries and regions (CIPS business more broadly covers 5,200+ banking institutions across 191 countries and regions)

Participant counts move roughly monthly to quarterly as CIPS admits new institutions — re-check the current CIPS Participants Announcement before citing a specific figure.

The June 2025 expansion added several new direct participants including Standard Bank (South Africa), African Export-Import Bank, First Abu Dhabi Bank, United Overseas Bank (Singapore/Thailand), and Bangkok Bank (Thailand). New CIPS operating rules took effect February 2026.

How CIPS works for operators: CIPS provides cross-border RMB payment and settlement services. Merchants normally work through banks; participation does not mean every eligible RMB transfer necessarily uses CIPS. Ask the bank to identify the actual route, beneficiary requirements and completion evidence.

Compared with Swift: messaging and settlement are separate functions. CIPS and Swift-related services can coexist in a bank's workflow. Neither membership nor a message format establishes that one route is always faster or available for a particular merchant.

For operators, CIPS is relevant in three B2B scenarios: a foreign SaaS company billing a Chinese subsidiary in RMB; an exporter receiving CNY payment from a Chinese buyer; a treasury team managing RMB cross-border payables. It is not a consumer checkout infrastructure.

CNAPS, NetsUnion, and Payment Connect

CNAPS (China National Advanced Payment System) is the PBOC interbank backbone, invisible to most operators at the API layer. It runs two main rails: HVPS (High Value Payment System, RTGS for large-value settlement) and IBPS (Internet Banking Payment System, near-real-time retail). Banks use CNAPS to settle with each other; non-bank PSP transactions clear through NetsUnion and then settle against the banking system via CNAPS.

NetsUnion is part of China's non-bank clearing infrastructure. The merchant-facing wallet service, clearing arrangement and bank settlement are different roles. Ask the provider for the applicable route; do not infer one universal flow or full visibility into every payment from the clearing mandate.

Payment Connect (launched 22 June 2025): A joint PBOC and Hong Kong Monetary Authority initiative linking mainland China's IBPS with Hong Kong's Faster Payment System (FPS) for real-time, cross-boundary retail payments in both RMB and HKD (HKMA press release, 20 June 2025). Six institutions per side participated at launch. This is the first meaningful mainland–HK real-time corridor for small-value retail flows — relevant for operators running HK-entity structures moving funds between Hong Kong and the mainland.

There is no open retail real-time rail in China equivalent to India's UPI or Brazil's Pix. Both UPI and Pix are open to third-party app builders via public APIs. China's real-time infrastructure is exclusively bank/PSP-licensed; no developer-open access layer exists.

e-CNY: Large Scale, Limited Practical Relevance for Foreign Operators

The e-CNY (digital yuan) is PBOC's central bank digital currency and — by cumulative transaction value — the most operationally advanced retail CBDC in the world. Official PBOC data through November 2025 shows approximately 3.48 billion cumulative transactions, a cumulative value of CNY 16.7 trillion, and approximately 225 million personal wallets opened (PBOC, via gov.cn). A framework change effective January 2026 added interest-bearing features, moving e-CNY toward deposit-money characteristics.

For foreign operators, the e-CNY has limited practical relevance today. There is no direct merchant-acceptance path for foreign entities; only licensed banks, major payment platforms, and PBOC-approved operators act as e-CNY intermediaries. Cross-border e-CNY pilots — in Hong Kong, Thailand, and the UAE — are wholesale and B2B, not consumer-facing channels available to foreign merchants. The January 2026 framework change expands domestic utility but does not open a foreign-merchant acceptance route.

This trajectory may shift over a longer horizon. But for 2026 planning purposes, e-CNY is not an acceptance channel foreign operators should build toward.

After Go-Live: The Wallet Operations Nobody Scopes

Everything above is about access — getting to the point where a Chinese consumer can pay you. The part foreign operators consistently under-scope is what happens afterwards. Wallet acceptance is not card acceptance with a different logo on the checkout page, and the operational differences surface in refunds, disputes, reconciliation, and the handling of transactions whose status you do not know.

The mechanics below are drawn from Antom's own merchant documentation — Ant International's acquiring platform, and the native route into the Ant ecosystem named earlier in this guide. They are specific to acquiring through Antom. Other intermediaries expose different APIs and different contractual terms, so treat this as the shape of the problem rather than a universal specification, and confirm the equivalents with whichever provider you actually integrate.

Refunds expire

The single most consequential difference from card acquiring: an Antom wallet refund has a deadline. Antom's refund API returns the error REFUND_WINDOW_EXCEED, described as "The refund date exceeds the refundable period that is agreed in the contract." Its online refund documentation is blunt about the consequence: "If the refund request is out of the refund window determined in the contract, the refund request will be declined."

That refundable period is a contract term, not a scheme-wide constant — which makes it a commercial negotiation item to raise before signing, not something to discover when a support agent cannot process a return. Any merchant running long return windows, extended warranties, subscription trials, deferred fulfilment, or seasonal goods should compare its own returns policy against the contracted refund window and find out where the gap sits. A 90-day returns promise on top of a shorter refund window is a liability the finance team absorbs manually, one case at a time.

Within the window, the mechanics are more generous than the deadline suggests. Refunds "can be full or partial", and a transaction "can have multiple refunds as long as the total refund amount is less than or equal to the original transaction amount" — so partial-return and multi-item-return flows work normally.

Refund idempotency is explicit and worth using properly. The merchant "uses the refundRequestId field for idempotency control", and for requests sharing a refundRequestId that reach a final status, "the same result is to be returned for the request." The practical rule: generate one stable refundRequestId per refund intent and reuse it on every retry. Do not mint a new one when a call times out — that is how a single customer return becomes two refunds.

Refunds may also settle asynchronously. Where the result is asynchronous, the documentation says the merchant can "call the inquiryRefund interface to query the refund result" rather than treating the initial response as final.

Disputes: what the documentation actually scopes

The common planning assumption is that because there is no Visa or Mastercard behind an Alipay transaction, there is no dispute exposure. The documentation neither confirms that assumption nor refutes it — and the detail of where it lands is more useful than either slogan.

Antom distinguishes four dispute types: retrieval request, chargeback, rapid dispute resolution (RDR), and compliance request. On chargeback scope it says: "Chargebacks apply to most payment methods, including local cards, international cards, and some non-card payment methods (e.g., QRPH, BANCOMAT Pay, BLIK)." The three non-card methods it names are the Philippine, Italian and Polish rails — none of them Chinese — and the page does not say the list is exhaustive.

The retrieval-request process is scoped in the other direction: "non-A+ wallet payment methods may be subject to the retrieval request process." That matters here because the same page lists Alipay (China) first among its A+ wallet payment methods, alongside AlipayHK, GCash, DANA, Kakao Pay, Touch'n Go, TrueMoney and others. On Antom's own scoping, Alipay sits outside the retrieval-request process.

So read honestly, this documentation does not place Alipay in either the named chargeback-exposed set or the retrieval-request process. That is an absence of confirmation, not a grant of immunity — the page says nothing that positively rules a dispute out, and the per-method mapping is a contractual question for your provider rather than something to infer from a public page. The useful conclusion for planning is narrower than "wallets have chargebacks" and more useful than "wallets are safe": dispute exposure on this platform is method-specific and contract-defined, and China's dominant wallet is not among the methods the public documentation flags.

Where a chargeback does arise, it runs on a clock the merchant does not control. The deadline arrives in a defenseDueTime parameter, and Antom "will send a warning notification via the notifyDispute API 24 hours before the processing time specified by the defenseDueTime parameter." Miss it and the outcome is automatic: "if you fail to handle the chargeback within the processing time specified by the defenseDueTime parameter, Antom will assume you have accepted the chargeback."

The mechanism that should actually worry a China-facing operator is the fourth one, and it is not a chargeback at all. For a compliance request, failing to respond means "your merchant account will be frozen until you successfully provide accurate information or documents." That is an availability risk rather than a revenue-leakage risk, it is not scoped away from any wallet tier, and it belongs on a different internal escalation path from ordinary dispute losses — a chargeback write-off is a finance problem; a frozen merchant account is an incident.

The staffing consequence is the same either way: a 24-hour warning is not a workflow. If these notifications land on an unmonitored webhook endpoint or in a shared inbox nobody owns overnight, the default outcome is loss by silence.

Reconciliation: one join key, one truncation guard

Antom's settlement details report "will be generated by 11:59 PM on the day following the settlement day," retrievable "through the SFTP server or Antom Dashboard." It "consists of three parts: header information, transaction details, and the end-of-file <END> that appears in the last line of the report."

Two things there are operationally load-bearing.

First, the join key is paymentId. The report's transactionId is "identical to paymentId" for PAYMENT, AUTHORIZATION, CANCEL, CAPTURE, REFUND, DISPUTE, DISPUTE_REVERSAL, REFUND_REVERSAL, PAYMENT_REVERSAL, RAPID_DISPUTE_RESOLUTION and CDRN rows alike. Store paymentId against your own order record at authorisation time. If you persist only your internal reference, every downstream row — refunds and disputes included — has to be matched back the hard way.

Second, the <END> marker is a completeness check, not decoration. A settlement file fetched over SFTP mid-write, or truncated by a failed transfer, is indistinguishable from a short settlement day unless you assert that the last line is <END> before ingesting it. Reconciliation that silently books a partial file is worse than reconciliation that fails loudly.

FX is itemised, which makes it auditable

The settlement report carries the conversion explicitly: quoteCurrencyPair (where "the two currencies are separated by a slash... such as EUR/USD"), quotePrice for the rate applied, convertedTransactionAmountValue, and fxFeeAmountValue for the foreign-exchange processing fee. settlementAmountValue is the "net settlement amount after deduction of fees for orders converted to settlement currency," expressed in settlementCurrency.

Because the rate and the FX fee arrive as separate fields rather than baked into a single net figure, the effective all-in conversion cost is measurable per transaction — a file you already receive contains a cost lever most acceptance stacks never surface. Computing it is worth doing before renegotiating anything.

The status value that causes double-fulfilment

inquiryPayment returns five statuses, and one of them is a trap. SUCCESS, FAIL, PROCESSING and CANCELLED behave as their names suggest. PENDING does not: the documentation defines it as "the payment is completed. Wait for the final payment result."

A status literally named pending that means completed, result outstanding is exactly the semantic mismatch that produces goods shipped against payments that later fail, or a second charge raised against a customer who already paid. Never map PENDING onto the same branch as PROCESSING, and decide deliberately — as a risk position, not an implementation accident — whether it is sufficient to release fulfilment.

When a call times out or returns an unknown exception, the documented recovery is to inquire rather than retry blindly: "if the pay API call returns unknown exceptions or timeouts, use paymentRequestId to inquire about the payment result." The cited page publishes no recommended polling interval for either state. For PROCESSING it says only to "continue querying or confirm the final status by querying again after the order closure time"; for PENDING, separately, to "continue querying or waiting for asynchronous notifications." That interval is yours to design, and designing it badly is how operators generate either stale orders or self-inflicted rate limiting.

What This Means for Operators

Accepting payments from Chinese consumers

• Route through a licensed intermediary — Adyen, Antom/2C2P, AsiaPay, or Stripe — for Alipay and WeChat Pay acceptance. No direct merchant agreement path exists for most foreign entities.
• Add UnionPay International coverage if your customers include Chinese travellers or diaspora outside mainland China.
• Budget for platform MDR plus intermediary markup. KYC documentation takes time; start the process early.
• Do not plan around e-CNY acceptance — no direct foreign-merchant path exists today.

For PSPs building China infrastructure

Separate using a payment service from operating a payment institution. Under the PBOC non-bank payment regulation, an institution must operate within its approved scope and may not rent, lend or otherwise unlawfully transfer its payment licence. A commercial partnership does not confer the partner's authorisation.

For a proposed service, identify the contracting entity, the activities each party performs and the permissions those activities require. Merchant acceptance through a provider is a different arrangement from acquiring or operating a licensed payment institution; confirm the applicable approvals before choosing either route.

For companies with B2B CNY flows

• A CNY bank account at a Chinese bank typically requires a PRC entity. Cross-border CNY transfers use CIPS infrastructure via your bank — no direct CIPS membership is needed.
• Tighten transaction documentation. PBOC and SAFE KYC and record-retention requirements continued to tighten through 2025–2026, and AML and transaction-monitoring obligations on payment institutions and their banking partners are rising.
• Plan for currency controls. CNY is not freely convertible, and cross-border payment and remittance oversight remains strict. Build in lead time for repatriation of material RMB balances and budget for SAFE documentation requirements.

Regulatory watch

• PBOC's July 2025 draft AML rule extending direct supervision to Alipay, Tenpay, and NetsUnion.
• e-CNY framework evolution post-January 2026.
• The ongoing expansion of Payment Connect for mainland–HK real-time flows.

None of these fundamentally change the access constraints for foreign operators in the near term, but they raise the compliance bar for intermediaries — which flows downstream to KYC requirements and onboarding timelines.