O PIX consta como aprovado no painel do provedor, mas o pedido WooCommerce continua Pendente de pagamento? Não peça ao cliente para pagar novamente e não altere o status ainda. Primeiro confirme que a transação aprovada pertence àquele pedido; depois examine notas, logs e o mecanismo de retorno usado pelo plugin. Esta sequência ajuda a investigar o desencontro sem criar uma segunda cobrança.
Este é um roteiro de diagnóstico, não uma instrução para forçar a confirmação. Nomes de telas, eventos e opções do gateway variam conforme o provedor, a extensão e sua versão. Se o assunto for escolher uma integração para uma loja nova, consulte nosso comparativo de gateways para WooCommerce no Brasil; aqui o foco é um pagamento já registrado.
Antes de tudo: preserve a cobrança e reúna os dados
Tenha acesso autorizado ao pedido no WooCommerce e ao painel do provedor (ou peça a quem tenha), além do plugin PIX instalado e sua versão. Anote o ID do pedido, o identificador da transação, o valor, os horários com fuso e os status exibidos nos dois sistemas. Um comprovante ou print enviado pelo cliente, sozinho, não substitui a verificação no painel oficial do provedor.
Nesta primeira etapa, faça somente consultas. Não envie outro link ou QR de pagamento, não estorne, não capture manualmente, não reenvie retornos e não marque o pedido como pago sem conciliação e autorização de quem responde pela operação. Se faltar acesso a uma das pontas ou se não for possível associar transação e pedido com confiança, pare e acione o suporte financeiro/técnico.
Para alterar configuração, atualizar extensão ou reproduzir o erro, tenha antes backup completo e restaurável de arquivos e banco. Faça testes em staging isolado, com sandbox e credenciais de teste, sem e-mails, integrações ou cobranças reais. Uma cópia da loja com o gateway de produção ativo pode gerar efeitos na operação real.
O que o status Pendente de pagamento informa — e o que não informa
No guia de status do WooCommerce, Pendente de pagamento (Pending payment) indica que o pedido foi recebido, mas o pagamento ainda não consta como feito no estado do pedido. Aguardando (On hold) pode representar espera pela confirmação; Processando (Processing) costuma indicar pagamento recebido e pedido aguardando atendimento; Concluído (Completed) indica pedido atendido. A tradução pode variar na instalação.
O status do pedido não é o extrato do provedor. Se há aprovação no gateway e pendência na loja, isso não prova nem que o dinheiro não entrou nem que a transação aprovada corresponde ao pedido aberto. Também não prova que o plugin recebeu ou processou uma notificação. O fluxo de status pode variar por integração e tipo de produto; na tabela do Mercado Pago para WooCommerce, por exemplo, “Approved” se relaciona a “Processing”, mas não use esse mapeamento como regra para outros gateways.
Pedido WooCommerce pendente após pagamento PIX: diagnóstico em três etapas
1. Identifique o pedido e leia seu histórico
Em WooCommerce > Pedidos, abra o pedido afetado. Registre em ambiente interno restrito número/ID, estado atual, valor, método de pagamento e horário. Leia as notas do pedido procurando tentativas de pagamento, mensagens do gateway e alterações de status. O ID da transação pode constar dos detalhes ou notas, conforme a extensão. Verifique se há outro pedido semelhante para a mesma compra antes de associar a aprovação a este registro. O guia oficial de diagnóstico de pedidos recomenda começar pelo método e pelos detalhes do pedido.
2. Cruze a operação no provedor
No painel do gateway, procure a transação no ambiente correto (produção ou teste) e confira estado atual, ID da operação, valor, método e horário. Compare a referência externa ou ID do pedido se esses campos existirem na integração. Mantenha os identificadores completos só na ferramenta interna autorizada; ao compartilhar evidências, oculte dados pessoais, tokens, chaves e outras informações sensíveis.
Se valor, referência ou ambiente divergir, se houver mais de uma transação ou se o pedido constar como Cancelado ou Falhou apesar de uma operação aprovada, interrompa qualquer mudança e peça conciliação ao responsável financeiro e ao suporte do provedor. Não conclua nem reabra o pedido automaticamente.
3. Compare notas, logs e retorno do gateway
Se transação e pedido corresponderem, procure registros do período em WooCommerce > Status > Logs, quando o plugin tiver logging habilitado. Compare horários e fusos com as notas do pedido e o histórico do provedor. Ativar logs agora não reconstitui o evento passado; conforme o guia oficial de troubleshooting, novos registros exigem atividade posterior. Evite deixar logging detalhado ativado por mais tempo que o necessário e remova dados sensíveis dos trechos enviados ao suporte.
Confira na documentação da versão instalada do plugin/gateway como ele comunica a confirmação: pode usar webhook, IPN, callback ou outro mecanismo. Se o provedor oferecer histórico de entregas, confronte evento, ambiente, destino, horário, tentativas e resposta HTTP com os registros da loja. Uma entrega ausente ou com erro é pista para investigar integração e infraestrutura; uma resposta HTTP 2xx, por si só, não comprova que o plugin conciliou a transação com o pedido. O Mercado Pago documenta tópicos e métodos de notificação distintos, conforme a solução integrada; não presuma os mesmos nomes ou eventos em outro provedor.
Não confunda as direções dos webhooks. A tela WooCommerce > Configurações > Avançado > Webhooks configura eventos enviados pelo WooCommerce a serviços externos. Ela não é, por padrão, o cadastro da notificação que o gateway envia à loja. Criar ali um webhook de saída não é correção para um PIX aprovado que não atualizou o pedido.
O que as evidências sugerem?
| Achado | Próximo passo seguro |
|---|---|
| O provedor não confirma aprovação ou não há vínculo confiável com o pedido | Suspenda alterações e peça conferência da transação ao suporte financeiro do provedor. Não solicite nova tentativa antes de descartar cobrança anterior. |
| Aprovação e pedido coincidem, mas não há nota de confirmação | Compare o histórico de retorno do provedor, se existir, e os logs do plugin. Registre IDs e horários sem expor segredos. |
| Retorno ausente, com falha ou destinado a outro ambiente | Escale à equipe técnica do plugin, provedor e hospedagem; valide configuração em staging antes de mexer na produção. |
| Retorno com HTTP de sucesso, pedido ainda pendente | Investigue o processamento no plugin e a associação transação–pedido. Resposta HTTP não garante atualização do status. |
| Múltiplos pedidos/transações ou pedido cancelado/falhou com pagamento aprovado | Pare e concilie cada operação com o suporte antes de cobrar, estornar, atender ou mudar estados. |
Se o sintoma acontece antes de o pedido ser criado — checkout demorando ou travando — siga o checklist de checkout lento no WooCommerce. Problemas de estoque ou entrega de e-mail têm outra trilha de diagnóstico.
Posso reenviar a notificação ou mudar o status manualmente?
Não como primeira medida. A documentação de diagnóstico do WooCommerce recomenda consultar as orientações do gateway para verificar ou reenviar o callback após confirmar a cobrança, e conciliar o pedido antes de atendê-lo. Se a integração permitir reprocessamento, confirme na documentação específica e com o suporte se o procedimento é apropriado ao evento e ao pedido; não simule payloads, desative assinaturas ou repita a ação às cegas em produção.
Mudar o status manualmente pode acionar estoque, e-mails, automações ou atendimento sem corrigir a causa do desencontro. Qualquer ajuste excepcional exige decisão documentada e autorizada após conciliação financeira. Para testar o fluxo de um novo pedido, use staging WordPress protegido e sandbox do provedor, com dados fictícios e integrações reais isoladas; não copie credenciais de produção nem restaure banco antigo sobre pedidos novos. Para os fundamentos da configuração, veja o guia completo para criar loja com WooCommerce.
O que enviar ao suporte e como encerrar o incidente
Abra chamado privado com plugin/gateway e versões, ambiente, IDs do pedido e transação mascarados conforme o canal, valor, horário com fuso, status em cada sistema, notas pertinentes e tentativas de retorno/HTTP quando disponíveis. Envie apenas os trechos necessários dos logs, com dados pessoais e segredos removidos. Se o provedor exigir IDs completos, use exclusivamente seu canal autenticado e sua política de tratamento de dados.
Até resolver a divergência, não cobre novamente nem libere o pedido com base apenas em um print ou no status isolado de um sistema. Após orientação do suporte e conciliação, confirme que transação, pedido e notas estão coerentes e monitore pedidos seguintes: uma correção pontual não demonstra que notificações futuras funcionarão.
