Proceso de compra en PrestaShop: configuración, pagos y diagnóstico

Qué haríamos

Qué cambio ayuda depende de la tienda existente: su versión de PrestaShop, su tema, sus módulos de pago y de transporte, el código de pedidos a medida y las integraciones de stock, contabilidad o entrega que reciben sus pedidos. Identifica qué datos de clientes, direcciones y pedidos recibe cada una de esas integraciones. Seguiríamos una compra fallida desde la cesta hasta la confirmación del pedido en esa combinación exacta, como visitante nuevo y como cliente que vuelve. Compara cada restricción con la regla que la tienda pretendía antes de tratarla como un fallo y corrige primero los errores de configuración o de integración demostrados. Cambia el diseño cuando las pruebas apunten a campos o navegación confusos; cambia la integración de pago cuando falte un método o una operación de pago necesarios.

Para cambios de configuración y de módulos del proceso de compra: reproduce el problema en una copia de pruebas de la tienda, aislada de pagos reales, del correo a clientes y de la preparación de pedidos; cambia una capa cada vez; ensaya escenarios de compra escritos; y haz después el cambio a una hora planificada, con una copia de seguridad de archivos y base de datos, una forma probada de volver atrás y un plan para conciliar los pedidos realizados mientras tanto. Un proceso de compra que ya cubre la necesidad se queda como está. Si el trabajo en el proceso de compra forma parte de una reconstrucción más amplia de la tienda, la vía segura habitual es una tienda de destino limpia en pruebas, una migración ensayada de los datos necesarios de la tienda y un cambio a producción planificado tras probar los módulos y las integraciones.

Si no está clara la causa de los pedidos perdidos, el PrestaShop B2C Conversion & Revenue Audit examina el descubrimiento, el carrito, el proceso de compra, el pago y la confirmación, empezando por el móvil, y entrega un plan de correcciones ordenado por prioridad sin instalar ni cambiar nada; la implementación es aparte.

Entiende el flujo de compra

En PrestaShop 1.7.8 y 9.1, el controlador de pedidos construye cuatro pasos lógicos: información personal, direcciones, envío y pago. Un carrito solo de productos virtuales omite el envío. La revisión del carrito y la confirmación del pedido son partes separadas del recorrido. Una sola URL de compra puede contener varios pasos, solicitudes y transferencias al proveedor de pago.

Un cliente que vuelve puede tener sus datos guardados. Un tema o módulo de compra puede cambiar la presentación. Cuenta las navegaciones entre documentos y las solicitudes en segundo plano en el navegador antes de describir tu tienda como un proceso de compra de cuatro o cinco páginas.

PrestaShop 9.2 incluye el módulo nativo ps_onepagecheckout. Debes activarlo y configurarlo para que su proceso de compra unificado esté activo. El proceso por pasos sigue disponible. La documentación actual del proceso de compra nativo explica la integración.

Mantén separadas cuatro decisiones: el diseño del proceso de compra, la integración de pago, la cuenta del proveedor que hay detrás y la forma de medir el recorrido.

Registra la versión de PrestaShop instalada, la versión de PHP, el tema y las versiones del módulo de compra y del módulo de pago antes de seguir cualquier instrucción, y comprueba qué admiten exactamente esas versiones. Evalúa a la vez las opciones nativas del proceso de compra y los módulos de terceros; una hoja de ruta antigua no es una guía de configuración.

Relaciona el síntoma con la siguiente acción

Antes de cambiar nada

1. Intenta la misma compra en un móvil como visitante nuevo y como cliente que vuelve. Anota dónde hay que volver a introducir información o dónde un error deja poco clara la siguiente acción.
2. Separa la navegación de las decisiones sin resolver. Un gasto de entrega que aparece tarde, un transportista inadecuado o un método de pago que falta necesitan su propia corrección, incluso en una sola página.
3. Escribe un escenario de aceptación para el obstáculo: tipo de cliente, cesta, destino, método de pago y resultado esperado. Úsalo para comparar el proceso de compra actual con cualquier alternativa propuesta.

Por ejemplo, una opción de pago puede aparecer para un cliente minorista nacional pero desaparecer cuando el comprador elige otro país, inicia sesión en una cuenta profesional o escoge un transportista concreto. Compara ese contexto del carrito con las reglas de pago previstas antes de culpar al diseño. Un método activado en el panel del proveedor puede seguir sin estar disponible a través de la integración instalada.

Cuando la integración usa ambos, el regreso del navegador desde la autenticación bancaria y la notificación del servidor del proveedor son vías de prueba distintas. Una página de retorno rota no demuestra que el pago haya fallado, y la falta de una página de confirmación no demuestra que no exista el pedido. Comprueba el estado, el importe, la moneda y la referencia en el proveedor frente al registro de la tienda; los pagos autorizados, pendientes, capturados y completados pueden necesitar un tratamiento distinto.

Un informe de soporte útil incluye la cesta, el tipo y grupo de cliente, el mercado y la moneda, el dispositivo, la hora del fallo con su zona horaria, la referencia del carrito o del pedido, una referencia de la transacción del proveedor anonimizada, los pasos para reproducirlo y el mensaje exacto. Pide al desarrollador que relacione las pruebas del navegador y del servidor. Elimina credenciales, datos de pago y datos de clientes innecesarios antes de compartir registros o capturas de pantalla.

Elige una vía para el proceso de compra después de definir la carencia

Conserva el flujo nativo instalado si cumple el requisito, y conserva una integración de pago existente si ofrece los métodos y la gestión de pedidos que necesitas. No compres un módulo porque su nombre suene más rápido: una sola página puede seguir conteniendo todas las decisiones necesarias, y una cartera puede reducir lo que hay que escribir sin resolver las opciones de entrega o de producto.

