ACP, UCP e AP2 comparados: os protocolos de comércio agêntico em outubro de 2026 e de qual precisa a sua loja

Há agora três protocolos abertos que descrevem como um agente de IA compra numa loja. O Agentic Commerce Protocol (ACP) vem da OpenAI e da Stripe. O Universal Commerce Protocol (UCP) vem da Google e da Shopify. O Agent Payments Protocol (AP2), que a Google criou e entregou à FIDO Alliance em abril, não é sequer um protocolo de checkout: define uma prova assinada de que um utilizador autorizou um pagamento e foi concebido para funcionar dentro do UCP. Os três estão sob a licença Apache 2.0.

A 22 de outubro de 2026, estão em estados muito diferentes. O ACP tem o rótulo beta, a sua versão mais recente é a 2026-04-17 e não recebe nenhum commit desde 17 de julho. O ChatGPT, o seu principal utilizador, abandonou em março o checkout próprio e usa agora o ACP sobretudo para receber dados de produtos. O UCP publicou em agosto uma versão incompatível com as anteriores, a 2026-08-25, enquanto os próprios serviços da Google continuam a usar a 2026-04-08 e o checkout da Google está em acesso antecipado, só nos EUA. O AP2 está na v0.2, e nenhum produto da Google documenta a sua utilização.

Este artigo destina-se aos CTO e aos programadores principais de lojas e de plataformas de comércio que estão a decidir o que implementar. Para saber o que cada plataforma de IA pede a uma loja enquanto negócio, comece pela nossa visão geral do comércio agêntico.

Lado a lado

ACP: o Agentic Commerce Protocol

Governação e versões

O repositório da especificação diz que o ACP é mantido pela OpenAI e pela Stripe e classifica-o como beta. O seu documento de governação faz das duas os Founding Maintainers: nomeiam os membros do comité diretivo (até sete) e mantêm um direito de veto para usar «como último recurso». A Meta juntou-se como terceira mantenedora principal e membro do comité a 24 de abril de 2026. A documentação da Stripe diz que o ACP foi «criado pela Stripe, pela OpenAI e pela Meta», mas o ficheiro NOTICE do repositório atribui-o apenas à OpenAI e à Stripe. Uma fundação neutra não passa de um caminho futuro declarado.

Há cinco versões datadas: 2025-09-29 (checkout e pagamento delegado), 2025-12-12 (alterações incompatíveis aprendidas com os adaptadores da URBN e da Etsy), 2026-01-16 (um fornecedor de 3DS escolhido pelo comerciante), 2026-01-30 (negociação de capacidades, extensões e uma estrutura de gestores de pagamentos incompatível com a anterior) e 2026-04-17 (carrinho, feed, encomendas, autenticação delegada, descoberta e MCP), que tornou obsoleta a 2026-01-30. Nos seis meses seguintes não saiu nenhuma versão. A pasta unreleased/ contém alterações mais pequenas datadas até 17 de julho, como um id de atualização do feed e um URL de produto opcional nos artigos do checkout.

O que um comerciante implementa na versão 2026-04-17

A API de checkout é alojada pelo comerciante e chamada pelo agente:

• POST /checkout_sessions cria uma sessão, POST /checkout_sessions/{checkout_session_id} atualiza-a (um POST, não um PUT), um GET nesse caminho obtém-na, e .../complete e .../cancel terminam-na.
• Os pedidos levam uma chave de API bearer e um header API-Version obrigatório. Desde a 2026-04-17, um Idempotency-Key é obrigatório em todos os POST, com erros definidos: 400 idempotency_key_required, 409 idempotency_in_flight e 422 idempotency_conflict.
• O pedido de criação leva um objeto capabilities. O agente declara o que suporta e o vendedor devolve a interseção, pelo que uma incompatibilidade se revela antes do pagamento.
• O comerciante envia por POST os eventos das encomendas para um recetor alojado pela OpenAI em /agentic_checkout/webhooks/order_events, assinados com HMAC-SHA256 num header Merchant-Signature. Os estados vão de created a delivered ou canceled, e adjustments[] transporta reembolsos, devoluções, disputas e chargebacks (estornos).

