Probamos el One Page Checkout nativo de PrestaShop 9.2: que funciona, que no, y cuando necesitas mas

Probado en julio de 2026 sobre PrestaShop 9.2.0 beta 1.

PrestaShop 9.2 incorpora un One Page Checkout nativo. Para cualquiera que lleve una tienda, eso convierte una vieja certeza en una pregunta real: si el checkout ya viene integrado, ¿sigues necesitando un módulo de checkout?

No queríamos responder a partir de las notas de versión. Así que instalamos la beta 9.2 en un contenedor limpio, activamos el one page checkout nativo y recorrimos todo el flujo con un navegador guiado por script, registrando cada navegación, cada script, cada petición XHR y de documento (los recursos estáticos como imágenes y fuentes quedaron fuera del registro) junto con los tiempos. Este artículo cuenta lo que midieron realmente los instrumentos.

Lo principal antes del detalle: es mejor de lo que esperábamos. Entramos con una sospecha concreta: que introducir una dirección forzaría recargas de página de forma silenciosa y que lo de "one page" sería cierto solo sobre el papel. Esa sospecha era falsa, y lo decimos primero porque era justo lo que más esperábamos encontrar.

No es perfecto, pero las asperezas son menores de lo que informamos al principio. Dos de nuestros hallazgos originales resultaron ser fallos de nuestro propio script de pruebas, y los retiramos más abajo en lugar de dejarlos en pie. Quedan una petición duplicada, algunos atributos de formulario ausentes, un problema de diseño móvil y una decisión de diseño deliberada que quita algo que el checkout antiguo sí hacía.

Antes de nada: nuestro conflicto de intereses

Vendemos módulos de checkout para PrestaShop. Un checkout nativo en el núcleo es, comercialmente, competencia para nosotros. Lee todo lo que digamos al respecto teniéndolo en cuenta.

Así lo hemos gestionado, para que puedas comprobar nuestro trabajo en lugar de fiarte de nuestras intenciones. Cada afirmación de abajo es un número que registramos o una captura que hicimos, sobre una instalación que cualquiera puede reproducir desde una imagen Docker pública. Donde esperábamos encontrar un fallo y no lo encontramos, lo decimos. Donde nuestra primera lectura fue errónea, la corregimos en lugar de quedarnos con la versión que nos favorecía: al principio pensamos que al nuevo checkout le faltaban los códigos de descuento, y no es así. Los pasos de instalación, las versiones exactas y todo lo que no pudimos probar están listados. Si alguna medición no se reproduce en tu caso, dínoslo y lo investigaremos.

Qué probamos exactamente

Cada cifra de abajo procede de este entorno. Si algo no se reproduce en tu caso, puede deberse a tu versión, a tu configuración o a nuestro método, y preferimos enterarnos.

Dos notas de configuración corresponden a la honestidad. Primero, la instalación por defecto no tenía ningún transportista que sirviera al propio país de la tienda, porque el Reino Unido está en la zona "Europa (no UE)" mientras que los transportistas de ejemplo solo cubren otras dos zonas. Asignamos los transportistas a esa zona, lo cual es configuración normal de comerciante y no un problema del checkout. Segundo, los tiempos vienen de una red local: tómalos como una comparación entre los dos checkouts sobre hardware idéntico, no como cifras que tu tienda vaya a reproducir.

Qué es realmente el OPC nativo de 9.2

Llega como módulo, ps_onepagecheckout, incluido en el paquete 9.2. Dos detalles que confirmamos en la instalación conviene conocerlos antes de planificar nada:

• Viene desactivado por defecto. Tras una instalación limpia de 9.2 el módulo está presente y habilitado, pero el ajuste PS_ONE_PAGE_CHECKOUT_ENABLED vale 0. Se activa desde Diseño > Checkout en el back office, y puedes volver al checkout clásico de cuatro páginas cuando quieras.
• Es 9.2 o nada. El módulo declara ps_versions_compliancy con un mínimo de 9.2.0. Una tienda en 1.7, 8.x, 9.0 o 9.1 no puede instalarlo.

