Los clientes no pueden finalizar la compra en PrestaShop: qué revisar

Identifica el último paso que sí funciona

Pregunta qué ocurrió justo antes del problema: añadir al carrito, identificarse, guardar la dirección, elegir transporte, seleccionar pago o volver de la pasarela. Un botón que no responde y un pedido sin confirmación son situaciones distintas.

La documentación del recorrido de compra y pedido en PrestaShop ayuda a situar esas fases. Para la revisión, interesa relacionar el paso concreto con las funciones que intervienen en tu tienda.

Conserva el mensaje exacto y la hora aproximada. Si se trata de un cliente real, evita pedirle que repita indefinidamente la operación. Puede existir un pedido o una autorización de pago que todavía no se haya reflejado como esperaba.

Comprueba si el fallo depende de un tipo de cliente o carrito

Compara un caso que falla con otro que funciona. La diferencia puede estar en el país, la moneda, el grupo de clientes, un producto o una regla comercial. Registrar esas condiciones es más útil que afirmar que «a veces no deja pagar».

Utiliza ejemplos sin datos personales al preparar la consulta. Si el problema requiere información de un pedido real, acuerda cómo compartirla con el equipo de soporte.

Cuándo solicitar soporte por un error de compra

Solicita soporte si el fallo se repite, afecta a varios compradores o hay diferencias entre cobros y pedidos. Si todavía no conoces la causa, no necesitas resolverla antes de consultar: basta con aportar un caso y el momento aproximado.

Antes de una campaña, comprueba compras representativas con las promociones, destinos y métodos que vas a ofrecer. Que ayer funcionara un pedido sin descuento no valida el carrito promocional de hoy. Si la incidencia ya está activa, prioriza su diagnóstico sobre un rediseño.

Puedes copiar este resumen para solicitar soporte técnico PrestaShop: «URL: …; empezó: …; último paso que funciona: …; mensaje: …; afecta a: …; pedido o pago localizado: sí/no/sin comprobar; último cambio conocido: …». Omite contraseñas y datos personales. Con esta información se puede delimitar la investigación sin empezar por cambios generales.

Cuando no aparece un transportista o no se puede continuar

La ausencia de transporte puede depender de condiciones del pedido y no de un fallo general. Hay que revisar las reglas aplicables al destino, los productos, el peso, el importe y los módulos utilizados.

Un ejemplo orientativo: si el proceso funciona para una dirección y falla para otra, conviene comparar sus condiciones antes de modificar todos los transportistas. Esa diferencia orienta la investigación, pero no confirma por sí sola una causa.

Registra también si la disponibilidad cambia al modificar la dirección o las cantidades. El técnico necesita saber si el checkout recalcula correctamente y si conserva una selección que ya no es válida.

Cuando falta un método de pago o falla su retorno

La disponibilidad de un método puede depender de reglas y compatibilidades. La referencia del ciclo de pedidos explica que existen restricciones por condiciones como país, moneda o grupo. Revisa cuáles se aplican en el caso afectado.

También conviene separar la selección del pago, la operación en el proveedor externo y la confirmación del pedido. La documentación de módulos de pago describe diferentes escenarios de integración; no todos siguen el mismo recorrido visible.

Si el cliente informa de un cobro, comprueba el registro de la pasarela y el de la tienda antes de indicar que vuelva a intentarlo. La pantalla de confirmación no es la única evidencia de lo ocurrido.

Qué revisar si comenzó después de un cambio

Recopila las últimas actualizaciones, modificaciones del tema y cambios en módulos, configuración o servicios externos. Anota el momento en que se aplicaron y si existe un ensayo anterior con el que comparar.

Una personalización visual puede afectar a la interacción de un formulario; una actualización de un módulo puede cambiar una dependencia. Son hipótesis que deben contrastarse con registros y pruebas, no motivos para desactivar componentes al azar.

Si hay un entorno separado, prepara un caso equivalente y controla las conexiones de prueba. No siempre será posible reproducir exactamente un incidente externo, por lo que hay que dejar claro qué se ha comprobado y qué queda pendiente.

Qué enviar a soporte y qué decisiones conviene coordinar

Envía un resumen breve con el paso, el ejemplo de condiciones, el mensaje, el momento de inicio y los cambios recientes. Añade si hay pedidos o transacciones afectados y cómo se ha comprobado su estado.

Cuando el impacto sea relevante, acordad quién decide las medidas temporales y cómo se informará al equipo. Detener un método de pago o modificar reglas puede afectar a compradores que no tenían el problema; debe valorarse el alcance.

En e-shop360 puedes solicitar soporte técnico PrestaShop para estudiar una incidencia de compra. Si después se necesita modificar el proceso, se podrá valorar por separado el desarrollo de la adaptación.

Cómo validar que los clientes vuelven a poder comprar

Repite el caso que fallaba y una selección de recorridos relacionados. Comprueba pedido, importe, estado y comunicación con los sistemas implicados. Deja constancia de las pruebas y de cualquier limitación.

¿El problema del pago siempre corresponde al banco?

No. Puede estar en la configuración, el módulo, la interacción del checkout o el servicio externo. Hay que contrastar la operación en los puntos relevantes.

¿Si una compra funciona ya está resuelto?

Es una comprobación útil, pero puede no representar el destino, cliente o carrito afectados. Hay que validar las condiciones que reproducían el fallo.

¿Hay que cambiar todo el checkout?

No necesariamente. La intervención debe responder a la causa comprobada y conservar las funciones que el negocio necesita.