¿El checkout de WooCommerce devuelve al carrito? Revisa el host SMTP

Respuesta corta: si WooCommerce crea el pedido pero el cliente vuelve al carrito, revisa el envío de correo antes de tocar el plugin de pago. WooCommerce envía los correos del pedido dentro de la misma petición que cierra el checkout. Si el servidor SMTP no responde nunca, esa petición se queda colgada hasta agotar el tiempo y el comprador vuelve a ver el carrito. En el caso que contamos, el nombre del servidor SMTP tenía activado el proxy de Cloudflare, que no transporta correo.

Lo que veía el dueño de la tienda

Una tienda WooCommerce con cerca de 60.000 pedidos, funcionando sin problemas desde hacía años, empezó a perder ventas de un día para otro. Los clientes rellenaban el checkout, pulsaban Realizar el pedido, miraban el indicador de carga un buen rato y volvían al carrito. Ningún mensaje de error.

Lo raro estaba en el panel. Los pedidos existían, en estado Pendiente de pago. El registro de la pasarela mostraba el cobro creado en aproximadamente un segundo. Para la pasarela, todo había ido bien.

Lo que pasaba en realidad

El checkout funciona como una sola petición AJAX a ?wc-ajax=checkout. Esa petición crea el pedido, habla con la pasarela de pago y, antes de responder al navegador, envía los correos de nuevo pedido. En esta tienda la petición no respondía nunca.

El registro de WP Mail SMTP tenía el motivo, repetido en cada pedido:

SMTP Error: Could not connect to SMTP host.

El plugin estaba configurado para enviar por mail. en el propio dominio de la tienda, puerto 587. Ese registro DNS tenía el proxy de Cloudflare activado, así que el nombre resolvía a direcciones de Cloudflare y no al servidor de correo. El proxy de Cloudflare gestiona tráfico web. No acepta conexiones SMTP, así que cada intento de conexión esperaba hasta rendirse. Y cada checkout esperaba con él.

Cómo comprobarlo en tu tienda

1. Consulta el host SMTP. Ejecuta dig +short mail.tudominio.com. Si la respuesta es una dirección de los rangos de Cloudflare (por ejemplo 104.21.x.x o 172.67.x.x) y no la IP de tu servidor, el registro tiene proxy.
2. Prueba el puerto desde el servidor. Por SSH: timeout 10 bash -c '</dev/tcp/mail.tudominio.com/587' && echo abierto || echo sin respuesta. Repite la prueba contra el nombre real del servidor. Si la primera se queda colgada y la segunda abre, ya lo tienes.
3. Lee los registros, no solo la lista de pedidos. Revisa el registro de correo de tu plugin SMTP y los registros de WooCommerce en wp-content/uploads/wc-logs/. Un correo fallido junto a cada checkout atascado es el patrón.

La solución

Hay dos salidas limpias. Elige una.

• Quitar el proxy del registro de correo. En Cloudflare, deja el registro mail (y cualquier otro que use tu plugin SMTP) en solo DNS, la nube gris. La web puede seguir con proxy.
• Apuntar el plugin SMTP al nombre real del servidor. Es lo que hicimos. El nombre del propio servidor del hosting, en el puerto 465 con SSL, conectó al instante.

Tras el cambio, un checkout de prueba respondió en unos 3,6 segundos con el código QR del pago en pantalla, y el correo de confirmación salió en 3 segundos.

Haz que el checkout no dependa del correo

Aunque el SMTP funcione, un servidor de correo lento nunca debería poder bloquear una venta. WooCommerce puede poner en cola sus correos transaccionales y enviarlos justo después de la respuesta del checkout, en lugar de durante:

add_filter( 'woocommerce_defer_transactional_emails', '__return_true' );

Ponlo en un pequeño plugin must-use o en tu tema hijo, haz un pedido de prueba y confirma que los correos siguen llegando. Si tu hosting ejecuta mal WP-Cron, configura un cron real para que la cola se procese a tiempo.

Lista de comprobación

• Pedidos creados pero clientes que vuelven al carrito: mira primero el registro SMTP.
• El host SMTP debe resolver al servidor de correo, no a una CDN ni a un proxy.
• Prueba el puerto SMTP desde el servidor, no desde tu ordenador.
• Pon en cola los correos transaccionales para que un fallo de correo nunca bloquee un pago.
• Cancela los pedidos de prueba que crees mientras investigas.

Preguntas que nos hacen sobre esto

¿Por qué Cloudflare rompe el SMTP?

Un registro con proxy apunta a los servidores de Cloudflare, que solo aceptan tráfico web en un conjunto de puertos HTTP y HTTPS. Los clientes de correo que conectan a los puertos 25, 465 o 587 no encuentran nada que responda.

¿Debo desactivar Cloudflare en toda la web?

No. Solo los registros que se usan para el correo tienen que estar en solo DNS. El registro de la web puede seguir con proxy.

¿Puede pasar con Gmail, SES u otro proveedor?

No de esta forma, siempre que el plugin use el nombre de host del propio proveedor. El problema aparece cuando el host SMTP es un subdominio de tu web que está detrás de un proxy.