Checkout agêntico

TL;DR — Checkout agêntico é a parte de “aperte comprar por mim” das compras com IA. Quando um assistente de IA encontra um produto e conclui a compra por você, essa etapa final da transação é o checkout agêntico. No fluxo de pagamento delegado da OpenAI, o agente usa um token de pagamento com escopo, em vez do número bruto do cartão; para qualquer ação arriscada (login ou verificação adicional), ele para e devolve o controle a uma pessoa. É uma peça dos protocolos maiores (ACP e UCP), não uma coisa independente.

O que é checkout agêntico

A maior parte das “compras com IA” é descoberta: você pede a um assistente que encontre algo, ele lê os feeds de produtos dos comerciantes e sugere opções. O checkout agêntico é a etapa seguinte — o momento em que o agente realmente cria o pedido, escolhe uma opção de envio, calcula impostos e frete, encaminha o pagamento e finaliza a compra.

A palavra-chave é etapa. Checkout agêntico não é um produto ou uma empresa separados. É a capacidade de concluir uma transação incorporada aos dois grandes padrões de comércio agêntico — o Agentic Commerce Protocol (ACP), da OpenAI e da Stripe, e o Universal Commerce Protocol (UCP), do Google e da Shopify. Se você quer a visão geral desses protocolos, os artigos irmãos cobrem cada um deles; esta página se concentra na mecânica do checkout.

Os três erros mais comuns

• “A IA compra sem nenhuma participação humana.” Não exatamente. Os dois protocolos têm uma etapa incorporada de “parar e pedir ajuda a uma pessoa” — para login, verificação adicional do cartão ou confirmação. Um checkout realmente sem intervenção não é como as especificações foram construídas.
• “A IA vê meu cartão de crédito.” Não. O pagamento é transmitido como um token com escopo — um substituto vinculado a um comerciante, um valor e uma janela de tempo, que só pode ser usado uma vez. O número bruto do cartão nunca chega ao agente.
• “Isso já é normal — a maioria das lojas oferece.” Também não. Em meados de 2026, ainda era cedo: apenas cerca de uma dúzia de lojas Shopify havia ativado o checkout do ChatGPT antes de a OpenAI reduzir a versão totalmente dentro do chat, em março de 2026.

Quem é responsável se algo der errado?

A loja em que você comprou continua sendo a loja — o que se chama merchant of record (comerciante responsável pelo registro). Ela cuida do pedido, dos reembolsos e das disputas, como em uma compra online normal. A parte realmente complicada, que ninguém resolveu por completo, é o que acontece com uma cobrança contestada quando o “comprador” era um agente de IA. O artigo Advanced explica isso melhor.

Quer ver a máquina de estados, entender como os tokens de pagamento são delimitados, saber onde uma pessoa precisa intervir e descobrir o que os comerciantes devem testar antes de ativar o recurso? Mude para a aba Advanced.

TL;DR — Checkout agêntico é a capacidade de concluir a transação no comércio agêntico: criar, atualizar, concluir ou cancelar uma sessão de checkout, delegar o pagamento e confirmar o pedido. É um bloco do ACP e um recurso do UCP, não um protocolo independente. A espinha dorsal técnica é uma máquina de estados: no ACP, a sessão passa por not_ready_for_payment → ready_for_payment → (requires_escalation / authentication_required quando necessário) → completed, refletindo o fluxo do UCP incomplete → requires_escalation → ready_for_complete. Os estados de escalonamento são a junção deliberada com a participação humana. A delegação do pagamento usa tokens com escopo — vinculados ao comerciante, limitados por valor e tempo e de uso único — para que o agente nunca tenha um cartão bruto. A confirmação do pedido é enviada por push: os comerciantes fazem POSTs de webhooks HMAC-assinados com o objeto completo. O comerciante continua sendo o merchant of record, portanto liquidação, reembolsos e chargebacks ficam com ele e seu PSP; mas a estrutura probatória para chargebacks continua genuinamente sem solução em meados de 2026. Antes de ativar, construa e teste retries seguros contra duplicação, verificação da assinatura dos webhooks e os caminhos de escalonamento.

Escopo: esta é a etapa da transação, não o protocolo inteiro

Checkout agêntico é uma capacidade. No ACP, ele é literalmente o bloco Agentic Checkout (um de cinco, ao lado de Product Feed, Delegate Payment, Delegate Authentication e Orders/Webhooks). No UCP, é a capacidade de checkout dentro de uma especificação mais ampla, negociada por capacidades. Os artigos irmãos sobre ACP e UCP cobrem o protocolo e o contexto de negócio — qualidade do feed, o perfil /.well-known/ucp e as implicações de descoberta da mudança de março de 2026. Esta página fica na mecânica de concluir a transação: ciclo de vida da sessão, delegação do pagamento, pontos de intervenção humana, confirmação do pedido e responsabilidade.

Uma ideia que vem do artigo irmão sobre ACP e não precisa ser reargumentada aqui: agentes transacionam usando feeds e APIs, não o HTML rastreado do seu site. Portanto, o que se otimiza aqui é a confiabilidade do checkout, não o texto da página.

A máquina de estados da sessão de checkout

A coisa mais importante — e que a maioria dos textos deixa de lado — é que um checkout é uma sessão com um status, e esse status percorre uma máquina definida.

