Proceso de compra de PrestaShop: el flujo, el módulo y tus mejores opciones

Última actualización: junio de 2026.

"PrestaShop checkout" significa dos cosas distintas: vamos a separarlas

La mitad de los tickets de soporte que recibimos sobre el proceso de compra acaban siendo sobre algo completamente distinto. Está el proceso de compra (el flujo en varios pasos integrado en cada tienda PrestaShop) y está ps_checkout, un módulo de pago específico desarrollado por PrestaShop SA en colaboración con PayPal. Suenan igual. No lo son. Sustituir uno no sustituye al otro.

Lanzamos Checkout Revolution en 2018 porque no conseguíamos que el proceso de compra nativo funcionara correctamente para nuestros clientes, y hemos visto todas las variantes del proceso de compra de PrestaShop rotas en producción: carritos que se vacían en el paso de pago, "no hay ningún método de pago disponible" con cinco módulos activos, redirecciones 3DS que terminan en páginas 404. Este artículo es la versión de la documentación que nos habría gustado tener cuando empezamos a crear módulos para el proceso de compra.

Cómo funciona el proceso de compra de PrestaShop

El flujo predeterminado en varios pasos

Toda tienda PrestaShop incluye el mismo flujo de cinco pasos, repartido en cargas de página separadas:

1. Revisión del carrito, productos, cantidades, totales
2. Información personal, iniciar sesión, registrarse o comprar como invitado
3. Dirección, entrega y facturación
4. Envío, selección del transportista según la dirección, el peso y las dimensiones
5. Pago, método de pago y confirmación del pedido

Después del pago, el cliente llega a la página de confirmación. Esa es la base que heredan todos los temas y a la que se conectan todos los módulos de pago. También es la fricción que nos pagan por eliminar: cinco cargas de página para una sola compra es mucho.

El proceso de compra predeterminado es una secuencia, no un módulo de pago.

Esta hoja de contacto se ha creado a partir de una ejecución limpia del proceso de compra en ps9-dev: producto añadido al carrito, datos de invitado introducidos, dirección guardada, transportista seleccionado y paso de pago alcanzado. Cuando un proveedor de pago falla en el último paso, los pasos anteriores siguen pareciendo correctos; por eso depuramos paso a paso, sin dar nada por supuesto.

Qué cambió entre 1.7 y 8/9

El flujo en sí se ha mantenido. La infraestructura que lo sostiene ha cambiado bastante:

• Arquitectura de temas. Classic sigue usando validación AJAX con mucho jQuery en cada paso. Hummingbird (la alternativa para 8/9) lo reescribió sobre una pila moderna; si sigues en Classic, mantienes código de interfaz del que buena parte del ecosistema ya se ha alejado.
• Hooks de pago. paymentOptions sustituyó a los antiguos displayPayment/displayPaymentEU en 1.7. En 8 y 9, los hooks de pago heredados ya no se ejecutan en absoluto. Cualquier módulo que aún use displayPayment queda invisible en silencio. Lo hemos encontrado más de una vez en tiendas de clientes.
• Migración a Symfony. La gestión de pedidos del back office ya está en Symfony. El OrderController de la tienda sigue funcionando sobre legacy. Los autores de módulos que apuntan a ambos mundos deben saber en qué lado de la línea están.
• Valores CSP más estrictos en 8+. Las cabeceras predeterminadas de Content Security Policy pueden bloquear por completo el JavaScript del proveedor de pago. "Mi proceso de compra se quedó en blanco después de actualizar" casi siempre es esto.
• PHP 8.1+ en PS 9. Cualquier módulo de pago escrito pensando en características de PHP 7 mostrará sus pecados al actualizar.

Si un módulo de pago desapareció después de actualizar a 8 o 9, la forma más rápida de confirmar que el problema es el hook muerto es buscar el antiguo en tu carpeta de módulos. Todo lo que aún registre displayPayment o displayPaymentEU pero nunca paymentOptions no se renderizará en el paso de pago:

# modules that still register a legacy payment hook
grep -rln "displayPayment\b\|displayPaymentEU" modules/*/

# of those, which never register the modern hook?
for d in $(grep -rln "displayPayment" modules/*/); do
  grep -q "paymentOptions" "$d" || echo "NO paymentOptions: $d"
done

Cada línea NO paymentOptions corresponde a un módulo que necesita actualizarse antes de poder aceptar pagos en 8/9. La corrección corresponde al autor del módulo: un hook de pago eliminado del núcleo no puede volver a activarse con un parche. Pero saber qué módulo es el culpable convierte "el proceso de compra está roto" en un problema concreto y resoluble.

El OrderController y cómo se ejecuta

El proceso de compra lo dirige controllers/front/OrderController.php. Carga el carrito, ejecuta hooks y recorre un objeto CheckoutProcess que contiene cada paso como una clase propia (CheckoutAddressesStep, CheckoutDeliveryStep, CheckoutPaymentStep, todas heredando de AbstractCheckoutStep).

Esa estructura modular está realmente bien diseñada: los módulos pueden sobrescribir un paso sin reemplazar todo el flujo. La pega es que "bien diseñada" no significa "fácil de razonar". Cuando cinco módulos modifican un paso distinto cada uno, depurar lleva tiempo. Todos los problemas del proceso de compra que hemos corregido han empezado leyendo OrderController de principio a fin.

Qué ocurre en cada paso

Detrás de cada paso se ejecutan validaciones y hooks que los módulos usan para ampliar el proceso:

