WeChat Pay and Alipay integration — entity before SDKs
Mainland China consumers pay with WeChat Pay and Alipay first. Domestic merchant onboarding expects a China entity or a partner that holds merchant accounts — and App, H5, and Mini Program checkout are separate products on each rail.
WeChat Pay Alipay China is a dual-rail decision — lock china payment rails before you schedule SDKs. WeChat Pay (微信支付) and Alipay (支付宝) are the dual consumer defaults. WeChat Pay and Alipay integration is an entity, merchant, and surface Decision Map (App vs H5 vs Mini Program), not a single console tutorial. Most product teams need a Mainland China entity or landing-partner merchant path before production keys are real work.
What WeChat Pay and Alipay mean as China payment rails
Hard names your Mainland China checkout program will use:
- WeChat Pay (微信支付) — Tencent’s consumer wallet rail, documented for merchants on WeChat Pay. In-WeChat journeys (Official Account / Mini Program) and APP / H5 products each need merchant enablement plus WeChat Open Platform AppID binding aligned to the same entity story.
- Alipay (支付宝) — Ant Group’s consumer wallet rail, with open capabilities on Alipay open docs. Separate open-platform application, merchant onboarding, and product enablement from WeChat Pay — do not treat one approval as covering both.
- Dual-rail expectation — Ordinary Mainland China users pay with WeChat Pay and Alipay first. Planning to accept WeChat Pay Alipay on only one rail is a conversion and support decision, not “we finished China payments.”
- Surface fork — App, H5 / mobile web, and Mini Program are different products and bindings on each rail. Shipping a native App SDK does not unlock H5 or Mini Program checkout automatically.
- Entity / partner merchant path — Direct domestic merchant onboarding expects a Chinese business organizing path (entity or contracted partner that holds merchant accounts). Overseas-only Stripe / PayPal / card stacks are not a substitute for these rails.
- Sibling deep-dives — This Guide is the combined rails map. For WeChat Pay–only App merchant and entity depth, see WeChat Pay apps China; Alipay–only App depth: Alipay for apps; for login + wallet sequencing beside Apple peers, see App login and payments in China.
- Common myth — “Add both SDKs after global launch.” Without entity, merchant, and surface decisions, SDKs are demos — not a fundable China checkout plan.
Vocabulary first. Next: what must exist before dual-rail tickets are real work.
What must exist before dual-rail merchant work
Missing any of these stops your product team before WeChat Pay or Alipay production APIs — not after the global payments backlog is already frozen.
| Precondition | Why your process stalls |
|---|---|
| Accept WeChat Pay Alipay as the dual baseline — both rails named for consumer B2C | One-rail checkout reopens conversion debates mid-build; boards never fund settlement ops |
| Mainland China entity or China landing partner for merchant accounts | Domestic merchant onboarding and open-platform verification need a China organizing path |
| Surface set locked — App, H5, Mini Program, offline QR (as relevant) | Wrong product apply → keys that cannot invoke the journey reviewers and users hit |
| SKU classification — digital goods vs physical / services; iOS vs Android | Wallet rails and Apple IAP forks collide when digital catalog items are mislabeled |
| Open-platform ownership — who holds WeChat AppIDs and Alipay apps, who binds merchant IDs | Engineering finishes SDKs while legal still has no applicant |
| Settlement + refund ops owner — who settles funds, who refunds, who answers disputes | Live launch fails when finance has no China merchant console access |
Chinese-language merchant consoles, legal-person verification, and package / domain binding sit outside a Stripe dashboard checklist. Broader login context: login and payments for apps.
WeChat Pay and Alipay integration decisions
Use this as a gate map for china payment rails. Stages are decisions — not SDK click-paths.
| Stage | Decision / outcome |
|---|---|
| 1. Confirm money surfaces | Which journeys must charge in Mainland China (App, H5, Mini Program, offline) |
| 2. Lock dual-rail policy | Accept WeChat Pay and Alipay as the consumer default pair — document any one-rail exception |
| 3. Choose organizing path | Chinese entity or partner that can hold WeChat Pay and Alipay merchant accounts |
| 4. Bind open platforms | WeChat Open Platform AppID(s) and Alipay open-platform app(s) matched to merchant entity |
| 5. Enable products per surface | APP / H5 / Mini Program (and related) products on each rail — separately |
| 6. Align store and privacy evidence | Screenshots and questionnaires match the China pay journey; PIPL-aware payment data handling |
| 7. Operate | Refunds, key rotation, reconciliation, dispute handling — live ops on both rails |
iOS digital goods still need Apple IAP classification beside wallet rails — do not collapse that fork into “WeChat Pay Alipay China done.” Detail: login and payments Guide.
Why skipping entity or surface forks blocks checkout
No Mainland China entity / partner → no durable merchant keys. WeChat Pay and Alipay domestic onboarding does not treat a foreign Stripe account as the China merchant path.
WeChat Pay without Open Platform bind → App / Mini Program invoke fails. Merchant ID and AppID must align; screenshots of a sandbox do not replace binding.
Alipay treated as “same as WeChat” → second console still empty. Separate open-platform app, merchant contract, and product enablement — WeChat Pay progress does not auto-enable Alipay.
App SDK only → H5 / Mini Program still dark. Surface products are separate gates on china payment rails; users who pay in-browser or in-WeChat never hit your native SDK.
Dual SDKs without settlement ops → launch without refunds. Finance cannot reconcile or refund when merchant ownership is unclear — stores and users escalate.
Global card-first checkout → empty Mainland China UX. Ordinary users expect to accept WeChat Pay Alipay first; cards are not the default consumer path.
Where dual-rail payment programs stall
- Treating WeChat Pay and Alipay integration as one backlog ticket — two merchant stacks, two open platforms, multiple surface products.
- Starting with SDK samples before entity and surface decisions — the stall is usually applicant path and product enablement, not API syntax.
- Promising “both wallets in two weeks” without naming who holds merchant accounts — diligence settlement, refund, and reject handling before dates go on a board slide.
- Ignoring Mini Program / H5 when the growth plan lives inside WeChat or Alipay — App-only wiring leaves the highest-intent journeys unpaid.
- Filing and store packages that show wallet UI the China binary cannot complete — the same failure mode as soft-launching without publish-path gates.
- Proving an H5 checkout only from outside Mainland China — a browser checkout page is a web surface like any other, so every host it loads needs the same Mainland China test evidence as the payment call itself; captcha and form dependencies are the usual example (Captcha and forms in China).
- Assuming sibling single-rail deep-dives replace this map — use this combined Decision Map first; planned WeChat Pay–only and Alipay–only Guides add depth later without changing the dual-rail floor.
When you need a China landing partner for payment rails
Most product teams exploring Mainland China entry need a China landing partner to turn WeChat Pay and Alipay into an executable dual-rail sequence — entity or merchant path, open-platform binding, surface product enablement, settlement and refund ownership, and Mainland China test evidence — not a longer SDK reading list. Your team still owns SKUs and the surface set; the partner path makes china payment rails workable when merchant accounts are not already in-house.
What we can offer?
Accepting WeChat Pay and Alipay in Mainland China is a dual-rail entity, merchant, and surface map — not one overseas wallet replacement. Chinaready helps your product team see which payment-rail gates block the China launch and run them beside login, filing, and distribution:
- China Readiness Assessment — Inventory WeChat Pay / Alipay dual-rail gaps, entity or partner merchant path, and App vs H5 vs Mini Program surfaces so the board funds the right sequence beside app filing.
- China Access Acceleration — Keep Mainland China review and payment test paths reachable so merchant evidence matches the journey users actually hit.
- China Product Hosting — Place China-critical payment-adjacent stacks where Mainland China reachability, callback reliability, and launch evidence describe one coherent path.
- Mobile App Distribution — Align store packages and checkout proof so distribution screenshots and live WeChat Pay / Alipay journeys do not diverge after listing.
Contact us when you need a dual-rail WeChat Pay and Alipay integration map for the Mainland China checkout you plan to fund.
Frequently asked questions
Do we need both WeChat Pay and Alipay to accept payments in Mainland China?
Yes for most consumer B2C apps. WeChat Pay and Alipay are the default China payment rails for ordinary users, so plan to accept both. One-rail-only checkout is a product choice with conversion risk, not a compliance shortcut.
Can an overseas company open WeChat Pay or Alipay merchant accounts directly?
Usually not directly. Domestic merchant onboarding expects a Mainland China business entity, or a contracted partner that already holds merchant rails. Global card or wallet SDKs do not replace those rails for ordinary Mainland China users. See WeChat Pay merchant docs and Alipay open docs for the current applicant paths.
What has to be locked before WeChat Pay and Alipay SDK work starts?
The organizing path. Before production keys are real work, lock the dual-rail policy, a Mainland China entity or landing partner that can hold merchant accounts, the surface set of App, H5, Mini Program and offline QR as relevant, SKU classification for digital versus physical goods, who holds the WeChat AppIDs and Alipay apps, and who owns settlement, refunds, and disputes.
What is the difference between App, H5, and Mini Program payment products?
Each surface is a separate product and binding path — App SDKs, H5 / browser payment, and Mini Program checkout do not share one “toggle.” WeChat Pay and Alipay each require the matching open-platform app, domain or package binding, and merchant product enablement for the surface you ship.
How does this Guide relate to login and Apple IAP?
This Decision Map is the combined WeChat Pay / Alipay merchant and surface fork. App login and broader checkout sequencing (including iOS peers) live in the login and payments Guide. Digital goods on Apple App Store China still need Apple IAP classification beside wallet rails.
Can product teams finish WeChat Pay and Alipay integration without Mainland China ops?
Usually no. Entity or partner merchant path, Chinese-language consoles, AppID / open-platform binding, settlement and refund ownership, and live test evidence from Mainland China sit outside a global payments backlog.
