Guest checkout e contas de cliente no Magento 2 explicados

Guest checkout é uma daquelas configurações que parece uma pergunta de sim ou não e vira uma discussão longa. O marketing quer contas para retenção, o pessoal de conversão quer menos campos e o suporte quer que os clientes achem os pedidos sem ligar. O Magento suporta os dois caminhos, mais algumas formas de conectá-los, e a maior parte do problema vem de não saber o que acontece com os pedidos de visitante depois.

Este artigo explica como guest checkout e contas de cliente funcionam juntos no Magento Open Source e no Adobe Commerce 2.4.8: a configuração, o que acontece quando um visitante cria uma conta depois do pedido, como vincular com segurança pedidos antigos de visitante e o que muda para frontends headless.

Ligando ou desligando o guest checkout

A chave principal está em Stores, Configuration, Sales, Checkout, Checkout Options, Allow Guest Checkout. Com ela desligada, os clientes precisam fazer login ou se cadastrar antes de chegar ao checkout. Com ela ligada, podem informar um e-mail e continuar.

Existe uma exceção no nível de produto. Em Stores, Configuration, Catalog, Catalog, Downloadable Product Options, a configuração "Disable Guest Checkout if Cart Contains Downloadable Items" força uma conta quando o carrinho tem produtos para download. Faz sentido, porque os links de download ficam na conta do cliente.

Meu conselho de sempre é manter o guest checkout ligado em lojas B2C e tornar a criação de conta atraente depois do pedido em vez de obrigatória antes dele. Forçar uma conta no começo do checkout é atrito no pior momento. A decisão, porém, é do lojista, e lojas B2B com preços negociados costumam exigir login de qualquer jeito.

Como é um pedido de visitante

Um pedido de visitante é um pedido normal com algumas diferenças em sales_order:

• customer_id é NULL.
• customer_is_guest é 1.
• customer_group_id é o grupo NOT LOGGED IN, id 0.
• Os campos de nome e e-mail guardam o que o cliente digitou no checkout.

Esse último ponto importa também para preços. Catalog price rules, cart price rules e tier prices podem ter como alvo grupos de clientes. Um visitante sempre recebe o grupo NOT LOGGED IN, então regras pensadas para clientes "General" não se aplicam a visitantes. Se o lojista espera que visitantes e clientes cadastrados vejam as mesmas promoções, as regras precisam dos dois grupos.

O e-mail usado por um visitante pode pertencer a uma conta de cliente existente. O Magento permite, e o pedido continua sendo de visitante. Ele não aparece na conta daquele cliente. Isso surpreende muitos lojistas.

Como os visitantes encontram seus pedidos

Visitantes não têm uma página de conta, então o Magento oferece a página "Orders and Returns" em /sales/guest/form/. O cliente informa o número do pedido, o sobrenome da cobrança e o e-mail ou o CEP da cobrança, e vê os detalhes do pedido, notas e envios. O link no rodapé faz parte do tema Luma padrão. Se o seu tema o removeu, coloque de volta ou crie um link para ele no e-mail de confirmação do pedido, porque senão toda pergunta de "cadê meu pedido" vai para o suporte.

Criando uma conta depois do pedido

Depois de um pedido de visitante, a success page mostra um bloco oferecendo a criação de uma conta, renderizado pelo Magento\Checkout\Block\Registration. Quando o cliente clica, o Magento guarda os dados do pedido em um delegation storage e redireciona para o formulário de cadastro com nome e e-mail já preenchidos.

Quando a conta é criada, um observer no Magento_Sales atribui aquele pedido ao novo cliente pelo Magento\Sales\Model\Order\CustomerAssignment. O pedido recebe o novo customer_id, o customer_is_guest vira 0 e ele aparece no histórico da conta.

Só o pedido daquela success page é vinculado. Pedidos de visitante anteriores com o mesmo e-mail continuam como pedidos de visitante. O Magento Open Source não tem um jeito nativo de vinculá-los.

Vinculando pedidos antigos de visitante com segurança

Um pedido comum é "quando um cliente se cadastrar, anexe todos os pedidos anteriores de visitante dele". Parece fácil: achar pedidos de visitante com o mesmo e-mail e definir o customer id. O risco é de segurança. Qualquer pessoa pode se cadastrar com o e-mail de outra e, se a conta ficar ativa na hora, ver o histórico de pedidos, os endereços e o telefone dessa pessoa.

Por isso o vínculo só deve acontecer depois de provado que o e-mail pertence ao cliente. O gatilho mais seguro é a confirmação de e-mail da conta, que você habilita em Stores, Configuration, Customers, Customer Configuration, Create New Account Options, Require Emails Confirmation. Então rode o vínculo depois que a conta for confirmada, não depois de criada.

O vínculo em si pode reaproveitar a mesma classe do core que o fluxo da success page usa:

<?php
declare(strict_types=1);

namespace Vendor\GuestOrders\Model;

