ACP vs AP2 vs UCP: Which Agentic Payment Protocols Should a PSP Support?

AI agents are becoming a new way for consumers to discover products, compare offers and authorize purchases. For payment service providers (PSPs), the challenge is no longer simply connecting a merchant to a checkout page. It is determining how to accept payment instructions from an AI-driven commerce flow while preserving authorization, security and control over payment processing.

Three protocols are shaping this transition: Agentic Commerce Protocol (ACP), Agent Payments Protocol (AP2) and Universal Commerce Protocol (UCP).

They are not three interchangeable payment systems.

ACP connects AI shopping experiences with merchants and payment providers. UCP standardizes broader commerce interactions, including checkout and payment-method negotiation. AP2 addresses a different problem: proving that an AI agent is authorized to complete a particular purchase.

For PSPs, the objective should not be to predict which protocol will dominate. It should be to determine which interfaces customers need and how to support them without rebuilding the underlying payment infrastructure.

What Are Agentic Payment Protocols?

Agentic payment protocols define how AI agents, merchants, credential providers and payment infrastructure exchange information during an AI-assisted or delegated purchase.

In traditional ecommerce, a customer selects a product, enters payment details and confirms the transaction.

In agentic commerce, the customer may instead instruct an AI agent to find a product and arrange a purchase within specified conditions.

For example:

A customer asks an AI assistant to purchase replacement office equipment from an approved supplier, provided the total remains below £500.

The agent may search available products, compare offers and prepare a checkout. Depending on the authorization model, the customer either approves the final purchase or delegates authority for the agent to act within predefined limits.

The payment infrastructure must still establish whether the transaction is permitted.

A secure agentic payment flow therefore needs to address several questions:

• Who is the AI agent, and can its identity be verified?
• What did the customer authorize the agent to purchase?
• Does the final transaction comply with that authorization?
• Which payment credential can be used?
• Which PSP or acquirer will process the payment?
• How will the transaction be recorded, reconciled and disputed if necessary?

ACP, UCP and AP2 approach different parts of these requirements.

ACP vs AP2 vs UCP: Key Differences

The key distinction: ACP and UCP define ways for agents to interact with commerce infrastructure. AP2 provides mechanisms for verifying the authority behind an agent-initiated payment.

AP2 can complement UCP, rather than replace it.

A PSP may therefore encounter multiple protocols in a single payment journey.

1. Agentic Commerce Protocol (ACP): Connecting AI Shopping to Payments

The Agentic Commerce Protocol (ACP) is an open standard maintained by OpenAI and Stripe.

It provides specifications for connecting AI agents, merchants and payment providers across commerce interactions.

ACP includes models for checkout sessions, payment handoff, merchant capabilities and other commerce operations.

How ACP works

In a supported agentic checkout flow:

1. An AI agent helps a customer select products.
2. The agent communicates with the merchant's commerce interface.
3. The merchant provides authoritative checkout information, including applicable prices and fulfillment details.
4. An authorized payment credential is obtained through a supported payment flow.
5. The merchant completes payment processing using its existing PSP relationship.

The agent facilitates the interaction. It does not automatically become the merchant, acquirer or settlement provider.

Why ACP matters to PSPs

ACP introduces an additional commerce interface through which payment instructions and credentials may reach merchants.

PSPs evaluating ACP should focus on whether their infrastructure can support:

• Compatible delegated payment tokens and credential exchange.
• Merchant checkout integration.
• Authentication and authorization requirements.
• Idempotent payment processing.
• Payment status, refund and failure handling.

A critical distinction is that supporting tokenized payments does not automatically make a PSP fully ACP-compatible. Protocol-specific interfaces and credential requirements must also be implemented.

ACP's changing role in ChatGPT commerce

ACP originally received attention for supporting checkout within AI conversations.

However, OpenAI expanded its emphasis toward product discovery in March 2026 and introduced greater flexibility for merchants to use their existing checkout experiences.

This matters for PSPs because ACP adoption should not be based on the assumption that every ChatGPT purchase will take place inside a native conversational checkout.

The commercial opportunity includes merchant discovery, conversion and connections between AI shopping experiences and existing payment systems.

When should a PSP prioritize ACP?

When its merchants are actively pursuing AI-driven shopping experiences that use ACP, or when a specific platform integration requires ACP-compatible payment handling.

2. Universal Commerce Protocol (UCP): A Common Language for Agentic Commerce

The Universal Commerce Protocol (UCP) is an open standard developed with participation from Google, Shopify and other commerce ecosystem companies.

Its objective is broader than processing an individual payment.

UCP provides common structures for communicating commerce capabilities between businesses, AI platforms, payment providers and credential providers.

How UCP works

A business can publish machine-readable information describing the commerce capabilities it supports.

This allows a compatible platform to discover supported operations and determine how to interact with the business.

