Respuesta breve: el checkout atraviesa JavaScript del navegador, sesión y carrito, petición al servidor, pasarela de pago y creación del pedido. El mismo síntoma visible puede venir de cualquiera, así que identifica la capa que falla antes de tocar la configuración.
Protege primero los datos
No repitas el pago con una tarjeta real ni borres pedidos fallidos para “ordenar”: esos registros y el historial de la pasarela indican si hubo movimiento de dinero. Anota la hora, el método de pago, el dispositivo y cualquier referencia de transacción antes de cambiar nada.
Observa la petición que falla en el navegador
Abre las herramientas de desarrollador, ve a Consola y Red e intenta el checkout. Un error de JavaScript en rojo apunta a un conflicto de scripts o a una minificación rota. La petición clave es ?wc-ajax=checkout: si devuelve 500 o agota el tiempo, el fallo es del servidor y su respuesta suele contener el propio error de PHP.
Lee los registros de WooCommerce
Ve a WooCommerce › Estado › Registros por los registros de la pasarela y errores fatales con hora, y a Estado › Estado del sistema por una base de datos desactualizada, una plantilla sobrescrita antigua o un conflicto de plugins. Contrasta la hora de una prueba fallida con el registro para ver si el pedido se creó, si se intentó el pago y dónde se rompió la cadena.
Sospechosos habituales
- Caché: la página de checkout nunca debe cachearse: una página antigua lleva un nonce caducado que bloquea el envío. Excluye carrito, checkout y mi-cuenta de la caché de página completa y del CDN.
- Optimización JS: minificar/combinar de forma agresiva rompe los scripts del checkout; exclúyelos.
- Conflicto de plugins: pruébalo en staging en lugar de desactivar plugins de pago o impuestos en producción.
- Confirmación de la pasarela: una autorización que tiene éxito sin confirmación deja el pedido atascado.
Verifica el ciclo completo
Usa el modo de pruebas de la pasarela o un pedido controlado de importe bajo y recorre producto → carrito → checkout → pago → confirmación. Después verifica el estado del pedido, el movimiento de stock, el correo de confirmación y el webhook. Un checkout solo está reparado cuando el ciclo completo termina de forma coherente, no cuando desaparece el error visible.
CRITERIO DE INCIDENTE WP REPAIR
Secuencia de intervención segura
El checkout es una cadena entre JavaScript, sesión, validación, pasarela, creación de pedido, stock y avisos. La primera transición rota identifica la capa que hay que reparar.
- Captura consola y respuesta wc-ajax de un intento controlado.
- Cruza la hora con logs fatales y de pasarela de WooCommerce.
- Verifica que carrito, checkout y cuenta se excluyen de caché completa y CDN.
- Usa modo de pruebas o pedido de importe bajo y registra cada cambio de estado.
Qué debe quedar verificado
- Un pedido controlado completa producto, carrito, pago y confirmación.
- La transacción y el pedido se referencian mutuamente.
- Stock, correo y webhook son correctos y repetibles.
Fuentes técnicas oficiales
Esta guía explica el diagnóstico. Si la web está afectada ahora, la intervención debe preservar una vía de vuelta y verificar el recorrido real del negocio.
Ver el servicio de reparación urgente →SOBRE ESTE SÍNTOMA
Preguntas frecuentes de esta guía.
¿Debo volver a probar un checkout fallido con una tarjeta real para ver si funciona?+
No, evitar repetidos intentos de tarjeta real y no eliminar los pedidos fallidos tampoco. Esos registros, junto con el registro de transacciones del gateway, son exactamente lo que le dice si el dinero realmente se movió, y destruirlos elimina la evidencia que necesita para diagnosticar el fracaso.
¿Qué petición única debo ver en el navegador para ver dónde checkout realmente se rompe?+
Mira la petición?wc-ajax=checkout en la pestaña Red mientras intenta checkout. Si devuelve un error de 500 veces, el fallo es del lado del servidor, y su respuesta a menudo contiene el error PHP subyacente directamente.
¿Puede realmente romper el caché checkout incluso si el rest del sitio se carga bien?+
Sí, y es una de las causas más comunes. La página checkout nunca debe ser enviada desde caché, porque una copia en caché rancio lleva una nonce de seguridad caducada que bloquea la presentación, por lo que cart, checkout, y las páginas de mi cuenta necesitan ser excluidas de caché de página completa y el CDN por completo.
¿Cómo sé si el problema es realmente corregido, versus sólo el error visible que desaparece?+
Camine el ciclo completo hasta el final utilizando el modo de prueba del gateway o un pedido controlado de bajo valor: producto, carro, checkout, pago, confirmación. Luego verifique el estado del pedido, el movimiento stock, el correo electrónico de confirmación, y el webhook todo completado coherentemente, no sólo que la página checkout dejó de mostrar un error.