Agentic Payments: How AI Agents Pay, and Which Protocol Does What

A conventional online payment assumes a human at a checkout page: they see the price, type or autofill a card, pass a challenge, and click pay. An agentic payment removes that human from the moment of payment while keeping them in control of the decision. The agent is software, usually built on a large language model, that acts for a person ("book a refundable flight under $400") or for a business ("buy search results whenever a research task needs them").

That shift breaks three assumptions at once, and each protocol below repairs one of them. The merchant cannot see a human. It needs a machine-readable catalog, cart and order flow instead of a web form. The issuer and merchant cannot tell a legitimate agent from an unwanted bot, and nobody can later prove what the human actually approved. Card payments have fixed costs and minimums that make sense for a $40 order but not for a fraction of a cent paid for one API call.

So when vendors say "agentic payments" they usually mean one of two different products. Agentic commerce is the consumer case: an assistant such as ChatGPT or Gemini buys a physical or digital product from a merchant, typically on a card. Machine payments are the developer case: an agent pays an API, a data source or another agent per request, typically in stablecoins. The protocols map cleanly onto that split, which is why the matrix below groups them by layer.

Each row was verified this year from the owner's own page or repository (listed under Sources). "Layer" is the job the protocol does; "rail" is how money actually moves.

Two patterns stand out. First, every card-network program in the table (Visa TAP, Mastercard Agent Pay, Stripe's Shared Payment Token inside ACP and MPP) solves the same core problem the same way: the agent never holds the real card number, it holds a scoped, revocable token with limits. Second, the two HTTP 402 protocols are the only ones designed for amounts below a typical card minimum, and both lean on stablecoins to get there.

You sell goods and want AI assistants to buy them: implement the ACP checkout spec if ChatGPT is your priority channel, and watch UCP if Google surfaces are; your payment provider handles the delegated token. You run an agent platform that spends users' money: AP2 mandates give you an auditable record of what the user approved; card programs (Visa TAP, Mastercard Agent Pay) are reached through your provider. You sell an API or tool to agents per call: x402 or MPP, and check your provider's minimums and session support before pricing below a cent. You build an agent that buys data: most data APIs still use an API key and prepaid or metered billing. TwitterAPI.io offers both: an API key with credits for every endpoint, and x402 on three read endpoints for an agent that holds USDC (see the worked example below). Our hosted MCP server at https://mcp.twitterapi.io/mcp (header Authorization: Bearer <your key>) lets an agent call X search and timelines as tools on the same credits.

ACP describes itself as "an open standard for programmatic commerce flows between buyers, AI agents, and businesses" (agenticcommerce.dev). The repository at github.com/agentic-commerce-protocol/agentic-commerce-protocol names OpenAI and Stripe as founding maintainers, uses the Apache 2.0 license, and states plainly that the specification "is currently in beta". Versions are dated rather than numbered: 2025-09-29, 2025-12-12, 2026-01-16, 2026-01-30 and 2026-04-17, the latest stable release at the time we checked, which the README says covers cart, feed, orders, authentication and MCP.

There are two machine-readable halves. The Agentic Checkout spec (openapi.agentic_checkout.yaml) is what a merchant implements so an agent can create and update a checkout and complete an order. OpenAI's developer docs put it directly: "Merchants integrate with OpenAI's checkout flow by implementing the Agentic Checkout Spec." The Delegated Payment spec (openapi.delegate_payment.yaml) is for payment service providers: it lets the buyer's credential be passed to the merchant's processor as a token, so the agent and the AI platform never see the card number. Stripe's Shared Payment Token was the first compatible implementation.

When ACP is the right reference: you sell physical or digital goods and want them purchasable inside an AI assistant. When it is not: you want to charge an agent a fraction of a cent per API call; ACP has no per-request settlement and inherits card economics.

Google announced the Agent Payments Protocol on September 16, 2025 "with a diverse group of more than 60 organizations", naming Adyen, American Express, Coinbase, Etsy, Mastercard, PayPal, Revolut, Salesforce and Worldpay among them (Google Cloud blog). AP2's core idea is the mandate: "tamper-proof, cryptographically-signed digital contracts that serve as verifiable proof of a user's instructions." The launch post described an Intent Mandate (what the user asked for) and a Cart Mandate (the exact items and price the user approved).

The current site, ap2-protocol.org, announces "AP2 v0.2 Release and FIDO Alliance Donation" and reorganizes mandates into a Checkout Mandate and a Payment Mandate, each with an open stage (constraints set before the cart exists, such as a budget) and a closed stage (authorization of one finalized checkout or amount). Standardization continues inside FIDO's agentic authentication and payments working groups. AP2 is framed as an extension for the Agent2Agent (A2A) protocol and usable with MCP, and it does not move money itself: it proves intent, then hands off to a rail. For crypto, Google and Coinbase published an A2A x402 extension at launch.

UCP sits one layer up. ucp.dev calls it "the common language for platforms, agents, and businesses", lists Google among co-developers with Shopify, Walmart, Amazon, Microsoft, Stripe, Booking.com and DoorDash, and says it handles "secure payment (AP2) via payment mandates and verifiable credentials". It started with retail and now has a lodging draft. Stripe's agentic commerce docs list UCP support alongside its own building blocks, which is a good sign that UCP and ACP will coexist at the checkout layer rather than one replacing the other.

Visa announced Visa Intelligent Commerce on April 30, 2025, saying it "opens Visa's payments network to developers and engineers building the first generation of true AI commerce", with Anthropic, IBM, Microsoft, Mistral AI, OpenAI, Perplexity, Samsung and Stripe named as partners (Visa press release). Its developer-facing protocol is the Trusted Agent Protocol (TAP): "a verifiable, cryptographic standard to help merchants differentiate legitimate agents from nefarious bots or web crawlers." A Visa-approved agent signs each request to the merchant with HTTP Message Signatures (RFC 9421); the merchant rebuilds the signature base and verifies it with the agent's public key. Sample code is at github.com/visa/trusted-agent-protocol.

Mastercard Agent Pay is the equivalent program on the Mastercard network, built on agentic tokens: a tokenized card credential issued for an agent instead of the real card number. We could not load Mastercard's own press or developer pages from our tools when we checked, so this row rests on Mastercard's official X posts, which we collected in the study below. In those posts Mastercard says Shop Pay is using Agent Pay ("Agentic tokens are helping keep the card details to themselves"), introduced Agent Pay for Machines in June 2026, "launching with 30+ partners", and in October 2026 opened Agent Pay for Machines early access after pilots with Cloudflare, Ant International, BVNK, AIsa, Coinbase, Base and Hype. We do not cite a Mastercard spec URL because we could not open one.

For a developer, the practical difference from ACP or AP2 is that you mostly do not implement the network programs yourself. Your payment provider, agent platform or CDN does, and the merchant opts in to recognize signed agents.

HTTP has reserved status 402 Payment Required since the 1990s without a standard way to use it. Two protocols now fill that gap. x402 (x402.org, "an open, neutral standard for internet-native payments") has the server answer an unpaid request with 402 and a PAYMENT-REQUIRED header; the client signs a payment payload, retries with a PAYMENT-SIGNATURE header, and gets the resource plus a PAYMENT-RESPONSE settlement receipt. Verification and on-chain settlement can be delegated to a facilitator. The reference repository started at github.com/coinbase/x402, whose README now calls it a development fork of the x402 Foundation's repo. The site says x402 "supports all EVM-compatible chains, Solana, and more" and that "stablecoin payments are the primary use case".

MPP (mpp.dev) is "an open protocol co-authored by Tempo and Stripe" that "works with stablecoins, cards, and bank transfers". Its normative spec is an individual IETF Internet-Draft, "The 'Payment' HTTP Authentication Scheme" (draft-httpauth-payment, revision 01, authors from Tempo Labs and Stripe), which reuses standard HTTP auth headers: the challenge in WWW-Authenticate, the credential in Authorization, the receipt in Payment-Receipt. MPP also defines sessions, so a client can be charged in sub-cent increments and settled later.

Stripe accepts both and settles them into a normal Stripe balance. Its machine payments docs ("Allow agents to pay-per-call using MPP and x402") list the rails: MPP on Tempo (USDC.e) and Solana (USDC), x402 on Base (USDC). They also list the minimums that decide what is economical: 0.50 USD for a card payment through a Shared Payment Token, 0.01 USDC for a stablecoin payment, and sub-cent charges inside an MPP session with a 0.01 USDC minimum settlement. In July 2026 Stripe's account reposted CEO Patrick Collison writing "Approaching 30k @mpp transactions per day".

Here is the case that touches us, and it shows why per-request payment design matters. An agent researching "what is X saying about MPP this week" calls the twitterapi.io search endpoint /twitter/tweet/advanced_search with "Machine Payments Protocol" -is:retweet and pages through 160 posts (8 pages of 20). The agent can pay us two ways. With an API key, it authenticates in the X-API-Key header and draws on prepaid credits ($1 = 100,000 credits; purchased credits never expire). With x402, it calls https://api.twitterapi.io/x402/twitter/tweet/advanced_search without a key, receives an HTTP 402 payment offer, and pays $0.006 in USDC on Base or Solana for each page of up to 20 tweets. TwitterAPI.io does not accept MPP or ACP.

Our x402 price is per request, so a page that returns fewer than 20 posts, or none, still costs $0.006, while credits are billed per post returned. The last two rows are not offers from anyone; they apply Stripe's published minimums to a per-page payment to show the floor. They explain why MPP added sessions and x402 added an upto scheme and batch settlement: a 402 payment is only economical for sub-cent data if many calls are rolled into one settlement. Prepaid credits are the older answer to the same problem: one top-up, then every result returned is metered against a balance. For the official API comparison, $5.00 versus $0.15 per 1,000 tweets is about 33x on the respective rate cards.

In practice, an agent that needs X data today gets an API key once (new accounts that pass the automatic bot check receive up to $1 of free credits (at most 100,000 credits, no card, one per person or network, expiring after 31 days)), stores it as a secret the agent runtime can read, and checks its balance with /oapi/my/info (recharge_credits) before a long job. An empty search still costs the 15-credit minimum ($0.00015), so a budget guard should count calls as well as tweets. The code below does exactly that, and it is the script that measured the protocol chatter in the next section.

We ran two small collections in 2026 to see how the protocols are actually discussed. Part A searched the newest original posts (retweets excluded) for each protocol's full name and for the phrase "agentic payments", up to 160 posts per query, 938 posts in all. Posts per day is the sample size divided by the time it spans, so it is a rate at collection time, not a trend. Part B read the newest posts of six official accounts: @stripe, @coinbase, @Visa, @Mastercard, @OpenAIDevs and @googlecloud (298 posts from 2026).

x402 is the conversation; the rest are footnotes to it. The bare string 'x402' ran at about 238x the rate of the next protocol name. It also works as the reference point for everything else: 20.1% of ACP posts, 32.1% of AP2 posts, 26.9% of MPP posts and 31.2% of Visa TAP posts also mention x402. Most of that x402 volume is crypto-flavored and low reach: 60.6% of posts used crypto terms, 34.4% were replies, and the median post had 44 views, against 884 for MPP posts and 773 for AP2 posts.

Checkout and authorization protocols are discussed as a set. Posts naming Visa's Trusted Agent Protocol named a second protocol 43.8% of the time (AP2 in 28.1%, ACP in 23.1%); ACP posts named UCP in 14.5%. That matches the layer reading above: people explain these together because a real deployment needs more than one.

The owners talk about agents far more than about agents paying. In Part B, @googlecloud mentioned agents in 38% of its posts but agents paying or buying in 2.5%. @OpenAIDevs mentioned agents in 11.7% and payments in none. @stripe was the only account that named a protocol (MPP in 6 of 100 posts, x402 in 1), and 14% of its posts were about agents paying. All 5 of @Mastercard's agent posts promoted its own programs. @Visa posted only 7 times in 2026 in our sample, none about agents.

"About agents paying" means the post names a payment protocol or program, or mentions agents together with a payment word (pay, checkout, commerce, purchase, wallet, merchant, card). It is a text rule, so it can miss a post that only shows a video, and it counted one generic @coinbase product roundup. Read the shares as direction, not precision.

The useful signal for a builder is where announcements land. If you track agentic payments on X, Stripe's account (and the @mpp handle it tags) and Mastercard's account carry product news; Google Cloud and OpenAI Developers talk about agents in general; and the x402 conversation lives mostly in crypto accounts rather than on any one company's feed. A saved search on the protocol names is a better feed than following the companies.

How we collected this. Question: how much is each agent-payment protocol discussed on X, and how do the companies behind them post about agentic payments? Data: /twitter/tweet/advanced_search (queryType Latest, retweets excluded) for six queries, up to 8 pages each, and /twitter/user/last_tweets for six organization accounts, up to 5 pages each. Window: the newest posts at collection time, collected in 2026; each query's span is shown in the table. Sample: 938 search posts and 298 timeline posts from 2026. Cost: 80 requests, 1,383 tweets and 6 profiles returned, 20,853 credits, about $0.21; the same reads on the official X API rate card would be about $6.97.

What the sample cannot show. Post counts are attention, not adoption: they say nothing about transaction volume, revenue or which protocol merchants deploy. Rates come from the newest posts only, so a launch day inflates them. 'x402' is a short token that also appears in token tickers and handles; we searched full names for the other protocols to keep matches clean, which undercounts posts that only use the acronym. Privacy: search results are reported as aggregates only and their raw pages were not kept; only organization accounts are named.