Pedidos duplicados no Magento 2 podem gerar cobrança repetida, reserva indevida de estoque, expedição em dobro e divergências com ERP ou marketplace. Apesar de o problema aparecer como duas vendas parecidas, a duplicidade pode ter começado no navegador, no backend, no gateway de pagamento ou em uma integração posterior.
Antes de cancelar pedidos, editar o banco ou bloquear o checkout, confirme se houve duas gravações reais e descubra qual etapa foi repetida. O roteiro abaixo ajuda a preservar evidências, conter o impacto e localizar a origem sem interromper vendas legítimas.
Pedidos duplicados no Magento 2: confirme o que foi repetido
Dois pedidos do mesmo cliente não são necessariamente uma duplicidade. O comprador pode ter tentado novamente após uma mensagem de erro, usado outro meio de pagamento ou concluído dois carrinhos diferentes. Compare os registros antes de classificar o incidente.
Reúna, para cada pedido suspeito:
- número incremental e identificador interno;
- data e horário com segundos;
- cliente, endereço e itens comprados;
- ID do carrinho ou quote, quando disponível;
- método e identificador da transação de pagamento;
- valor autorizado, capturado ou recusado;
- IP, sessão e canal de origem, se registrados;
- status de envio ao ERP, hub ou marketplace.
Se os números de pedido são diferentes, mas o ID da transação é o mesmo, a investigação deve priorizar o módulo de pagamento e a conciliação. Se também existem duas transações, verifique submissões repetidas, ausência de idempotência ou nova tentativa do comprador. Quando há uma cobrança sem o pedido correspondente, use o roteiro sobre pagamento aprovado sem pedido no Magento 2, pois o fluxo de diagnóstico é diferente.
1. Preserve logs antes de reproduzir ou limpar caches
Registre o intervalo exato do incidente e faça uma cópia dos logs da aplicação, servidor web, PHP, gateway e integrações. Limpar arquivos, rotacioná-los manualmente ou repetir compras em produção pode apagar a sequência original ou criar novas cobranças.
Nos logs do Magento, procure pelo número do pedido, ID do carrinho, e-mail do cliente e identificador do pagamento. Uma busca defensiva pode ser feita em uma cópia protegida dos arquivos:
grep -RniE 'NUMERO_DO_PEDIDO|ID_DA_TRANSACAO|ID_DO_QUOTE' var/log/Evite compartilhar resultados completos em chamados sem remover tokens, dados pessoais, cabeçalhos de autorização e informações de cartão. Também registre o fuso horário de cada sistema: diferenças de horário podem inverter a ordem aparente dos eventos.
2. Verifique se o checkout enviou a requisição duas vezes
Em homologação, reproduza o fluxo com as ferramentas de rede do navegador abertas. Observe se o clique em finalizar compra gera uma ou várias requisições. Um botão que permanece habilitado, um evento JavaScript registrado duas vezes ou uma personalização que reenvia a chamada após timeout pode iniciar duas tentativas.
Teste separadamente:
- cliente autenticado e visitante;
- desktop e dispositivo móvel;
- cada método de pagamento;
- tema padrão de homologação e tema personalizado;
- checkout com e sem módulos adicionais habilitados em ambiente controlado;
- rede normal e conexão deliberadamente mais lenta.
Não conclua que o problema é apenas visual porque o minicarrinho ou a página de sucesso demorou a responder. A requisição pode ter chegado ao servidor mesmo quando o navegador exibiu erro. Se a falha acontece antes da finalização e os itens nem permanecem no carrinho, consulte também os testes para quando o produto não adiciona ao carrinho no Magento 2.
3. Diferencie repetição no navegador e no backend
Compare os horários do access log com os registros do Magento. Duas chamadas vindas do navegador apontam para clique repetido, JavaScript, extensão de checkout ou política de retry do cliente. Uma única chamada externa seguida por duas criações no backend direciona a análise para plugins, observers, customizações ou integrações que executam novamente o serviço de criação.
Faça essa comparação usando um identificador de correlação, quando a infraestrutura o registrar. Sem ele, combine horário, IP, rota, sessão, quote e transação. Não altere classes do core para adicionar logs: implemente instrumentação em módulo próprio e valide primeiro em homologação.
4. Confira retries, timeouts e respostas do servidor
Uma resposta demorada ou interrompida pode levar navegador, proxy, aplicativo, gateway ou middleware a repetir uma operação. O primeiro processamento pode ter sido concluído, embora o sistema chamador tenha recebido timeout.
Verifique se houve erro 499, 502, 503 ou 504 na camada de proxy; lentidão no PHP; bloqueio no banco; indisponibilidade do serviço de pagamento; ou retry automático na integração. O ponto central é identificar se a operação repetida possui proteção contra a criação de um segundo pedido.
Aumentar o timeout pode esconder o sintoma, mas não garante consistência. Primeiro descubra por que a resposta demorou e se uma nova tentativa reutilizou o mesmo identificador de operação.
5. Audite webhooks e notificações de pagamento
Gateways podem reenviar notificações quando não recebem uma resposta adequada. Isso é esperado em muitas arquiteturas assíncronas, portanto o consumidor precisa reconhecer eventos já processados.
Compare o ID do evento, ID da transação, tipo de notificação e resposta HTTP devolvida pela loja. Confirme se o endpoint responde rapidamente e se tarefas demoradas são tratadas de modo apropriado. Um webhook repetido deve atualizar ou confirmar o pedido correto, não criar uma nova venda.
Não bloqueie todas as notificações duplicadas no firewall. O reenvio pode ser necessário para recuperar eventos que realmente falharam. A correção deve distinguir um evento já concluído de uma tentativa legítima ainda pendente.
6. Investigue módulos, plugins e observers
Liste alterações recentes no checkout, pagamento, cálculo de totais e integração de pedidos. Plugins em métodos de colocação do pedido, observers de eventos de vendas e customizações que convertem carrinhos merecem atenção especial.
Em homologação, use a mesma versão de código e uma configuração representativa. Desative componentes por grupos, nunca aleatoriamente em produção. Depois de cada teste, confirme pedido, pagamento, estoque, e-mail e exportação. Uma extensão aparentemente distante do checkout pode interferir ao interceptar eventos ou executar chamadas externas.
7. Confirme se a duplicidade nasceu fora do Magento
Algumas operações recebem pedidos de aplicativo, marketplace, televendas ou ERP. Nesses casos, dois pedidos podem ter sido enviados à API com identificadores externos diferentes, embora representem a mesma compra.
Revise a regra de idempotência da origem e do middleware. Um identificador externo estável deve acompanhar novas tentativas da mesma operação. Gerar um identificador novo a cada retry impede que o destino reconheça a repetição.
8. Contenha o incidente sem apagar pedidos
Enquanto a causa é investigada, sinalize pedidos suspeitos para revisão manual, suspenda expedições duplicadas e faça a conciliação com o provedor de pagamento. Não exclua linhas diretamente das tabelas de vendas. Pedidos se relacionam com pagamentos, faturas, estoque, crédito, e-mails e integrações; uma remoção parcial pode ampliar a inconsistência.
Cancelamento, estorno e liberação de estoque devem seguir o estado real de cada transação. Se houver duas cobranças, valide com o gateway qual operação foi autorizada ou capturada antes de qualquer ação financeira.
9. Valide a correção de ponta a ponta
A correção não termina quando dois pedidos deixam de aparecer. Execute testes com clique repetido, resposta lenta, recarregamento da página, retorno do pagamento, webhook reenviado e falha temporária da integração. Confirme que cada tentativa produz um único resultado consistente e que uma falha apresenta ao comprador uma orientação segura.
Monitore por identificador de carrinho, transação e evento externo, evitando alertas baseados somente no e-mail do cliente. Documente a causa, o componente corrigido, a forma de rollback e os sinais que indicariam recorrência.
Perguntas frequentes
Posso excluir um dos pedidos duplicados diretamente no banco?
Não é recomendado. A exclusão pode deixar pagamentos, faturas, estoque e integrações inconsistentes. Preserve os registros e trate cancelamento ou estorno conforme o estado real da venda.
O clique duplo sempre é a causa de pedidos duplicados?
Não. A repetição também pode vir de JavaScript, retries após timeout, webhooks, módulos de pagamento, APIs, ERP ou customizações no backend.
Limpar o cache resolve pedidos duplicados no Magento 2?
Normalmente não. A limpeza pode dificultar a reprodução sem corrigir a ausência de idempotência, o reenvio de requisições ou a execução duplicada no backend.
Como impedir que um webhook crie outro pedido?
O consumidor deve registrar e reconhecer o identificador único do evento ou da transação, processando reenvios de forma idempotente. A regra precisa ser validada conforme o módulo e o gateway utilizados.
Conclusão
Pedidos duplicados no Magento 2 exigem correlação entre checkout, aplicação, pagamento e integrações. Preservar logs, comparar identificadores e testar retries é mais seguro do que cancelar vendas às pressas ou alterar o banco.
Se a origem continuar indefinida ou envolver cobranças reais, uma análise técnica pode reduzir o risco operacional. A equipe do SuporteMagento.com.br pode ajudar a revisar o fluxo e planejar a correção com testes controlados.