Checkout Revolution reúne en una sola página el contacto, la dirección, la entrega, el pago, los vales y el resumen del pedido, en una, dos o tres columnas, con el orden de secciones que elijas y decidiendo qué campos se muestran o son obligatorios. Tus transportistas y pagos existentes aparecen en él, un cliente que vuelve no tiene que reescribir su dirección, las reglas de pago pueden depender de la tienda, el idioma, el grupo de clientes, el país, el dispositivo y el importe del pedido, y el presupuesto aceptado de un comprador profesional puede convertirse en un pedido sin volver a introducirlo. También incluye una ventana de compra exprés en las páginas de producto, los listados y el carrito.

Express Checkout reúne la dirección, la entrega, el pago y la confirmación en una sola ventana en las páginas de producto, los listados o el carrito. Los pagos usan Stripe, sin cuota mensual y con una comisión por transacción, para tarjetas, carteras y métodos locales; compara esas condiciones por separado de si su recorrido encaja con la tienda. Tú eliges la ubicación de los botones, los campos de dirección obligatorios y la disponibilidad de los pagos por público, país y moneda. Los precios de entrega se actualizan en tiempo real, las combinaciones excluidas de pago y transportista se rechazan y los reembolsos totales o parciales se hacen desde la pantalla del pedido. Un proceso de compra opcional en una sola página incluye tus otros módulos de pago y de envío.

En ambos, un pago completado después de cerrar el navegador sigue convirtiéndose en un pedido. Ninguna de las dos descripciones de producto promete tarjetas guardadas ni nombra una cartera concreta como Apple Pay o Google Pay, así que confirma cualquier requisito de ese tipo frente a la versión y tu cuenta de pago antes de comprar. El nombre de ninguno de los dos productos garantiza la compatibilidad con tu código a medida: incluye en el requisito los overrides del proceso de compra, los campos adicionales, las integraciones de stock o de contabilidad y las reglas B2B.

Si la elección necesita pruebas, el PrestaShop Module Selection & Fit Assessment compara los ajustes nativos, los productos que ya tienes, los proveedores y el desarrollo a medida para un requisito, prueba los candidatos en una copia controlada de la tienda e incluye la configuración, la adaptación visual y el despliegue del módulo comercial elegido; las licencias se pagan aparte y el desarrollo a medida se presupuesta por separado. Si ya tienes el módulo elegido, el PrestaShop Module Installation & Configuration Service instala y configura un módulo existente según un alcance acordado y verifica el recorrido afectado; las licencias, los módulos adicionales y el desarrollo se pagan aparte.

Elige un proceso por pasos, en una página o integrado

PrestaShop 1.6 tenía un ajuste de tipo de proceso de pedido. El proceso de compra reconstruido de 1.7 no usaba ese antiguo interruptor. En 1.7, 8 y 9.0/9.1, un diseño completo alternativo necesita un módulo adecuado o una implementación personalizada. PrestaShop 9.2 proporciona OPC nativo, así que evalúa esa opción disponible antes de encargar un sustituto.

El OPC nativo no está limitado de forma absoluta a Hummingbird. Los temas derivados de Classic y los personalizados pueden integrarse con su contrato de plantillas y JavaScript. Sigue la guía de compatibilidad de temas y prueba tu combinación instalada.

Las compras complejas, los productos regulados, la personalización y varias opciones de envío pueden beneficiarse de una agrupación deliberada. Los pedidos sencillos pueden encajar en una vista unificada. Para un artículo de alto valor, como un reloj de €2.000, haz que la revisión final sea clara. Elige el diseño a partir de los requisitos de tus pedidos y de pruebas de usabilidad: el objetivo útil es tener menos pasos innecesarios manteniendo visible el pedido correcto para revisarlo, no un número menor de páginas.

Checkout Revolution implementa un proceso de compra en una página y flujos exprés/modales; consulta la ayuda de Checkout Revolution. Comprueba el resumen del pedido y los controles de envío en anchos de escritorio y móvil.

Evitar cambios en el núcleo puede reducir el mantenimiento, pero no garantiza la compatibilidad futura. Mantén los cambios del tema hijo bajo control de versiones y prueba las actualizaciones con tus módulos de transporte y pago.

Mide los eventos y diagnostica el abandono

Registra la entrada del carrito al proceso de compra, la finalización de la compra, los fallos de pago, el tiempo hasta finalizar y el importe del pedido. Define si la finalización significa un pedido creado o un pago confirmado. Usa la misma definición en toda una comparación y registra con ella los recorridos normal, exprés y con redirección, para que una cartera o un flujo modal no falte en los totales. Divide los resultados por dispositivo, tipo de cliente, país y método de pago cuando el volumen lo permita.

Estos son eventos de comercio electrónico de Google, no un evento para cada paso de la interfaz nativa. Para distinguir el abandono en los datos personales del abandono en la dirección, registra explícitamente vistas de pasos, envíos de formularios, resultados de validación y eventos de finalización. No envíes nombres, correos electrónicos, direcciones ni datos de pago a la analítica.

Comprueba cada evento en las herramientas de depuración del navegador y de la analítica, incluidos el envío de los datos de envío y de pago, los carritos virtuales y los reintentos. Para la integración de Google Analytics GA4, usa la ayuda del módulo.

Usa los comentarios de clientes, las grabaciones de sesiones enmascaradas con el consentimiento adecuado y los errores del navegador para investigar una caída. Una salida en el paso de envío puede deberse al coste, transportistas no disponibles, plazos de entrega o un fallo técnico. La posición en el embudo no demuestra la motivación del comprador. Prioriza los fallos y oportunidades confirmados según el tráfico afectado, el coste y el impacto previsto.

Las encuestas sobre los motivos de abandono pueden sugerir preguntas. No miden tu embudo de PrestaShop ni predicen la mejora de un cambio, y no existe un objetivo universal de finalización ni un periodo de amortización: compara con tu propia referencia. Elige un diseño de comparación y un tamaño de muestra a partir de tu referencia, el efecto que necesitas detectar y la variabilidad del tráfico. Controla las promociones, la estacionalidad y la mezcla de tráfico. Que se usen carteras sin que cambie la conversión total no demuestra canibalización.

Como ejemplo, subir la finalización del 30% al 31% es un aumento relativo de aproximadamente el 3,33%. Los ingresos cambian en la misma proporción solo si el volumen de inicios de compra y el importe medio del pedido permanecen constantes. Este cálculo no es una previsión.

