Há um número que deveria envergonhar qualquer equipe que lance um checkout em mercados emergentes. No Brasil, o Pix —um rail que a maioria dos gerentes de produto do Vale do Silício nem conhecia até pouco tempo— processou cerca de 64 bilhões de transações em 2024, cerca de 80% a mais que cartões de crédito e débito juntos. Na Índia, o UPI liquidou 172 bilhões de transações naquele mesmo ano. No Quênia, o M-Pesa movimenta 40 trilhões de xelins por ano em 31,5 milhões de contas ativas. Nenhum desses fluxos passa pela Visa ou Mastercard. Quase nenhum passa por um checkout WebView genérico.
E, no entanto, a forma padrão como um app em crescimento «integra pagamentos» nesses mercados é soltar um WebView, apontar para um PSP global e rezar para o formulário de cartão converter. Não converte. O rail que realmente move o dinheiro localmente é invisível para aquele formulário, e o imposto de redirecionamento —redirecionamento bancário, OTP, troca de app, timeout— come a conversão que você cruzou o oceano para capturar.
A armadilha é estrutural, não cosmética
Um checkout WebView é construído sobre uma suposição: o usuário tem cartão e um banco que joga bem com 3-D Secure. Em mercados emergentes essa suposição costuma estar errada. Nas Filipinas, o GCash sozinho detém 89% do mercado de carteiras móveis com 94 milhões de usuários registrados; a penetração de cartões é um arredondamento perto disso. No Brasil, o Pix já é o padrão para pagamento pessoa a comércio —39% de todo o volume Pix em março de 2024 foi P2B, e é a fatia de crescimento mais rápido. Na Índia, o UPI é oito em cada dez pagamentos digitais.
Quando seu checkout só fala cartão, você está pedindo a um brasileiro, um indiano, um queniano, um filipino que deixe sua carteira preferida, abra um navegador, digite 16 dígitos, sobreviva a uma rodada de OTP e volte. A cada passo, a sessão pode morrer. O WebView é a porta errada para um mercado que já escolheu a sua.
Cada mercado é um rail diferente, e você não controla nenhum
O segundo problema é que «pagamentos locais» não é uma coisa só. São Pix no Brasil, UPI na Índia, M-Pesa e MTN MoMo na África, GCash e Maya nas Filipinas, PromptPay na Tailândia, GoPay e OVO na Indonésia, e mais uma dúzia. Cada um tem sua API, seu PSP, seu ritmo de liquidação e sua tampa regulatória —licenças, KYC, localização de dados, limites de transação.
Construa uma integração baseada em navegador para cada um e você terá implantado N páginas frágeis que não são suas. O código vive no origin de outra pessoa. A sessão, a lógica de retry, o modo de falha —tudo fora do seu runtime. Quando o PSP muda um redirecionamento, seu checkout quebra em silêncio, em um idioma que seu suporte não monitora, em um mercado que você tenta conquistar.
Lado a lado
| Dimensão | Checkout WebView (cartão primeiro) | Runtime do host + rails locais |
|---|---|---|
| Cobertura de rail local | Apenas cartões | Pix, UPI, M-Pesa, GCash nativos |
| Custo de integração | Um PSP global, depois N redirecionamentos frágeis | Uma superfície de runtime, PSPs locais atrás |
| Conversão | Imposto redirecionamento + OTP, alta queda | Dentro do app, sem troca de app |
| Propriedade do host | O provedor possui sessão e dados | O host possui transação e relação |
| Postura de conformidade | Bruta, você é o controlador de dados | Rails locais + KYC controlado pelo host |
| Manutenibilidade | N páginas de navegador à deriva | Uma entrada de catálogo por rail |
O que um runtime muda de verdade
Um runtime próprio do host não inventa um rail de pagamento. Ele elimina a parte que sempre foi sua para consertar: a porta. Em vez de entregar o usuário a um navegador e rezar, o host conecta uma carteira e os rails locais diretamente ao runtime. O usuário fica dentro do app, toca Pix ou UPI ou M-Pesa, autentica uma vez no app do banco e cai de volta no seu fluxo. Sem troca de app, sem WebView morto, sem sessão órfã.
O host também guarda o que importa: a transação, a identidade por trás dela e a relação. Este é o mesmo argumento de propriedade da peça anterior sobre controle de ativos —mas aqui é concreto e é dinheiro. O rail é local; o controle fica com o host.
A ressalva honesta
Um runtime não é uma licença de pagamentos. Conectar-se ao Pix, UPI ou M-Pesa ainda significa uma parceria com PSP, KYC local, contas de liquidação e uma tampa regulatória que varia por país. O que o runtime elimina é o imposto WebView —a conversão que você perde toda vez que rebote um usuário local para um navegador que ele não escolheu. Não elimina o trabalho regulatório. Quem lhe disser «só solta um runtime e você já está bancarizado no Brasil» está vendendo algo.
Se seu plano de crescimento depende de mercados onde o cartão é a exceção, a pergunta não é se deve suportar rails locais. É se sua arquitetura consegue falar a língua deles nativamente, ou se você ainda está entregando cada pagador local a uma porta que não serve.