Arquitectónicamente hace lo que describe el anuncio oficial en el blog build de PrestaShop. Inyecta su propio proceso de checkout mediante un hook del núcleo en lugar de sobrescribir el controlador de pedidos, y sustituye las cuatro clases de pasos por un único paso combinado. El inicio de sesión y la creación de cuenta se sacaron deliberadamente del checkout a páginas propias. Cubrimos el diseño antes de su lanzamiento en lo que comerciantes y desarrolladores deberían saber sobre el OPC nativo de 9.2. Este artículo sustituye aquellas conjeturas por mediciones.

El benchmark

El one page checkout nativo de 9.2 con la dirección rellenada. Método de envío, método de pago, condiciones y botón de pago están todos en la misma pantalla, y el resumen de la derecha se actualiza en directo.

Misma tienda, mismo producto, mismos datos de dirección, mismos transportistas, cada vez en un carrito nuevo. Los dos recorridos eran equivalentes pero no idénticos acción por acción, porque los dos checkouts no ofrecen las mismas acciones. Las "cargas completas de página" cuentan navegaciones del marco principal desde abrir el checkout hasta la confirmación del pedido.

La misma tienda con el one page checkout desactivado. Tres de los cuatro pasos son inaccesibles hasta que se completa el anterior, y cada paso completado cuesta una carga completa de página.

Valora ese intercambio con honestidad, y ten en cuenta el tamaño de la muestra. Son cinco ejecuciones en una red local, así que tómalas como descriptivas. En particular, la diferencia en el primer pintado queda dentro de la dispersión entre ejecuciones (one page checkout de 152 a 180 ms, clásico de 148 a 188 ms) y no la presentaríamos como una diferencia real. La diferencia en DOMContentLoaded y los recuentos de bytes sí fueron constantes en todas las ejecuciones. El one page checkout tarda unos 50 ms más en llegar a DOMContentLoaded y lleva aproximadamente 28 KB más de JavaScript, porque renderiza contacto, dirección, envío, pago y resumen en un solo documento en lugar de paso a paso. A cambio elimina del recorrido tres cargas completas de página. En cualquier conexión real, tres viajes al servidor menos superan con holgura 50 ms de renderizado local.

Dónde murió la hipótesis de la dirección

Era exactamente lo que queríamos pillar, así que aquí está el desglose en bruto por acción. Cada una se registró con el registro de red del propio navegador.

Añadir una dirección no recarga la página. Editarla no recarga la página. Cambiar de país no recarga la página: reconstruye el formulario de dirección por AJAX, porque cambian los campos obligatorios y el comportamiento fiscal. El cambio de transportista actualizó el total del pedido en directo, de 19,12 EUR a 26,12 EUR, sin ninguna navegación.

La lógica de refresco también es más cuidadosa de lo que suponíamos. Editar la calle, que no puede cambiar un precio de envío, disparó una única petición de guardado de borrador y nada más. Transportistas y opciones de pago solo se volvían a pedir cuando cambiaba algo que realmente les afecta, como el país o la dirección completada. Es un comportamiento sensato, con una salvedad: nuestros transportistas de ejemplo eran de tarifa plana, así que un cambio de código postal no podía alterar el precio. Un transportista que tarifica por código postal necesitaría su propia prueba, porque aquí tanto un cambio de calle como uno de código postal produjeron solo un guardado de borrador.

Lo que hace bien

Reconocerlo como corresponde importa, porque son las partes que los comerciantes van a notar.

