Pagamento aprovado, mas pedido não aparece no Magento 2? Faça 9 testes

Quando o pedido não aparece no Magento 2, mas o gateway informa que o pagamento foi aprovado, a equipe precisa agir com cuidado. Tentar criar outro pedido, reenviar a cobrança ou alterar registros diretamente no banco pode gerar duplicidade financeira, divergência de estoque e dificuldade de conciliação.

O primeiro objetivo não é “forçar” o pedido a aparecer. É descobrir até onde a operação avançou: checkout, quote, criação do pedido, autorização, captura, callback ou atualização de status. Os nove testes abaixo ajudam a localizar essa interrupção com evidências.

Por que o pagamento pode existir sem um pedido visível?

O fluxo depende da implementação do meio de pagamento. Em alguns módulos, o Magento cria o pedido e solicita a autorização durante o fechamento da compra. Em outros, especialmente nos fluxos assíncronos, o pedido pode ficar aguardando uma notificação posterior do provedor.

Também é importante separar autorização de captura. Uma transação “aprovada” no painel do gateway pode representar apenas uma reserva de limite, enquanto a captura financeira depende de outra etapa. A terminologia varia entre provedores e precisa ser confirmada antes de tratar o cliente como efetivamente cobrado.

Entre as causas possíveis estão uma exceção depois da comunicação com o gateway, falha na resposta do checkout, callback bloqueado, consumidor de fila parado, consulta incorreta no Admin ou comportamento inadequado de uma extensão.

Pedido não aparece no Magento 2: 9 testes para encontrar a falha

1. Reúna os identificadores antes de repetir qualquer ação

Registre o horário da tentativa, e-mail ou identificador interno do cliente, valor, método de pagamento, carrinho, ID da transação no provedor e eventual número reservado de pedido. Preserve os logs correspondentes antes de limpar cache ou reiniciar serviços.

Não peça ao cliente que tente novamente até verificar se houve autorização ou captura. Se a primeira operação for concluída tardiamente, a nova tentativa poderá produzir dois pagamentos válidos.

2. Confirme se o pedido realmente não foi criado

Pesquise no Admin por intervalo de data, cliente, valor e número do pedido. Remova filtros antigos e confira se o usuário administrativo possui acesso ao website ou à visão de dados correspondente.

O pedido pode existir e não ter sido percebido porque a página de sucesso falhou, o e-mail não foi enviado ou o status exibido é diferente do esperado. Nessa situação, o problema não está na criação do pedido, mas na confirmação apresentada ao cliente ou no processamento posterior.

Se o checkout permaneceu com o carregamento infinito, siga também os testes do guia sobre checkout Magento 2 que fica carregando.

3. Analise a última requisição do checkout no navegador

Reproduza o comportamento em homologação e use as abas Network e Console das ferramentas do navegador. Localize a chamada responsável por enviar o pagamento ou executar o fechamento do pedido.

Verifique o status HTTP, o corpo da resposta e erros JavaScript. Uma resposta 200 não comprova sucesso comercial: ela ainda pode conter uma mensagem de erro tratada incorretamente pelo frontend. Respostas 400 ou 422 costumam indicar rejeição de dados, enquanto erros 500 apontam para uma falha no backend que deve ser correlacionada com os logs.

Não publique tokens, dados de cartão, cookies ou informações pessoais ao compartilhar capturas e arquivos de diagnóstico.

4. Correlacione os logs pelo horário da transação

Examine os arquivos em var/log, os logs específicos do módulo de pagamento, o servidor web e o PHP. Procure pelo horário, ID da transação, número reservado e mensagens relacionadas a place order, timeout, constraint, exceção ou callback.

grep -niE "exception|critical|payment|place.?order|webhook" 
var/log/system.log var/log/exception.log 2>/dev/null | tail -n 200

O comando é apenas um ponto de partida e os nomes dos arquivos podem variar. Faça a consulta com acesso autorizado e sem habilitar logs excessivamente detalhados em produção por longos períodos. Uma exceção registrada logo após a resposta do gateway pode explicar por que a operação financeira avançou, mas a aplicação não concluiu o fluxo esperado.

5. Verifique a quote e o número reservado

O Magento pode reservar um número antes da persistência completa do pedido. Portanto, encontrar reserved_order_id na quote não significa que exista uma entrada correspondente em sales_order.

Em uma cópia ou com acesso somente de leitura, a equipe pode comparar os registros:

SELECT entity_id, reserved_order_id, is_active, updated_at
FROM quote
WHERE reserved_order_id = '<NUMERO_RESERVADO>';

SELECT entity_id, increment_id, state, status, created_at
FROM sales_order
WHERE increment_id = '<NUMERO_RESERVADO>';

Não edite essas tabelas para fabricar um pedido. A criação manual de registros ignora relacionamentos com itens, pagamentos, estoque, totais, impostos e histórico.

