Comércio agêntico: x402, MPP, ACP, AP2 e UCP

Aula 1

O problema: um agente com cartão na mão

O comércio eletrônico foi desenhado para uma pessoa com um navegador: ela vê o produto, aceita os termos, digita o cartão e confirma. Quando um agente compra, quase tudo nesse desenho vira problema. Quem autorizou a compra? O agente pode guardar o cartão? Como a loja sabe que o pedido não foi manipulado? Como cobrar R$ 0,01 por uma chamada de API se a taxa do cartão é maior que isso?

Os protocolos não são excludentes. Um mesmo comércio pode anunciar o perfil UCP, aceitar checkout via ACP no ChatGPT, exigir mandatos AP2 para valores altos e cobrar a API de preços com x402. Por isso este módulo trata cada um pelo problema que resolve, não como concorrentes de uma escolha única.

Aula 2

x402 e MPP: pagamento no próprio HTTP

O HTTP tem desde 1997 um código de status reservado para "uso futuro": 402 Payment Required. Os protocolos desta aula finalmente dão uso a ele. A ideia é que pagar faça parte da própria requisição: o servidor responde 402 com as condições, o cliente paga e repete a requisição com a prova de pagamento.

x402

O x402 nasceu na Coinbase e hoje é mantido pela x402 Foundation, nos LF Projects, com licença Apache 2.0. Ele usa stablecoins (como USDC) em redes como Base e Solana, o que permite valores de frações de centavo com liquidação em segundos. Um facilitador verifica e liquida o pagamento para que o servidor não precise operar uma carteira.

# 1. Cliente pede o recurso
GET /api/cotacao HTTP/1.1

# 2. Servidor responde 402 com as condições (objeto em base64)
HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: eyJ4NDAyVmVyc2lvbiI6Miwi...

# 3. Cliente paga e repete com a prova
GET /api/cotacao HTTP/1.1
PAYMENT-SIGNATURE: eyJ4NDAyVmVyc2lvbiI6Miwi...

# 4. Servidor verifica, liquida e entrega
HTTP/1.1 200 OK
PAYMENT-RESPONSE: eyJzdWNjZXNzIjp0cnVlLC...

• Na versão 2, os cabeçalhos são PAYMENT-REQUIRED, PAYMENT-SIGNATURE e PAYMENT-RESPONSE. A versão 1 usava X-PAYMENT e X-PAYMENT-RESPONSE.
• As redes passaram a ser identificadas no padrão CAIP-2, como eip155:8453 (Base).
• O esquema exact cobra exatamente o preço anunciado; há outros esquemas, como cobrança até um teto e liquidação em lote.
• O facilitador expõe /verify e /settle. Bibliotecas prontas transformam isso num middleware de poucas linhas.

app.use(paymentMiddleware({
  'GET /api/cotacao': {
    accepts: [{ scheme: 'exact', price: '$0.001', network: 'eip155:8453', payTo: '0xSuaCarteira' }],
    description: 'Cotação de frete em tempo real'
  }
}));

MPP: Machine Payments Protocol

O MPP, desenhado pela Tempo e pela Stripe, segue a mesma ideia de cobrar requisições, chamadas de ferramenta e conteúdo com HTTP 402, mas se apoia num rascunho de esquema de autenticação HTTP para pagamentos (paymentauth). O servidor responde 402 com WWW-Authenticate: Payment ..., o cliente repete com Authorization: Payment ... e recebe um Payment-Receipt. A diferença prática é o leque de meios: além de stablecoins, o MPP foi pensado para trilhos tradicionais da Stripe, e desde 2026 também executa fluxos x402.

Fontes desta aula: x402.org · Documentação do x402 · Machine Payments Protocol · Rascunho HTTP Payment Authentication

Aula 3

ACP: checkout dentro do assistente

O Agentic Commerce Protocol (ACP), desenvolvido pela OpenAI e pela Stripe e publicado com licença Apache 2.0, define como um assistente conduz uma compra em uma loja sem que o usuário saia da conversa. A loja continua sendo a vendedora: ela recebe o pedido, processa o pagamento com o seu provedor e cuida da entrega. O ChatGPT foi a primeira plataforma e a Stripe o primeiro provedor de pagamento compatível.

A loja implementa uma API REST de sessões de checkout:

POST /checkout_sessions/cs_123/complete HTTP/1.1
Authorization: Bearer <chave-da-plataforma>
Content-Type: application/json
API-Version: 2026-01-30
Idempotency-Key: 6f1c...

{
  "payment_data": { "token": "spt_1234567890abcdef", "provider": "stripe" }
}

O ponto central de segurança é o pagamento delegado: o assistente nunca entrega o número do cartão à loja. Ele obtém do provedor um token de uso único, limitado ao valor e à loja (na Stripe, o Shared Payment Token), e a loja cobra com esse token. Cabeçalhos de idempotência e assinatura protegem contra pedidos duplicados ou adulterados.

