Protocolos de comércio agêntico: ACP, AP2 e UCP, e o que o seu catálogo precisa

TL;DR

• Os três protocolos de comércio agêntico abertos que importam em outubro de 2026 são o ACP (OpenAI e Stripe), o UCP (Google e parceiros do varejo) e o AP2 (criado pelo Google, agora com a FIDO Alliance). Eles cobrem camadas diferentes da mesma compra.
• O ACP e o UCP padronizam o catálogo de produtos e o checkout entre o agente e o lojista. O AP2 padroniza a prova assinada de que um usuário autorizou uma compra e um pagamento específicos. A Visa e a Mastercard mantêm programas próprios para verificar agentes e credenciais de pagamento.
• Os três aceitam um GTIN nos dados do produto, mas nenhum o exige, e nenhum menciona o GS1 Digital Link. O checkout funciona com os IDs de item do próprio lojista, e é exatamente aí que a identidade do produto pode se perder.

Os protocolos de comércio agêntico são as especificações abertas que permitem a um agente de IA encontrar um produto, colocá-lo no carrinho e pagar por ele em nome de alguém sem fazer scraping de um site. Em outubro de 2026, três deles concentram a maior parte do peso do setor: o Agentic Commerce Protocol (ACP), o Universal Commerce Protocol (UCP) e o Agent Payments Protocol (AP2). Eles funcionam em camadas: o ACP e o UCP descrevem como um agente conversa com um lojista sobre produtos, carrinhos e pedidos, e o AP2 descreve como todos podem provar depois o que o usuário de fato autorizou.

Para uma marca ou um importador, a pergunta prática é mais estreita. Seja qual for o protocolo que um agente usa, ele pergunta ao seu catálogo as mesmas coisas: que item é este, quanto custa, posso comprá-lo e qual ID devo passar ao checkout. Este guia mostra quem controla cada protocolo, o que ele padroniza, o que um lojista precisa fornecer e onde entra a identidade do produto, em outubro de 2026.

Quais protocolos de comércio agêntico existem e quando foram lançados?

O que é o Agentic Commerce Protocol (ACP)?

O ACP é uma especificação aberta para o comércio entre compradores, seus agentes de IA e empresas. A OpenAI e a Stripe o lançaram em 29 de setembro de 2025, junto com o Instant Checkout no ChatGPT, sob a licença Apache 2.0. O repositório oficial o descreve como em beta e mantido pela OpenAI e pela Stripe como mantenedoras fundadoras; desde abril de 2026, o arquivo de mantenedores também lista a Meta como mantenedora principal. A versão estável mais recente é a 2026-04-17.

O ACP padroniza quatro coisas:

• Checkout. O lojista expõe uma API de sessão de checkout: o agente cria uma sessão a partir de itens, atualiza-a com o endereço e a opção de entrega e a conclui ou cancela. A especificação deixa claro que o lojista continua sendo o sistema de registro de pedidos, pagamentos, impostos e conformidade, e que o pagamento passa pelo próprio provedor de serviços de pagamento do lojista.
• Pagamento delegado. Um provedor de pagamento emite um token de uso único cujo uso é limitado por uma "allowance": um valor máximo, uma moeda, uma sessão de checkout específica, um lojista específico e um prazo de expiração. O Shared Payment Token da Stripe foi a primeira implementação compatível. Uma API separada de autenticação delegada cobre as verificações 3-D Secure 2.
• Feed de produtos. A versão 2026-04-17 adicionou uma Feed API. É um modelo push: o lojista envia o catálogo para um feed hospedado pela plataforma do agente, seja como arquivo completo, seja como atualizações parciais.
• Carrinho e pedidos, além de um binding para o Model Context Protocol (MCP).

O que aconteceu com o Instant Checkout?

Em 24 de março de 2026, a OpenAI anunciou que a versão inicial do Instant Checkout não havia oferecido a flexibilidade que ela queria, e que os lojistas poderiam usar o próprio checkout enquanto a OpenAI se concentrava na descoberta de produtos. No mesmo anúncio, disse que estava estendendo o ACP para levar feeds de produtos e de promoções ao ChatGPT. Ou seja, o protocolo continua, a especificação de checkout ainda existe, e hoje, no ChatGPT, o feed importa mais do que o checkout. A integração de feeds de produtos ao ChatGPT está limitada a parceiros aprovados, que se candidatam junto à OpenAI.

De quais dados de produto um feed ACP precisa?

Na Feed API aberta do ACP, um produto precisa de um id estável e de pelo menos uma variante, e cada variante precisa de um id estável e de um title. Todo o resto é opcional no schema: preço e preço de tabela em unidades menores da moeda, status de disponibilidade, mídia, categorias, opções de variante como cor e tamanho, vendedor, preço unitário e uma lista de barcodes, em que cada entrada tem um tipo, como GTIN, UPC ou EAN, e um valor.