• Es de verdad una sola pantalla. Contacto, dirección de envío, método de envío, pago, resumen del pedido y botón de pago están todos en un único formulario desde el primer pintado. No hay bloqueo por pasos ni nada plegado tras un botón de "continuar".
• Los estados de espera se explican solos. Mientras la dirección no está completa, los bloques de envío y pago no se quedan vacíos. Dicen "Completa arriba tu dirección de envío para ver tus opciones de entrega" y luego enumeran exactamente lo que falta: "Todavía se necesita: Nombre, Apellidos, Dirección, Ciudad, Código postal". Es un microtexto inusualmente claro para un checkout por defecto.
• La validación en línea bloquea datos erróneos sin recargar. Con Francia seleccionada (que define un formato de código postal), escribir ABC marcó el campo como inválido, mostró "Código postal no válido, debería ser como "NNNNN"", sustituyó la lista de transportistas por "Corrige los campos de dirección resaltados" y se negó a enviar. Pulsar Pagar produjo cero peticiones de red y devolvió el foco al formulario. No se perdió nada y no se recargó nada. En la prueba aparte en la que vaciamos un campo Ciudad obligatorio, el navegador puso el foco exactamente en ese campo al enviar.
• El botón de pago es honesto. Permanece desactivado mientras falte un consentimiento obligatorio, algo que registramos con un cliente recurrente cuyo transportista y pago ya estaban resueltos pero con la casilla de condiciones sin marcar, y muestra el total actualizado en él mismo. No es un indicador completo de que todo esté listo: con un campo Ciudad obligatorio vacío siguió activo, y fue el navegador y no el checkout quien bloqueó el envío ("Pagar 19,12 EUR", y luego "Pagar 26,12 EUR" tras elegir el transportista de pago).
• Las direcciones guardadas se gestionan sin salir de la página. Para un cliente identificado, la lista de direcciones ofrece "Usar otra dirección de envío", y tanto esa opción como el menú de edición de cada dirección abren una ventana modal en la misma pantalla. Añadir y editar una dirección en pleno checkout nunca lleva fuera de la página.
• Los códigos promocionales están soportados y recalculan en directo. El resumen incluye un acordeón "Código promocional" con un campo "Pega aquí tu cupón". Aplicar un código recalculó el descuento, los transportistas y las opciones de pago por AJAX, sin ninguna recarga. Una cosa que conviene saber: el campo solo aparece cuando la tienda tiene al menos una regla de carrito, porque PrestaShop desactiva la función entera mientras no haya ninguna.
• Los clientes recurrentes tienen un camino realmente rápido. Con la sesión iniciada y una dirección guardada, el formulario del checkout apareció en 193 ms, y la lista de direcciones, ambos transportistas y los tres métodos de pago se resolvieron poco después por AJAX, sin una sola interacción. Completar el pedido requirió dos acciones: marcar las condiciones y pulsar pagar. El campo de correo desaparece por completo para un cliente identificado, exactamente como describe el anuncio.
• El diseño móvil aguanta. A 375 px no hubo ningún desbordamiento horizontal (ancho del documento 375 px, viewport 375 px), y el primer pintado de contenido fue a los 152 ms. Las filas de transportista y la de condiciones tienen áreas táctiles amplias (351x136 px y 327x48 px).

Un código postal francés no válido. El campo se marca en línea, la lista de transportistas se sustituye por un aviso de corrección, y pulsar Pagar no produjo ninguna petición de red.

Un cliente identificado ve sus direcciones guardadas como tarjetas seleccionables, con un menú por dirección y la posibilidad de añadir una nueva.

Añadir una dirección abre una modal sobre el checkout. La página de detrás nunca se recarga y no se pierde nada de lo ya introducido.

La página de confirmación del pedido también se ha rehecho y se ve bastante más limpia que la que sustituye.

Las asperezas que sí medimos

Son cosas que podemos demostrar, no impresiones.

1. El endpoint de métodos de pago se pide dos veces

Cada vez que la dirección se resuelve, el checkout pide sus opciones de pago dos veces con una URL idéntica byte a byte:

GET /module/ps_onepagecheckout/paymentmethods?ajax=1&action=opcPaymentMethods&id_country=17
GET /module/ps_onepagecheckout/paymentmethods?ajax=1&action=opcPaymentMethods&id_country=17

Lo registramos seis veces en cuatro sesiones de navegador independientes: en la primera introducción de la dirección y en un cambio de país en la ejecución como invitado, en la ejecución móvil, en una ejecución con código postal no válido, y tanto en un primer como en un segundo checkout de un cliente identificado. El caso del segundo checkout es el más revelador, porque ocurre en una simple carga de página, sin ninguna interacción por script. Es una petición duplicada, no dos estados distintos. En una tienda donde los módulos de pago hacen trabajo real en cada renderizado (cálculo de comisiones, reglas de disponibilidad, llamadas remotas), eso es tiempo de servidor desperdiciado en la página más crítica para la conversión. Es justo el tipo de cosa que a un módulo 0.6.2 le queda por pulir.

