Na Green Hat, antes de construirmos um pipeline de implantação real, desenvolvedores carregavam arquivos direto para produção. Alguém sobrescrevia algo numa terça-feira à tarde, e o primeiro sinal de problema era um cliente reclamando que a página inicial estava quebrada, ou que o checkout não estava funcionando.
Um checkout do WooCommerce que para de funcionar quase sempre falha em uma de quatro camadas: o tipo de checkout que sua loja executa, um erro PHP ou JavaScript quebrando a requisição, um problema de cache ou sessão destruindo o carrinho, ou um gateway de pagamento que morreu silenciosamente. É bem fácil descobrir onde o problema está, se você seguir os passos abaixo. A maioria deles não requer nenhuma atualização de código.
O que realmente se quebra quando o checkout do WooCommerce não funciona
Um checkout do WooCommerce é quatro sistemas fazendo uma transferência coordenada enquanto fingem ser uma página. WordPress a renderiza, WooCommerce valida o carrinho e totais, um gateway de pagamento processa a transação pela sua própria API, e um script do lado do navegador une tudo isso com requisições AJAX ou REST. Qualquer um deles pode falhar sozinho, e o sintoma visto pelo cliente se parece quase idêntico de qualquer forma: um spinner que nunca para, um botão que não faz nada, um redirecionamento de volta para um carrinho vazio, ou, ainda pior, uma mensagem de erro vaga o suficiente para ser inútil.
Checkouts quebrados também se escondem bem. O Baymard Institute coloca a taxa média de abandono de carrinho em 70,22% em uma meta-análise de cinquenta estudos. Quando sete em dez carrinhos devem ser abandonados, um checkout falhando para um subconjunto de clientes não move o gráfico o suficiente para notar. A maioria das lojas descobre por email de um cliente.
Então o diagnóstico começa com observação. Desabilitar plugins vem depois, se em tudo.
Passo 1: Descubra qual checkout sua loja está executando
Toda correção que você encontra online se aplica a checkout em blocos ou checkout clássico, e geralmente não aos dois. Vá para Páginas, edite sua página de Checkout e olhe o que está nela. Um bloco Checkout significa que você está executando checkout em blocos. O texto [woocommerce_checkout] significa checkout clássico com shortcode.
O checkout em blocos se tornou o padrão para novas instalações na versão 8.3 do WooCommerce. O shortcode clássico ainda existe e ainda funciona, mas está em modo de manutenção, recebendo apenas correções de segurança em vez de novos recursos. Arquitetonicamente, ambos são diferentes o suficiente para que qualquer correção precise ser tratada de maneiras diferentes. O checkout clássico é um template PHP renderizado no servidor e customizado com hooks e overrides de template. O checkout em blocos é uma aplicação React conversando com a Store API.
É por isso que um snippet que funciona perfeitamente para uma loja não faz nada em outra.
Passo 2: Leia a requisição de rede que falhou
O código de status HTTP da requisição de checkout falhada diz a você qual camada quebrou, e a mensagem de erro na tela quase nunca o faz. Abra suas devtools do navegador, vá para a aba Network, adicione um produto ao carrinho e tente um checkout real com credenciais de teste.
O checkout em blocos faz POST da ordem para /wp-json/wc/store/v1/checkout. O checkout clássico faz POST para /?wc-ajax=checkout. Encontre essa requisição e leia-a.
Um 500 significa um erro fatal do PHP, então vá para o passo 3. Um 403 geralmente significa um nonce expirado, uma regra de firewall ou um plugin de segurança bloqueando a rota REST. Um 504 ou uma requisição que não responde aponta para timeouts do servidor em vez do WooCommerce. Um 200 que retorna trazendo uma mensagem de erro no corpo da resposta significa que WooCommerce funcionou bem e algo rejeitou a ordem propositalmente, normalmente uma regra de validação de uma extensão ou um gateway declinando a transação.
E se nenhuma requisição é disparada quando você clica Place Order, o JavaScript morreu antes de conseguir enviar. Verifique a aba Console para um erro não capturado e anote qual arquivo o lançou. Esse nome de arquivo é geralmente seu culpado.
Passo 3: Abra o log de erros fatais
WooCommerce escreve erros fatais do PHP em seu próprio log automaticamente, e a maioria dos donos de loja nunca olha para ele. Vá para WooCommerce > Status > Logs e abra o arquivo mais recente nomeado fatal-errors. De acordo com a documentação do WooCommerce sobre como encontrar logs de erros PHP, isso captura erros fatais e de tempo de execução do PHP junto com o arquivo e linha onde se originaram.
Esse caminho de arquivo é a resposta para "qual plugin está fazendo isso." E, enquanto você está nessa tela, abra a aba Scheduled Actions. Ações presas lá explicam um número surpreendente de pedidos que são criados e nunca progridem.
Passo 4: Estabeleça o que mudou e quando
Um checkout que funcionava ontem e falha hoje se quebrou porque algo na pilha se moveu. Encontre o timestamp do primeiro pedido falhado, então olhe tudo que mudou nas 48 horas anteriores a ele.
O próprio WooCommerce lança versões menores em um ritmo que a maioria dos donos de loja subestima. A versão 10.9.3, lançada em 3 de julho de 2026, corrigiu um erro fatal causado por filtros em WC_Email. A versão 10.9.4 chegou quatro dias depois para corrigir lógica de isenção de IVA no checkout em blocos para usuários conectados. WooCommerce 11.0 foi agendado para 28 de julho de 2026 e foi adiado para 4 de agosto após um erro fatal surgir durante testes de candidato a lançamento.
Adicione atualizações do núcleo do WordPress, edições de tema, um host silenciosamente aumentando sua versão PHP, um certificado SSL expirado, e um plugin de gateway auto-atualizando à noite. Sim, as coisas podem se quebrar mesmo com uma atualização menor.
Se você não consegue responder "o que mudou" porque ninguém rastreia, essa é sua própria descoberta. Uma estratégia de manutenção WordPress com atualizações em estágios e um registro de mudanças transforma esse passo em uma busca de dois minutos.
Passo 5: Descarte cache e sessões perdidas
Um carrinho que está cheio na página da loja e vazio na página de checkout aponta para a camada de sessão. WooCommerce armazena o carrinho no servidor e o conecta ao navegador com um cookie de sessão. Qualquer coisa que remova, bloqueie ou coloque em cache esse cookie quebra a conexão.
Os suspeitos usuais são um cache de página completa servindo uma versão em cache de /checkout/, uma CDN configurada para remover cookies de respostas, uma regra de WAF correspondendo ao padrão de cookie, ou um banner de consentimento de cookie bloqueando tudo até o visitante clicar aceitar.
Exclua /cart/, /checkout/ e /my-account/ do cache de página completa. Classifique cookies de sessão do WooCommerce como estritamente necessários em sua ferramenta de consentimento para que se definam antes do consentimento. Depois limpe cada camada de cache que você tem, incluindo a CDN, e reteste em uma janela privada.
Cache também produz o spinner infinito, onde checkout em blocos carrega mas nunca resolve totais porque uma resposta obsoleta está sendo servida contra um carrinho ao vivo. A otimização de velocidade WordPress encurta a janela de timeout que deixa essas falhas acontecerem em primeiro lugar.
Passo 6: Separe "sem método de pagamento" de "pagamento falhou"
Esses são dois problemas diferentes relatados com a mesma frase. Confirme qual você tem antes de resolver qualquer um deles.
Nenhum método de pagamento visível no checkout geralmente vem para baixo para configuração de gateway, HTTPS ausente, um país não suportado, ou incompatibilidade de blocos. O último pega as pessoas. Para aparecer dentro do checkout em blocos, um gateway tem que se registrar com a Store API através da API de integração de método de pagamento do WooCommerce, que é separada da API de Gateway de Pagamento mais antiga usada para processamento real. Um gateway que nunca implementou esse registro é invisível no checkout em blocos enquanto funciona perfeitamente no shortcode clássico. O mesmo se aplica a algumas extensões de campo de checkout, é por isso que muitas lojas ficaram no shortcode muito tempo depois da versão 8.3.
Um método de pagamento que aparece e depois falha é uma investigação diferente. Verifique se credenciais de produção estão salvas enquanto o gateway fica em modo de teste, e se o carrinho contém apenas produtos virtuais, que pulam envio e desqualificam alguns métodos. Então abra o painel do gateway e leia seu log de transações. Stripe e PayPal mostram a você a requisição declinada e o código de razão.
Passo 7: Verifique se o pedido foi realmente criado
Se o pedido existe no WooCommerce, seu checkout está funcionando, e a falha é em algum lugar depois dele. Vá para WooCommerce > Pedidos e filtre por data de hoje, incluindo status pendente e com falha.
Encontrar pedidos lá muda a investigação completamente. O cliente viu um erro ou uma página em branco, mas WooCommerce processou a transação. Agora você está olhando para o redirecionamento de página de agradecimento, a camada de email transacional, ou um webhook que nunca retornou do gateway. Essas falhas custam tickets de suporte e cobranças duplicadas em vez de pedidos perdidos. Falhas de webhook de inscrição WooCommerce seguem esse padrão exato, onde o log do gateway e o log do WooCommerce parecem corretos, e a lacuna entre eles é onde o dinheiro vai.
Não encontrar nenhum pedido confirma que a falha acontece antes da criação do pedido, que o manda de volta para os passos 2 e 3 com melhor informação.
Quando parar de diagnosticar e chamar um desenvolvedor WooCommerce
Pare quando o próximo passo custaria mais que a correção. Esse limite chega muito mais rápido do que a maioria dos donos de loja espera.
Uma loja fazendo $60.000 por mês em média gera aproximadamente $83 por hora em receita. Quatro horas de tentativa e erro em um checkout ativo custam cerca de $330 em vendas perdidas antes de qualquer um tocar em uma linha de código, o que compra bastante suporte de desenvolvimento WooCommerce, e isso assume que as adivinhações não quebram mais nada no caminho.
As situações que genuinamente precisam de alguém mais:
- O log de erros fatais nomeia um plugin que sua empresa depende, então removê-lo custa uma função que funciona
- O checkout falha para alguns clientes apenas, filtrados por país, moeda, dispositivo ou tipo de produto
- A Store API retorna 200 e nenhum pedido aparece, o que significa que uma extensão está se conectando à validação e rejeitando silenciosamente
- O erro é rastreado até um override de template dentro de seu tema
- Você não tem um ambiente de estágios e o único lugar deixado para testar é produção
- Noventa minutos de testes estruturados não produziram nenhuma causa reproduzível
Esse último é o limite honesto. Esses sete passos encontram a causa na maioria dos casos. Quando não, o problema geralmente é arquitetônico, e problemas arquitetônicos pioram quando você continua fuçando neles em uma loja ao vivo durante horário de funcionamento.
Em 2024 assumi como líder técnico em uma plataforma de ecommerce de produtos regulados no Canadá onde o mecanismo de cobrança de inscrição estava falhando de maneiras que os logs descreviam como bem-sucedidas. Esse tipo de falha não aparece em uma lista de verificação de sete passos, porque a lista assume que os logs estão dizendo a verdade.
Execute os sete passos primeiro. Eles são baratos, e geralmente são o suficiente. Se você terminar segurando um nome de plugin que não pode remover ou uma resposta 200 sem nenhum pedido atrás dela, você se moveu de solução de problemas para engenharia, e o movimento inteligente é passar para alguém que faz isso propositalmente.
Se o seu checkout está falhando agora e os sete passos deixaram você com mais perguntas que respostas, esse trabalho de diagnóstico é o que eu faço. Me diga o que você está vendo e a gente descobre onde realmente quebra. Se está tranquilo no momento e você prefere não ter essa conversa sob pressão, desenvolvimento e manutenção WooCommerce cobre a versão de auditoria.