O erro 400 checkout virtual Magento pode impedir a conclusão de pedidos de produtos sem entrega física, como serviços, assinaturas, cursos e itens digitais. Um cenário especialmente difícil de identificar ocorre quando o checkout de convidado possui apenas um método de pagamento: a opção é selecionada automaticamente, mas o e-mail do comprador ainda não foi informado.
Nesse caso, o frontend pode chamar a API de pagamento com dados incompletos. O diagnóstico correto exige registrar a sequência das requisições, examinar o payload enviado e verificar se o comportamento vem do checkout padrão, do tema ou de uma extensão.
O que foi relatado sobre o erro 400 no checkout virtual Magento?
Uma contribuição aberta no repositório oficial descreve um erro HTTP 400 intermitente em checkouts de convidados com produtos virtuais ou carrinhos sem etapa de entrega quando há somente um método de pagamento disponível. Segundo o relato, a seleção automática desse método pode acontecer antes do preenchimento do e-mail, provocando uma chamada de set-payment-information sem um valor válido para o campo obrigatório, conforme a Pull Request #41110 do Magento Open Source.
Esse registro não deve ser interpretado como confirmação de que todo erro 400 no pagamento possui a mesma origem. Uma resposta HTTP 400 indica, em termos gerais, que a requisição não pôde ser aceita como enviada. Validação de endereço, campos adicionais do gateway, sessão expirada, customizações JavaScript e interceptadores de API podem produzir o mesmo código com mensagens diferentes.
Por que produtos virtuais mudam a ordem do checkout?
Em um carrinho com produtos físicos, a etapa de entrega normalmente coleta endereço, modalidade de frete e dados de contato antes da confirmação do pagamento. Carrinhos compostos apenas por produtos virtuais não precisam de frete, eliminando parte desse fluxo.
Essa diferença pode expor uma condição de corrida ou uma dependência de ordem no frontend. Se existe apenas um método de pagamento, o componente pode marcá-lo automaticamente assim que a lista é carregada. Caso essa ação dispare o envio dos dados antes de o estado do checkout receber o e-mail do convidado, a API recebe uma requisição incompleta.
Para a loja, o sintoma pode parecer uma falha do gateway, pois acontece exatamente ao escolher ou exibir o pagamento. Entretanto, a transação talvez nem tenha sido enviada à adquirente, ao banco ou ao provedor. Confirmar esse ponto evita abrir uma investigação no lugar errado.
Como reproduzir o problema sem afetar clientes
Faça a reprodução em homologação, usando configurações equivalentes às da loja e credenciais de teste do provedor de pagamento. Não habilite logs detalhados indiscriminadamente em produção, pois payloads podem conter dados pessoais ou informações sensíveis.
- Crie um carrinho como visitante, sem autenticar uma conta.
- Adicione somente um produto virtual habilitado e disponível.
- Configure o ambiente para apresentar apenas um método de pagamento aplicável.
- Abra as ferramentas do desenvolvedor do navegador e selecione a aba Network.
- Avance até o pagamento sem preencher previamente o e-mail, quando o fluxo permitir.
- Filtre as chamadas por termos como
payment-informationouguest-carts. - Registre horário, URL, status HTTP, mensagem de resposta e ordem das requisições.
Depois, repita o teste preenchendo primeiro um e-mail válido. Se a primeira sequência retorna 400 e a segunda funciona, existe um indício relevante de dependência entre o preenchimento do e-mail e o envio das informações de pagamento. Ainda assim, compare o comportamento com o checkout padrão antes de atribuir a causa ao núcleo da plataforma.
Como inspecionar a chamada set-payment-information
Na requisição que falhou, examine o corpo enviado sem copiar tokens, cookies, documentos ou dados de cartão para chamados e ferramentas externas. Verifique principalmente:
- se o e-mail do convidado está vazio, ausente, nulo ou contém um valor válido;
- se o identificador do carrinho corresponde à sessão testada;
- se o código do método de pagamento é o esperado;
- se o módulo adiciona campos obrigatórios em
additional_data; - se a resposta contém uma mensagem de validação mais específica que o código 400;
- se duas chamadas são disparadas quase simultaneamente.
Preserve também os registros de var/log/exception.log, var/log/system.log e os logs próprios do meio de pagamento, quando existirem. Correlacione tudo pelo horário da reprodução. Um erro mostrado no navegador pode ter uma exceção correspondente no backend, mas a ausência dela também é informativa: a rejeição pode ter ocorrido durante a validação normal da API.
Separe resposta da API e erro do navegador
Nem toda mensagem vermelha no console corresponde à causa da falha. Um componente pode gerar um erro JavaScript depois que a API já devolveu 400. Leia primeiro a resposta da chamada de rede e, em seguida, analise a pilha do console.
Também confira se o endpoint foi alcançado. Bloqueios de WAF, regras de proxy e limites de requisição podem devolver códigos semelhantes antes de o Magento processar o payload. Compare os cabeçalhos e os logs da infraestrutura para determinar qual camada gerou a resposta.
Como saber se a causa está no Magento ou em um módulo?
O checkout reúne componentes do núcleo, tema, mixins JavaScript, módulos de pagamento, validações fiscais, antifraude e personalizações. Por isso, desativar extensões aleatoriamente em produção não é um teste seguro.
Em uma cópia controlada, monte uma matriz simples:
- produto virtual e produto físico;
- cliente convidado e cliente autenticado;
- um método e mais de um método disponível;
- tema atual e implementação de referência compatível;
- módulo de pagamento da loja e um método de teste apropriado ao ambiente.
Se a falha aparece apenas com uma extensão específica, compare os mixins, observadores, plugins e sobrescritas relacionados ao salvamento do pagamento. Se também ocorre no fluxo de referência, documente a versão instalada pelo Composer, os patches aplicados e o procedimento exato de reprodução.
Evite atualizar pacotes isolados sem avaliar dependências. Se a investigação apontar conflito durante a preparação de uma correção, consulte o roteiro para resolver um erro do Composer no Magento 2 sem substituir inesperadamente dezenas de componentes.
Correção temporária e deploy seguro
Enquanto a contribuição permanece aberta, não presuma que a alteração já integra uma versão estável ou um pacote instalado na loja. Antes de adotar qualquer ajuste inspirado no código proposto, a equipe deve revisar a implementação, confirmar a compatibilidade com sua versão e validar o fluxo completo em homologação.
Uma mitigação defensiva deve impedir o envio das informações de pagamento enquanto o e-mail obrigatório do convidado estiver ausente ou inválido. Ela não deve preencher um endereço fictício, ignorar validações do backend nem alterar diretamente arquivos em vendor. Mudanças diretas nessa pasta podem desaparecer na próxima instalação e dificultam auditoria e rollback.
O teste de regressão precisa cobrir, no mínimo:
- checkout convidado com produto virtual;
- checkout autenticado com produto virtual;
- carrinho físico e carrinho misto;
- um e vários métodos de pagamento;
- alteração do e-mail durante o checkout;
- aprovação, recusa e retorno do provedor em ambiente de teste;
- criação do pedido e envio das confirmações esperadas.
Após o deploy, acompanhe respostas 400 no endpoint, erros JavaScript e taxa de avanço entre pagamento e sucesso. Não use apenas a criação do pedido como indicador: uma tentativa pode falhar antes dessa etapa. Se o problema resultar em pedidos aprovados sem registro na plataforma, siga também as verificações específicas para integração e filas de pagamento, sem reenviar cobranças automaticamente.
Perguntas frequentes
Por que o pagamento é enviado antes do e-mail do convidado?
Em um carrinho sem entrega e com apenas um método disponível, o frontend pode selecionar automaticamente o pagamento. Se essa seleção disparar a API antes da atualização do e-mail no estado do checkout, a requisição chega incompleta.
O erro 400 afeta somente produtos virtuais?
Não necessariamente. O cenário relatado envolve carrinhos virtuais ou sem etapa de entrega, mas HTTP 400 também pode surgir em outros fluxos por payload inválido, sessão, validações adicionais ou customizações.
Como testar set-payment-information no checkout de convidado?
Reproduza em homologação, abra a aba Network do navegador e registre a chamada de pagamento, seu payload, a resposta e a ordem em relação ao preenchimento do e-mail. Remova dados pessoais antes de compartilhar evidências.
Posso aplicar diretamente o código da contribuição aberta?
Não é recomendável copiar uma alteração sem revisão. Confirme a versão da loja, avalie extensões, implemente de forma rastreável e execute testes de regressão antes do deploy.
Conclusão
O erro 400 checkout virtual Magento precisa ser investigado pela sequência real do frontend, e não apenas pela mensagem exibida ao comprador. Confirmar se o método foi selecionado antes do e-mail, inspecionar set-payment-information e comparar o checkout padrão com as customizações ajuda a separar falha de validação, extensão de pagamento e infraestrutura.
Se a loja perde pedidos nesse fluxo ou a equipe não consegue isolar a origem, um diagnóstico técnico controlado pode reduzir tentativas arriscadas e orientar uma correção compatível com a operação. A equipe do SuporteMagento.com.br pode apoiar a análise, os testes de checkout e o planejamento do deploy.
Fontes consultadas
As informações atuais mencionadas neste artigo foram verificadas nas fontes abaixo.