2. Ninguna pista de autocompletado en los campos de dirección

Auditamos todos los campos del bloque de dirección de envío. Ninguno lleva un atributo autocomplete, y ninguno lleva un inputmode:

El autocompletado de direcciones en navegador y móvil se apoya justamente en esos tokens (given-name, address-line1, postal-code y demás). Sin ellos, lo único que más escritura ahorra en el móvil funciona de forma poco fiable, lo que socava un checkout cuyo objetivo declarado es precisamente la fricción móvil. Sabemos que es un descuido y no una decisión, porque la página de registro de 9.2 en la misma plantilla sí pone los tokens correctamente: email, given-name, family-name, new-password y tel-national. El formulario de dirección del checkout, que más los necesitaría, no tiene ninguno. El teléfono al menos usa type="tel", así que ese teclado sí es el correcto.

3. No puedes crear una cuenta mientras compras, y eso es una regresión

El inicio de sesión y el registro se sacaron deliberadamente del checkout, algo que el anuncio dice con claridad. Vale la pena detallar qué significa en la práctica, porque es un paso atrás respecto al checkout al que sustituye.

Comparamos los dos checkouts en la misma tienda. El checkout clásico de cuatro pasos renderiza un <input type="password" name="password"> real dentro del checkout, así que un comprador puede crear una cuenta mientras compra, y su "Iniciar sesión" es una pestaña en la propia página. El one page checkout no tiene ningún campo de contraseña en ninguna parte, y ambos controles son enlaces normales que sacan de la página:

Un cliente que quiera comprar y quedarse con una cuenta tiene por tanto que salir del checkout, registrarse en una página aparte y volver. Para un checkout pensado primero para invitados es una decisión coherente, y quien compra como invitado no lo nota nunca. Para una tienda que depende de las altas de cuenta en el momento de la compra, quita algo que el checkout antiguo sí hacía. También significa que el momento en que un cliente está más motivado para registrarse, justo después de decidir comprar, es el único momento en que el checkout no se lo permite.

4. En móvil el botón de pago queda muy abajo

El one page checkout a 375 px. El diseño aguanta sin desbordamiento horizontal, pero todo el checkout es una única columna muy alta.

Poner todo en una pantalla hace que esa pantalla sea alta. En un viewport de 375 px el botón de pago queda 3337 px más abajo, y no es pegajoso: su posición calculada es static, sin ningún ancestro fixed o sticky. Incluso un cliente recurrente con dirección guardada tiene que recorrer todo el formulario para llegar a él. Un resumen o barra de pago fija es la respuesta habitual, y todavía no está.

5. Es un módulo anterior a la 1.0, y su propio README lo dice

No es un defecto, pero es el dato más importante para planificar de toda la página. El paquete beta que probamos incluye el módulo en versión 0.6.2, mientras que en el repositorio ya se había etiquetado la 0.6.5 unos días antes de nuestra prueba, así que trata los números de versión concretos como un objetivo móvil. Y el propio anuncio de la beta de PrestaShop es inequívoco: "esta versión beta es software previo al lanzamiento. Es posible que encuentres problemas. ¡No la uses en tu tienda de producción!" Tampoco se puede actualizar una beta a release candidate o a estable por la vía normal de actualización.

El repositorio del módulo es aún más directo. El README de PrestaShop/ps_onepagecheckout afirma: "Este módulo está en desarrollo intenso. No está listo para producción y no debería usarse en entornos en vivo." En el momento de escribir esto tiene un puñado de issues abiertas, y dos coinciden exactamente con cosas que encontramos por nuestra cuenta: #94 reporta identificadores de campo duplicados entre la modal de dirección oculta y el formulario en línea, razón por la cual el mismo id #field-postcode aparece más de una vez en la página que auditamos, y #102 describe la pila de casillas de consentimiento que coloca el bloque más pesado en la primera pantalla, justo la fricción que describimos abajo. #132 trata del formulario de dirección que ignora el orden de campos propio de cada país, y #105 es una petición abierta para exponer un contrato de express checkout. Esto último importa si vendes mediante monederos o pagos exprés, porque la superficie a la que se engancharían todavía se está diseñando.

