The Agentic Economy: Exploring OpenAI and Google’s Race to Build AI-driven Payments
A deep dive into the protocols behind agentic payments, the trust layers that make them possible, and the emerging ecosystem that could change how digital commerce works.
What if you could shop just by saying what you want, and an AI handled the rest? No checkout pages, no copy-pasting card numbers, no switching between apps. Just intent in, transaction out.
So far, agents have been great at finding things, comparing options, and helping you make decisions. However, when it comes to actually completing a purchase, they’ve been stuck at the final step.
That’s beginning to shift.
OpenAI and Google are building protocols that give agents the ability to handle transactions on your behalf. Where traditionally we’ve relied on buttons, checkout pages, clicks, and copied card numbers, these new systems aim to create a trusted way for agents to prove user intent, pass credentials, and move money through existing commerce flows.
It marks a clear transition from assistants that suggest to agents that execute.
This effort fits into a bigger shift toward what is commonly referred to as the agentic economy. The idea is simple. If AI can already plan your travel, manage your schedule, or handle repetitive tasks, why shouldn’t it also be able to book the flight, buy the watch you’ve been eyeing, or sign you up for a service, all on your behalf and without pulling you back into the process? For that to work, agents need reliable tools that can move through real financial systems with clarity and trust.
Right now, two frameworks are leading the way:
Agentic Commerce Protocol (ACP), developed by OpenAI, already powers transactions inside ChatGPT using Stripe and Shopify under the hood.
Agent Payments Protocol (AP2), introduced by Google, focuses on cryptographic verification and mandate-based permissions to help agents interact safely across a broader network of merchants, banks, and platforms.
In this post, I’ll walk through how each protocol works, where they overlap, and what sets them apart. We’ll also look at other players entering the space like Coinbase’s x402, and dig into the infrastructure that’s starting to take shape behind the scenes.
The rails for agentic payments are being laid right now and they’re coming faster than most people think.
Why Agentic Commerce Exists
Agentic commerce didn’t emerge because traditional shopping flows were broken. It emerged because the way people interact with software has changed. Once natural language became the dominant interface for LLMs, it created a gap that traditional commerce stack was never designed to fill.
When someone instructs an agent to, “Find me a flight for Thursday and book the best option,” there is no clean way for that intent to move through a traditional payment stack. The web expects clicks, forms, login pages, and confirmations. Agents operate through context and intent. Those two worlds don’t line up.
As LLMs became more capable, the tasks they could take on naturally expanded into areas that involve transactions. Planning travel, managing subscriptions, organizing purchases, tracking renewals. These fit seamlessly inside conversational workflows, but the actual purchase still forces a context switch back into a human-centric process.
The real motivation behind ACP and AP2 is to close that gap. They give merchants and banks a structured way to understand what the user is asking for, verify that the request is legitimate, and complete the transaction without leaving the flow.
It’s less about fixing inefficiency and more about creating a new path that matches how people now express intent. Natural language is becoming the interface. These protocols make commerce compatible with that shift.
What ACP and AP2 Are Trying to Achieve
Before diving into how each protocol works, it helps to step back and look at the goals they share. Even though OpenAI and Google are taking different approaches, they are both trying to answer the same fundamental question: how do you let an agent participate in commerce without introducing chaos, fraud, or guesswork?
The first goal is clarity. An agent needs a way to express what the user is asking for in a structured format that a merchant or bank can understand. Natural language is great for people, but financial systems need precision. These protocols define that bridge. They take conversational intent and shape it into something that downstream systems can trust.
The second goal is control. Users need to decide what an agent is allowed to do, how far it can go, and when it should stop. That requires permissions, limits, and scopes. ACP handles this through platform level guardrails. AP2 does it through explicit mandates that the agent must present to the merchant. Both approaches serve the same purpose, which is giving users confidence that the agent is acting inside a defined boundary.
The third goal is safety. Payments are tightly regulated for a reason. Fraud, misuse, and unauthorized transactions damage trust. If agents are going to operate inside financial systems, they need a way to prove intent, show provenance, and provide a trail that banks and merchants can audit. These protocols provide the scaffolding for that. They make it clear who asked for what, which agent acted on the request, and what led up to the decision.
The last goal is continuity. If agents become a primary way people interact with software, then commerce should not force them out of the flow. The entire point of conversational interfaces is that they remove friction. ACP and AP2 aim to preserve that. They let users stay inside a single conversation even when the task involves something as sensitive as a payment.
Together, these goals form the foundation for agentic commerce. They answer the question of what these protocols are trying to enable long before we get to the specifics of how they do it.
Introducing ACP and AP2
Now that we have a sense of why these protocols exist and what they are aiming to support, we can look at how OpenAI and Google are approaching the problem.
ACP: Agentic Commerce Protocol (OpenAI)
ACP is the system that allows agents inside ChatGPT to complete transactions using existing payment providers behind the scenes. It handles the full flow from capturing user intent, confirming what the agent is trying to do, passing that intent to a payment partner, and returning the result to the user.
In practice, ACP acts like a structured wrapper around normal checkout flows. The user stays in conversation, the agent stays aligned with what was requested, and the merchant receives a clear record of what happened.
Today, ACP is live inside ChatGPT with Stripe and Shopify, and OpenAI expects more partners to build on it over time.
AP2: Agent Payments Protocol (Google)
AP2 approaches the same space from a different angle. Instead of focusing on the in-app experience, it focuses on trust and verification across a broader agent ecosystem. The core idea is the mandate. A user grants an agent a specific, limited permission to complete a type of action. That mandate can be shown to a merchant or service to confirm that the agent is allowed to act.
AP2 is more cryptographic and distributed in nature. It is meant to work across services, platforms, and merchant networks instead of staying inside a single app experience.
Google has demonstrated AP2 in Gemini workflows, and early partners are beginning to explore how the mandate system can fit into their ecosystems.
Two paths toward the same outcome
ACP focuses on framed, in-platform commerce. AP2 focuses on agent identity, mandate proofs, and a broader cross-platform ecosystem. Both are early, both are evolving, and both are aimed at making agents safe and useful in real-world transactions.
How ACP Works
ACP is designed to let an agent complete a transaction without ever leaving the conversation. The key idea is to take a natural language request, turn it into a structured action, confirm it with the user, and pass it to a trusted payment partner who can complete the work. Behind the scenes, ACP runs through a predictable set of steps that keep the process safe and auditable.
At a high level, the flow looks like this:
The user expresses intent in natural language
Something as simple as “Order me another bag of coffee” or “Buy the book I mentioned earlier.” ACP takes that request and turns it into a structured action that the system can understand.The agent proposes an action
The agent translates the intent into a concrete step. For example, selecting a product, choosing a merchant, or preparing a cart. This proposed action is always visible to the user.The user confirms the action
Before anything moves forward, ACP requires an explicit confirmation from the user. This guardrail removes ambiguity. The agent cannot proceed until the user signs off.The platform forwards the request to a payment partner
Once confirmed, ACP handles the handoff to a provider like Stripe or Shopify. These partners complete the actual payment flow using the credentials the user already has stored with them.The merchant receives a structured and auditable request
The merchant sees exactly what the user asked for, which agent submitted the request, and the full context of the intent. This keeps the transaction verifiable and traceable.The result flows back into the conversation
The user stays in the same chat the entire time. The agent provides the final confirmation, along with any additional steps the user might want to take.
ACP is turning a conversation into a transaction in a way that merchants, banks, and users can understand. It keeps the steps familiar for payment providers, while giving agents a controlled path to act on behalf of a user.
Diagram: ACP Flow Inside ChatGPT
This diagram from OpenAI shows the full lifecycle of an ACP transaction from the moment the user expresses intent all the way to the payment processor charging the card. What’s helpful about this view is how ordinary the flow actually is. ACP doesn’t change how payments work. It simply gives an agent a safe, structured way to move through the same steps a user would take on their own.
How AP2 Works
AP2 takes a different path from ACP. Instead of focusing on keeping the entire purchase inside a single conversational experience, AP2 focuses on trust. The central idea is that an agent should only be able to act if it can prove that the user gave it permission to do something specific. That proof comes in the form of a mandate.
A mandate is a small, structured document that describes exactly what the agent is allowed to do. It might be something like “Book this flight using my saved payment method” or “Pay my monthly storage bill as long as the amount stays under a set limit.” The user creates the mandate, the agent presents it, and the merchant verifies it before taking any action.
At a high level, the AP2 flow looks like this:
The user creates a mandate
Inside a Gemini powered workflow, the user grants an agent a permission with clear limits. The mandate can define the type of action, the merchant, the amount, and any constraints the agent should follow.The agent prepares a request
When the user gives a new instruction, the agent checks whether the mandate covers the action. If it does, the agent packages the request and attaches the mandate as proof of permission.The merchant verifies the mandate
The mandate is sent to the merchant, who checks its validity. This step is similar to verifying a signature or credential. The merchant is confirming two things: the mandate came from the user, and the agent is acting within its scope.The merchant completes the transaction
Once the mandate is verified, the merchant processes the order using the user’s stored payment method. The mandate removes the ambiguity around whether the request was authorized.A receipt or result flows back to the agent
After the order is processed, the result flows back to the agent, which then summarizes it for the user. The user stays within the same conversational flow the entire time.
AP2 is built to support a broad ecosystem. Instead of keeping everything inside one application, it gives merchants and services a consistent way to interact with agents they might not control. The protocol focuses heavily on identity, cryptographic verification, and user intent so that anyone participating in the ecosystem can trust what the agent is presenting.
Deep Dive on AP2 Mandates
Mandates are the core of AP2. They give agents a controlled way to act on behalf of a user, and they give merchants a reliable way to verify that the action was actually authorized. Instead of relying on trust or assumptions, a mandate serves as a structured and verifiable permission that clearly defines what the agent is allowed to do.
A mandate answers three questions:
What is the agent allowed to do?
Who granted that permission?
What limits or conditions apply to the action?
Once a mandate exists, the agent presents it whenever it needs to perform the action it covers. The merchant validates the mandate, checks that it fits the request, and proceeds only if everything lines up.
What goes inside a mandate
Although implementations will evolve, a mandate typically includes fields like:
Action type
The specific task the agent is permitted to execute, such as “book this flight” or “pay this invoice.”Merchant or domain
The business or category the mandate applies to. This keeps an agent from using a mandate outside of its intended scope.Amount or spending limit
Either a fixed price or an upper boundary. This prevents unexpected or inflated charges.Validity window
When the mandate is allowed to be used. It could be a one-time action, a limited window, or a renewable period.User signature
A cryptographic proof that the permission came from the user, not the agent.Agent signature
A clear identity marker for the agent presenting the mandate.Integrity metadata
Timestamps, nonces, hashes or other safeguards that help merchants detect tampering or replay attempts.
These fields give merchants enough structure to make a confident decision without needing access to the entire conversation between the user and the agent.
How mandates are created
Mandates begin with natural language. When a user expresses an instruction that involves payment or authorization, AP2 converts that request into a structured mandate that mirrors exactly what the user intended. The system presents the mandate back to the user for review. Only after they confirm it does the mandate become valid.
How merchants verify mandates
Verification is the heart of AP2. Merchants check:
The user signature is valid.
The agent signature matches the agent presenting the request.
The mandate has not expired or been revoked.
The action fits the mandate’s constraints.
The merchant matches the scope defined in the mandate.
The amount falls within the approved limit.
If everything checks out, the merchant completes the transaction. If anything is out of bounds, they reject it.
Mandate revocation
Mandates are not permanent. Users can revoke them at any time. Once revoked:
The agent loses the ability to act
Merchants will reject any requests that rely on it
The ecosystem maintains a clean, auditable boundary of authority
Why mandates matter
Mandates give AP2 the flexibility to operate across an open network rather than inside a single application. They let users grant precise, scoped permissions that can be validated by any participating merchant. They also give merchants what they need most: a guarantee that the request was authorized, traceable, and safe to process.
Mandates turn agentic actions from informal instructions into structured decisions that the entire ecosystem can rely on.
How Merchants Adopt AP2
For AP2 to work in the real world, merchants need a way to recognize agent-driven requests, verify the user’s permission, and process the order without relying on screens or traditional checkout flows. This means AP2 only succeeds if merchants integrate it directly into their own backend systems.
At a high level, a merchant becomes AP2 compatible by adding a verification step that accepts two things:
A structured purchase request and the mandate that authorizes it.
The mandate contains everything the merchant needs to decide whether the request is valid. If the mandate checks out, the merchant completes the order using the same payment processors and fraud systems they already rely on today. AP2 doesn’t replace their checkout, but becomes another entry point into it.
The actual implementation is minimal. The merchant exposes an endpoint that can receive:
the AP2 purchase request
the attached mandate
the user and agent signatures
From there, the merchant verifies the mandate and either fulfills or rejects the request. Google will provide SDKs and helper libraries that handle most of this work, similar to how Apple Pay, OAuth, and ShopPay integrated into existing ecommerce platforms.
Merchants benefit from this model because they gain access to a new class of agent-driven customers without giving up control. They keep their fraud checks, keep their rails, and gain a clean and auditable record of what the user authorized and why.
The Overlooked Requirement: Where Intent Comes From
There is one important detail that often gets missed. AP2 only handles permissions. It does not handle the conversational interface, the action schemas, or the intent recognition needed to decide which action should be executed in the first place.
Someone still has to translate natural language like “Order me another pair of Levi jeans” into a structured action the merchant understands.
There are two ways this can happen:
1. The merchant builds their own action or intent API.
They define structured tooling like purchase_item, reserve_item, or check_inventory, and agent platforms route natural language instructions into these actions.
2. The merchant relies on a platform-level interface provided by a partner.
Gemini, Shopify, or another ecosystem can offer a declarative action layer that merchants plug into, and the platform handles the natural language interpretation for them.
This is an important distinction because OpenAI already has a robust function-calling ecosystem, and that gives them a practical advantage. Merchants integrating with ACP can reuse an existing, widely adopted interface for actions and intent. AP2 requires more build-out unless Google ships a similarly strong action framework.
ACP vs AP2 - Key Differences
ACP and AP2 share the same mission, but they approach the problem from very different angles. ACP is built around a contained and highly polished user experience inside ChatGPT. AP2 is designed as a broader, portable trust framework that can work across different platforms and merchants. Looking at them side by side makes the contrast clear.
1. Where the protocol lives
ACP:
Lives inside the ChatGPT environment. The agent, the confirmation step, and the merchant handoff all happen within one cohesive flow. Everything is driven by OpenAI’s interface.
AP2:
Lives outside any single application. It is a distributed protocol meant to support agents acting across multiple surfaces, not just one conversational environment.
This difference alone affects adoption. ACP is easier to adopt early because the surface area is small and controlled. AP2 is wider and more flexible but requires more ecosystem alignment.
2. How intent becomes action
ACP:
Uses OpenAI’s built-in function calling and action frameworks. Merchants do not need to build a conversational interface from scratch. ChatGPT interprets user intent, maps it to the right action, and presents a structured request.
AP2:
Requires the merchant or platform to provide an action layer above the protocol. AP2 does not handle intent. It only handles permission. Merchants must either publish schemas for their actions or rely on a partner (like Shopify or Gemini) to manage the intent-routing layer.
This gives OpenAI a short-term advantage. They already have a mature action system that merchants can plug into with minimal effort.
3. How user permission is captured
ACP:
Relies on real-time user confirmation inside ChatGPT. Before an agent takes an action, the user approves it directly in the conversation. This creates clarity for both the user and the merchant but keeps transactions synchronous.
AP2:
Uses mandates. These are structured, cryptographically verifiable permission objects that define what an agent is allowed to do. Mandates can be reused within their scope and do not require the user to be present for every action.
ACP prioritizes simplicity. AP2 prioritizes portability and repeatability.
4. The trust model
ACP:
Merchants trust OpenAI and its payment partners (like Stripe or Shopify) because the entire flow stays inside ChatGPT’s environment. The user request, agent proposal, and confirmation all occur in one place.
AP2:
Merchants trust the mandate, not the agent platform. The mandate itself contains the proof of authorization. This is closer to a decentralized trust model and allows AP2 to work across different systems without relying on a single platform.
5. Merchant integration effort
ACP:
Lower effort upfront. If a merchant already uses Stripe or Shopify, they can participate automatically inside ChatGPT. OpenAI handles most of the flow.
AP2:
Requires merchants to implement a verification endpoint and support an action layer. It is more flexible long term but requires more work initially.
6. Ecosystem strategy
ACP:
Focused on creating a refined, frictionless experience within ChatGPT.
OpenAI optimizes for user experience first, ecosystem later.
AP2:
Structured as a protocol that can live beyond Gemini.
Google optimizes for interoperability and long-term ecosystem growth.
7. Long-term potential
ACP shows how powerful agent-driven purchases can feel when everything is tied to one environment. AP2 shows how agentic commerce might look once it spreads across the entire web.
It is entirely possible that ACP becomes the default experience inside ChatGPT-powered applications, while AP2 becomes the standard protocol for agent-driven purchases across different platforms and merchants.
Both approaches are valid. Both fill different needs. And both are early glimpses of what commerce looks like when agents stop at recommendations and start completing tasks.
Other Players in the Agentic Payments Space
ACP and AP2 are getting the most attention right now, but they are not the only efforts shaping this space. As soon as agents became capable of taking real actions, it was only a matter of time before other companies started thinking about how agents should move money, verify identities, and interact with financial networks. A few early entrants are already starting to define their own roles in this ecosystem.
Coinbase x402
x402 is Coinbase’s agent-first wallet architecture. Instead of designing a protocol for merchants, x402 focuses on giving agents direct access to wallets through tightly scoped permissions. The wallet can approve transactions, sign messages, and interact with crypto networks, all under user-defined limits. If agentic commerce grows in financial or Web3 environments, x402 positions Coinbase as a direct bridge between agents and on-chain transactions.
What makes x402 interesting is the symmetry with AP2. Both rely on scoped permissions and cryptographic verification. The difference is that AP2 is built for traditional commerce and fiat rails, while x402 is designed for programmable value, tokenized assets, and on-chain actions. It is not hard to imagine a future where these two approaches start to overlap.
Stripe’s Agentic Experiments
Although Stripe has not formally announced its own protocol, it has already integrated with ACP and has been quietly building components that agents can use to process payments, retrieve balance information, or manage subscriptions. Stripe’s focus has always been developer-first financial infrastructure, and agent-driven commerce fits naturally into that strategy. If Stripe decides to formalize an agentic interface, it will likely become one of the simplest ways for merchants to support this new model.
Shopify’s Semantic and Action Layers
Shopify has been pushing toward semantic APIs that let agents interact with storefronts through structured actions rather than HTML screens. The company already integrates with ACP, and it is building the tooling that allows agents to navigate catalog data, fulfill carts, and manage orders programmatically. Shopify could become one of the largest accelerators of agentic commerce because of its control over millions of independent storefronts.
Amazon and the Implicit Threat
Amazon has not announced anything public yet, but they have every incentive to build an agentic commerce layer. They already have the largest product catalog, the most complete logistics network, and a huge base of users with stored payment credentials. If Amazon builds a first-party agent interface, it could become a central hub for agent-driven purchasing simply because most shopping starts there already.
What This Means and Closing Thoughts
Agentic payments are still early, but the shift they represent is hard to ignore. As natural language becomes a more streamlined way people interact with software, it creates a gap that traditional checkout flows were never built to handle. ACP and AP2 are the first real attempts to close that gap.
ACP shows how smooth this can feel inside a single environment like ChatGPT. AP2 pushes the idea further by creating a portable trust layer that can work across different apps, merchants, and platforms. Around them, companies like Coinbase, Shopify, and Stripe are starting to build the infrastructure that will make agent-driven commerce practical at scale.
The interesting part is how early all of this still is. Merchants are experimenting, the tooling is evolving, and the standards are still taking shape. But the foundation is here, and once agents can understand intent and safely complete transactions, commerce could begin to move into the background.
Will these systems be secure enough? Will merchants adopt them at scale? Can this model grow beyond early demos? And is natural language truly the future of commerce, or just a moment shaped by the current wave of AI demand?
We’ll find out soon enough, but the rails are already being built.