Na Green Hat, antes de montarmos um pipeline de deploy de verdade, os desenvolvedores subiam arquivo direto em produção. Alguém sobrescrevia alguma coisa numa terça à tarde, e o primeiro sinal de problema era um cliente reclamando que a home estava quebrada, ou que o checkout não funcionava.
Um checkout do WooCommerce que para de funcionar quase sempre falha numa de quatro camadas: o tipo de checkout que a loja usa, um erro de PHP ou JavaScript derrubando a requisição, um problema de cache ou de sessão apagando o carrinho, ou um gateway de pagamento que morreu em silêncio. Seguindo os passos abaixo, é bem fácil descobrir onde está o problema. A maioria nem exige mexer em código.
O que quebra de fato quando o checkout do WooCommerce não funciona
O checkout do WooCommerce são quatro sistemas passando o bastão entre si enquanto fingem ser uma página só. O WordPress renderiza, o WooCommerce valida o carrinho e os totais, um gateway de pagamento processa a transação pela própria API, e um script no navegador amarra tudo com requisições AJAX ou REST. Qualquer um deles pode falhar sozinho, e o cliente vê praticamente o mesmo sintoma em todos os casos: um spinner que não para, um botão que não faz nada, uma volta pro carrinho vazio ou, pior, uma mensagem de erro tão vaga que não serve pra nada.
Checkout quebrado também se esconde bem. O Baymard Institute calcula a taxa média de abandono de carrinho em 70,22%, numa meta-análise de cinquenta estudos. Se sete em cada dez carrinhos já seriam abandonados de qualquer jeito, um checkout falhando pra uma parte dos clientes não mexe o gráfico o bastante pra alguém notar. A maioria das lojas descobre por e-mail de cliente.
Então o diagnóstico começa observando. Desligar plugin vem depois, se vier.
Passo 1: Descubra qual checkout a sua loja usa
Toda correção que você acha na internet vale pro checkout em blocos ou pro checkout clássico, e normalmente não pros dois. Vá em Páginas, edite a página de Checkout e veja o que tem nela. Se for um bloco Checkout, você está no checkout em blocos. Se aparecer o texto [woocommerce_checkout], é o checkout clássico com shortcode.
O checkout em blocos virou padrão nas instalações novas a partir da versão 8.3 do WooCommerce. O shortcode clássico continua existindo e funcionando, mas está em modo de manutenção: só recebe correção de segurança, nada de recurso novo. Por dentro, os dois são diferentes o bastante pra que qualquer correção precise ser feita de jeitos diferentes. O clássico é um template PHP renderizado no servidor e personalizado com hooks e overrides de template. O de blocos é uma aplicação React conversando com a Store API.
Por isso um snippet que funciona perfeitamente numa loja não faz nada na outra.
Passo 2: Leia a requisição de rede que falhou
O código HTTP da requisição de checkout que falhou diz qual camada quebrou. A mensagem de erro na tela quase nunca diz. Abra as ferramentas de desenvolvedor do navegador, vá na aba Network, coloque um produto no carrinho e tente um checkout de verdade com credenciais de teste.
O checkout em blocos manda o pedido por POST pra /wp-json/wc/store/v1/checkout. O clássico manda pra /?wc-ajax=checkout. Ache essa requisição e leia.
Um 500 é erro fatal de PHP, então vá pro passo 3. Um 403 costuma ser nonce vencido, regra de firewall ou plugin de segurança bloqueando a rota REST. Um 504, ou uma requisição que nunca responde, aponta pra timeout do servidor, e não pro WooCommerce. Um 200 que volta com mensagem de erro no corpo quer dizer que o WooCommerce funcionou e alguma coisa recusou o pedido de propósito, normalmente uma regra de validação de alguma extensão ou o gateway recusando a transação.
E se nenhuma requisição sai quando você clica em Place Order, o JavaScript morreu antes de conseguir enviar. Olhe a aba Console atrás de um erro não tratado e anote qual arquivo disparou. Esse nome de arquivo costuma ser o culpado.
Passo 3: Abra o log de erros fatais
O WooCommerce grava os erros fatais do PHP num log próprio, automaticamente, e a maioria dos donos de loja nunca abre. Vá em WooCommerce > Status > Logs e abra o arquivo mais recente chamado fatal-errors. Segundo a documentação do WooCommerce sobre como achar os logs de erro do PHP, ali ficam os erros fatais e de execução, com o arquivo e a linha de origem.
Esse caminho de arquivo responde "qual plugin está fazendo isso". E, já que você está nessa tela, abra a aba Scheduled Actions. Ações travadas ali explicam um número surpreendente de pedidos que são criados e nunca andam.
Passo 4: Descubra o que mudou e quando
Checkout que funcionava ontem e falha hoje quebrou porque alguma coisa na pilha se mexeu. Ache o horário do primeiro pedido que falhou e olhe tudo o que mudou nas 48 horas anteriores.
O próprio WooCommerce solta versões menores num ritmo que a maioria dos donos de loja subestima. A 10.9.3, de 3 de julho de 2026, corrigiu um erro fatal causado por filtros em WC_Email. A 10.9.4 saiu quatro dias depois pra corrigir a isenção de IVA no checkout em blocos pra usuários logados. O WooCommerce 11.0 estava marcado pra 28 de julho de 2026 e foi adiado pra 4 de agosto depois que um erro fatal apareceu nos testes da versão candidata.
Some a isso atualização do núcleo do WordPress, edição no tema, a hospedagem subindo a versão do PHP sem avisar, certificado SSL vencido e plugin de gateway se atualizando sozinho de madrugada. Pois é, até atualização pequena quebra coisa.
Se ninguém sabe responder "o que mudou" porque ninguém anota, isso já é uma descoberta. Uma estratégia de manutenção WordPress com atualização em etapas e registro de mudanças transforma esse passo numa busca de dois minutos.
Passo 5: Descarte cache e sessão perdida
Carrinho cheio na loja e vazio no checkout aponta pra camada de sessão. O WooCommerce guarda o carrinho no servidor e liga ele ao navegador por um cookie de sessão. Qualquer coisa que remova, bloqueie ou coloque esse cookie em cache quebra essa ligação.
Os suspeitos de sempre: cache de página inteira servindo uma cópia de /checkout/, CDN configurada pra tirar cookies das respostas, regra de WAF que casa com o padrão do cookie, ou banner de consentimento bloqueando tudo até o visitante clicar em aceitar.
Tire /cart/, /checkout/ e /my-account/ do cache de página inteira. Marque os cookies de sessão do WooCommerce como estritamente necessários na sua ferramenta de consentimento, pra que eles sejam gravados antes do aceite. Depois limpe todas as camadas de cache que você tem, CDN incluída, e teste de novo numa janela anônima.
O cache também causa o spinner infinito, quando o checkout em blocos carrega mas nunca fecha os totais porque está recebendo uma resposta velha pra um carrinho ao vivo. Otimizar a velocidade do WordPress diminui a janela de timeout que deixa essas falhas acontecerem.
Passo 6: Separe "sem forma de pagamento" de "pagamento falhou"
São dois problemas diferentes que chegam descritos com a mesma frase. Confirme qual é o seu antes de tentar resolver.
Nenhuma forma de pagamento aparecendo no checkout normalmente é configuração do gateway, falta de HTTPS, país não atendido ou incompatibilidade com blocos. Esse último pega muita gente. Pra aparecer no checkout em blocos, o gateway precisa se registrar na Store API pela API de integração de métodos de pagamento do WooCommerce, que é separada da antiga Payment Gateway API usada pra processar a cobrança. Um gateway que nunca fez esse registro fica invisível no checkout em blocos e funciona perfeitamente no shortcode clássico. O mesmo vale pra algumas extensões de campos de checkout, e é por isso que muita loja ficou no shortcode muito tempo depois da 8.3.
Forma de pagamento que aparece e depois falha é outra investigação. Veja se há credenciais de produção salvas com o gateway ainda em modo de teste, e se o carrinho só tem produto virtual, que pula o frete e desqualifica alguns métodos. Depois abra o painel do gateway e leia o log de transações. Stripe e PayPal mostram a requisição recusada e o código do motivo.
Passo 7: Confira se o pedido foi criado
Se o pedido existe no WooCommerce, o seu checkout funciona e a falha está em algum ponto depois dele. Vá em WooCommerce > Pedidos e filtre pela data de hoje, incluindo pendentes e com falha.
Achar pedido ali muda a investigação inteira. O cliente viu um erro ou uma página em branco, mas o WooCommerce processou a transação. Agora você está olhando pro redirecionamento pra página de agradecimento, pra camada de e-mail transacional ou pra um webhook que o gateway nunca devolveu. Essas falhas custam ticket de suporte e cobrança em dobro, e não pedido perdido. As falhas de webhook em assinaturas do WooCommerce seguem exatamente esse padrão: o log do gateway e o do WooCommerce parecem certos, e o dinheiro some no vão entre os dois.
Não achar pedido nenhum confirma que a falha acontece antes de o pedido ser criado, e isso te manda de volta pros passos 2 e 3, agora com informação melhor.
Quando parar de diagnosticar e chamar um desenvolvedor WooCommerce
Pare quando o próximo passo for custar mais que a correção. Esse limite chega bem antes do que a maioria dos donos de loja imagina.
Uma loja que fatura US$60.000 por mês gera, em média, uns US$83 por hora. Quatro horas de tentativa e erro com o checkout quebrado custam uns US$330 em vendas perdidas antes de alguém encostar numa linha de código. Isso paga bastante suporte de desenvolvimento WooCommerce, e ainda supõe que os chutes não quebrem mais nada no caminho.
As situações que pedem outra pessoa de verdade:
- O log de erros fatais aponta um plugin de que o negócio depende, então tirar ele custa uma função que funciona
- O checkout falha só pra alguns clientes, por país, moeda, dispositivo ou tipo de produto
- A Store API devolve 200 e nenhum pedido aparece, sinal de que alguma extensão está pendurada na validação e recusando em silêncio
- O erro leva a um override de template dentro do seu tema
- Você não tem ambiente de staging e o único lugar que sobrou pra testar é produção
- Noventa minutos de teste organizado não chegaram a nenhuma causa que dê pra reproduzir
Esse último é o limite honesto. Os sete passos acham a causa na maioria dos casos. Quando não acham, o problema costuma ser de arquitetura, e problema de arquitetura piora quando você continua fuçando numa loja no ar em horário comercial.
Em 2024 assumi como líder técnico numa plataforma de e-commerce de produtos regulados no Canadá, onde a cobrança das assinaturas falhava de um jeito que os logs descreviam como sucesso. Esse tipo de falha não aparece numa lista de sete passos, porque a lista parte do princípio de que os logs estão falando a verdade.
Faça os sete passos primeiro. São baratos e quase sempre bastam. Se você terminar com o nome de um plugin que não pode tirar ou com uma resposta 200 sem pedido nenhum por trás, você saiu do conserto e entrou na engenharia, e o mais inteligente é passar pra alguém que faz isso de propósito.
Se o seu checkout está falhando agora e os sete passos te deixaram com mais perguntas que respostas, esse diagnóstico é o que eu faço. Me conta o que você está vendo e a gente descobre onde quebra de verdade. Se está tudo calmo no momento e você prefere não ter essa conversa sob pressão, desenvolvimento e manutenção WooCommerce cobre a versão auditoria.