那一次跳转，丢掉了成交
把同一家店铺分别做成 WebView 里的 H5 页面和小程序，到了付款那一刻，体验完全不同。H5 页面走的是远端收银：浏览器跳转到外部收银台，用户确认，然后还得自己跳回商家——往往要在支付页关闭后点一个很小的「返回商家」。每一次跳转都是一次流失。小程序版本调用的是原生支付意图，熟悉的密码面板就地弹出；关闭后，控制权直接回到你的代码。
这不是样式差异，是容器的差异。H5 通过浏览器重定向加远端签名来协商支付；小程序持有一项平台级的支付能力，由运行时直接映射到原生钱包。
上下文内支付到底是什么
运行时通过单一、经审核的 API 面——熟悉的 wx.* 家族——暴露支付，而不是让每个网页自建收银台和跳转流程。在这层表面背后，桥接把调用路由到原生钱包：订单在服务端签名，运行时弹出原生支付面板，用户授权，结果在同一会话里回到你的回调。没有域名白名单的折腾，没有第三方浏览器可能拦截的 deeplink，没有手动点返回。
差距在哪里显现
| 环节 | WebView 里的 H5 | 小程序运行时（原生支付） |
|---|---|---|
| 触发 | window.location 跳远端收银台 | 上下文内支付面板 |
| 应用切换 | 2 次跳转（浏览器→钱包→浏览器） | 0 次跳转 |
| 用户操作 | 确认订单、跳出、输密码、手动返回 | 确认订单、输密码 |
| 转化率 | 60% 至 80% | 约 95% |
| 支付后页面 | 手动点返回商家 | 回调自动跳转 |
| 第三方浏览器 | 可能拦截 weixin:// deeplink | 不涉及 |
多个拆解数据一致：H5 支付在切换中流失 20% 到 40%，小程序 JSAPI 支付接近 95%。对真实体量的店铺而言，这个差距是「能结账」和「一直漏单」的区别。
为什么一个接口面胜过一堆跳转
单一、经审核的支付接口面意味着开发者写一次 wx.requestPayment，就能跨设备和宿主 App 生效，而不是为每个浏览器维护重定向流程、JS-SDK 签名和域名白名单。它也让平台能在边界处执行策略——支付能力由审核授予，而不是由谁提供文档决定——这正是超级 App 做电商所需的信任模型。
Cross Mini App 如何落地
Cross Mini App 为程序提供原生支付桥接：在上下文内弹出支付面板，并在同一会话把结果交回你的代码，且在执行前按策略校验。你的店铺调用一次支付意图，运行时把它映射到当前宿主 App 的设备钱包上。用户不用离开房间就能付款，而你保留下了被跳转白白丢掉的转化。
这就是把人送出门口的收银台，与就地成交的收银台之间的区别。