A especificação de feed da própria OpenAI para o ChatGPT é mais rigorosa. Ela exige ID do item, título, descrição, URL do produto, marca, nome do vendedor, URL da imagem principal, disponibilidade e preço. O campo gtin é opcional, deve ter 8, 12, 13 ou 14 dígitos com dígito verificador válido e deve ser omitido se o produto não tiver um. O campo mpn deve ser enviado com a marca, e a especificação orienta os lojistas a não inventar um número de peça para substituir um GTIN ausente.

A proposta de feed do ACP também resolve um ponto importante: os dados do feed são informativos, e a resposta do checkout é a que vale para preço, estoque, impostos e entrega. Se o ID da variante no feed não for o ID que o checkout do lojista aceita, o lojista precisa fornecer um mapeamento.

O que é o Universal Commerce Protocol (UCP)?

O UCP é um padrão aberto que cobre toda a jornada de compra: descoberta, carrinho, checkout, vinculação de contas e pedidos. O Google o lançou em 11 de janeiro de 2026, desenvolvido em colaboração com Shopify, Etsy, Wayfair, Target e Walmart e publicado em ucp.dev sob a licença Apache 2.0. A governança cresceu desde então: em abril de 2026, a Stripe se juntou ao Google e à Shopify como membro permanente do Governing Council, e comitês técnicos de pagamentos, hospedagem e alimentação foram formados ao longo do verão. A versão atual é a v2026-08-25.

Uma empresa que oferece suporte ao UCP publica um perfil em /.well-known/ucp listando as capacidades que oferece, para que um agente possa descobri-las sem uma integração personalizada. As capacidades incluem:

• Busca e consulta de catálogo, adicionadas na v2026-04-08.
• Carrinho e checkout, com impostos e preços calculados pela empresa.
• Vinculação de identidade por OAuth 2.0, para que um agente possa agir dentro da conta de um cliente sem ter a senha dele.
• Pedidos, com atualizações de status, envio e devolução por webhook.
• Payment handlers, que separam o instrumento de pagamento do provedor que o processa e que usam o AP2 para os mandatos de pagamento.

O UCP pode ser oferecido via REST, MCP ou Agent2Agent (A2A). A primeira implementação do Google permite comprar de lojistas elegíveis no AI Mode da Pesquisa e no app Gemini. Ela funciona a partir de uma conta do Google Merchant Center e dos feeds de shopping existentes, o acesso é feito por lista de espera, e o lojista continua sendo o merchant of record.

De quais dados de produto o UCP precisa?

Uma variante UCP precisa ter um id, um title, uma description e um price. O id da variante é o usado como ID do item no checkout. Os campos opcionais incluem o sku do lojista, uma URL canônica, disponibilidade, mídia, preço unitário e barcodes, cujos tipos conhecidos são UPC, EAN, ISBN, GTIN e JAN.

As regras de consulta são reveladoras. Um catálogo UCP precisa permitir a consulta por ID do produto e por ID da variante. Ele pode permitir identificadores secundários, como o SKU. Uma consulta por GTIN não é algo com que um agente possa contar.

Na implementação do próprio Google, continuam valendo as regras de feed do Merchant Center. O Google recomenda um GTIN para todos os produtos que tenham um atribuído pelo fabricante e avisa que omitir um GTIN atribuído pode levar à reprovação do produto.

O que é o Agent Payments Protocol (AP2)?

O AP2 resolve um problema diferente. Quando um agente paga, o lojista, o emissor do cartão e a rede de pagamento não viram o usuário clicar em "comprar". O AP2 dá a eles uma prova assinada do que o usuário autorizou, para que possam aceitar a transação e resolver disputas. O Google o anunciou em 16 de setembro de 2025. Em 28 de abril de 2026, o Google lançou a versão 0.2 e anunciou que estava doando o AP2 à FIDO Alliance, onde a padronização continua nos grupos de trabalho da FIDO. O site da especificação do AP2 e o repositório são publicados sob a licença Apache 2.0.

As duas versões descrevem a mesma ideia de formas diferentes:

• Versão 0.1 (setembro de 2025): usava três mandatos: um Intent Mandate, que registrava o que o usuário pediu, um Cart Mandate, que registrava os itens e o preço exatos que o usuário aprovou, e um Payment Mandate.
• Versão 0.2 (abril de 2026): usa um Checkout Mandate, que garante o que está sendo comprado, e um Payment Mandate vinculado, que garante o pagamento. Cada um existe em uma forma aberta, que guarda as restrições do usuário antes de o carrinho estar fechado, e em uma forma fechada, vinculada a um único checkout finalizado. Os mandatos são credenciais assinadas com divulgação seletiva, de modo que cada parte vê apenas o que precisa.