6. Tres casillas de consentimiento obligatorias separan al cliente de las opciones

En una instalación 9.2 por defecto, quien compra por primera vez como invitado se encuentra tres marcas obligatorias: privacidad de datos del cliente, la casilla propia del módulo RGPD y los términos y condiciones. Para un invitado, las dos primeras bloquean las opciones de envío y pago, que permanecen tras un mensaje de "acepta los términos requeridos" hasta que se marcan. Para un cliente recurrente es más suave: medimos que las opciones se resolvían con normalidad quedando solo la casilla de condiciones sin marcar, la cual bloquea el botón de pago y no las opciones. Esa pila es configuración de tu tienda y no culpa del checkout, y se puede quitar, pero es lo que una instalación 9.2 recién hecha le presenta a un primer comprador. PrestaShop tiene una issue abierta justo sobre esto, la #102.

Una corrección: dos hallazgos retirados

Una versión anterior de este artículo incluía otros dos hallazgos. Los dos eran erróneos, y los dos eran culpa nuestra y no del checkout. Lo dejamos aquí por escrito en lugar de borrarlo en silencio.

Informamos de que aplicar un código de descuento reiniciaba el método de envío del cliente y, por separado, de que el checkout podía mostrar un transportista y un total mientras el carrito guardado contenía otro. Ambos venían del mismo error: nuestro script seleccionaba el transportista de forma programática en lugar de pulsarlo, así que la elección nunca llegaba al servidor y cada renderizado posterior mostraba simplemente la versión del servidor.

Lo que lo zanjó fue completar un pedido real y luego leer la fila de la base de datos en vez de fiarnos de la pantalla:

Pulsado como lo haría una persona, el pedido coincide con la pantalla siempre, con y sin cupón. Los códigos de descuento funcionan correctamente: el campo aparece en cuanto la tienda tiene realmente una regla de carrito, y aplicar uno recalcula el descuento, los transportistas y las opciones de pago por AJAX sin recargar. No deberíamos haber publicado ninguna de las dos afirmaciones, y dejamos constancia de la corrección porque un benchmark del que no puedes fiarte para corregirse a sí mismo no merece la lectura.

Lo que no pudimos probar

Decirlo con claridad es la diferencia entre un benchmark y una opinión.

• Pasarelas de pago reales. Probamos solo con métodos offline. Una pasarela de tarjeta, un flujo de monedero o un paso 3D Secure añadirán cada uno su propio traspaso, que puede ser una redirección, una ventana emergente o un marco incrustado. La última navegación que medimos fue el módulo de cheque pasando a su página de validación.
• La plantilla classic. Probamos sobre hummingbird, la plantilla que instala 9.2. El anuncio oficial advierte de que las plantillas classic no están soportadas por defecto y de que "quizá tengas que sobrescribir algunas plantillas del módulo One Page Checkout para que funcione". No completamos una instalación classic limpia y correctamente migrada, así que en ese punto citamos a PrestaShop y no un resultado propio.
• Carga y concurrencia. Mediciones con un solo navegador en una red local. Nada de lo aquí expuesto dice cómo se comportan los endpoints AJAX adicionales bajo tráfico real.
• Módulos de checkout de terceros. No probamos cómo se renderizan los módulos existentes de transporte, comisiones o upsell dentro del flujo one page. Es lo más importante que deberías comprobar en tu propia copia de pruebas.

Reprodúcelo tú mismo

Nada de esto vale mucho si no puedes comprobarlo. Todo el banco de pruebas es una imagen pública y unos diez minutos de configuración. Esta es una versión abreviada del fichero compose que usamos (añade las habituales MYSQL_* y las DB_* correspondientes, y apunta el dominio a donde lo ejecutes):

