PrestaShop 9.2 añade un One Page Checkout nativo en beta, ¿esperar o actuar?

Actualización de mayo de 2026: PrestaShop ya ha confirmado a sus socios que el proceso de pago nativo en una página se lanzará como módulo del núcleo en PrestaShop 9.2, y que la propia versión 9.2 está prevista actualmente para el segundo semestre de 2026. Cubrimos ese anuncio en una noticia más breve: One Page Checkout nativo de PrestaShop 9.2.

Última actualización: junio de 2026.

Llevamos desarrollando módulos de pago desde los tiempos de PrestaShop 1.6, y también hemos reconstruido desde cero el proceso de pago en aproximadamente la mitad de las tiendas de nuestros clientes en algún momento. Así que, cuando el equipo del núcleo de PrestaShop anunció un proceso de pago nativo en una página en la Live Update del 30 de julio de 2025, prestamos atención. El desarrollo empezó en serio a comienzos de 2026 y el primer feature flag llegó al núcleo unas semanas después.

Esta es la página que enviamos a los comerciantes que nos preguntan: "¿Debería esperar al OPC nativo o arreglar mi proceso de pago ahora?" Vendemos Checkout Revolution, así que no somos neutrales. Pero también gestionamos tiendas, y preferimos que leas una comparación honesta antes que comprar algo que no necesitas.

Tres búsquedas sobre pago que parecen iguales, tres problemas distintos

Antes de comparar nada, conviene separar estas tres ideas. Las vemos confundidas en tickets de soporte todas las semanas.

El OPC nativo de PrestaShop es un diseño de proceso de pago del núcleo para el futuro: todavía no existe en una versión estable. Checkout Revolution es nuestro reemplazo completo del proceso de pago en una página para comerciantes que no pueden esperar. Express Checkout es un módulo independiente y más ligero que añade botones de Apple Pay / Google Pay / PayPal a las páginas de producto y carrito sin tocar el proceso de pago existente. No son el mismo producto, y la tabla comparativa de abajo existe porque hay gente que compra habitualmente el módulo equivocado.

Qué ha dicho realmente PrestaShop

La Live Update de julio de 2025 confirmó que el OPC nativo estaba en la hoja de ruta. El informe Core Monthly de febrero de 2026 confirmó que el desarrollo había empezado, y el primer feature flag llegó en la pull request #40796.

Leyendo las PR y las etiquetas de hito en lugar del lenguaje de marketing, esto es lo que el código público nos dice actualmente:

• Versión objetivo: PrestaShop 9.2 (las PR abiertas están marcadas para 9.2.0, no para 9.1).
• Tema: el trabajo visible está ligado a la pila moderna de pago de 9.x. Si los temas classic o personalizados tendrán una ruta de actualización limpia es algo que solo sabremos por las notas de lanzamiento de 9.2.
• Arquitectura: híbrida. AJAX para la inicialización como invitado y la actualización del formulario de dirección; los módulos de pago aún pueden redirigir o usar pasarelas alojadas, como hacen hoy.
• Flujo de invitado: el código actual asocia un cliente invitado válido al carrito antes de enviar el formulario, lo cual tiene sentido; la UX final no está cerrada.
• Alternativa: el proceso de pago actual en varios pasos se mantiene como opción.
• Impacto en módulos: los autores de módulos tendrán que adaptar cualquier cosa que enganche con el flujo de pago. El equipo del núcleo ha sido claro al respecto.

En el momento de escribir esto, el OPC nativo no se ha lanzado en ninguna versión estable. Está detrás de feature flags y en desarrollo activo.

Por qué el diseño del proceso de pago importa de verdad

Baymard sitúa el abandono medio del carrito en torno al 70%. Buena parte de eso son visitas exploratorias que ningún proceso de pago puede salvar, pero el propio desglose de Baymard atribuye el 18% de los abandonos específicamente a un proceso de pago demasiado largo o complicado. Ese es el bloque que un diseño en una página puede mover.

