Evaluación inicial sin contraseñas Presupuesto antes de intervenir Especialista responsable de principio a fin

Sintomas Carrito Checkout

El checkout de WooCommerce sigue cargando y no crea el pedido

Diagnostica un checkout infinito rastreando la petición, errores PHP, sesiones, pasarela, caché y JavaScript.

Un spinner que nunca termina suele indicar que el navegador envió la compra pero no recibió una respuesta utilizable. Puede existir un error PHP, una pasarela lenta, una petición AJAX bloqueada, una sesión rota o JavaScript incapaz de procesar la respuesta.

No pulses varias veces. Comprueba primero si WooCommerce creó un pedido o la pasarela cobró, porque los reintentos pueden duplicarlos.

Conserva un intento fallido

Anota hora exacta, email sintético, carrito, método de pago, navegador y total. Utiliza un producto controlado y el modo de pruebas de la pasarela cuando esté disponible.

Busca pedidos de esa hora, incluidos Pendiente de pago, Fallido y Borrador. Si existe uno, el fallo ocurrió después de que WooCommerce empezara a procesar.

Ante clientes reales, revisa pedidos y proveedor antes de reproducir.

Inspecciona la petición del checkout

Abre Network, envía una vez y localiza la petición con wc-ajax=checkout. Debe finalizar con un estado HTTP y normalmente devuelve JSON.

Petición: /?wc-ajax=checkout
Anota:
- código HTTP
- tiempo de respuesta
- tipo y cuerpo de respuesta
- redirección o mensaje de bloqueo

Un 500 apunta a PHP o servidor; un 403, a firewall o seguridad. Una petición pendiente sugiere timeout, workers ocupados o una llamada externa lenta. Un 200 con HTML en vez de JSON puede ser un warning, login o error cacheado.

Correlaciona logs PHP y WooCommerce

Consulta WooCommerce > Estado > Registros y el log PHP del hosting en la misma hora. Activa debug temporal solo si puedes impedir su visualización pública y la captura de datos personales.

No atribuyas el problema a cualquier warning antiguo. Relaciona hora, archivo y stack. Un fatal en la pasarela, campos de checkout o plantilla sobrescrita pesa más que un aviso ajeno de cron.

Separa la pasarela del fallo común

Prueba de forma segura con transferencia bancaria u otro método offline. Si funciona y la pasarela normal se queda cargando, revisa credenciales, API, firewall y log del proveedor.

Si fallan todos los métodos, céntrate en PHP, sesiones, WooCommerce y personalizaciones compartidas.

No cambies una pasarela de producción a test sin conocer el efecto sobre compras reales.

Revisa sesión, caché y llamadas

Excluye Carrito, Checkout y Mi cuenta de la caché de página. Confirma que las cookies WooCommerce sobreviven entre producto, carrito y pago. Cloudflare y el plugin de caché no deben servir el estado de un visitante a otro.

Prueba una sesión limpia en ventana privada, pero conserva por separado la sesión fallida. Borrar todas las sesiones destruye evidencia y carritos activos sin demostrar la causa.

Comprueba también bloqueos de base de datos y workers PHP si la petición queda pendiente.

Diagnostica JavaScript sin ocultar el servidor

En Console empieza por el primer error, no por la cascada posterior. Consentimiento, autocompletado, Analytics o un plugin de campos pueden interceptar el envío.

Aísla una integración sospechosa en staging o mediante una prueba controlada; no desactives plugins al azar en la tienda activa.

El error de JavaScript puede ser consecuencia de HTML inválido devuelto por el servidor. Lee siempre la respuesta antes de culpar al navegador.

Aplica la corrección mínima

Actualiza o revierte el único componente incompatible, corrige el fatal PHP, arregla la exclusión de caché, aumenta un recurso realmente agotado o restaura la conexión con la pasarela.

Purga únicamente los assets afectados y verifica el archivo nuevo como visitante anónimo. Documenta qué cambió y cómo revertirlo.

No ocultes el spinner ni fuerces una redirección sin confirmar el pedido.

Verifica toda la transacción

Prueba compra como invitado y usuario, móvil y escritorio, impuestos, envío, cupones, stock, emails, estado de pasarela y página de gracias.

Confirma en WooCommerce y proveedor que existe exactamente un pedido y un cobro. Revisa también intentos inciertos del intervalo de la incidencia.

La reparación urgente termina cuando se puede comprar y no quedan transacciones dudosas. El mantenimiento recurrente debe alertar sobre errores de checkout, webhooks y estados anómalos antes de perder ventas.

ANTES DE ENVIAR LA SOLICITUD

Preguntas frecuentes.

¿Pedís contraseñas en el formulario?+

No. El formulario público nunca solicita accesos. Los datos seguros se piden únicamente después de aprobar el alcance y el presupuesto.

¿Quién revisa la incidencia?+

La solicitud llega a Jordi Ensenyat, fundador de Code Barcelona y especialista WordPress con más de 15 años de experiencia.

¿Se cambia algo antes del presupuesto?+

No. Primero se revisan los síntomas visibles y se define el alcance. La intervención empieza tras la aprobación y con una vía de vuelta preparada.

¿Trabajáis con webs en inglés y fuera de España?+

Sí. WP Repair atiende incidencias WordPress y WooCommerce en inglés y español, con servicio remoto.

Evaluar mi incidencia