Sí. Checkout Revolution soporta completamente el guest checkout dentro de su flujo de una sola página, y eliges la política por tienda: exigir creación de cuenta, ofrecerla como paso opcional posterior a la compra o permitir que los compradores completen un checkout puramente como invitados solo con email.

Permitir guest checkout suele aumentar las tasas de conversión en primeros pedidos — muchos compradores abandonan cuando se les obliga a registrarse, especialmente en móvil. Con la creación de cuenta opcional posterior a la compra, sigues construyendo una audiencia con sesión iniciada sin introducir fricción durante el paso de compra.

Los pedidos de invitados pasan por la misma UI de una página, recuperación de carrito abandonado, validación de cupones y opciones de pago (Stripe, Apple Pay, Google Pay, PayPal, BNPL, métodos offline) que los pedidos registrados. Para contexto sobre por qué importa el guest checkout, consulta nuestra guía de one-page checkout. Soporta PrestaShop 1.6 a 9.x.

En el flujo del módulo, el paso de contacto expone al front end un indicador de invitados permitidos, para que el comprador pueda continuar solo con una dirección de email cuando el guest checkout está activado. Si el email pertenece a una cuenta existente, Checkout Revolution aún puede mostrar opciones de inicio de sesión y una ruta para continuar como invitado; cuando se usa un email de cuenta existente sin autenticar, el procesador de pedidos evita iniciar sesión silenciosamente con ese cliente después del pedido. Si el comprador define una contraseña durante el checkout, el pedido queda respaldado por cuenta; si no, el pedido se procesa como invitado y el módulo puede mostrar un bloque de registro posterior al pedido.

El punto operativo es elegir la política adecuada para tus productos. Las tiendas B2B de compras repetidas suelen beneficiarse de creación de cuenta o registro posterior al pedido; el retail de compra impulsiva suele convertir mejor con guest checkout puro. El guest checkout aún necesita los campos habituales obligatorios de dirección, transportista, pago y consentimiento legal, y algunos módulos de pago o reglas antifraude pueden añadir sus propios requisitos fuera de Checkout Revolution.

Checkout Revolution soporta varias necesidades B2B esenciales, pero no incluye un flujo de aprobación de órdenes de compra en varios pasos.

Lo que SÍ está soportado: un flujo completo de presupuestos con estados personalizados (codificados por color y visibles para el cliente), plantillas de email ligadas a cada estado y páginas orientadas al cliente para aceptar y pagar, de modo que un comprador pueda convertir un presupuesto en un pedido pagado sin intervención comercial. También cubre captura de número VAT de empresa, visualización de precios netos donde tus reglas fiscales lo permiten y campos personalizados de empresa, y las facturas y abonos pueden personalizarse por tienda. La gestión de impuestos respeta las reglas fiscales nativas de PrestaShop, lo que mantiene limpio el B2B multinacional.

Lo que NO está incluido: un verdadero flujo de orden de compra approve → submit → invoice (donde el equipo de compras del comprador aprueba antes del pago y tú envías con condiciones net-30 y un documento PO separado). Ese tipo de flujo necesita un módulo B2B/presupuestos dedicado o desarrollo personalizado sobre Checkout Revolution.

Para validación VAT automática basada en VIES en checkout, combínalo con nuestro módulo Automatic EU VAT Checker. Soporta PrestaShop 1.6 a 9.x.

Por debajo, el sistema de presupuestos almacena estados de presupuesto, artículos de presupuesto, mensajes, historial y enlaces presupuesto-a-pedido, con valores predeterminados como referencias QUO-{YEAR}-{ID:5}, validez de presupuesto de 30 días y enlaces de pago de 48 horas. Los campos opcionales de presupuesto incluyen teléfono, empresa, referencia de proyecto y adjunto; existen solicitudes de presupuesto de invitados, pero están desactivadas por defecto. La negociación de precio también es un ajuste separado, así que puedes mantener los presupuestos simples o permitir contraofertas según tu proceso comercial.

Para datos estilo orden de compra, la ruta práctica es capturar un número PO/referencia como campo personalizado de checkout o factura, o usar el método de pago de cuenta de crédito/manual cuando encaje en tu proceso. El módulo incluye gestión de pago por cuenta de crédito y derivación de solicitud de cuenta comercial, pero sus propias notas de integración mantienen flujos de aprobación, límites de crédito y gestión de cuentas de empresa como responsabilidades de una capa dedicada de cuenta comercial. En resumen: bueno para presupuestos, campos VAT/empresa, checkout con cuenta de crédito y personalización de facturas; no es por sí solo un sistema completo de aprobación de compras.

