Where Agentic Commerce Started: Payments Within ChatGPT’s Interface

Agentic commerce entered broad public awareness with OpenAI’s introduction of the “Instant Checkout“, an in chat shopping feature within ChatGPT, for US users in September 2025. This marked the first large-scale deployment of AI driven purchasing flows executed directly by autonomous agents.

Agentic commerce refers to a new model of digital commerce in which AI agents perform product discovery, market evaluation and purchasing actions on behalf of users, based on predefined preferences and constraints. The level of an agent’s autonomy may vary; however, users are typically required to approve a specific product at a defined price before the agent proceeds with the purchase flow, with final approval given at the stage where funds are to be withdrawn from the selected payment method. At the infrastructure layer, this shifts the problem from ‘checkout UX’ to agentic payments: how an agent proves authorization, identity, and intent while operating across multiple payment rails.

According to research by McKinsey, by 2030:

• The US B2C retail market alone could generate up to USD 1 trillion in revenue orchestrated through agentic commerce.
• Global projections range between USD 3 trillion and USD 5 trillion.

Scope: The Agent-to-Agent Payment Infrastructure Layer

Agentic commerce involves a broad range of stakeholders, including users, AI system providers, merchants, payment service providers and infrastructure vendors. In the scheme below, you can see the generalised view of the applicable stakeholders involved in the agentic commerce, although there can always be different approaches and structures:

In this article we focus exclusively on the payment and technical infrastructure layer supporting agent-to-agent transactions. Other stakeholders and layers are referenced only to the extent necessary to explain how the infrastructure operates within the broader ecosystem.

Agentic Payment Protocols: ACP (OpenAI/Stripe) and AP2 (Google)

OpenAI + Stripe: Agentic Commerce Protocol (ACP)

Following the launch of the “Instant Checkout”, OpenAI has also introduced the Agentic Commerce Protocol (ACP), developed in collaboration with Stripe. This protocol supports the in chat shopping experience and is designed to enable secure and interoperable agent initiated payments. Importantly, Stripe does not need to be the payment processor in all cases, as the protocol is designed to support interoperability with other payment processors.

In parallel with OpenAI and Stripe, other major industry players have begun developing their own agent oriented payment frameworks.

Google: Agent Payments Protocol (AP2)

The Agent Payments Protocol (AP2) by Google is a payment agnostic framework supporting multiple payment rails, ranging “from credit and debit cards to stablecoins”. Its primary objective is to address challenges arising from the introduction of an intermediary agent layer, including:

• Determining whether a user has validly authorised an agent to perform a specific transaction. Example: A user may authorise an agent to buy green sneakers in size 35, but the agent could attempt to purchase red sneakers in size 43.

• Ensuring that the agent has accurately transmitted user intent to the merchant. Example: AI agents translate user instructions into purchase requests, which may introduce deviations due to the probabilistic nature of AI systems. Merchants therefore need reliable signals that the agent’s request truly reflects the user’s intent.

Emerging Startup Layers: Agent Identity, Policy Controls, and Stablecoin Rails

Beyond established industry players, agentic commerce creates significant opportunities for startups building specialised infrastructure layers. These solutions often focus on narrower but critical use cases within agent driven commerce.

Examples observed in the market include:

• An agent identity verification protocol that enables merchants to confirm they are interacting with legitimate AI agents while also verifying merchant legitimacy. A key feature is that the agent remains entirely within the AI system interface throughout the transaction.
• A platform combining smart contract based constraints for AI agents with stablecoin native payments. The system enables auditable purchase flows and integrates with existing major payment infrastructure protocols.

Legal and Regulatory Considerations for Agent-to-Agent Payments

Payment Services Licensing (Software vs Processing)

A primary regulatory consideration when building agentic payment infrastructure is payment processing, which is subject to complex licensing regimes in many jurisdictions. Licensing obligations typically arise when an entity is:

• Remitting or transferring funds.
• Executing payment transactions on behalf of users.
• Transmitting payment orders or payment data.

If a project aims to qualify as a software only provider, without triggering licensing requirements, it must ensure that:

• It does not handle or transfer user funds.
• It does not route transactions or transmit payment orders.

In practice, this means the entity develops the software but does not operate the payment flows itself.

Where an infrastructure provider does engage in payment processing activities and therefore falls within the scope of applicable licensing regimes, it becomes subject to a broad set of regulatory, operational and security requirements. At a high level, regulated payment service providers are typically required to meet obligations in the following areas:

• Authorisation and governance

Payment processing generally requires prior authorisation or registration with a competent authority. This includes requirements relating to corporate governance, internal controls, risk management frameworks and the fitness and propriety of key personnel.

• Safeguarding of funds and operational separation

Where user funds are handled, payment processors are required to segregate client funds from their own assets.

• Security and fraud prevention