Usa los registros de carritos sin inventar un embudo

PrestaShop conserva los carritos. Pedidos > Carritos de compra te ayuda a inspeccionarlos, pero una fila de carrito no demuestra que se haya iniciado la compra. Elige el prefijo de tabla y el ID de tienda correctos. El siguiente ejemplo de solo lectura cuenta los carritos creados recientemente que actualmente no están vacíos y el subconjunto vinculado a un pedido actualmente válido.

SELECT COUNT(*) AS nonempty_carts,
       SUM(EXISTS (
         SELECT 1 FROM ps_orders o
         WHERE o.id_cart = c.id_cart AND o.valid = 1
       )) AS carts_with_valid_order,
       ROUND(100.0 * SUM(EXISTS (
         SELECT 1 FROM ps_orders o
         WHERE o.id_cart = c.id_cart AND o.valid = 1
       )) / NULLIF(COUNT(*), 0), 1) AS cohort_ratio_pct
FROM ps_cart c
WHERE c.id_shop = 1
  AND c.date_add >= DATE_SUB(NOW(), INTERVAL 30 DAY)
  AND EXISTS (SELECT 1 FROM ps_cart_product cp WHERE cp.id_cart = c.id_cart);

Esta es una proporción de cohorte de carritos no vacíos que pasan a pedidos actualmente válidos. No es la conversión del proceso de compra. Los carritos recientes han tenido menos tiempo para convertir, los pedidos pendientes pueden validarse más tarde y un carrito puede crear varios pedidos. EXISTS evita contar un carrito más de una vez.

Define el abandono con un umbral de inactividad y una política de pedidos. Este segundo ejemplo usa 24 horas sin actualizar el carrito como umbral ilustrativo y excluye todo carrito con cualquier pedido, incluidos los no pagados.

SELECT CASE
         WHEN c.id_carrier > 0 THEN '3 - carrier value stored'
         WHEN c.id_address_delivery > 0 THEN '2 - delivery address stored'
         ELSE '1 - neither value stored'
       END AS stored_state,
       COUNT(*) AS inactive_nonempty_carts
FROM ps_cart c
WHERE c.id_shop = 1
  AND c.date_add >= DATE_SUB(NOW(), INTERVAL 30 DAY)
  AND c.date_upd < DATE_SUB(NOW(), INTERVAL 24 HOUR)
  AND EXISTS (SELECT 1 FROM ps_cart_product cp WHERE cp.id_cart = c.id_cart)
  AND NOT EXISTS (SELECT 1 FROM ps_orders o WHERE o.id_cart = c.id_cart)
GROUP BY stored_state
ORDER BY stored_state;

Lee directamente las etiquetas de etapa. Las direcciones y los transportistas guardados pueden haberse restaurado o asignado automáticamente; son solo indicios. Esta consulta no puede distinguir entre investigación, interrupción, tráfico de bots o un fallo del proceso de compra. Aplica tus exclusiones documentadas de bots y concilia con los datos de eventos. Controla por separado la recuperación de pedidos no pagados si ese es tu objetivo.

Configura la compra como invitado y los campos de cuenta

1. Abre Parámetros de la tienda > Configuración de pedidos y revisa Activar el pedido exprés para cuentas de invitado. En versiones modernas corresponde a PS_GUEST_CHECKOUT_ENABLED. Guarda desde el back office en el contexto de tienda previsto.
2. Prueba una sesión de invitado nueva y una cuenta que vuelve. En el proceso de compra nativo, la compra como invitado hace opcional la contraseña. Sigue siendo posible iniciar sesión.
3. Revisa por separado las solicitudes de fecha de nacimiento, los tratamientos y los campos adicionales de clientes. El modo B2B controla determinados campos de la cuenta del cliente; no elimina de forma universal los campos de empresa o VAT de las direcciones.
4. Revisa el formato de dirección y los requisitos de código postal y provincia de cada país de destino en Internacional > Ubicaciones > Países. Los requisitos de dirección y del transportista deben ajustarse a la preparación y entrega.

Puedes inspeccionar las filas de configuración sin modificarlas:

SELECT id_shop_group, id_shop, name, value
FROM ps_configuration
WHERE name = 'PS_GUEST_CHECKOUT_ENABLED';

El correo de un pedido no es un permiso de marketing. Ofrece una aceptación separada y adecuada. El seguimiento de pedidos puede usar el flujo nativo de seguimiento de invitados. La conversión nativa de invitado es un proceso explícito; activar la compra como invitado no instala un registro automático después de la compra. Prueba cómo se trata el correo de una cuenta existente en lugar de prometer cuentas duplicadas o un enrutamiento automático de correos.

Las cuentas pueden servir para el acceso B2B restringido, la gestión de servicios recurrentes y los registros de fidelización. Decide a partir de esos requisitos: en la venta a consumidores, prueba si exigir una cuenta crea un obstáculo evitable; en la venta a empresas, establece qué compradores deben tener cuentas aprobadas o datos de empresa. Cambiar de proveedor de pagos no decide estas reglas de cuentas. Las descargas nativas de productos virtuales pueden usar enlaces protegidos para invitados; vender un producto descargable no exige en sí mismo iniciar sesión con una cuenta registrada.

Mantén las direcciones de entrega y de facturación editables por separado. Pide un número de teléfono cuando tu servicio de entrega lo necesite. Conserva los caracteres internacionales válidos y explica los errores de los campos sin borrar los campos ya completados. Antes de eliminar un campo obligatorio con el que los clientes tienen problemas, averigua por qué es obligatorio.

Prueba las etiquetas y los errores en cada idioma de la tienda, incluidos los mensajes de los módulos de pago, los campos de dirección específicos de cada país y las condiciones enlazadas. Un tema traducido no demuestra que estén traducidos todos los mensajes de los módulos o del proveedor: cuando un proceso de compra en francés muestra un error de dirección en inglés, averigua si lo genera el tema, un módulo o el proveedor antes de decidir dónde traducirlo. Un campo de provincia obligatorio que no se ve o un error de código postal poco claro pueden detener una compra antes de que empiece el pago. La guía de traducciones y venta internacional cubre la configuración de idiomas completa.

