AP2 vs. x402: How AI Agents Handle Payment Authorization and Automated Settlement

AP2 (Agent Payments Protocol) and x402 are two payment protocols designed for AI Agent commerce. They provide infrastructure for autonomous transactions from the perspectives of payment authorization and programmatic settlement, respectively. AP2 focuses on proving that an AI Agent’s purchase has been authorized by the user, while x402 uses standardized HTTP payment interactions to allow software systems to purchase APIs, data, and other digital services on demand.

As Agent-to-Agent Commerce continues to develop, AI Agents are evolving from information lookup tools into automated systems capable of making purchases, managing subscriptions, and calling services. When an Agent begins using funds on behalf of a user or business, traditional payment processes that rely on manual clicks and confirmations face new challenges: How can the system determine whether the Agent is authorized to make a payment? How can the payment amount be limited? How can different systems complete settlement automatically?

AP2 and x402 offer two complementary approaches. This article introduces the core mechanisms, technical differences, and collaborative workflows of the two protocols, analyzes the role of stablecoins in AI Agent payments, and explores the security and compliance risks that automated transactions may involve.

Key Takeaways

• AP2 (Agent Payments Protocol) is an open protocol for AI Agent payment authorization. It focuses on whether an Agent can make payments on behalf of a user and how to verify that a transaction reflects the user’s intent.
• x402 is a programmatic payment protocol based on the HTTP 402 Payment Required status code. It allows AI Agents to automatically pay for APIs and digital services based on payment requirements returned by the server.
• AP2 and x402 address different layers: AP2 focuses on authorization and accountability verification, while x402 focuses on payment requests, credential verification, and settlement. The two protocols can be used together.
• Stablecoins provide AI Agents with a programmable form of digital payment. They are suitable for pay-per-use APIs, data services, and machine-to-machine transactions, but are not necessary for every Agent payment scenario.
• AI Agent auto-payments still require budget limits, wallet permission controls, counterparty verification, and abnormal transaction handling. Automated execution should not be treated as unlimited authorization to use funds.

What Are AP2 and x402? Why Do AI Agents Need Dedicated Payment Protocols?

AP2 and x402 both support AI Agent automated commerce, but they solve different problems. AP2 was launched in September 2025 by Google together with participants from the payments and technology industries. It aims to establish a cross-platform, payment-method-agnostic framework for Agent payment authorization. It focuses on proving that a user has authorized an Agent to make a specific purchase and enabling payment institutions to verify that authorization.

x402, meanwhile, was advanced by Coinbase and is based on the 402 Payment Required status code in the HTTP protocol. It allows websites, APIs, and other digital services to send payment requirements directly to clients. After receiving the payment information, an AI Agent can use a controlled wallet to generate payment credentials and access the relevant resource after verification and settlement are completed.

The emergence of these two protocols reflects two distinct challenges in AI Agent commerce. First, an Agent can autonomously discover products and services, but it must prove that it has received user authorization. Second, even if an Agent has payment permission, it still needs a way to interact with external services and complete payments automatically.

Traditional online payment systems generally assume that consumers will personally review products, click to confirm, and complete identity verification. An AI Agent, however, may execute tasks without the user’s real-time participation. Payment systems therefore need to determine not only whether a transaction is valid but also whether the Agent’s behavior complies with predefined permissions.

AP2 and x402 provide technical support for these two stages, respectively, but not every AI Agent payment requires both protocols.

How Does AP2 Verify AI Agent Payment Authorization?

The core of AP2 is the Mandate, a cryptographically verifiable authorization credential. It records the actions that a user has allowed an Agent to perform and the applicable restrictions, enabling merchants and payment service providers to determine whether a transaction reflects the user’s intent.

According to the AP2 v0.2 technical specification, the protocol defines two primary types of credentials: Checkout Mandate and Payment Mandate. A Checkout Mandate proves that an Agent has been authorized to purchase a specific product or service. A Payment Mandate proves that the Agent can initiate payment for the corresponding order. The two are linked through order information, reducing the risk that a payment credential will be used for another transaction.

For example, suppose a user wants an AI Agent to purchase a data service priced at no more than $50. The system can record the product category, budget, and authorization conditions in the relevant credentials. After the Agent finds a service that meets the requirements, the merchant verifies the purchase authorization, and the payment service provider then verifies the payment authorization. The transaction should proceed to the next payment stage only after the relevant conditions are satisfied.

AP2 also distinguishes between Human Present and Human Not Present transaction modes. In the former, the user can confirm the specific order during checkout. In the latter, the Agent can execute the transaction within the constraints authorized in advance. In either mode, key authorization checks must be completed through deterministic processes rather than relying solely on a large language model’s judgment.