O AP2 define cinco papéis (agente de compras, provedor de credenciais, lojista, processador de pagamentos do lojista e uma superfície confiável em que o usuário dá o consentimento) e dois modos. Nas compras "human present", o usuário aprova o carrinho final. Nas compras "human not present", a principal novidade da v0.2, o usuário assina restrições com antecedência e o agente conclui uma compra que as cumpra.

O AP2 deixa deliberadamente fora do escopo as APIs de catálogo e de checkout. Ele foi projetado para funcionar com o UCP: quando usado com o UCP, o checkout assinado pelo lojista dentro de um Checkout Mandate precisa ser o objeto de checkout do UCP. O seu tipo de item contém apenas um id (descrito como frequentemente o SKU), um title, um price e uma URL de imagem opcional.

Onde entram a Visa e a Mastercard?

As duas bandeiras de cartão têm programas que ficam ao lado desses protocolos, em vez de substituí-los. Eles tratam da identidade do agente e das credenciais de pagamento, não dos dados de produto.

• O Visa Trusted Agent Protocol (14 de outubro de 2025, desenvolvido com a Cloudflare) permite que um agente aprovado assine as suas requisições a um lojista, para que o lojista consiga distinguir um agente de compras legítimo de um bot malicioso. Ele pode levar a intenção do agente, o reconhecimento do consumidor e informações de pagamento opcionais, e está publicado no Visa Developer Center e no GitHub.
• O Mastercard Agent Pay (29 de abril de 2025) introduziu os Agentic Tokens e exige que os agentes sejam registrados e verificados antes de fazer transações. O Verifiable Intent, apresentado pela Mastercard e pelo Google em 5 de março de 2026, é uma especificação aberta para um registro à prova de adulteração do que um usuário autorizou, alinhada com o AP2 e o UCP. O anúncio do Google de abril de 2026 diz que o Verifiable Intent também está sendo doado à FIDO Alliance.

Normalmente, um lojista lida com esses programas por meio do seu provedor de pagamento, e eles não mudam o que o seu catálogo precisa conter.

Como o ACP, o UCP e o AP2 se comparam?

Onde entra a identidade do produto, e sobre o que os protocolos se calam?

Lidas lado a lado, as três especificações identificam um produto no checkout com um ID escolhido pelo lojista. O ACP usa o ID da variante do feed, o UCP usa o seu ID de variante, e os mandatos do AP2 listam IDs de item aceitáveis fornecidos pelo lojista. Isso é razoável para concluir um pedido em uma loja. É também o ponto fraco que Paula Rivero descreveu no workshop W3C/GS1 em Zurique: um agente pode executar o checkout sem falhas e ainda assim comprar o produto errado, porque o ID interno de um lojista não diz nada sobre qual produto físico ele é fora daquela loja.

O GTIN é o campo que atravessa essa fronteira. O ACP e o UCP têm um lugar para ele, e a especificação de feed da OpenAI valida o seu dígito verificador. Nenhum dos três protocolos o torna obrigatório, nenhum diz como um agente deve comparar o mesmo GTIN entre lojistas, e nenhum menciona o GS1 Digital Link, o passaporte digital de produto ou qualquer outra forma de resolver um produto para informações da própria marca.

A nossa leitura de como eles se encaixam, que não está declarada em nenhuma das especificações:

• O GTIN no feed é a ponte entre lojistas. Se duas lojas vendem o mesmo xampu com o mesmo GTIN, um agente pode reconhecê-lo como o mesmo produto e comparar ofertas em vez de adivinhar pelos títulos. Se o GTIN estiver ausente, o agente volta a comparar nomes.
• Um mandato AP2 aberto é tão preciso quanto os seus IDs de item. Um usuário que autoriza "comprar de novo exatamente este produto" está, na v0.2, autorizando uma lista de IDs de item do lojista. Um GTIN por trás desses IDs é o que faz a instrução significar a mesma coisa em uma segunda loja.
• O GS1 Digital Link é onde fica a versão da verdade da marca. Uma URI GS1 Digital Link é construída a partir do mesmo GTIN, então um agente que já tem o GTIN pode montá-la e resolvê-la para informações que a marca controla: especificações, instruções, informações de segurança e, na UE, dados do passaporte. Nenhum dos protocolos exige que um agente faça isso. Mas nada neles o impede.

Onde um QR code não ajuda: ele não tem papel no checkout, no pagamento nem nos mandatos, e um feed em conformidade com os protocolos não precisa de um. O valor dele aqui é o identificador por trás dele.