A versão 2026-04-17 acrescentou também um /.well-known/acp.json estático e público, cujo campo transports indica se a loja fala rest, mcp ou ambos. Acrescentou um binding para MCP sobre Streamable HTTP com cinco ferramentas (create_checkout_session, get_checkout_session, update_checkout_session, complete_checkout_session, cancel_checkout_session), autenticado na configuração do servidor e não por pedido. E acrescentou uma Feed API alojada pelo agente, para a qual o comerciante envia os dados (POST /feeds, PATCH /feeds/{id}/products), um carrinho de um único vendedor sem dados de pagamento (POST /carts, PUT /carts/{id}) e a autenticação 3DS2 delegada (POST /delegate_authentication). Não há subscrições: o RFC das extensões lista subscription como «Suporte para faturação recorrente (futuro)».

Como funciona o pagamento no ACP

A resposta original do ACP é o pagamento delegado. O PSP ou o cofre de cartões implementa POST /agentic_commerce/delegate_payment, que transforma um cartão (o único tipo de credencial) num token que o PSP do comerciante só pode usar dentro de um limite autorizado: reason (apenas one_time), max_amount, currency, checkout_session_id, merchant_id e expires_at. Nas palavras do RFC: «Os pagamentos, a liquidação e a conformidade continuam na infraestrutura do comerciante.» A Worldpay documenta a sua própria versão da chamada, e o PayPal suporta o ACP através de tokens delegados no Braintree.

Desde a 2026-01-30, os métodos aceites são declarados como gestores de pagamentos em capabilities.payment.handlers. O exemplo de dados de pagamento do registo de alterações:

{ "handler_id": "card_tokenized", "instrument": { "type": "card", "credential": { "type": "spt", "token": "spt_123" } } }

O spt é o Shared Payment Token da Stripe, disponível «nos EUA, no Canadá e em determinados países europeus». Um vendedor que usa a Stripe cobra-o com payment_method_data[shared_payment_granted_token] numa versão de pré-visualização (preview) da API; um vendedor com outro processador pode obter a partir dele, uma única vez, as credenciais de rede. O nosso artigo sobre pagamentos agênticos explica quem suporta o risco.

O que mudou com a decisão da OpenAI em março

A 24 de março de 2026, a OpenAI escreveu que «a versão inicial do Instant Checkout não oferecia o nível de flexibilidade que aspiramos a proporcionar», deixou os comerciantes usar os seus próprios checkouts e disse que estava a «alargar o ACP para ser a camada de ligação entre comerciantes e utilizadores ao longo de toda a descoberta». Target, Sephora, Nordstrom, Lowe's, Best Buy, The Home Depot e Wayfair tinham integrado o ACP para a descoberta, e os catálogos do Shopify chegam através do Shopify Catalog. O que isto significa para um programador:

• O feed é a parte ativa. A página para comerciantes da OpenAI diz que as compras «são concluídas em sites ou aplicações dos próprios comerciantes» e que a funcionalidade de compras está ativa para os utilizadores dos EUA. A adesão ao feed destina-se a parceiros aprovados a partir de uma lista de espera: um ficheiro completo diário por SFTP com nove campos obrigatórios, atualizações por API ao longo do dia e promoções apenas por API. O carregamento normal «destina-se atualmente aos EUA».
• O checkout é uma porta à parte. A especificação do feed diz que o checkout «requer uma integração ativada separadamente». Para as apps do ChatGPT, o caminho com disponibilidade geral é o checkout externo no domínio do próprio programador. O painel de pagamento dentro da conversa é um beta privado, «limitado a determinados marketplaces», que entrega um token de pagamento ao servidor MCP da app numa chamada à ferramenta complete_checkout.
• As páginas da OpenAI estão atrasadas em relação à especificação. A sua referência do checkout ainda mostra API-Version 2025-09-12 e um enum provider com stripe, adyen e braintree. Desenvolva com base no repositório e confirme com a OpenAI que versão aceita.

As páginas de PSP que ainda apresentam o Instant Checkout como ativo estão desatualizadas.