services:
  prestashop:
    image: prestashop/prestashop:9.2.0-6.0-beta.1-classic-apache
    ports: ["8088:80"]
    environment:
      DB_SERVER: ps92-db
      PS_INSTALL_AUTO: 1
      PS_DEV_MODE: 0          # dejalo DESACTIVADO o todos los tiempos salen inflados
      PS_DOMAIN: localhost:8088
  ps92-db:
    image: mysql:8.0

Y luego cuatro cosas que si no te costarán la tarde, porque a nosotros nos costaron la nuestra:

• Activa el checkout. Viene instalado pero desactivado. Diseño > Checkout, o pon PS_ONE_PAGE_CHECKOUT_ENABLED a 1.
• Dale a tus transportistas la zona correcta. Una instalación por defecto coloca el Reino Unido en "Europa (no UE)" mientras que los transportistas de ejemplo solo sirven otras dos zonas, así que una dirección británica no muestra ningún transportista, y con razón. Son datos de ejemplo, no un fallo del checkout, y estuvimos a punto de reportarlo como tal.
• Prueba la validación del código postal con Francia, no con el Reino Unido. PrestaShop entrega para GB un zip_code_format vacío, así que cuela cualquier disparate y el checkout parece roto sin estarlo. Francia define NNNNN y valida correctamente.
• Para reproducir el caso del cupón necesitas más que la tienda por defecto. El benchmark principal corría con los dos transportistas de ejemplo, pero la prueba del cupón necesita un transportista cuya pérdida se note: añadimos Standard Delivery a 4,90, Economy a 6,90 (gratis por encima de 100) y Express 24h a 12,90, cada uno cubriendo todas las zonas, y luego creamos una regla de carrito del 10% con el código TEST10 y el envío gratis desactivado. Elige el transportista más caro, aplica el código, completa el pedido y compara el método de envío del pedido final con el que habías elegido. Una trampa: el campo del código promocional es invisible hasta que existe al menos una regla de carrito, porque PrestaShop pone PS_CART_RULE_FEATURE_ACTIVE a 0 en una tienda que no tiene ninguna.

Para contar las recargas, abre el panel de Red, filtra por Doc y observa cuántas navegaciones del marco principal obtienes entre abrir el checkout y la página de confirmación. Para la petición duplicada, filtra por paymentmethods.

¿Te basta el OPC nativo de 9.2?

Según lo que medimos, este es el reparto honesto.

El OPC nativo basta de verdad si

• Vas a pasar a 9.2 de todos modos y usas la plantilla hummingbird o una hija suya.
• Tu checkout es estándar: unos pocos transportistas, métodos de pago habituales, sin campos personalizados.
• Vendes a consumidores y el pedido como invitado es la norma.
• Quieres el flujo de cuatro pasos comprimido y un total que se actualiza en directo, que es exactamente lo que ofrece, con cero recargas.
• Te conformas con esperar a la versión 9.2 estable antes de activarlo.

Para esa tienda la respuesta es sencilla: la plataforma ya lo cubre, y no deberías comprar un módulo para hacer lo que hace el núcleo. Si tu checkout está perdiendo pedidos ahora mismo y quieres saber si siquiera es él el problema, empieza por por qué tu checkout te hace perder ventas y las razones por las que la gente se va antes de pagar.

Aun así te chocarás con un muro si

• No estás en 9.2. Este es el punto duro. El módulo se niega a instalarse por debajo de 9.2.0, y las actualizaciones que tocan el checkout son justamente las que los comerciantes posponen. Una tienda en 1.7, 8.x, 9.0 o 9.1 no saca nada de esta versión.
• Necesitas que el propio paso de pago sea un solo toque. El one page checkout elimina la fricción previa al pago. No convierte una pasarela en un botón de monedero. Eso es otra funcionalidad, tratada en checkout rápido y en checkout en un clic en PrestaShop.
• El móvil es la mayor parte de tus ingresos y necesitas una barra de pago fija, o un formulario de dirección que colabore con el autocompletado del teléfono. Ambas son carencias medidas arriba.
• Quieres que los clientes se registren en el momento de la compra. No hay campo de contraseña en el checkout, así que crear una cuenta implica salir de él.
• Necesitas reglas del tipo "este método de pago solo entre importe X e Y". Esa lógica condicional de pagos y transportes no forma parte del módulo nativo.
• Necesitas campos personalizados en el checkout, reglas B2B, upsells a nivel de pedido o selector de fecha de entrega. Nada de eso entra en el alcance del módulo nativo.