Sí. Cuando una campaña está activa, Smart Dynamic & Scheduled Discounts muestra por ti las señales de urgencia en el storefront:

• un temporizador de cuenta atrás en la página de producto que cuenta hasta el final de la campaña (estilo simple, flip o círculo);
• un badge en productos en páginas de categoría y listados;
• el ahorro mostrado junto al precio, como porcentaje e importe;
• un bloque de campaña en el carrito.

Cada uno de estos es un interruptor independiente por campaña, así que una flash sale discreta y una promoción estacional llamativa pueden verse completamente distintas. Un desliz común es activar la campaña pero dejar todas las opciones de visualización apagadas — el descuento sigue aplicándose, pero los compradores no ven temporizador ni badge que les impulse a actuar. Como el temporizador lee la fecha de fin de campaña, defines las fechas una vez y el storefront se mantiene actualizado por sí mismo.

En términos de configuración, el registro de display de una campaña controla show_countdown, show_badge, show_original_price y show_savings, además de colores de badge, estilo de cuenta atrás y CSS personalizado opcional. El módulo tiene hooks separados para la cuenta atrás/badge de página de producto, badge de listado, ahorros en bloque de precio y barra de campaña del carrito, así que un tema puede necesitar esos hooks presentes o una ubicación equivalente en la plantilla.

El motor de descuentos está separado de la capa visual. Una campaña válida puede aplicar su mejor descuento porcentual, de importe o de precio fijo aunque el badge y el temporizador estén ocultos. A la inversa, no se muestra temporizador cuando no hay campaña activa para ese producto, la campaña no tiene tiempo restante, el interruptor de display está apagado o el tema no renderiza el hook. Para merchandising, prueba una página de producto, un listado de categoría y el carrito porque cada uno usa una superficie distinta del storefront.

Sí. Junto a una oferta programada puntual, Smart Dynamic & Scheduled Discounts tiene un tipo de campaña recurrente que se repite según un calendario en lugar de ejecutarse una sola vez. Una campaña recurrente contiene una o más reglas de calendario, cada una con:

• un tipo — daily, weekly, monthly o custom;
• los días en que se ejecuta (días de la semana para weekly, días del mes para monthly);
• una hora de inicio y fin y una timezone;
• un interruptor active por regla.

Antes de aplicar el descuento, el módulo compara la hora actual con esas ventanas, así que un happy hour every Friday 18:00-20:00 se ejecuta solo semana tras semana. Vigila el campo timezone: si lo dejas mal, la ventana se abrirá a la hora local incorrecta. Esa es la diferencia entre reconstruir a mano la misma promoción cada semana y configurarla una vez.

Hay un límite importante: los calendarios recurrentes viven dentro del indicador activo principal de la campaña y de las fechas globales de inicio/fin. La campaña debe seguir activa y dentro de date_start y date_end; el calendario solo decide qué horas o días dentro de esa ventana más amplia son válidos. Si una campaña recurrente no tiene filas de calendario, el código la trata como activa durante todo el rango de fechas de la campaña, así que añade al menos una regla de calendario cuando quieras una ventana realmente limitada.

Las listas de días vacías son amplias, no restrictivas: un calendario weekly sin días de semana seleccionados puede coincidir con cualquier día de semana durante la ventana horaria configurada, y un calendario monthly sin días de mes seleccionados puede coincidir con cualquier día del mes. La timezone se almacena por regla y recurre a UTC si falta, así que usa la zona horaria local real de la tienda para promociones como Europe/Warsaw. Ejemplo: campaign_type=recurring; schedule_type=weekly; days_of_week=5; time_start=18:00:00; time_end=20:00:00; timezone=Europe/Warsaw.

PrestaShop guarda los carritos en la base de datos, pero que un cliente pueda recuperar un carrito depende de cómo esté vinculado ese carrito al visitante.

• Clientes conectados: el carrito queda asociado a la cuenta del cliente. Si el carrito no se ha convertido en pedido, PrestaShop normalmente puede restaurar el último carrito utilizable cuando el cliente vuelve e inicia sesión.
• Visitantes invitados: el carrito se vincula principalmente mediante la cookie del front office que guarda el identificador del carrito. Si el visitante vuelve con el mismo navegador antes de que caduque la cookie, el carrito puede restaurarse. Si borra las cookies, usa otro dispositivo, navega en modo privado o caduca la duración de la cookie, la tienda puede seguir teniendo la fila del carrito en la base de datos, pero no puede asociarla de forma fiable a ese visitante.
• Después de un pedido: el carrito pedido deja de tratarse como el carrito de compra abierto del cliente. El módulo de checkout también evita dejar los productos ya pedidos visibles como carrito actual después de la confirmación.