El mecanismo es sencillo: todas las decisiones delante del cliente a la vez, sin cargas de página entre pasos, sin indicador de espera entre "ya he introducido mi dirección" y "qué opciones de envío tengo". En un ordenador de escritorio con conexión rápida, el ahorro es marginal: uno o dos segundos. En una conexión móvil 4G, donde ya vive más de la mitad del tráfico de nuestros clientes, un proceso de pago de cinco pasos puede acumular fácilmente tres o cuatro minutos de espera. Un flujo en una página lo reduce a menos de un minuto.

Lo que vemos en la práctica en las tiendas que migramos: una caída del 10–25% en el abandono del carrito, según la categoría. Moda y electrónica de consumo suelen estar en la parte alta de ese rango. Las tiendas B2B y de ticket medio alto, en la parte baja, porque sus compradores ya estaban más decididos.

Este sigue siendo el aspecto del proceso de pago estándar de PrestaShop.

Capturas de una tienda real de desarrollo en PS9 que mantenemos: datos personales, dirección, envío, pago, todos en pasos separados. El OPC nativo es interesante porque cambia esta estructura, no porque cambie cómo funcionan por debajo los proveedores de pago.

El proceso de pago en una página reúne todas las decisiones en una sola vista.

En paralelo, la diferencia práctica es evidente: el cliente nunca tiene que comprometerse con un paso antes de saber qué le pedirá el siguiente. Por eso hablamos del pago en una página como una función de conversión, no como un ajuste de tema.

Nuestra lectura honesta del OPC nativo

Por lo que muestran las PR, los informes mensuales del núcleo y la Live Update, esta es la imagen realista.

Dónde el OPC nativo va a ser excelente

• Gratis. Se lanza con el núcleo. Sin licencia, sin suscripción, sin clave por tienda. Para muchas tiendas, eso por sí solo lo convierte en la respuesta adecuada.
• Creado por el equipo del núcleo. Encajará limpiamente dentro del flujo de pedidos, el sistema de hooks y la capa de componentes de Hummingbird, sin necesidad de adaptadores.
• Mantenido junto con PrestaShop. Las correcciones de errores y los parches de seguridad llegarán con cada versión de PS. Quien haya dado soporte a un módulo de terceros durante migraciones de PS 1.7 → 8 → 9 sabe lo que eso vale.
• Arquitectura moderna. El trabajo actual usa AJAX donde importa (inicialización de invitado, actualización de dirección) y deja tranquilos los redireccionamientos de pago/3DS/pasarelas alojadas, que es la decisión correcta.
• Identificación del invitado antes en el flujo. Si la implementación llega como está planteada, no tendrás esas sorpresas tardías de "espera, no, corrige tu email" que el proceso de pago actual en varios pasos todavía produce a veces.

Si estás empezando una tienda nueva en PrestaShop 9.2 con Hummingbird, envío estándar, métodos de pago estándar y sin requisitos B2B, el OPC nativo probablemente sea la herramienta adecuada, y lo diremos cuando los clientes nos pregunten. No queremos vender módulos a quienes no los necesitan.

Dónde una función nativa v1 seguirá siendo una función nativa v1

Toda versión "1.0" de una función del núcleo se lanza con un alcance limitado. No es una queja: así ha sido la primera versión de todos los frameworks con los que hemos trabajado. Las limitaciones honestas que conviene tener en cuenta:

• La compatibilidad con temas es realmente una incógnita. El trabajo público está ligado a la pila moderna de pago de 9.x. Si tu tema classic/personalizado actual necesitará una reconstrucción importante es algo que solo sabremos por las notas finales de migración a 9.2. Presupuesta esa reconstrucción como posibilidad.
• Es solo para 9.2. Todo lo que funcione en 1.6, 1.7, 8.x, 9.0 o 9.1 queda fuera. Si no vas a actualizar antes del segundo semestre de 2026, el OPC nativo no estará en tu menú este año.
• Sin pago exprés. El OPC nativo es un formulario en una página. Los botones de Apple Pay / Google Pay / PayPal en páginas de producto y carritos son una función completamente distinta; consulta la sección de pago exprés más abajo. El equipo del núcleo no ha anunciado esto como parte del alcance del OPC.
• Retraso del ecosistema de módulos. Módulos de pago, módulos de envío, personalizaciones de transportistas, módulos de pasos del pago: todos necesitarán actualizaciones. Siempre hay un periodo de transición después de un cambio importante de UX en el núcleo. Tenlo previsto.
• La v1 cubre el camino común. Gestión de campos personalizados, lógica condicional ("ocultar el método de envío X si el cliente está en el país Y"), validación avanzada, restricciones de pago estilo B2B: no son funciones del primer día en ningún proceso de pago de núcleo de primera generación. Tardan años en madurar.

