Agentic Payment Protocols in 2026: x402, ACP, AP2, and Agent Pay Explained

TL;DR

• x402 is an open payment protocol created by Coinbase. It uses HTTP 402 responses and stablecoins to let agents pay APIs per request.
• ACP is a commerce standard developed by OpenAI and Stripe. It lets agents complete merchant checkout flows through structured payment instructions.
• AP2 is an open framework led by Google. It uses signed mandates to authorize agent-initiated payments across payment methods.
• Mastercard Agent Pay for Machines is Mastercard’s framework for machine-initiated transactions. It uses tokenized payment credentials on existing card rails.
• None of these protocols alone provides complete agent identity verification and spending-limit enforcement. Agentic commerce still needs infrastructure that connects a verified agent to scoped authority and transaction controls.

What agentic commerce means in 2026

Agentic commerce lets software agents purchase data, API access, compute, and other services without waiting for a person to approve each transaction. These purchases often involve low values and high frequency. Human checkout flows assume that someone can review an order and complete an authentication step, but repeated intervention removes the speed and autonomy that make agents useful.

Existing card networks can settle some agent purchases, but consumer checkout flows were not built for automated requests that may occur many times per minute. Manual approval adds delay, and fixed processing costs can exceed the value of a small transaction. New agent payment protocols address these constraints by embedding payment instructions in software interactions or defining how agents communicate with merchants and payment networks.

Payment execution and agent trust remain separate technical problems. A payment protocol can specify how an agent presents payment, how a merchant accepts it, and how the parties settle the transaction. Separate identity and authorization infrastructure must verify which agent initiated the purchase and whether its owner granted the required authority. Spending controls must also limit transaction size, cumulative spend, and permitted purchase types.

You need both layers for safe agentic commerce. Payment infrastructure moves value, while trust infrastructure determines whether a specific agent may move that value under the requested conditions.

x402: HTTP-native stablecoin payments

x402 turns the HTTP 402 Payment Required status code into a payment flow for agents and APIs. Coinbase introduced and open-sourced the protocol. Coinbase and Cloudflare later established the x402 Foundation to support its development and adoption.

The protocol lets an API charge for each request without sending the agent through a conventional checkout. When an agent requests a paid resource, the server returns an HTTP 402 response with the price, accepted network, payment asset, and destination wallet. The agent signs a payment authorization and retries the request with that authorization attached. The server or a payment facilitator verifies the authorization, settles the payment, and returns the requested resource.

x402 uses blockchain networks for settlement, and current implementations commonly use stablecoins such as USDC. A facilitator can handle blockchain verification and settlement on the seller’s behalf, which keeps those tasks out of the API’s application logic. The HTTP exchange carries the payment requirements and proof, while the supported blockchain records the transfer.

Per-request settlement makes x402 useful for metered API calls, data access, compute jobs, and other low-value machine purchases. An agent can pay for one request at a time instead of opening an account, committing to a subscription, or completing a human checkout flow.

x402 does not establish whether an agent should receive permission to spend. A valid payment proves that the requested transfer can settle. It does not independently verify the agent’s identity, confirm delegated authority from a person or business, or enforce a budget across multiple transactions. Builders need separate identity, authorization, and spending-control infrastructure for those functions.

ACP: Agentic Commerce Protocol

ACP is an open standard created by OpenAI and Stripe for agent-mediated checkout with merchants. OpenAI first used it to power Instant Checkout in ChatGPT. The protocol defines how an agent exchanges product, order, and payment information with a merchant while the merchant retains control of fulfillment, customer support, and its existing payment provider.

During checkout, the agent asks the merchant to create a checkout session. The merchant returns available items, prices, shipping choices, and other order details in a structured format. After the shopper approves the purchase, the agent submits the completed order with a payment credential. The merchant then processes payment through its chosen provider and remains the merchant of record.

