¿Pagos fallando en horas punta sin patrón claro? Tiendas WooCommerce con plugins de caché o CDN suelen servir checkout estático, rompiendo nonces, cookies y fragmentos de carrito. Con pasos rápidos y comandos reproducibles se obtiene un diagnóstico fiable y un bypass temporal que restaura conversiones mientras se depura la causa.
Errores de caché en pagos: si el proceso de pago falla por caché, primero se debe purgar cachés (plugin, CDN y navegador) y excluir páginas críticas (checkout, carrito, mi-cuenta) y cabeceras que gestionan nonces y cookies. Revisar logs, cabeceras HTTP (Cache-Control, Vary, Set-Cookie) y reglas Nginx/htaccess; seguir el checklist para aislar CDN, plugin o servidor.
Resumen del proceso: recuperar pagos en 15 minutos
Sigue estos pasos en orden y en menos de 15 minutos tendrás un diagnóstico claro y un bypass temporal activo.
1) Reproduce el fallo y toma cabeceras con curl.
2) Desactiva/bypassea caché en CDN y plugin.
3) Verifica logs y pasarela; aplica reglas de servidor.
4) Purga por URL en el CDN y prueba en sandbox.
5) Aplica reglas definitivas en Nginx/htaccess y revisa cookies/Vary.
La comprobación que más rápidamente confirma origen es: si la cabecera CF-Cache-Status o X-Cache indica HIT y Age>0, la respuesta vino del borde y no del origin.
Paso 1: diagnostica origen y cabeceras
Toma evidencia inmediata con curl y decide si el origen del fallo es CDN, plugin o servidor en menos de 10 minutos.
Usa los comandos de abajo y guarda la salida para soporte.
¿Qué comprobar con curl?
Ejecuta este comando con cookies que simulen un carrito activo:
bash
curl -I -H 'Cookie: woocommerce_items_in_cart=1; wp_woocommerce_session=abc' https://tudominio/checkout
Busca estas cabeceras (cada una indica algo concreto): Cache-Control, Expires, Vary, Set-Cookie, Age, X-Cache, CF-Cache-Status.
Si aparece X-Cache: HIT y Age>0, el borde respondió con contenido cacheado.
¿Qué logs abrir primero?
Revisa PHP-FPM y error.log de WordPress para nonces o REST errors.
Mira access.log de Nginx/Apache para comparar requests con cookie y sin cookie.
Consulta el panel de la pasarela (Stripe/PayPal/Redsys) para ver intentos y duplicados.
El manejo de cabeceras Vary y las cookies en la cache key es crítico para evitar servir checkout estático. Evite emitir Vary: Cookie en páginas de pago; en su lugar marque esas rutas con Cache-Control: no-store o no-cache desde el origin y configure el CDN para pasar (pass) las peticiones cuando detecte cookies de sesión (wp_woocommerce_session, woocommerce_items_in_cart). Si necesita que el CDN mantenga caché para partes públicas, use surrogate-keys o tags y defina reglas de ‘pass’ por ruta o por presencia de las cookies; por ejemplo, en Fastly VCL: if (req.url ~ "^/(checkout|cart)") { return (pass); } y en Cloudflare cree Page Rules que hagan bypass de caché cuando existan cookies en rutas dinámicas.
También tenga presente que fragmentos de carrito y endpoints AJAX deben devolver Cache-Control: private o no-cache y un header Surrogate-Key propio (por Surrogate-Key: cart-fragment) para permitir invalidaciones granulares sin comprometer la seguridad de nonces y tokens.
Paso 2: aplica bypass en servidor y plugin
Activa un bypass inmediato en Nginx o htaccess y desactiva temporalmente la caché del plugin para confirmar si el fallo desaparece.
Este cambio demuestra si la caché local o la de borde causa el problema.
¿Qué regla poner en nginx ahora?
Snippet para Nginx (insertar en server block):
nginx
location ~* /(checkout|cart|my-account|wc-api|wp-json/wc) {
proxy_no_cache 1;
proxy_cache_bypass 1;
add_header Cache-Control "no-cache, no-store, must-revalidate";
}
map $http_cookie $no_cache {
default 0;
~woocommerce_items_in_cart 1;
~wp_woocommerce_session 1;
}
proxy_cache_bypass $no_cache;
¿Qué hacer en htaccess/Apache ahora?
Añade esto en el bloque .htaccess para marcar peticiones dinámicas:
apache
RewriteCond %{REQUEST_URI} ^/(cart|checkout|my-account) [NC]
RewriteRule .* - [E=NO_CACHE:1]
Header set Cache-Control "no-cache, no-store, must-revalidate" env=NO_CACHE
1 Reproducir fallo
curl con cookie; captura cabeceras
→
2 Bypass temporal
Nginx/htaccess + desactivar plugin
→
3 Purga CDN
Purgar por URL / invalidación por tag
Paso 3: configura CDN y purgas correctas
Configura reglas en el CDN para bypass completo de las rutas de pago y purga por URL o tag desde la API del CDN.
No confíe en la purga del plugin; el borde puede seguir sirviendo contenido.
¿Cómo crear una regla en cloudflare?
Page Rule "tudominio.com/checkout" → Cache Level: Bypass.
Usar Purge by URL via API para invalidar exactamente /checkout y /cart.
¿Cómo pasar en fastly o varnish?
En Fastly, usar VCL: si req.url ~ "^/(checkout|cart|my-account)" { pass; } y purgar por surrogate-key.
En Varnish, usar beresp.http.Cache-Control para forzar pass en rutas dinámicas.
| Opción |
Coste |
Tiempo de invalidación típico |
Idóneo para checkout? |
| CDN (Cloudflare/Fastly) |
Variable; puede ser gratuito o por plan |
10s–5min (por URL), invalidación global hasta 10min |
Sí, con bypass de rutas dinámicas |
| Plugin de caché (WP) |
Bajo |
Inmediato en origen; no garantiza borde |
No, salvo que coopere con el CDN |
| Cache en servidor (Varnish/Nginx) |
Medio |
Inmediato si se purga por URL |
Sí, con reglas precisas |
Para purgas y invalidaciones automáticas en el borde conviene ejecutar comandos reproducibles contra la API del CDN. Ejemplos prácticos: en Cloudflare puede invalidar por URL con curl: curl -X POST "https://api.cloudflare.com/client/v4/zones/{ZONE_ID}/purge_cache" -H "X-Auth-Email: tu@correo" -H "X-Auth-Key: TU_API_KEY" -H "Content-Type: application/json" --data '{"files":["https://tudominio/checkout","https://tudominio/cart"]}'. En Fastly es frecuente purgar por surrogate key: curl -X POST -H "Fastly-Key: $FASTLY_KEY" "https://api.fastly.com/service/$SERVICE_ID/purge/$SURROGATE_KEY" o usar la llamada de purge_all para emergencias; para purgar por URL en Fastly se puede usar: curl -X POST -H "Fastly-Key: $FASTLY_KEY" "https://api.fastly.com/purge/https:/tudominio/checkout".
Guardar y adjuntar la respuesta JSON de la API (status, id) en el ticket ayuda a verificar que la invalidación llegó al borde. Estos ejemplos permiten purgas selectivas rápidas sin depender sólo del panel UI del CDN.
Errores que arruinan el checkout
Identifica y corrige estos fallos que suelen aparecer en picos de tráfico o tras despliegues.
Evitarlos reduce cobros duplicados y reintentos fallidos.
¿Qué errores son los más frecuentes?
El error más frecuente en este punto es purgar solo el plugin y no invalidar el CDN, lo que deja el borde sirviendo páginas viejas.
Otro problema común es cachear el checkout sin excluir cookies o nonces.
¿Qué consecuencias provocan en pagos?
Nonces expirados dan error al enviar el formulario y la pasarela puede abortar.
Timeouts en el borde pueden duplicar intentos y causar cobros dobles si no hay idempotencia.
Cuándo no funciona este método
Este plan no aplica si el fallo proviene de la pasarela, del JavaScript del tema que impide el envío, o en arquitecturas headless que gestionan caché en la API.
En esos casos, el problema no se resuelve con reglas de cache en borde o servidor.
Recomendación práctica: si el bypass elimina el fallo tras 10 minutos, el origen era cacheo; planifica reglas definitivas y pruebas de carga antes de la próxima campaña.
Plantillas listas para hosting y desarrolladores
Envía estos mensajes para ahorrar tiempo y obtener datos útiles desde el primer ticket.
Incluye siempre las salidas de curl y capturas de cabeceras.
¿Qué decir al hosting?
Asunto: Incidencia urgente, checkout devuelve contenido cacheado
Cuerpo (pegable):
text
Hola,
El checkout de https://tudominio está devolviendo contenido cacheado desde el borde. He adjuntado la salida de curl. CF-Cache-Status: HIT y Age: 120.
Solicito bypass de /checkout y /cart en el CDN y purga por URL. También necesito revisar si existe cache en el proxy inverso (Varnish/Nginx).
Salida curl:
curl -I -H 'Cookie: woocommerce_items_in_cart=1; wp_woocommerce_session=abc' https://tudominio/checkout
Gracias,
[Nombre del responsable]
¿Qué pedir al desarrollador WordPress?
Copia este mensaje:
text
Atención: tras bypass en CDN el paso de pago sigue fallando. Adjuntad logs PHP y devolved entries con nonces expirados. Revisad plugins de caché y fragments (cart fragments). Si hay reglas en functions.php que fuerzan cache, revertidlas temporalmente.
Comandos útiles:
- curl -I -H 'Cookie: woocommerce_items_in_cart=1; wp_woocommerce_session=abc' https://tudominio/checkout
- tail -n 200 /var/log/php8.0-fpm.log
- grep "woocommerce" /var/log/nginx/access.log | tail -n 50
Preguntas frecuentes sobre caché y pagos
¿Puedo cachear el checkout para acelerar la web?
No, el checkout no debe cachearse; contiene nonces y tokens de pago.
Cachear checkout suele provocar nonces expirados y fallos al enviar el pago.
¿La purga del plugin borra el CDN?
La purga del plugin borra solo el origen salvo que el plugin invoque la API del CDN.
Purgar desde WP no garantiza que el borde deje de servir contenido cacheado.
¿Qué cabeceras indican cache en el borde?
CF-Cache-Status, X-Cache y Age muestran si el borde respondió con caché.
Si Age>0 y X-Cache: HIT, el contenido salió de la CDN o proxy.
¿Cómo evito cobros duplicados causados por caché?
Implementar idempotency keys en la pasarela y lógica server-side para bloquear reintentos.
Comprobar logs de la pasarela antes de reintentar cargos.
¿Qué cookies afectan la cache key del CDN?
Las cookies típicas: wp_woocommerce_session, woocommerce_items_in_cart y PHPSESSID.
La cache key debe excluir estas cookies para rutas de pago.
¿Qué pruebas hacer tras aplicar cambios?
Probar un pago en modo sandbox con tarjeta de prueba y ver las cabeceras.
Verificar CF-Cache-Status o X-Cache y comprobar que Set-Cookie aparece solo en origin.
Checklist final y recursos
Checklist final para dejar el sistema estable tras el incidente:
1) Verificar bypass en CDN y plugin.
2) Implementar reglas Nginx/htaccess definitivas.
3) Configurar purga por URL o surrogate-keys.
4) Añadir idempotency y revisar webhooks de pasarela.
5) Ejecutar pruebas de carga y pagos sandbox.
Datos y referencia: PCI DSS v4.0 exige revisar los controles de pago; PSD2 con SCA ha tenido implantaciones clave en los últimos años.
Además, WooCommerce controla gran parte del comercio online, por eso estas reglas afectan muchas tiendas.
⚠️ Evitar cambios permanentes en reglas de cache sin pruebas automatizadas; un ajuste mal probado puede reintroducir fallos en la próxima campaña.
Referencias sobre PCI DSS
Un par de recursos prácticos y ejemplos de logs aceleran el diagnóstico y la comunicación con soporte. Checklist mínimo imprimible:
- Reproducir fallo y capturar headers completos
- Bypass CDN por URL
- Desactivar plugin de caché
- Revisar access.log/PHP-FPM
- Purga por surrogate-key y prueba sandbox. Ejemplo de access.log que indica borde: 203.0.113.10 - - [04/Jun/2026:12:34:56 +0000] "GET /checkout HTTP/1.1" 200 4521 "-" "Mozilla/5.0" "CF-Cache-Status: HIT". Ejemplo de PHP error que aparece cuando falla nonce: [04-Jun-2026 12:34:57] PHP Warning: wp_verify_nonce: Nonce expired in /var/www/html/wp-includes/pluggable.php on line 1234. Adjuntar estas líneas en el ticket y ofrecer una pequeña tabla CSV con timestamp, X-Cache/CF-Cache-Status, cookie presente (sí/no) permite acotar rápidamente si el problema es borde u origin
