Agentic protocols
A map of the standards around agent payments, so you can tell which ones matter for what you are building. Status is as of 22 October 2026, taken from the specifications and announcements themselves. This area moves fast: nearly every protocol shipped a breaking change in 2026, so pin the version you build against and check the source before relying on a detail here. Payware does not implement these protocols today (see Agentic payments).
Status at a glance
| Protocol | Owner | Layer | Status |
|---|---|---|---|
| MCP | Agentic AI Foundation (Linux Foundation) | Transport | Live, stable (spec 2026-07-28) |
| A2A | Linux Foundation | Transport | Live, stable (v1.0, March 2026) |
| Web Bot Auth | IETF working group | Identity | Draft, deployed at Cloudflare and Akamai |
| Visa Trusted Agent Protocol | Visa, with Cloudflare | Identity | Live and pilot |
| UCP | Google, Shopify, Etsy, Wayfair, Target, Walmart | Checkout | Live (Google AI Mode and Gemini) |
| ACP | OpenAI and Stripe | Checkout | Live (beta). ChatGPT scaled back in-chat checkout in March 2026 and mainly uses it for product discovery |
| AP2 | Google, contributed to the FIDO Alliance | Mandate | Draft (v0.2). v0.1 mandates are superseded |
| Verifiable Intent | Mastercard, contributed to the FIDO Alliance | Mandate | Draft (v0.1) |
| x402 | x402 Foundation (Linux Foundation) | Machine payment | Live (V2) |
| MPP | Stripe and Tempo | Machine payment | Live at Stripe and Tempo; IETF draft |
| L402 | Lightning Labs | Machine payment | Live, niche |
| Visa Intelligent Commerce | Visa | Card network | Live |
| Mastercard Agent Pay | Mastercard | Card network | Live (US and EU, including Romania) |
| American Express ACE | American Express | Card network | Pilot; some specifications still in development |
| EMVCo Agentic Payments Framework | EMVCo | Standards | Draft |
"Live" means production traffic with real money. "Draft" means published but not declared stable. Early volumes are small: announced partners far outnumber real transactions, and many European "live" payments are pilot purchases.
Transport: MCP and A2A
MCP (Model Context Protocol) is how an agent calls a tool. Payment tools exist from Stripe, PayPal, Adyen, Worldpay and others. Three patterns appear: a payment provider's tool server that the agent operates for a merchant; paid tools that charge per call (x402 or MPP carried inside a tool call); and commerce over MCP (UCP and ACP both define an MCP binding for checkout). The 2026-07-28 revision is stateless, and URL-mode elicitation lets a server send the person to an out-of-band page (for a bank challenge or consent) so credentials never pass through the model. A payment MCP server should default to read-only, require out-of-band confirmation for money movement, and apply per-tool spending limits.
A2A (Agent2Agent) carries tasks between agents, for example a shopping agent and a merchant's agent. It is not a payment
protocol, but a task can pause in an input required or auth required state while a payment or authentication
happens, and payment extensions (AP2 and an x402 extension) ride on it. Agents publish an Agent Card at
/.well-known/agent-card.json.
Identity: knowing which agent is calling
Web Bot Auth signs each request with an HTTP message signature (RFC 9421). The signature proves which agent operator sent it, checked against a published key directory, usually at the merchant's CDN. It does not prove which person the agent acts for or what they intended, so user binding still relies on tokens and mandates. Visa's Trusted Agent Protocol builds on it with tags for browsing and for paying, and Mastercard Agent Pay and UCP use the same signatures. Other "know your agent" efforts include Skyfire's KYAPay tokens, the Agent Name Service, the on-chain ERC-8004 registries and the card networks' own agent registries.
Commerce: UCP and ACP
Both let an agent discover a merchant, build a cart and complete a checkout while the merchant stays merchant of record and keeps normal card liability.
| UCP | ACP | |
|---|---|---|
| Main surface | Google AI Mode and Gemini; open to any platform | ChatGPT for discovery; other agents for checkout |
| Discovery | /.well-known/ucp profile, plus a merchant feed | Product feed |
| Versioning | Date-based protocol and per-capability versions | Date-based API-Version header |
| Transports | REST, MCP, A2A, embedded | REST, MCP |
| Payment | Pluggable payment handlers (Google Pay, Shop Pay, any payment provider) and an AP2 extension | Payment handlers and Delegate Payment (a scoped vault token) |
| Agent identity | RFC 9421 signatures and a UCP-Agent header | Signature and timestamp headers |
| Bank challenge | requires_escalation with a continue_url | authentication_required |
In ACP, a delegate payment call hands the payment provider card data plus an allowance, and returns a token bound to one merchant, one checkout, a maximum amount and an expiry. The agent then completes the checkout with that token, so the merchant never sees the card and the agent cannot spend beyond the allowance.
Authorisation: AP2 and Verifiable Intent
These prove the person agreed. AP2 and Mastercard's Verifiable Intent converged on the same selective-disclosure (SD-JWT) credentials, and both were handed to the FIDO Alliance in April 2026.
- An open mandate records constraints the person signs once, on a trusted surface such as a wallet or bank app with a passkey: an amount range, a budget, allowed merchants or payees, a recurrence, an expiry. It is bound to the agent's key.
- A closed mandate covers one concrete transaction: the merchant-signed cart and the payment, signed by the person (human present) or by the agent within an open mandate (human not present).
- A receipt closes the loop.
Together they form a chain of evidence: person, agent, merchant, receipt. It does not by itself change card-network liability rules; networks and issuers still have to recognise the evidence. Whether a passkey-signed mandate can count as strong customer authentication for later payments is not settled in the EU.
Machine payments: x402, MPP and L402
For software paying for an API call, a page or a tool without an account or a card form. All three use HTTP status 402 Payment Required: the server answers with what it wants, the client pays and retries.
- x402 settles in stablecoins (mainly on Base and Solana) through an optional facilitator that verifies and settles
but cannot move funds beyond what the client signed. Schemes include
exact(a fixed amount),upto(a maximum, settled on actual use), batched settlement and auth-capture. Payments are final on-chain: no chargebacks. - MPP (Machine Payments Protocol) is a payment-method-agnostic HTTP authentication scheme (
WWW-Authenticate: Payment) covering stablecoins and, through Stripe, cards and wallets, with one-off, session and subscription intents. - L402 pays a Lightning invoice and reuses the resulting credential.
x402 and MPP use different 402 headers, so servers often offer both. Treat verified as not yet paid: confirm settlement before delivering. Published volume figures for x402 conflict and include test traffic, so do not size a plan on them.
Card networks and agentic tokens
Visa, Mastercard and American Express converge on the same four building blocks: agent registration, agentic tokens (a network token provisioned per agent with spend controls, so the card number never reaches the agent), consumer authentication with passkeys, and signals the merchant and issuer can read (Web Bot Auth signatures at the CDN, plus agent and intent data in the authorisation). In Europe, Visa Agentic Ready had 31 issuers complete live agent purchases by July 2026, and Mastercard Agent Pay completed its first Romanian payment in April 2026. Network specifications are gated to issuers and acquirers, so details beyond the public pieces are not available.
Payment providers and open banking
Stripe offers Shared Payment Tokens (a limited, single-merchant credential) in the EEA, plus machine payments through MPP and x402. PayPal, Adyen, Checkout.com, Worldpay, Shopify and Coinbase each support a subset of the protocols above; most launched in the US first. For paying from a bank account, there are three routes: payment initiation per purchase (the person authenticates in the bank app each time), mandated recurring or variable payments (UK variable recurring payments, Polish BLIK mandates, SEPA Direct Debit) and instant credit transfers with a request to pay (in Romania, the RoPay request to pay over the national instant scheme). A service that initiates payments from someone's account on their behalf is likely to need payment-initiation authorisation.
Regulation to keep in mind
- PSD2 strong customer authentication applies to payer-initiated electronic payments. An agent purchase can be customer-initiated with authentication at the time, merchant-initiated after an authenticated mandate, or use an exemption. Which of these an "agent within a mandate" qualifies for is unsettled, and no supervisor has said.
- PSD3 and the Payment Services Regulation keep strong authentication and add fraud-data sharing and liability for impersonation fraud. Nothing in the text is specific to agents, and dates may still move.
- MiCA governs stablecoins and crypto-asset services, so settling x402 or MPP payments in stablecoin needs its own legal analysis.
- Open questions: who bears the loss when an agent buys the wrong item within a valid mandate, and how profiling data in feeds and risk signals fits GDPR.
Sources
Primary sources, as of 22 October 2026: the specifications and repositories for MCP, A2A, x402, AP2, UCP, ACP, Visa Trusted Agent Protocol, Web Bot Auth, MPP and Verifiable Intent.