Pagamento recusado no WooCommerce: por que acontece e como resolver

Um cliente tenta comprar na sua loja, o pagamento é recusado e ele desiste. Você não sabe se o problema é do banco dele, do gateway ou da sua loja. Cada causa tem um remédio diferente — e errar o diagnóstico significa perder tempo e vendas.

Pagamento recusado no WooCommerce não tem uma causa única. O emissor ou o antifraude podem barrar a transação de fato, mas o checkout também pode falhar por problemas de comunicação com o gateway ou de configuração da própria loja. Este artigo ensina a identificar qual camada falhou usando códigos de erro reais dos principais gateways brasileiros.

• Por que o checkout falha — as 3 camadas que podem causar o problema
• Recusas no emissor ou antifraude
• Falhas de comunicação ou configuração do gateway
• Problemas do ambiente WooCommerce que quebram o checkout
• Como interpretar códigos de erro — tabela por gateway
• Reduzir falsos positivos do antifraude
• Quando o problema é do servidor
• Sandbox vs. produção — como isolar o problema
• Checkout transparente vs. redirecionamento
• Quando chamar um especialista
• Checklist de diagnóstico rápido
• Perguntas frequentes
• Próximos passos

Por que o checkout falha — as 3 camadas que podem causar o problema

Quando um pagamento falha no checkout, o WooCommerce exibe uma mensagem genérica. Por trás dessa mensagem, existem três camadas onde o problema pode estar:

1. Emissor/antifraude — o banco do cliente ou o sistema antifraude do gateway barraram a transação. O WooCommerce apenas repassa a resposta.
2. Gateway/comunicação — credenciais inválidas, webhook mal configurado, chave expirada ou falha na chamada HTTP entre seu servidor e a API do provedor.
3. Ambiente WooCommerce — cache no checkout, plugin em conflito, tema quebrando o fluxo, JavaScript que não carrega ou sessão corrompida.

Entender essa separação é essencial. Se você já tentou de tudo e o pagamento continua falhando, talvez o problema não esteja onde você imagina.

Recusas no emissor ou antifraude

Esta é a camada mais comum. O cliente preenche os dados, clica em “finalizar” e recebe uma mensagem de recusa. Nesses casos, o WooCommerce não tem culpa — ele apenas exibe o que o gateway retornou.

O que acontece por trás

Quando o gateway recebe os dados do cartão, ele encaminha para a rede (Visa, Mastercard, Elo, Amex) e depois para o banco emissor. O emissor aplica suas próprias regras: saldo disponível, limite de crédito, bloqueio para compras online e histórico de fraude do cartão.

O gateway também pode ter seu próprio sistema de antifraude. Se os dados parecem suspeitos — endereço diferente do cadastro, tentativas repetidas, valor alto — o antifraude do gateway pode barrar antes mesmo de enviar para o emissor.

Exemplos reais por gateway

Os códigos abaixo são reais e estão documentados na documentação oficial de cada gateway. Para cada um, indicamos a camada responsável.

Mercado Pago (documentação oficial):

• cc_rejected_insufficient_amount — saldo ou limite insuficiente no cartão. É o emissor que informa.
• cc_rejected_high_risk — o antifraude do Mercado Pago avaliou risco elevado e barrou a transação. A documentação não especifica as causas exatas dessa avaliação.
• cc_rejected_call_for_authorize — o cartão precisa de autorização manual no banco. Exige contato do cliente com o banco para liberar a transação.
• cc_rejected_card_disabled — o cartão está desabilitado para compras online pelo emissor.
• cc_rejected_max_attempts — excedeu o limite de tentativas com esse cartão.
• cc_rejected_3ds_challenge / cc_rejected_3ds_mandatory — o cliente não completou ou não passou na autenticação 3D Secure.

Stripe (documentação oficial):

• insufficient_funds — saldo insuficiente.
• expired_card — cartão vencido.
• incorrect_cvc / incorrect_number / incorrect_address — dados incorretos. O cliente pode ter digitado errado.
• authentication_required — a transação exige 3D Secure. O Stripe tenta iniciar o fluxo automaticamente, mas se falhar, o cliente precisa tentar novamente.
• generic_decline — o emissor não forneceu motivo específico, ou o bloqueio veio do Radar/Adaptive Acceptance do Stripe. Origem não determinada pelo código — o cliente precisa ligar para o banco ou usar outro método.
• fraudulent — o Stripe suspeita de fraude com base em seus próprios critérios. stolen_card e lost_card indicam que o cartão foi reportado como perdido ou roubado no ecossistema do emissor.
• duplicate_transaction — uma transação com dados idênticos foi enviada recentemente. Não necessariamente indica fraude — pode ser tentativa legítima repetida.

