Agentic payments: what an agent can verify before paying

An agent that is about to pay can verify almost nothing about who it is paying. It can usually verify that a payment instrument is valid, that a signed authorisation matches the amount its user approved, and that some address will receive the funds. It cannot verify that the address belongs to the merchant it thinks it chose, that the resource it is buying is the one it was quoted, or that the seller exists in any sense beyond a listing. Every deployed agentic payments stack authenticates the buyer to the seller. None of them authenticates the seller to the buyer.

What are agentic payments?

Agentic payments are payments initiated by software acting for a person, where the software chooses the counterparty, the amount or the timing rather than replaying an instruction typed by a human. The term covers work at three different layers: intent, authorization and settlement.

Which layer is which?

The IMF splits the stack into three layers. IMF Notes 2026/004, “How Agentic AI Will Reshape Payments” by Sonja Davidovic and Hervé Tourpe (April 2026, DOI 10.5089/9781513533308.068), builds on a three-layer framework its abstract names as “intent, authorization, and settlement”, used to identify “where agentic capabilities may add value while preserving control and finality”. The IMF uses the US spelling for the middle layer, and so does this table.

Layer	Question it answers	Who is working here
Intent	What is being bought, from whom, and on whose behalf?	ACP, UCP, MCP, A2A
Authorization	Was this specific payment authorised, and within what limits?	AP2, Visa TAP
Settlement	How does the money actually move?	Card rails, x402, MPP

Which ACP do you mean this time?

We already had to write MCP vs ACP because three unrelated protocols shared that acronym. Agentic commerce added a fourth, and the academic literature names more. The SoK on agentic commerce security (Mao et al., April 2026) opens its terminology note by disambiguating three overloaded senses at once, reserving ACP for “the Agent Commerce Protocol by Virtuals Protocol, which is a settlement and escrow coordination layer”, and flagging a further “Agent Control Protocol” in concurrent work.

Name	Owner	What it connects
Agent Client Protocol	Zed and contributors	Code editors to coding agents
Agent Communication Protocol	IBM	Agent to agent (merged into A2A)
Agentic Commerce Protocol	OpenAI and Stripe	Buyers and their agents to merchants
Agent Commerce Protocol	Virtuals Protocol	On-chain settlement and escrow, per the SoK

When a payments document says “ACP” today it usually means the third one in that table. It is company-governed, though not in the way it is usually described. Its governance document says the technical steering committee “has up to 7 seats” and that “Each seat is held by one organization”. Three are filled: seat 1 OpenAI, seat 2 Stripe, seat 3 Meta. OpenAI and Stripe are Founding Maintainers, each holding “one seat on the TSC with the same voting rights as any other member”, plus a reserve veto the document describes as “limited” and “expected to be exercised in extremely rare situations”.

Its latest dated specification snapshot is 2026-04-17, with 17 changelog entries sitting unreleased (checked 17 August 2026). On payment methods, the card is the only thing the specification actually models: DelegatePaymentRequest.payment_method is a hard $ref to PaymentMethodCard, whose type is {"const": "card"} (schema.delegate_payment.json). Everything else is an open string: the checkout schema’s PaymentMethodObject takes any method, and PaymentData.instrument.type is documented only by example, “card, wallet_token”.

UCP, the Universal Commerce Protocol from Google and Shopify, is the other serious contender at that layer. Its first commit lands on 11 January 2026 and its latest release is v2026-04-08. The tooling gap is the real difference. UCP’s organisation ships python-sdk, js-sdk, samples and a conformance suite as separate repositories; ACP’s organisation contains exactly one repository, and its only tooling is a consistency-validation script.

Governance on the UCP side concentrates differently. Its Governing Council has five seats, one permanent each for Google and Shopify, and its governance document states that “Google holds proxy vote for all open seats until Dec 2028 to facilitate rapid early stage growth & adoption of the protocol”.

Anyone framing this as Google plus Shopify against OpenAI plus Stripe is working from an old map. UCP’s Shopping Tech Council now lists members from Stripe, Meta, Amazon, Microsoft, Etsy, Target, Salesforce and Wayfair alongside Google and Shopify, and Meta holds an ACP steering seat. The same Stripe engineer sits on both.

Can you use AP2 without x402?

Yes. AP2 is a mandate format; x402 is one settlement rail among several.