For example, a merchant may advertise capabilities for checkout, order management and identity linking.

The payment portion uses payment handlers that describe how supported payment instruments are obtained and processed.

A simplified flow looks like this:

1. An AI platform discovers the merchant's supported commerce capabilities.
2. The platform establishes a checkout session.
3. The merchant communicates available payment handlers.
4. A compatible credential is obtained through the appropriate provider.
5. The merchant submits the payment through its existing PSP integration.
6. Order and payment results are returned through the relevant commerce interfaces.

Under UCP, the business remains the merchant of record.

UCP does not automatically transfer merchant responsibilities for payment acceptance, refunds or disputes to the AI platform.

What UCP changes for PSPs

UCP separates commerce coordination from the underlying payment processor.

That distinction can make it easier for merchants to expose payment options through different AI interfaces without replacing their acquiring relationships.

A PSP considering UCP compatibility should evaluate:

• Payment-handler specifications and credential formats.
• Token exchange between platforms and payment providers.
• Supported currencies, payment methods and merchant configurations.
• Checkout state and payment confirmation.
• Consistent transaction identifiers across commerce and processing systems.

A PSP does not necessarily need to build a complete UCP storefront. Its relevant role may be to support the payment-handler and processing requirements used by merchants and platforms.

Does UCP allow fully autonomous payments?

Not automatically.

Under the UCP checkout specification, checkout normally requires completion through a trusted user interface unless the relevant AP2 mandate extension is supported.

That distinction matters: a standardized checkout interface is not, by itself, proof that an AI agent has permission to spend.

For autonomous purchasing, the payment flow needs an appropriate authorization mechanism.

When should a PSP prioritize UCP?

When merchants need interoperable commerce integrations across AI platforms, or when their selected commerce systems require UCP-compatible payment handlers.

3. Agent Payments Protocol (AP2): Proving an AI Agent Is Authorized to Pay

The Agent Payments Protocol (AP2) addresses one of the most important challenges in agentic commerce: verifying delegated payment authority.

An AI agent's ability to create a payment instruction does not prove that the customer authorized the purchase.

AP2 introduces cryptographically verifiable mandates that help participating systems establish what the customer approved and whether a proposed transaction matches that authorization.

How AP2 works

In the AP2 v0.2 specification, two principal mandate types are defined.

Checkout Mandate

Provides evidence that the agent is authorized to complete a particular checkout. It is linked to merchant-signed checkout information.

Payment Mandate

Provides evidence that the agent is authorized to pay for that checkout using the relevant payment instrument.

The protocol supports two broad scenarios.

Human-present payment: The customer reviews the finalized purchase and explicitly authorizes it.

Human-not-present payment: The customer authorizes constraints in advance, and the agent subsequently completes an eligible purchase within those limits.

In both cases, the parties responsible for verification must validate the applicable mandates before proceeding.

AP2 also defines receipts that can help establish an evidence trail for disputes.

Why AP2 matters to PSPs

Traditional payment risk systems commonly use signals associated with human interaction.

An AI agent may complete a transaction without typing payment details, moving a mouse or interacting with the checkout like a conventional shopper.

That creates new challenges for identifying legitimate transactions and detecting unauthorized activity.

AP2 is designed to provide verifiable authorization context rather than relying solely on behavioral assumptions.

For PSPs participating in AP2-enabled flows, relevant implementation requirements may include:

• Validating applicable payment mandates.
• Checking that payment credentials are appropriately scoped.
• Confirming that the transaction matches the authorized checkout.
• Handling expired, invalid or rejected authorization evidence.
• Retaining necessary records for audit and disputes.

The exact verification responsibilities depend on the participant's role in the transaction.

AP2 does not replace a PSP, payment gateway or acquiring bank. Nor does implementing AP2 automatically satisfy every applicable card-scheme authentication or regulatory requirement.

When should a PSP prioritize AP2?

When its merchants, payment partners or agentic commerce integrations need verifiable delegated authorization, particularly for purchases completed without the customer approving each transaction individually.

Can ACP, AP2 and UCP Work Together?

Yes, although their compatibility and use depend on the specific implementation.

The protocols address different concerns across the transaction lifecycle.

A simplified architecture can be understood as three layers:

For example, a merchant could use UCP for checkout interoperability and AP2 to verify the customer's delegated authorization.

Once the payment is permitted, the merchant's established payment infrastructure processes the transaction.

ACP may serve as another commerce integration path for merchants and AI platforms that support it.

Not every transaction requires all three protocols, and protocol support should not be interpreted as universal interoperability without integration testing.

Which Agentic Payment Protocol Should a PSP Support First?

There is no universally correct implementation order.

The priority should follow the needs of the PSP's merchants and the agentic commerce environments they want to reach.

The practical recommendation is to avoid building a separate payment-processing system for every emerging agentic interface.