Si mantienes módulos o un tema personalizado, ejecuta primero estos greps

"Carga" no es una comprobación de compatibilidad. Antes de comprometerte a migrar al OPC nativo, localiza todos los puntos donde tus módulos o tu tema tocan el proceso de pago. La versión barata son dos ripgreps:

rg -n "paymentOptions|displayPayment|actionValidateOrder|actionCarrierProcess|displayBeforeCarrier" modules themes
rg -n "checkout/_partials|order-confirmation|cart-summary|payment.tpl|shipping.tpl" themes modules

Cada resultado es un candidato a romperse. Hemos visto módulos de pago que superan la prueba visual básica en el nuevo proceso de pago, pero fallan silenciosamente en un pedido real porque enganchaban marcado antiguo, escuchaban eventos JS antiguos o dependían de una sobreescritura de tema que ya no existe. Haz siempre esta prueba primero en un entorno de pruebas, nunca el primer día del nuevo proceso de pago en la tienda en producción.

Qué te ofrece hoy un módulo de pago maduro

Esta es la parte en la que tenemos que ser cuidadosos, porque Checkout Revolution es nuestro. Nos ceñiremos a los hechos.

Lo que obtienes realmente hoy de un módulo de pago maduro y ya en producción, usando Checkout Revolution como referencia porque es lo que usamos en las tiendas de nuestros propios clientes:

• Funciona en todas las versiones de PS que seguimos soportando. De 1.6 a 9.1, en todos los temas en los que lo hemos probado. Tu proceso de pago deja de depender de la versión de PrestaShop que instalaste en su día.
• Más de 30 métodos de pago en un solo módulo. Apple Pay, Google Pay, PayPal, Klarna, Afterpay, BLIK, Przelewy24, iDEAL, SEPA, Amazon Pay, Link by Stripe y una larga cola de métodos locales. Un módulo que configurar, no 30.
• Pago exprés en tres lugares. Botones de Apple Pay y Google Pay en páginas de producto, en el carrito y dentro del panel desplegable del minicarrito, con autenticación biométrica. El cliente ni siquiera tiene que ver la página de pago.
• Envío dentro de la hoja de Apple Pay / Google Pay. Cuando el cliente elige una dirección en la interfaz del monedero, calculamos las tarifas de envío en tiempo real y las devolvemos a esa misma hoja. No hay "siguiente paso" para el envío.
• Creación automática de direcciones. Las direcciones del monedero (Apple Pay, Google Pay) se guardan directamente en la cuenta del cliente. Sin formulario de dirección para esos compradores.
• Funciones B2B. Cuentas de crédito, flujos de presupuesto/RFQ con salida en PDF, gestión a nivel de empresa, restricciones de métodos de pago por grupo de clientes.
• Análisis de riesgo. Integración con Stripe Radar para puntuación de transacciones.
• Recuperación de carritos. Seguimiento de carritos abandonados sincronizado por webhook, para que puedas recuperar ventas en lugar de limitarte a contarlas.

Esto no es una hoja de ruta. Funciona hoy en tiendas que operamos nosotros mismos (modernedusche.de, douchemoderne.fr, blackdeblacks.de) y procesa transacciones reales. Preferimos que lo sepas y decidas, antes que fingir que la comparación es entre iguales.

Pago exprés: lo que el OPC nativo no es

Esta es la distinción que se pierde en cada conversación de "¿debería esperar al OPC nativo?" que tenemos. El pago en una página y el pago exprés no son la misma función.

Un proceso de pago en una página coloca los campos de dirección, envío y pago en una sola página. El cliente sigue escribiendo su dirección, eligiendo un método de envío e introduciendo los datos de pago. Es más rápido que cinco pasos, pero sigue siendo un formulario.

