OpenAI and Stripe's Agentic Commerce Protocol decides who sells inside AI checkout

The open specification from OpenAI and Stripe sets the technical and commercial rules for selling inside agents like ChatGPT. For those running e-commerce in Brazil, this is an architecture and revenue decision, not just technical compliance.

What ACP solves (and why it's not just another API)

The Agentic Commerce Protocol (ACP) is an open specification, published under the Apache 2.0 license, created jointly by OpenAI and Stripe to standardize how buyers, AI agents, and businesses transact. The core idea, according to the protocol's official documentation, is to define a common language to coordinate checkout and securely share payment credentials between an agent (such as ChatGPT) and the seller's commerce system.

So far this sounds like just another technical standard. The point that changes the game for anyone running e-commerce is different: ACP does not create a new marketplace controlled by OpenAI. It formalizes that the selling business remains the merchant of record, the one who decides which products are listed, how they're presented, and how the order is fulfilled. The AI agent only mediates the conversation and the payment; the commercial relationship and the legal responsibility for the sale stay where they always were.

This is a deliberate business-model choice, not a legal detail. By keeping regulatory risk and tax liability on the retailer's side, OpenAI avoids becoming a retailer itself, and manages to plug any store into ChatGPT without taking on the liability of inventory, returns, or fraud. On the agent's side, ACP is explicitly designed so the AI platform can "embed commerce in the app without being the merchant of record," in the words of the specification itself.

How it works underneath: REST, MCP, and the token Stripe named

Technically, ACP is stack-agnostic: the specification can be implemented via a traditional REST API or via MCP (the protocol that has already become the de facto standard for connecting models to external tools). This means that anyone who already has a working e-commerce backend doesn't need to rewrite the checkout layer from scratch, just expose an ACP-compatible endpoint on top of what already exists.

The sensitive part is payment. ACP solves the problem of passing card credentials through an intermediary (the agent) without violating PCI DSS by using a token: Stripe is the first compatible processor, with what the documentation calls the Shared Payment Token. In practice, the buyer authorizes the payment, Stripe issues a token representing that authorization, and that token, not the card number, travels between the agent and the seller's system. The specification is explicit: "securely pass payment credentials from buyers to AI agents, without exposing the underlying credentials."

The choice founders need to make: implementing isn't getting in

Here's the detail that separates strategy from marketing. Implementing ACP puts a company's checkout in technical condition to accept orders from any compatible agent, since the specification is open and any AI platform can call it. But the protocol's own documentation is direct when answering whether this means automatic listing in agents: it doesn't.

Each AI platform controls its own participation process. In ChatGPT's specific case, the first to implement ACP, the business that wants to sell needs to apply separately: OpenAI decides who gets into the storefront, even though the connection protocol is public. In other words: ACP removes the technical integration barrier, but keeps (and perhaps reinforces) the commercial curation barrier.

This creates two layers of decision for sellers:

1. Technical layer: is the engineering investment worth it to make the checkout ACP-ready, even without a guarantee of immediate traffic?
2. Commercial layer: does the company apply to each AI platform's process (today, only ChatGPT) and accept curation terms it doesn't control?

In short: whoever implements ACP first doesn't necessarily sell first, but is ready for when (and if) they're accepted, while competitors are still deciding whether it's worth it.

Fine-grained control: accepting or rejecting agent by agent

A point that goes unnoticed in more superficial ACP coverage: the specification lets a business accept or reject transactions by agent, by individual transaction, or by its own custom logic. This means a store can, for example, accept orders coming from ChatGPT but block an unknown agent trying to connect to the same endpoint, or refuse transactions above a certain value without human review.

For those designing e-commerce risk architecture, this is the difference between exposing a public, generic checkout and maintaining a decision perimeter. This granularity favors those who already have maturity in fraud and anti-fraud rules, and works against those who will only notice the problem after the first strange order goes through.

The counterpoint: open standard isn't synonymous with open access

The obvious thesis is that ACP, being Apache 2.0 and technically agnostic to PSP and agent, democratizes access to agentic commerce. The best argument against this reading is simple: today, in practice, there is only one relevant agent implementing the specification (ChatGPT) and one compatible processor (Stripe). An open protocol with a single real entry point works, in practice, like a closed protocol, until other players join.

OpenAI and Stripe's defense is that discovery mechanisms for other AI platforms are still being built, and that parties interested in adopting ACP can reach out through the project's official contact. It's a promise of future openness, not a market reality today. Whoever decides to implement now is betting that the OpenAI/Stripe duo will keep the spec genuinely neutral as more agents and PSPs arrive, and that bet has a mixed track record when a standard is born inside two companies with a direct commercial interest in the outcome.

What this means for sellers in Brazil

For Brazilian marketplaces and e-commerce businesses, the math has three concrete variables. The first is payment infrastructure: the Shared Payment Token today depends on Stripe as the compatible processor. In practice, this means that those running on Pagar.me, Mercado Pago (Brazilian payment processors), or other domestic acquirers need to wait (or push) for equivalent compatibility before ACP becomes a real revenue option.

The second is engineering priority: given that applying to ChatGPT is separate from the technical implementation, it makes more sense to map out the integration effort before deciding to chase OpenAI's approval, since the technical work isn't lost even if approval takes time or never comes. The third is regulatory: remaining the merchant of record within the ACP flow means Brazilian tax and consumer-protection obligations continue to be the seller's problem, not the agent's. Nothing in the protocol changes that, and it's worth checking with legal counsel before treating "selling through ChatGPT" as just another marketing channel.