Instead, distinguish the protocol-specific requirements from the underlying payment functions that remain necessary regardless of the interface.

Those functions include authorization, fraud controls, routing, transaction state management, refunds, reconciliation and reporting.

This approach makes future integrations easier to evaluate without assuming that all protocols will become market standards.

Five Payment Infrastructure Requirements for Agentic Commerce

Supporting a protocol is only one part of preparing for AI-initiated payments.

A PSP must also consider whether its infrastructure can process those transactions securely and consistently.

1. Payment credential management

Agentic commerce often depends on scoped or tokenized payment credentials.

However, not all tokens are interchangeable or portable across payment providers.

A PSP should distinguish between processor-specific tokens, network tokens and credentials issued for a particular delegated payment.

It should also verify the restrictions and permissions associated with each credential before using it.

2. Agent identity and authorization

A payment instruction should not be accepted merely because it comes from an AI application.

The appropriate participants must establish the identity or trust status of the agent, validate any required authorization evidence and confirm the allowed transaction parameters.

Authorization checks must be enforced by deterministic systems rather than left to an AI model's interpretation.

3. Fraud and transaction risk controls

An agent-initiated payment may generate different behavioral signals from a human checkout.

Risk systems therefore need to evaluate available agent identity, authorization and transaction context while continuing to apply relevant merchant and payment-method controls.

Verified agent identity is useful, but it is not proof that every subsequent transaction is legitimate.

4. Payment routing and failure handling

Agentic commerce does not eliminate authorization declines, processor outages or differences in payment-method availability.

Payment orchestration can help merchants manage multiple payment connections and supported fallback routes.

However, a declined transaction should only be retried when the decline reason, scheme rules, credential restrictions and applicable authorization permit it.

Idempotency and transaction-state controls are essential to avoid duplicate processing.

5. Reconciliation, audit and dispute evidence

When a payment is initiated through an AI agent, the PSP needs to maintain a reliable connection between the payment instruction, processing result and any relevant authorization evidence.

Transaction identifiers, payment statuses, mandate references and reconciliation records should remain consistent across participating systems.

Where an authorization protocol provides signed evidence, that evidence may assist dispute investigation. It does not guarantee that a chargeback will be resolved in the merchant's favour.

These requirements are relevant even when the commerce interface or agentic protocol changes.

Where Payment Orchestration Fits into Agentic Commerce

ACP, UCP and AP2 do not replace the infrastructure responsible for executing and managing payments.

A merchant still needs payment processing connections, supported credentials, fraud controls, reporting and reconciliation.

A payment orchestration platform provides a technology layer for managing transactions across multiple payment providers.

That makes orchestration relevant to agentic commerce for a practical reason: the interface that initiates a transaction can change without requiring a completely separate payment-processing architecture for every AI platform.

For a PSP evaluating future protocol integrations, a modular architecture can separate:

• Agentic commerce interfaces and protocol adapters.
• Authorization and credential verification.
• Core payment processing and orchestration.
• Merchant reporting, reconciliation and dispute workflows.

The separation does not remove the need for protocol-specific engineering. It helps limit how much of the existing payment infrastructure must change when new interfaces are introduced.

How Payneteasy Fits into an Agentic Payments Strategy

Payneteasy provides payment technology for PSPs, fintech companies, banks and other businesses operating payment infrastructure.

Its payment orchestration platform connects payment providers through a common integration layer and supports capabilities such as transaction routing, cascading, risk management, reporting and reconciliation.

The platform offers access to more than 1,000 pre-built payment-related integrations.

For organisations building branded payment services, Payneteasy also offers white-label payment gateway technology.

In an agentic commerce architecture, these underlying processing capabilities remain relevant regardless of whether the merchant introduces an ACP or UCP interface.

Protocol-specific payment handlers, mandate verification and credential integrations would still need to be assessed and implemented where required.

Payneteasy's existing MCP functionality addresses a separate use case: allowing AI tools to inspect operational payment data.

It does not itself authorize agent-initiated purchases or provide ACP, AP2 or UCP payment execution.

The distinction matters for PSPs planning their infrastructure: AI access to payment information and AI-authorized payment execution are different capabilities with different security requirements.

The Future of Agentic Payments: Interoperability Before Protocol Lock-In

Agentic commerce is introducing new ways for customers to interact with merchants, but its payment infrastructure is still evolving.

ACP addresses AI-driven commerce interactions. UCP provides a broader framework for commerce interoperability. AP2 introduces mechanisms for proving delegated payment authorization.

These approaches can coexist, and their adoption will depend on merchant requirements, platform participation, payment methods and security models.

For PSPs, the most useful strategy is not necessarily to implement every protocol immediately.

It is to identify actual merchant demand, support the appropriate interfaces and preserve a reliable payment-processing foundation underneath them.

The long-term advantage comes from being able to accommodate new agentic commerce channels without rebuilding the payment stack each time.