App login and payments in China — try WeChat or Alipay first
For Mainland China apps, try WeChat and Alipay first for login and checkout — the most mature consumer rails — then phone or other methods; on iOS add Sign in with Apple and Apple IAP as peer options.
For Mainland China apps, try WeChat and Alipay first for login and checkout — then other methods. They are the most mature and popular consumer rails for Android apps. Keep phone SMS as a strong second login path. On iOS, add Sign in with Apple and Apple In-App Purchase as peer options beside WeChat / Alipay. Lock a Chinese entity or partner path for merchant rails before you ship global auth or card SDKs.
Mainland China App use login and payment rails mean
Hard names your China app program will use:
- WeChat login + WeChat Pay / Alipay — The first choice for most Mainland China Android B2C apps. Consumers already trust these rails; open-platform and merchant docs live on WeChat Open Platform, WeChat Pay, and Alipay open docs. Direct merchant onboarding expects a Chinese business entity or a partner that holds those accounts.
- Phone + SMS login — The universal second path; pairs cleanly with store and real-name expectations when WeChat alone is not enough.
- Sign in with Apple + Apple IAP (iOS peers) — On the Apple App Store China territory, add Apple’s native login and Apple In-App Purchase / StoreKit as peer options beside WeChat / Alipay — not a delayed afterthought. Digital goods and subscriptions on iOS still need Apple IAP.
- Complete account system — China Android OEM stores commonly require registration/login, purchase history, subscription management with renewal notice, account deletion, and guest-checkout binding prompts when the app sells IAP.
- Linked gates — Login and pay sit beside real-name verification, publish an app in China, and (for WeChat surfaces) Mini Program filing.
- Common myth — “Ship Firebase Auth + Stripe / Google Pay and localise the UI.” Mainland China users and store reviewers expect China rails first, not a mirrored Western checkout.
Vocabulary first. Next: what must exist before SDK tickets are real work.
What must exist before WeChat Pay or Alipay
Missing any of these stops your product team before merchant APIs or store review — not after the global auth stack is already frozen.
| Precondition | Why your process stalls |
|---|---|
| WeChat + Alipay first locked — login and pay baseline for Android; phone as second path | Global OAuth / cards-first plans fail China UX before merchant work starts |
| iOS peer options named — Sign in with Apple + Apple IAP beside WeChat / Alipay | Apple China review and digital catalog rules break when iOS is treated as “Android wallets only” |
| Mainland China entity or China landing partner | WeChat Pay / Alipay merchant accounts and open-platform verification need a China organizing path |
| SKU classification — digital goods vs physical / services; iOS vs Android | Wrong fork → Apple IAP reject or useless wallet wiring on digital iOS items |
| Complete account UX willingness — history, cancel, delete, guest prompts | OEM store packages fail when payments exist without an account system |
| Settlement and refund ops owner — who holds merchant keys, who refunds, who answers stores | Engineering finishes SDKs while finance and ops still have no China path |
Chinese-language consoles, enterprise verification, and legal-person rails sit outside a global Auth0 / Stripe checklist. Distribution context: publish an app in China and China app stores directory.
Login and payment decisions for China apps
Use this as a gate map. Stages are decisions, not console click-paths.
| Stage | Decision / outcome |
|---|---|
| 1. Classify the money surface | Digital goods / subscriptions vs physical goods / services; free + ads-only vs paid |
| 2. Lock first rails | WeChat login + WeChat Pay / Alipay as the Mainland China default; phone SMS as the strong second login |
| 3. Add iOS peer options | On App Store China: Sign in with Apple and Apple IAP as peer options beside WeChat / Alipay |
| 4. Choose organizing path | Chinese entity or contracted partner that can hold WeChat / Alipay merchant and open-platform accounts |
| 5. Design the complete account system | Registration, purchase history, subscription cancel + renewal notice, account deletion, guest binding prompts |
| 6. Align store packages | Screenshots and questionnaires match the China login and pay journey reviewers will hit |
| 7. Operate after listing | Refunds, subscription notices, PIPL requests, merchant key rotation — live ops, not a one-time SDK |
If scale later triggers MLPS or broader personal-information gates, sequence those beside payments — see China MLPS — do not invent thresholds without Mainland China ops.
Why global auth and card SDKs stall China launch
Skip WeChat / Alipay → empty China UX. Ordinary Mainland China consumers log in and pay with WeChat and Alipay first. Phone SMS is the usual backup login — not Google / Facebook OAuth.
Stripe / PayPal / cards first → empty checkout. Merchant onboarding without a Chinese entity or partner path stalls before production keys. Global card SDKs do not replace WeChat Pay or Alipay for ordinary China users.
Treat iOS as Android-only wallets → Apple policy conflict. Keep WeChat / Alipay in the China story, then add Sign in with Apple and Apple IAP as peer options. Digital catalog items on App Store China still need Apple IAP.
Payments without account system → OEM reject. In-app purchase without purchase history, cancel paths, deletion, or guest binding prompts fails common Android store rules even when the payment SDK works in a sandbox.
Login without real-name when the category needs it → live enforcement. Payment and social surfaces often need real-name verification beyond a soft signup — phone binding is the usual bridge.
Store pack ≠ live journey. Marketing builds that show WeChat Pay while the China binary still ships Stripe-only checkout trigger post-listing removals — the same failure mode as soft-launching without publish-path gates.
Where login and payment programs stall product teams
- Treating China checkout as a localisation ticket — merchant entity, open-platform verification, and Apple IAP classification are program gates, not string tables.
- Starting with global IAM docs before WeChat / Alipay and entity decisions — the stall is usually contracting and rail choice, not OAuth syntax.
- Ignoring the iOS peer fork — Android can lead with WeChat / Alipay; iOS still needs Sign in with Apple and Apple IAP named as peers.
- Shipping guest pay without account binding prompts — OEM stores treat unprotected purchase history as a compliance miss.
- Filing and store work without payment ops — mobile app filing and multi-store packages still fail when reviewers cannot complete login, pay, cancel, and delete.
- Broker promises of “WeChat Pay in a week” — diligence who holds the merchant account, who settles funds, what happens on reject, and who owns refunds.
When you need a China landing partner for login and pay
Most product teams exploring Mainland China entry need a China landing partner to turn login and payments into an executable launch sequence — entity or merchant path, WeChat and Alipay onboarding first, Sign in with Apple and Apple IAP as iOS peers, store-aligned account UX, and Chinese privacy materials — not a longer SDK reading list. Your team still owns product SKUs and the login method set; the partner path makes China payment rails and live ops workable when those rails are not already in-house.
What we can offer?
Login and payments in Mainland China are a rail map across identity, merchant entity, and store account gates — not one Stripe-replacement ticket. Chinaready helps your product team see which login and pay gates block the China launch and run them beside filing and distribution:
- China Readiness Assessment — Inventory WeChat / Alipay-first rails, iOS peer options (Sign in with Apple + Apple IAP), and entity gaps so the board funds the right sequence beside app filing and store gates.
- China Access Acceleration — Keep China review and payment test paths reachable from Mainland China so store checks match the journey users actually hit.
- China Product Hosting — Place China-critical account and payment-adjacent stacks where Mainland China reachability, data expectations, and launch evidence describe one coherent path.
- Mobile App Distribution — Align store packages, complete account UX, and payment proof so distribution and checkout stories do not diverge after listing.
Contact us when you need a login and payment rail map for the Mainland China app launch you plan to fund.
Frequently asked questions
Which login methods should China apps try first?
Start with WeChat login for most B2C Android apps — it is the mature consumer default in Mainland China. Keep phone number with SMS as a strong second path. On iOS, treat Sign in with Apple as a peer option beside WeChat when you offer third-party login. Email-only or Google/Facebook OAuth is not a China store plan.
Can overseas companies open WeChat Pay or Alipay merchant accounts directly?
Usually no. WeChat Pay and Alipay merchant onboarding expects a Mainland China business entity (or a contracted partner that holds merchant rails). Global Stripe, PayPal, or card SDKs do not replace those rails for ordinary China users.
How should iOS handle login and payments beside WeChat and Alipay?
Treat WeChat and Alipay as the consumer-first Mainland China rails, then add Sign in with Apple and Apple In-App Purchase / StoreKit as peer options on the Apple App Store China territory ([Apple IAP](https://developer.apple.com/in-app-purchase/)). Digital goods and subscriptions on iOS still need Apple IAP; physical goods and many services may use wallet rails — classify SKUs before you mix paths.
Why do China Android stores care about a complete account system?
Major OEM stores commonly require a complete account system when the app sells in-app purchases — registration/login, purchase history, subscription cancel and renewal notice, account deletion, and clear prompts if guest checkout is allowed. Missing account UX is a frequent review reject.
How does real-name verification relate to login and payments?
Payments, social, and regulated categories often need real-name verification (实名认证) on top of login. Phone binding is the common practical path because Mainland China mobiles are tied to identity. See the real-name verification Guide for classification and factor tiers.
Can product teams finish China login and payments without Mainland China ops?
Usually no. You need a Mainland China entity or landing-partner path, Chinese-language merchant and open-platform consoles, WeChat/Alipay (and Apple IAP) contracting, store-aligned account UX, and PIPL-aware data handling.