use Magento\Customer\Api\Data\CustomerInterface;
use Magento\Framework\Api\SearchCriteriaBuilder;
use Magento\Sales\Api\OrderRepositoryInterface;
use Magento\Sales\Model\Order\CustomerAssignment;

class LinkGuestOrders
{
    public function __construct(
        private readonly OrderRepositoryInterface $orderRepository,
        private readonly SearchCriteriaBuilder $searchCriteriaBuilder,
        private readonly CustomerAssignment $customerAssignment
    ) {
    }

    public function execute(CustomerInterface $customer): int
    {
        $criteria = $this->searchCriteriaBuilder
            ->addFilter('customer_email', $customer->getEmail())
            ->addFilter('customer_is_guest', 1)
            ->addFilter('customer_id', true, 'null')
            ->create();

        $linked = 0;
        foreach ($this->orderRepository->getList($criteria)->getItems() as $order) {
            if ((int) $order->getStore()->getWebsiteId() !== (int) $customer->getWebsiteId()) {
                continue;
            }

            $this->customerAssignment->execute($order, $customer);
            $linked++;
        }

        return $linked;
    }
}

A checagem de website importa quando as contas de cliente são por website. Em Customer Configuration, Account Sharing Options, as contas podem ser compartilhadas globalmente ou por website. Com contas por website, o mesmo e-mail pode pertencer a dois clientes diferentes em dois websites, e um pedido de um não pode acabar na conta do outro.

Rode isso a partir de um consumer de queue ou de um cron, não dentro da requisição que confirma a conta, para que um cliente com centenas de pedidos de visitante não fique esperando. Para uma base de clientes existente, um comando CLI único pode rodar a mesma classe para todas as contas confirmadas. Teste antes em uma cópia sanitizada da produção. Veja sanitizando um banco de staging.

Checagem de e-mail no checkout

No checkout do Luma, quando um visitante digita um e-mail, o frontend pergunta ao servidor se existe uma conta para ele e, se existir, mostra um campo de senha para fazer login. Isso é conveniente, mas também diz a qualquer pessoa se um e-mail tem conta na loja, o que é uma preocupação de privacidade. O Magento 2.4.7 adicionou uma configuração em Checkout Options, Enable Guest Checkout Login, que vem desligada por padrão. Quando está desligada, o checkout não revela se o e-mail tem conta. Confira essa configuração depois de um upgrade de uma versão mais antiga, porque o comportamento do checkout muda e os lojistas às vezes relatam como bug.

Carrinhos quando um visitante faz login

Se um visitante adiciona produtos e depois faz login, o Magento faz o merge do carrinho de visitante no carrinho ativo do cliente. Os itens que já estavam no carrinho do cliente permanecem, e as quantidades do mesmo produto são somadas. Os clientes às vezes notam itens antigos aparecendo no checkout. Isso é esse merge, não um bug. O recurso "Persistent Shopping Cart", configurado em Customers, Persistent Shopping Cart, é um mecanismo separado que mantém por um tempo o carrinho de um cliente deslogado.

Na loja, o que o header e o minicart mostram depois do login vem das customer data sections carregadas por JavaScript. Se parecerem desatualizados depois de um fluxo de login customizado, provavelmente as sections não foram invalidadas. Customer data sections explica como isso funciona.

Headless e GraphQL

Em uma loja headless valem as mesmas regras, mas o frontend é dono do fluxo. Visitantes usam um cart id sem autenticação e precisam definir um e-mail no carrinho com o setGuestEmailOnCart antes de finalizar o pedido. Clientes logados usam um token de cliente, e fazer o merge de um carrinho de visitante no carrinho do cliente é uma chamada explícita ao mergeCarts. Os detalhes estão em mutations de carrinho e checkout no GraphQL.

O fluxo de criação de conta depois do pedido da success page do Luma não existe no GraphQL. Um frontend headless que queira o mesmo comportamento precisa criar a conta e atribuir o pedido por conta própria, com as mesmas preocupações de verificação de e-mail descritas acima.

FAQ

Por que um pedido de visitante não aparece na conta do cliente?

Pedidos de visitante mantêm o customer_id vazio mesmo quando o e-mail bate com uma conta existente. Só o pedido vinculado pelo cadastro na success page é atribuído automaticamente. Pedidos mais antigos precisam de um vínculo customizado.

É seguro vincular pedidos de visitante por e-mail automaticamente?

Só depois que o cliente confirmou o endereço de e-mail. Do contrário qualquer pessoa pode se cadastrar com o e-mail de outra e ver os pedidos e endereços dela.

Por que visitantes não recebem o mesmo desconto que clientes logados?

Visitantes sempre pertencem ao grupo de clientes NOT LOGGED IN. Adicione esse grupo às regras de preço que devem valer para visitantes.

Como um visitante consulta o status de um pedido?

Pela página Orders and Returns em /sales/guest/form/, usando o número do pedido, o sobrenome da cobrança e o e-mail ou CEP.

Atendo como freelancer em Magento e Adobe Commerce, incluindo fluxos de checkout e de contas de cliente. Se precisar de ajuda com isso, fale comigo.