The Agent Payment Protocol Stack: What Is Real in 2026

Why This Exists

The agent payment protocol stack is the control plane that has to exist before autonomous agents can buy services, call paid APIs, settle microtransactions, and prove that a purchase was authorized. The current market conversation often collapses that stack into one phrase: agentic payments. That is too vague for operators.

A real deployment needs several different answers at once. Who proved the user wanted the purchase? Which merchant endpoint executed checkout? What payment method or settlement rail moved value? Which identity or reputation layer says the agent is real? What spending limit stopped a runaway loop? What happens when the agent buys the wrong thing?

This post is the cleaned, publish-safe version of a longer research run. Gemini Deep Research produced the broad map. ChatGPT Deep Research cross-validated the claims and flagged the unsafe parts. The result is narrower than the first draft, but more useful: keep the verified protocol mechanics, remove the unverified market-size and acquisition claims, and separate live capabilities from roadmap language.

AP2 Is An Authorization Layer, Not A Generic Checkout Button

Google’s Agent Payments Protocol, AP2, is best read as an authorization and dispute-evidence protocol for agent-performed transactions. Its public specification defines a Checkout Mandate and a Payment Mandate. The Checkout Mandate is about proving to the merchant that an agent is authorized to purchase the assembled checkout. The Payment Mandate is about proving to credential providers, networks, and payment processors that the agent is authorized to pay for that checkout [1].

That distinction matters. AP2 is not simply a “pay now” button for bots. It is a way to bind intent, checkout contents, and payment authorization into signed evidence. In enterprise language, AP2 is closer to a chain-of-authority and dispute file than a replacement for every payment rail.

The key correction from the validation pass is terminology. The public AP2 specification uses Checkout Mandate and Payment Mandate. A draft that casually says “Intent Mandate” or “Cart Mandate” as canonical terminology should be corrected before publication.

ACP Is The Merchant Integration Surface

The Agentic Commerce Protocol, developed around OpenAI and Stripe’s agentic commerce work, occupies a different layer. ACP describes how buyers, agents, sellers, and payment providers coordinate an agentic checkout. Its architecture page lays out the parties and the flow: agents help buyers discover and transact, sellers expose commerce surfaces, and payment providers handle the payment side [2].

The delegated payment specification is the important enterprise detail. It describes how payment details can be shared with a merchant or its payment service provider while the merchant keeps its own payment processing relationship [3]. That makes ACP a merchant-to-agent commerce integration standard, not a direct substitute for AP2.

The safe comparison is this: AP2 answers “how do we prove authorized agent intent and payment authority?” ACP answers “how does a seller participate in an agentic checkout flow?” They overlap in agentic commerce, but treating them as the same rail makes the architecture harder to reason about.

x402 And MPP Bring Payment Into The Request Flow

x402 revives the HTTP 402 Payment Required status code as a payment negotiation pattern for APIs, content, and agents. Coinbase’s x402 documentation describes a client requesting a protected resource, the server replying with payment requirements, and the client returning a payment payload that lets the request proceed [4]. That is why x402 keeps showing up in agent discussions: it makes small programmatic payments feel like part of the API call.

AWS AgentCore Payments shows how this becomes an enterprise guardrail problem. Its documentation describes stablecoin payments, x402 support, and configurable payment limits for agents and users [5]. The important part is not only “agents can pay.” It is that payments can be bounded by session budgets, user-level controls, and observability.

Stripe’s machine-payments documentation points in the same direction from a different angle. Stripe frames machine payments as a way for businesses to accept payments initiated by machine clients, including support for x402 and the Machine Payments Protocol [6]. The practical read is that HTTP-native payment flows are not only a crypto story. They are becoming a bridge between APIs, card networks, wallets, and stablecoin settlement.

Identity And Delegation Are The Enterprise Bottleneck

ERC-8004 is useful in this conversation because it points away from payment rails and toward identity, reputation, and validation. The Ethereum proposal is still a draft ERC, not a finalized standard. It should be described that way. The proposal also treats payments as orthogonal, which is exactly why it belongs in the stack as a trust layer rather than a settlement layer [7].

EIP-7702 belongs in the delegation layer. It gives externally owned accounts a way to delegate behavior, which can help wallets act more like smart accounts. That is powerful, but it also creates policy and security questions: who can delegate, what code is authorized, and how does an enterprise revoke or constrain that authority [8]?

American Express ACE adds the card-network view of the same problem. The public ACE material describes account enablement, intent intelligence, tokenized payment credentials, and cart context. It also makes clear that some specifications are available while others remain under development, and that Agent Purchase Protection language is forward-looking and conditional [9]. That is not a weakness. It is the honest shape of a market where liability design is still catching up to agent autonomy.

The Practical Enterprise Checklist

If you are evaluating agent payments, do not start with the settlement rail. Start with the control questions.

• Intent: What signed object proves the user or business authorized the agent’s action?
• Checkout: Which merchant integration receives the order and returns the checkout state?
• Payment: Which protocol or PSP handles payment credentials, payment requirements, and settlement?
• Limits: Where are user, agent, session, merchant, and category spending limits enforced?
• Identity: How is the agent registered, discoverable, and reputation-scored?
• Dispute: What evidence exists if the agent buys the wrong item, exceeds scope, or triggers fraud controls?

The answer will usually be layered. AP2 can help with verifiable authorization. ACP can help with merchant integration. x402 and MPP can help with machine-readable payment flows. ERC-8004 and EIP-7702 can help frame identity and delegation. ACE-style card-network controls can help with trust and dispute posture. No single acronym removes the need to design the full stack.