Las pruebas de checkout a gran escala del Baymard Institute muestran con qué frecuencia las tiendas fallan en ambos puntos: el 98 % de los sitios no usa mensajes de error específicos y el 62 % no hace que la compra como invitado sea la opción más visible. La investigación UX de Baymard sobre el checkout explica la evidencia detrás de estas recomendaciones.

Muestra los costes, los plazos de entrega y las condiciones de devolución

Muestra pronto los precios, los impuestos y los gastos de entrega conocidos. Indica que una estimación es una estimación cuando aún no se conocen la dirección o el transportista definitivos. Configura los impuestos, la visualización de precios por grupo de clientes y los transportistas para los destinos a los que envías; la guía de envíos cubre la configuración de transportistas y los gastos de entrega. Transporte > Preferencias ofrece umbrales de envío gratuito; un mensaje con lo que falta por gastar requiere que lo muestre el tema o un módulo.

Por ejemplo, un comprador que espera pagar €40 puede replanteárselo si el total sube a €49. Muestra el cargo adicional y su motivo antes de la acción final del pedido. Un precio más bajo y una explicación más temprana resuelven problemas distintos.

Ofrece información realista sobre la preparación y el tránsito de cada transportista. Estimated Delivery Date proporciona plazos de envío o de entrega; consulta la ayuda de Estimated Delivery Date. Para los gastos de envío, usa un estimador de precios probado por separado o una política clara de precios de entrega.

Haz que la política real de devoluciones y la vía de contacto sean fáciles de encontrar en las páginas de producto y carrito. El interruptor de devolución de mercancía controla un flujo técnico. No crea ni elimina derechos legales, ni justifica anunciar devoluciones de 30 días salvo que las ofrezcas. Consulta las normas y excepciones aplicables al desistimiento.

Entiende las carteras exprés y los requisitos de sus botones

Las carteras pueden proporcionar datos de contacto guardados y credenciales de pago tokenizadas. Una integración exprés completa puede recopilar direcciones, ofrecer opciones de envío compatibles y actualizar los totales dentro de su flujo. El cliente puede seguir necesitando confirmar datos, elegir la entrega, aceptar condiciones o autenticarse. Pagar con una cartera en el último paso no omite automáticamente los formularios anteriores.

La compra exprés es un recorrido de usuario, no un requisito de usar la API Payment Request del navegador. Las integraciones pueden usar interfaces de carteras, SDK de proveedores, modales o redirecciones. Pueden recopilar datos separados de facturación y envío. Conserva una ruta de compra normal para navegadores, destinos y requisitos de pedido no compatibles.

Los botones pueden aparecer en páginas de producto, carritos, minicarritos o durante la compra, según la integración y los hooks renderizados. Prueba si la compra exprés desde el producto paga el artículo seleccionado, todo el carrito existente o uno recién creado. Mide el valor del carrito y la finalización en lugar de suponer que Comprar ahora reduce el valor del pedido.

1. Confirma que el método de pago esté activado para tu cuenta de comercio, país, moneda e importe del carrito.
2. Registra cada nombre de host de compra pertinente según exija el procesador, incluidos los dominios de pago integrado aplicables.
3. Comprueba HTTPS, certificados, permisos de iframe y errores de consola/red del navegador.
4. Comprueba la matriz actual de navegadores del procesador y la cartera o método de pago configurados por el cliente.
5. Comprueba las restricciones específicas del módulo y las ubicaciones compatibles. La capacidad del proveedor no demuestra la compatibilidad del módulo.

La compatibilidad del navegador depende de la cartera y de la integración. Consulta la matriz de compra exprés de Stripe y la guía de compra de Apple para las opciones actuales de dispositivos y autorización.

Cuando tu procesador requiera un archivo de asociación, esto comprueba solo su accesibilidad:

curl -I https://example.com/.well-known/apple-developer-merchantid-domain-association

Una respuesta correcta no demuestra el registro del dominio ni que la cartera esté disponible. Una pasarela compatible puede ofrecer ya botones exprés; un acelerador independiente es otra opción. Consulta la ayuda de Express Checkout.

Un escenario de cesta que revela el comportamiento erróneo

Un comprador ya tiene un filtro en el carrito, elige una combinación de recambio en una página de producto y pulsa el botón exprés. Tu especificación debe indicar si esa acción compra solo el recambio, la cesta existente o ambos tras revisarlos. Muestra el contenido antes del pago y comprueba qué queda en el carrito después; la etiqueta de un botón no determina el comportamiento del módulo.

Repite con una personalización obligatoria sin rellenar y después completada: la vía rápida debe exigir los mismos requisitos de producto que el proceso de compra principal. Si no hay un transportista adecuado para el destino, el cliente necesita una explicación y una forma de cambiar la dirección o la cesta antes de pagar.

Separa los pagos guardados de los pedidos en un clic

Un token de pago reutilizable, un cliente conocido, una dirección actual, una opción de envío que pueda determinarse, el contexto fiscal correcto y un consentimiento válido pueden acortar una compra repetida. Vuelve a comprobar el stock, los precios, la entrega y las opciones obligatorias antes de cobrar. Mantén los datos de pago con el proveedor y almacena solo los identificadores de cliente/método de pago del proveedor que necesite tu integración. No almacenes números de tarjeta sin procesar ni CVV en PrestaShop.

Por ejemplo, Anna vuelve a pedir café con una dirección y una tarjeta guardadas. Su siguiente pedido puede necesitar pocos datos, pero un cambio en el precio del envío o una autenticación bancaria pueden añadir un paso. Cuando envía el siguiente paquete a la dirección de una amiga, hay que volver a comprobar la disponibilidad de la entrega y el total. Un proceso de compra rápido y útil le permite corregir la dirección o completar la verificación del banco y le muestra después un resultado claro del pedido; no mantiene un número de clics reutilizando en silencio información antigua. Un visitante que compra por primera vez también puede tener una cartera configurada, aunque tu tienda no tenga ningún registro previo de ese cliente, así que valora ambos recorridos por la exactitud de los datos y una compra completada, no por el historial de registro.