• Validación de dirección. Campos obligatorios, combinaciones país/provincia, recálculo de reglas fiscales según el país de entrega.
• Selección de transportista. Transportistas disponibles filtrados por zona, peso, dimensiones y restricciones. actionCarrierProcess es el hook en el que intervenir.
• Renderizado del pago. Cada módulo de pago activo se registra mediante paymentOptions y el orden de renderizado es el que configures en Pago > Preferencias.
• Validación del pedido. actionValidateOrder se ejecuta en la confirmación: pago, decremento de stock, correos, creación de la fila del pedido, todo el conjunto.

Esto es lo que hace extensible el proceso de compra. También es la razón por la que dos módulos mal escritos pueden interferir entre sí y producir errores que nadie puede diagnosticar sin `var/logs/` en una mano y la base de datos en la otra.

Por qué tu proceso de compra es lento

Un proceso de compra lento cuesta dinero. Cada segundo de carga cuesta conversiones. Cuando auditamos el rendimiento del proceso de compra, los cuellos de botella casi siempre son uno de estos:

• Demasiados módulos en hooks del proceso de compra. Hemos visto tiendas con más de 15 módulos ejecutándose en displayPayment, displayBeforeCarrier, actionCarrierProcess. Cada uno añade milisegundos. Juntos añaden segundos.
• Llamadas a API externas. Tarifas en tiempo real de UPS/FedEx, cálculo fiscal de TaxJar, verificación de direcciones: cualquiera de estas llamadas puede frenar todo el proceso de compra cuando el servicio externo falla.
• Configuraciones de transportistas descontroladas. Decenas de transportistas con reglas de zona/peso solapadas obligan a PrestaShop a hacer consultas largas en cada renderizado del paso de entrega.
• Exceso de reglas de carrito. Cientos de reglas de carrito activas significan cientos de evaluaciones por carrito. Las reglas caducadas deben eliminarse, no desactivarse.
• Índices ausentes en tablas de reglas de carrito y precios específicos. En tiendas que llevan años funcionando, estas tablas son enormes y a menudo no tienen los índices adecuados.
• Sin OPcache, sin Redis. No necesita mucha explicación. Si en 2026 sigues usando sesiones en archivos y OPcache desactivado, el resto de este artículo no te salvará.

Para encontrar al culpable en una copia de preproducción, activa el profiler:

// staging only
define('_PS_DEBUG_PROFILING_', true);

Nunca dejes eso activado en producción. Haz una compra de prueba, lee la tabla del profiler; el módulo más lento suele verse antes de necesitar logs más profundos. Lo aprendimos por las malas en una tienda de un cliente en la que un módulo de conversión de divisas se comía 1,8 segundos por renderizado del proceso de compra.

Los errores del proceso de compra que vemos con más frecuencia

"No hay ningún método de pago disponible." El error más buscado en Google. Significa que ningún módulo de pago devolvió nada desde paymentOptions. Los sospechosos habituales:

• Una restricción de divisa o país excluye el carrito del cliente
• Pago > Preferencias excluye el transportista, el país o el grupo de clientes actuales
• El módulo de pago tiene un error PHP y falla en silencio: revisa var/logs/
• En PS 8+, las cabeceras CSP están bloqueando el JavaScript del módulo

Normalmente es un desajuste de configuración, no un problema del tema.

En el proceso de compra de PS9 capturado, carrito/dirección/transportista funcionaban, pero el paso de pago volvió vacío. La matriz del back office lo delataba: los módulos de pago nativos estaban restringidos a un país distinto de Francia, que era el del carrito de prueba.

Pago > Preferencias es el primer lugar donde mirar.

Las restricciones de divisa, grupo de clientes, país y transportista deciden si un módulo llega a aparecer en el proceso de compra. Un módulo de pago instalado y activo puede seguir siendo invisible para el cliente si alguna restricción excluye el contexto actual del carrito.

"Se ha producido un error al procesar tu pedido." El mensaje más genérico que trae PrestaShop. Empieza por la excepción real en el log de errores de PHP y en los logs de PrestaShop. Después revisa la disponibilidad de stock (si un producto se queda sin stock entre el carrito y el pago, el pedido falla) y los conflictos de reglas de carrito (un vale no válido puede contaminar silenciosamente la validación final).

El carrito se vacía durante el proceso de compra. Siempre es un problema de cookies o sesión. Mala configuración SSL, dominios de tienda/SSL no coincidentes, partición de sesión llena o (y hemos visto esto llegar a producción) un módulo que llama a Context::getContext()->cart = new Cart() dentro de un hook del proceso de compra y reinicia el carrito por accidente. Si sospechas de un módulo, desactívalos uno a uno hasta que el proceso de compra empiece a comportarse.

Fallos de validación de dirección. Provincia/región obligatoria en un país que el cliente no vio, cadena de formato de dirección mal formada o una regex de código postal demasiado estricta. Internacional > Ubicaciones > Países es donde debes mirar.

Fallos de redirección 3DS. El cliente se autentica pero aterriza en una página de error o nunca vuelve. Causas: la URL de retorno es HTTP y no HTTPS, la sesión caducó durante 3DS, la URL de callback no es accesible desde el banco o una configuración multidominio en la que la URL de retorno 3DS apunta a un dominio distinto del que usaba el cliente para comprar.

Reglas de carrito y descuentos: la capa que se rompe al final

La lógica de descuentos es la parte del proceso de compra que confunde por igual a comerciantes y desarrolladores. Las reglas de carrito (vales, promociones, descuentos automáticos) y los precios específicos a nivel de producto interactúan de formas que no siempre son intuitivas.

