Na web aberta, tocar em «Pagar» abre o painel de pagamento do navegador: Apple Pay no Safari, Google Pay no Chrome ou a Payment Request API em todos os navegadores. Dentro de um WebView, esses botões somem em silêncio. O Apple Pay simplesmente não está disponível no WKWebView, e o Android desativa a Payment Request API a menos que o host a reative explicitamente. Um runtime próprio do host conecta os SDKs de pagamento nativos: uma chamada de pagamento uniforme que resolve Apple Pay, Google Pay ou a carteira da plataforma em cada motor.
Apple Pay: apenas Safari e SFSafariViewController
A documentação da Apple e todo o ecossistema de pagamentos são claros: o Apple Pay na web é suportado apenas no Safari e no SFSafariViewController. A Apple orienta os apps que carregam o checkout em um WKWebView a moverem a solicitação de pagamento para o código nativo. O Apple Pay JS (window.ApplePaySession) é efetivamente inexistente em um WebView embutido; o painel que abre nativamente no Safari desaparece e a página não obtém nenhum método de pagamento utilizável: a opção simplesmente não é oferecida.
O iOS 13 abriu um caminho estreito para o Apple Pay dentro do WKWebView, mas com uma armadilha severa: se o app chamar WKUserScript ou evaluateJavaScript antes da página usar o Apple Pay, a transação é desativada. Com o WebKit em camadas, mais WKWebViews agora são totalmente restritas à injeção de scripts. Para um app híbrido, o resultado prático é o mesmo: não se pode confiar no painel de pagamento web e é preciso conectar o Apple Pay via PKPaymentAuthorizationController em código nativo.
Android: Payment Request desativada por padrão
A própria documentação do Google Pay diz sem rodeios: «Por padrão, o WebView desativa a Payment Request API». Quando um checkout web é embutido em um Android WebView, a Payment Request API —que o fluxo web do Google Pay usa para abrir o painel de pagamento— fica desligada. Para reativá-la, o host deve adicionar a dependência AndroidX WebKit, declarar a flag de metadados android.webkit.WebView.enablePaymentRequest e chamar WebSettingsCompat.setPaymentRequestEnabled(settings, true) em tempo de execução.
E os requisitos são rigorosos: o Google Pay dentro do WebView precisa do Google Play services 25.18.30+ e do Android WebView (Chrome) 137+, e o isReadyToPay retorna false quando não são atendidos. A Stripe descontinuou seu Payment Request Button, e os provedores empurram sistematicamente para SDKs nativos justamente porque o caminho web embutido é pouco confiável.
O que quebra quando o pagamento morre
- O botão da carteira nunca aparece. Um checkout que mostra Apple Pay ou Google Pay no navegador não mostra nenhum dos dois no WebView: sem erro, apenas uma opção ausente.
- A conversão despenca. Os usuários que pagavam só com uma carteira ficam obrigados a digitar os dados do cartão ou desistem.
- O login federado também falha. O mesmo WebView embutido perde o login com Google (
disallowed_useragent), então login e pagamento travam juntos. - Os navegadores de apps sociais também o escondem. Os WebViews de WeChat, Douyin, Instagram e Facebook impõem suas próprias restrições, então a quebra não aparece no QA de desktop.
A solução do runtime
Um runtime próprio do host conecta a camada de pagamento. A página chama uma API uniforme —runtime.requestPayment(methods, details)— e o host a resolve por meio do SDK de pagamento nativo da plataforma: Apple Pay via PKPaymentAuthorizationController no iOS, Google Pay / o painel de pagamento nativo no Android. A sessão do comerciante, a apresentação do painel e o retorno do token são tratados de forma nativa e consistente. Uma integração, cada motor, um checkout concluído.
| Dimensão | WebView | Runtime próprio do host |
|---|---|---|
| Apple Pay (iOS) | Não suportado no WKWebView | PKPaymentAuthorizationController nativo |
| Google Pay (Android) | Payment Request desativada por padrão | SDK do Google Pay nativo |
| Ativação | Flags do host + AndroidX WebKit | Um runtime.requestPayment() |
| Apresentação do painel | Do navegador, ausente | Do host, confiável |
| Fallback | Apenas cartão manual | Carteira ou cartão, ambos conectados |
| Consistência | Conforme o motor | Uniforme |
Um app nativo conclui um pagamento com carteira em todos os dispositivos. Um WebView padrão o conclui em quase nenhum. Um runtime dá à página uma ação de pagar —e uma autorização real no final.
Fontes
- Apple Developer — Password AutoFill / guia do Apple Pay na web — a Apple leva as solicitações de pagamento do WKWebView ao código nativo; o Apple Pay na web é recurso do Safari / SFSafariViewController.
- Google Pay API for Android — Usando o Android WebView — «Por padrão, o WebView desativa a Payment Request API»; requer AndroidX WebKit +
setPaymentRequestEnabled. - openpwa — Ecossistema de pagamentos — «um WKWebView não pode [usar Apple Pay] e a Apple direciona esses apps ao código nativo»; matriz de camadas e comportamento da Payment Request.
- MoonPay — FAQ de pagamentos móveis — Apple Pay não suportado no WKWebView; Google Pay não suportado oficialmente em WebViews, usar Chrome Custom Tabs.
- Breeze — Guia de apps móveis embutidos — o WebView padrão é o único contêiner que perde tanto o Google Pay quanto o login federado; os métodos restantes são cartão, Apple Pay e crypto.