El pago exprés se salta el formulario. El cliente toca un botón de Apple Pay, Google Pay o PayPal, se autentica con huella o Face ID, y la dirección / el pago / la preferencia de envío se extraen directamente de su monedero digital. Compra de punta a punta, sin escribir un solo carácter. En dispositivos reales vemos que se completa en tres a cinco segundos.

Checkout Revolution incluye el pago exprés dentro del reemplazo completo del proceso de pago. Express Checkout es el módulo independiente y más ligero si lo único que quieres son botones de monedero sin tocar la propia página de pago. Son productos distintos que resuelven problemas distintos: no es una frase de marketing, es la razón por la que los mantuvimos como dos SKU.

El pago exprés es una palanca de conversión completamente aparte.

Página de producto real de PrestaShop, con botón de pago exprés junto a Añadir al carrito. Esto no es "pago en una página dentro de una página de producto": es un flujo distinto en el que algunos clientes se saltan por completo el formulario de pago.

• Página de producto: toca Apple Pay, autentícate con Face ID, pedido realizado. Sin carrito, sin proceso de pago, sin formularios.
• Página del carrito: botones exprés encima del resumen. Toca, autentícate, listo.
• Minicarrito: el panel deslizante del carrito también tiene botones exprés: el cliente nunca abandona la página que estaba viendo.

El OPC nativo, según todos los artefactos públicos que hemos visto, no incluye nada de esto. Es un formulario mejor. El pago exprés en páginas de producto y carrito es una función a nivel de módulo, y no esperamos que llegue al núcleo en la rama 9.x.

Matriz de decisión: ¿OPC nativo, Checkout Revolution o Express Checkout?

Quién debería esperar y quién debería actuar ya

La respuesta honesta depende de dónde estés. Intentamos decirles exactamente esto a los clientes antes de que compren nada.

Espera al OPC nativo si:

• Estás creando una tienda completamente nueva y no la lanzarás hasta que PrestaShop 9.2 sea estable
• Planeas usar Hummingbird v2 desde el primer día
• Tu proceso de pago es realmente estándar: envío básico, métodos de pago comunes, sin B2B
• No necesitas pago exprés en las páginas de producto
• Te parece bien esperar a que los módulos de pago, envío y proceso de pago se actualicen para la nueva estructura

Si la mayoría de esos puntos se cumplen, ahorra tu dinero. El OPC nativo va a ser una respuesta perfectamente válida para ti.

Actúa ya si:

• Tu tienda está activa y hoy pierde carritos por fricción en el proceso de pago
• Estás en cualquier versión de PS entre 1.6 y 9.1, y probablemente no actualizarás en los próximos seis meses
• Usas cualquier tema que no sea Hummingbird v2: classic, personalizado, 1.7, 8.x
• Quieres Apple Pay / Google Pay / PayPal en páginas de producto y carrito
• Necesitas una cobertura amplia de pagos más allá de tarjetas y PayPal
• Vendes B2B y necesitas cuentas de crédito, presupuestos o restricciones de pago por grupo de clientes
• La conversión importa para tu P&L este trimestre, no en 2027

El camino intermedio pragmático

Para la mayoría de las tiendas activas con las que trabajamos, la respuesta es: usa un módulo ahora y vuelve a evaluar el OPC nativo cuando 9.2 esté realmente disponible. Un módulo de pago no es un matrimonio. Si el OPC nativo de 9.2 cubre tus necesidades de forma limpia, podrás cambiar. Lo que no haces es dejar conversión sobre la mesa durante seis a nueve meses mientras esperas una función que aún no se ha lanzado.

E incluso cuando el OPC nativo ya esté en circulación, las cosas que nuestro módulo hace además de "formulario en una página" (pago exprés, la larga cola de métodos de pago, flujos B2B, soporte entre versiones) no desaparecen cuando llega 9.2.

La conclusión, dicho sin rodeos

Que el OPC nativo llegue al núcleo es realmente bueno para PrestaShop. Eleva el punto de partida para todas las tiendas que de otro modo no pagarían por un módulo de pago, y esa es una mejora que queremos ver. No estamos aquí para hablar mal de ello.