A referência de Checkout do ACP lista o enum completo de status: incomplete, not_ready_for_payment, requires_escalation, authentication_required, ready_for_payment, pending_approval, complete_in_progress, completed, canceled, in_progress e expired. O caminho feliz é curto — not_ready_for_payment → ready_for_payment → in_progress → completed, com canceled como o outro estado terminal. De acordo com os conceitos de ciclo de vida do ACP, fornecer uma opção de entrega obrigatória é o que move uma sessão de not_ready_for_payment para ready_for_payment; um pagamento recusado pode devolvê-la a ready_for_payment para uma nova tentativa.

Os estados interessantes são os que ficam fora do caminho feliz:

• requires_escalation / authentication_required — o agente não pode avançar sozinho; é necessária uma pessoa ou uma verificação adicional (veja a próxima seção).
• pending_approval — aguardando aprovação, por exemplo a autorização de um pedido de compra B2B.
• expired — a sessão expirou (CheckoutSession carrega expires_at).

Este é o mesmo desenho subjacente do checkout do UCP, que percorre incomplete → requires_escalation → ready_for_complete, e no qual requires_escalation devolve o controle a uma pessoa por meio de uma continue_url (coberta no artigo irmão sobre UCP). Dois protocolos separados, um padrão convergente: um checkout nem sempre consegue terminar sem parar para perguntar algo a uma pessoa. Isso não é uma limitação acrescentada depois — é o formato central do desenho.

Uma observação prática para quem desenvolve com ACP: uma requisição malformada devolve um objeto de erro no nível HTTP (o campo type pode ser invalid_request, request_not_idempotent, processing_error ou service_unavailable). Já um problema de lógica de negócio dentro de uma sessão válida volta como um objeto MessageError no array messages[] da sessão, não como erro HTTP. Você precisa tratar os dois, e é fácil confundi-los no início da integração.

Como funciona a delegação do pagamento

O objetivo de toda a camada de delegação do pagamento é que os dados brutos do cartão nunca cheguem ao agente. Em vez de entregar o número do cartão, os dados de pagamento do comprador são transformados em um token com escopo.

De acordo com a especificação de Pagamento Delegado da OpenAI, o payload de pagamento delegado é enviado diretamente ao PSP ou vault do comerciante, e o PSP ou vault devolve um token de pagamento delimitado ao pagamento delegado, fora do escopo PCI. Esse token é limitado em quatro eixos:

• reason — atualmente "one_time": uso único.
• max_amount — limita a cobrança ao total do checkout; o token não pode ser usado para cobrar a mais.
• expires_at (RFC 3339) — o token tem uma expiração rígida.
• merchant_id + checkout_session_id — ficam vinculados a um comerciante e a uma sessão.

Portanto, um token delegado fica vinculado ao comerciante, limitado por valor e tempo e é de uso único. Esse é o mecanismo que permite a um agente “gastar dinheiro” sem jamais receber uma credencial de cartão reutilizável. No ACP, o Shared Payment Token da Stripe é descrito como a primeira implementação compatível com a Delegated Payment Spec, e outros PSPs devem vir depois. O UCP usa um modelo desacoplado paralelo que separa instrumentos de pagamento de handlers (coberto no artigo irmão sobre UCP).

O escopo PCI é uma decisão real aqui. A especificação da OpenAI é explícita: integrar diretamente com a Delegated Payment Spec envolve lidar diretamente com dados do titular do cartão e pode afetar seu escopo PCI; a integração direta exige status PCI DSS Level 1. Para a maioria dos comerciantes, o caminho tokenizado (tokens de rede ou um PSP que cuide da delegação) é a forma de manter os dados do titular fora do seu ambiente. Escolher entre “lidar diretamente com CHD” e “deixar o PSP tokenizar” é a primeira decisão de arquitetura — a aba Decision percorre as opções.

Onde uma pessoa ainda precisa intervir

“O comprador ainda autoriza” é verdade, mas é vago. Os gatilhos no nível do protocolo são específicos, e nomeá-los é como você projeta a transferência de controle em vez de chegar a um beco sem saída silencioso:

• 3-D Secure / etapa adicional. O ACP modela isso com InterventionCapabilities (os tipos compatíveis incluem 3ds e address_verification), um nível de enforcement (always / conditional / optional) e um display_context (native / webview / modal / redirect). O resultado volta como um AuthenticationResult, com valores como authenticated, denied, rejected, abandoned, canceled ou not_supported.
• Estados requires_escalation / authentication_required. São os status da sessão que dizem: “preciso de uma pessoa ou de uma verificação adicional antes de continuar”.
• approval_required em B2B. O objeto PaymentData carrega campos B2B (purchase_order_number, payment_terms, due_date, approval_required) — checkout agêntico não é apenas DTC.
• Transferência por continue_url no UCP. O requires_escalation do UCP expõe uma continue_url para que o comprador conclua a etapa sozinho (login, confirmação ou verificação de idade). É a mesma junção, em outro protocolo.

A conclusão é simples: uma transação que escala corretamente é muito melhor do que uma que termina em silêncio. Projete os caminhos de escalonamento como fluxos de primeira classe, não como casos de erro.

A confirmação do pedido é push, não pull

Aqui está um ponto que os explicadores concorrentes em grande parte deixam de fora. Depois da compra, a plataforma do agente não fica consultando sua API para saber o status do pedido. O comerciante envia webhooks assinados.

De acordo com a referência de webhooks do ACP, os comerciantes fazem POST de eventos do pedido para que a plataforma do agente permaneça sincronizada com a verdade do fulfillment. Dois tipos de evento transportam essa informação: order_create para novos pedidos e order_update para mudanças de estado. Os status de pedido citados incluem created, manual_review, confirmed, canceled, shipped e fulfilled. Três detalhes importam para quem vai implementar isso:

• As requisições precisam ser assinadas com uma assinatura HMAC no cabeçalho Merchant-Signature. Requisições sem assinatura ou com assinatura incorreta recebem 401.
• O campo data precisa conter o objeto Order completo, não deltas incrementais. Envie o estado inteiro todas as vezes.
• Códigos de resposta a tratar: 200 para sucesso, 401 para assinatura inválida e 429 para limitação de taxa.

Então, “como a plataforma sabe que o pedido foi concluído?” tem uma resposta concreta: você informa, com um POST assinado contendo o objeto completo, e trata a contrapressão da plataforma por meio de 429.

Fraude, chargebacks e responsabilidade — o que está resolvido e o que não está

Esta é a seção mais honesta e mais diferenciadora, então vou ser direto sobre onde realmente fica a linha entre o que está “resolvido” e o que continua em aberto.

O que está resolvido: o merchant of record. A própria especificação de pagamento da OpenAI afirma que a OpenAI não é o merchant of record — no ACP, os comerciantes trazem seu próprio PSP, e liquidação, reembolsos, chargebacks e compliance continuam com o comerciante e seu PSP. Arjun Bhargava, da Rye, confirma isso de forma independente: os dois protocolos mantêm o comerciante como merchant of record, responsável por fulfillment, chargebacks e disputas. Isso é consistente com o enquadramento de merchant of record nos dois artigos irmãos — leve essa premissa adiante, sem rederivá-la.

O que não está resolvido: a estrutura probatória do chargeback. Ser merchant of record diz quem absorve uma disputa por padrão. Não diz como você vence uma disputa quando o “cliente” foi mediado por um agente de IA. A defesa tradicional contra chargebacks depende de trilhas de evidências geradas por pessoas (IP, dispositivo, comportamento de navegação e uma pessoa clicando em “comprar”). Logs de autorização gerados por agentes são outro tipo de evidência, e as regras de disputa das redes de cartões não foram escritas para eles. Ben Herut, especialista em fraude da Chargeflow, descreve o comércio agêntico como uma nova camada de fraude e confusão que os sistemas legados não conseguem interpretar; a análise da Chargeflow é ainda mais direta: ainda não existem respostas claras — redes de cartões, emissores e provedores de plataformas estão trabalhando nessas questões.

Os frameworks emergentes ainda estão em construção. O Trusted Agent Protocol da Visa é descrito como um framework baseado em padrões que permite aos comerciantes verificar a identidade e a intenção de um agente em tempo real, evitando personificação sem degradar a experiência do usuário. O Agent Pay da Mastercard (anunciado em abril de 2025) usa “Agentic Tokens”, uma extensão do Digital Enablement Service. Segundo reportagens de terceiros (Fintech Wrap Up / Finextra), a responsabilidade da Mastercard seguiria as mesmas regras de transações tokenizadas comuns — o emissor assumiria a responsabilidade por fraude quando o token fosse emitido e aceito validamente na autorização —, mas eu trataria essa distribuição específica como relatada, não confirmada até que apareça na documentação da Mastercard. E observe que a garantia de responsabilidade zero da Visa voltada ao consumidor protege titulares de cartão contra cobranças não autorizadas; ela não resolve a questão da disputa do lado do comerciante, que é o ponto realmente aberto. Não confunda as duas coisas.

O que os comerciantes precisam implementar e testar

O conteúdo existente oferece conselhos estratégicos de preparação (limpar feeds, programas de fidelidade). Aqui está a camada operacional — o que de fato construir e verificar antes de ativar o recurso:

• Decida sua postura de PCI. Compare o caminho tokenizado/token de rede com o tratamento direto de CHD (Level 1). A maioria dos comerciantes prefere que o PSP mantenha a delegação.
• Torne os retries seguros contra duplicação. O ACP tem um tipo de erro request_not_idempotent por um motivo. Um agente (ou uma rede instável) vai repetir uma chamada de criação ou conclusão; envie uma chave de idempotência e torne seguras as chamadas repetidas com a mesma chave, para não cobrar duas vezes nem criar dois pedidos.
• Verifique as assinaturas dos webhooks. Valide o HMAC Merchant-Signature em cada webhook de pedido recebido, rejeite divergências e confirme que você devolve 200/429 corretamente sob carga.
• Simule os caminhos de escalonamento no sandbox. Force requires_escalation / authentication_required, execute uma etapa 3DS e confirme que o tratamento de AuthenticationResult cobre denied/rejected/abandoned, não apenas authenticated.
• Concilie a paridade de preço entre feed e checkout. Se o agente vê um preço no feed e o checkout devolve outro, a confiança se perde rapidamente — o artigo irmão sobre feeds destaca isso, e o impacto é maior no checkout.
• Crie atribuição para pedidos de agentes. Um checkout agêntico concluído pode não ter uma sessão do GA4. Rastreie-o no nível do pedido/OMS, em vez de esperar por uma visita ao site.

As abas Testing SOP e Cheat Sheet transformam isso em um teste concreto.

Em que ponto isso está em meados de 2026

