Pagamento aprovado, mas pedido não aparece no Magento 2? Faça estas 7 verificações

O pagamento foi aprovado, mas o pedido não aparece no Magento 2? Essa divergência precisa ser investigada antes de pedir ao cliente que refaça a compra. Uma nova tentativa pode gerar cobrança duplicada, reservar estoque indevidamente ou criar dois pedidos para a mesma transação.

O diagnóstico deve descobrir se o pedido foi criado e não está visível, se ficou interrompido durante o checkout ou se o provedor confirmou uma transação que o Magento não conseguiu registrar. As sete verificações abaixo ajudam a separar esses cenários sem alterar dados às pressas.

Primeiro: descubra o que realmente não aparece

“Pedido não aparece” pode descrever problemas diferentes. Antes de limpar caches, reiniciar serviços ou cancelar a transação, reúna o e-mail do cliente, horário aproximado, valor, método de pagamento, identificador da transação no provedor e produtos comprados.

Em seguida, verifique se:

• o pedido não aparece apenas na conta do cliente;
• não existe pedido no painel administrativo;
• o pedido existe, mas permanece pendente ou em análise;
• o pagamento consta no provedor, porém não há número de pedido;
• o cliente recebeu e-mail, mas a equipe não localizou a venda;
• o pedido foi criado em outra visão de loja ou website.

Pesquise no Admin por e-mail, nome, valor e intervalo de datas, não apenas pelo número informado pelo consumidor. Confira também filtros salvos e o escopo da grade. Se outras etapas do fluxo também estiverem falhando, use este roteiro de testes para checkout Magento para delimitar o ponto da interrupção.

7 verificações quando o pedido não aparece no Magento 2

1. Confirme o estado real da transação no provedor

Uma tela de “pagamento aprovado” nem sempre significa liquidação concluída. Dependendo da integração, a transação pode estar autorizada, capturada, em análise, recusada após uma resposta inicial ou aguardando confirmação assíncrona.

No painel do provedor, registre o identificador da transação e verifique seu estado. Confira também se o valor, a moeda e o ambiente correspondem à loja investigada. Credenciais de homologação usadas por engano, contas diferentes por website ou divergências entre autorização e captura podem confundir o atendimento.

Não faça captura manual nem solicite outro pagamento antes de entender o vínculo entre a transação e o Magento.

2. Verifique se o pedido existe no banco, mas não na grade

A grade administrativa é uma representação dos pedidos, não a única evidência de que eles existem. Uma falha de sincronização, filtro ou customização pode esconder um registro criado corretamente.

Em uma conexão somente leitura, a equipe técnica pode pesquisar por e-mail e período. Adapte o prefixo das tabelas, caso exista:

SELECT entity_id, increment_id, customer_email, state, status,
       grand_total, created_at
FROM sales_order
WHERE customer_email = '[email protected]'
ORDER BY created_at DESC
LIMIT 20;

Se o registro estiver em sales_order, mas não aparecer na grade, investigue a sincronização com sales_order_grid, consumidores, cron e extensões que alteram pedidos. Não insira o registro manualmente na grade e não edite estado ou status diretamente no banco.

3. Correlacione os logs pelo horário da tentativa

Analise os arquivos em var/log no intervalo exato da compra. Os arquivos disponíveis dependem da versão e das extensões instaladas, mas system.log, exception.log, relatórios em var/report e logs próprios do módulo de pagamento são pontos comuns de partida.

grep -RniE "[email protected]|identificador-da-transacao" var/log var/report 2>/dev/null

Procure exceções de PHP, timeouts, respostas inválidas, falhas de banco, erros de API e mensagens emitidas logo após o clique de finalização. Antes de compartilhar registros com terceiros, remova tokens, credenciais, dados pessoais e informações de pagamento.

Se o log detalhado do gateway estiver desativado, evite ativá-lo diretamente em produção sem avaliar o conteúdo registrado e o impacto. O ideal é reproduzir o problema em staging com dados de teste.

4. Teste webhooks e notificações assíncronas

Muitos meios de pagamento enviam uma confirmação posterior ao Magento. Se a URL de notificação estiver incorreta, bloqueada ou respondendo com erro, o provedor pode registrar a transação enquanto o pedido permanece ausente ou sem atualização.

No painel do provedor, consulte o histórico de entregas e verifique:

• URL chamada e ambiente utilizado;
• código HTTP recebido;
• horário e quantidade de tentativas;
• timeout, bloqueio ou falha de autenticação;
• correlação entre o evento e o identificador da transação.

Na infraestrutura, confira proxy reverso, firewall, CDN, regras de segurança e logs do servidor web. Não libere uma URL inteira sem critérios e não desative validações de assinatura para fazer o webhook “funcionar”.

5. Confira cron, filas e consumidores