UCP: o Universal Commerce Protocol

Governação e versões

A Google lançou o UCP a 11 de janeiro de 2026, desenvolvido em conjunto com a Shopify, a Etsy, a Wayfair, a Target e a Walmart. As regras de governação dão à Google e à Shopify um voto permanente cada uma no Governing Council, ao qual a Stripe aderiu a 28 de abril de 2026, e estabelecem que «a Google detém o voto por procuração de todos os lugares vagos até dezembro de 2028». A 24 de abril, o Shopping Tech Council passou a ter 16 lugares, com a entrada da Amazon, da Meta, da Microsoft, da Salesforce e da Stripe, pelo que a Meta e a Stripe têm agora lugar tanto no comité do ACP como no conselho do UCP.

O repositório tem quatro versões. A 2026-04-08 acrescentou as capacidades de carrinho e de catálogo, a assinatura de pedidos e de respostas e o Get Order. A 2026-08-25 é incompatível com as anteriores: signing_keys[] deu lugar a um JWK Set em keys[], as extensões de pagamento passaram de dev.ucp.shopping.* para dev.ucp.common.payment.*, os schemas partilhados mudaram de sítio e alteraram os seus URL $id, e os PAN e os tokens de rede passaram a ser tipos de credencial separados. Acrescentou também 3DS2 independente do fornecedor, pagamentos divididos, condições de pagamento e interoperabilidade com o Web Bot Auth.

Eis a armadilha. O guia de perfis da Google abrange apenas a 2026-04-08 e a 2026-01-23, o próprio perfil de agente da Google em ucp.goog declara "version": "2026-04-08", e o Salesforce B2C Commerce 26.9 serve as mesmas duas versões. O Checkout MCP da Shopify, por sua vez, remete para a 2026-08-25. Se desenvolver com base na versão mais recente, desenvolve uma versão que a Google não documenta. A resposta da especificação é um objeto supported_versions que associa cada versão anterior ao seu próprio URI de perfil.

Descoberta, transportes e autenticação

Cada empresa publica um perfil em /.well-known/ucp com ucp.version, ucp.services e ucp.payment_handlers, e a Google exige que seja público e sem autenticação. A plataforma do agente também publica um, e cada pedido leva o URI desse perfil num header UCP-Agent, por HTTPS com TLS 1.3, no mínimo. A autenticação fica à escolha da empresa: nenhuma, X-API-Key, OAuth 2.0, TLS mútuo ou HTTP Message Signatures segundo o RFC 9421. A Google envia um token bearer, e as suas perguntas frequentes oferecem também mTLS. Um Idempotency-Key é apenas um «SHOULD» (recomendado); um servidor que o aceite guarda-o durante pelo menos 24 horas e responde 409 quando é reutilizado com um corpo diferente.

O REST é o transporte principal, a par do MCP, de uma extensão A2A e de um modo incorporado (embedded) acessível através de um continue_url. As encomendas são um GET /orders/{id} mais um webhook da empresa para a plataforma, assinado segundo o RFC 9421. Os caminhos do carrinho são os mesmos do ACP. As operações de checkout parecem-se, mas não são intercambiáveis:

Um único núcleo de checkout pode servir os dois. Uma única tabela de rotas, não.

Como funciona o pagamento no UCP

O UCP não movimenta dinheiro. Um gestor de pagamentos é uma especificação escrita por um fornecedor de credenciais, como com.google.pay para o Google Pay ou dev.shopify.shop_pay para o Shop Pay. A empresa lista os gestores que aceita, a plataforma executa um deles e, no complete, a empresa recebe um token opaco para cobrar através do seu próprio PSP.

Nos serviços da Google, o único gestor é o Google Pay, PAN_ONLY é o único método de autenticação usado e o seu PSP «tem de conseguir processar os nossos tokens». A Stripe publica o com.stripe.payments para cartões e Apple Pay: «O agente envia um shared payment token (SPT) no pedido Complete Checkout, e o vendedor cobra-o.» O Google Pay continua no seu próprio gestor. O PayPal aceita o gestor do Google Pay através do Braintree ou da sua API Orders v2.

