O salto que custa a venda
Abra a mesma loja como página H5 dentro de um WebView e como mini-programa, e o instante do pagamento se comporta de forma totalmente diferente. A página H5 chama um caixa remoto: o navegador redireciona para uma pasarela externa, o usuário confirma e depois precisa voltar ao comércio, muitas vezes tocando num pequeno botão de retorno quando a página de pagamento fecha. Cada redirecionamento é uma chance de abandono. A versão mini-programa invoca uma intenção de pagamento nativa e a conhecida folha de senha aparece no lugar; ao fechar, o controle volta direto ao seu código.
Não é diferença de estilo. É o contêiner. O H5 negocia o pagamento por redirecionamento do navegador e assinatura remota; o mini-programa possui uma capacidade de pagamento em nível de plataforma que o runtime mapeia diretamente para a carteira nativa.
O que é realmente o pagamento em contexto
O runtime expõe o pagamento por uma única superfície de API revisada, a familiar família wx.*, em vez de deixar cada página web construir seu próprio caixa e sua própria dança de redirecionamentos. Atrás dessa superfície, a ponte roteia a chamada para a carteira nativa: o pedido é assinado no servidor, o runtime apresenta a folha de pagamento nativa, o usuário autoriza e o resultado volta ao seu callback na mesma sessão. Sem ginástica de listas brancas de domínio, sem deeplink que navegadores de terceiros possam bloquear, sem toque manual de retorno.
Onde aparece a diferença
| Passo | H5 em WebView | Runtime de mini-programa (pagamento nativo) |
|---|---|---|
| Disparador | window.location para caixa remoto | Folha de pagamento em contexto |
| Trocas de app | 2 saltos (navegador a carteira a navegador) | 0 saltos |
| Ações do usuário | Confirmar pedido, sair, senha, voltar manual | Confirmar pedido, senha |
| Conversão | 60 a 80 por cento | ~95 por cento |
| Página pós-pago | Toque manual de retorno | Redirecionamento automático por callback |
| Navegador de terceiros | Pode bloquear deeplink weixin:// | Não intervém |
Os números são consistentes em várias análises: pagamentos H5 perdem 20 a 40 por cento na troca, enquanto pagamentos JSAPI de mini-programa chegam perto de 95 por cento. Para uma loja com volume real, essa diferença é entre um caixa e um vazamento.
Por que uma superfície vence um redirecionamento
Uma única superfície de pagamento revisada significa que um desenvolvedor escreve wx.requestPayment uma vez e funciona em todos os dispositivos e apps anfitriãs, em vez de manter fluxos de redirecionamento por navegador, assinaturas JS-SDK e listas brancas de domínio. Também permite à plataforma aplicar política na fronteira: a capacidade de pagamento é concedida por revisão, não por quem serve o documento, que é exatamente o modelo de confiança que uma super-app precisa para o comércio.
Como a Cross Mini App aplica
A Cross Mini App oferece aos programas uma ponte de pagamento nativa que apresenta a folha de pagamento em contexto e devolve o resultado ao seu código na mesma sessão, validada contra a política antes de executar. Sua loja invoca uma intenção de pagamento; o runtime a mapeia para a carteira do dispositivo em qualquer app anfitriã. Os usuários pagam sem sair da sala, e você mantém a conversão que os redirecionamentos descartam.
Esta é a diferença entre um caixa que manda as pessoas porta afora e um que fecha a venda onde elas estão.