Reconocer a un cliente con sesión iniciada no es lo mismo que tener el permiso y el soporte técnico para reutilizar un método de pago. Una entrada de la libreta de direcciones o un pedido anterior correcto no establecen que se pueda cobrar el siguiente pedido, y guardar una dirección no guarda una tarjeta. Pregunta al proveedor de la integración dónde se guardan los datos reutilizables, cómo los elige el cliente y cómo puede cambiar esa elección.

Un cliente que está comprando activamente usa un flujo de pago guardado on-session (con el cliente presente). Off-session describe un cobro iniciado por el comerciante mientras el cliente no está. No marques un cobro interactivo del proceso de compra como off-session solo para evitar la autenticación. Gestiona la autenticación necesaria y los resultados asíncronos según la integración del proveedor, y pregunta al proveedor de la integración cómo se gestionan la confirmación del cliente, el permiso para pagos guardados y una verificación de autenticación.

1. Recalcula y valida el carrito en el servidor.
2. Confirma la autorización del cliente mediante el flujo compatible del proveedor.
3. Verifica el resultado de pago fiable, el importe, la moneda y la correspondencia con el carrito.
4. Crea o actualiza el pedido de PrestaShop de forma idempotente. Gestiona las llamadas de retorno duplicadas y los reintentos.
5. Concilia el estado final de pagado, fallido, pendiente o reembolsado.

Un fragmento de creación de PaymentIntent no completa este ciclo de vida del pedido. Los métodos sin conexión también pueden simplificar el pedido sin tokenizar una tarjeta, pero el pedido resultante puede seguir sin pagar y necesitar conciliación bancaria o pago contra reembolso. No se puede garantizar un número literal de toques ni una compra sin autenticación.

Elige integraciones de pago y resuelve sus problemas

ps_checkout, PrestaShop Checkout, es una integración de pago, no el nombre de todo el proceso de compra. Gestiona opciones de pago, autorización/captura, transacciones y reembolsos mediante su integración compatible con PayPal. El comerciante conecta una cuenta PayPal Business. Revisa las condiciones de liquidación y abono de tu cuenta de comercio conectada.

Su inclusión depende de la distribución y la fecha. Comprueba el módulo instalado y la versión compatible. Usa el repositorio oficial del módulo para su documentación y la guía oficial de transacciones para los estados de pago. Existen vías oficiales de resolución de problemas de cuenta y soporte; sigue sus condiciones publicadas.

Para instalar, incorporar la cuenta y eliminar la integración, usa la documentación oficial de PrestaShop Checkout. Antes de desactivar un proveedor, confirma que queda otra vía de pago operativa.

Puedes evaluar Stripe, Mollie, PayPal, Adyen, Amazon Pay e integraciones específicas de pago a plazos como Klarna, Alma o Clearpay/Afterpay frente a tus requisitos. Verifica el módulo de PrestaShop concreto en lugar del número de métodos que ofrece el proveedor en todo su catálogo. Compara el soporte de autorización, los reembolsos, las disputas, la liquidación, las monedas, los requisitos de la cuenta, los pagos recurrentes, los informes y el soporte. La guía de pagos trata con más detalle la elección y la gestión de los métodos.

Entre los métodos regionales que puedes investigar están iDEAL para Países Bajos, Bancontact para Bélgica, BLIK o Przelewy24 para Polonia, SEPA u opciones de factura para Alemania/Austria, Cartes Bancaires o pagos a plazos para Francia, Bizum para España, Satispay o MyBank para Italia y opciones de banca abierta para Reino Unido. Son ejemplos para investigar, no promesas de disponibilidad en tu módulo. No planifiques integraciones nuevas en torno a los servicios independientes retirados SOFORT o Giropay. Consulta la documentación actual de métodos del proveedor.

Compara las comisiones reales para tu entidad jurídica, método, origen de la tarjeta, moneda, conversión de divisas, pagos fallidos, reembolsos y disputas. Un módulo gratuito puede seguir teniendo costes de procesamiento. La transferencia bancaria evita la comisión de una pasarela de tarjetas, pero puede tener comisiones bancarias y requerir conciliación manual. Comprueba los fondos recibidos antes de preparar el pedido; consulta el módulo nativo de transferencia bancaria.

Para cualquier método diferido, define cuándo puede prepararse un pedido y quién confirma la recepción de los fondos: una confirmación de pedido no demuestra que haya llegado el pago, así que incluye ese trabajo de conciliación del personal en la elección. Si recibes transferencias en varias cuentas o monedas, Bank Transfer Accounts muestra a los clientes la cuenta correspondiente a la moneda de su pedido, con el importe y la referencia del pedido, en la página de confirmación, en el email de instrucciones y en la página de detalles del pedido; sigues siendo tú quien confirma la recepción y actualiza el pedido.

Preguntas para el proveedor de pagos y el del módulo

• ¿Está disponible cada método necesario para nuestra entidad jurídica, mercados de clientes, monedas y versión del módulo?
• ¿Dónde encontrará el personal las referencias de transacciones, conciliará abonos y gestionará reembolsos totales o parciales?
• ¿Quién gestiona fallos de integración, restricciones de cuenta y disputas de pago, y qué pruebas necesitará soporte?
• Tras un cambio, ¿dónde se procesan y registran los reembolsos de los pedidos cobrados con el módulo anterior?

No hay ningún método de pago disponible

1. Comprueba los módulos activos y las restricciones de Pago > Preferencias para moneda, país, grupo y transportista.
2. Comprueba las credenciales del proveedor, el estado de la cuenta, los límites de importe y el modo real/de prueba.
3. Inspecciona las opciones realmente devueltas, los registros PHP y los errores del navegador.
4. Inspecciona las cabeceras de respuesta reales si se bloquean scripts. No supongas que PrestaShop 8/9 estándar tiene una CSP universal de compra que cause el fallo.

