WooCommerce checkout sends customers back to the cart? Check the SMTP host

Short answer: if WooCommerce creates the order but the customer ends up back on the cart, check outgoing e-mail before you touch the payment plugin. WooCommerce sends the order e-mails inside the same request that finishes the checkout. If the SMTP server never answers, that request hangs until it times out, and the shopper sees the cart again. In the case below the SMTP hostname was proxied by Cloudflare, which does not carry mail traffic.

What the store owner saw

A WooCommerce store with close to 60,000 orders, running for years without trouble, started losing sales overnight. Customers filled in the checkout, clicked Place order, watched the spinner for a long time and were sent back to the cart. No error message.

The strange part was on the admin side. The orders were there, marked Pending payment. The payment gateway log showed the Pix charge created in about one second. From the gateway’s point of view everything worked.

What was actually happening

The checkout runs as a single AJAX request to ?wc-ajax=checkout. That request creates the order, talks to the payment gateway and, before it answers the browser, sends the new order e-mails. In this store the request never answered.

The WP Mail SMTP log had the reason, repeated for every order:

SMTP Error: Could not connect to SMTP host.

The plugin was configured to send through mail. on the store’s own domain, port 587. That DNS record was proxied in Cloudflare, so the name resolved to Cloudflare addresses instead of the mail server. Cloudflare’s proxy handles web traffic. It does not accept SMTP connections, so every attempt to connect simply waited until it gave up. Each checkout waited with it.

How to confirm it on your store

1. Look up the SMTP host. Run dig +short mail.yourdomain.com. If the answer is an address in Cloudflare’s ranges (for example 104.21.x.x or 172.67.x.x) and not your server’s IP, the record is proxied.
2. Test the port from the server. Over SSH: timeout 10 bash -c '</dev/tcp/mail.yourdomain.com/587' && echo open || echo no answer. Run the same test against your server’s real hostname. If the first one hangs and the second one opens, you have found it.
3. Read the logs, not just the order list. Check the e-mail log of your SMTP plugin and the WooCommerce logs under wp-content/uploads/wc-logs/. A failed e-mail next to every stuck checkout is the pattern.

The fix

There are two clean ways out. Pick one.

• Stop proxying the mail record. In Cloudflare, set the mail record (and any record your SMTP plugin uses) to DNS only, the grey cloud. The website itself can stay proxied.
• Point the SMTP plugin at the server’s real hostname. This is what we did. The host’s own server name on port 465 with SSL connected at once.

After the change a test checkout answered in about 3.6 seconds with the Pix QR code on screen, and the confirmation e-mail left in 3 seconds.

Make the checkout independent of e-mail

Even with SMTP working, a slow mail server should never be able to block a sale. WooCommerce can queue its transactional e-mails and send them right after the checkout response instead of during it:

add_filter( 'woocommerce_defer_transactional_emails', '__return_true' );

Put it in a small must-use plugin or your child theme, then place a test order and confirm the e-mails still arrive. If your host runs WP-Cron poorly, set up a real cron job so the queue is processed on time.

Checklist

• Orders created but customers return to the cart: check the SMTP log first.
• The SMTP hostname must resolve to the mail server, not to a CDN or proxy.
• Test the SMTP port from the server, not from your laptop.
• Defer transactional e-mails so mail problems never block a payment.
• Cancel the test orders you create while debugging.

Questions we get about this

Why does Cloudflare break SMTP?

A proxied record points to Cloudflare’s servers, which only accept web traffic on a set of HTTP and HTTPS ports. Mail clients connecting on 25, 465 or 587 reach nothing that answers.

Should I turn off Cloudflare for the whole site?

No. Only the records used for mail need to be DNS only. The website record can stay proxied.

Can this happen with Gmail, SES or another provider?

Not in this way, as long as the plugin uses the provider’s own hostname. The problem appears when the SMTP host is a subdomain of your site that sits behind a proxy.