Stripe formalizes checkout inside AI agents with the Agentic Commerce Protocol

Stripe's documentation details how sellers can now sell directly inside chatbots like ChatGPT, and what that costs in customer data and long-term relationships for those building e-commerce or SaaS in Brazil.

Stripe published documentation dedicated to "agentic commerce" that lays out how a seller lists products for sale inside an AI agent, and how an agent processes that payment without taking the user out of the conversation. At the center of this is the Agentic Commerce Protocol (ACP), cited in the documentation as one of the protocols used in the "sell through agents" flow. The doc already reaches the public with well-defined roles, protocols and maturity levels, including parts that are still in restricted access.

Stripe's page organizes the ecosystem into two sides: sellers, who make catalogs available and accept payment coming from agents, and agents, who act as an intermediary between buyer and seller, presenting products, building the cart and closing the purchase. According to the doc itself, the "agent" role is still in private preview, with an open waitlist, which means that anyone who wants to build an agent that processes checkout via Stripe (not just use a ready-made agent) doesn't have free access yet.

Two protocols, two different business models

Stripe doesn't treat "selling through an agent" as a single thing. The documentation explicitly separates two paths, and the difference between them is what determines whether the founder is competing for attention inside a third-party app or selling infrastructure to another system.

The first path is "sell through agents": sharing a catalog feed with the agent, letting it build the cart and complete checkout, receiving payment credentials from the agent itself. This flow runs on ACP or on a second protocol cited in the doc, the Universal Commerce Protocol (UCP), treated as an equivalent alternative for the same goal. It's the traditional e-commerce model: clothing, subscription, digital content, product with price and SKU, now exposed in a feed that the agent consumes instead of the site's own cart.

The second path is "accept machine payments": allowing an agent to pay for an API or service programmatically, processing payment outside of Stripe via MPP or x402. The doc gives a concrete example: monetizing an API or service by charging directly to personal agents like Claude Code. This isn't product commerce, it's automated usage billing, the natural model for those selling infrastructure SaaS, dev tooling, or a service consumed by an agent rather than by a human browsing.

For whoever decides where to invest engineering effort, the choice between the two paths is already a business-model decision: an e-commerce business selling physical or digital products looks at ACP/UCP; a SaaS that sells API calls or usage credits looks at MPP/x402. Confusing the two means integrating the wrong thing.

Link Agent Wallet: the agent pays, but the money still belongs to the customer

The piece that supports the model on the buyer's side is Link Agent Wallet, described in the doc as a way to give the agent the ability to pay online using a wallet controlled by the customer, plus permissioned access to financial insights from connected accounts. In other words: the agent doesn't hold the card or decide on its own how much to spend, it operates within limits and permissions that the owner of the money grants via Stripe. This technical design is what separates "an agent buying for you" from "an agent with your card saved," and it's the regulatory piece that any founder who's going to accept agent payments will need to understand before simply plugging in the catalog feed.

The question the documentation doesn't answer: who keeps the customer

Here's the point that matters to whoever is building a business, not just whoever is integrating an API. When the purchase happens inside the conversation, as Stripe itself describes it, without the buyer leaving the chat, checkout no longer happens on the seller's domain. This shifts three things that today live inside Brazilian e-commerce or transactional SaaS: who charges the processing fee, who sees browsing behavior and cart abandonment, and who holds the first-party data (email, history, preference) that today feeds remarketing, loyalty programs and churn prediction.

The doc doesn't address this point because it isn't its scope, it's the scope of the seller's own strategy. But the technical design already delivers the answer: if the catalog is consumed by the agent and checkout is closed by the agent, the post-sale relationship by default belongs to the platform that hosts the agent (OpenAI, or whoever runs the agent), not to the merchant. A SaaS that today lives on usage-telemetry-driven upsell loses exactly the channel where it captured that data, if it decides to sell exclusively via MPP inside a third-party agent.

The counterpoint: this already exists, it's called a marketplace

The obvious objection is that this trade-off isn't new. Anyone who already sells on Mercado Livre (Latin America's largest e-commerce marketplace), on Amazon, or accepts payment inside a delivery app has already given up first-party data in exchange for distribution. For a small e-commerce founder in Brazil, appearing in a feed consumed by an agent with a larger user base than any owned channel can be exactly the kind of customer acquisition that today costs a lot in paid media. The question isn't "is it worth giving up the data," it's the same question any marketplace has always demanded: does the volume make up for the lost margin and relationship, and is there a way to keep retention data even without the checkout, via post-purchase CRM or identification through transactional email.

What's missing for Brazil

Stripe's documentation doesn't mention Pix (Brazil's instant payment system), boleto, or installment payments anywhere, which is expected from a global product page, but it's the first point any Brazilian founder will need to solve before deciding to get in line for the private preview. Stripe operates in Brazil, but the ACP as documented was designed around cards and digital wallets in the American style; integrating a catalog with a local payment method inside an agent's flow is integration work that the company hasn't publicly mapped out yet. Anyone deciding today to join the "agent" waitlist or test "sell through agents" as a seller is betting on infrastructure that, in its current design, solves the American problem first.