O que a Google exige antes de chamar a sua API

O guia do checkout nativo da Google pede a API REST de checkout e reserva para si o passo do pagamento: o comprador introduz os dados sensíveis «apenas na interface da Google». Os níveis de serviço são de pelo menos 95 % de disponibilidade em cada endpoint, com latências p50 e p95 de 1 e 4 segundos na criação, 1 e 5 na atualização e 6 e 10 na conclusão. Depois de uma encomenda, envia atualizações de estado para um webhook da Google, com um id de parceiro e uma chave emitidos na adesão. No Merchant Center, cada produto precisa de native_commerce(checkout_eligibility) com o valor true (o atributo «assume FALSE por omissão»), uma política de devoluções e um contacto de apoio são obrigatórios, e ficam excluídos as subscrições, os pagamentos em prestações, os produtos personalizados, os artigos usados e recondicionados, as pré-encomendas e os produtos com restrição de idade.

A opção mais leve, desde a 2026-04-08, é a transferência do carrinho: implementa apenas a criação do carrinho, a Google entrega o carrinho ao seu site e não é preciso nenhum gestor de pagamentos nem nenhum webhook de encomendas.

O acesso é o verdadeiro limite. O checkout está «disponível para comerciantes selecionados» através de um formulário de interesse do programa de acesso antecipado, no qual se compromete a começar no prazo de 30 dias e aceita que o acesso «pode ser retirado» se não fizer progressos. Os termos do UCP Checkout aplicam-se «apenas aos Estados Unidos». A chegada do hub do Merchant Center à Austrália e ao Canadá está prevista para «o início do próximo ano»; a Google não indica nenhuma data de checkout para qualquer outro país.

O UCP fora da Google

O Microsoft Merchant Center aceita feeds compatíveis com UCP nos EUA desde 21 de abril de 2026. O Copilot Checkout precisa de um feed compatível com UCP, aceita comerciantes de língua inglesa que vendem a compradores dos EUA em dólares, com um PSP cada um, e a definição correspondente na loja aparece como «só em piloto, para clientes selecionados». A Shopify expõe o UCP através de MCP em https://{shop}/api/ucp/mcp e retirou as suas ferramentas de catálogo e de carrinho mais antigas. Uma capacidade de reserva de alojamento foi integrada como proposta (draft) a 24 de setembro de 2026 e não consta de nenhuma versão.

AP2: o Agent Payments Protocol

O AP2 não é uma terceira forma de fazer checkout. A sua especificação diz que «funciona como uma funcionalidade de segurança dentro de um protocolo de comércio» e foi «concebido explicitamente para ser compatível com o Universal Commerce Protocol (UCP)». A versão 0.1.0 saiu a 16 de setembro de 2025 e a v0.2 a 28 de abril de 2026, o dia em que a Google doou o AP2 à FIDO Alliance. O anúncio da FIDO refere dois grupos de trabalho, Agentic Authentication e Payments, presididos por membros da Mastercard e da Visa, e diz que as contribuições «serão analisadas e desenvolvidas». A FIDO não publicou nenhuma especificação do AP2. O repositório no GitHub aceita agora apenas exemplos e alterações aos SDK, e o último commit data de 29 de abril.

A versão 0.2 define um Checkout Mandate (o que é comprado) e um Payment Mandate (o pagamento, com restrições como payment.amount_range, payment.budget e payment.allowed_payees). Cada um é um SD-JWT, numa forma fechada e numa forma aberta (mandate.payment.1 e mandate.payment.open.1, por exemplo). No modo Human Present, o utilizador aprova os mandatos fechados. No modo Human Not Present, o utilizador aprova mandatos abertos que fixam restrições e que levam a chave pública do agente numa claim cnf, e o agente monta os mandatos fechados dentro desses limites. Os tutoriais sobre Intent Mandates e Cart Mandates descrevem a v0.1; esses termos desapareceram da v0.2.