PagBank (documentação oficial):

• 20003 — saldo ou limite insuficiente (reason_code 51).
• 20001 — “Contate a central do seu cartão”. Pode indicar suspeita de fraude (reason_code 63), bloqueio temporário (57) ou outros problemas do emissor.
• 10000 — “Não autorizado pelo PagSeguro” — o antifraude do PagBank barrou.
• 20017 — “Transação não permitida”. Pode indicar cartão perdido (41), roubo (43) ou fraude confirmada (reason_code 83).
• 20007 — “Verifique os dados do cartão”. Número inválido, cartão vencido ou erro de formatação.
• 10001 — excesso de tentativas de re-processamento.
• 20019 — “Falha de comunicação” — o emissor estava fora do ar no momento da transação.

Asaas — o plugin Asaas para WooCommerce não dispõe de uma tabela oficial de códigos de recusa específica para o checkout. Para diagnosticar falhas, habilite o Log de Depuração no plugin e consulte WooCommerce > Status > Logs. Os arquivos de log relevantes são asaas-credit-card, asaas-ticket ou asaas-pix, conforme o método de pagamento. O código efetivamente retornado pela API do Asaas aparece nesses logs — interprete-o com base na documentação oficial do Asaas para o produto específico que sua loja utiliza.

O que fazer quando a recusa é no emissor/antifraude

• Informe ao cliente que o problema não é da loja — ele precisa entrar em contato com o banco emissor.
• Verifique se o cartão está habilitado para compras online.
• Sugira um método de pagamento diferente (Pix, boleto ou outro cartão).
• Se o antifraude do gateway barrou (cc_rejected_high_risk, 10000, fraudulent), a causa específica não é exposta pela maioria dos gateways. Evite retentativas imediatas com os mesmos dados e sugira outro método de pagamento — o Mercado Pago recomenda evitar novas tentativas com parâmetros idênticos.

Falhas de comunicação ou configuração do gateway

Quando o pagamento nunca chega ao emissor, a falha é entre seu servidor e a API do gateway. O WooCommerce tenta fazer a chamada, mas algo impede o fluxo completo. Uma falha de comunicação entre o servidor e o gateway impede o processamento — isso é diferente de uma recusa efetiva pelo emissor, e o diagnóstico muda completamente.

Causas mais comuns

• Credenciais inválidas ou expiradas — a chave de API foi renovada no painel do gateway mas não atualizada no WooCommerce. É um dos erros mais frequentes, especialmente após renovações de segurança.
• Sandbox vs. produção — o gateway está configurado com chaves de teste em ambiente real, ou vice-versa. O pagamento parece funcionar, mas nenhum pedido é confirmado.
• Webhook mal configurado — o pagamento é aprovado no gateway, mas o WooCommerce não recebe a confirmação. O pedido permanece pendente até que a notificação chegue do gateway ou até que você atualize o status manualmente.
• Conta do provedor com problema — a conta no gateway foi suspensa, está em análise ou atingiu limites de processamento.
• Chave de assinatura do webhook divergente — o gateway envia a notificação, mas a assinatura não confere. O WooCommerce rejeita a notificação por segurança.

Como identificar

• Verifique os logs do WooCommerce: WooCommerce > Status > Logs. Procure por erros do gateway específico. O log mostra o código de erro exato que ajuda a identificar a camada do problema.
• No painel do gateway (Mercado Pago, Stripe Dashboard, PagBank), verifique se os pagamentos aparecem como aprovados, pendentes ou recusados.
• Se o pagamento aparece como aprovado no gateway mas o pedido continua “pendente” no WooCommerce, verifique os logs e o painel do gateway para confirmar se o webhook está sendo entregue e processado corretamente.
• Compare as chaves de API no WooCommerce com as que estão no painel do gateway. Qualquer diferença, atualize.

O que fazer

• Atualize as credenciais no WooCommerce com as chaves atuais do gateway.
• Verifique se o webhook está configurado corretamente. Cada gateway tem uma URL específica: para Stripe, é seu-dominio.com/?wc-api=wc_stripe; para o Mercado Pago, a configuração automática geralmente funciona, mas pode precisar de ajuste manual.
• Confirme se a conta no gateway está ativa e sem restrições.
• Teste com o sandbox do gateway para isolar se o problema é de configuração ou de dados reais.

