Stripe formaliza o checkout dentro de agentes de IA com a Agentic Commerce Protocol

A documentação da Stripe detalha como sellers passam a vender direto dentro de chatbots↳Chatbots21 conteúdosiMasters Case – Cresce uso de chatbots no WhatsAppDevSecOps · nov 2020Criando um ChatBot em menos de 5 minutos? Sim, é possível!AI · abr 2019Chatbots que analisam tom de voz e texto reduzem frustração em atendimentosAI · jul 2025Ver tudo em AI → como o ChatGPT, e o que isso custa em dado de cliente e relação de longo prazo para quem constrói e-commerce↳E-commerce21 conteúdosECBR Club: novo espaço para devs se conectarem ao ecossistema de e-commerceDev (Back & Front) · mai 2025TOTVS anuncia joint venture com VTEXMarketing Tech · mai 2019Jovens da Brasilândia recebem formação gratuita em tecnologiaGestão Dev & TI · jul 2025Ver tudo em Marketing Tech → ou SaaS no Brasil.

A Stripe publicou uma documentação dedicada a "agentic commerce" que organiza como um vendedor coloca produtos à venda dentro de um agente de IA, e como um agente processa esse pagamento sem tirar o usuário da conversa. O centro disso é a Agentic Commerce Protocol (ACP), citada na documentação como um dos protocolos usados no fluxo "sell through agents". A doc já chega ao público com papéis, protocolos e níveis de maturidade bem definidos, incluindo partes que ainda estão em acesso restrito.

A página da Stripe organiza o ecossistema em dois lados: sellers, que disponibilizam catálogo e aceitam pagamento vindo de agentes, e agents, que atuam como intermediário entre comprador e vendedor, apresentando produtos, montando carrinho e fechando a compra. Segundo a própria doc, o papel de "agent" ainda está em private preview, com lista de espera aberta, o que significa que quem quer construir um agente que processa checkout via Stripe (não apenas usar um agente pronto) não tem acesso livre ainda.

Dois protocolos, dois modelos de negócio diferentes

A Stripe não trata "vender por agente" como uma coisa só. A documentação separa explicitamente dois caminhos, e a diferença entre eles é o que decide se o founder está competindo por atenção dentro de um app de terceiro ou vendendo infraestrutura para outro sistema.

O primeiro caminho é "sell through agents": compartilhar um catalog feed com o agente, deixar que ele monte o carrinho e conclua o checkout, recebendo credenciais de pagamento do próprio agente. Esse fluxo roda sobre ACP ou sobre um segundo protocolo citado na doc, o Universal Commerce Protocol (UCP), tratado como alternativa equivalente para o mesmo objetivo. É o modelo do e-commerce tradicional: roupa, assinatura, conteúdo digital, produto com preço e SKU, agora exposto num feed que o agente consome em vez do carrinho do próprio site.

O segundo caminho é "accept machine payments": permitir que um agente pague por uma API ou serviço de forma programática, processando o pagamento fora da Stripe via MPP ou x402. A doc dá o exemplo concreto: monetizar uma API ou serviço cobrando diretamente de agentes pessoais como o Claude Code. Isso não é comércio de produto, é cobrança de uso automatizada, o modelo natural para quem vende SaaS de infraestrutura, ferramenta de dev ou serviço consumido por agente e não por humano navegando.

Para quem decide onde investir engenharia, a escolha entre os dois caminhos já é uma decisão de modelo de negócio: um e-commerce de produto físico ou digital olha para ACP/UCP; um SaaS que vende chamada de API ou crédito de uso olha para MPP/x402. Confundir os dois é integrar a coisa errada.

Link Agent Wallet: o agente paga, mas o dinheiro continua sendo do cliente

A peça que sustenta o modelo do lado do comprador é o Link Agent Wallet, descrito na doc como forma de dar ao agente capacidade de pagar online usando uma carteira controlada pelo cliente, além de acesso permissionado a insights financeiros de contas conectadas. Ou seja: o agente não guarda o cartão nem decide sozinho quanto gastar, ele opera dentro de limites e permissões que o dono do dinheiro concede via Stripe. Esse desenho técnico é o que separa "agente comprando por você" de "agente com seu cartão salvo", e é a peça regulatória que qualquer founder que for aceitar pagamento de agente vai precisar entender antes de simplesmente plugar o feed de catálogo.

A pergunta que a documentação não responde: quem fica com o cliente

Aqui está o ponto que interessa a quem constrói negócio, não só a quem integra API. Quando a compra acontece dentro da conversa, como a própria Stripe descreve, sem o comprador sair do chat, o checkout deixa de acontecer no domínio do vendedor. Isso desloca três coisas que hoje moram no e-commerce ou no SaaS transacional brasileiro: quem cobra a taxa de processamento, quem enxerga o comportamento de navegação e abandono de carrinho, e quem detém o dado de primeira parte (e-mail, histórico, preferência) que hoje alimenta remarketing, programa de fidelidade e previsão de churn.

A doc não trata desse ponto porque não é escopo dela, é escopo de estratégia de quem vende. Mas o desenho técnico já entrega a resposta: se o catálogo é consumido pelo agente e o checkout é fechado pelo agente, o relacionamento pós-venda por padrão pertence à plataforma que hospeda o agente (OpenAI, ou quem quer que rode o agente), não ao lojista. Um SaaS que hoje vive de upsell orientado por telemetria de uso perde justamente o canal onde capturava esse dado, se decidir vender exclusivamente por MPP dentro de um agente de terceiro.

O contraponto: isso já existe, chama-se marketplace

A objeção óbvia é que esse trade-off não é novo. Quem já vende no Mercado Livre, na Amazon ou aceita pagamento dentro de um app de delivery já abriu mão de dado de primeira parte em troca de distribuição. Para um founder de e-commece pequeno no Brasil, aparecer num feed consumido por um agente com base de usuários maior que qualquer canal próprio pode ser exatamente o tipo de aquisição de cliente que hoje custa caro em mídia paga. A pergunta não é "vale abrir mão do dado", é a mesma pergunta que qualquer marketplace sempre exigiu: o volume compensa a margem e o relacionamento perdidos, e existe uma forma de manter dado de retenção mesmo sem o checkout, via CRM pós-compra ou identificação por e-mail transacional.

O que falta para o Brasil

A documentação da Stripe não menciona Pix, boleto ou parcelamento em nenhum ponto, o que é esperado de uma página de produto global, mas é o primeiro ponto que qualquer founder brasileiro vai precisar resolver antes de decidir entrar na fila do private preview. A Stripe opera no Brasil, mas a ACP como documentada foi desenhada em torno de cartão e carteira digital ao estilo americano; integrar catálogo com meio de pagamento local dentro do fluxo de um agente é trabalho de integração que ainda não está mapeado publicamente pela empresa. Quem decide hoje entrar na waitlist de "agent" ou testar "sell through agents" como seller está apostando em infraestrutura que, no desenho atual, resolve o problema americano primeiro.

Fonte: Stripe Docs — Agentic Commerce