The hop that costs you the sale
Open the same storefront as an H5 page inside a WebView and as a mini-program, and the moment of payment behaves completely differently. The H5 page calls a remote checkout: the browser redirects out to an external cashier, the user confirms, and then has to return to the merchant — often by tapping a small return button after the payment page closes. Every redirect is a chance to drop off. The mini-program version calls a native payment intent and a familiar password sheet appears in place; when it closes, control returns straight to your code.
This is not a styling difference. It is the container. H5 negotiates payment through a browser redirect and a remote signature; the mini-program holds a platform-level payment capability that the runtime maps directly to the native wallet.
What in-context payment actually is
The runtime exposes payment through a single reviewed API surface — the familiar wx.* family — rather than leaving each web page to build its own cashier and redirect dance. Behind that surface, the bridge routes the call to the native wallet: the order is signed server-side, the runtime presents the native pay sheet, the user authorizes, and the result comes back to your callback in the same session. No domain whitelist gymnastics, no deeplink that third-party browsers may intercept, no manual return tap.
Where the gap shows up
| Step | H5 in WebView | Mini-program runtime (native pay) |
|---|---|---|
| Trigger | window.location to remote cashier | In-context pay sheet |
| App switches | 2 hops (browser to wallet to browser) | 0 hops |
| User actions | Confirm order, jump out, enter password, return manually | Confirm order, enter password |
| Conversion | 60 to 80 percent | ~95 percent |
| Post-pay page | Manual return-to-merchant tap | Automatic callback redirect |
| Third-party browser | May block weixin:// deeplink | Not involved |
The numbers are consistent across multiple teardowns: H5 payments lose 20 to 40 percent on the switch, while mini-program JSAPI payments land near 95 percent. For a store doing real volume, that gap is the difference between a checkout and a leak.
Why one surface beats a redirect
A single reviewed payment surface means a developer writes wx.requestPayment once and it works across devices and host apps, instead of maintaining per-browser redirect flows, JS-SDK signatures, and domain whitelists. It also lets the platform enforce policy at the boundary — payment capability is granted by review, not by whoever serves the document — which is exactly the trust model a super-app needs for commerce.
How Cross Mini App applies it
Cross Mini App gives programs a native payment bridge that presents the in-context pay sheet and returns the result to your code in the same session, validated against policy before execution. Your store calls one payment intent; the runtime maps it to the device wallet on whatever host app it runs in. Users pay without leaving the room, and you keep the conversion that redirects throw away.
That is the difference between a checkout that sends people out the door and one that closes the sale where they stand.
Sources
- Juejin — Taro: H5 payment vs Mini-program JSAPI, 95 percent vs 60 to 80 percent
- Baiyu Group — Mini-program mall vs H5 mall: over 80 percent payment conversion, 30 percent higher than H5
- AInvest — Taro framework: seamless native-intent payment at roughly 95 percent conversion
- WeChat Pay — Mini Program payment API (wx.requestPayment)