Problemas do ambiente WooCommerce que quebram o checkout

Esta é a camada que mais confunde. O pagamento pode estar falhando por problema no servidor ou na configuração da loja, sem que o emissor ou o antifraude tenham barrado a transação. Nesses casos, nenhum erro específico aparece na tela — o cliente apenas vê uma mensagem genérica.

Cache no checkout

Páginas de checkout, carrinho e “minha conta” nunca devem ser cacheadas. Quando o cache serve uma versão antiga da página, o nonce (token de segurança) expira. O pagamento falha silenciosamente ou com erro de “nonce inválido”.

• Verifique se seu plugin de cache exclui as páginas de checkout, carrinho e Minha Conta. Os caminhos reais dependem da configuração do seu WordPress — confirme em WooCommerce > Configurações > Avançado quais são as URLs dessas páginas e exclua-as em todas as camadas de cache e CDN (ex.: /finalizar-compra/, /carrinho/, /minha-conta/, além de qualquer URL com ?wc-ajax=).
• Se você usa Cloudflare ou CDN, certifique-se de que a regra de cache não está capturando páginas de sessão.

Plugin em conflito

Um plugin de otimização, segurança ou marketing pode estar interceptando o checkout. Conflitos não afetam as credenciais de API. Eles quebram o JavaScript que renderiza o formulário de pagamento ou bloqueiam a chamada AJAX.

• Abra o checkout no navegador, pressione F12, vá na aba Console. Erros em vermelho indicam qual script está falhando.
• Em ambiente de staging com backup recente, desative plugins temporariamente, exceto WooCommerce e o gateway de pagamento. Teste o checkout. Se funcionar, reative um por um até encontrar o conflito. Não faça isso diretamente em loja ativa sem staging — desativar plugins em produção pode quebrar funcionalidades.

Tema incompatível

Temas customizados podem não carregar os scripts do gateway corretamente. Também podem alterar a estrutura HTML do checkout de forma que o formulário de pagamento não funcione.

• Em staging, teste com o tema padrão (Storefront ou Twenty Twenty-Five) por alguns minutos. Se o pagamento funcionar, o problema está no tema. Não troque o tema em loja ativa sem backup e staging.

JavaScript não carrega

Se o checkout recarrega sem processar o pagamento, geralmente é erro de JavaScript impeditivo. O formulário de pagamento nunca é inicializado.

• Verifique o console do navegador (F12 > Console). Procure por erros em vermelho.
• Problemas de mixed content (página HTTPS carregando recursos HTTP) bloqueiam scripts de pagamento. Todos os recursos devem ser servidos por HTTPS.

Sessão corrompida ou cookies bloqueados

Cookies do WooCommerce (woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_*) são essenciais para o checkout. Se estão bloqueados pelo navegador ou pelo servidor, o carrinho some ou a sessão é perdida.

• Confirme que o WordPress está com Site URL e Home URL usando HTTPS.
• Verifique se o cookie SameSite está configurado corretamente.

Como interpretar códigos de erro — tabela por gateway

A tabela abaixo resume os códigos mais comuns e indica a camada responsável em cada caso.

Mercado Pago

Código	Significado	Camada
cc_rejected_bad_filled_*	Dados incorretos (número, data, CVV)	Emissor/dados do cliente
cc_rejected_insufficient_amount	Saldo ou limite insuficiente	Emissor
cc_rejected_card_disabled	Cartão desabilitado para online	Emissor
cc_rejected_call_for_authorize	Cartão precisa de autorização	Emissor
cc_rejected_max_attempts	Limite de tentativas excedido	Emissor
cc_rejected_duplicated_payment	Pagamento duplicado	Origem não determinada pelo código
cc_rejected_high_risk	Antifraude do Mercado Pago barrou	Antifraude (gateway)
cc_rejected_blacklist	Cartão está na lista negra	Antifraude (gateway)
cc_rejected_3ds_challenge	Falha na autenticação 3DS	Emissor
cc_rejected_time_out	Gateway não recebeu resposta	Comunicação
rejected_by_bank	Banco emissor rejeitou	Emissor

Stripe