Baseie-se na realidade da adoção, não no discurso do pitch deck. O presidente da Shopify, Harley Finkelstein, indicou que apenas cerca de uma dúzia de comerciantes Shopify usava ativamente ferramentas de checkout com IA — um número insignificante diante da base total de comerciantes da Shopify — e a própria OpenAI reduziu a versão totalmente dentro do chat do Instant Checkout para descoberta com redirecionamento em março de 2026, depois de enfrentar dificuldades de onboarding, precisão e carrinhos com vários itens. Leigh McKenzie, da Semrush, resumiu bem o atrito: normalizar em tempo real catálogos com dezenas de milhões de SKUs é um problema de escala de uma década, e os consumidores continuam preferindo fluxos de checkout em que confiam — Apple Pay, Google Wallet e o one-click da Amazon.

Isso não significa que o checkout agêntico seja vaporware. A capacidade do protocolo — criar, atualizar e concluir uma sessão programaticamente, com pagamento delegado e webhooks de pedido assinados — é real, especificada e vale a pena implementar. Apenas não é “já normal”, e o fato de a etapa final fechar dentro do chat ou no seu site é um detalhe de implementação que já mudou uma vez e pode mudar novamente.

Resumo de IA

Uma versão condensada do conteúdo Advanced:

• Checkout agêntico = a etapa de conclusão da transação do comércio agêntico: um agente cria, atualiza, conclui ou cancela uma sessão de checkout em nome de um comprador. É um bloco do ACP e do UCP, não um protocolo independente.
• É uma máquina de estados. ACP: not_ready_for_payment → ready_for_payment → (requires_escalation/authentication_required) → completed, com canceled, expired e pending_approval fora do caminho feliz. O UCP segue incomplete → requires_escalation → ready_for_complete.
• Os estados de escalonamento são a junção com a participação humana — login, etapa 3DS, verificação de endereço, approval_required B2B e continue_url do UCP. Um checkout totalmente autônomo, sem nenhuma pessoa, não é como as especificações foram construídas.
• Pagamento = tokens com escopo: vinculados ao comerciante (merchant_id + checkout_session_id), limitados por valor (max_amount), por tempo (expires_at) e de uso único (reason: one_time). O agente nunca recebe um cartão bruto. O tratamento direto de CHD afeta o escopo PCI (Level 1); a maioria dos comerciantes usa o caminho tokenizado pelo PSP.
• A confirmação do pedido é um push: os comerciantes fazem POST de webhooks HMAC-assinados (Merchant-Signature; eventos order_create/order_update) com o objeto completo e tratam 200/401/429.
• Responsabilidade: o comerciante continua como merchant of record (liquidação, reembolsos e chargebacks com comerciante + PSP, segundo a especificação da OpenAI), mas a questão probatória do chargeback — contestar uma compra feita por um agente de IA — continua sem solução em meados de 2026. Visa TAP e Mastercard Agent Pay são frameworks emergentes, ainda não concluídos.
• Teste: retries seguros contra duplicação (request_not_idempotent), verificação da assinatura dos webhooks, caminhos simulados de escalonamento/3DS, paridade entre preço do feed e do checkout e atribuição do pedido do agente (sem sessão GA4).
• A adoção ainda é inicial: cerca de uma dúzia de comerciantes Shopify estavam ativos antes da mudança da OpenAI, em março de 2026, para descoberta com redirecionamento.

Documentação oficial

Documentação de fontes primárias para a mecânica do checkout.

ACP — checkout, ciclo de vida e webhooks

• Referência da API de Checkout do ACP — endpoints da sessão, enum completo de status, campos de CheckoutSession, objetos de erro/MessageError, RiskSignals, AuthenticationResult e InterventionCapabilities.
• Ciclo de vida/conceitos do ACP — transições de estado (opção de fulfillment → ready_for_payment; retry após pagamento recusado).
• Webhooks de pedido do ACP — eventos order_create/order_update, exigência HMAC de Merchant-Signature, payloads com objeto completo e códigos de resposta.
• Especificação do ACP no GitHub — OpenAPI/JSON Schema e versões por data.

OpenAI / Stripe — delegação do pagamento

• Especificação de Pagamento Delegado da OpenAI — fluxo do token com escopo, objeto de permissões (max_amount, expires_at, merchant_id, checkout_session_id, reason), nota sobre escopo PCI e linguagem de merchant of record.
• Documentação de comércio da OpenAI — visão geral da integração de comerciantes.
• Stripe — Agentic Commerce (ACP) — Shared Payment Token, a primeira implementação compatível com o pagamento delegado.
• Stripe — especificação do protocolo ACP — construção dos endpoints de checkout.

UCP (máquina de checkout paralela)

• Google for Developers — guia do UCP — enquadramento de merchant of record e elegibilidade no lado Google/Shopify.

Plataforma / rede de pagamentos

• Shopify — requisitos de Agentic Storefronts — os Supplemental Terms e, segundo a pesquisa, o status de acesso antecipado ao Google AI Mode/Gemini.
• Visa — Ameaças e riscos do comércio agêntico — o enquadramento do Trusted Agent Protocol.

Citações da fonte

Declarações registradas sobre como o checkout agêntico funciona e sobre as questões em aberto. Os links profundos saltam para a passagem citada quando a página de origem a sustenta.

**ACP / OpenAI — a especificação