Segundo o próprio site do protocolo, mecanismos padronizados de descoberta ainda estão em desenvolvimento. Hoje, a loja entra no ecossistema por cadastro com a plataforma, e o scanner registra o suporte como informativo.

Fontes desta aula: Agentic Commerce Protocol · ACP: referência de checkout

Aula 4

AP2: mandatos e prova de autorização

Quando um agente paga, alguém vai perguntar depois: o usuário realmente autorizou isso? O Agent Payments Protocol (AP2), anunciado pelo Google em setembro de 2025, responde com mandatos: credenciais digitais verificáveis, assinadas, que registram o que foi autorizado. Na versão atual, o AP2 foi doado à FIDO Alliance.

Versões anteriores falavam em Intent Mandate e Cart Mandate; a nomenclatura mudou, mas a lógica é a mesma. A cadeia de mandatos cria uma trilha de auditoria não repudiável, útil para disputas e chargebacks, e permite compras sem a pessoa presente dentro de limites prévios.

O AP2 é agnóstico de meio de pagamento (cartão, transferência, stablecoin) e foi pensado para funcionar junto com A2A e MCP. Para um site, implementar AP2 normalmente significa aceitar e validar mandatos via um provedor de pagamento compatível, não escrever criptografia própria.

Fontes desta aula: AP2: Agent Payments Protocol

Aula 5

UCP: o perfil de comércio em /.well-known/ucp

O Universal Commerce Protocol (UCP) é a tentativa mais ampla de um padrão comum de comércio para agentes. Foi desenvolvido pelo Google com varejistas e plataformas como Shopify, Etsy, Wayfair, Target e Walmart, com licença Apache 2.0. É o único dos cinco com um endereço de descoberta próprio: o perfil do negócio em /.well-known/ucp, registrado provisoriamente na IANA em 2026.

{
  "ucp": {
    "version": "2026-08-25",
    "services": {
      "dev.ucp.shopping": {
        "version": "2026-08-25",
        "transport": "rest",
        "endpoint": "https://exemplo.com.br/api/ucp"
      }
    },
    "capabilities": [
      { "name": "dev.ucp.shopping.checkout", "version": "2026-08-25" },
      { "name": "dev.ucp.shopping.fulfillment", "version": "2026-08-25" },
      { "name": "dev.ucp.shopping.discount", "version": "2026-08-25" }
    ],
    "payment_handlers": {}
  }
}

• O perfil declara versão, serviços com transporte e endpoint, capacidades e meios de pagamento. Não lista produtos.
• Capacidades usam nomes reversos de domínio, como dev.ucp.shopping.checkout, dev.ucp.shopping.fulfillment e dev.ucp.common.identity_linking.
• O checkout cria sessões em POST {endpoint}/checkout-sessions, num modelo próximo ao do ACP.
• O perfil deve ser servido por HTTPS, sem redirecionamentos e com Cache-Control público de pelo menos 60 segundos.
• O UCP pode transportar pagamentos com AP2 e se integrar a A2A e MCP.

Como escolher o primeiro protocolo

Fontes desta aula: Universal Commerce Protocol · UCP: visão geral da especificação · specification.website: UCP

Erros comuns

• Cobrar com 402 sem dizer como pagar. Um 402 sem as condições no formato do protocolo é só um erro.
• Pedir o cartão ao agente. Todos os protocolos sérios usam tokens delegados. Nunca aceite dados de cartão crus de um agente.
• Ignorar idempotência. Agentes repetem requisições quando há falha de rede. Sem Idempotency-Key, o cliente paga duas vezes.
• Preço e estoque que não batem com o site. O agente compara. Divergências geram desistência e reclamação.
• Implementar sem política de devolução clara. Agentes leem termos; termos vagos reduzem a confiança e a conversão.

Aplicação prática: avalie o comércio agêntico

1. Liste o que você vende e classifique: produto físico, serviço, assinatura ou acesso por uso.
2. Verifique o que sua plataforma de e-commerce e seu provedor de pagamento já suportam (UCP, ACP, x402, MPP).
3. Escolha um piloto pequeno: por exemplo, uma API de cotação com x402 ou o perfil /.well-known/ucp com checkout.
4. Defina métricas: pedidos iniciados por agentes, taxa de conclusão e ticket médio comparados ao canal humano.

Siglas e termos deste módulo

x402:

Protocolo de pagamento sobre o status HTTP 402.

MPP:

Machine Payments Protocol, protocolo de pagamentos para máquinas (Tempo e Stripe).

ACP:

Agentic Commerce Protocol, checkout em assistentes (OpenAI e Stripe).

AP2:

Agent Payments Protocol, mandatos de pagamento verificáveis (Google).

UCP:

Universal Commerce Protocol, perfil e capacidades de comércio para agentes.

Stablecoin:

Criptomoeda com valor atrelado a uma moeda, como o dólar (ex.: USDC).

CAIP-2:

Padrão para identificar redes de blockchain, como eip155:8453.

Idempotência:

Garantia de que repetir a mesma requisição não duplica o efeito.