Therefore, AP2 is not intended to replace bank cards, bank accounts, or stablecoins. Its value lies in establishing a verifiable authorization foundation for different payment methods and providing records for subsequent audits and dispute resolution.

How Does x402 Enable Automated Payments Through HTTP 402?

The core idea behind x402 is to embed the payment process directly into HTTP requests. Traditional API services typically require users to register an account, link a payment method, or purchase subscription credits in advance. x402 allows a server to return standardized payment requirements when it receives a request, after which the client completes the payment and retrieves the resource again.

According to the official x402 protocol, the typical process begins when a client sends an HTTP request to a resource server. If the resource requires payment, the server returns 402 Payment Required and provides the price, supported networks, payment assets, and other required information. The client selects a supported payment method, generates payment credentials, and submits them through an HTTP request.

The resource server then verifies the payment credentials and completes settlement through an on-chain transaction or a Facilitator—a payment verification and settlement service. A Facilitator can perform signature verification and on-chain settlement on behalf of the server, reducing the complexity of maintaining blockchain payment infrastructure. After verification and settlement succeed, the server returns the requested data or service result.

Note that different versions of x402 use different HTTP Header names and data structures. For example, earlier versions used X-PAYMENT, while newer specifications use fields such as PAYMENT-SIGNATURE. Developers therefore need to implement the specific version they use and should not directly mix interfaces from different versions.

For AI Agents, the advantage of x402 is that payment can become part of an ordinary web request. If an Agent needs to purchase paid data or call an AI model, it can complete the payment within an authorized budget without being redirected to a separate manual checkout page each time.

What Are the Differences Between AP2 and x402?

The most fundamental difference between AP2 and x402 lies in their responsibilities. AP2 primarily answers, “Is this transaction authorized?” x402 primarily answers, “How can the payment be completed programmatically according to the server’s requirements?”

AP2 does not depend on a specific payment currency or settlement network. For example, an AI Agent can use AP2 to prove that a purchase has been authorized and then complete the transaction with a bank card or another supported payment method. x402 focuses more on the technical execution of digital service payments and is particularly suitable for combining stablecoin payments with API requests.

The two protocols also have some functional overlap. x402 can verify payment credentials submitted by a client, but this verification primarily concerns whether the payment meets the server’s requirements. It is not inherently equivalent to complete authorization of the user’s commercial intent. AP2 can record more extensive information about the user’s intent, product, and payment conditions.

Therefore, AP2 should not simply be viewed as an upgraded version of x402, nor should x402 be considered a replacement for all payment authorization mechanisms. They can be deployed independently or used together.

How Can AP2 and x402 Work Together to Complete an Agent-to-Agent Transaction?

The collaboration between AP2 and x402 can be understood through an example involving a paid data analysis service.

Suppose a user authorizes a research Agent to purchase no more than $20 worth of market data in a single day. The Agent discovers that another service provider offers an API that meets its needs and receives a quote of $0.10 per call. The system must first confirm that the service falls within the authorized purchase scope and then check that cumulative spending does not exceed the budget.

During the authorization stage, AP2 can provide a verifiable Mandate proving that the Agent has the corresponding purchase and payment permissions. During the payment stage, x402 can deliver the server’s payment requirements to the Agent and complete the fund transfer through a controlled wallet, payment credentials, and a settlement service. After the payment succeeds, the server returns the data, and the Agent continues the research task.

This combination is not limited to a conceptual model. Google-related open-source projects have released the A2A x402 Payments Extension, which allows Agents to purchase services provided by other Agents through on-chain payments. Its v0.2 specification also defines independent and embedded payment flows. The latter can integrate payment structures into higher-level protocols such as AP2.

However, the process above is an example used to explain how the protocols can be combined. It does not mean that all AP2 or x402 implementations already support exactly the same functions. Actual systems still need to handle details such as authorization credential verification, wallet permissions, failed payments, duplicate requests, and transaction receipts.

Why Are Stablecoins Suitable for AI Agent Automated Payments?

Stablecoins are one of the leading candidates for AI Agent programmatic payments. Compared with crypto assets that have greater price volatility, USD-pegged stablecoins are generally denominated against the U.S. dollar, helping service providers set relatively stable prices for API calls, data access, and computing resources.

For example, an AI Agent may need to call a paid data interface hundreds of times each day. If every call requires manual confirmation of a bank card payment, the transaction process will be difficult to automate. With x402 and a supported stablecoin network, payment requirements, signatures, and settlement operations can be integrated into programmatic requests, allowing the Agent to pay for services automatically within its budget.

Stablecoins are also digital-native and programmable. Developers can combine payment logic with API permissions, usage limits, and wallet restrictions, allowing software systems to transfer funds across different platforms. When introducing x402, Coinbase identified automated payments between APIs, software services, and AI Agents as a key application area.