O que marcas e importadores devem fazer agora?

Os protocolos vão continuar mudando; o trabalho no catálogo não depende de qual deles vencer.

1. Garanta que todo produto que tem um GTIN o informe nos seus próprios sistemas, no seu feed do Google Merchant Center e em qualquer feed ACP, e que o dígito verificador seja válido. Não invente identificadores para produtos que não têm um.
2. Mantenha um ID estável por variante e verifique se o ID no seu feed é o que o seu checkout aceita. Tanto o ACP quanto o UCP dependem disso.
3. Mapeie explicitamente o GTIN para o ID da variante. Um GTIN deve apontar para uma única variante vendável no seu catálogo, incluindo tamanho da embalagem e formulação.
4. Envie os campos que os agentes usam para escolher: título, descrição, marca, preço, disponibilidade, imagens e uma URL canônica do produto. No ACP e no UCP, é isso que um agente vê antes do checkout.
5. Mantenha preço e estoque atualizados. As duas especificações tratam o feed como informativo e o checkout como o que vale, então um feed desatualizado leva os agentes a checkouts que falham.
6. Pergunte ao seu provedor de pagamento quais fluxos agênticos ele suporta: o Shared Payment Token da Stripe para o ACP, os payment handlers do UCP, os mandatos AP2, os programas de agentes da Visa e da Mastercard. Raramente você implementa isso sozinho.
7. Dê ao GTIN um endereço resolvível. Um resolver GS1 Digital Link no seu próprio domínio permite que qualquer agente, em qualquer protocolo, confira o produto com os seus próprios dados. É também o caminho em que o passaporte digital de produto da UE vai se apoiar.

A Digital Link é parceira de soluções da GS1, e a nossa plataforma dá a cada produto um GS1 Digital Link construído sobre o seu GTIN, com páginas controladas pela marca e dados estruturados por trás que pessoas e máquinas conseguem ler. No comércio agêntico, essa é a camada de identidade que os protocolos deixam em aberto: um identificador por produto que resolve para os seus dados, seja qual for o agente ou protocolo que pergunta. Se você quiser verificar o quanto o seu catálogo está pronto para compras conduzidas por agentes, entre em contato e a nossa equipe vai revisar os seus dados de produto com você.

Perguntas frequentes

Qual é a diferença entre o ACP e o AP2?

O ACP é um protocolo de comércio: padroniza o feed de produtos, a sessão de checkout e um token de pagamento delegado entre um agente de IA e um lojista. O AP2 é um protocolo de confiança em pagamentos: padroniza mandatos assinados que provam o que um usuário autorizou, e deixa o catálogo e o checkout para outros protocolos. A especificação do AP2 cita o UCP como o protocolo de comércio com o qual foi projetado para funcionar.

O ACP é o mesmo que o Instant Checkout no ChatGPT?

Não. O Instant Checkout era o produto da OpenAI construído sobre o ACP. Em março de 2026, a OpenAI se afastou do Instant Checkout independente para que os lojistas pudessem usar o próprio checkout, e estendeu o ACP para levar feeds de produtos e de promoções para a descoberta no ChatGPT. A especificação do ACP em si continua aberta e em beta.

Os protocolos de comércio agêntico exigem um GTIN?

Não. O ACP e o UCP oferecem um campo opcional de código de barras que aceita um GTIN, e a especificação de feed do ChatGPT da OpenAI lista gtin como opcional. O Google Merchant Center recomenda um GTIN para todo produto que tenha um e pode reprovar produtos em que falte um GTIN atribuído.

Algum desses protocolos usa o GS1 Digital Link?

Não em outubro de 2026. Nenhuma das especificações do ACP, do UCP ou do AP2 menciona o GS1 Digital Link. Como uma URI GS1 Digital Link é construída a partir do GTIN, qualquer agente que receba um GTIN por meio desses protocolos pode resolvê-la, mas essa é a nossa leitura de como eles se combinam, não um requisito dos protocolos.

Quem controla o AP2 agora?

O Google criou o AP2 e anunciou a sua doação à FIDO Alliance em 28 de abril de 2026, junto com o lançamento da versão 0.2. A especificação e o SDK continuam públicos no GitHub, e a padronização prossegue nos grupos de trabalho da FIDO.

Lojistas da UE podem usar esses protocolos?

As especificações são abertas e podem ser implementadas em qualquer lugar. Os primeiros produtos para consumidores construídos sobre elas foram lançados nos Estados Unidos, e as plataformas decidem país por país onde os lojistas podem participar, então confira a elegibilidade atual de cada plataforma antes de contar com ela.