• Las reglas de carrito se evalúan por orden de prioridad: algunas se aplican a todo el carrito, otras a productos o categorías concretos.
• Los precios específicos se aplican antes de las reglas de carrito. Un producto que ya está rebajado puede no cumplir las condiciones para descuentos adicionales.
• Las restricciones de acumulación permiten marcar reglas como no combinables, pero la lógica de "cuál gana" no es evidente en tiendas multidivisa.

Las reglas de carrito no son solo códigos promocionales.

La lista real del back office de ps8-dev muestra la prioridad, el código, el límite de cantidad, la caducidad y el estado activo de cada regla de carrito. Cuando los descuentos se comportan de forma extraña durante la compra, empezamos por esta lista antes de culpar al módulo de pago.

Reglas de carrito con envío gratuito y cómo interactúan con los transportistas

Una regla de carrito de "envío gratuito" no hace gratuitos todos los transportistas. Si la regla no está restringida a transportistas concretos, se aplica al que elija el cliente. Si está restringida a ciertos transportistas, solo esos bajan a cero; los demás siguen mostrando su precio normal. Las restricciones de país y zona de la regla de carrito la acotan aún más. Si se aplican varias reglas de envío gratuito, se usa la válida con mayor prioridad y el resto se descarta en silencio.

La trampa de la prioridad y la acumulación

La prioridad importa más de lo que cree la mayoría de comerciantes. Un caso habitual:

• Regla A (prioridad 1): 20% de descuento en todo el carrito, no combinable
• Regla B (prioridad 2): envío gratuito a partir de 50 EUR

Como la Regla A no es combinable y va primero, la Regla B nunca se aplica. El cliente recibe un 20% de descuento y aun así paga el envío. O haces que la Regla A sea combinable, o incorporas el envío gratuito directamente en la Regla A.

Otro clásico: un cliente introduce un vale de 10 EUR, pero el carrito ya tiene un descuento automático del 15% que no es combinable. PrestaShop rechaza el vale con un inútil mensaje de "no válido". Hemos reconstruido la lógica de reglas de carrito para clientes más de una vez porque era más fácil que explicárselo al equipo de soporte.

Importe mínimo en reglas de carrito

La comprobación del importe mínimo se ejecuta antes o después de otros descuentos según la configuración, y puede incluir o excluir impuestos y envío. Resultado: un carrito de 110 EUR antes del descuento pero de 95 EUR después puede superar o no una regla de "mínimo 100 EUR". Prueba siempre las reglas de importe mínimo con escenarios reales de carrito en varios países antes de ponerlas en producción.

Compra como invitado frente a creación de cuenta

La compra como invitado es una opción de pedidos, no de pago: Parámetros de la tienda > Configuración de pedidos en PS 8. La activamos en casi todos los clientes B2C porque obligar a crear una cuenta mata la conversión móvil. B2B es la excepción: compras basadas en cuenta, historial de pedidos recurrentes y facturación correcta suelen pesar más que la fricción de un formulario.

La compra como invitado vive en Configuración de pedidos.

Esta captura de ps8-dev muestra el interruptor real Activar compra como invitado. Desactivarlo cambia el primerísimo paso del proceso de compra antes de que ningún transportista o módulo de pago entre en juego.

El módulo ps_checkout: qué es en realidad

Qué hace ps_checkout (y qué no hace)

El módulo PrestaShop Checkout (nombre técnico ps_checkout) es un módulo de pago gratuito desarrollado conjuntamente por PrestaShop SA y PayPal. Viene preinstalado en todos los PrestaShop desde la versión 1.7.5.

Esta es la distinción con la que tropiezan a diario los comerciantes: ps_checkout es un módulo de pago, no el flujo de compra. No cambia los pasos, el diseño, el orden de los campos ni ninguna otra parte de cómo PrestaShop guía al cliente durante la compra. Solo renderiza opciones de pago en el paso de pago. Cualquiera que te venda "pago en una página mediante ps_checkout" no ha leído el README del propio módulo.

Qué ofrece

Para ser gratuito, la lista de funciones es razonable:

• Pagos con tarjeta (Visa, Mastercard, AmEx) mediante campos alojados por PayPal
• Monedero PayPal
• Apple Pay y Google Pay donde estén disponibles
• Métodos locales: iDEAL, Bancontact, BLIK y otros según el mercado
• Pay Later / Pay in 3-4 (PayPal BNPL)
• 3DS2
• Más de 20 divisas a través de la red de PayPal

Código fuente completo en el repositorio de ps_checkout en GitHub.

Comisiones por transacción

El módulo es gratuito. El procesamiento no. Trata cualquier comisión citada como un ejemplo específico de mercado: PayPal, Stripe, Mollie y Adyen varían según el país del comerciante, el origen de la tarjeta, el método, la divisa, el volumen y el perfil de riesgo. Pide una oferta por escrito para tu propio país de comerciante antes de comprometerte.

Referencias de precios, última comprobación en mayo de 2026: Stripe France, Mollie, Adyen, PayPal UK. Usa la página equivalente para tu país de comerciante.

Comparar proveedores de pago: las comisiones no lo son todo

Hemos visto a comerciantes elegir proveedor por una diferencia de 0,3 EUR por pedido y luego perder clientes en el paso de pago porque no ofrecían el método local en el que esos clientes confían. La tasa de autorización, la cobertura de pagos locales, el flujo de reembolsos, la calidad del soporte y la facilidad de depuración en el back office importan al menos tanto como el porcentaje anunciado.

ps_checkout frente a Stripe y Mollie de un vistazo

Instalar y configurar ps_checkout