• “Merchant maintains full control over inventory, pricing, tax calculations, and payment processing.” (tradução) «O comerciante mantém controle total sobre estoque, preços, cálculos de impostos e processamento de pagamentos.» — Referência da API de Checkout do ACP. Ir para a citação
• O enum de status do checkout, literalmente: “incomplete not_ready_for_payment requires_escalation authentication_required ready_for_payment pending_approval complete_in_progress completed canceled in_progress expired.” (tradução) «o enum completo inclui os estados de incompleto, pronto para pagamento, escalonamento, autenticação, pagamento pronto, aprovação pendente, conclusão em andamento, concluído, cancelado, em andamento e expirado.» — Referência da API de Checkout do ACP. Ir para a citação
• “OpenAI is not the merchant of record.” (tradução) «A OpenAI não é o merchant of record.» No ACP, os comerciantes trazem seu próprio PSP, e liquidação, reembolsos, chargebacks e compliance permanecem com o comerciante e seu PSP. — Especificação de Pagamento Delegado da OpenAI. Ir para a citação
• Sobre o fluxo do token: o PSP ou vault devolve um “payment token scoped to the delegated payment” (tradução) «token de pagamento delimitado ao pagamento delegado» fora do escopo PCI. — Especificação de Pagamento Delegado da OpenAI. Ir para a citação

**Vozes do setor — a questão da responsabilidade

• “Agentic commerce brings efficiency, but also a new layer of fraud and confusion that legacy systems cannot interpret.” (tradução) «O comércio agêntico traz eficiência, mas também uma nova camada de fraude e confusão que os sistemas legados não conseguem interpretar.» — Ben Herut, estrategista de fraude e chargebacks da Chargeflow. Leia a análise
• Sobre a questão estar resolvida: segundo a análise da Chargeflow, “there are no clean answers yet” (tradução) «ainda não há respostas claras» — redes de cartões, emissores e provedores de plataformas estão trabalhando nessas questões. Leia a análise
• “Both protocols keep the merchant as the merchant of record — responsible for fulfillment, chargebacks, and disputes.” (tradução) «Os dois protocolos mantêm o comerciante como merchant of record — responsável por fulfillment, chargebacks e disputas.» — Arjun Bhargava, cofundador e CEO da Rye. Leia a análise

**Redes de pagamentos — frameworks emergentes

• Sobre a abordagem da Visa: o Trusted Agent Protocol é “a standards-based framework enabling merchants to verify agent identity and intent in real time, preventing impersonation without degrading user experience.” (tradução) «um framework baseado em padrões que permite aos comerciantes verificar a identidade e a intenção do agente em tempo real, evitando personificação sem degradar a experiência do usuário.» — Visa. Ir para a citação

**Realidade da adoção

• Sobre por que o checkout totalmente autônomo está mais lento que o hype: “Real-time catalog normalization across tens of millions of SKUs is a decade-scale problem Google already solved with Merchant Center, and consumers still default to checkout flows they trust—Apple Pay, Google Wallet, and Amazon one-click.” (tradução) «Normalizar em tempo real um catálogo com dezenas de milhões de SKUs é um problema de escala de uma década que o Google já resolveu com o Merchant Center, e os consumidores ainda preferem fluxos de checkout em que confiam — Apple Pay, Google Wallet e o one-click da Amazon.» — Leigh McKenzie, diretora de visibilidade online da Semrush, via Search Engine Land. Leia a análise

Qual caminho de integração de pagamento você deve escolher?

A primeira decisão real de arquitetura no checkout agêntico é como o pagamento será delegado — porque isso determina diretamente seu escopo PCI e quanto você terá de construir. Percorra as opções:

Teste pré-lançamento do checkout agêntico

Execute isto em modo sandbox/teste antes de ativar o checkout agêntico em produção. Esta é a camada operacional que o conselho estratégico de “limpar seu feed” deixa de fora.

1. Crie uma sessão de checkout e percorra o caminho feliz. Faça POST /checkout_sessions, confirme que recebe 201 e uma sessão em not_ready_for_payment (ou incomplete). Adicione uma opção de fulfillment e confirme a transição do status para ready_for_payment.
2. Verifique se os totais são a fonte de verdade. Confirme que totals[] da sessão (subtotal / imposto / fulfillment / descontos / total) correspondem ao cálculo do seu backend — e que o preço é igual ao do feed. Divergência de preço entre feed e checkout destrói a confiança.
3. Conclua a sessão. Faça POST /checkout_sessions/{id}/complete; confirme que o pagamento é processado, um pedido é criado e o status chega a completed.
4. Cancele uma sessão. Faça POST /checkout_sessions/{id}/cancel; confirme que o estoque é liberado para não deixar unidades reservadas sem controle.
5. Force os caminhos de escalonamento. Simule requires_escalation / authentication_required. Execute uma etapa 3DS e confirme que o tratamento de AuthenticationResult cobre os resultados de falha (denied, rejected, abandoned, canceled, not_supported), não apenas authenticated.
6. Teste a idempotência. Envie a mesma requisição de criação/conclusão duas vezes com a mesma chave de idempotência; confirme que recebe um pedido, não dois, e que um retry realmente não idempotente expõe request_not_idempotent em vez de cobrar duas vezes.
7. Teste erros de lógica de negócio contra erros HTTP. Provoque um problema dentro da sessão (por exemplo, um item sem estoque) e confirme que ele volta como um objeto MessageError em messages[], enquanto uma requisição malformada volta como um objeto de erro no nível HTTP — seu cliente precisa tratar ambos.
8. Verifique as assinaturas dos webhooks. Envie um webhook order_create válido e confirme que valida o HMAC Merchant-Signature e devolve 200. Envie um webhook adulterado e confirme a rejeição com 401. Confirme que emite o objeto Order completo, não um delta.
9. Teste a contrapressão dos webhooks. Confirme que o remetente trata um 429 da plataforma com retry/backoff, em vez de descartar o evento.
10. Confirme a captura da atribuição. Verifique que o pedido concluído é marcado como originado por agente no nível do OMS, já que não haverá uma sessão do GA4.