Código	Significado	Camada
insufficient_funds	Saldo insuficiente	Emissor
expired_card	Cartão vencido	Emissor
incorrect_cvc / incorrect_number	Dados incorretos	Dados do cliente
authentication_required	Exige 3D Secure	Emissor
generic_decline	Recusa genérica — origem não determinada pelo código	Origem não determinada pelo código
fraudulent	Suspeita de fraude (critérios do Stripe)	Antifraude (gateway)
stolen_card / lost_card	Cartão reportado como perdido/roubado no ecossistema do emissor	Emissor
duplicate_transaction	Transação idêntica enviada recentemente	Origem não determinada pelo código
processing_error	Erro de processamento	Comunicação
issuer_not_available	Emissor inacessível	Comunicação
testmode_decline	Cartão de teste em produção	Ambiente/configuração

PagBank

Código	Significado	Camada
20000	Sucesso	—
10000	Não autorizado pelo PagBank (antifraude)	Antifraude (gateway)
10001	Excesso de retentativas	Antifraude (gateway)
20003	Saldo/limite insuficiente	Emissor
20001	Contate a central (fraude/bloqueio)	Emissor
20007	Verifique dados do cartão	Dados do cliente
20017	Transação não permitida (cartão perdido/roubado/fraude)	Emissor
20019	Falha de comunicação — tente mais tarde	Comunicação
20039	Transação não permitida para o cartão	Emissor

Asaas

O plugin Asaas para WooCommerce não fornece uma tabela padronizada de códigos de recusa para o checkout. Para identificar o motivo de uma falha:

1. Habilite o Log de Depuração nas configurações do plugin.
2. Acesse WooCommerce > Status > Logs e abra o arquivo de log correspondente ao método de pagamento (asaas-credit-card, asaas-ticket ou asaas-pix).
3. O código e a mensagem retornados pela API do Asaas aparecem no log — consulte a documentação oficial do Asaas para o produto específico que sua loja utiliza.

Reduzir falsos positivos do antifraude

Antifraude nunca é infalível — e bloquear um pagamento legítimo custa uma venda. Algumas práticas reduzem a chance de falsos positivos:

• Preencha os campos corretamente: envie os dados de cobrança e entrega conforme solicitado pelo gateway. Validações adicionais dependem do provedor, do emissor e da integração utilizada — consulte a documentação do gateway para saber quais campos são obrigatórios e como devem ser preenchidos.
• Evite retentativas imediatas com os mesmos dados: se a primeira tentativa falhou, espere ou sugira outro método. Retentativas rápidas podem ser interpretadas como padrão suspeito pelo antifraude do gateway.
• Configure regras de antifraude no gateway: muitos gateways permitem ajustar a sensibilidade do antifraude. Verifique as opções disponíveis no painel do gateway que você utiliza e ajuste conforme o perfil de risco da sua loja.
• Autenticação 3D Secure: ativar o 3DS pode reduzir recusas por fraude em alguns cenários, pois autentica o portador do cartão junto ao emissor. Não é imunidade contra chargeback — a proteção depende das regras de cada emissor e bandeira. Verifique se o gateway que você utiliza oferece essa configuração e quais são as implicações.
• Preencha os campos exigidos pelo gateway: cada gateway documenta quais campos são necessários para a validação da transação (CVC, CEP de cobrança, telefone, etc.). Preencher apenas os campos exigidos pela documentação oficial do gateway reduz recusas por dados incompletos.

Quando o problema é do servidor

Se o checkout trava, retorna erro genérico ou o log mostra erros de comunicação, o problema pode estar na infraestrutura do servidor. O diagnóstico de falha no checkout precisa considerar essa camada também.

Erros de chamada ao gateway

O WooCommerce se comunica com gateways por meio da HTTP API do PHP (que pode usar cURL, streams ou outra transportadora dependendo da configuração do servidor). Quando o servidor não consegue conectar à API do gateway, ocorrem erros de timeout ou conexão recusada.

Causas comuns de falha de comunicação:

• O servidor não tem recursos suficientes (memória ou tempo de execução) para processar a chamada.
• O firewall do servidor bloqueia a saída para o domínio da API do gateway.
• A versão do PHP ou das bibliotecas de rede está desatualizada e não suporta os protocolos de segurança exigidos.
• O DNS do servidor não resolve corretamente o domínio do gateway.

Esses erros podem aparecer nos logs do WooCommerce como falhas de comunicação. Se o log mostrar erro específico de cURL (como cURL error 28: Connection timed out), o diagnóstico aponta para timeout de rede. Se não houver erro cURL, verifique outros logs do servidor (PHP-FPM, Apache/Nginx).

