有一个数字应该让任何向新兴市场推收银台的团队脸红。在巴西，Pix——一个多数硅谷产品经理直到最近都没听说过的通道——2024 年处理了约 640 亿笔交易，比信用卡和借记卡加起来还多约 80%。同年在印度，UPI 清算了 1720 亿笔。在肯尼亚，M-Pesa 一年经手 40 万亿先令，覆盖 3150 万个活跃账户。这些流水没有一笔走 Visa 或万事达，也几乎没有一笔走通用的 WebView 收银台。
然而成长型 App「接入支付」的默认做法，仍是丢一个 WebView，指向一家全球 PSP，然后祈祷那个卡片表单能转化。它转化不了。真正在当地搬动钱的通道，那个表单根本看不见；而跳转税——银行跳转、OTP 验证码、应用切换、超时——会吃掉你漂洋过海抢来的转化。
这是个结构性陷阱，不是皮肤问题
WebView 收银台建立在一个假设上：用户有卡，且他的银行友好支持 3-D Secure。在新兴市场，这个假设大多数时候是错的。在菲律宾，GCash 一家就占移动钱包市场 89%，注册用户 9400 万；卡渗透率相比之下可以忽略。在巴西，Pix 已成为个人对商户付款的默认方式——2024 年 3 月 Pix 总量里 39% 是 P2B，且是增长最快的一块。在印度，UPI 占每十笔数字支付里的八笔。
当你的收银台只认卡，你是在要求一个巴西人、印度人、肯尼亚人、菲律宾人离开他惯用的钱包，打开浏览器，敲 16 位卡号，熬过一轮 OTP，再回来。每一步，会话都可能死掉。对于一个已经选好自己的门的市场，WebView 是错的门。
每个市场是另一条通道，且你一条都控制不了
第二个问题是，「本地支付」不是一件事。它是巴西的 Pix、印度的 UPI、非洲的 M-Pesa 和 MTN MoMo、菲律宾的 GCash 和 Maya、泰国的 PromptPay、印尼的 GoPay 和 OVO，以及十几条别的。每条都有自己的 API、自己的 PSP、自己的结算节奏，以及自己的监管盖子——牌照、KYC、数据本地化、交易限额。
为每条都做一套浏览器集成，等于你发出了 N 个你不拥有的脆弱页面。代码跑在别人的 origin 上。会话、重试逻辑、失败模式——全在你的 runtime 之外。当 PSP 改了一次跳转，你的收银台会静默崩掉，用的是你客服团队不监控的语言，在你正想拿下的市场里。
逐项对比
| 维度 | WebView 收银台（卡片优先） | 宿主 runtime + 本地通道 |
|---|---|---|
| 本地通道覆盖 | 仅卡片 | 原生支持 Pix、UPI、M-Pesa、GCash |
| 接入成本 | 一家全球 PSP，外加 N 次脆弱跳转 | 一个 runtime 面，本地 PSP 藏在后面 |
| 转化率 | 跳转 + OTP 税，高流失 | 应用内完成，无应用切换 |
| 宿主归属 | 服务商拥有会话与数据 | 宿主拥有交易与关系 |
| 合规姿态 | 粗放，你仍是数据控制者 | 本地通道 + 宿主可控 KYC |
| 可维护性 | N 个浏览器页面各自漂移 | 每条通道一个目录条目 |
runtime 真正改变的是什么
宿主自有的 runtime 不会发明一条支付通道。它去掉的，是一直本该你修的那部分：那扇门。宿主不再把用户交给浏览器然后祈祷，而是把钱包和本地通道直接插进 runtime。用户留在 App 里，点一下 Pix 或 UPI 或 M-Pesa，在自己的银行 App 里认证一次，回到你的流程。没有应用切换，没有死掉的 WebView，没有孤儿会话。
宿主也保住了要紧的东西：交易、交易背后的身份、以及关系。这和之前那篇讲资产归属的论点同源——但这里它是具体的，而且是钱。通道是本地的，控制权留在宿主手里。
诚实的提醒
runtime 不是支付牌照。接入 Pix、UPI 或 M-Pesa，仍然意味着一家 PSP 合作、本地 KYC、结算账户，以及随国家变化的合规盖子。runtime 去掉的是 WebView 税——你每次把一个本地用户弹到他没选的浏览器时丢掉的转化。它不去掉监管工作。谁跟你说「丢个 runtime 就能在巴西开户」，那是在卖东西。
如果你的增长计划押在卡片是例外的市场，问题不是要不要支持本地通道，而是你的架构能不能原生地说它们的语言，还是你仍在把每个本地付款人交给一扇不合身的门。