6. Compare autorização, captura e identificadores do gateway

No painel do provedor, confirme o tipo e o estado real da operação. Registre o identificador da transação, o valor, a moeda e as referências enviadas pelo módulo. Depois, compare esses dados com os registros do Magento e da integração.

Verifique também o comportamento de idempotência. Uma integração bem controlada deve evitar que a repetição da mesma intenção gere cobranças adicionais, mas não presuma que todo módulo implemente essa proteção da mesma forma. Não teste reenvios em produção sem conhecer o contrato do provedor.

7. Teste o webhook ou callback do pagamento

Em pagamentos assíncronos, o provedor pode comunicar a aprovação por uma URL de notificação. Confira se a chamada chegou ao servidor, recebeu resposta adequada e passou pelas validações de assinatura ou autenticação.

Firewall, WAF, proxy, redirecionamento, certificado, rota incorreta ou bloqueio por método HTTP podem impedir a entrega. Uma resposta 200 também não garante que a atualização foi aplicada: o endpoint pode capturar uma exceção e responder antes de concluir o processamento.

Não desative permanentemente validações de assinatura ou proteções do servidor. Se precisar isolar um bloqueio, faça uma regra restrita, temporária e baseada na documentação do provedor.

8. Confira cron, filas e consumidores

Alguns módulos processam notificações, alterações de status ou operações auxiliares de maneira assíncrona. Liste os consumidores disponíveis e verifique, na configuração da loja, quais deveriam estar ativos:

bin/magento queue:consumers:list

Analise os processos do gerenciador utilizado pela infraestrutura e o acúmulo de mensagens antes de iniciar consumidores manualmente. Se a execução depender de tarefas agendadas, consulte o diagnóstico de cron do Magento 2 que não executa.

Falhas de sessão também podem interromper o checkout ou fazer o cliente retornar a um carrinho inesperado. Nesse caso, vale investigar os erros de Redis relacionados a cache e sessões.

9. Isole módulos e customizações em homologação

Mapeie plugins, observers e preferências envolvidos no envio do pagamento, criação do pedido e atualização de status. Compare a versão instalada com a versão homologada e revise mudanças recentes no checkout, antifraude, ERP, PIX, cartão ou cálculo de totais.

Não desative módulos de pagamento durante o horário de vendas apenas para “ver se resolve”. Reproduza o cenário em homologação com credenciais de sandbox, mesma configuração relevante e logs controlados. O teste deve incluir aprovação, recusa, cancelamento, timeout e repetição da resposta.

Como reconciliar sem criar cobrança ou pedido duplicado

Depois do diagnóstico, classifique cada ocorrência. Se o pedido existe, mas a atualização não chegou, use o mecanismo suportado pelo módulo para consultar ou reconciliar a transação. Se houve autorização sem pedido, avalie com o provedor se ela deve ser cancelada, expirar ou ser estornada conforme a operação financeira aplicável.

Se o cliente foi efetivamente cobrado, não insira um pedido diretamente no banco. A solução precisa preservar totais, itens, impostos, estoque e rastreabilidade. Documente qualquer pedido administrativo criado por um fluxo autorizado e vincule internamente os identificadores da ocorrência e da transação.

Antes de liberar novas tentativas, confirme se callbacks antigos ainda podem ser entregues. Isso reduz o risco de um evento atrasado atualizar a operação errada.

Conclusão

Quando o pedido não aparece no Magento 2 após a aprovação do pagamento, a investigação deve conectar evidências do navegador, aplicação, quote, pedido, gateway, webhook e processamento assíncrono. Recriar pedidos ou repetir cobranças antes dessa correlação pode transformar uma falha isolada em um problema financeiro maior.

Se a sua loja apresenta esse comportamento e a origem não está clara, uma análise técnica especializada em Magento pode ajudar a localizar a interrupção e definir uma reconciliação segura.

Perguntas frequentes

O gateway aprovou, mas não existe pedido no Magento. Devo criar outro?

Não imediatamente. Primeiro confirme se houve autorização ou captura, procure o pedido por diferentes identificadores e verifique logs, quote e callbacks. Uma nova tentativa pode gerar cobrança duplicada.

Um número reservado comprova que o pedido foi criado?

Não. A quote pode possuir um reserved_order_id mesmo sem um registro correspondente em sales_order. As duas informações precisam ser comparadas.

Posso inserir o pedido diretamente no banco de dados?

Não é recomendado. O pedido depende de itens, endereços, pagamento, totais, impostos, estoque e históricos relacionados. Inserções manuais podem criar inconsistências difíceis de reverter.

Webhook bloqueado pode causar divergência no pagamento?

Sim. Em fluxos assíncronos, o pagamento pode avançar no provedor enquanto o Magento permanece sem a atualização esperada. É necessário verificar entrega, autenticação, resposta e processamento interno do callback.