Si al pulsar no aparece spinner, mensaje ni petición de red, el fallo suele ocurrir en el navegador antes de que WooCommerce reciba los datos. Puede haber un overlay invisible, botón deshabilitado, validación oculta, excepción JavaScript o código que cancela el submit.
Comprueba qué produce realmente el clic antes de cambiar servidor o pasarela.
Define qué significa “no hace nada”
Prueba una vez en ventana privada. Anota si cambia el botón, la página salta hacia un campo, aparece un error en Console o Network envía el checkout.
Revisa también pedidos recientes y el panel de la pasarela. Un cliente puede decir “nada” aunque la página fallara después del cobro.
Protege frente a duplicados antes de pedir un nuevo intento.
Comprueba si el botón recibe el clic
Inspecciona el elemento. Debe estar visible, habilitado y dentro del formulario. Usa el selector para descubrir si un banner de cookies, máscara, chat o capa transparente queda encima.
/* Solo para diagnóstico local o staging */
.capa-sospechosa {
outline: 3px solid red;
pointer-events: none;
}No dejes ese CSS en producción: puede inutilizar controles de consentimiento o accesibilidad.
Lee el primer error del navegador
Abre Console, recarga y pulsa una vez. Investiga el primer error nuevo; los siguientes pueden ser consecuencias.
Las fuentes habituales son plugins de campos, tema, autocompletado, consentimiento o JavaScript comprimido. Un objeto indefinido, error de jQuery o script bloqueado es una pista mejor que desactivar todo.
Comprueba CSP y extensiones del navegador. Repite con un perfil limpio antes de modificar la tienda.
Inspecciona campos y validación
WooCommerce puede impedir el envío por un campo requerido mientras el CSS oculta el aviso o el scroll. Busca aria-invalid="true" y contenedores de error en la parte superior.
Los campos propios necesitan nombre único, valor válido y validación equivalente en servidor. Prueba direcciones, teléfonos y códigos postales correspondientes al país seleccionado.
No elimines globalmente la validación para conseguir que pase una prueba.
Confirma el evento y la petición
Filtra checkout en Network y pulsa. Si no sale ninguna petición, el problema sigue en layout, JavaScript o validación. Si existe y devuelve error, analiza su estado y cuerpo: ya no es un fallo del botón.
Busca manejadores que llamen a preventDefault() sin reanudar el checkout. Revisa condiciones según método de pago, aceptación de términos o campos dinámicos.
Comprueba que no haya dos formularios con el mismo ID.
Aísla la integración responsable
Reproduce el diseño en staging con el mismo tema, tipo de checkout y datos relevantes. Desactiva primero la combinación de scripts si oculta el origen y prueba después una integración cada vez.
Cambiar temporalmente a un tema estándar puede demostrar que la capa del tema interviene, pero no es la reparación final. Localiza la plantilla, selector o script concreto.
Conserva evidencias y reversión de cada prueba.
Repara sin debilitar el checkout
Corrige el selector, handler, z-index, marcado inválido u orden de carga. Restaura los controles de consentimiento, fraude y pago que hayas aislado.
No uses snippets que habiliten el botón continuamente: pueden permitir pedidos incompletos o múltiples.
Purga solo la caché del asset afectado y confirma que el archivo corregido llega a un visitante sin sesión.
Verifica todas las rutas de cliente
Prueba invitado y cuenta, cada método activo, pulsación móvil, teclado, términos y errores de validación. Un pedido válido debe crearse una vez, reducir stock una vez y generar una transacción coincidente.
Comprueba que doble clic, retorno atrás y cambio de método no duplican acciones.
En mantenimiento recurrente monitoriza errores front-end y ejecuta un checkout de bajo riesgo después de actualizaciones de tema, WooCommerce, pasarela u optimización. Así el cliente no se convierte en el sistema de alerta.