Payment processors must implement technical and organisational measures to protect payment data, prevent unauthorised access and reduce fraud risks. This typically includes secure authentication mechanisms, access controls, transaction monitoring systems and incident response procedures.

• Data protection and confidentiality

Providers must comply with applicable data protection laws, ensuring lawful processing, data minimisation, confidentiality and appropriate retention policies. Particular attention is paid to breach prevention and incident handling, as data breaches involving payment data often lead to significant regulatory and financial consequences.

• Anti-money laundering (AML) and counter-terrorist financing (CTF)

Licensed payment processors are subject to AML and CTF obligations. These include customer identification and verification, collection of information about the counterparty, transaction monitoring, suspicious activity reporting and the implementation of internal compliance policies.

Crypto Payments: CASP/VASP Exposure

Where an infrastructure provider is involved in crypto asset related payment flows, compliance with applicable crypto asset service provider regulatory regimes, commonly known as CASPs or VASPs, becomes equally critical. In particular, such regimes commonly require:

• Prior authorisation or registration with the competent authority. This typically involves demonstrating adequate corporate governance, risk management and the fitness and propriety of key personnel.
• Customer due diligence and transaction monitoring, including Know-Your-Customer (KYC) procedures, assessment of the source and destination of funds, including collecting and storing this information, and ongoing AML and CTF controls.
• Safeguarding and integrity of crypto assets, including rules on custody, access controls and operational separation, where applicable.
• Security measures, including technical documentation of information and communication technology (ICT) systems and clear descriptions of security arrangements suitable for regulatory review.

Importantly, where a business operates both fiat and crypto payment flows, these regulatory regimes apply in parallel, each in relation to the relevant asset type. In practice, this may require compliance with two distinct regulatory frameworks and, depending on the structure of the services provided, the holding of separate licences or registrations for fiat payment services and crypto asset services.

Decentralised Architectures and “Substance Over Form”

An important question arising from the above analysis is whether such payment and infrastructure services could be launched in a genuinely decentralised and autonomous manner, in a way that materially reduces or removes licensing requirements. In theory, a fully decentralised architecture — such as where smart contracts operate independently, parameters are immutable, and no identifiable party retains control or influence — could limit or exclude the applicability of traditional payment services and VASP regulation. In such a model, the infrastructure itself would function as neutral software, rather than as a regulated financial service operated by a specific entity.

In practice, however, achieving a sufficient level of decentralisation is challenging. Regulatory authorities increasingly apply the principles of substance over form, focusing on who designs, controls, benefits from or can influence the system, rather than on the use of blockchain technology as such. As a result, even highly automated or partially decentralised infrastructures may still fall within regulatory scope if any party retains meaningful control, sets parameters, collects fees or facilitates asset transfers.

Security Standards: PCI DSS and Due Diligence

Even where licensing requirements are not triggered, security remains critical. Licensed payment processors are subject to extensive regulatory requirements and will expect third party software to meet comparable standards, such as those established in the Payment Services Directive 2, including:

• Procedures for filing, monitoring and restricting access to sensitive payment data.
• Comprehensive security policies supported by detailed risk assessments.
• Strong customer authentication.
• Fraud prevention and mitigation measures.

For fiat payment flows, compliance with PCI DSS is essential in practice. While not a statutory requirement, non-compliance may result in the inability to process card payments at all, as card schemes such as Visa and Mastercard condition access to their networks on adherence to PCI DSS standards.

EU Operational Resilience: Data Protection and DORA

Beyond payment regulation, data protection law plays a critical role, particularly with respect to sensitive payment data. Strong encryption, secure data handling and breach prevention measures are essential, as regulatory penalties increase significantly where breaches result in financial losses for consumers.

In addition, in the EU the Digital Operational Resilience Act (DORA) applies to payment processors and also to “ICT third-party service providers”, including software providers. DORA introduces obligations relating to:

• Information and communication technology risk management.
• Software testing.
• Cybersecurity incident reporting and response.

Conclusion

Agentic commerce is rapidly turning payments into an agent-to-agent issue: merchants and payment providers must be able to trust that an AI agent is authorised, that it accurately expresses user intent, and that the transaction can be executed securely across different rails. Protocols such as OpenAI and Stripe’s Agentic Commerce Protocol (ACP) and Google’s Agent Payments Protocol (AP2) show how the market is converging on interoperable standards for agent-initiated transactions — but technical interoperability does not remove regulatory exposure.

For infrastructure builders, the key legal question is where the product sits on the spectrum between software tooling and regulated payment processing. Licensing risk, AML/KYC and sanctions compliance, custody and safeguarding expectations, and security standards (including PCI DSS in practice for card rails) can attach quickly once a provider routes payment orders, controls funds, or meaningfully influences execution. In parallel, data protection and operational resilience obligations are becoming central design constraints — including in the EU where DORA extends into the ecosystem of critical ICT providers supporting regulated financial entities.