AP2 is Google’s Agent Payments Protocol. Its changelog records v0.2.0 on 28 April 2026. It is a mandate format: a cryptographically signed record of what a user authorised, built on IETF SD-JWT (RFC 9901, “Selective Disclosure for JSON Web Tokens”, Standards Track, November 2025). In v0.2 the mandate model is the open or closed Checkout Mandate plus the Payment Mandate, replacing the Intent and Cart Mandate pair that v0.1-era write-ups still describe. AP2 does not move money and does not do discovery, so it needs a settlement rail underneath it, and any rail will do.

The x402 connection is looser than it is usually reported. It exists as a2a-x402, an extension to A2A rather than to AP2. Its current v0.2 specification uses the correct google-agentic-commerce URIs, but the shipped Python SDK still hardcodes the old organisation: X402_EXTENSION_URI = "https://github.com/google-a2a/a2a-x402/v0.1" in types/config.py. The AP2 repository has had no commit at all since 29 April 2026, and its partners page has been deleted rather than updated.

Does ACP compete with AP2?

No. ACP and UCP compete with each other, and AP2 sits at a different layer. The two projects describe the relationship symmetrically rather than hierarchically. UCP’s ucp-and-ap2.md says “AP2 serves as the trust layer for agent-led transactions” and lists AP2 under “Dependencies: Checkout capability”. AP2’s own overview calls itself “an extension for emerging agent-to-agent (A2A), model-context protocols (MCP), and Universal Commerce Protocol (UCP)”. Neither claims to sit under the other. So “AP2 vs ACP” is a layer confusion, while “ACP vs UCP” is a real question with no answer yet.

What does each layer refuse to do?

• ACP puts settlement on somebody else’s books. Its delegate-payment RFC states: “Payments, settlement, and compliance remain on the merchant’s rails.” Its discovery RFC lists “Agent registration or whitelisting” as a non-goal, on the ground that “Agent identity and authorization are separate concerns”.
• x402 v2 lists “Client-side budget management” and “Session handling mechanisms” under Out of Scope. Whatever stops your agent spending its whole allowance in one afternoon, the protocol is not it.
• AP2 offers a Trusted Agent Provider model that, by its own agent authorization document, “requires Verifiers to establish trust with every Agent Provider”. It defines no mechanism for doing that, populates no list, and provides no way to query one.

What does an agent actually know about the party it is paying?

Take x402, the most concrete case, since its payment authorisation is a signed structure you can read. The specification’s own version history dates v2.0 to 9 December 2025. The project is now the x402 Foundation, hosted by the Linux Foundation: the operational launch announcement is datelined “SAN FRANCISCO, July 14, 2026” and says “Since the Foundation’s intent to launch in April, 40 organizations have joined as members.”

Here is the entire authorisation object an x402 exact payment carries on EVM chains, from the scheme specification:

"authorization": {
  "from": "0x857b06519E91e3A54538791bDbb0E22373e36b66",
  "to": "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
  "value": "10000",
  "validAfter": "1740672089",
  "validBefore": "1740672154",
  "nonce": "0xf3746613c2d920b5fdabc0856f2aeb2d4f88ee6037b8cc5d04a71a4462f13480"
}

A payer, a payee, an amount, a validity window and a nonce. There is no URL, no content hash and no order identifier: nothing ties the signature to the thing being bought. A signature captured while buying one resource is a valid signature for any other resource priced the same at the same address. The systematic analysis puts the same point in protocol terms: the EIP-3009 authorization “commits to payee, value, and validity window but not to the resource”.

The party that checks all of this is the facilitator, a third service that verifies and settles on the merchant’s behalf. As the authors of Five Attacks on x402 put it, x402 “bridges these two layers through an off-chain facilitator whose correctness is neither enforced by the protocol nor verifiable by the client”. The agent is trusting an intermediary it did not choose, cannot audit, and has no protocol-level means of checking.

What is left is an address, an amount, and a listing that said the address belonged to a merchant.

What do the security papers actually break?

