Agent Payment Protocols in 2026: An Evidence-Graded Technical Review

Research Question And Method

This review asks one constrained question: which parts of the agent-payment stack are supported by public primary sources as of May 25, 2026, and which claims remain draft, preview, roadmap, or unsupported?

The evidence set is deliberately narrow. Gemini Deep Research and ChatGPT Deep Research were used for discovery and adversarial cross-checking, but the article’s public claims are grounded in primary protocol specifications or official documentation. Secondary market-size, adoption, acquisition, dominance, and exact performance claims are excluded unless a primary source with methodology is available.

Evidence labels used below are an author-defined maturity scale for this review, not an established medical or academic evidence taxonomy:

• A: primary specification or official protocol documentation with enough detail to evaluate roles, messages, or verification responsibilities.
• B: official product or platform documentation, including preview services and vendor-controlled implementation claims.
• C: draft standards-track proposal that is technically inspectable but not final consensus infrastructure.
• Excluded: claims not supported by primary public evidence in this review.

Threat Model: Why Payment Is Not The First Problem

The technical problem is not merely moving value. The harder problem is proving that a non-deterministic agent acted within authorized scope. AP2 makes this explicit by distinguishing agentic and non-agentic roles, requiring deterministic validation for processing, and treating an agent as a potential attacker when an LLM participates in communication [1].

This framing is important for scientific readers because it defines an evaluable system boundary. A credible agent-payment architecture must specify who authorizes intent, how checkout state is bound to authorization, how payment authority is constrained, and what evidence survives a dispute. Without that, the term “agentic payments” is not a technical claim; it is a market label.

Finding 1: AP2 Is Authorization Evidence, Not A General Checkout Layer

AP2’s specification states that the protocol secures agent-performed payment transactions through an agent authorization model. It defines a Checkout Mandate for what is being purchased, a linked Payment Mandate for payment, role-specific verification duties, and use of mandates as dispute evidence [1].

The strict conclusion is therefore limited: AP2 is a candidate evidence and authorization layer inside a broader commerce protocol. It is not, by itself, a complete catalog API, checkout API, processor integration, identity registry, or settlement rail. The specification itself says commerce-protocol details such as catalog APIs and checkout updates are outside AP2’s scope [1].

Finding 2: ACP Is A Commerce Integration Surface With Delegated Payment Constraints

ACP describes four parties in the purchase flow: buyers, agents, sellers, and payment providers. It assigns sellers responsibility for checkout APIs, inventory, pricing, fulfillment, and merchant-of-record duties; it assigns payment providers tokenization and spending-limit enforcement roles [2].

The delegated-payment reference is the strongest control claim. It describes secure, time-limited payment tokens with allowance constraints, including maximum amount, expiration, and merchant scope [3]. That makes ACP materially different from AP2. ACP is about an agent-mediated checkout and payment-token workflow; AP2 is about verifiable authorization and dispute evidence.

Finding 3: x402 And Machine Payments Are Payment-Challenge Infrastructure

x402 revives HTTP 402 as a payment-required challenge for machine clients. Coinbase’s documentation frames it as an open protocol for instant stablecoin payments over HTTP, including APIs, digital content, and AI agents that pay programmatically [4].

Official platform documentation shows two implementation directions. AWS AgentCore Payments documents x402 orchestration, payment limits, wallet integration, endpoint discovery, and observability, but labels the service preview [5]. Stripe’s machine-payments documentation describes x402 and MPP support, low-value USDC payments, refunds, and network availability across Base, Solana, Tempo, and Stripe card networks [6]. The conservative conclusion is that payment-challenge infrastructure is real enough to implement against, while production claims still require per-platform maturity checks.

Finding 4: Identity, Delegation, And Liability Remain Less Mature Than Payment Messaging

ERC-8004 is relevant because it separates discovery and trust from payment. It proposes identity, reputation, and validation registries for agents, while explicitly stating that payments are orthogonal to the protocol [7]. Because the proposal is marked draft, it should not be cited as a finalized standard.

EIP-7702 is relevant but adjacent. It defines a transaction type that lets externally owned accounts set delegated code, supporting account-behavior upgrades such as batching and sponsored transactions [8]. It can support agent-wallet patterns, but it does not solve authorization, merchant checkout, or dispute evidence on its own.

American Express ACE is a card-network example of the same control problem. The ACE page names account enablement, intent intelligence, tokenized payment credentials, and cart context, but it also labels some specifications as still under development and describes purchase protection in future-facing terms [9]. That matters: liability controls are emerging, not settled science.

Key Takeaways

• AP2 can be tested as an authorization-evidence layer: an implementation should produce and verify Checkout and Payment Mandates and retain dispute evidence.
• ACP can be tested as a merchant checkout integration: an implementation should expose checkout lifecycle behavior and delegated-payment token constraints.
• x402 can be tested as a request-payment handshake: a protected endpoint should return payment requirements and accept a valid payment payload before serving the resource.
• Preview products need maturity checks: AWS AgentCore Payments should be treated as preview until general-availability documentation changes that status.
• ERC-8004 should be tracked as draft: it should not be used as evidence of finalized agent identity infrastructure until its standards status changes.

What Would Make This Scientifically Stronger

A stronger future study would not rely only on documentation. It would implement a reproducible test harness across a small set of merchants and paid API endpoints, measure mandate verification failure modes, compare x402 and MPP payment-request flows, and publish the raw traces. It would also separate security properties from adoption claims: protocol existence, interoperability, transaction cost, latency, error recovery, budget enforcement, privacy leakage, and dispute evidence should be measured independently.

Until those measurements exist, the most defensible position is cautious. The agent-payment stack is technically inspectable, but unevenly mature. The strongest current evidence supports a layered architecture: authorization evidence, merchant checkout integration, payment challenge, settlement, identity, account delegation, and liability controls. It does not support winner-takes-all predictions.

Practitioner Supplement: Enterprise Evaluation Checklist

• Authorization: What signed object proves the user or business authorized this agent action?
• Checkout binding: How is the exact item, price, merchant, tax, shipping, and total bound to the authorization?
• Payment constraints: Are payment credentials single-use, merchant-scoped, amount-limited, and expiry-limited?
• Budget enforcement: Are user, agent, session, category, and merchant limits enforced before payment signing?
• Identity and reputation: Is the agent discoverable and accountable through a verifiable registry or equivalent control?
• Delegation and revocation: Can account delegation be constrained, audited, and revoked without trusting the LLM?
• Dispute evidence: What non-repudiable record survives if the agent buys the wrong item or exceeds scope?