Instala el módulo (preinstalado en tiendas nuevas; si no, desde Addons), vincula una cuenta de PrestaShop Addons, conecta tu cuenta PayPal Business mediante el asistente de configuración inicial (las cuentas personales de PayPal no son compatibles, y eso confunde a mucha gente), elige qué métodos de pago ofrecer, comprueba que los ajustes de redondeo/divisa coinciden con lo que espera PayPal y prueba en el entorno de pruebas antes de pasar a producción. Nosotros hacemos siempre al menos un pedido de prueba por cada divisa en la que vende la tienda.

La configuración combina alta de cuenta y configuración de pagos.

El módulo puede estar instalado sin que la experiencia de pago esté completa. Cuenta de PrestaShop vinculada, cuenta business de PayPal asociada, redondeo compatible y al menos un pago de prueba o real confirmado desde el proceso de compra: solo entonces está terminado.

Desinstalar ps_checkout

Módulos > Gestor de módulos, busca ps_checkout, primero Desactivar (seguro: lo detiene sin perder datos). Para eliminarlo por completo, Desinstalar y, opcionalmente, borra modules/ps_checkout/. Asegúrate antes de tener configurado otro módulo de pago o tu tienda mostrará "No hay ningún método de pago disponible" en la siguiente compra.

La arquitectura intermediaria (y por qué importa)

Aquí es donde ps_checkout se diferencia de una integración directa. Stripe, Mollie y Adyen liquidan los pagos directamente en tu cuenta de comerciante. ps_checkout los encamina a través de la cuenta de plataforma de comercio PayPal de PrestaShop SA: PrestaShop SA es el facilitador de pagos.

Qué cambia esto en la práctica:

• Vinculas tu cuenta business de PayPal mediante el flujo de PrestaShop, no directamente con PayPal
• El calendario de liquidación depende tanto de las políticas de PayPal como de la configuración de plataforma de PrestaShop SA
• Los contracargos pasan por una capa adicional: las disputas tardan más en resolverse
• Los datos brutos de transacción son menos visibles que en una pasarela directa

No es malo por naturaleza: Shopify Payments funciona igual. Pero para comerciantes de alto volumen o regulados, añade una complejidad operativa que conviene conocer antes de comprometerse.

Las limitaciones que seguimos viendo

A partir de incidencias en GitHub, foros de la comunidad y tickets de soporte que nos han traído clientes:

• Compatibilidad con temas. ps_checkout funciona mejor en Classic. Los temas muy personalizados rompen con frecuencia el renderizado de los campos de pago alojados.
• El spinner infinito. El formulario de pago nunca termina de cargar. Normalmente es un conflicto JavaScript con otro módulo o una cabecera CSP que bloquea los scripts de PayPal.
• Errores 3DS poco útiles. Cuando 3DS falla, el cliente ve un mensaje genérico que no le ayuda a intentarlo de nuevo: abandono que podría haberse recuperado con un texto más claro.
• Sin soporte directo. La ayuda llega por canales comunitarios. Para tiendas que están perdiendo dinero durante una caída de pagos, esta es la parte que más duele.
• Riesgo de actualización. Las versiones mayores han introducido cambios incompatibles. Ritmo rápido de funciones, actualizaciones frágiles. Prueba en preproducción cada vez.

Ninguna de estas limitaciones es decisiva por sí sola. Juntas explican por qué siempre probamos las actualizaciones de ps_checkout primero en una copia de preproducción.

Cuándo tiene sentido ps_checkout

A pesar de todo lo anterior, es una opción inicial razonable para:

• Tiendas nuevas que necesitan aceptar pagos mañana sin coste inicial
• Tiendas de un solo mercado sin requisitos complejos de liquidación multidivisa
• Comerciantes con presupuesto ajustado que prefieren pagar por transacción antes que comprar módulos
• Catálogos simples: sin suscripciones, sin preventas, sin flujos de pago exóticos

Personalizar el proceso de compra de PrestaShop

Qué puedes cambiar sin módulos

Antes de añadir código de terceros, hay varias cosas que pueden modificarse con herramientas integradas:

• Plantillas del tema. Edita las plantillas Smarty del proceso de compra en tu tema hijo: diseño, orden de campos, contenido personalizado entre pasos.
• CSS. Colores, espaciado, botones, tipografía. Alineación con la marca sin tocar la lógica.
• Configuración de transportistas. Nombres de transportistas, descripciones, estimaciones de entrega, orden de visualización.
• Orden de módulos de pago. Pago > Preferencias controla qué método aparece primero.
• Campos obligatorios. Clientes > Direcciones controla qué campos son obligatorios.

Todas son personalizaciones seguras que sobreviven a las actualizaciones de PrestaShop si usas un tema hijo, que deberías usar. Para profundizar más, nuestra guía de optimización del proceso de compra entra en detalle.

El formato de direcciones está integrado en PrestaShop.

El editor de países controla qué campos aparecen y en qué orden. Importa en el proceso de compra porque el país de entrega determina la validación, las reglas de código postal, la zona fiscal y la disponibilidad de transportistas.

Campos personalizados en el proceso de compra

La mayoría de los comerciantes con los que trabajamos acaban necesitando campos que PrestaShop no recoge por defecto. Móvil para notificaciones por SMS, nombre de empresa y número de IVA para B2B, códigos de acceso e instrucciones de entrega tipo "dejar con el vecino", referencias de pedido personalizadas para compras B2B.

El formulario de direcciones del back office (Clientes > Direcciones) cubre lo básico. Para cualquier cosa más compleja necesitarás un módulo personalizado enganchado a actionValidateOrder o un módulo de campos para el proceso de compra de Addons. Ambos sirven: elige el que encaje con el nivel de comodidad de tu equipo con PHP.

Traducir el proceso de compra