Erros comuns (e o que fazer no lugar)

Presumir que “checkout agêntico” significa uma compra totalmente autônoma, sem participação humana. Por que está errado: toda implementação confiável mantém uma junção de autorização/escalonamento — requires_escalation, authentication_required, etapa 3DS e approval_required B2B. Autonomia completa sem autorização de uma pessoa no circuito não é como as especificações foram construídas nem como as redes de cartões tratam atualmente essas transações. Faça isto: projete os caminhos de escalonamento (continue_url, 3DS e aprovação) como fluxos de primeira classe, para que uma transação que precisa de uma pessoa escale corretamente em vez de terminar em um beco sem saída.

Tratar isto como algo já normal porque as manchetes são barulhentas. Por que está errado: apenas cerca de uma dúzia de comerciantes Shopify havia ativado o checkout do ChatGPT antes de a OpenAI reduzir a versão dentro do chat, em março de 2026. Faça isto: implemente a capacidade do protocolo (ela é real e especificada), mas planeje e dimensione como um adotante inicial, não como alguém atrasado tentando alcançar o mercado.

Acreditar que a responsabilidade por fraude está totalmente resolvida porque “merchant of record” está definido. Por que está errado: merchant of record está confirmado para liquidação, reembolsos e compliance, mas a estrutura probatória do chargeback — provar que uma transação foi devidamente autorizada quando o comprador era um agente de IA — é descrita explicitamente por especialistas do setor como sem solução. Faça isto: capture agora os logs de autorização do agente e os sinais de risco, trate Visa TAP/Mastercard Agent Pay como frameworks emergentes (não concluídos) e não presuma que suas evidências atuais de defesa contra chargebacks serão transferidas.

Presumir que o agente ignora seu site, portanto o checkout no site não importa. Por que está errado: “sempre ignora o site do comerciante” era o discurso original do ChatGPT Instant Checkout, mas a própria implementação principal do ACP mudou para descoberta com redirecionamento em março de 2026. A capacidade do protocolo é independente da implementação. Faça isto: mantenha sólido o checkout hospedado por você e ofereça o fluxo de sessão programático — a conclusão pode acontecer no chat ou no site, dependendo da superfície.

Achar que o agente lida com o número do cartão do cliente. Por que está errado: os dados brutos do cartão nunca chegam ao agente por desenho — tokens com escopo/delegados (Shared Payment Token e o modelo desacoplado de instrumento/handler do UCP) são justamente o objetivo da camada de delegação do pagamento. Faça isto: encaminhe a delegação pelo seu PSP para que um token vinculado ao comerciante, limitado por valor e de uso único faça o trabalho — e mantenha seu escopo PCI pequeno.

Tratar retries não idempotentes. Por que está errado: agentes e redes fazem retries. O ACP tem um tipo de erro request_not_idempotent precisamente porque retries ingênuos podem cobrar duas vezes ou criar dois pedidos. Faça isto: exija chaves de idempotência em criação/conclusão e torne seguras as chamadas repetidas com a mesma chave.

Cheat sheet do checkout agêntico

Enum de status da sessão de checkout do ACP

Máquina paralela do UCP: incomplete → requires_escalation (pessoa via continue_url) → ready_for_complete.

Endpoints de checkout (ACP)

• POST /checkout_sessions — criar (201)
• GET /checkout_sessions/{id} — consultar
• POST /checkout_sessions/{id} — atualizar
• POST /checkout_sessions/{id}/complete — processar pagamento + criar pedido
• POST /checkout_sessions/{id}/cancel — cancelar + liberar estoque

Token de pagamento com escopo — os quatro limites

• merchant_id + checkout_session_id → vinculado ao comerciante e à sessão
• max_amount → limitado por valor
• expires_at (RFC 3339) → limitado por tempo
• reason: "one_time" → uso único

Webhooks de pedido (ACP)

• Eventos: order_create, order_update
• Assinatura: cabeçalho HMAC Merchant-Signature (obrigatório)
• Payload: objeto Order completo, não deltas
• Respostas: 200 ok · 401 assinatura inválida · 429 com limitação de taxa
• Status do pedido: created · manual_review · confirmed · canceled · shipped · fulfilled

Gatilhos de intervenção humana

• Estados requires_escalation / authentication_required
• InterventionCapabilities (3ds, address_verification; enforcement always/conditional/optional)
• Resultados de AuthenticationResult (authenticated/denied/rejected/abandoned/…)
• approval_required B2B; continue_url do UCP

Responsabilidade em um olhar

• Comerciante = merchant of record → liquidação/reembolsos/chargebacks com comerciante + PSP ✅ resolvido
• Regras de evidência de chargeback para compradores-agentes ⚠️ sem solução (meados de 2026)
• Visa TAP / Mastercard Agent Pay → frameworks emergentes, ainda não concluídos

Trechos para trabalhar com checkout agêntico

Estes exemplos servem para inspecionar e testar sua própria integração — não para conduzir compras reais. Use credenciais de sandbox/teste.

Verificar uma assinatura de webhook (Node.js, HMAC)

Rejeite tudo cuja Merchant-Signature não corresponda. Compare em tempo constante.

import crypto from "node:crypto";

