A customer in Shenzhen asks to "just scan" — and your checkout says no
It usually shows up as a support ticket rather than a strategy problem. A prospect likes the product, gets to the payment page, and asks whether they can pay with Alipay or WeChat Pay. Your stack accepts Visa, Mastercard and maybe a local European method. The deal stalls, and someone in sales asks why the biggest e-commerce market in the world is not on the list.
Adding China is not one integration. It is a choice between three different legal and settlement structures, each with its own onboarding queue, its own currency, and its own idea of what a refund is. Most teams pick the first provider that says yes and discover the difference three months later, when finance cannot reconcile a settlement batch.
This guide is the operational version: what you are actually choosing, what documents decide your timeline, where the money lands, and what breaks in the first month.
Three ways in, and they are not interchangeable
Every route ends with a Chinese consumer scanning a QR code. What differs is who holds the merchant relationship, what currency you get paid in, and who owns the compliance work.
| Route | Who holds the merchant account | Typical onboarding | Settlement currency | Best for |
|---|---|---|---|---|
| Cross-border wallet acquiring through an international PSP that supports Alipay+ and WeChat Pay | The PSP, under its own licences | 2–6 weeks, mostly KYC and website review | USD, EUR, HKD and other majors — rarely CNY | Foreign entities selling digital goods or services into China with no local presence |
| Domestic acquiring through a Chinese licensed acquirer | You, via a Chinese entity | 6–12 weeks, includes local entity, ICP filing and category review | CNY, onshore | Companies with a mainland entity, local staff and RMB costs |
| Hong Kong or Singapore entity acquiring cross-border, settling offshore | Your offshore entity | 4–10 weeks | HKD, USD, SGD | Groups that want RMB exposure without a mainland subsidiary |
There is no "cheapest" column because the cost is not only the rate. A domestic route gives you CNY pricing and lower decline rates on local traffic, then charges you in entity maintenance, tax registration and a compliance function you did not have before. A cross-border PSP route is fast, but you inherit its category restrictions and its settlement calendar, and you will not be able to reprice in RMB.
One more distinction that trips people up: Alipay+ is a connector that reaches dozens of Asian wallets, not a synonym for Alipay. Being live on Alipay+ does not automatically mean you accept WeChat Pay, and it certainly does not mean you can settle in CNY.
The documents that decide your timeline
Underwriting, not engineering, is what makes China take a quarter instead of a fortnight. In practice the queue moves when these arrive complete and consistent:
- Corporate identity — certificate of incorporation, and for most providers a shareholder register going up to 25% beneficial ownership, with passport copies that match the register exactly. Mismatched name spellings are the single most common cause of a two-week delay.
- Business description that matches your website — the underwriter will read your site. If your homepage says "digital services" and your application says "SaaS subscription", expect questions.
- Category and MCC selection — wallets apply their own prohibited and restricted lists. Getting this wrong does not fail the application outright; it fails at the first transaction, which is worse.
- Customer journey evidence — screenshots of checkout, pricing page, refund policy and terms. Some providers ask for a short screen recording of a test purchase.
- Bank account proof in the name of the contracting entity. Third-party or payment-facilitator accounts are usually rejected.
- For the domestic route only — Chinese business licence, ICP filing for the domain, and local tax registration.
Send the whole set once. Providers that accept partial applications still stop the clock at the missing document, and the queue position does not hold.
Where the money actually goes
A wallet payment is authorized in CNY, captured by the wallet, and settled to you days later in a different currency. Four separate costs sit inside that journey, and vendors tend to quote only the first.
| Cost component | What it is | Where teams get surprised |
|---|---|---|
| Acquiring fee | Percentage of transaction value, quoted by the PSP | Quoted for card traffic, then repriced when wallet volume becomes material |
| FX spread | Difference between the interbank rate and the rate applied to your settlement | Rarely shown as a line item; it is embedded in the rate you receive |
| Settlement and payout fees | Per-batch or per-transfer charges | Batching policy is yours to set — daily settlement on low volume can cost more than it saves |
| Refund and dispute handling | Fees on reversed transactions, sometimes with a floor | Refunds can cost more than the original sale at low ticket sizes |
Ask for one worked example in writing: a $100 transaction, refunded once, settled to a USD account. Any provider that cannot produce that number in a spreadsheet has not thought about your finance team.
Refunds, disputes, and the chargeback gap
Wallets do not run card chargebacks. There is no 120-day window and no network arbitration, which sounds like a risk win until you realise it means something else: the dispute process is a conversation, and the wallet's user protection rules, not a card network's, decide the outcome.
Two operational consequences matter.
First, refunds are API calls against the original transaction, bounded by a window that varies by wallet and is often shorter than a card scheme's. Subscription businesses that allow refunds on request should confirm that window before promising anything to customers.
Second, "no chargebacks" does not mean "no losses". Fraudulent wallet accounts, stolen-device payments and consumer complaints escalate to the wallet, and the remedy is usually a debit or a held settlement rather than a formal case. Your fraud rules still need to run on wallet traffic — velocity checks and device signals do not become optional just because the rail is different.
Four things that will break in month one
| Symptom | Usual cause | Fix |
|---|---|---|
| Orders stuck as pending, then expire | QR code timeout — the user opened the wallet after the code had already lapsed | Poll order status instead of assuming success, and regenerate the code client-side on expiry |
| Payment succeeds in the wallet but your order stays unpaid | Async notification lost, blocked by a firewall, or not idempotent | Treat the callback as an optimization, not the source of truth: reconcile by querying the order and de-duplicate on the wallet transaction ID |
| Partial refunds fail with a signature or parameter error | Amount fields in the wrong unit, or refunds issued against the authorization instead of the capture | Send amounts in minor units exactly as the docs specify, and refund against the settled transaction |
| Higher declines for one segment than another | Per-user limits or category controls applied by the wallet, not by you | Model limits into the checkout message instead of showing a generic failure |
Reconciliation: the fields to insist on
China wallet settlements arrive as batches, and a batch is not a list of your orders. Before you sign, confirm that the report and the API expose the same identifiers, and that you can join them without heuristics:
- Your own order reference, returned on every callback and in the settlement file
- The wallet's transaction ID, stored immutably — it is the only reliable de-duplication key
- Gross amount, fee amount and net amount as separate fields
- The FX rate applied and the rate timestamp
- Settlement batch ID and value date
If the rate timestamp is missing, month-end close becomes an estimate, and an estimate is what auditors ask about.
A 30-day launch sequence
- Days 1–3: decide the route by entity, not by rate. Confirm which legal entity contracts and which currency it wants to be paid in.
- Days 3–7: shortlist two providers that support both Alipay and WeChat Pay for your category, and request the worked $100 example plus a sample settlement file.
- Days 7–14: submit a complete KYC pack to both. Applications are often free; a second option costs nothing but a week of patience.
- Days 10–20: build against sandbox. Implement order-status polling, idempotent callbacks and refunds before touching production keys.
- Days 20–25: run a live test with a real low-value transaction from a real wallet, then refund it and reconcile the batch.
- Days 25–30: switch on for one market or one product line, watch decline reasons daily for a week, then widen.
The teams that regret this project are rarely the ones that picked the second-best provider. They are the ones that went live without polling, discovered the gap during a sale, and spent the next month rebuilding trust with their own finance team.
FAQ
Can a foreign company accept Alipay and WeChat Pay without a Chinese entity?
Yes — through a PSP that holds the acquiring relationship and settles to you offshore. You will be paid in a major currency rather than CNY, and your category must pass the wallet's own review.
Do wallet payments support recurring billing?
Some do, through a merchant-initiated agreement model rather than card-on-file. Coverage differs by wallet and by market, so confirm it for the specific wallet before designing a subscription flow around it.
Is a Chinese payment gateway required if we already accept UnionPay cards?
No. Card acceptance through UnionPay and wallet acceptance through Alipay or WeChat Pay are separate integrations with separate onboarding. Many merchants need both, and they rarely arrive from the same provider.