Las integraciones de pago modernas deben implementar paymentOptions. Los núcleos 1.7.8 y 9.1 también leen las rutas de compatibilidad displayPaymentEU y advancedPaymentOptions. Buscar solo el nombre de un hook antiguo no diagnostica la invisibilidad. Las restricciones de disponibilidad son distintas del orden: inspecciona la posición de paymentOptions en Diseño > Posiciones y cualquier ordenación interna del módulo de pago.

Prueba el envío dinámico, los descuentos y los requisitos B2B

Cambiar el país, código postal, cantidad o producto puede cambiar los transportistas, impuestos, métodos de pago disponibles y total. Conserva las selecciones aún válidas, borra de forma visible las inválidas e impide enviar el pedido mientras el recálculo esté incompleto. Prueba carritos reales pesados, virtuales, mixtos y de varios paquetes.

Como ejemplo, un artículo de 0,5 kg más uno de 25 kg suman 25,5 kg. Eso supera un límite hipotético de transportista de 20 kg, pero no uno de 30 kg. Otras dimensiones, zonas y restricciones pueden seguir excluyendo un transportista. Son límites de ejemplo, no condiciones publicadas de transportistas.

Las reglas del carrito tienen prioridades, reglas de compatibilidad, restricciones de clientes/productos, fechas y límites de uso. Una regla no acumulable del 20% y una regla separada de envío gratuito necesitan una configuración de compatibilidad probada. Un vale fijo de €10 puede entrar en conflicto con una regla automática del 15%. Las condiciones de acceso y la acción de descuento son controles diferentes.

El mínimo de una regla del carrito usa los totales de productos con los ajustes de impuestos y moneda seleccionados, más el envío cuando así se configura. Las reducciones de precio específicas de un producto ya afectan a esos totales. En PrestaShop 9.1, el cálculo también resta los regalos aplicables de las reglas que ya están en el carrito. Prueba un umbral de €100 con una cesta que lo cumple y otra justo por debajo, con productos con descuento, productos de regalo, conversión de moneda y el envío incluido o excluido.

Ensaya también un caso combinado. Una cesta tiene un descuento automático de producto, el cliente introduce un vale y debería aplicarse una promoción de entrega. Anota primero el resultado previsto: qué descuentos se combinan, qué transportistas cumplen las condiciones y el importe final a pagar. Repite después de cambiar la cantidad, el transportista y el país de entrega, y compara el resumen visible, el importe enviado al proveedor y el registro del pedido. Un vale rechazado debe dejar una explicación clara y una vía utilizable hasta el pago.

Las restricciones de transportista de las reglas de envío gratuito deben coincidir con las opciones previstas. Analiza la evaluación lenta de reglas antes de borrar reglas históricas; las fechas caducadas ya afectan a su aplicación. Conserva la configuración según tus necesidades operativas.

Un control compacto «¿Tienes un código?» puede reducir el ruido visual manteniendo utilizables los vales. La aplicación de códigos promocionales debe usar un flujo de carrito probado que gestione tokens. La URL simple addDiscount=1&discount_name=SUMMER10 no siempre basta, especialmente para clientes autenticados. Valida los requisitos en el carrito real.

Para B2B, especifica facturación/entrega separadas, datos de empresa, referencias de órdenes de compra, aprobación de cuentas y condiciones de pago acordadas. Una identificación VAT válida es solo parte del tratamiento transfronterizo del VAT; también importan las condiciones de la operación y los registros justificativos. Trata la indisponibilidad de VIES por separado de un resultado inválido. Consulta la guía de VAT transfronterizo de la UE.

Los campos adicionales necesitan un ciclo de vida completo: mostrarlos, validarlos, guardarlos y exponerlos donde se necesiten en pedidos, exportaciones o facturas. Una referencia de orden de compra solo es útil si se valida, se guarda con el pedido y la ve el personal o la exportación que la necesita; las instrucciones de entrega deben llegar a quien prepara el pedido. Hacer que un campo aparezca en una plantilla no es una implementación completa. Las ampliaciones del formulario de cliente pueden usar additionalCustomerFormFields y validateCustomerFormFields; la guía de hooks y overrides explica cómo se conectan a ellos los módulos. actionValidateOrder por sí solo no puede implementar el formulario.

Ese hook de creación de pedidos se ejecuta dentro de PaymentModule::validateOrder(), antes de la gestión posterior del estado. Puede ejecutarse para pedidos pendientes o sin conexión. Comprueba el estado de pago y la confirmación del navegador por separado de este hook. Usa las llamadas de retorno adecuadas del proveedor y la gestión de estados de pedido para las acciones de pago, stock y correo.

Haz que el recorrido sea fácil de usar en móviles

Usa analítica por categoría de dispositivo con eventos de compra operativos. El antiguo informe de navegadores y sistemas operativos es un informe de compatibilidad, no un embudo moderno de ingresos móviles. La intención del tráfico, la combinación de adquisición, las compras entre dispositivos y las lagunas de seguimiento también pueden explicar las diferencias entre dispositivos.

Classic sigue siendo habitual en tiendas antiguas y actualizadas. Hummingbird pasó a ser el predeterminado para instalaciones nuevas de PrestaShop 9.1. Ni una etiqueta de diseño adaptable ni un tema nuevo garantizan ausencia de desbordamientos, teclados utilizables o módulos accesibles.

• Usa type="email" y autocomplete="email" para correo, y type="tel" con autocomplete="tel" para teléfono.
• Usa campos de texto para códigos postales. Añade inputmode="numeric" solo para el formato numérico del país elegido. Los formatos británico, neerlandés y canadiense necesitan letras.
• Usa los tokens de autocompletado adecuados para nombre y dirección. Inspecciona los campos realmente generados. El formulario moderno de direcciones usa customer/_partials/address-form.tpl y renderizado compartido de campos, no un supuesto archivo de entrada entre los parciales de compra.
• Usa controles grandes y espaciados y filas de transportista/pago totalmente etiquetadas. Un área de interacción de 44 a 48 píxeles CSS es una opción práctica de diseño; comprueba el tamaño y espaciado de los controles en dispositivos reales.
• Mantén accesibles el total actualizado y la vía de revisión. Asegúrate de que los controles fijos de envío del formulario no tapen condiciones, errores, chat ni controles de consentimiento.
• Conserva los valores escritos, el foco visible y los mensajes de error específicos junto a los campos.

