Checkout do WooCommerce volta para o carrinho? Confira o host SMTP

Resposta curta: se o WooCommerce cria o pedido mas o cliente volta para o carrinho, confira o envio de e-mails antes de mexer no plugin de pagamento. O WooCommerce envia os e-mails do pedido dentro da mesma requisição que finaliza o checkout. Se o servidor SMTP nunca responde, essa requisição fica presa até estourar o tempo, e o cliente vê o carrinho de novo. No caso abaixo, o endereço SMTP estava com o proxy da Cloudflare ligado, e a Cloudflare não transporta e-mail.

O que o dono da loja via

Uma loja WooCommerce com quase 60 mil pedidos, rodando havia anos sem problema, começou a perder vendas de um dia para o outro. O cliente preenchia o checkout, clicava em Finalizar pedido, ficava olhando o carregamento por um bom tempo e voltava para o carrinho. Nenhuma mensagem de erro.

O estranho estava no painel. Os pedidos estavam lá, como Pagamento pendente. O log do gateway mostrava a cobrança Pix criada em cerca de um segundo. Do ponto de vista do gateway, tudo tinha funcionado.

O que estava acontecendo de verdade

O checkout roda como uma única requisição AJAX para ?wc-ajax=checkout. Essa requisição cria o pedido, conversa com o gateway de pagamento e, antes de responder ao navegador, envia os e-mails de novo pedido. Nessa loja, a requisição nunca respondia.

O log do WP Mail SMTP mostrava o motivo, repetido em todos os pedidos:

SMTP Error: Could not connect to SMTP host.

O plugin estava configurado para enviar por mail. no próprio domínio da loja, porta 587. Esse registro DNS estava com proxy na Cloudflare, então o nome apontava para endereços da Cloudflare e não para o servidor de e-mail. O proxy da Cloudflare cuida de tráfego web. Ele não aceita conexões SMTP, então cada tentativa de conexão simplesmente esperava até desistir. E cada checkout esperava junto.

Como confirmar na sua loja

1. Consulte o host SMTP. Rode dig +short mail.seudominio.com.br. Se a resposta for um endereço das faixas da Cloudflare (por exemplo 104.21.x.x ou 172.67.x.x) e não o IP do seu servidor, o registro está com proxy.
2. Teste a porta a partir do servidor. Por SSH: timeout 10 bash -c '</dev/tcp/mail.seudominio.com.br/587' && echo aberta || echo sem resposta. Rode o mesmo teste contra o nome real do servidor. Se o primeiro trava e o segundo abre, você achou o problema.
3. Leia os logs, não só a lista de pedidos. Veja o log de e-mails do seu plugin SMTP e os logs do WooCommerce em wp-content/uploads/wc-logs/. Um e-mail com falha ao lado de cada checkout travado é o padrão.

A correção

Existem dois caminhos limpos. Escolha um.

• Tirar o proxy do registro de e-mail. Na Cloudflare, deixe o registro mail (e qualquer outro que o plugin SMTP use) como somente DNS, a nuvem cinza. O site em si pode continuar com proxy.
• Apontar o plugin SMTP para o nome real do servidor. Foi o que fizemos. O nome do próprio servidor da hospedagem, na porta 465 com SSL, conectou na hora.

Depois da mudança, um checkout de teste respondeu em cerca de 3,6 segundos com o QR Code do Pix na tela, e o e-mail de confirmação saiu em 3 segundos.

Deixe o checkout independente do e-mail

Mesmo com o SMTP funcionando, um servidor de e-mail lento nunca deveria conseguir travar uma venda. O WooCommerce pode colocar os e-mails transacionais numa fila e enviá-los logo depois da resposta do checkout, e não durante:

add_filter( 'woocommerce_defer_transactional_emails', '__return_true' );

Coloque isso em um pequeno plugin must-use ou no tema filho, depois faça um pedido de teste e confirme que os e-mails continuam chegando. Se a sua hospedagem executa mal o WP-Cron, configure um cron real para a fila ser processada no tempo certo.

Checklist

• Pedido criado mas cliente volta para o carrinho: olhe o log de SMTP primeiro.
• O host SMTP precisa apontar para o servidor de e-mail, não para uma CDN ou proxy.
• Teste a porta SMTP a partir do servidor, não do seu computador.
• Deixe os e-mails transacionais em fila para que problemas de e-mail nunca bloqueiem um pagamento.
• Cancele os pedidos de teste criados durante o diagnóstico.

Perguntas que recebemos sobre isso

Por que a Cloudflare quebra o SMTP?

Um registro com proxy aponta para os servidores da Cloudflare, que só aceitam tráfego web em um conjunto de portas HTTP e HTTPS. Clientes de e-mail que conectam nas portas 25, 465 ou 587 não encontram nada que responda.

Devo desligar a Cloudflare do site inteiro?

Não. Só os registros usados para e-mail precisam ficar como somente DNS. O registro do site pode continuar com proxy.

Isso pode acontecer com Gmail, SES ou outro provedor?

Não dessa forma, desde que o plugin use o endereço do próprio provedor. O problema aparece quando o host SMTP é um subdomínio do seu site que está atrás de um proxy.