System-owned identity and payment change flow boundaries

What it is

On WeChat, Alipay, and HarmonyOS, sign-in and paying are often not two steps inside the app funnel. They are host sheets raised by the system or the super-app. The app’s flow should end at “request identity” or “request payment”: the host shows its own account picker, biometrics, checkout, and result, then returns a token or a payment result. Trust cues (is this my WeChat, which account is charged) live on the host chrome, not on a merchant page imitating a form. The flow boundary moves forward—the merchant no longer owns the stretch from typing a phone number to seeing payment succeed.

This is which side owns the identity and money steps, not how the mini-program capsule is laid out, and not how desktop cards promote a function. Building a parallel username, password, and bank-card form inside the app will be intercepted by the host, and will make users who already parked their identity in WeChat or Alipay feel they are proving themselves twice.

Why it happens

Identity and money accounts live on the host; the app only asks to use them once. The host draws the sheet so the user checks the chrome, not the merchant: a familiar avatar, already-bound cards, system biometrics. Those cues cannot be honestly copied on a merchant page; copying them is a phishing signal. What the app may add is context before the request (what is being bought, amount, merchant name) and a business result after (order created, what to change on failure). The middle—picking an account, confirming, verifying, seeing the funding source—is neither drawable nor appropriate for the app.

Cancel and failure change owners too. A swipe-away on the host sheet arrives as cancel, not as “form validation failed.” The app should return to the pre-request merchant page and keep the cart, not invent error copy that pretends to explain what happened inside the host. Once amount, currency, and item description are handed to checkout, they must not change underneath while the host sheet is still open, or the chrome the user checked will disagree with the charge. Scopes are listed by the host as well: avatar, phone, address the app wants must be visible on the host consent surface, not silently added after the callback.

Where it stops holding

A standalone site that does not connect WeChat Pay, Alipay, or a system account still owns its own funnel; the host-sheet model does not apply. Cross-border receipts, corporate transfers, cash, and cash-on-delivery never go through these sheets; forcing them hides channels that should exist. Minors, enterprise accounts, and split-settlement merchants may be extra-blocked on the host side. The app sees a failure code, not “the user decided not to buy,” and must separate those failures from ordinary payment failure. Pure browsing surfaces that involve neither identity nor money should not raise a sign-in sheet for the sake of “being consistent.”

Applying it

• Cut the funnel into three: the app states context before the request (item, amount, merchant name); identity and payment only raise the host sheet; after the callback the app handles success, cancel, and failure codes as business states.
• Do not collect passwords, SMS codes, or card numbers in-app for the same sign-in or payment. List needed data once in the host’s authorization items.
• Freeze amount and description while the host sheet is open. On cancel, return to the pre-request page and keep what the user had already entered.
• Verify by walking WeChat or Alipay sign-in and payment (or a sandbox) and noting the frame where the app hands control to host chrome and the frame where it takes control back. Overlaying a spinner on the host sheet, changing the price while it is open, or emptying the cart on cancel all mean the boundary was drawn wrong. Then deny one scope and confirm the app does not silently collect it after the callback.

Related

• Same group: R4.04.1 Distributed continuation across devices · R4.04.2 Constraints of mini-programs inside super-apps · R4.04.3 Points of divergence from international platform conventions · R4.04.4 Multi-end deployment requires layout by capability, not screen name · R4.04.5 Service cards surface functions at the desktop layer
• Adjacent: R4.07 App store review · H1.07 Preventing duplicate submission
• Search terms: host-mediated payment · OAuth sheet · WeChat Pay · Alipay