HTTPS e certificado SSL

Três direções de comunicação dependem de HTTPS ou de certificados válidos:

1. Navegador → loja (HTTPS da página): o checkout exige que a página seja servida por HTTPS. Se o certificado SSL do seu domínio está expirado, mal configurado ou se o navegador não consegue validar a cadeia de certificados, o formulário de pagamento pode não carregar corretamente. Mixed content (página HTTPS carregando recursos HTTP) bloqueia scripts de pagamento no navegador.

2. Loja → API do gateway (chamada de saída): quando o WooCommerce envia os dados do pagamento para o gateway, o PHP valida o certificado do endpoint de destino. O erro SSL certificate problem: unable to get local issuer certificate nos logs indica que o cliente HTTP no servidor não conseguiu validar a cadeia de certificados — isso pode significar que o endpoint do gateway apresentou uma cadeia incompleta ou que o CA bundle/trust store do servidor local está ausente, incompleto ou desatualizado.

3. Gateway → webhook da loja (entrada): quando o gateway envia a confirmação do pagamento para sua loja, ele precisa acessar a URL do webhook via HTTPS. Se o certificado da loja está inválido, o gateway pode não conseguir entregar a notificação.

Sandbox vs. produção — como isolar o problema

O sandbox (ambiente de testes) do gateway é uma ferramenta útil para isolar se o problema é de configuração do gateway. Não substitui o diagnóstico completo, mas ajuda a confirmar se credenciais e fluxo básico estão funcionando.

Quando usar sandbox

• Para confirmar se as credenciais de API estão funcionando.
• Para testar se o checkout redireciona corretamente e se o webhook retorna o status correto.
• Para confirmar se credenciais e endpoints estão funcionando antes de verificar outras camadas.

Regras importantes

• Use exclusivamente os dados de teste indicados na documentação de cada gateway. Cartões reais podem não ser processados corretamente no sandbox — o comportamento varia conforme o gateway.
• Sandbox não é produção. O fato de funcionar no sandbox não garante que funciona em produção. Credenciais, endpoints e regras podem diferir.
• Se funciona no sandbox mas não em produção, o problema geralmente é de credenciais (chaves de teste vs. chaves reais) ou de conta (conta sandbox ativa, conta real com restrições). Verifique as credenciais e a conta no gateway.

Checkout transparente vs. redirecionamento

A forma como o gateway apresenta o checkout afeta a experiência e a taxa de conversão:

• Checkout transparente (on-site): o cliente nunca sai da sua loja. O formulário de pagamento é integrado ao checkout do WooCommerce. A maioria dos gateways modernos usa tokenização via iframe ou campos hospedados, reduzindo a carga de compliance. Mas pode ter mais problemas de JavaScript e cache.
• Redirecionamento (off-site): o cliente é redirecionado para a página do gateway e volta após o pagamento. Mais simples de configurar, menos dependente do ambiente da loja, mas pode causar abandono.

Se você usa checkout transparente e os pagamentos falham, o problema pode estar no JavaScript do checkout. Plugins de otimização, CSP restritivo ou scripts conflitantes podem impedir o carregamento do formulário. Se você usa redirecionamento e o retorno não atualiza o pedido, verifique se o webhook está configurado e recebendo notificações corretamente.

Quando chamar um especialista

Diagnóstico de falha no checkout pode ser direto quando o código de erro aponta a causa. Mas existem situações em que o problema é mais profundo e persiste mesmo após as verificações básicas:

• Pagamentos aprovados no gateway mas pedidos sempre “pendentes” no WooCommerce (possível falha de sincronização via webhook — confirme nos logs e no painel do gateway).
• Erros de comunicação com o gateway (cURL, TLS) que persistem após verificar certificado e firewall.
• Conflitos entre plugins que você não consegue identificar mesmo desativando um por um.
• Checkout que funciona em alguns navegadores e não em outros.
• Pedidos que somem ou carrinho que esvazia durante o pagamento.

Em casos como esses, um diagnóstico profundo identifica a raiz do problema sem tentativa e erro. A Panacea oferece análise inicial para lojas WooCommerce com problemas de checkout e pagamento.

Falha no checkout pode ser causada por cache na página de pagamento. Para mais detalhes sobre configuração de cache, consulte nosso artigo sobre cache em WooCommerce. Se o problema é mais geral de checkout, temos um diagnóstico completo de checkout que pode ajudar.