Dentro do UCP, o AP2 é a extensão dev.ucp.common.payment.ap2_mandate (dev.ucp.shopping.ap2_mandate antes da 2026-08-25). Depois de negociada, a empresa assina as suas respostas de checkout, a plataforma apresenta um checkout_mandate e um payment_mandate no complete, e a sessão fica «Security Locked» (bloqueada por segurança): nenhuma das partes pode voltar a um checkout comum.

Ainda ninguém o pede. As perguntas frequentes da Google descrevem o AP2 como «particularmente útil para cenários futuros que envolvam transações de agentes de IA autónomos». O próprio perfil de agente da Google indica o Google Pay como único gestor de pagamentos e não declara nenhuma capacidade AP2, e o seu perfil 2026-08-25 também não tem nenhuma entrada AP2. Nenhum produto da Google documenta a utilização do AP2, pelo que não há nada para um comerciante desenvolver até que uma plataforma o negocie.

Os protocolos vizinhos

MCP

O ACP e o UCP podem ambos funcionar sobre MCP, cuja especificação atual, 2026-07-28, elimina as sessões e o header Mcp-Session-Id, abandona o handshake initialize, exige server/discover e obriga o cliente a reemitir um pedido com um novo ID quando o respetivo stream se interrompe. O binding do ACP ainda remete para o transporte 2025-11-25. Um id de sessão de checkout é exatamente o identificador gerado pelo servidor que a nova especificação espera, e um complete perdido a meio do stream regressa como um pedido novo: trate as chaves de idempotência como obrigatórias nos dois protocolos.

WebMCP

O WebMCP é uma proposta de norma web para expor as funções da própria página aos agentes que funcionam no navegador. A Shopify oferece o checkout UCP tanto como Checkout MCP como Checkout WebMCP, com o mesmo objeto de checkout, e recomenda o Checkout MCP. O nosso guia do WebMCP explica em que ponto está.

x402 e MPP

O x402 e o Machine Payments Protocol, concebido pela Tempo e pela Stripe, cobram a um agente por cada pedido HTTP o acesso a uma API, a dados ou a conteúdos. Não são protocolos de checkout para lojas. Veja o nosso artigo sobre o x402.

Visa Trusted Agent Protocol e Mastercard Agent Pay

Funcionam ao lado do ACP e do UCP, em vez de os substituírem. O Trusted Agent Protocol da Visa dá a um agente «um método criptográfico normalizado» para provar a sua identidade e a sua autorização aos comerciantes, e o Mastercard Agent Pay é um programa de tokenização para o comércio agêntico. O guia para comerciantes da Mastercard coloca o UCP e o ACP no seu nível de preparação mais elevado, observa que «os primeiros a adotar estão a integrar neste momento» e aconselha os comerciantes a começar pelos seus dois níveis mais simples. O nosso artigo sobre pagamentos agênticos trata dos dois programas.

Personal Agent Protocol

A Sierra diz que anunciou o Personal Agent Protocol («Poppy») com a Meta a 6 de outubro de 2026, e publicou uma proposta a 9 de outubro. Uma empresa publica um único ficheiro em /.well-known/poppy.json; o protocolo usa OAuth, JWT, HTTPS, OpenAPI e MCP para permitir que um agente pessoal se identifique e obtenha a permissão do cliente para qualquer tipo de tarefa, e a Sierra considera-o complementar ao UCP. O site do protocolo mostra a versão 0.2 e diz: «É uma proposta.» Não encontrámos nenhuma publicação sobre ele na sala de imprensa da própria Meta.

De qual precisa?

No Shopify

Não há nada a desenvolver. As agentic storefronts da Shopify (montras para agentes de IA) estão «ativas por omissão nas lojas elegíveis». O ChatGPT recebe o seu catálogo através do Shopify Catalog e envia os compradores para a sua loja. O checkout direto da Google está ativo por omissão nas lojas sediadas nos EUA que vendem para os EUA, e o Copilot inscreveu automaticamente os comerciantes do Shopify. O que lhe cabe decidir são os dados dos produtos e se mantém ativo o checkout direto, sabendo que os pixels personalizados não disparam no checkout da Google.

Na Salesforce, na commercetools ou noutra plataforma