Dónde un módulo sigue teniendo sentido

Vendemos módulos de checkout, así que trata este párrafo con el escepticismo que merece y contrástalo con la tabla de arriba. Las carencias que realmente medimos son más estrechas que hace un año, y en una tienda 9.2 estándar el checkout nativo ya hace bien el trabajo de base.

La única carencia que no es cuestión de gustos es el alcance de versiones. El OPC nativo empieza en 9.2, según confirma la propia declaración de compatibilidad del módulo. Nuestro Checkout Revolution existe para llevar un checkout de una página a las versiones de PrestaShop que la mayoría de tiendas en producción ejecutan hoy realmente, sin tocar el núcleo. Consulta en la ficha de producto el rango exacto de versiones soportadas, y ten en cuenta que todavía no lo hemos certificado sobre la propia 9.2. Su historia está en Checkout Revolution 3.0. Si en cambio lo que quieres es comprimir el gesto de pago en sí y no el formulario de encima, eso es Express Checkout, y sigue siendo relevante sea cual sea el checkout que renderice la página. Si estás comparando caminos, la guía de optimización del checkout y el repaso al proceso y las alternativas los ponen en orden.

Si estás en 9.2 con un catálogo estándar y un checkout estándar, te diríamos que uses el nativo. Es lo que respaldan las mediciones.

Preguntas frecuentes

¿Es el one page checkout de PrestaShop 9.2 lo bastante estable para producción?

Todavía no, y PrestaShop lo dice dos veces. El anuncio de la beta 9.2 indica que es software previo al lanzamiento y desaconseja a los comerciantes usarlo en una tienda de producción, y el README del módulo dice: "Este módulo está en desarrollo intenso. No está listo para producción y no debería usarse en entornos en vivo." El propio módulo de checkout está en la versión 0.6.2. Cada pedido que realizamos coincidió con lo que el checkout había mostrado, pero un módulo anterior a la 1.0 sobre una plataforma en beta sigue perteneciendo a un entorno de pruebas hasta que 9.2 sea estable. Tampoco puedes pasar de la beta a la release candidate o a la estable por la vía de actualización estándar, así que prueba sobre una copia desechable.

¿Funciona con mi plantilla?

Está hecho para hummingbird, la plantilla que instala el paquete 9.2 y sobre la que probamos, donde funcionó sin ninguna modificación. El propio anuncio de PrestaShop advierte de que las plantillas classic no están soportadas por defecto y de que quizá tengas que sobrescribir algunas plantillas del módulo para que funcione. No verificamos nosotros mismos el caso de la plantilla classic, así que trata tu plantilla como lo primero que hay que probar en un entorno de pruebas, sobre todo si sobrescribe plantillas del checkout.

¿Sigo necesitando un módulo de checkout?

Si estás en 9.2, usas hummingbird o una plantilla hija y tienes un checkout convencional, entonces honestamente no. El módulo nativo comprime los cuatro pasos en una pantalla, actualiza los totales en directo, valida en línea y completa un pedido en dos acciones para un cliente recurrente. Seguirás queriendo un módulo específico para lo que, según nuestras pruebas, no hace: funcionar en PrestaShop de 1.6 a 9.1, el pago con monedero de un solo toque, campos de checkout personalizados o B2B, upsells a nivel de pedido y refinamientos móviles como una barra de pago fija.

¿Cómo lo activo?

Ve a Diseño > Checkout en el back office y selecciona el diseño de one page checkout. El módulo viene instalado con 9.2 pero el ajuste está desactivado por defecto, así que una instalación nueva te da el checkout clásico de cuatro pasos hasta que lo actives. Puedes volver atrás en cualquier momento, y en una configuración multitienda la elección se hace por tienda y no de forma global.

¿Pueden los clientes usar códigos de descuento en el one page checkout?

