Agentic Commerce Protocol redefines who owns the customer when the buyer is an AI agent

The standard that's no longer news, but still hasn't been digested

The Agentic Commerce Protocol (ACP) was published by Stripe and OpenAI as an open specification, under the Apache 2.0 license, to standardize how AI agents, buyers, and businesses close a purchase. The first implementation is ChatGPT on the agent side, and Stripe on the payment processing side, via a mechanism called Shared Payment Token. What became clear isn't the technology itself, but the power structure it embeds.

That's what matters to whoever decides where to allocate the next quarter of engineering: it's not about integrating one more checkout, it's about accepting the rules of a distributor that is still designing its own rules.

Merchant of record: the detail that looks technical and is strategic

The ACP specification explicitly guarantees that the business remains the merchant of record (MOR). This means the company that sells, not OpenAI nor the agent, keeps control over which products are sold, how they are presented, and how the order is fulfilled. In practice, this is the opposite of the classic marketplace model, where Amazon or iFood (Brazil's dominant food delivery platform) absorb the MOR and, with it, tax liability, chargeback handling, and, above all, the end customer's data.

Keeping the MOR has a price: the company remains responsible for fraud, refunds, and tax compliance on the sale, even when the one who pressed the buy button was an agent acting on behalf of a user the company never saw directly. The ACP allows the business to accept or decline transactions by agent, by transaction, or by custom logic, which hands back control, but also hands back work: someone on the team needs to decide that policy and maintain it.

In summary: the ACP doesn't outsource the business's risk to OpenAI. It outsources discovery and closing of the sale, while keeping the account, inventory, fulfillment, and fraud exposure on the side of whoever always had it: the seller.

Stripe as the first compatible PSP: lock-in disguised as an open standard

The specification says any compatible payment processor can operate with the ACP, but it's also explicit: Stripe is the first compatible PSP, with its Shared Payment Token. That's an important distinction for anyone who already runs their payment operation on another provider, such as Adyen, PagSeguro (a Brazilian payments company), or Mercado Pago.

The technical entry point, today, runs through Stripe. A business that wants to sell via ChatGPT without being on Stripe depends on that other PSP implementing the protocol and getting certified, something the documentation itself treats as an open-ended process, with no date. This is the classic pattern of conditional openness: the specification is Apache 2.0 and anyone can read it, but real distribution, for now, runs through a single path.

The application to sell on ChatGPT: open protocol, closed distribution

The least discussed part of the specification is also the most decisive for sellers' planning: implementing the ACP does not automatically list the product on any agent. The documentation itself answers this directly: each AI platform manages its own participation process, and to sell on ChatGPT you need to apply and be approved.

This creates an asymmetry worth naming. As a protocol, the ACP is neutral, any agent can call an enabled checkout. As a channel, ChatGPT (today the only relevant agent implemented) decides who gets in, the way an app store decides who gets shelf space. The company that invests engineering in making its checkout agent-ready doesn't buy automatic access to ChatGPT's traffic, it buys the right to request that access.

The counterpoint: why it's still worth implementing even without a distribution guarantee

The argument against is straightforward: investing in a protocol whose PSP certification is limited to a single vendor, and whose distribution depends on the discretionary approval of a single platform, means betting on infrastructure that hasn't yet proven volume. There is no GMV figure transacted via ACP, either in the specification or in any public data it cites, to support the thesis that the channel already pays for the cost of implementation.

The counter-argument is one of optionality, not certainty. The specification is open, runs over REST or MCP, and integrates with existing commerce infrastructure, which lowers the cost of experimenting: there's no need to rebuild checkout, inventory, or payment backend, just expose a compatible endpoint. For a business that already processes on Stripe, the marginal cost of testing is small; for those on another PSP, the calculation changes, because the bet includes waiting for third-party certification.

For decision-makers: three questions before allocating the sprint

Before putting the ACP on the roadmap, it makes sense to answer three questions the specification leaves open:

• Who is the operation's PSP today? If it's not Stripe, implementation depends on a timeline that OpenAI and Stripe don't control and haven't published.
• Is the company willing to give up direct visibility into the end buyer? The MOR stays with the business, but the discovery journey now happens inside the agent, outside the funnel the company instruments today.
• What is the policy for accepting or declining transactions by agent? The protocol provides this granular control, but someone needs to design it, and that's product and risk work, not just engineering.

The ACP isn't a new fee baked into the product price, it's a redistribution of where control (and work) lives in the sales chain. For e-commerce and SaaS founders, the decision to implement is less about technology and more about how much of the customer relationship the company is willing to mediate through an agent it neither builds nor audits.