Five Attacks on x402 Agentic Payment Protocol (Li, Wang and Wang, 12 May 2026) runs over 25,000 payment requests across 48 configurations on Hardhat, Anvil and Base Sepolia, plus four production endpoints, and reports 95% Wilson score intervals. Findings were reported to Coinbase through HackerOne (#3679163, #3679179, #3679220).

• Revert-grant under optimistic execution. Where servers grant access before settlement confirms, the revert-grant probability reaches 5.18% at zero confirmations, a 400ms injected delay and a 5% reorg probability, over 5,000 requests per condition. Paid content delivered, payment reverted.
• Unauthorised settlement preemption. settle() is caller-unbound, demonstrated against a Permit2 proxy on Base Sepolia, where an unrelated attacker account settled someone else’s authorisation and consumed the nonce.
• Replay across the HTTP-to-chain boundary. A barrier-released batch of 1,000 concurrent replays of one payment header against a live testnet endpoint produced, in the strongest positive round, 248 HTTP-layer grants against 1 on-chain settlement.
• Proxy confusion. With nginx caching and no Cache-Control protection, all 1,000 unpaid requests received the cached paid content. With Cache-Control: no-store, private from a cold cache, 0 of 1,000 did. Caddy cached in neither condition. That one is a configuration fix, and it is not the default.
• Server-selection attacks. A single attacker server with crafted metadata won selection 71.8% of the time on MiniMax-M2.7, 69.4% on GPT-5.3 and 68.8% on Sonnet 4.5. Sybil aliases raised aggregate selection from 27.5% at one alias to 60.2% at five.

The paper’s audit summary reads: “none of the audited stacks binds payments to the intended resource.”

Free-Riding the Agentic Web (Ling et al., v2, 22 June 2026) states five invariants a pay-per-use protocol should hold, then measures four ways they break.

Flaw	What it is	Measured
F1	Cross-resource substitution	A signature minted for one resource accessed an equal-priced sibling in all 100 of 100 rounds
F2	Duplicate-settlement race	Under concurrency, 48% of trials swapped resources and 6% fully duplicated service
F3	Allowance overdraft	97.76% leakage: 47,277 wei delivered, 1,057 wei settled, on a 50-request burst against a 10,000-wei allowance
F4	Denial of settlement	86.95% leakage: 14,761 wei delivered at 1,926 wei cost, when a 50-req/s burst outran a 10-tx/s settlement limit

Its Theorem 1 is an impossibility result for pay-per-token billing: no output-only pricing function can be simultaneously fair to honest users and bounded against inflation of hidden reasoning tokens, with an unavoidable gap of √(1+Θ) invisible to the pricing layer.

A full pagination traversal of the CDP resource registry covered 24,875 listed resources, resolving to 915 merchants across 868 hosts after de-duplication, of which 99.6% expose only the exact scheme.

Whispers of Wealth (Debi, Zhu and Sen Gupta, 30 January 2026) red-teams AP2 with two prompt-injection techniques, “the Branded Whisper Attack and the Vault Whisper Attack which manipulate product ranking and extract sensitive user data”, against a working AP2 shopping agent. AP2’s mandates stay cryptographically correct throughout; what bends is the information used to build them. Protocol-Level Attacks on Agentic Commerce Platforms (Louck, 23 July 2026) reports 33 structural vulnerabilities across three platforms and “a 100% attack-success rate (ASR) wherever live-measured”, noting that “exploitation is deterministic and independent of which model an agent runs, so no model improvement removes them”.

Does reputation fix it?

ERC-8004 is the Ethereum standard for agent reputation: agents rate each other, and a registry carries the scores. It has enough deployment history to check.

Can Trustless Agents Be Trusted? (Xiong et al., v2, 8 July 2026) studies Ethereum, BSC and Base from protocol deployment through 13 May 2026, covering 173,441 registered agents.

• Only 3%, 4% and 15% of registrations respectively expose “a valid ERC-8004 registration file with at least one live service endpoint”. The overwhelming majority of registered agents are not reachable at all.
• 73.5%, 59.2% and 90.6% of reviewers exhibit coordinated Sybil behaviour.
• The median cost of fabricating or destroying a reputation is $0.055, $0.0042 and $0.0027 by chain, and “the aggregated score can be moved by a single input”.
• The share of feedback records with no payment proof and no task linkage is 98.7% on Ethereum, 100.0% on BSC and 99.3% on Base. Payment proofs account for at most 0.6% of observations.

The paper’s verdict is that “the Registry, as currently deployed, cannot function as a trust signal”.

Why does Know Your Agent point the wrong way?

Because the industry built the half of the problem merchants were paying to solve.

The layer under Visa’s Trusted Agent Protocol and Mastercard’s Agent Pay is agent identity: a cryptographic way for an automated client to prove which agent it is when it knocks on a merchant’s door. We cover that layer as a standard in AI agent identity. The shared framing is “Know Your Agent”, and the direction of travel is right there in the phrase. The merchant learns which agent is knocking. The agent learns nothing about the merchant.

Neither programme is a finished technical artefact. Visa’s Trusted Agent Protocol repository has no releases and no tags, and was last pushed on 28 October 2025.

Does MCP have a payment story?

Not an official one. SEP-2007: Add MCP Payment Support Specification was opened on 23 December 2025 and closed unmerged on 24 June 2026. Nothing has replaced it.

MCP’s ToolAnnotations defines exactly five fields, title, readOnlyHint, destructiveHint, idempotentHint and openWorldHint, so a client can warn a user before an irreversible call. The strings “price”, “payment” and “charge” appear nowhere in the 2026-07-28 schema. A tool that charges money is indistinguishable, in the schema, from one that does not.

x402 works around this in its MCP transport binding, which specifies that “When a tool requires payment, servers MUST return a tool result with isError: true containing the PaymentRequired data”, after which the client retries with the payment in _meta["x402/payment"]. That is a workable trick and a bad discovery story: a paid tool is discovered by calling it and being refused. An agent enumerating an unfamiliar server has no way to know, before it acts, which tools will cost money. AP2 ships MCP sample servers but still no normative MCP binding.

How big is agentic payment traffic really?

Nobody knows, including the people running it. Three sources you can fetch today cannot all be describing the same universe.

• The x402.org homepage, under a heading reading “Last 30 Days”, shows 75.41M Transactions, $24.24M Volume, 94.06K Buyers and 22K Sellers (read 17 August 2026). It cites no source and publishes no methodology.
• Coinbase’s facilitator documentation states, as a bullet headed “Proven at scale”, that “The CDP Facilitator has processed more than 100 million transactions and $28 million in payment volume across Base and Solana alone”. It is undated and cumulative.
• Free-Riding the Agentic Web reports that “As of May 2026, the Dune dashboard attributes approximately 130 million all-time transactions to x402”, and attributes 32.7% of facilitator volume to CDP.

Line those up. If the whole protocol had done roughly 130 million transactions all-time by May 2026, then a single recent 30-day window worth 75.41 million is over half of everything ever settled, three months later. And if CDP’s share is about a third, CDP’s all-time total should be somewhere near 43 million, not the “more than 100 million” its own documentation claims. The numbers may each be defensible under some definition, but no definition reconciling them has been published.

One figure you can compute rather than trust: $24.24M across 75.41M transactions is a mean of about 32 cents. Whatever that network is, it is machine-to-machine micropayments, not a commerce channel. The same paper notes that monthly volume “peaked in late 2025 and has since contracted”.

Where to go next

• If you are deciding whether to let an agent spend money: assume the merchant is unverified, cap what any single mandate can authorise, and treat the selection step, not the payment step, as the exposed one.
• If you are building the tools an agent calls: MCP prompt injection covers how listing and tool text steers a model, and MCP vs API covers why descriptions are attack surface rather than documentation.
• If you are working on the identity half: AI agent identity covers Web Bot Auth and what it does and does not prove.
• If you are untangling the acronyms: MCP vs ACP covers the other protocols wearing that name.
• If you want the underlying HTTP story: RFC 9110 §15.5.3 reads, in full, “The 402 (Payment Required) status code is reserved for future use.” Every 402 dialect in production is therefore a private extension, and at least three incompatible ones are deployed.

Dialect	Fields	Status
x402 v2	PAYMENT-REQUIRED, PAYMENT-SIGNATURE, PAYMENT-RESPONSE; “All x402 protocol information is communicated through headers” (transport spec)	v1 used X-PAYMENT and X-PAYMENT-RESPONSE instead
MPP	Reuses WWW-Authenticate and Authorization; adds one new field, Payment-Receipt	draft-ryan-httpauth-payment-01, 18 March 2026
Cloudflare pay-per-crawl	crawler-price, crawler-exact-price, crawler-max-price, crawler-charged, crawler-error (docs)	Vendor feature, five fields

Two notes on that table. The IETF draft is titled “The ‘Payment’ HTTP Authentication Scheme” and never uses the phrase “Machine Payments Protocol”; the MPP branding comes from Stripe and Tempo Labs, and the security literature names it “Machine Payments Protocol (MPP; Stripe and Tempo Labs)”. It is an individual submission with no working group and no IETF stream, active and expiring 19 September 2026, and it requests four IANA registrations. And of every field name in that table, none appears in the IANA HTTP Field Name Registry. The nearest registered neighbour is Signature-Input, from RFC 9421.

A paying agent can verify its own authorisation, and that some address will receive the money, but not that the address belongs to the merchant it meant to pay. Until something at the intent layer makes merchant identity checkable, the control that remains is a spending limit, and where you set it depends on the rail. On a mandate-based rail, cap what a single mandate can authorise. On one without mandate semantics, x402 having put client-side budget management out of scope entirely, the limit has to live outside the protocol, in the wallet or the funding account. Either way, treat every seller an agent picked out of listing text as a party you have not met.