Pagamento aprovado sem pedido no Magento 2 é uma ocorrência que exige cuidado: o cliente pode ter recebido a confirmação da operadora enquanto a loja não exibe a venda no Admin. Repetir a compra, criar um pedido manual ou estornar imediatamente pode agravar o problema e gerar cobrança duplicada, divergência financeira ou baixa incorreta de estoque.
Antes de agir, registre horário, e-mail do cliente, valor, método de pagamento, identificador da transação e resposta exibida no checkout. Os nove testes abaixo ajudam a descobrir se o pedido não foi criado, está oculto na grade ou aguarda alguma etapa da integração.
Pagamento aprovado sem pedido no Magento 2: o que isso significa?
“Aprovado” pode representar eventos diferentes conforme o método utilizado: autorização do valor, captura efetiva, confirmação de PIX ou apenas uma situação intermediária no provedor. Por isso, não considere somente a mensagem enviada ao consumidor ou o status exibido em uma tela externa.
Também é importante separar três cenários:
- o pedido existe no banco, mas não aparece na grade do Admin;
- o pedido foi criado, porém está associado a outro site, visão de loja ou status;
- o pagamento avançou no provedor, mas o Magento não concluiu a criação ou atualização do pedido.
Se o problema estiver acompanhado por carregamento infinito ou erro na finalização, consulte também o checklist de testes para pagamentos no checkout do Adobe Commerce.
1. Impeça novas tentativas antes de investigar
Oriente o atendimento a não solicitar uma nova compra até confirmar o resultado da primeira transação. Preserve capturas de tela e identificadores, mas não compartilhe números completos de cartão, tokens, códigos de segurança ou outros dados sensíveis em chamados e canais internos.
Se várias pessoas estiverem sendo afetadas, avalie desabilitar temporariamente apenas o método problemático, mantendo alternativas confiáveis disponíveis. Evite colocar toda a loja em manutenção sem confirmar que o defeito alcança outros meios de pagamento.
2. Procure o pedido sem depender apenas da grade
Remova filtros antigos do Admin e pesquise pelo e-mail, nome, valor aproximado e intervalo de horário. Confirme ainda se o usuário administrativo possui acesso ao site ou à visão de loja em que a compra foi realizada.
Uma consulta somente de leitura pode confirmar se o registro existe na tabela de pedidos. Ajuste o prefixo das tabelas, caso a instalação utilize um:
SELECT entity_id, increment_id, state, status, customer_email,
grand_total, store_id, created_at
FROM sales_order
WHERE customer_email = '[email protected]'
ORDER BY entity_id DESC
LIMIT 10;Execute consultas diretamente no banco apenas com credenciais de leitura e conforme as regras de privacidade da operação. Não altere estados ou status por SQL.
3. Verifique se a grade de pedidos está atrasada
Quando o registro aparece em sales_order, mas não em sales_order_grid, o defeito pode estar na atualização da grade, e não na criação da venda. Compare os dados:
SELECT entity_id, increment_id, status, created_at
FROM sales_order_grid
WHERE increment_id = '000000123';Confira o estado dos indexadores e do cron antes de executar qualquer correção:
bin/magento indexer:status
bin/magento cron:statusNão crie outro pedido apenas porque ele está ausente na interface. Primeiro confirme se a venda original existe e se estoque, nota fiscal, ERP ou e-mails já receberam informações dela.
4. Relacione a transação externa ao pedido ou carrinho
No painel do provedor, localize o identificador da transação e procure referências enviadas pela loja, como número do pedido, identificador do carrinho, código do estabelecimento ou chave de idempotência. Os campos variam entre integrações; registre exatamente o que estiver disponível.
Se houver número de pedido, pesquise-o diretamente no Magento. Se houver apenas um identificador de carrinho, a equipe técnica poderá relacioná-lo à cotação e verificar se ela foi convertida. Um carrinho ainda ativo não prova sozinho que o pedido falhou, pois customizações podem modificar esse comportamento.
Quando a jornada também perde produtos ou sessão, vale aplicar o diagnóstico de carrinho do Magento 2 que esvazia sozinho.
5. Diferencie autorização, captura e liquidação
Confirme qual evento ocorreu de fato. Uma autorização pode reservar limite sem representar captura definitiva; uma captura pode existir antes de a conciliação financeira; um pagamento instantâneo pode depender de uma notificação para atualizar a loja.
Registre status, valor, moeda, data, identificador e histórico de eventos. Se o pedido existir, compare essas informações com os registros de pagamento relacionados a ele. Não use apenas o status textual, pois nomes semelhantes podem ter significados diferentes entre extensões e adquirentes.
6. Consulte os logs no horário exato
Pesquise alguns minutos antes e depois da tentativa nos arquivos de var/log, no servidor web, PHP-FPM e nas ferramentas de observabilidade adotadas pela operação. Procure pelo identificador da transação, e-mail mascarado, carrinho, URL do callback e mensagens de exceção.
grep -RniE 'transaction_id|cart_id|exception|critical' var/log/Substitua os termos por identificadores reais e evite exportar logs contendo dados pessoais ou credenciais. Erros 500, timeouts, falhas de banco e respostas inválidas de módulos podem interromper o fluxo entre a confirmação do pagamento e a resposta final do checkout.
7. Teste callbacks, webhooks, filas e cron
Algumas integrações recebem notificações assíncronas para confirmar ou atualizar pagamentos. Verifique se o endpoint está acessível, se a assinatura foi validada e se o provedor registrou tentativas com códigos HTTP de erro. Não simule notificações diretamente em produção sem documentação e autorização do integrador.
Também confira se consumidores de filas e tarefas agendadas estão ativos. Uma fila acumulada pode atrasar atualizações, mas reiniciar consumidores sem coletar métricas e logs remove pistas importantes. Para checkouts baseados em API, os testes de checkout GraphQL ajudam a conferir criação do pedido e integrações relacionadas.
8. Reproduza em homologação com rastreamento completo
Use o modo de testes do provedor, quando disponível, e uma cópia sanitizada da configuração. Reproduza a compra com o mesmo tipo de produto, método de entrega, cupom, moeda e forma de pagamento. Registre as requisições sem armazenar dados sensíveis.
Teste pelo menos:
- cliente visitante e autenticado;
- aprovação, recusa e cancelamento;
- retorno normal e retorno demorado do provedor;
- recarregamento da página após o envio;
- duplo clique ou repetição controlada da requisição;
- recebimento duplicado do mesmo webhook.
O objetivo é comprovar que a integração trata repetições sem criar pedidos ou cobranças adicionais.
9. Escolha a correção conforme o estado financeiro
Se o pedido existe e somente a grade está atrasada, corrija o processamento responsável pela sincronização. Se o pedido existe com status incorreto, investigue a notificação e use os mecanismos da própria plataforma ou extensão para atualizar o fluxo.
Quando há cobrança efetiva sem qualquer pedido, envolva as equipes financeira e técnica antes de decidir entre estorno e recuperação operacional. Um pedido manual pode não carregar corretamente impostos, descontos, estoque, identificadores de pagamento e histórico de auditoria. Se for indispensável, o procedimento deve ser documentado e reconciliado com a transação original.
Depois da correção, valide checkout, e-mails, estoque, faturamento, ERP, antifraude e conciliação. Monitore novas ocorrências pelo identificador da transação e pelo intervalo de tempo afetado.
Como prevenir novas divergências
- centralize logs do checkout, aplicação e callbacks com horários sincronizados;
- mantenha identificadores correlacionáveis entre carrinho, pedido e pagamento;
- monitore erros HTTP e tempo de resposta dos endpoints de notificação;
- teste idempotência e repetição de webhooks antes de cada atualização;
- inclua PIX, cartão, antifraude, frete e ERP na homologação;
- documente quem pode estornar, capturar ou recriar uma operação.
Conclusão
Um pagamento aprovado sem pedido no Magento 2 não deve ser tratado com uma nova compra automática ou alteração direta no banco. Primeiro descubra se o pedido existe, confirme o evento financeiro, correlacione os identificadores e examine logs, callbacks, filas e grades.
Se a operação não consegue localizar a ruptura ou o problema afeta vários clientes, uma análise técnica especializada pode preservar as evidências, corrigir a integração e reduzir o risco de novas cobranças divergentes. A equipe do Suporte Magento pode auxiliar no diagnóstico do checkout e dos serviços envolvidos.
Perguntas frequentes
O cliente deve tentar pagar novamente?
Não antes de a primeira transação ser verificada. Uma nova tentativa pode gerar cobrança duplicada. Confirme o status no provedor, procure o pedido no banco e relacione os identificadores da operação.
Posso criar manualmente o pedido que não apareceu?
Somente após analisar pagamento, estoque, descontos, impostos e integrações. O pedido manual pode não preservar a referência financeira original e deve ser documentado e conciliado.
Por que o pedido existe no banco, mas não aparece no Admin?
A grade pode estar atrasada, filtrada ou fora do escopo permitido ao usuário administrativo. Compare as tabelas de pedido e grade, além de verificar cron e processamento assíncrono.
Limpar o cache resolve pagamento aprovado sem pedido?
Normalmente, limpar o cache não recria um pedido nem processa uma notificação perdida. A ação pode até dificultar o diagnóstico se for feita antes da coleta de logs e identificadores.