Si vendes internacionalmente y tu proceso de compra muestra errores en inglés en una tienda francesa, estás perdiendo pedidos. Los clientes no pagarán por algo que no entienden.

Las piezas que debes traducir:

• Etiquetas de pasos. Internacional > Traducciones > Traducciones de la tienda, tu tema.
• Cadenas de módulos de pago. Cada módulo de pago tiene sus propios archivos de traducción, separados del núcleo.
• Mensajes de error. "Introduce una dirección válida" y compañía: las cadenas que aparecen en el peor momento posible.
• Términos y condiciones. La casilla "Acepto" enlaza a una página CMS que debe existir en todos los idiomas.
• Etiquetas del formulario de dirección. Los formatos específicos por país deben coincidir con el idioma del cliente.

La trampa clásica: instalar un paquete de idioma no traduce las cadenas de los módulos. Hemos entregado siete traducciones multitienda para nuestros clientes y esta trampa atrapa a todo el mundo la primera vez.

Busca la cadena del proceso de compra y edita el dominio del tema.

Esta pantalla de traducciones de ps8-dev filtrada por checkout muestra cadenas de Shop > Theme > Actions. El mismo flujo se aplica a cada etiqueta, botón y mensaje de la tienda que aparece durante el proceso de compra.

Proceso de compra en una página

La personalización del proceso de compra más solicitada. Cinco cargas de página separadas se condensan en una sola página donde los campos de dirección, envío y pago son visibles a la vez.

La razón por la que funciona no tiene nada de mágica: elimina fricción de navegación y mantiene visible todo el contexto del pedido. La mejora de conversión varía: fuente de tráfico, mezcla de dispositivos, complejidad del envío, métodos de pago y cantidad de campos obligatorios importan. No afirmamos un porcentaje fijo. Sí vemos de forma constante menos abandonos en analítica después de activar un proceso de compra en una página en una tienda de cliente. Trátalo como un experimento, no como una promesa universal de "X% mejor".

Desde el punto de vista UX: todos los campos visibles a la vez, costes de envío actualizados por AJAX, validación inline mientras el cliente escribe, sin indicador de progreso necesario y resumen del pedido persistente. Bien hecho, resulta sensiblemente más tranquilo que un flujo en varios pasos.

PrestaShop no tiene hoy un proceso de compra nativo en una página. La hoja de ruta lo lista para PrestaShop 9.2 junto con Hummingbird v2, pero será opcional y el flujo en varios pasos no desaparecerá. Hasta entonces, la respuesta es un módulo.

Este es el territorio de Checkout Revolution: lo construimos porque todas las alternativas parecían anticuadas, se rompían en Hummingbird o apilaban otros cuatro módulos encima para funcionar. Es nuestro producto insignia, y creemos sinceramente que es el mejor proceso de compra en una página del mercado para PrestaShop. Lo diríamos incluso si no lo hubiéramos creado nosotros.

La diferencia estructural, lado a lado.

Izquierda: el flujo predeterminado en varios pasos de PrestaShop 9 en ps9-dev. Derecha: Checkout Revolution en ps178-dev: contacto, envío, pago y resumen del pedido visibles en una sola página.

Compra exprés: algo completamente distinto

La compra exprés suele confundirse con el proceso de compra en una página. No es lo mismo.

Proceso de compra en una página = sustitución completa del flujo en varios pasos. Compra exprés = botones de monedero (Apple Pay, Google Pay, PayPal Express, Link) en la página de producto y en el carrito que omiten todo el proceso de compra. El cliente toca Apple Pay en la página de producto, se autentica con Face ID y el pedido queda realizado. Sin formulario de dirección, sin selector de transportista, sin paso de pago: el monedero aporta todo.

Esto no sustituye al flujo de compra. Es un punto de entrada alternativo. En móvil, donde cada campo del formulario de dirección mata conversiones, es lo más impactante que podemos añadir a una tienda de cliente. Lo vendemos como producto propio: Express Checkout. Para tiendas que quieren ambas cosas (botones de monedero y proceso de compra en una página), Checkout Revolution las agrupa.

La compra exprés empieza antes de la página del carrito.

Esta página de producto de ps178-dev muestra un botón real de Express Checkout justo junto a los controles de compra del producto. Según proveedor, navegador, país y elegibilidad del monedero, el botón visible puede ser un botón exprés genérico o uno específico de Apple Pay, Google Pay, PayPal o BNPL.

Proceso de compra integrado y modal

Un patrón menos común: el formulario de pago aparece en un modal o en línea en la página actual, sin navegar a una URL separada del proceso de compra. Stripe Payment Element y el flujo contextual de PayPal lo soportan. La distancia psicológica entre "quiero esto" y "lo he comprado" se acorta. Usamos este enfoque en Checkout Revolution cuando el comerciante quiere la reducción de fricción más agresiva posible.

Alternativas a ps_checkout

Si ps_checkout no encaja, estas son las opciones maduras para procesar pagos en PrestaShop:

Stripe

Payment Element de Stripe es la integración de pagos más amable para desarrolladores del mercado. Lo usamos por debajo en Checkout Revolution porque nos da la cobertura de métodos más amplia con la API más limpia.

• Cuenta de comerciante directa: sin intermediario en la liquidación
• Más de 135 divisas, FX automático
• Apple Pay, Google Pay, Link, más de 40 métodos locales
• La mejor documentación de API en pagos
• Stripe Radar para protección antifraude

Mejor para: tiendas internacionales, equipos técnicos y cualquiera que quiera control total sobre sus datos de pago.

Mollie

Un proveedor de pagos europeo con gran cobertura en Países Bajos, Bélgica, Alemania y Francia.

