Hay un número que debería avergonzar a cualquier equipo que lance una pasarela a mercados emergentes. En Brasil, Pix —un rail que la mayoría de los gerentes de producto de Silicon Valley ni conocía hace poco— procesó cerca de 64 mil millones de transacciones en 2024, un 80% más que tarjetas de crédito y débito juntas. Ese mismo año, en India, UPI liquidó 172 mil millones de transacciones. En Kenia, M-Pesa mueve 40 billones de chelines al año en 31,5 millones de cuentas activas. Ninguno de estos flujos pasa por Visa o Mastercard. Casi ninguno pasa tampoco por una pasarela WebView genérica.
Y, sin embargo, la forma predeterminada en que una app en crecimiento «integra pagos» en estos mercados es soltar un WebView, apuntarlo a un PSP global y rezar para que el formulario de tarjeta convierta. No convierte. El rail que realmente mueve el dinero localmente es invisible para ese formulario, y el impuesto de redirección —redirección bancaria, OTP, cambio de app, timeout— se come la conversión que volaste el océano para capturar.
La trampa es estructural, no cosmética
Una pasarela WebView se construye sobre un supuesto: que el usuario tiene tarjeta y un banco que juega bien con 3-D Secure. En mercados emergentes ese supuesto suele ser falso. En Filipinas, GCash por sí sola tiene el 89% del mercado de monederos móviles con 94 millones de usuarios registrados; la penetración de tarjetas es un redondeo al lado. En Brasil, Pix ya es el predeterminado para el pago persona a comercio —el 39% de todo el volumen Pix en marzo de 2024 fue P2B, y es la porción de más rápido crecimiento. En India, UPI es ocho de cada diez pagos digitales.
Cuando tu pasarela solo habla tarjetas, le pides a un brasileño, un indio, un keniano, un filipino que deje su monedero preferido, abra un navegador, teclee 16 dígitos, sobreviva una ronda de OTP y vuelva. En cada paso, la sesión puede morir. El WebView es la puerta equivocada para un mercado que ya eligió la suya.
Cada mercado es un rail distinto, y no controlas ninguno
El segundo problema es que «pagos locales» no es una sola cosa. Son Pix en Brasil, UPI en India, M-Pesa y MTN MoMo en África, GCash y Maya en Filipinas, PromptPay en Tailandia, GoPay y OVO en Indonesia, y una docena más. Cada uno tiene su API, su PSP, su ritmo de liquidación y su tapa regulatoria —licencias, KYC, localización de datos, límites de transacción.
Construye una integración basada en navegador para cada uno y habrás desplegado N páginas frágiles que no posees. El código vive en el origin de otro. La sesión, la lógica de reintento, el modo de fallo —todo fuera de tu runtime. Cuando el PSP cambia una redirección, tu pasarela se rompe en silencio, en un idioma que tu soporte no monitorea, en un mercado que intentas ganar.
Cara a cara
| Dimensión | Pasarela WebView (tarjeta primero) | Runtime del host + rails locales |
|---|---|---|
| Cobertura de rail local | Solo tarjetas | Pix, UPI, M-Pesa, GCash nativos |
| Costo de integración | Un PSP global, luego N redirecciones frágiles | Una superficie de runtime, PSP locales detrás |
| Conversión | Impuesto redirección + OTP, alta caída | En la app, sin cambio de app |
| Propiedad del host | El proveedor posee sesión y datos | El host posee transacción y relación |
| Postura de cumplimiento | Tozuda, tú eres el controlador de datos | Rails locales + KYC controlado por host |
| Mantenibilidad | N páginas de navegador a la deriva | Una entrada de catálogo por rail |
Lo que un runtime cambia de verdad
Un runtime propio del host no inventa un rail de pago. Elimina la parte que siempre fue tuya por arreglar: la puerta. En lugar de entregar el usuario a un navegador y rezar, el host conecta una billetera y los rails locales directamente al runtime. El usuario se queda dentro de la app, toca Pix o UPI o M-Pesa, se autentica una vez en su app del banco y aterriza de vuelta en tu flujo. Sin cambio de app, sin WebView muerto, sin sesión huérfana.
El host también conserva lo que importa: la transacción, la identidad detrás y la relación. Este es el mismo argumento de propiedad de la pieza anterior sobre control de activos —pero aquí es concreto y es dinero. El rail es local; el control queda con el host.
La salvedad honesta
Un runtime no es una licencia de pagos. Conectarse a Pix, UPI o M-Pesa sigue significando una sociedad con un PSP, KYC local, cuentas de liquidación y una tapa regulatoria que varía por país. Lo que el runtime elimina es el impuesto WebView —la conversión que pierdes cada vez que rebotas a un usuario local a un navegador que no eligió. No elimina el trabajo regulatorio. Quien te diga «solo suelta un runtime y ya estás bancarizado en Brasil» está vendiendo algo.
Si tu plan de crecimiento depende de mercados donde la tarjeta es la excepción, la pregunta no es si soportar rails locales. Es si tu arquitectura puede hablarlos de forma nativa, o si sigues entregando a cada pagador local una puerta que no le queda.
