El salto que le cuesta la venta
Abre la misma tienda como página H5 dentro de un WebView y como mini-programa, y el instante del pago se comporta de forma totalmente distinta. La página H5 llama a una caja remota: el navegador redirige a una pasarela externa, el usuario confirma y luego debe volver al comercio, a menudo tocando un pequeño botón de retorno cuando la página de pago se cierra. Cada redirección es una oportunidad de abandono. La versión mini-programa invoca una intención de pago nativa y aparece en su lugar la conocida hoja de contraseña; al cerrarse, el control vuelve directo a tu código.
No es una diferencia de estilo. Es el contenedor. El H5 negocia el pago mediante una redirección del navegador y una firma remota; el mini-programa posee una capacidad de pago a nivel de plataforma que el runtime mapea directamente a la billetera nativa.
Qué es realmente el pago en contexto
El runtime expone el pago mediante una única superficie de API revisada, la familiar familia wx.*, en lugar de dejar que cada página web construya su propia caja y su propio baile de redirecciones. Detrás de esa superficie, el puente enruta la llamada a la billetera nativa: el pedido se firma en el servidor, el runtime presenta la hoja de pago nativa, el usuario autoriza y el resultado regresa a tu callback en la misma sesión. Sin gimnasia de listas blancas de dominio, sin deeplink que navegadores de terceros puedan bloquear, sin toque manual de retorno.
Dónde aparece la brecha
| Paso | H5 en WebView | Runtime de mini-programa (pago nativo) |
|---|---|---|
| Disparador | window.location a caja remota | Hoja de pago en contexto |
| Cambios de app | 2 saltos (navegador a billetera a navegador) | 0 saltos |
| Acciones del usuario | Confirmar pedido, salir, contraseña, volver manual | Confirmar pedido, contraseña |
| Conversión | 60 a 80 por ciento | ~95 por ciento |
| Página post-pago | Toque manual de retorno | Redirección automática por callback |
| Navegador de terceros | Puede bloquear deeplink weixin:// | No interviene |
Las cifras son coherentes en varios análisis: los pagos H5 pierden 20 a 40 por ciento en el cambio, mientras los pagos JSAPI de mini-programa llegan cerca del 95 por ciento. Para una tienda con volumen real, esa brecha es la diferencia entre una caja y una fuga.
Por qué una superficie vence a una redirección
Una única superficie de pago revisada significa que un desarrollador escribe wx.requestPayment una vez y funciona en todos los dispositivos y apps anfitrionas, en lugar de mantener flujos de redirección por navegador, firmas JS-SDK y listas blancas de dominio. También permite a la plataforma aplicar políticas en el límite: la capacidad de pago se concede por revisión, no por quien sirve el documento, que es exactamente el modelo de confianza que una super-app necesita para el comercio.
Cómo lo aplica Cross Mini App
Cross Mini App ofrece a los programas un puente de pago nativo que presenta la hoja de pago en contexto y devuelve el resultado a tu código en la misma sesión, validado contra la política antes de ejecutarse. Tu tienda invoca una intención de pago; el runtime la mapea a la billetera del dispositivo en cualquier app anfitriona. Los usuarios pagan sin salir de la habitación, y tú conservas la conversión que las redirecciones desperdician.
Esta es la diferencia entre un mostrador que saca a la gente por la puerta y uno que cierra la venta donde está parada.