• Precios por transacción, sin cuotas mensuales
• iDEAL, Bancontact, SOFORT, EPS, Giropay, KBC/CBC nativos
• Módulo sólido de PrestaShop mantenido por la propia Mollie
• Alta rápida

Mejor para: tiendas de la UE, especialmente Benelux o DACH, donde dominan los métodos locales.

Compra ahora, paga después: Klarna, Alma, Clearpay/Afterpay

BNPL merece añadirse cuando el tamaño del carrito es lo bastante alto como para que fraccionar el pago cambie la decisión de compra. En PrestaShop casi siempre se añade mediante un proveedor de pago o un módulo dedicado, no a través de ajustes del proceso de compra del núcleo.

• Klarna, DACH, países nórdicos, Reino Unido y pilas europeas más amplias. Pay later, Pay in 3/4, financiación o exprés según la integración.
• Alma, fuerte en Francia y el sur de Europa para pagos a plazos en carritos más altos.
• Clearpay/Afterpay, mercados donde opera Afterpay, incluido el Reino Unido como Clearpay.

La pega: las comisiones BNPL son más altas que el procesamiento con tarjeta, y el comerciante asume carga operativa de disputas/reembolsos. Comprueba la elegibilidad por país y el calendario de liquidación (por adelantado o diferido) antes de activarlo.

Métodos de pago locales por mercado

Si vendes en Europa, la cobertura de pagos locales puede importar tanto como el precio de las tarjetas. Los clientes confían en el método que ya usan con su banco o monedero móvil. Proveedores como Stripe y Mollie pueden mostrarlos dinámicamente, pero solo si tu módulo de PrestaShop, divisa, restricciones de país y cuenta del proveedor están configurados para ello.

Para el soporte actual de métodos, consulta métodos de pago de Stripe, métodos de pago de Mollie y el aviso de retirada de Giropay de Stripe.

Adyen

La opción enterprise. Usada por Booking.com y eBay, más de 250 métodos de pago, enrutamiento inteligente, detección de fraude RevenueProtect y acquiring directo: Adyen es procesador y adquirente a la vez, eliminando intermediarios.

La contrapartida es complejidad y coste. Para comerciantes de alto volumen, Adyen suele salir ganando. Para todos los demás, Stripe, Mollie o ps_checkout te pondrán en marcha más rápido y con menos conversaciones comerciales y técnicas.

Amazon Pay

Los clientes compran usando su cuenta de Amazon existente: dirección, pago y todo lo demás. Compra en un toque con los datos guardados en Amazon y protección del comprador A-to-Z. Hay un módulo de PrestaShop en Addons. Funciona bien como opción secundaria junto a tarjetas y PayPal, peor como opción principal.

Módulo PayPal independiente

Si quieres PayPal sin la capa intermediaria de PrestaShop SA, un módulo independiente se conecta directamente a tu cuenta business de PayPal. Obtienes control directo sobre liquidaciones y gestión de disputas, la misma experiencia de monedero PayPal que conocen los clientes y Pay Later configurado desde tu propio panel de PayPal.

Mejor para: comerciantes que quieren PayPal, pero prefieren una relación directa con PayPal en lugar de una facilitada.

Transferencia bancaria: la opción sin comisiones que la gente olvida

Es fácil descartarla porque no es un monedero ni un formulario de tarjeta. Aun así, sigue siendo útil en la tienda adecuada. El módulo nativo ps_wirepayment muestra tus datos bancarios durante el proceso de compra y permite al cliente realizar un pedido sin ninguna pasarela de tarjeta.

El argumento comercial es sencillo: sin comisión de pasarela, sin comisión de esquema de tarjeta, sin calendario de pagos de intermediario. Para B2B, productos bajo pedido, cuentas mayoristas, carritos de alto valor y mercados donde la transferencia bancaria es culturalmente normal, eso resulta realmente atractivo.

El coste operativo es la conciliación. Los fondos no se confirman al instante, los clientes salen de tu sitio para completar el pago en su aplicación bancaria y alguien de tu equipo tiene que casar las transferencias entrantes con los pedidos antes de preparar el envío. Lo hemos configurado para clientes B2B y el coste del día 2 es "diez minutos de contable cada mañana". Merece la pena para la tienda adecuada.

Referencia: PrestaShop ps_wirepayment.

Checkout Revolution (sí, el nuestro)

Transparencia total: Checkout Revolution es nuestro producto insignia y, obviamente, creemos que es la respuesta adecuada para la mayoría de tiendas que han superado el proceso de compra nativo. Combina proceso de compra en una página y botones exprés en un único módulo impulsado por Stripe. Botones de compra en la página de producto, carrito y proceso de compra. Apple Pay, Google Pay, PayPal, Link, tarjetas y más de 30 métodos adicionales mediante Payment Element de Stripe. Los pagos van directamente a tu cuenta Stripe.

Lo construimos porque los clientes seguían instalando tres o cuatro módulos separados para obtener una funcionalidad que debería venir junta. Si quieres proceso de compra en una página, botones exprés y una pila moderna de pagos de un solo proveedor con un único contrato de soporte, esto es lo que recomendaríamos. Si solo necesitas una solución rápida de PayPal para una tienda nueva, ps_checkout hará el trabajo por menos dinero.

Comparación rápida

Seguridad del proceso de compra y cumplimiento PCI

Esta no es la sección que conviene saltarse. Los clientes confían a tu tienda los datos de su tarjeta. Una brecha te cuesta dinero, clientes y posicionamiento, en ese orden.

Qué significa realmente PCI DSS para tu tienda