ACP assumes that the commerce platform authenticates the shopper and captures purchase approval. A scoped payment token can prevent the merchant or agent from receiving reusable card credentials. However, ACP does not independently prove the identity of an autonomous agent or determine whether that agent has authority to spend. External identity, wallet, and policy infrastructure must enforce delegated authority and transaction limits.

ACP works best for agent-to-merchant retail transactions that resemble conventional online checkout. It can connect conversational shopping interfaces with merchant catalogs and order systems without requiring merchants to surrender their existing commercial relationships. ACP does not provide an HTTP-native micropayment rail like x402, and it does not settle funds itself. Fully autonomous purchasing also requires controls beyond ACP, including revocable authorization and limits bound to a verified agent.

AP2: Agent Payments Protocol

Google introduced the Agent Payments Protocol, or AP2, as an open framework for authorizing and verifying payments initiated by AI agents. Google developed AP2 with support from payment networks, processors, technology companies, and merchants, including Mastercard, PayPal, Coinbase, Adyen, and American Express. The framework lets those participants exchange evidence that a user approved an agent’s actions.

AP2 records authorization through cryptographically signed digital contracts called mandates. An Intent Mandate can document the user’s instructions, such as a request to buy a specific product within a spending limit. A Cart Mandate can capture the final items, price, and merchant before payment. These records create a verifiable link between the user’s instructions, the agent’s decision, and the resulting transaction.

AP2 sits above payment rails rather than replacing them. A merchant or payment provider can use its authorization records with cards, bank payments, stablecoins, or other supported methods. That design makes AP2 most useful when agents need to transact across several payment networks while preserving evidence of user consent.

AP2 still depends on external infrastructure to establish trust and move funds. A wallet or credential provider must bind mandates to a user and agent, while payment providers handle acceptance, settlement, and disputes. AP2 can verify that signed instructions remained intact, but the framework does not independently prove an agent’s identity or enforce every spending rule. Builders still need identity verification, scoped authority, revocation, and transaction-level controls around the protocol.

Mastercard Agent Pay for Machines

Mastercard Agent Pay for Machines connects autonomous software to Mastercard’s existing card network through tokenized payment credentials. An agent can receive a credential for a defined transaction without handling the underlying card number. Issuers, acquirers, merchants, and other network participants continue to process authorization and settlement through familiar card infrastructure.

Tokenization gives network participants a way to recognize and control agent-initiated payments. Issuers and payment providers can apply approval rules, while merchants can accept payment through their existing Mastercard connections. Agent Pay therefore fits purchases where sellers already accept cards and do not want to add a separate settlement rail.

Skyfire participates in Mastercard Agent Pay for Machines. Skyfire contributes agent identity and payment authorization infrastructure, while Mastercard provides the card-network payment mechanism. The two functions remain distinct. A tokenized credential enables payment, but an autonomous agent still needs verified identity, scoped authority, and enforceable spending limits.

“Soon, most payments online won’t come from a human clicking buy – they’ll be machines paying machines at a speed and scale legacy rails were not built for. That future scales when identity and settlement trust move together. Mastercard’s authorize-once model gives agents bounded, discoverable spending authority; Skyfire’s Know Your Agent binds it to a verifiable identity and the human behind it – so every spend proves not just how much, but who and on whose behalf. Few partners we’d rather build that future with, and this is only the first chapter.” — Ankit Agarwal, Chief Technology Officer, Skyfire.

Comparing the four protocols

Each framework covers a different part of agentic commerce. The comparison separates payment execution and settlement from agent identity, delegated authority, and spending controls.

Why payment protocols alone don’t solve agent trust

Payment protocols move transaction instructions and value, but no single protocol supplies every trust control an autonomous agent needs. x402 handles request-level payments, ACP structures merchant checkout, AP2 carries payment mandates, and Mastercard Agent Pay uses tokenized credentials. Each approach still depends on other infrastructure for some combination of identity, delegated authority, and spend governance.