Algumas integrações processam notificações, atualizações de status ou tarefas complementares de forma assíncrona. Cron atrasado, consumidor parado ou fila acumulada pode impedir que o fluxo seja concluído.

bin/magento cron:run
bin/magento queue:consumers:list

Esses comandos, isoladamente, não provam que os processos estão saudáveis. Verifique o agendador do sistema, a tabela cron_schedule, a supervisão dos consumidores e os logs do broker, quando houver. O artigo sobre cron do Magento 2 que não roda apresenta um diagnóstico específico para tarefas atrasadas.

6. Investigue erros entre o quote e a criação do pedido

Durante a finalização, o Magento transforma o carrinho, ou quote, em pedido. Uma exceção nessa transição pode interromper a gravação depois que alguma comunicação externa já ocorreu.

As causas possíveis incluem customizações em observers e plugins, validação de endereço, estoque insuficiente, conflito de cupom, falha de banco, timeout e comportamento inadequado do módulo de pagamento. Reproduza com o mesmo tipo de produto, endereço, frete e método de pagamento, mas use um ambiente de testes e credenciais próprias para homologação.

Também compare uma compra como visitante com uma compra autenticada. Se o problema afetar apenas um carrinho, preserve seus dados antes de qualquer limpeza. Falhas relacionadas à persistência e à sessão exigem investigação própria, especialmente quando o cliente volta ao checkout depois de navegar em outro dispositivo.

7. Revise deploys e mudanças recentes

Se a divergência começou em um período específico, relacione o primeiro caso confirmado com deploys, atualização do módulo de pagamento, troca de credenciais, mudança de domínio, proxy, PHP, banco ou regras de segurança.

Compare o código implantado com o pacote homologado e procure alterações em plugins ligados à criação do pedido. Limpar todos os caches raramente corrige uma transação não persistida e ainda pode eliminar condições úteis para reproduzir a falha. Quando houver suspeita de conteúdo desatualizado, identifique primeiro qual camada de cache do Magento precisa ser limpa.

O que não fazer durante o diagnóstico

• Não orientar uma nova tentativa sem conferir a transação anterior.
• Não criar um pedido manual para “fechar” a divergência sem conciliação.
• Não alterar tabelas de vendas diretamente para forçar um status.
• Não cancelar ou capturar a transação sem entender o fluxo do provedor.
• Não desativar firewall, validação de webhook ou mecanismos antifraude.
• Não testar cartões ou dados reais de clientes em staging.

Se houver cobrança confirmada sem pedido, preserve logs e identificadores antes de executar mudanças. A solução operacional — estorno, captura, criação assistida ou atendimento ao cliente — deve seguir as regras do provedor e os procedimentos internos da loja.

Como reduzir a chance de recorrência

Depois de corrigir a causa, implemente monitoramento para respostas com erro nas rotas de notificação, exceções do módulo de pagamento e divergências de conciliação. Documente também como o atendimento deve pesquisar transações e quando escalar o caso para a equipe técnica.

Em staging, mantenha testes para pagamento aprovado, recusado, cancelado, expirado e assíncrono. Valide ainda pedidos como visitante e cliente autenticado, diferentes fretes, cupons e produtos simples ou configuráveis usados pela operação.

Perguntas frequentes

O Magento pode cobrar sem criar o pedido?

A comunicação com o provedor pode ocorrer antes de a criação do pedido ser concluída. Se uma exceção interromper o fluxo, pode existir uma transação sem o registro esperado no Magento. É necessário confirmar o estado real no provedor e correlacionar logs e identificadores.

Limpar o cache faz o pedido aparecer?

Normalmente, não. Se o pedido existe no banco, mas não está na grade, a investigação deve considerar sincronização, filtros, cron e customizações. Se ele não foi persistido, limpar cache não recria a venda.

É seguro criar o pedido diretamente no banco?

Não. Pedidos têm relações com itens, pagamentos, endereços, estoque, impostos e outras entidades. Inserções manuais podem gerar inconsistências. Preserve os dados e use um procedimento suportado pela aplicação e pelo meio de pagamento.

Como evitar uma cobrança duplicada?

Antes de solicitar nova compra, pesquise a transação pelo cliente, valor, horário e identificador do provedor. Confirme se houve autorização ou captura e siga o processo de conciliação definido pela operação.

Conclusão

Quando o pedido não aparece no Magento 2, a prioridade é conciliar a transação e preservar evidências, não repetir a cobrança. Confirme o estado no provedor, pesquise o banco em modo somente leitura, correlacione logs e valide webhooks, cron, filas e customizações.

Se a loja apresenta divergências recorrentes entre pagamento e pedido, uma análise técnica do fluxo completo pode localizar a etapa interrompida e reduzir o impacto no atendimento. A equipe do SuporteMagento.com.br pode ajudar no diagnóstico do checkout, das integrações e da infraestrutura da loja.