En el resto de la tienda móvil, usa menús desplegables por toque con enlaces a las categorías superiores, un panel de filtros utilizable, información de producto legible y ventanas emergentes que puedan cerrarse. Mantén el contenido importante y los datos estructurados disponibles en el renderizado móvil. Usa tamaños de imagen adaptables y carga diferida bajo el primer pantallazo sin retrasar la imagen principal.

Los enlaces telefónicos pueden ayudar en móviles y aplicaciones de llamadas de escritorio compatibles. Los productos vistos recientemente y el botón fijo de añadir al carrito son opciones para probar en el tema o módulo instalado, no comportamientos nativos universales. Compara las salidas de categorías, el descubrimiento de productos y las compras junto con la finalización del proceso de compra.

Analiza las solicitudes de compra en una copia de preproducción aislada. Los hooks de módulos, las llamadas externas de tarifas/impuestos/direcciones, la resolución de transportistas, las reglas del carrito, las consultas a la base de datos y los scripts son posibles cuellos de botella. Usa _PS_DEBUG_PROFILING_ solo donde su salida sea privada. Activa las opciones de caché y recursos de producción solo tras probar el flujo de pago resultante. Mantén las respuestas personalizadas de carrito, compra y JSON fuera de las cachés compartidas de página completa/CDN.

Usa PageSpeed Insights/Lighthouse actuales, Search Console y pruebas en dispositivos reales. La antigua prueba de optimización para móviles de Google está retirada. Prueba conexiones móviles, teléfonos compatibles, autocompletado activado y desactivado, cambios de país, todos los métodos de pago ofrecidos, cancelaciones de autenticación y reintentos. Redimensionar una ventana de escritorio no prueba el teclado real ni la cartera.

Restaura carritos e investiga los fallos de actualización

Los clientes con sesión iniciada pueden recuperar carritos abiertos utilizables según el comportamiento del carrito al iniciar sesión de la tienda. La recuperación de invitados depende principalmente de la cookie del navegador que identifica el carrito. Borrar cookies, cambiar de dispositivo o usar sesiones privadas puede romper esa asociación aunque la fila de la base de datos siga existiendo. Los carritos con pedidos ya no son cestas abiertas.

PS_COOKIE_LIFETIME_FO controla la duración de la cookie de la tienda, no la conservación del carrito en la base de datos. Localiza el campo de duración de cookie correspondiente en la administración de tu versión y confirma su valor en el contexto de tienda correcto. Los ajustes de cookies han cambiado de página de administración entre versiones.

1. Reproduce el problema con un producto, combinación, cantidad, cliente y país concretos, y anota la URL que falla y la hora. Abre Console y Network en las herramientas del navegador.
2. Inspecciona la solicitud y respuesta del carrito. Un estado 200 puede contener un error de aplicación o HTML donde se esperaba JSON. Un 500 requiere registros de PHP/servidor; un 403 requiere comprobar tokens, permisos, WAF y seguridad.
3. Repite la solicitud real del navegador solo en un contexto de pruebas seguro con sus cookies de sesión y el token actual. Un ejemplo curl inventado con token estático no es una prueba fiable del carrito.
4. Vacía las cachés de plantillas/recursos pertinentes en Parámetros avanzados > Rendimiento. Desactiva temporalmente la combinación de recursos en preproducción si un paquete combinado oculta el fallo.
5. Comprueba el dominio de cookies, HTTPS, el comportamiento SameSite/Secure y cualquier almacenamiento de sesiones con balanceo de carga. Verifica la gestión de www y sin www.
6. Revisa los hooks de módulos relacionados con el carrito y aísla los conflictos en una copia de pruebas con copia de seguridad y un plan de reversión. Desactiva grupos y acota después hasta el módulo responsable. Vuelve a probar los callbacks del proveedor tras el cambio.

Trata los hallazgos sobre el dominio, las cookies y los módulos como pistas de investigación hasta que el fallo se reproduzca y la corrección lo elimine. Regenera o purga la caché correspondiente de la CDN o de los recursos tras una corrección. La caché compartida debe omitir los endpoints del carrito propios de cada cliente. Un error de JavaScript puede detener el flujo afectado, pero un solo error no demuestra automáticamente que hayan dejado de ejecutarse todos los scripts de la página.

Protege el pago y recupera los carritos abandonados restantes

Sirve los recursos del proceso de compra y del proveedor por HTTPS válido. Comprueba el contenido mixto, las URL de retorno y la accesibilidad de los callbacks. Prioriza los campos alojados por el proveedor o el proceso de compra alojado cuando proceda, y mantén los datos de tarjeta sin procesar fuera de los registros de la aplicación y de los formularios de la tienda. No añadas código a medida que envíe datos de tarjeta sin procesar a través de tu tienda.

El alcance PCI depende de la implementación completa. Los iframes alojados o las redirecciones no garantizan por sí solos el cumplimiento de los requisitos de SAQ A. Para formularios integrados, los criterios actuales de SAQ A incluyen confirmar que la página del comerciante no es vulnerable a ataques de scripts. Confirma la evaluación aplicable con la entidad que acepta tu declaración de cumplimiento. Sigue la guía de requisitos de PCI SSC; no decidas entre SAQ A y A-EP solo por la presencia de JavaScript del proveedor.

Los requisitos de autenticación reforzada de clientes tienen exenciones y transacciones fuera de su alcance. 3D Secure es un mecanismo compatible con integraciones de tarjetas, no el reglamento en sí. Algunas transacciones se completan sin un desafío visible; otras requieren autenticación. Prueba éxito, rechazo, cancelación, tiempos de espera y regreso desde una página externa de pago.