Agent identity establishes which agent initiated a transaction and which person or business operates it. API keys and payment credentials can authenticate access to a resource, but a valid credential does not always provide a portable, verified agent identity.

Scoped authority defines what a verified agent may do for a specific task. An agent authorized to book a hotel under a stated price should not automatically gain permission to buy unrelated goods. Authorization can include approved merchants, transaction types, time windows, and revocation conditions.

Spending controls determine when an agent must stop transacting. Per-transaction caps cover individual purchases, while cumulative budgets and velocity rules constrain repeated payments. Those controls become especially important when agents make frequent, low-value purchases without human approval for each charge.

A layered architecture keeps these responsibilities separate. Payment protocols can manage interoperability and settlement, while an agent trust layer can verify identity and evaluate transaction-level authority. At Skyfire, we position KYA and the Agentic Wallet in that identity and payment-authorization layer, rather than treating a payment rail as proof that an agent should be allowed to spend.

A layered architecture for agentic commerce

A layered architecture separates payment movement from the trust decisions that precede it. Each layer performs a distinct job, and an agentic commerce workflow may combine components from several providers.

• Protocol interoperability. This layer defines how agents, merchants, APIs, and payment providers exchange requests and payment information. x402 specifies an HTTP payment flow, while ACP standardizes agent-led merchant checkout. AP2 provides a framework for communicating payment mandates across participating networks. Mastercard Agent Pay connects agents with participants in the Mastercard ecosystem.
• Identity and scoped authority. Identity infrastructure establishes which agent initiated a transaction and whose authority it carries. Scoped authority limits the agent to an approved task, merchant, or type of purchase. Skyfire KYA can provide portable agent identity and transaction-scoped authorization at this layer. Such infrastructure complements OAuth, API keys, and workload identity rather than replacing every credential system.
• Spending controls. Policy engines decide whether a proposed transaction fits its assigned limits. Controls can evaluate the amount, merchant, and cumulative budget. More advanced policies can also consider the task that produced the purchase request. Binding these controls to a verified agent provides more context than applying restrictions to a card number alone.
• Payment authorization. The authorization layer converts an approved action into permission to charge a credential or transfer funds. AP2 mandates and Mastercard Agent Pay credentials address parts of this function within their respective models. An agent wallet can also enforce transaction-level approval before releasing a payment credential.
• Settlement. The settlement layer moves value and records the final transfer. x402 commonly uses stablecoins, while Mastercard Agent Pay relies on card-network infrastructure. ACP and AP2 can coordinate commerce or authorization without requiring one universal settlement rail.

The components do not need to compete for the same role. A merchant could use a commerce protocol for message exchange, an identity layer to verify the agent, a wallet to enforce spending policy, and an existing network to settle the payment. Protocol choice therefore does not remove the need to evaluate identity, authority, and spending controls separately.

Skyfire’s role: identity and authorization infrastructure

Skyfire provides the identity and payment-authorization layer that agentic commerce protocols may rely on but do not necessarily supply. KYA gives an autonomous agent a portable, verifiable identity and connects that identity to transaction-scoped authority. A merchant or service can evaluate which agent is acting, whether its current task falls within the granted authority, and whether the authorization remains valid.

KYA complements existing access controls rather than replacing them. OAuth can grant delegated scopes, API keys can authenticate credentials, and workload identity can identify a service. KYA adds agent-specific identity, behavioral authorization, and transaction-level trust for autonomous agents whose actions may change as they work.

The Agentic Wallet connects payment controls to the verified agent that initiates a purchase. A card number or payment credential can carry limits, but the credential alone cannot establish which agent or task requested the charge. By binding spend authorization to KYA, the wallet can evaluate the agent’s identity and transaction authority before approving payment. You can then apply controls to the autonomous actor instead of relying only on card-level restrictions.

