There is a number that should embarrass any team shipping a checkout to emerging markets. In Brazil, Pix — a rail most Silicon Valley product managers had never heard of until recently — processed about 64 billion transactions in 2024, roughly 80% more than credit and debit cards combined. In India, UPI cleared 172 billion transactions that same year. In Kenya, M-Pesa moves KSh 40 trillion a year across 31.5 million active accounts. None of these flows go through Visa or Mastercard. Almost none of them go through a generic WebView checkout either.
And yet the default way a growth-stage app «integrates payments» in these markets is to drop a WebView, point it at a global PSP, and hope the card form converts. It doesn't. The rail that actually moves money locally is invisible to that form, and the redirect tax — bank redirect, OTP, app-switch, timeout — eats the conversion you flew overseas to capture.
The trap is structural, not cosmetic
A WebView checkout is built on one assumption: that the user has a card and a bank that plays nicely with 3-D Secure. In emerging markets that assumption is wrong most of the time. In the Philippines, GCash alone holds 89% of the mobile-wallet market with 94 million registered users; card penetration is a rounding error by comparison. In Brazil, Pix is now the default for person-to-business payment — 39% of all Pix volume in March 2024 was P2B, and it is the fastest-growing slice. In India, UPI is eight of every ten digital payments.
When your checkout only speaks cards, you are asking a Brazilian, an Indian, a Kenyan, a Filipino to leave their wallet of choice, open a browser, type a 16-digit number, survive an OTP round-trip, and come back. At every step, the session can die. The WebView is the wrong door for a market that has already chosen its own door.
Each market is a different rail, and you control none of them
The second problem is that «local payments» is not one thing. It is Pix in Brazil, UPI in India, M-Pesa and MTN MoMo across Africa, GCash and Maya in the Philippines, PromptPay in Thailand, GoPay and OVO in Indonesia, and a dozen more. Each has its own API, its own PSP, its own settlement rhythm, and its own regulatory lid — licensing, KYC, data localization, transaction caps.
Build a browser-based integration for each and you have shipped N fragile pages you don't own. The code lives on someone else's origin. The session, the retry logic, the failure mode — all outside your runtime. When the PSP changes a redirect, your checkout breaks silently, in a language your support team doesn't monitor, in a market you are trying to win.
Side by side
| Dimension | WebView checkout (card-first) | Host runtime + local rails |
|---|---|---|
| Local rail coverage | Cards only | Pix, UPI, M-Pesa, GCash native |
| Integration cost | One global PSP, then N fragile redirects | One runtime surface, local PSPs behind it |
| Conversion | Redirect + OTP tax, high drop-off | In-app, no app-switch |
| Host ownership | Provider owns session & data | Host owns transaction & relationship |
| Compliance posture | Blunt, you are still the data controller | Local rails + host-controlled KYC |
| Maintainability | N browser pages drift | One catalog entry per rail |
What a runtime actually changes
A host-owned runtime does not invent a payment rail. It removes the part that was always yours to fix: the door. Instead of handing the user to a browser and praying, the host plugs a wallet and the local rails directly into the runtime. The user stays inside the app, taps Pix or UPI or M-Pesa, authenticates once in their bank app, and lands back in your flow. No app-switch, no dead WebView, no orphaned session.
The host also keeps what matters: the transaction, the identity behind it, and the relationship. This is the same ownership argument from the earlier piece on asset control — but here it is concrete, and it is money. The rail is local; the control stays with the host.
The honest caveat
A runtime is not a payments license. Plugging into Pix, UPI, or M-Pesa still means a PSP partnership, local KYC, settlement accounts, and a compliance lid that varies by country. What the runtime removes is the WebView tax — the conversion you lose every time you bounce a local user out to a browser they didn't choose. It does not remove the regulatory work. Anyone who tells you «just drop in a runtime and you're banked in Brazil» is selling something.
If your growth plan depends on markets where cards are the exception, the question isn't whether to support local rails. It is whether your architecture can speak them natively, or whether you are still handing every local payer to a door that doesn't fit.