La conservación del carrito y el email de recuperación son funciones distintas. El almacenamiento nativo de carritos no envía recordatorios automáticamente. Una herramienta específica o una integración de marketing puede encargarse de la recuperación, según las normas de mensajería aplicables y las condiciones de consentimiento o de soft opt-in. Consulta la ayuda de Sales Revolution y la ayuda de Klaviyo Integration.

Un recordatorio puede ayudar a un comprador cuya compra se interrumpió o que quería más tiempo. También puede devolverlo al mismo error sin resolver. Corrige los fallos confirmados del proceso de compra y mide la recuperación por separado. Incluye costes de mensajería, descuentos, preparación y soporte al evaluar los beneficios. Respeta las bajas y no supongas que un recordatorio sin descuento es puramente transaccional.

Ensaya el recorrido del pedido antes del cambio en producción

Mantén una referencia con fecha y hora y una vía de reversión para los cambios en el proceso de compra. Antes de sustituir, desactivar o desinstalar un módulo de compra o de pago, haz una copia de seguridad de archivos y base de datos, trabaja en una copia de pruebas y prueba la vuelta atrás. Aísla el entorno de pruebas de los pagos reales, del correo a clientes y de la preparación de pedidos. Sigue las instrucciones de eliminación del módulo y conserva los registros y accesos necesarios para los pagos y reembolsos existentes; la guía de eliminación de módulos explica qué conservar.

• Cliente nuevo: una compra como invitado cuando se ofrezca y después una compra con registro, en móvil y escritorio. Comprueba los campos obligatorios y los datos de entrega y facturación separados.
• Cliente que vuelve: selección de una dirección guardada, un cambio de dirección y el flujo de pago guardado o de cartera que haya confirmado el proveedor.
• Producto y carrito: una combinación, una personalización obligatoria y una cesta con varios artículos. Confirma que una ventana exprés compra el contenido previsto.
• Entrega y totales: cambia el país y el transportista a mitad del proceso, aplica un vale y comprueba los importes finales de impuestos y entrega para cada país, moneda y grupo de clientes al que vendes.
• Pago: éxito, rechazo, autenticación completada y cancelada, confirmación retrasada, cierre del navegador y una notificación repetida, con el procedimiento de pruebas admitido por el proveedor.
• Operaciones: totales, facturas, cambios de stock, emails de confirmación, reembolsos, registros del proveedor y exportaciones a contabilidad o a preparación de pedidos, incluida cualquier integración a medida.

Valora cada escenario por esos registros, no solo por la pantalla de confirmación. Comprueba que un pago rechazado o una autenticación cancelada muestren un resultado de pago claro, conserven el carrito previsto y permitan reintentar o cambiar de método sin un cargo duplicado no deseado. Registra el estado de pedido y de pago esperado para cada método: una transferencia pendiente y un pago con tarjeta confirmado no deben compartir la misma expectativa de preparación. Comprueba expresamente la prevención de pedidos duplicados: actualizar o volver a visitar la página de confirmación no debe crear un segundo pedido ni un segundo cargo no deseados.

Pide pruebas al proveedor, no un adjetivo de velocidad

• ¿Qué recorrido usa tus módulos de pago actuales y cuál usa la integración de pago propia del módulo? ¿Qué versiones exactas se comprobaron?
• ¿Un botón en la página de producto compra el artículo seleccionado o la cesta, y cómo se revisan las variantes, la personalización y un cambio de dirección?
• ¿Qué requisito de pago guardado o monedero se admite y qué ocurre si la autenticación se rechaza o cancela?
• ¿Cómo concilia el personal un pago completado después de cerrar el navegador, y cómo se restaura el proceso de compra anterior si fallan las comprobaciones del lanzamiento?

Pide a la agencia que entregue un inventario de versiones, los escenarios de compra acordados, las pruebas realizadas, la configuración guardada y los pasos de reversión, y que indique quién se encarga de los pagos retrasados, los reembolsos y la supervisión tras el lanzamiento.

Tras el lanzamiento, concilia los pedidos nuevos con las transacciones del proveedor. Si fuera necesario revertir, ten en cuenta las ventas realizadas desde la copia de seguridad antes de restaurar una base de datos. Compara los pedidos pagados completados, los fallos de pago y los problemas de soporte por dispositivo y tipo de cliente con tu propia referencia.

Preguntas de propietarios de tiendas

¿Es posible comprar en un clic en PrestaShop?

Una sola acción puede realizar un pedido cuando la identidad, la dirección, la entrega y el acuerdo de pago ya están resueltos. Los flujos de pago guardado requieren una reutilización admitida y el permiso del cliente; un método sin conexión puede realizar un pedido sin pagar sin datos de tarjeta reutilizables. Incluso así, un cambio de dirección, un transportista no disponible o una solicitud de autenticación bancaria añaden un paso, así que describe el proceso de compra como rápido sin prometer el mismo número de acciones a todos los compradores.

¿Una tienda con clientes mayoritariamente nuevos debe aspirar a un clic?

Empieza por la compra como invitado cuando proceda, los totales mostrados pronto y un formulario fácil de usar, y prueba después una cartera compatible. Un atajo para clientes que vuelven resuelve poco de lo que encuentran los compradores primerizos.

¿Instalar ps_checkout nos dará un proceso de compra en una página?

No. Añade opciones de pago basadas en PayPal al paso de pago. En 9.2, la cuestión del diseño corresponde al módulo nativo de una página; en versiones anteriores, a un módulo de compra o a un desarrollo a medida.

¿Necesitamos Checkout Revolution y Express Checkout a la vez?

Normalmente no. Ambos ofrecen una ventana de compra en las páginas de producto, los listados y el carrito, y ambos convierten en pedido un pago completado después de cerrar el navegador. Elige según si el requisito es una sola página con tus transportistas y pagos existentes o una ventana de compra basada en Stripe; ninguna de las dos descripciones garantiza que funcionen juntos, así que prueba la combinación en el entorno de pruebas antes de activar ambos.