Que un administrador compre correctamente no demuestra que el checkout público funcione. Los administradores suelen evitar la caché, conservan cookies antiguas, tienen otras capacidades y pueden ver reglas de pago o envío diferentes.
Usa esa diferencia como evidencia y compara peticiones controladas desde sesiones separadas.
Reproduce como visitante real
Abre un navegador privado donde nunca hayas iniciado sesión. Añade el mismo producto, país y método de pago. Prueba por separado como invitado y como cliente normal.
Después de cada intento consulta pedidos y pasarela. Si la ruta pública crea un pedido o cobro, no repitas hasta aclarar su estado.
Anota URL, hora, total y error exacto con datos sintéticos.
Compara el comportamiento de caché
Muchos sistemas excluyen a quien lleva cookie de login. El administrador recibe PHP fresco mientras el invitado puede recibir un checkout antiguo o compartido.
Compara estas cabeceras:
Cache-Control
Age
CF-Cache-Status
X-Cache o estado propio del hostingCarrito, Checkout, Mi cuenta y endpoints AJAX deben evitar caché pública. Corrige la regla, purga, deja que vuelva a poblarse y prueba otra vez. Un único MISS no demuestra la solución.
Compara también el HTML y los fragmentos de checkout recibidos por ambas sesiones. Una regla puede excluir la URL principal y seguir cacheando un bloque de totales, nonce o métodos. La respuesta pública no debe contener identificadores ni disponibilidad calculada para la sesión administrativa.
Compara cookies y sesiones
El navegador del administrador puede tener sesión WooCommerce válida, consentimiento aceptado y experiencia previa en el dominio canónico. Inspecciona las cookies del invitado entre producto, carrito y checkout.
Comprueba si el gestor de consentimiento bloquea cookies funcionales a nuevos usuarios. Prueba los estados aceptado, rechazado y sin decidir según la configuración legal.
No reclasifiques cookies de marketing como esenciales para simplificar.
Busca código dependiente del rol
Revisa tema y plugins propios por comprobaciones de capacidad, login o retornos anticipados alrededor de precios, checkout, envío y pago.
Pistas habituales son is_user_logged_in(), current_user_can() y condiciones sobre roles. Inspecciona hooks PHP y JavaScript localizado de forma distinta por usuario.
No edites el tema padre. Aplica la corrección probada en child theme o plugin pequeño con historial y reversión.
Compara pago y transporte
Las pasarelas y métodos pueden depender de moneda, país, código postal, total, clase de producto, rol o dirección guardada. Un administrador con datos prellenados quizá nunca entra en la rama fallida.
Registra paquetes y tarifas de la petición pública. Confirma impuestos y totales antes de culpar a la pasarela.
Un envío ausente puede detener el checkout aunque el CSS oculte el mensaje.
Revisa seguridad solo para público
El WAF, bots o rate limiting pueden desafiar AJAX anónimo y permitir al administrador conectado. Relaciona 403 o challenge con eventos mediante hora, URI e identificador seguro.
Crea la excepción mínima para tráfico legítimo de WooCommerce. No desactives el firewall ni autorices peticiones arbitrarias a endpoints sensibles.
Comprueba también ModSecurity y plugins de seguridad.
Elimina ventajas del test administrativo
El administrador puede usar transferencia, ver productos ocultos, evitar stock o tener extensiones del navegador diferentes. Escribe cada diferencia de producto, cuenta, dirección, cupón, dispositivo y pago.
Usa staging para aislamiento invasivo, pero separa callbacks y emails de producción. Nunca debe procesar transacciones reales por accidente.
Repara y verifica el checkout anónimo
Corrige la capa demostrada: exclusiones de caché, consentimiento, condición de rol, método o firewall. Prueba después invitado nuevo, invitado recurrente y cliente con sesiones limpias.
Verifica pedido, pago, estados, stock, emails y página de gracias. Mantén la prueba administrativa, pero no como única aceptación.
Repite después de cerrar todas las sesiones de prueba y desde otra red controlada. Así descartas que una allowlist de IP, una cookie de seguridad o una excepción temporal esté haciendo pasar el test sin reparar a los clientes.
El mantenimiento recurrente debe incluir checkout anónimo tras cambios de caché, seguridad, consentimiento, tema o WooCommerce. Estos fallos son graves precisamente porque el personal puede no verlos.