// secret = your shared webhook signing secret; rawBody = the exact bytes received
function verifyMerchantSignature(rawBody, signatureHeader, secret) {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(rawBody)          // sign the raw body, not the parsed JSON
    .digest("hex");
  const a = Buffer.from(expected);
  const b = Buffer.from(signatureHeader || "");
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}
// In your handler: if (!verify) return res.status(401).end();  // else 200

Consultar o status de uma sessão de checkout (shell)

Observe uma sessão de sandbox percorrer a máquina de estados enquanto testa.

# Retrieve a session and print just its status field (needs jq)
SESSION_ID="cs_test_123"
curl -s "https://api.example.com/checkout_sessions/$SESSION_ID" \
  -H "Authorization: Bearer $ACP_TEST_KEY" \
  | jq -r '.status'          # e.g. not_ready_for_payment → ready_for_payment → completed

Enviar uma chamada de criação com uma chave de idempotência (Python)

Comprove que um retry com a mesma chave produz um pedido, não dois.

import uuid, requests

key = str(uuid.uuid4())  # reuse this SAME key on retry
headers = {
    "Authorization": f"Bearer {ACP_TEST_KEY}",
    "Idempotency-Key": key,
    "Content-Type": "application/json",
}
payload = {"line_items": [{"id": "sku_1", "quantity": 1}]}
r1 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)
r2 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)  # retry
print(r1.json().get("id") == r2.json().get("id"))  # expect True — same session, no dupe

Trecho de console — verificar um perfil UCP em .well-known

Uma verificação rápida no Console do DevTools para saber se um comerciante expõe a descoberta UCP (cole no console do navegador, na origem do comerciante):

fetch("/.well-known/ucp")
  .then(r => (console.log("status:", r.status), r.ok ? r.json() : null))
  .then(p => console.log("capabilities:", p && p.capabilities));

Bookmarklet — saltar para o enum de status do checkout na documentação do ACP

Coloque isto em um favorito para abrir a referência de Checkout do ACP na lista de status:

javascript:location.href='https://www.agenticcommerce.dev/docs/reference/checkout#:~:text=incomplete';

Falhas comuns do checkout agêntico

Um retry cria dois pedidos ou cobranças

Sintoma: a mesma sessão de checkout produz pedidos duplicados depois de um timeout ou retry de rede. Causa provável: as chamadas de criação ou conclusão não têm chave nem proteção contra replay. Correção: exija uma chave de idempotência, devolva o resultado original para um retry com a mesma chave e confirme que duas chamadas idênticas no sandbox produzem uma sessão e um pedido.

O checkout nunca fica pronto para o pagamento

Sintoma: uma sessão permanece em not_ready_for_payment ou incomplete. Causa provável: uma opção de fulfillment obrigatória, um campo de endereço ou uma regra de negócio não foi resolvida. Correção: inspecione os campos obrigatórios da sessão e messages[], forneça a escolha que falta e confirme o avanço para ready_for_payment ou ready_for_complete.

Uma requisição válida parece funcionar, mas o carrinho não pode ser concluído

Sintoma: a requisição HTTP funciona enquanto a sessão contém um erro de negócio, como falta de estoque. Causa provável: o cliente trata apenas erros HTTP e ignora entradas MessageError. Correção: processe tanto os erros de transporte quanto as mensagens da sessão e confirme que a pessoa ou o agente vê uma falha acionável.

A verificação humana termina silenciosamente em um beco sem saída

Sintoma: o checkout entra em requires_escalation ou authentication_required e nunca retorna. Causa provável: a transferência de controle para 3DS, login, aprovação ou continue_url foi tratada como erro excepcional, e não como um estado compatível. Correção: mantenha a sessão durante a transferência, trate todos os resultados de autenticação e confirme que os fluxos bem-sucedidos e abandonados terminam corretamente.

O status do pedido para de atualizar depois do pagamento

Sintoma: o comerciante tem o pedido, mas a superfície do agente continua pendente ou desatualizada. Causa provável: uma assinatura de webhook falha, apenas um delta foi enviado ou respostas 429 foram descartadas. Correção: assine o payload exato, envie o objeto Order completo, repita eventos limitados por taxa com backoff e confirme que o receptor aceita o evento.

Modelos mentais para checkout agêntico

Checkout é uma máquina de estados, não uma chamada de API

Cada resposta deve mover a sessão para um estado conhecido ou expor um motivo conhecido pelo qual ela não pode avançar. Projete os clientes ao redor de transições, estados terminais, retries e escalonamentos, não de uma única requisição de “comprar”.

A autoridade continua com o comerciante

O agente expressa uma intenção, mas o comerciante continua sendo a autoridade sobre preço, estoque, impostos, fulfillment, estado do pedido e obrigações de merchant of record. Trate o carrinho solicitado pelo agente como entrada e o carrinho devolvido pelo comerciante como a verdade.

A delegação reduz a permissão

Um token de pagamento com escopo é seguro porque fica vinculado ao comerciante e à sessão, é limitado por valor e tempo e é de uso único. Avalie cada capacidade delegada perguntando o que ela pode fazer, para quem, por quanto e por quanto tempo.

O escalonamento é um caminho bem-sucedido

A intervenção humana não é um checkout autônomo que falhou. Uma transferência bem executada para 3DS, login, endereço ou aprovação B2B é o protocolo funcionando como foi projetado.

A entrega é assíncrona depois da conclusão

A conclusão do pagamento não encerra a integração. Webhooks assinados com o objeto completo carregam a verdade do pedido depois do checkout; por isso, verificação de assinatura, segurança contra replay e tratamento de retries fazem parte da confiabilidade do checkout.