O Salesforce B2C Commerce 26.9 serve o UCP 2026-01-23 e 2026-04-08: /.well-known/ucp com um mapa supported_versions e os endpoints de sessão de checkout protegidos por um token SLAS. A Salesforce indica que o checkout UCP na Google tem disponibilidade geral em outubro de 2026. Uma sessão é uma vista headless de um cesto, e o guia de auditoria da Salesforce avisa que os controladores SFRA e SiteGenesis e «outros recursos SCAPI que usa hoje não são executados neste fluxo», pelo que a lógica associada a eles tem de ser copiada para os hooks de sessão de checkout do UCP ou ligada a eles através de uma ponte. O feed tem de ter como destino en-US, e a Salesforce «não dispensa a lista de espera da Google». Para o ChatGPT, a Salesforce é um dos caminhos de entrega que a OpenAI indica para os feeds ACP.

Na commercetools ou noutra plataforma, pergunte ao fornecedor que versões e capacidades do UCP serve, quais dos seus hooks são executados num checkout feito por um agente e se envia feeds para a OpenAI.

Com software próprio

1. Primeiro os feeds. O Google Merchant Center e, quando a OpenAI aceitar a sua candidatura, o feed de produtos da OpenAI. A utilização comercial do ACP no ChatGPT hoje é exatamente esta.
2. UCP para a Google, se vende nos EUA e a Google aceitar a sua candidatura. Desenvolva com base na 2026-04-08: o perfil com com.google.pay, as operações de checkout dentro dos objetivos de latência da Google, um PSP que processe tokens do Google Pay, o webhook de encomendas e o atributo do feed. Ou comece apenas pela transferência do carrinho.
3. Checkout ACP só com um motivo, como uma app do ChatGPT admitida no beta do painel de pagamento. Desenvolva com base na 2026-04-17 do repositório.
4. AP2: para já, nada.
5. Um único núcleo de checkout. Os dois protocolos querem uma sessão que possa ser criada, atualizada, concluída e cancelada através de uma API e cujos pedidos possam ser repetidos em segurança. Desenvolva-a uma vez sobre a sua lógica de encomendas, impostos e pagamentos, com adaptadores finos de ACP e UCP por cima e MCP onde os agentes precisarem.

Nenhum dos protocolos oferece hoje a um negócio de subscrições um checkout nativo para agentes.

Se vende apenas fora dos Estados Unidos

Nenhum dos três lhe dá hoje um checkout para agentes. As compras no ChatGPT e o carregamento normal de feeds da OpenAI são só para os EUA; os termos do UCP Checkout da Google aplicam-se apenas aos EUA; o Copilot Checkout serve compradores dos EUA em dólares. O próximo passo anunciado pela Google é o hub do Merchant Center na Austrália e no Canadá, previsto para «o início do próximo ano», sem data para o Reino Unido nem para a UE.

Mantenha completo o seu feed do Merchant Center e, se estiver de qualquer forma a reconstruir o checkout, desenvolva o núcleo comandado por API descrito acima, para que um adaptador seja um trabalho pequeno quando o seu mercado abrir. Vende para os EUA a partir do estrangeiro? Verifique onde cada programa exige que o comerciante esteja sediado; o checkout direto da Google através da Shopify, por exemplo, exige uma loja dos EUA.

Onde obter ajuda

Desenvolvemos a camada de protocolos para lojas que não usam o Shopify: um perfil /.well-known/ucp e endpoints de sessão de checkout sobre a sua lógica atual de encomendas, impostos e pagamentos, webhooks de encomendas para a Google, feeds de produtos para o Google Merchant Center e para a OpenAI, e servidores MCP que expõem o mesmo checkout aos agentes. O nosso serviço de desenvolvimento de agentes de IA e integração de servidores MCP é onde esse trabalho começa.

Escreva para office@c9group.dev com a sua plataforma, o seu fornecedor de pagamentos e os países onde vende, e dizemos-lhe que protocolo se aplica e o que implicaria implementá-lo. As condições dos programas da Google e da OpenAI são contratos: somos engenheiros, não advogados, por isso peça a um assessor jurídico que as leia antes de assinar.