La duración relevante es el ajuste de cookie del front office, almacenado como PS_COOKIE_LIFETIME_FO. Ese ajuste controla cuánto tiempo puede sobrevivir la cookie de carrito/cliente en el navegador, no cuánto tiempo permanecen los registros de carritos abandonados en la base de datos.

En PrestaShop 1.7, 8 y 9, comprueba esto en Shop Parameters > General: el campo normalmente se llama Lifetime of front office cookies y corresponde a PS_COOKIE_LIFETIME_FO. Las tiendas más antiguas pueden mostrar el mismo ajuste en Preferences > General.

Para recuperar por email en lugar de usar una restauración pasiva mediante cookies, utiliza una herramienta específica de carritos abandonados como Sales Revolution, o una integración con plataforma de email como Klaviyo Integration si quieres flujos de carrito abandonado dentro de tu sistema de marketing.

PrestaShop nativo no envía automáticamente emails de recordatorio de carrito abandonado. Para recordatorios, enlaces de recuperación o automatización de marketing, necesitas un módulo de carrito abandonado o una integración de marketing. Checkout Revolution no sustituye la persistencia nativa del carrito de PrestaShop; trabaja con el carrito y el flujo de checkout existentes.

Por grupo de cliente y moneda: sí. Por valor del carrito: no solo con el módulo de pago — eso pasa por las reglas de carrito nativas de PrestaShop. Este es el reparto honesto.

Checkout Revolution guarda reglas de segmentación por método y las comprueba en tiempo real contra el contexto del cliente. Puedes mostrar u ocultar cada opción de pago por:

• Grupo de cliente — p. ej. transferencia o "pago a cuenta" solo para tu grupo B2B / mayorista.
• Moneda — un método regional aparece solo cuando el carrito está en su moneda.
• País e idioma — limitar un método a países de entrega o idiomas concretos.
• Navegador — para que los wallets del dispositivo salgan correctamente (Apple Pay en Safari, Google Pay en Chrome).
• Página / tienda — limitar un método a ciertos contextos de checkout o, en multitienda, a tiendas concretas.

Lo que no hace: no hay una regla integrada del tipo "ocultar contra reembolso por encima de 500 €" basada en el valor del carrito sobre el propio método. Para umbrales de importe usa las herramientas estándar de PrestaShop (reglas de carrito o una condición de disponibilidad) — Checkout Revolution mostrará luego lo que quede disponible. El error común es esperar un interruptor de mínimo de carrito en la opción de pago; vive a nivel de PrestaShop, no aquí.

No — y la distinción importa, así que esto es exactamente lo que hace cada módulo.

Estimated Delivery Date no modela tiempos de tránsito por transportista. Calcula una única fecha estimada de entrega a partir de reglas para toda la tienda: un número de días de preparación, una hora límite diaria (los pedidos posteriores suman un día de preparación), exclusión automática de fines de semana y un formato de fecha a elegir. El resultado aparece en las páginas de producto bajo el precio, p. ej. "Entrega estimada: lunes, 15 de enero". Un solo panel rige todo el catálogo — en este módulo no hay plazos por transportista ni por país.

Checkout Revolution tampoco calcula los tiempos, pero puede mostrarlos: al configurar los métodos de envío lee el texto de plazo que ya escribiste en cada transportista de PrestaShop (p. ej. "2-4 días"), extrae el número mínimo y máximo de días y lo muestra junto al método en el paso de envío. La cifra viene de tu configuración del transportista, no de un cálculo de ruta.

Si quieres un ETA real por transportista y país de destino, hace falta un módulo de transportista dedicado — ninguno de los dos hace ese cálculo. Usa Estimated Delivery Date cuando lo que necesitas es un mensaje claro y global "pide antes de X para recibir el Y" en la página de producto.

La regla corta: use precios específicos cuando el descuento deba cambiar cómo se ve un producto en el catálogo, y reglas del carrito cuando dependa de todo el pedido o necesite un código de descuento.

Precios específicos — cambian el precio en sí

Los precios específicos sobrescriben el precio mostrado de un producto antes de que llegue al carrito. El precio original tachado y el nuevo aparecen en la ficha de producto y en los listados de categoría, y alimentan los feeds de Google Shopping y comparadores. Elíjalos para:

• Un precio de oferta o una etiqueta de descuento visible en el catálogo.
• Tramos por cantidad (compra 5, ahorra 10%) mostrados en la ficha de producto.
• Precios por grupo de clientes — B2B, VIP o mayorista, que el cliente adecuado ve ya al navegar.
• Precios por combinación para tallas, colores o variantes concretas.

Reglas del carrito — descuentan el pedido

Las reglas del carrito actúan cuando los productos ya están en el carrito y admiten condiciones que los precios específicos no pueden expresar:

• Códigos de descuento que el cliente introduce en el checkout.
• Un importe mínimo de pedido antes de aplicarse.
• Envío gratuito como recompensa.
• Condiciones entre productos (p. ej. solo si hay artículos de dos categorías en el carrito).
• Límites de uso totales o por cliente.

Usar ambos juntos

Se acumulan: PrestaShop aplica primero el precio específico y luego la regla del carrito sobre el precio reducido — un precio específico del 30% más una regla del 20% dan un 44% de descuento total, no el 50%. Calcule los descuentos combinados antes de lanzar una campaña para que no bajen de su margen sin darse cuenta. Error frecuente: una promoción solo mediante regla del carrito deja su feed de Google Shopping con el precio completo, porque los feeds leen el precio del producto, no los descuentos del carrito.

Gestionar ambos a gran escala — campañas programadas, tramos por cantidad y precios por grupo en un solo lugar — es para lo que está hecho Sales Revolution.

Instala Checkout Revolution y conecta tu cuenta Stripe — eso da a PrestaShop un express checkout impulsado por Stripe, para que un cliente pueda pagar en un paso sin pasar por todo el flujo carrito-a-confirmación.

La configuración es corta:

• instala el módulo y pega tus claves publicable y secreta de Stripe (la clave secreta se valida contra Stripe);
• elige dónde aparecen los botones express — la página de producto, el listado, el carrito o el checkout estándar;
• los clientes luego pagan con Apple Pay, Google Pay, PayPal, Link o tarjeta, y la wallet se muestra si el dispositivo del comprador y tu panel Stripe lo permiten.

El módulo carga el JavaScript propio de Stripe y gestiona por ti el carrito, estado de pago y callbacks de webhook. Una cosa a saber: los transportistas y envíos que configures bajo Express Checkout se aplican solo al modal express, no a tu checkout normal — configúralos o la compra express no tendrá con qué enviarse. Si solo necesitas un botón más ligero, compáralo primero con la opción menor Express Checkout.

En el código fuente actual, Checkout Revolution es el módulo activo y el código antiguo mprexpresscheckout está marcado como obsoleto y fusionado en él. El módulo espera claves Stripe que coincidan con el modo: el modo test usa pk_test_ y sk_test_, mientras que el modo live usa pk_live_ y sk_live_. También hay un Admin Test Mode para que empleados de back office con sesión iniciada puedan probar con claves test mientras la tienda procesa en modo live.

Las wallets no son simples botones on/off. La configuración de método de pago define wallets para Google Pay, Apple Pay, Link y Samsung Pay; Google Pay está restringido a Chrome, Apple Pay a Safari, y la disponibilidad de wallets se cachea desde el navegador para que wallets no disponibles puedan ocultarse o desactivarse en lugar de aparecer y desaparecer. El ajuste de país de la cuenta Stripe se usa para elegibilidad de Apple Pay / Google Pay, y si está vacío el módulo recurre al país del locale de la tienda.

La configuración de webhooks es importante porque la finalización de pedidos y eventos de pago posteriores dependen de ella. El módulo puede registrar webhooks Stripe para modos test y live configurados y comprueba eventos como payment_intent.succeeded, charge.succeeded, refund.updated y eventos de facturas de suscripción. También tiene un ajuste de recuperación de transacciones, con cron recomendado cada 5-10 minutos como respaldo para fallos de webhook.

El envío necesita su propia comprobación antes del lanzamiento. Checkout Revolution tiene asociaciones de opción de pago con servicio de envío, y el front-end filtra transportistas por la opción de pago seleccionada. Si un transportista no tiene restricciones de pago, soporta todos los métodos de pago; si se definen restricciones, un transportista incompatible se desactiva o bloquea para esa opción de pago. Por eso express checkout puede parecer activado pero seguir fallando comercialmente si no hay transportista compatible para la wallet o país probado.

Launch checklist: correct test/live Stripe keys; webhooks paired for the active mode; at least one active Stripe-enabled payment option; at least one compatible carrier; wallet tested on a real supported browser/device.