Checklist de diagnóstico rápido

Use este checklist para identificar a camada do problema:

• Verifique o código de erro exato no log do WooCommerce (WooCommerce > Status > Logs)
• Consulte a tabela de códigos deste artigo e identifique a camada responsável
• Se o código indica emissor/antifraude, oriente o cliente a contatar o banco ou usar outro método
• Se o código indica problema de comunicação, verifique as credenciais do gateway no WooCommerce
• Confirme se o gateway está em modo produção (não sandbox/teste)
• Verifique se o webhook está configurado e recebendo notificações
• Teste com o sandbox do gateway para isolar o problema
• Desative plugins não essenciais e teste o checkout
• Teste com o tema padrão (Storefront) para descartar conflito de tema
• Verifique o console do navegador (F12 > Console) para erros de JavaScript
• Confirme que o checkout não está sendo cacheado
• Verifique se o certificado SSL está válido e se a página de checkout carrega por HTTPS sem mixed content
• Se o problema persiste, consulte um especialista em WooCommerce

Perguntas frequentes

Por que meu pagamento é recusado sem erro específico?

A maioria dos gateways retorna um código genérico quando o emissor não fornece o motivo exato. No Stripe, é o generic_decline. No Mercado Pago, pode ser cc_rejected_other_reason. O cliente precisa ligar para o banco emissor para saber o motivo real. Essa é uma limitação da rede — o gateway não tem mais informação do que isso.

O pagamento foi aprovado no gateway mas o pedido continua “pendente”

Verifique os logs do WooCommerce e o painel do gateway para confirmar se o webhook está sendo entregue e processado. Causas comuns incluem: webhook bloqueado por firewall, URL errada, assinatura que não confere ou servidor retornando erro 4xx/5xx.

Posso aceitar cartão de crédito sem SSL?

Não. A página de checkout precisa ser servida por HTTPS — APIs de pagamento e integrações de checkout exigem contexto seguro para funcionar; sem HTTPS, o navegador pode sinalizar a página como insegura e a integração com o gateway pode falhar. Além disso, há três direções que dependem de certificados válidos: o navegador valida o certificado da loja ao carregar a página; o gateway valida o certificado da loja ao enviar webhooks de confirmação; e o servidor da loja valida a cadeia de certificados do endpoint do gateway ao enviar os dados do pagamento (essas são cadeias independentes).

O checkout funciona no sandbox mas não em produção

Verifique se as chaves de API no WooCommerce são as de produção (não as de teste). Chaves de teste começam com sk_test_ (Stripe) ou equivalentes em outros gateways. Outra causa comum: a conta no gateway está ativa no sandbox mas tem restrições em produção (limite de processamento, documentação pendente, conta em análise).

Como sei se o problema é do plugin de cache?

Desative o plugin de cache temporariamente e teste o checkout. Se funcionar, reative o cache e configure a exclusão das páginas de sessão — verifique os caminhos reais em WooCommerce > Configurações > Avançado e exclua-os em todas as camadas de cache/CDN. Nunca cacheie páginas que contenham nonces ou cookies de sessão.

Meu cliente recebe “nonce invalid” ao pagar

Nonce é um token de segurança que expira. Se o checkout está cacheado, o nonce antigo é servido e a validação falha. Remova o cache do checkout e verifique se cookies do WooCommerce estão sendo bloqueados pelo navegador ou pelo servidor.

Posso testar com cartão real em sandbox?

Use apenas os dados de teste indicados na documentação do gateway que você utiliza. O comportamento de cartões reais no sandbox varia conforme o gateway — alguns não processam, outros podem gerar resultados que não refletem produção. Siga as instruções oficiais de teste de cada provedor.

Próximos passos

Falha no checkout é um problema com solução — quando você sabe onde procurar. Identifique a camada, verifique os códigos e aplique a correção correspondente.

Se o diagnóstico aponta para um problema mais estrutural — como atualizações que causaram conflitos ou performance que afeta o checkout — consulte também nosso guia sobre como atualizar WordPress e WooCommerce sem quebrar e sobre diagnóstico de loja lenta.

Se o problema persiste mesmo após o diagnóstico, pode ser hora de contar com um especialista em WooCommerce que identifique a raiz do problema rapidamente. Também pode ser útil revisar a configuração completa dos gateways de pagamento e o checklist de lançamento da sua loja para garantir que nada foi deixado passar.