Sí. El resumen del pedido incluye un acordeón "Código promocional" con un campo, y aplicar un código recalcula el descuento, los transportistas y las opciones de pago por AJAX sin recargar la página. Inicialmente informamos de que aplicar un código reinicia el transportista elegido por el cliente. Era nuestro script de pruebas seleccionando el transportista de forma programática en lugar de pulsarlo, y hemos retirado esa afirmación: con pulsaciones reales, el pedido final coincidió siempre con el método de envío elegido, con y sin cupón. La única particularidad real es que el campo del cupón permanece oculto hasta que la tienda tiene al menos una regla de carrito, porque PrestaShop desactiva entonces la función por completo.

¿One page checkout significa ninguna redirección?

No, y este es el malentendido más común. En todo el recorrido medimos dos cargas completas de página: abrir el checkout y el traspaso del módulo de pago tras enviar. Todo lo demás, incluido introducir una dirección, editarla, cambiar de país, cambiar de transportista y elegir método de pago, ocurrió sin una sola recarga. Pero un método de pago real todavía puede pasar a una página alojada, a un desafío 3D Secure, a una ventana emergente o a un marco incrustado. Solo medimos el traspaso del módulo de cheque offline, y ese tipo de paso es comportamiento normal del comercio electrónico, no un defecto del checkout.

¿Seguirán funcionando mis módulos de pago y transporte actuales?

Por diseño deberían, porque el checkout nativo usa el mecanismo estándar de PrestaShop para descubrir opciones de pago en lugar de saltárselo, y nuestros tres métodos de pago offline aparecieron y funcionaron sin modificaciones. La salvedad es que ahora todo se renderiza a la vez en una sola pantalla, así que los módulos de transporte que reaccionan a cambios de dirección en directo y los módulos de pago renderizados en un contexto de una sola página son exactamente los puntos donde pueden romperse las suposiciones del flujo por pasos. Ten en cuenta además que el endpoint de opciones de pago se pide actualmente dos veces por cada cambio de dirección, lo cual importa si tus módulos de pago hacen trabajo costoso en cada renderizado.

Fuentes y método de prueba

Fuentes primarias, todas públicas:

• Introducing One Page Checkout in PrestaShop 9.2, el anuncio oficial en el blog build de PrestaShop.
• PrestaShop 9.2 Beta is open for feedback, que recoge la advertencia de versión previa citada arriba.
• PrestaShop/ps_onepagecheckout en GitHub, el código fuente del módulo, su README y su lista de issues abiertas.

Método. Una instalación limpia de PrestaShop 9.2.0 beta 1 desde la imagen Docker oficial, plantilla hummingbird, modo debug desactivado y caché de producción caliente. El recorrido como invitado, el del cliente recurrente y la comparación con el checkout clásico de cuatro pasos fueron guiados cada uno por un navegador con script que registraba navegaciones y peticiones XHR, fetch y de documento, excluyendo recursos estáticos, contando las navegaciones del marco principal por separado de las llamadas AJAX. Los tiempos de carga son la mediana de cinco ejecuciones, con la caché HTTP vaciada antes de cada una. Dos hallazgos de una versión anterior de este artículo se retiraron tras atribuirlos a nuestro propio script, que seleccionaba el transportista de forma programática en lugar de pulsarlo; todos los pedidos realizados con pulsaciones reales coincidieron con lo que mostraba el checkout, verificado en la fila del pedido de la base de datos. Las capturas automáticas usaron viewports CSS de 1440 px y 375 px; las imágenes publicadas se recortaron o redimensionaron para su presentación, pero su contenido no está retocado.

Fechado y provisional. Estas mediciones describen PrestaShop 9.2.0 beta 1 con ps_onepagecheckout 0.6.2, probado el 27 de julio de 2026. Es software previo al lanzamiento en desarrollo activo, así que los fallos que describimos bien pueden estar corregidos cuando 9.2 llegue a estable, y pueden aparecer otros nuevos. Tenemos intención de repetir exactamente este benchmark en la release candidate y de nuevo en la versión estable, y de actualizar este artículo con las nuevas cifras en lugar de dejar las viejas ahí en silencio. Si reproduces algo distinto, dínoslo y lo corregiremos.