ACP and UCP organize agent-to-merchant commerce, AP2 addresses user intent and payment authorization, and Mastercard Agent Pay supplies network identity and payment capabilities. They are not interchangeable checkout APIs. Choose by use case: discovery and checkout, cross-surface commerce, authorization evidence, or payment-network execution. A production design may use multiple layers.
Tech
ACP and UCP organize agent-to-merchant commerce, AP2 addresses user intent and payment authorization, and Mastercard Agent Pay supplies network identity and payment capabilities. They are not interchangeable checkout APIs. Choose by use case: discovery and checkout, cross-surface commerce, authorization evidence, or payment-network execution. A production design may use multiple layers.
Reviewed July 30, 2026: These specifications and commercial programs are developing quickly. Capabilities, participant availability, payment rails, geographic coverage, and merchant onboarding requirements must be rechecked in the linked official material before implementation.
At a glance
• ACP connects agents and merchants for product discovery and purchase flows, including ChatGPT commerce.
• UCP defines commerce capabilities and discovery across consumer surfaces, businesses, and payment providers.
• AP2 focuses on trusted agent-led payment authorization through verifiable intent and mandates.
• Mastercard Agent Pay applies payment-network credentials, controls, authentication, and settlement capabilities.
• Supporting a protocol does not automatically make a merchant eligible for a vendor’s distribution surface.
• Existing payment, fraud, refund, tax, privacy, and consumer-protection duties still apply.
The architecture: commerce is not the same as payment
An agentic purchase has several stages: discover a product, construct a cart, calculate fulfillment and tax, collect user approval, authorize a payment instrument, execute payment, settle funds, and support refunds or disputes. The four names in this comparison cover different portions of that chain.
OpenAI describes the Agentic Commerce Protocol as the language through which agents and businesses complete purchases for users. Its initial public use powered Instant Checkout, and OpenAI later expanded ACP for richer product discovery. This makes ACP relevant to merchants that want products and checkout functions represented inside compatible agent experiences.
Google describes the Universal Commerce Protocol as an open-source standard for commerce journeys across consumer surfaces, businesses, and payment providers. UCP publishes commerce capabilities and supports transport through APIs, A2A, or MCP. It can work with AP2 for payment. That separation is important: UCP can describe checkout and fulfillment without becoming the payment rail itself.
Google’s Agent Payments Protocol addresses the trust gap between an agent’s instruction and a payment. Its mandate model is intended to provide cryptographically verifiable evidence of what the user authorized, including scenarios where the user is present and where an agent acts later under constraints.
Mastercard Agent Pay for Machines is part of Mastercard’s Agent Pay program. Mastercard describes credentialing, permissioning, transaction, and multi-rail settlement capabilities for machine-driven transactions. It is a commercial network initiative and ecosystem, not merely a neutral message schema that can be substituted for ACP, UCP, or AP2.
How each mechanism works
ACP: connect an agent surface to merchant commerce
ACP gives the agent and merchant a shared representation for the commerce interaction. The merchant remains responsible for its products, fulfillment, and business rules while the agent surface can present discovery and checkout to the user. The relevant integration question is not only protocol support; it is which ACP capabilities a specific surface exposes and how a merchant becomes available there.
ACP is therefore strongest as a surface-to-merchant commerce contract. It should not be treated as a universal payment credential or proof that every wallet and payment service can execute the transaction.
UCP: advertise modular commerce capabilities
UCP uses capability discovery so a business can indicate which commerce functions and extensions it supports. The official explanation shows shopping services, fulfillment extensions, and payment handlers as distinct components. Businesses can preserve existing infrastructure while exposing standardized capabilities to compatible surfaces.
This modularity helps when a merchant wants a broader commerce interface rather than an integration designed around one assistant. Its value still depends on implementer adoption, compatible versions, and the exact extensions both sides support.
AP2: bind payment to user intent
AP2 is concerned with authorization evidence. A user-present flow can capture approval for a specific purchase. A delegated flow needs a mandate describing constraints under which the agent may transact later. The payment provider can use that evidence in risk, authorization, and accountability decisions.
AP2 does not remove the need for merchant checkout, payment credentials, fraud controls, or settlement. It adds a trust artifact to the payment path.
Mastercard Agent Pay: execute within network controls
Mastercard’s program connects agent recognition and permissioning to payment-network operation. Its official materials describe tokenized credentials and mechanisms intended to distinguish agent-led transactions. Agent Pay for Machines extends the model toward high-frequency and low-value machine transactions across supported rails.
Adoption depends on participating issuers, acquirers, providers, markets, and use cases. A press release or pilot is not evidence that every Mastercard acceptance path supports the same agentic flow.
Decision table
Primary need: Sell inside a compatible ChatGPT shopping experience; Best starting point: ACP; Why: Connects product and checkout interactions to that surface; Boundary to verify: Merchant eligibility, region, catalog, and supported flow
Primary need: Expose commerce capabilities across multiple agent surfaces; Best starting point: UCP; Why: Modular discovery and checkout capability model; Boundary to verify: Version and extension support on both sides
Primary need: Prove what a user authorized an agent to purchase; Best starting point: AP2; Why: Mandates focus on intent and authorization evidence; Boundary to verify: Wallet, credential, and payment-provider support
Primary need: Use Mastercard identity, controls, and settlement; Best starting point: Mastercard Agent Pay; Why: Connects agent activity to network capabilities; Boundary to verify: Participant, issuer, acquirer, rail, and market availability
Primary need: Build a complete agentic purchase; Best starting point: Combination; Why: Commerce, intent, payment, and settlement are separate layers; Boundary to verify: Integration ownership and evidence handoff
Primary need: Automate internal supplier payments; Best starting point: Existing treasury stack first; Why: Enterprise approvals may matter more than consumer checkout protocols; Boundary to verify: Bank, ERP, procurement, and segregation-of-duty controls
Security and governance
Treat an agent payment as a high-consequence action. The model should not hold raw card data, bank credentials, private keys, bearer tokens, or wallet secrets. A payment service should attach protected credentials after policy checks.
Bind approval to the material terms: merchant, amount or maximum, currency, product, quantity, recurrence, delivery destination, timing, and substitution policy. A generic statement such as “buy supplies” is not sufficient evidence for an unlimited transaction.
Implement controls for:
• spending limits per transaction, day, merchant, category, and agent;
• allowlisted merchants and prohibited product categories;
• strong user confirmation for new payees, subscriptions, or changed totals;
• immutable correlation between mandate, cart, authorization, capture, and refund;
• idempotency so retries do not create duplicate orders or charges;
• fraud, sanctions, tax, privacy, chargeback, and consumer-rights processes;
• revocation of credentials and mandates when an agent or owner is disabled;
• separation between the model’s recommendation and the payment policy decision.
Do not infer liability allocation from technical compatibility. Contracts among the merchant, agent surface, wallet, payment provider, issuer, and user determine operational and legal responsibility.
Implementation checklist
• [ ] Define whether the use case is discovery, checkout, delegated buying, or machine payment.
• [ ] Map every party: user, agent, surface, merchant, payment provider, issuer, acquirer, and settlement rail.
• [ ] Select the commerce protocol independently from the payment authorization mechanism.
• [ ] Confirm supported protocol versions and extensions on both endpoints.
• [ ] Document enrollment, certification, regional, and merchant-eligibility requirements.
• [ ] Keep payment credentials outside prompts and model-visible tool output.
• [ ] Define an exact mandate schema and user confirmation experience.
• [ ] Add amount, merchant, category, recurrence, and time constraints.
• [ ] Require a fresh approval when material cart terms change.
• [ ] Implement idempotency, timeout recovery, cancellation, refund, and dispute handling.
• [ ] Correlate intent, mandate, order, payment, capture, settlement, and refund events.
• [ ] Test replay, prompt injection, altered totals, unavailable inventory, and duplicate execution.
• [ ] Assign owners for fraud operations, customer support, security incidents, and protocol upgrades.
• [ ] Launch with a narrow merchant and transaction boundary before expanding autonomy.
Limitations and change risk
The market uses “protocol,” “standard,” “program,” and “platform” inconsistently. These four mechanisms have different governance, integration, and availability models. Announced features may remain limited to selected partners or products.
Versioned schemas and extension points can change. Commerce surfaces can also change ranking, merchant onboarding, or supported categories without changing the underlying protocol. Payment-network support can vary by issuer and geography. Build conformance tests and retain a conventional checkout fallback.
This comparison does not assess fees because official pricing and commercial terms vary by participant and are not consistently public. It also does not establish regulatory suitability. Payments counsel and the relevant providers should review the target markets and flows.
For the broader operating model that connects these payment controls to business processes, read What is a business AI operator?.
FAQs
Is UCP a replacement for AP2?
No. UCP defines commerce capabilities and interactions; AP2 focuses on proving and carrying payment authorization intent. Google explicitly positions them as compatible layers.
Are ACP and UCP interoperable?
Do not assume so. Both address agentic commerce, but they have different schemas, governance, capability models, and surface integrations. A merchant may need adapters or separate implementations.
Does AP2 move money?
AP2 provides a framework for trusted authorization and mandate evidence. Payment credentials, provider authorization, clearing, settlement, refunds, and disputes still require payment infrastructure.
Is Mastercard Agent Pay an open protocol?
It is a Mastercard program and network capability with participating ecosystem providers. Evaluate its published mechanisms and commercial availability separately from open commerce specifications.
Can an agent pay without asking every time?
Only within an explicit, revocable mandate with narrow limits and a supported legal and payment model. New merchants, changed totals, subscriptions, or high-risk categories should trigger stronger confirmation.
Get a 20-Minute AI Workflow Audit
AI Operator can map the commerce surface, mandate, credentials, controls, evidence, failure paths, and ownership for one real transaction before an integration commitment.