Skyfire participates in Mastercard Agent Pay for Machines, which connects Skyfire’s agent identity and authorization infrastructure with Mastercard’s card-network approach to agent payments. Mastercard Agent Pay for Machines is the only named protocol relationship confirmed here. Skyfire does not claim support for x402, ACP, or AP2 without corresponding first-party documentation.

Implementation considerations for builders

Start with the transaction profile. High-frequency, low-value API purchases benefit from low-overhead, per-request payment methods such as x402. Higher-value retail purchases may fit card-based checkout flows that already support refunds, disputes, and merchant acceptance.

Choose a settlement rail that the receiving party can use. An API that accepts stablecoins creates a different integration path than a merchant that accepts tokenized card credentials. Protocol design cannot overcome missing merchant or API support for the underlying rail.

Set authorization requirements according to the agent’s independence. A human-in-the-loop workflow can request approval before checkout or above a defined amount. A fully autonomous workflow needs preapproved boundaries, transaction-level policy checks, and an immediate way to revoke authority when behavior changes.

Static credentials and payment controls provide limited context. An API key can authenticate a caller, but the key does not establish which agent initiated a purchase or whether the purchase serves an approved task. Merchant category code restrictions can block broad categories, but they cannot reliably distinguish an authorized transaction from an unauthorized transaction at the same merchant.

Transaction-level authorization should evaluate the verified agent, requested purchase, spending limit, and delegated task before releasing payment credentials. Revocable authority also limits exposure when an agent behaves unexpectedly or a credential becomes compromised. Skyfire’s KYA and Agentic Wallet can provide this identity and payment-authorization layer without replacing the chosen settlement protocol.

Builders should also plan for retries, duplicate requests, and incomplete transactions. Idempotency controls can prevent an agent from paying twice after a timeout, while transaction records should connect each payment to the agent identity and authorization decision that produced it.

FAQs

Can x402, ACP, AP2, and Mastercard Agent Pay be used together?

Yes, when each protocol handles a different layer. For example, ACP can structure a merchant checkout while AP2 carries authorization evidence. An integration could use x402 for a separate API payment. Developers must map credentials, authorization rules, and settlement events because the protocols do not become interoperable automatically.

Do x402, ACP, or AP2 verify agent identity?

None provides complete agent identity verification on its own. x402 verifies payment for an HTTP request. ACP coordinates agent and merchant checkout interactions. AP2 uses mandates to record user intent and payment authority, but external identity and wallet infrastructure must establish which agent receives that authority.

What is Mastercard Agent Pay for Machines?

Mastercard Agent Pay for Machines is a program for autonomous machine transactions over Mastercard’s existing network. It uses tokenized payment credentials and network participants to support controlled agent payments. Skyfire participates in the program as an identity and payment infrastructure provider.

Does Skyfire support x402, ACP, or AP2?

Skyfire has not verified public support for x402, ACP, or AP2 in the materials used for this guide. Its confirmed protocol relationship is participation in Mastercard Agent Pay for Machines. Builders should not infer broader compatibility without current first-party documentation.

How does KYA differ from a virtual card?

A virtual card supplies payment credentials and may enforce controls such as merchant or amount limits. Skyfire KYA establishes a portable agent identity and can connect transaction-scoped authority to that identity. Used with the Agentic Wallet, KYA lets a payment policy evaluate which verified agent and task initiated a purchase, rather than relying only on the card number.

Conclusion

Teams designing agentic commerce workflows should evaluate payment protocols and trust infrastructure as separate layers. A protocol can define how an agent requests, authorizes, or settles a payment, but successful settlement does not prove which agent acted or whether it stayed within delegated authority.

Builders should choose a payment layer based on accepted rails, transaction patterns, and counterparties. They should assess trust infrastructure separately by asking how the workflow verifies an agent, grants scoped authority, enforces spending limits, and revokes access. Skyfire’s KYA and Agentic Wallet address agent identity and payment authorization, while settlement frameworks handle money movement and interoperability. Both layers must work together, but each requires its own technical and risk review.