PCI DSS se aplica a cualquier negocio que acepte, procese, almacene o transmita información de tarjetas. Tu carga de cumplimiento depende por completo de cómo maneje tu proceso de compra los datos de tarjeta:

• SAQ A (carga más baja). Campos de pago alojados o redirección: los datos de tarjeta nunca tocan tu servidor. Aquí es donde te sitúan ps_checkout, Stripe Payment Element y el proceso de compra alojado de Mollie. Apunta aquí.
• SAQ A-EP. El JavaScript del proveedor de pago se ejecuta en tu página y captura datos de tarjeta, aunque se envíen directamente al proveedor. Carga ligeramente mayor.
• SAQ D (carga más alta). Los datos de tarjeta pasan por tu servidor en algún momento. Los formularios de pago personalizados que hacen POST de números de tarjeta a tu tienda antes de reenviarlos caen aquí. Caro, complejo y casi nunca la opción adecuada. Evítalo.

Usa módulos de pago con campos alojados o páginas de proceso de compra alojadas. Confirma el SAQ exacto con tu proveedor o adquirente, porque los detalles de implementación importan y nosotros no somos tu QSA.

Campos de pago alojados, no entradas de tarjeta en bruto

Los campos de pago alojados son iframes servidos por el proveedor de pago e incrustados en tu página de proceso de compra. El número de tarjeta, la caducidad y el CVV parecen parte de tu formulario, pero se ejecutan en el dominio del proveedor: tu servidor nunca toca los datos de tarjeta. Todos los grandes proveedores lo soportan. Si un módulo te pide añadir campos HTML de tarjeta en bruto a tu tienda, aléjate. Es una señal roja PCI y una pesadilla de mantenimiento.

SCA, 3DS2 y SSL

SCA en la UE exige 3DS2 para la mayoría de pagos con tarjeta. Tu módulo de pago debe soportarlo: cualquier cosa solo 3DS1 verá aumentar las tasas de fallo y acabará dejando de funcionar. 3DS2 añade un paso de autenticación que puede perjudicar las tasas de finalización, así que elige un proveedor con altas tasas de éxito en 3DS2 y no muestres errores genéricos cuando falle la autenticación. "Inténtalo de nuevo" gana a "se ha producido un error" siempre.

Todas las páginas del proceso de compra deben ser HTTPS. Sin un certificado válido, los navegadores se niegan a cargar campos alojados, Google penaliza el posicionamiento y los avisos de "No seguro" asustan a los clientes. Let's Encrypt es gratis. Después de instalarlo, verifica que todo HTTP redirige a HTTPS: el contenido mixto romperá módulos de pago en silencio.

Comprueba HTTPS en el navegador, no solo en la configuración.

Esta es una captura real de Chrome del proceso de compra de ps178-dev sobre HTTPS. Chrome moderno eliminó el candado verde, pero el control de seguridad sigue en la barra de direcciones, y la URL del proceso de compra debe cargar de forma segura antes de que los campos de pago alojados funcionen de manera fiable.

Medir el rendimiento del proceso de compra

No puedes mejorar lo que no mides. Las métricas que importan para un proceso de compra de PrestaShop:

Métricas clave

• Tasa de finalización del proceso de compra, pedidos completados / sesiones de proceso de compra. El número más importante.
• Tasa de abandono del proceso de compra, porcentaje de quienes empiezan el proceso de compra pero no lo terminan. Aísla problemas del proceso de compra frente a simples visitantes que miran escaparates.
• Abandono por paso, qué paso pierde más clientes. Si el 40% se va en el envío, tus opciones de transportista son el problema.
• Tiempo hasta completar, cuanto más largo, mayor abandono.
• Tasa de fallo de pago, tasas altas suelen indicar mala configuración de 3DS o reglas antifraude agresivas.

Pruebas A/B de cambios en el proceso de compra

Cuando cambies el diseño, prueba contra tu propia línea base. Envía parte del tráfico comparable al proceso de compra actual y parte al nuevo flujo, luego compara tasa de finalización, fallos de pago, AOV y tickets de soporte. Mantén la prueba comparable: no mezcles B2B con sesión iniciada, móviles de primera visita y escritorio recurrente en una sola conclusión si se comportan de forma distinta.

Comercio electrónico mejorado en GA4

La forma estándar de medir el embudo. Instala un módulo GA4 que dispare begin_checkout, add_shipping_info, add_payment_info y purchase. Configura un informe de embudo en GA4 > Explorar > Exploración de embudos con pasos que coincidan con tu proceso de compra.

Para un seguimiento de compras preciso, considera hacerlo del lado del servidor. El JavaScript del lado del cliente puede bloquearse, retrasarse o perderse entre redirecciones. Una implementación server-side del GA4 Measurement Protocol disparada por hooks de pedido de PrestaShop es lo que usamos en tiendas donde los informes de ingresos realmente importan.

Cómo es una "buena" tasa de finalización

No existe una cifra universal. Una tienda de camisetas de 5 EUR, un catálogo B2B de recambios y una tienda de muebles de 3.000 EUR no se comportan igual. Construye una línea base con tu propia analítica y observa los cambios después de editar el proceso de compra. Si la finalización cae de golpe: creación de cuenta obligatoria, costes de envío sorpresa, opciones de pago ausentes, validación de dirección, errores del módulo de pago. En ese orden.

Lo que viene: proceso de compra nativo en una página en 9.2

La hoja de ruta de PrestaShop lista 9.2 para Q2-Q3 2026, incluyendo un proceso de compra nativo en una página. Es un cambio relevante: los comerciantes con la pila adecuada podrán ofrecer proceso de compra en una sola página sin un módulo de terceros.

Las salvedades:

• Solo tema Hummingbird v2. Las tiendas Classic no lo verán.
• Opcional, no predeterminado. El flujo en varios pasos seguirá disponible.
• Los autores de módulos tendrán que adaptar sus módulos de pago y envío al nuevo flujo.
• El calendario de la hoja de ruta no es una fecha de lanzamiento. Puede moverse.

¿Deberías esperar? Si vas a lanzar hoy, no: esperar meses (o más) a algo que quizá exija una migración completa de tema no es práctico. Si ya estás en Hummingbird y planeas una actualización, vigila la hoja de ruta. Nuestra lectura de los planes para PS 9.2 está en los planes de OPC nativo de PrestaShop.

Elegir el proceso de compra adecuado para tu tienda

No existe una única configuración "mejor". Nuestro marco después de una década construyendo esto:

• Acabas de empezar, presupuesto ajustado. Flujo predeterminado en varios pasos + ps_checkout. Gratis, funciona, actualiza más adelante.
• Tienda establecida, mucho abandono. Módulo de proceso de compra en una página. La mejora de conversión suele pagarse sola en semanas.
• Tráfico muy móvil. Compra exprés con Apple Pay y Google Pay. Los formularios de dirección en móvil son el mayor freno a la conversión en comercio electrónico.
• Vendes en Europa. Mollie para métodos locales sólidos o Stripe para cobertura internacional más amplia.
• Alto volumen. Integración directa con Stripe o Adyen: liquidación, informes y gestión de disputas importan más a escala.
• Empresa / omnicanal. Adyen para unificar venta en línea + tienda física en una sola plataforma.
• Quieres todo de un solo proveedor. Soluciones que combinan optimización del flujo y pagos en un único módulo en lugar de apilar tres o cuatro.

Elijas lo que elijas, pruébalo. Haz pedidos de prueba en distintos dispositivos, prueba diferentes métodos de pago, aplica códigos de descuento, comprueba qué pasa cuando algo sale mal. El proceso de compra es donde se genera el ingreso. Merece más atención de la que le dan la mayoría de tiendas.

FAQ

¿ps_checkout es lo mismo que el proceso de compra de PrestaShop?

No, y esta es la confusión más común que vemos. El proceso de compra es el flujo en varios pasos (carrito, información personal, dirección, envío, pago) integrado en cada tienda PrestaShop. ps_checkout es un módulo gratuito de pago desarrollado por PrestaShop SA con PayPal que solo renderiza opciones de pago en el paso de pago. No cambia los pasos, el diseño ni el orden de los campos. Desinstalar ps_checkout no cambia tu flujo de compra, e instalarlo no te dará un proceso de compra en una página: cualquiera que te diga lo contrario no ha leído el README del módulo.

¿Por qué mi proceso de compra dice "No hay ningún método de pago disponible"?

Significa que ningún módulo de pago devolvió nada desde el hook paymentOptions. Las causas habituales, en orden: una restricción de divisa o país excluye el carrito; Pago > Preferencias excluye el transportista, país o grupo de clientes actual; el módulo de pago encontró un error PHP y falló en silencio (revisa var/logs/); o, en PS 8+, las cabeceras CSP están bloqueando el JavaScript del módulo. Empieza por Pago > Preferencias: un módulo completamente instalado y activo puede seguir siendo invisible si alguna restricción excluye el contexto actual del carrito.

¿Por qué se vacía mi carrito en el paso de pago?

Los carritos que se vacían casi siempre son un problema de cookies o sesión: una mala configuración SSL, dominios de tienda y SSL no coincidentes, una partición de sesión llena o un módulo que reinicia el carrito dentro de un hook del proceso de compra. Desactiva módulos uno por uno hasta que el proceso de compra se comporte para encontrar al culpable. Rara vez es el propio proveedor de pago: el carrito ya ha desaparecido antes de que se llame al proveedor.

¿Tengo que gestionar yo el cumplimiento PCI?

Mantén los datos de tarjeta fuera de tu servidor y tu carga se queda en el nivel más bajo (SAQ A). Usa un módulo con campos de pago alojados o redirección: ps_checkout, Payment Element de Stripe y el proceso de compra alojado de Mollie te sitúan ahí, porque el número de tarjeta, la caducidad y el CVV se ejecutan en el dominio del proveedor dentro de un iframe, no en tu tienda. Si un módulo te pide añadir campos HTML de tarjeta en bruto a tu página, aléjate: eso te empuja hacia SAQ D, que es caro y casi nunca es la opción correcta. Confirma el SAQ exacto con tu proveedor; nosotros no somos tu QSA.

¿Debería esperar al proceso de compra nativo en una página de 9.2?

Si lanzas hoy, no: esperar meses a una función que quizá requiera una migración completa al tema Hummingbird no es práctico, y la versión nativa será solo para Hummingbird y opcional en lugar de predeterminada. Si ya estás en Hummingbird y planeas actualizar, vigila la hoja de ruta. Hasta que llegue, un proceso de compra en una página significa un módulo: ese es el territorio de Checkout Revolution. Nuestro análisis más completo está en los planes de OPC nativo de PrestaShop.

Lecturas relacionadas

• Guía de optimización del proceso de compra de PrestaShop, cambios concretos que mejoran la tasa de finalización
• Proceso de compra nativo en una página de PrestaShop 9.2, nuestra lectura de la hoja de ruta
• Checkout Revolution, nuestro módulo de una página + exprés
• Express Checkout, botones de monedero sin sustituir tu proceso de compra
• PrestaShop Hooks & Overrides, los hooks que ejecuta el proceso de compra y cómo conectarte a ellos de forma segura