Ir para o conteúdo principal
AprenderGlossárioprotocolo AP2
GLOSSÁRIO

O que é o protocolo AP2.

DEFINIÇÃO

AP2 é o Protocolo de Pagamentos de Agentes do Google, uma especificação aberta de como agentes de IA pagam comerciantes programaticamente. Ele padroniza três partes: como um usuário concede um mandato de pagamento, como um agente apresenta esse mandato a um processador de pagamentos e como o acerto acontece através de qualquer infraestrutura que o comerciante aceite. AP2 está na camada de mandato; as infraestruturas subjacentes podem ser fiat ou stablecoin.

POR QUE ISSO É IMPORTANTE

A aposta de comércio agente do Google.

AP2 é a aposta do Google na categoria de comércio de agentes. Enquanto o x402 da Coinbase adota uma abordagem HTTP por chamada, o AP2 adota uma abordagem baseada em mandato: pré-autorizando o agente para um envelope de pagamentos, permitindo que ele execute dentro desse envelope sem mais envolvimento do usuário. Os dois protocolos visam formas ligeiramente diferentes de atividade do agente. O x402 se encaixa na cobrança por chamada de API; o AP2 se encaixa em compras, assinaturas e aquisições impulsionadas por agentes.

For developers, AP2 matters because it is the first agent-payment protocol from a hyperscaler with the distribution to mainstream-adopt it. If Gemini agents (consumer and enterprise) and Google Pay merchants both speak AP2 natively, then "agent paying via Google Pay" becomes a default capability rather than a custom integration. The stack rapidly expands beyond the developer-tooling ecosystem.

COMO FUNCIONA

Mandato, apresentação, liquidação.

  1. Concessão de mandato. O usuário autoriza o agente através da interface de mandato do Google (no Wallet ou através de uma interface de desenvolvedor para empresas). O mandato especifica valor máximo, janela de frequência, destinatários permitidos ou categorias de destinatários e uma expiração.
  2. Apresentação de mandato. Quando o agente precisa pagar, ele agrupa o mandato na solicitação de pagamento ao processador do comerciante. O processador valida a assinatura e os parâmetros do mandato; se a solicitação se encaixar, o pagamento prossegue.
  3. Liquidação. A liquidação real acontece sobre a ferrovia escolhida pelo comerciante (Google Pay, uma rede de cartões, ACH, stablecoin). O AP2 é agnóstico em relação à liquidação; o que ele padroniza é a autorização do agente para retirar da conta do usuário.
  4. Auditoria e revogação. Cada pagamento contra o mandato é registrado. O usuário pode revogar o mandato de sua carteira a qualquer momento. Apresentações subsequentes falham na validação; liquidações em andamento no momento da revogação podem ou não ser concluídas dependendo do rail.
EXEMPLOS

Onde AP2 se encaixa.

EXEMPLO 1

Agente pagando via Google Pay

Um agente da pilha Google (executando dentro do Gemini, Agentspace ou Vertex AI) apresenta um mandato AP2 ao processador de um comerciante. O processador valida o mandato, liquida o pagamento através das vias existentes do Google Pay e retorna a confirmação. A integração do comerciante é idêntica a uma transação normal do Google Pay; a diferença está do lado do comprador, onde o agente substituiu um humano.

EXEMPLO 2

Comércio de agentes entre protocolos

Um agente tem um mandato AP2 para pagamentos em fiat através do Google Pay E uma carteira Blockchain0x para pagamentos em USDC na Base. Quando precisa pagar um comerciante que aceita ambos, escolhe a opção com taxas mais baixas para essa forma de transação. O usuário concedeu ambas as autorizações uma vez; o agente roteia por pagamento.

EXEMPLO 3

Aquisição empresarial via AP2

Um agente de aquisição corporativa tem um mandato AP2 da equipe financeira autorizando pagamentos de até $10.000/mês para uma lista de fornecedores definida. O agente processa pedidos de compra, valida contra o mandato e liquida pagamentos sem que um humano aprove cada um. O registro de auditoria (mandato mais eventos de pagamento) vai para o sistema ERP da empresa.

FAQ

Três perguntas comuns.

AP2 é um concorrente do x402 ou eles coexistem?

Eles coexistem, com escolhas de design sobrepostas, mas distintas. AP2 é baseado em mandatos: o usuário pré-autorizou um envelope de pagamento, e o agente retira dele. x402 é baseado em solicitações: o comerciante retorna 402 com uma URL de pagamento, e o agente paga por chamada. AP2 se encaixa melhor em padrões de assinatura e recorrentes; x402 se encaixa melhor em padrões de pagamento por chamada e pay-as-you-go. Um agente sofisticado pode usar ambos os protocolos dependendo da forma do pagamento. Esperamos que ambos sejam de nível de produção até meados de 2026.

O AP2 requer criptomoeda ou funciona em trilhas tradicionais?

Funciona em trilhos tradicionais. O AP2 é agnóstico a trilhos; o protocolo especifica como o mandato é concedido, apresentado e validado, não como a liquidação subjacente acontece. A implementação de referência do Google visa o Google Pay (cartões, transferências bancárias, métodos de pagamento regionais). Implementações independentes poderiam liquidar em stablecoins. Na prática, as implantações do AP2 hoje são predominantemente em trilhos fiat porque o ecossistema do Google se inclina para lá.

O Blockchain0x suporta AP2?

Ainda não. Nosso modelo atual de controle de gastos (uma verba por agente por período e um limite por transação, aplicado na camada da API) é equivalente a mandate para os casos comuns, mas não implementa o protocolo de transporte AP2. O suporte formal a AP2 está no roadmap quando a especificação se estabilizar e os sinais de adoção ficarem mais claros. Enquanto isso, a diferença entre a nossa abordagem e AP2 é o documento formal de mandate que o agente carrega; os resultados de política são muito semelhantes.
Última revisão: 2026-05-15. Publicado sob CC BY 4.0.

Construa a superfície de pagamento do seu agente hoje.

O suporte ao AP2 está no roteiro. As capacidades principais (controles de gastos equivalentes a mandatos, identidade por agente, logs de auditoria) estão ativas agora.