Sales Revolution reúne en un solo panel las herramientas de venta que una tienda PrestaShop suele tener que montar a partir de varios módulos separados:

• Pares de upsell y cross-sell — definidos a mano o generados desde tu historial de pedidos.
• Bloques "comprados juntos habitualmente" y "los clientes también vieron" en las fichas de producto.
• Packs de productos con descuentos de pack y sincronización de stock (el pack pasa a agotado cuando falta un componente).
• Campañas con tiempo limitado con insignias de cuenta atrás, fechas de inicio/fin y planificador estacional.
• Reglas de precio dinámicas por tramo de cantidad y valor del carrito ("compra 3, ahorra 15%", "envío gratis desde 99 €").
• Recuperación de carrito abandonado con disparadores por correo.
• Analítica por ubicación que registra impresiones, clics, conversiones e ingresos, para ver qué ofertas rinden de verdad.

Registra hooks estándar de PrestaShop como displayProductActions, displayCartModalContent y displayShoppingCartFooter. El buen momento para añadirlo es cuando quieres elevar el valor medio del pedido de los clientes que ya tienes.

Sí. Estimated Delivery Date tiene un único ajuste diario de cutoff hour, en formato de 24 horas, y funciona de forma directa.

• Pedido a la hora límite o después - el módulo añade un día extra de procesamiento, porque ese pedido ya no saldrá en el envío de hoy. La fecha estimada de entrega en la página de producto se desplaza en consecuencia.
• Pedido antes de la hora límite - la página de producto también puede mostrar cuántas horas completas quedan, por ejemplo Order within 3 hours, para impulsar el envío el mismo día.

Además de la hora límite, la fecha se construye con un número configurable de días de procesamiento y exclusión automática de fin de semana (se saltan sábados y domingos, y una fecha que cae en fin de semana pasa al lunes). Tú eliges el formato de fecha mostrado a clientes.

Los valores predeterminados de instalación son activado, PROCESSING_DAYS=1, CUTOFF_HOUR=14, exclusión de fin de semana activada y DATE_FORMAT=l, F j. Con esos valores, un visitante de lunes antes de las 14:00 ve el siguiente día laborable elegible; un visitante de lunes a las 14:00 o después recibe un día extra de procesamiento antes de mostrar la fecha.

El módulo renderiza en el hook displayProductAdditionalInfo, así que aparece solo si el tema de la página de producto todavía llama a ese hook. No inspecciona el transportista seleccionado, país de entrega, almacén, estado de stock ni plazo de entrega individual del producto. El cálculo es global para la tienda y se basa en la hora actual del servidor cuando se genera la página de producto.

Dos límites honestos que conviene conocer: la hora límite es una única hora para toda la tienda - no por transportista ni país - y la cifra de horas restantes son horas completas, actualizadas cuando carga la página, no un temporizador que corre segundo a segundo. Si lo que necesitas es un mensaje global de pedido-antes-de-esta-hora-para-entrega-en-esta-fecha en tus páginas de producto, eso es exactamente lo que hace este módulo.

El B2B Essentials Pack reúne los cuatro módulos PrestaShop que una tienda B2B realmente necesita: validación de NIF intracomunitario, plazos de pago aplazado, visualización de impuestos por grupo y un verdadero flujo de registro de cuenta comercial. Cada módulo funciona de forma independiente con su propia pantalla de configuración.

Módulos incluidos:

1. EU VAT Number Checker — valida los NIF intracomunitarios contra el servicio oficial europeo VIES, para que apliques el tratamiento fiscal intracomunitario correcto.
2. B2B Deferred Payment Terms — añade plazos de pago configurables con cálculo automático del vencimiento, seguimiento de impagos y límites de crédito por grupo para clientes comerciales aprobados.
3. Tax Display Switcher — permite a los visitantes alternar entre precios con IVA y sin IVA y recuerda la elección en una cookie; el valor por defecto puede seguir la configuración nativa de visualización de precios del grupo de cliente.
4. Trade Account — añade un formulario de registro dedicado con campos de empresa (razón social, NIF, tipo de actividad, referencias comerciales) y un flujo de aprobación; los clientes aprobados se asignan a tu grupo comercial, con visualización sin IVA opcional.

Instálalo cuando tu tienda necesite una verdadera capa B2B sobre el checkout retail, no solo "ocultar precios hasta el login". Cada módulo conserva sus ajustes, así que los configuras una vez según tu flujo real. Desglose completo y precio actual en la página B2B Essentials Pack.