Pero el proceso de pago es la página donde se gana o se pierde dinero en cada pedido, y "estamos trabajando en ello para la versión del año que viene" no es un plan para una tienda que está perdiendo carritos hoy. Si tu proceso de pago actual te está costando ventas, las herramientas para arreglarlo ya existen, soportan la versión de PrestaShop que realmente estás usando y cubren terreno que ninguna función v1 del núcleo puede cubrir todavía. Esa es la compensación, explicada con toda la honestidad posible.

FAQ

¿Cuándo se lanzará el proceso de pago nativo en una página en PrestaShop?

PrestaShop ha confirmado a sus socios que el OPC nativo se lanzará como módulo del núcleo en PrestaShop 9.2, actualmente prevista para el segundo semestre de 2026. En el momento de escribir esto, no se ha lanzado en ninguna versión estable: está detrás de feature flags y en desarrollo activo, con las PR abiertas marcadas para 9.2.0, no para 9.1. El calendario de la hoja de ruta es un plan, no una fecha de lanzamiento, así que trata la ventana del segundo semestre de 2026 como movible.

¿Debería esperar al OPC nativo o arreglar mi proceso de pago ahora?

Si estás creando una tienda completamente nueva, no la lanzarás hasta que 9.2 sea estable, planeas usar Hummingbird desde el primer día y tu proceso de pago es realmente estándar, sin B2B y sin necesidad de botones exprés, espera y ahorra tu dinero. Si tu tienda está activa y hoy pierde carritos por fricción en el pago, estás en cualquier versión de 1.6 a 9.1, usas un tema classic o personalizado, o la conversión importa para tu P&L este trimestre, actúa ya. Para la mayoría de tiendas activas, la respuesta pragmática es: usa un módulo ahora y vuelve a evaluar el OPC nativo cuando 9.2 esté realmente disponible. Un módulo de pago no es un matrimonio.

¿El OPC nativo incluirá botones de Apple Pay y Google Pay en las páginas de producto?

No, no según todos los artefactos públicos que hemos visto. El OPC nativo es un formulario en una página: un mejor diseño del proceso de pago. El pago exprés (botones de monedero en páginas de producto y carrito que permiten al cliente saltarse el formulario por completo) es una función separada que el equipo del núcleo no ha anunciado como parte del alcance del OPC, y no esperamos verla en la rama 9.x. Si quieres botones exprés, eso sigue siendo una función a nivel de módulo: Express Checkout por separado, o integrado en Checkout Revolution.

¿El OPC nativo funcionará con mi tema actual?

Es una incógnita real hasta que lleguen las notas de lanzamiento de 9.2. El trabajo público está ligado a la pila moderna de pago de 9.x, así que nadie puede prometer todavía si un tema classic o personalizado tendrá una ruta de actualización limpia, o si necesitará una reconstrucción importante. Si estás planificando en torno a esto, presupuesta la reconstrucción como posibilidad en lugar de asumir que será instalar y listo.

¿Cómo compruebo si el OPC nativo romperá mis módulos?

No confíes en que "carga". Antes de migrar, localiza todos los puntos donde tus módulos o tu tema tocan el proceso de pago: la versión barata son los dos ripgreps de la sección anterior, ejecutados sobre una copia en un entorno de pruebas. Cada resultado para paymentOptions, actionValidateOrder, actionCarrierProcess o una sobreescritura de tema de checkout/_partials es un candidato a romperse. Hemos visto módulos de pago superar la prueba visual básica en un nuevo proceso de pago, pero fallar silenciosamente en un pedido real porque enganchaban marcado antiguo o escuchaban eventos JS antiguos. Nunca lo pruebes por primera vez en la tienda en producción.

Lecturas relacionadas

• Checkout Revolution: nuestro módulo completo de pago en una página
• Express Checkout: botones de monedero sin reemplazar el proceso de pago
• One Page Checkout nativo de PrestaShop 9.2: qué significa específicamente la versión 9.2 para comerciantes y desarrolladores
• Guía de optimización del proceso de pago en PrestaShop: los cambios concretos que mejoran la tasa de finalización mientras decides
• Por qué tu página de pago te hace perder ventas: diagnostica la fuga antes de elegir una solución
• Notas de lanzamiento de PrestaShop 9.1: cambios en Hummingbird y multitransportista