The pitch sounds effortless: tell ChatGPT what you want, tap to confirm, and it's yours. No tabs, no forms, just done. The reality behind that tap is a Rube Goldberg machine of cryptographic contracts, payment tokenization, and fraud detection built atop infrastructure that assumes humans are clicking buttons.
OpenAI launched Instant Checkout in ChatGPT, letting U.S. users buy single items from Etsy sellers without leaving the conversation. It's powered by the Agentic Commerce Protocol (ACP)—a new standard OpenAI built with Stripe to let AI agents handle commerce. The launch is real but narrow: for U.S. users, one item at a time, U.S. merchants only, Etsy for now with Shopify "coming soon."
Earlier, Google announced the Agent Payments Protocol (AP2), backed by over 60 companies including Mastercard, PayPal, and Coinbase. Unlike OpenAI's live-but-limited rollout, AP2 is specification-complete with zero consumer products. It's a more deliberate, cryptographically rigorous framework that won't see real users for months.
The timing reveals the stakes. Both companies see a future where AI agents don't just recommend products but transact autonomously on your behalf. The question is whose infrastructure becomes the standard—and whether either can actually deliver on the promise without breaking the existing financial system.
The problem both are trying to solve
E-commerce infrastructure has one foundational assumption: a human is clicking "buy" on a website they trust. That assumption powers everything—fraud detection models, liability frameworks, dispute resolution, regulatory compliance.
When an AI agent initiates a purchase, especially one you're not actively monitoring, that assumption collapses. How do you prove the user authorized it? How does a merchant know the agent's request reflects actual intent and not an AI hallucination about what "running shoes under $100" means? When something goes wrong—wrong size, wrong color, fraudulent charge—who's liable?
"Without a common protocol, we risk a fragmented ecosystem of proprietary payment solutions," Google's AP2 documentation warns. OpenAI's materials echo similar concerns. Both are positioning their protocols as neutral, open-source infrastructure—ACP and AP2 are both Apache 2.0 licensed—that anyone can implement.
Both support explicit user confirmation. Both claim to work across payment processors. Both invoke the language of user control and security.
But dig into the technical architecture and the differences are stark—revealing fundamentally different bets about what matters most and what can ship today versus what needs to be built right the first time.
ACP: Ship it fast, fix it in production
The Agentic Commerce Protocol is pragmatic infrastructure designed to get merchants selling through ChatGPT quickly. The spec covers product discovery, checkout APIs, and payment flows with OpenAPI specifications, JSON schemas, and reference implementations.
The value proposition for merchants is straightforward: use your existing systems, keep your customer relationships, tap into ChatGPT's user base. If you're already on Stripe, enabling basic agent payments can require "as little as one line of code"—Stripe's own phrasing for existing merchants enabling the feature.
That claim is technically accurate for the specific case of existing Stripe merchants adding a feature flag to enable Stripe Shared Payment Tokens (SPT). For everyone else, there's real work: implementing REST endpoints, webhooks for order events, product feed specifications, and integration with a payment service provider supporting the Delegated Payment Spec. Stripe's SPT is currently the only documented option for the concrete "how" of ACP payments.
ACP's spec is broad—supporting subscriptions, async purchases, multi-merchant carts—but its shipping path is narrow: single-item Etsy purchases for U.S. users today, Shopify "soon," with cards via Stripe's Shared Payment Token. That's not a criticism—it's exactly how standards get real—but it's a far cry from "agents buying anything, anywhere." Multi-item carts and broader geographies are explicitly on OpenAI's roadmap as future work.
This is classic move-fast-and-iterate: ship a minimum viable version, learn from production traffic, evolve the spec based on what breaks. The bet is that production deployment—even with severe limitations—teaches you things specifications can't.
AP2: Build the trust layer first
Google's Agent Payments Protocol takes a different path. Where ACP offers shortcuts for quick adoption, AP2 is building cryptographic infrastructure for verifiable trust.
The core mechanism is Mandates—tamper-proof, cryptographically-signed contracts that create an audit trail from initial intent to final payment. AP2's specification defines three types of these immutable JSON blobs that serve as dispute evidence:
Intent Mandates capture the conditions under which an agent can act. "Buy concert tickets the moment they go on sale, under $200, seats together" becomes a cryptographically signed contract specifying exact constraints.
Cart Mandates capture real-time approval. When you confirm a purchase, both you and the merchant sign it—creating non-repudiable proof of what was bought at what price.
Payment Mandates are minimal credentials shared with payment networks, signaling agent involvement and user presence to issuers.
This mandate chain answers authorization, authenticity, and accountability questions with cryptographic proofs rather than policy promises. It's explicitly designed for both "human-present" (you're actively shopping) and "human-not-present" scenarios (your agent executes a pre-authorized purchase autonomously).
AP2 is positioned to sit alongside interoperability efforts like Google's Agent-to-Agent protocol and Anthropic's Model Context Protocol, rather than hard-depending on them. There's an x402 extension for stablecoin payments, developed with Coinbase, the Ethereum Foundation, and others.
AP2 chooses cryptographic certainty over speed: a signed mandate at each hop that regulators will love and engineers will curse—until someone publishes a latency budget.
The catch? As VentureBeat reported: "Consumers cannot use AP2-based payments today in any publicly known, real-world product or service." The protocol is specification-complete with reference implementations in Python and Android.[^11] Consumer products are still months away, minimum.
What you're actually signing up for
Both companies pitch easy integration. The reality is considerably messier.
The documented "one line of code" for ACP is real—if you're an existing Stripe merchant enabling a specific feature. For new implementations, expect weeks of development: checkout API endpoints, product feed management, webhook infrastructure, payment provider integration, fraud detection logic, and error handling for dozens of edge cases.
AP2's barrier is higher. Because it's designed to work across payment rails, you're not locked to Stripe. But you're responsible for credential and mandate infrastructure: issuing verifiable credentials, signature verification, cryptographic key management, audit logging, and the role-based architecture that keeps PCI data properly segmented.
And both protocols face the same brutal reality: the hard parts aren't API wiring.
Identity and credential bootstrapping: How do merchants and agents trust credential issuers? This requires governance frameworks, audits, and potentially regulatory oversight. It's a chicken-and-egg problem where early adopters need trust infrastructure that doesn't exist yet.
Agent drift and hallucinations: How do you ensure agents don't exceed their mandates? What happens when an agent misinterprets "running shoes under $100" and tries to buy 100 pairs? The protocols define constraints, but enforcing them across non-deterministic AI systems is unsolved.
Legacy payment system integration: Real-world commerce runs on decades-old infrastructure with arcane rules. 3D Secure authentication, PCI-DSS compliance, network-specific fraud rules, chargebacks, KYC/AML requirements—all of this assumes human oversight. Retrofitting it for autonomous agents is not a spec problem; it's a political negotiation with entrenched financial institutions.
Dispute resolution: When your agent buys the wrong thing, who bears the loss? The protocols create audit trails, but they don't define liability frameworks. That requires contracts, insurance, and legal precedent that doesn't exist yet.
Regulatory compliance: What happens when EU consumer protection law collides with autonomous agent purchases? What about GDPR's requirements around automated decision-making? Which jurisdiction's laws apply when an agent shops across borders?
For proof-of-concept work using reference implementations, either protocol might take weeks to months. For production systems handling real money at scale? Industry analysts estimate hundreds of developer-months—and that's just the technical work, not the legal and compliance frameworks.
The payment rail reality check
ACP is designed to work across processors, but today's live path is Stripe's Shared Payment Token over traditional card rails.[^7] There's no public ACP crypto-rail equivalent to AP2's x402 today.[^9] AP2 explicitly supports cryptocurrency via its x402 extension and is architected to handle cards, real-time bank transfers, and stablecoins.
This isn't a minor detail. It reflects different philosophies about what needs to ship now versus what needs to be architecturally possible later. ACP is optimized for the payment rails that matter today—credit and debit cards processed through established providers. AP2 is architected for a future where stablecoins and real-time bank transfers might dominate.
Calling both "payment-agnostic" conflates specification flexibility with current capability. Payment-agnostic is a heavy design constraint that imposes specific architectural choices around credential management and risk handling. ACP's current implementation is firmly in traditional card territory.
Cryptographic overhead nobody's talking about
AP2's mandate chain requires cryptographic operations at every step: signing intent mandates, verifying cart mandates, generating payment mandates, and validating the entire chain. In high-volume commerce systems processing thousands of transactions per second, this overhead could be brutal.
The protocol documentation doesn't address performance characteristics—no published latency budgets, no throughput benchmarks, no discussion of cryptographic acceleration strategies. What's the latency penalty for mandate verification? How do you cache verification results without compromising security? What happens when cryptographic operations fail mid-transaction?
These aren't hypothetical concerns. Payment systems are built on millisecond-scale latency budgets. Adding cryptographic verification to every step could easily blow through those budgets, forcing architectural tradeoffs between security and performance that aren't discussed in the specifications. This is editorial analysis—neither protocol has published performance numbers—but it's the kind of reality check that will matter when these systems face production load.
The liability minefield
Both protocols create audit trails. Neither defines who actually bears risk when things go wrong.
Google's announcement frames AP2 around "authorization, authenticity, accountability," but stops short of assigning liability. ACP and Stripe materials similarly focus on integration mechanics rather than liability governance. If an agent buys something illegal or violates platform policies, who's liable: the user who gave vague instructions, the AI company whose model misinterpreted them, the merchant who accepted the order, or the payment processor who facilitated it?
If an agent's credentials are compromised and used for fraud, what's the dispute resolution path? Traditional payment fraud has decades of legal precedent and chargeback mechanisms. Agent fraud is entirely novel.
The protocols treat liability as someone else's problem—a contract layer to be figured out later. But liability is the actual hard part. Financial institutions won't process agent payments at scale without clear liability frameworks. Merchants won't accept agent orders without fraud protection that accounts for non-deterministic AI behavior. Users won't trust agents with purchasing authority if they're on the hook for every hallucination.
Why the "open standard" framing is misleading
Both protocols are described as open-source and neutral. ACP's GitHub repository carries an Apache 2.0 license. AP2 is similarly open-licensed. That's technically true—specifications are public and anyone can implement them.
But "open standard" conflates specification transparency with practical accessibility.
ACP's implementation path is heavily Stripe-dependent. The first-class integration path, the reference implementation, the Shared Payment Token infrastructure—it's all Stripe. You can theoretically implement ACP with other payment processors, but you're on your own for credential management and merchant onboarding.
AP2's openness is more genuine but comes with a different constraint: you need to build or integrate credential infrastructure that doesn't exist yet. The protocol is open, but the trust networks required to make it work are not.
In practice, "open standard" often means "open spec with proprietary implementation bottlenecks."
Network effects and the winner-take-most dynamic
Payments are winner-take-most. Merchants won't lovingly maintain two agent protocols. Either ACP's head start or AP2's coalition will harden into the default, and the other will be legacy glue.
Once one protocol becomes dominant among merchants, agents, and card networks, switching costs become prohibitive. Merchants are exhausted by supporting multiple payment methods; they're not enthusiastic about supporting multiple agent payment protocols. Card networks want a single set of rules for agent transactions. AI platforms want to integrate once, not maintain parallel implementations.
Payment standards exhibit stronger winner-take-most dynamics than most protocol domains. This isn't a world where both protocols coexist peacefully serving different niches. It's more likely one wins decisively and the other fades, or—worse—they fragment the ecosystem and create painful integration overhead that slows adoption of agentic commerce entirely.
What happens when this goes live at scale
Neither protocol has faced real-world adversarial conditions yet. ACP's Etsy integration is live but tiny—single items, limited merchants, U.S. only. AP2 has zero production deployment.
Wait until fraud rings start exploiting agent behavior. Wait until agents trigger regulatory violations across jurisdictions. Wait until high-profile failures—agents buying restricted items, executing fraudulent transactions, making purchases that violate sanctions—create PR nightmares and congressional hearings.
The protocols are optimistic infrastructure for a world that doesn't quite exist yet. They assume agents will behave reasonably, that merchants will adopt new risk models, that regulators will accept autonomous commerce, and that users will trust AI with purchasing authority.
Those are enormous assumptions.
The honest timeline
OpenAI has live integration with severe limitations. Expanding to multi-item carts, international merchants, and multiple payment processors will take quarters, not weeks. Each expansion surfaces new edge cases that require protocol revisions.
Google has a complete specification and zero products. Launching consumer-facing AP2 integration requires not just code but trust infrastructure, merchant onboarding, payment network agreements, and regulatory clarity. That's 2026 at the earliest for meaningful deployment.
The "coming soon" framing for Shopify integration is marketing until it ships. Multiple outlets echo the claim, but deployment timelines remain vague.
What this actually means
Both protocols are ambitious bets that the infrastructure for autonomous commerce needs to be built now, before use cases fully crystallize. That's either visionary or premature depending on how quickly AI agents become capable enough to handle purchasing decisions reliably.
The optimistic case: one protocol wins, becomes widely adopted, and unlocks genuinely novel commerce patterns—agents negotiating bulk purchases, assembling multi-vendor carts, executing complex delegated transactions. Commerce becomes more efficient, more personalized, and less friction-filled.
The realistic case: both protocols struggle with adoption because the trust infrastructure, liability frameworks, and regulatory clarity don't exist yet. Merchants wait for proof of ROI before investing in integration. Payment networks move cautiously because fraud risks are unknown. Regulators slow-walk approval pending consumer protection clarity.
The pessimistic case: fragmentation. ACP and AP2 split the ecosystem, creating integration overhead for merchants and confusion for users. The protocols evolve incompatibly. AI platforms build proprietary extensions. We end up with exactly the fragmented landscape both protocols claim to prevent.
The agents are coming, eventually. Whether they're transacting through standardized protocols or proprietary systems built by whoever moves fastest—that's still very much in play.
And the technical debt being accumulated in the rush to ship? That's coming due regardless.
Jargon decoder
Intent Mandate: Cryptographically signed contract capturing user's initial request and conditions for agent action (AP2)
Cart Mandate: Non-repudiable proof of specific items and prices approved for purchase (AP2)
Payment Mandate: Minimal credential shared with payment networks signaling agent involvement (AP2)
Shared Payment Token (SPT): Stripe's mechanism for securely passing payment credentials through AI agents (ACP)
Delegated Payment Spec: ACP's specification for how payment processors can enable agent-initiated payments
Unlock the Future of Business with AI
Dive into our immersive workshops and equip your team with the tools and knowledge to lead in the AI era.