Métricas para checkout agêntico

Conclusão do checkout por estado terminal

• Métrica: sessões concluídas, canceladas ou expiradas como proporção das sessões iniciadas.
• O que informa: onde termina a máquina de estados do checkout e quanta intenção é perdida antes de existir um pedido.
• Como obter: agregue mudanças de estado das sessões de checkout na API de comércio ou plataforma de pedidos, segmentadas por protocolo e superfície do comerciante.
• Benchmark / faixa realista: estabeleça uma linha de base para seu próprio mix de produtos e compare fluxos equivalentes; nesta fase de adoção, nenhuma taxa universal é defensável.
• Cadência: monitoramento diário com revisão semanal da tendência.

Taxa de recuperação após escalonamento

• Métrica: sessões escaladas que retornam e são concluídas depois de uma intervenção de 3DS, login, endereço ou aprovação.
• O que informa: se a transferência para uma pessoa é um caminho utilizável ou um beco sem saída.
• Como obter: associe eventos de escalonamento a transições de estado posteriores usando o ID da sessão de checkout.
• Benchmark / faixa realista: estabeleça uma linha de base para cada tipo de intervenção, porque autenticação e aprovação B2B têm atritos diferentes.
• Cadência: semanalmente e depois de qualquer mudança no fluxo de transferência.

Taxa de pedidos duplicados e falhas de webhook

• Métrica: pedidos duplicados de retries com a mesma chave, somados a entregas de webhook rejeitadas ou esgotadas.
• O que informa: se a idempotência e a sincronização assíncrona de pedidos são seguras sob falhas.
• Como obter: compare chaves de idempotência, IDs de pedido, falhas de assinatura, 401, 429, retries e eventos em dead letter nos logs da aplicação.
• Benchmark / faixa realista: pedidos duplicados devem ser zero; estabeleça uma linha de base normal de retries transitórios e investigue desvios persistentes.
• Cadência: alerte imediatamente e faça um resumo semanal.

Recursos que valem seu tempo

Meus textos relacionados

• Os dois protocolos que contêm o checkout agêntico são abordados em profundidade neste site — veja os artigos sobre Agentic Commerce Protocol (ACP) e Universal Commerce Protocol (UCP); esta página é o aprofundamento da mecânica do checkout sob os dois.
• The Beginner’s Guide to Ecommerce SEO — onde o checkout voltado a agentes se encaixa no panorama maior de SEO para ecommerce.

Minhas palestras

• How Search Works (SlideShare) — minha explicação de descoberta, indexação e ranqueamento; um contexto útil para entender como uma camada de transação mediada por agente se apoia na busca. (Meu aviso permanente se aplica: “Esta é a minha compreensão dos sistemas… não será 100% completa ou precisa.”)

Do setor

• Referência do checkout do Agentic Commerce Protocol (OpenAI/Stripe) — enum oficial de status, campos da sessão e objetos de intervenção/autenticação.
• Especificação de pagamento delegado da OpenAI — fluxo de tokens com escopo e linguagem sobre merchant of record / escopo PCI.
• Referência de webhooks de pedido do ACP (OpenAI/Stripe) — mecânica de sincronização de pedidos baseada em push, assinada por HMAC e com objeto completo.
• Comércio agêntico: quem responde quando a IA compra? (Chargeflow) — a análise honesta de que “ainda não há respostas claras” para o problema probatório.
• Ameaças e riscos do comércio agêntico (Visa) — o Trusted Agent Protocol e o enquadramento da identidade do agente.
• O plano do Instant Checkout do ChatGPT acabou de mudar (Search Engine Land) — a mudança de março de 2026 e as citações sobre a realidade da adoção.
• O que é checkout agêntico? (Rye) — uma definição independente clara e a confirmação do merchant of record.
• Análise aprofundada: Mastercard Verifiable Intent vs. Visa Trusted Agent Protocol (Fintech Wrap Up / Finextra) — comparação dos frameworks de redes de pagamento (trate a distribuição específica de responsabilidade como relatada, não confirmada).

Números que vale citar

Números que ajudam a enquadrar o estado real do checkout agêntico — trate valores informados por comerciantes e valores repassados como direcionais e verifique-os antes de basear uma conclusão neles.

• Cerca de uma dúzia de comerciantes Shopify usava ativamente ferramentas de checkout com IA — descrito como insignificante diante da base total da Shopify — segundo o presidente da Shopify, em relato repassado pela cobertura do Search Engine Land sobre a mudança de março de 2026. Cobertura
• Março de 2026: a mudança. A OpenAI moveu o Instant Checkout do ChatGPT de uma conclusão completa dentro do chat para descoberta com redirecionamento, depois de enfrentar atritos de onboarding, precisão e carrinhos com vários itens. Cobertura
• Escopo do token = quatro limites. Um token de pagamento delegado é limitado por max_amount, expires_at, merchant_id/checkout_session_id e reason: one_time — o mecanismo concreto que mantém o cartão bruto longe do agente. Fonte
• Regra do webhook: sempre o objeto completo. O ACP exige que o campo data do webhook carregue o objeto Order completo, e não deltas incrementais, e que toda requisição seja assinada por HMAC. Fonte

Teste seus conhecimentos: Checkout agêntico

Cinco perguntas rápidas sobre a mecânica do checkout. Escolha uma resposta para cada pergunta e depois confira.

Registro de alterações