However, stablecoin payments also have limitations. On-chain transfers may incur network fees, some transactions may require time to reach finality, and incorrect addresses or irreversible transfers can result in the loss of funds. Stablecoins also involve issuer, reserve, redemption, and regulatory risks. Stablecoins should therefore be understood as one settlement option for Agent Commerce rather than a universal solution to all payment problems.

What Security Risks and Technical Limitations Do AP2 and x402 Face?

The first risk is authorization abuse. An AI Agent may misunderstand a user’s request or be influenced by malicious webpages, tool responses, or prompt injection, causing it to initiate purchases beyond the user’s actual intent. If the system relies solely on the model to determine whether a payment is reasonable and lacks independent budget and permission checks, unintended spending may occur.

AP2 reduces this risk through Mandates and deterministic verification mechanisms, but its security still depends on how authorization credentials are issued, stored, and verified. Systems must also avoid granting excessively broad permissions and should introduce additional confirmation for high-risk transactions.

The second risk is payment execution. x402 involves the client, server, wallet, and settlement service, and an implementation error at any stage may affect the transaction outcome. For example, repeated request submissions may result in duplicate payments, a successful payment followed by failed service delivery may lead to a dispute, and a Facilitator failure may delay settlement. Developers therefore need to design idempotent processing, failed-payment retries, receipt reconciliation, and exception-based refund procedures.

The third risk concerns counterparty and identity verification. Even if an Agent correctly submits payment credentials, the recipient is not necessarily trustworthy. A malicious server may misrepresent prices, provide an invalid service, or falsify product information. A2A and x402 can improve Agent communication and payment flows, but they cannot automatically guarantee the authenticity of a merchant’s identity or that the service quality will meet expectations.

The final risks involve privacy and regulation. Agent Commerce may involve users’ consumption preferences, enterprise procurement information, and payment data. Although on-chain payments provide publicly verifiable transaction records, they may also expose addresses and fund flows. Cross-border payments also require consideration of applicable anti-money laundering, sanctions, and consumer protection requirements.

As a result, practical applications of AP2 and x402 need to be built on a multilayer security architecture that includes user authorization, Agent permission controls, payment credential verification, transaction monitoring, and exception handling. Only by combining these mechanisms can systems control fund-related risks while increasing the level of automation.

Conclusion

AP2 and x402 provide infrastructure for AI Agent commerce from the perspectives of payment authorization and programmatic settlement, respectively. Through Mandates and verifiable credentials, AP2 helps merchants and payment service providers confirm whether an Agent’s transaction complies with user authorization. Through HTTP 402 and payment verification processes, x402 enables AI Agents to automatically purchase APIs, data, and other digital services.

The two protocols are not substitutes for each other. AP2 can work with different payment methods, while x402 can serve as an execution mechanism for on-chain payments. As technologies such as the A2A x402 Payments Extension develop, authorization verification and automated settlement are forming a closer collaborative relationship.

For Agent-to-Agent Commerce, the key issue is not simply enabling AI Agents to make payments. Each transaction must have clearly defined authorization boundaries, verifiable payment results, and reliable exception-handling mechanisms. Stablecoins and Web3 provide new settlement tools for this direction, but the widespread adoption of Agent commerce will ultimately depend on security, interoperability, and real-world business needs.

FAQ

What Is the Core Difference Between AP2 and x402?

AP2 primarily verifies an AI Agent’s purchase and payment authorization, while x402 primarily enables programmatic payments through HTTP requests. The former focuses on authorization, while the latter focuses on payment execution.

Is AP2 a Blockchain Payment Protocol?

No. AP2 is a payment-method-agnostic authorization framework that can support different payment systems, including bank cards and stablecoins. It does not require transactions to be settled on a blockchain.

Can x402 Only Use USDC?

No. x402’s payment capabilities depend on the specific payment scheme, network, and support provided by the server. USDC is a common payment asset in implementations, but it should not be understood as the only asset supported by the protocol.

Can AP2 and x402 Be Used Together?

Yes. AP2 can be used to verify an Agent’s transaction authorization, while x402 can be used to execute the corresponding programmatic on-chain payment. The A2A x402 Extension has already explored ways to combine x402 with higher-level protocols such as AP2.

Does an AI Agent Need Manual Confirmation to Make a Payment with x402?

Not necessarily. If the user has provided valid authorization and the transaction meets the budget, recipient, and other applicable restrictions, the system can allow the Agent to make the payment automatically. Transactions outside the authorized scope should require confirmation again.

Is Service Delivery Guaranteed After an x402 Payment Succeeds?

No. Successful payment and service fulfillment are separate stages. API failures, unavailable services, or delivery disputes may still occur. Risks should therefore be managed with transaction receipts, exception handling, and refund mechanisms where necessary.