Agentic payments standards: 26 companies are writing the rules — and no seller is in the room

What actually launched on August 18, 2026

In New York on August 18, 2026, Rain — an enterprise infrastructure provider for stablecoin-powered card programmes — announced the Agentic Payments Alliance, a coalition formed to guide how AI agents will be allowed to transact on people's behalf. It launched with 26 founding members: Avalanche, Basis Theory, Chainalysis, Circle, Coinflow, Crossmint, delta Network, Episode Six, Evertec, Fireblocks, Fiserv, Kala, Lithic, Mastercard, Monad, PayOS, Rain, Remitly, Rialo by Subzero Labs, Sardine, Shift4, Solana, Turnkey, Uniswap Labs, Visa and Yuno.

The framing was explicitly about governance rather than product. Rain's co-founder and CEO Farooq Malik put it plainly: "No single company should get to decide how agents transact on someone's behalf." The group describes itself as a working coalition run collectively by its founding members rather than owned by any one of them, and its early agenda is shared research and frameworks, testing emerging standards for agent identity and authorization, and advocacy on the regulatory questions agent-led transactions raise. The number in the background, per PYMNTS' coverage of the launch, is a McKinsey estimate of US$3–5 trillion in global agentic commerce by 2030.

American Banker's read was the sharpest: this is an attempt at an EMV for the AI era — an industry body standardising authorization and risk protocols before every participant builds something incompatible. That comparison is doing a lot of work, and it is worth taking seriously. EMV is the reason a chip card works in a terminal on another continent. If agent payments end up with an EMV, it will matter.

It is also the fourth or fifth body with a claim on this territory. Visa and Mastercard already run competing agent-payment protocols. Google has AP2. OpenAI and Stripe have ACP; Shopify and Google have UCP. And the Linux Foundation announced the x402 Foundation on April 2, 2026, which became operational in July with roughly forty members — Adyen, AWS, American Express, Base, Circle, Cloudflare, Coinbase, Fiserv, Google, KakaoPay, Mastercard, Microsoft, Polygon Labs, PPRO, Shopify, Solana Foundation, Stripe, thirdweb and Visa among them. We covered that one when it happened, in the x402 Foundation and what an open standard changes.

Read the member list. It's a map of the buyer side.

Sort the 26 founding members by what they actually do and the picture resolves immediately:

• Card networks: Visa, Mastercard.
• Processors and acquiring platforms: Fiserv, Shift4, Evertec, Yuno, Coinflow, PayOS.
• Card issuing and credential infrastructure: Rain, Lithic, Episode Six, Basis Theory.
• Wallets, custody and key management: Fireblocks, Turnkey, Crossmint.
• Chains and protocol infrastructure: Solana, Avalanche, Monad, Rialo, Uniswap Labs, delta Network, Kala.
• Risk, fraud and analytics: Sardine, Chainalysis.
• Issuer and remittance: Circle, Remitly.

That is a complete and competent map of the plumbing on the paying side of an agentic transaction: how the agent is funded, how it is credentialed, how the risk is scored, where the money moves. What is missing is the other half of every transaction. No merchant. No API provider. No SaaS company, marketplace, publisher, data vendor or software business that would be the recipient of these payments.

To be fair where fairness is due: the x402 Foundation's roster does include a commerce platform in Shopify, and Amazon and Google both sit inside these conversations wearing several hats at once. But the pattern holds across both bodies. The organisations writing agentic payment standards are, overwhelmingly, the organisations that make money moving money. The business that has to decide whether to accept an agent's payment — and that carries the loss if the answer turns out badly — is represented by nobody.

This is not a conspiracy. It is how payment standards have always been written, and it is exactly why merchants spent thirty years litigating interchange. It is worth naming anyway, because it tells you something practical: the questions on the agenda are the questions that matter to the buyer side, and they are not the same as yours.

Their four hard problems, and your four

Set the two lists side by side and the asymmetry becomes obvious.

Look at the middle column. Three of the four problems are artefacts of the instrument, not of agents. Identity, delegated authority and fraud attribution are hard because a card payment is a promise: a credential presented now, funded later, reversible for months afterwards. Everything downstream — the scoped card, the spend cap, the anomaly detector, the liability framework — exists to manage the gap between the promise and the money.

Close that gap and most of the problem set closes with it. When an agent pays by transferring value that settles on arrival, there is no window in which the payment might not be real. The agent either holds the funds or the request fails. You don't need to know who the agent is in order to know you were paid — you need to know that for your own compliance file, which is a different obligation you already have and which the rail does not change.

This is also why the fourth question — rewards — is a genuinely interesting problem for card networks and a non-problem for a seller. If you have ever wondered why the incumbents are moving carefully here, that row is the answer. A large part of what a card network sells is the loyalty and rewards layer, and an agent buying on your behalf breaks the human it is attached to.

The cost of waiting for a standard that isn't about you

Standards bodies take years. EMV, the analogy everyone reached for, was specified in the mid-1990s and took two decades to finish rolling out in the United States — and it only moved when a liability shift forced it. The APA is roughly two dozen members old and recruiting. There are at least four other consortia with overlapping claims. Nobody sensible expects convergence this year.

Meanwhile the demand side is already funded and shipping. AWS made agent payments generally available in Bedrock AgentCore this month — we wrote that up in AgentCore payments going GA with x402. Cloudflare issues wallets and identities to agents. Coinbase, Google, OpenAI and Binance all have buyer-side agent payment stacks in production. And the demand is measurable: in the week of August 17, 2026, x402 carried 8.7 million stablecoin transfers, roughly double the prior week, at an average of about four cents each — the detail is in x402's busiest week of 2026.

Four cents is the whole story in one number. It tells you two things at once: the agent economy is real and growing fast, and it cannot run on card rails, because a four-cent transaction cannot absorb a fixed authorization fee, let alone a dispute. We took that argument apart properly in virtual cards for AI agents vs x402.

So the practical risk of waiting isn't that you back the wrong standard. It's more mundane: for the next several years, agents will be buying things, and the sellers who are reachable will be reachable and the ones who aren't, won't. A committee will not send you revenue while it deliberates.

The seller-side answer that already exists

The reason no consortium is convening to solve the seller's side of agentic payments standards is, bluntly, that it is the easier half — and it already has a working answer.

x402 is an open protocol that uses the long-dormant HTTP 402 Payment Required status code. An agent requests your endpoint; the endpoint answers 402 with a price and payment details; the agent pays; the request goes through. It was contributed by Coinbase to a neutral home at the Linux Foundation, and it settles in stablecoins — in Payzum's case, USDC on Base, where a transfer confirms in roughly two seconds and costs a fraction of a cent in gas.

Here is Payzum's exact role, stated precisely, because this is the part that gets misreported. Payzum is the middleware / proxy that sits in front of your existing API. You do not implement a protocol. In the dashboard you configure the endpoint you already run, the API key or bearer token it already uses, and a price. Payzum then publishes an x402 URL, returns the 402 to the agent, settles the payment through an external facilitator — currently Coinbase's — and proxies the paid call to your real endpoint with your key. Payzum is not the facilitator today; that is a future goal, not a present claim.

And the money never touches us. Payzum is non-custodial: the USDC lands directly in a wallet you control. There is no Payzum balance, no settlement delay, no reserve, nothing to freeze. The settlement is the payment. Pricing is usage-shaped — around 1,000 transactions per month free, then roughly $0.001 per transaction plus gas.

Notice what that arrangement does to the four questions on the alliance's agenda. You don't need to identify the agent to be sure of the payment. You don't need a delegation framework, because the agent cannot spend money it doesn't hold. You don't need fraud attribution, because there is no reversal window to attribute. And you don't need rewards portability, because you were never selling loyalty points — you were selling API calls.

How it works, step by step

1. Pick one endpoint worth metering. Not your whole product — one route an agent would plausibly want to buy: a search, a lookup, an enrichment, a generation, a scrape. Ideally something you currently give away or gate behind a signup that no machine will ever complete.
2. Connect a wallet you control. Settlement goes there directly. Choose whether incoming payments auto-convert to USDC or USDT so what you hold is the dollar token you decided on, not whatever arrived.
3. Configure the endpoint and a price in the dashboard. Your existing URL, your existing API key or bearer, and what one call costs. Payzum publishes the x402 URL and handles the 402 handshake, the facilitator and the proxying. No code in your service, no protocol to implement, no new deploy.
4. Wire it into what you already run. REST API with API keys, signed webhooks and an integration playground, so your billing, analytics or entitlement system learns about a paid call the moment it settles. The full mechanics are in x402: pay per API call.
5. Make yourself findable, then price honestly. Agents discover priced endpoints; if yours answers a 402 with a sane price, it is buyable. Start at a price that makes sense per call rather than per seat — pricing for machines is a different exercise, which we go through in x402 vs API-key billing.

Where this shows up in real businesses

None of the below requires anyone to have finished writing a standard.

• The API company with a signup wall no machine can pass. A data or enrichment provider gets agent traffic that bounces off a free-tier registration form requiring an email, a credit card and a human. Publishing the same endpoint at a per-call price turns rejected traffic into revenue — the argument in full at let AI agents pay for your API.
• The MCP server nobody is paying for. Someone built a genuinely useful tool, it gets called thousands of times a day inside other people's assistants, and it earns nothing because there was no way to charge a caller who isn't a person. See monetising an MCP server with x402.
• The four-cent transaction. A price of $0.0004 per call is impossible on any card rail — the authorization fee alone exceeds it. On USDC on Base, per request, it's ordinary.
• The seller who just wants finality. Agent-initiated purchases raise a liability question nobody has answered cleanly on reversible rails — who eats it when an agent buys wrongly. We looked at that in agentic commerce and chargeback liability. On a settled rail the question doesn't arise, which is not the same as saying it's free: it means your refund policy has to be written down, because refunds are payments you initiate.

Waiting for the standard vs publishing a paid endpoint today

Objections worth taking seriously

"Isn't x402 also just one of several competing standards?"

Yes, and pretending otherwise would be dishonest. x402 sits alongside AP2, ACP, UCP, Visa's and Mastercard's agent protocols and now the APA's forthcoming frameworks. What makes the risk asymmetric is which side of the transaction you're on. The buyer side has to pick a stack and build to it. The seller side, in this arrangement, keeps its own endpoint, its own API key and its own wallet, and rents a gateway in front. If a different protocol wins, what changes is the gateway configuration — not your service, not your billing, not where your money lives. Also worth noting: x402 already appears as an extension inside Google's AP2, and several of the APA's founding members sit in the x402 Foundation too. These bodies overlap more than the headlines suggest.

"Visa and Mastercard are in every one of these. Doesn't that mean cards win?"

It means they intend to be present wherever it lands, which is rational and tells you nothing about the economics. The constraint on cards in the agent economy isn't strategy, it's arithmetic: a rail with a fixed per-authorization cost and a months-long dispute window cannot serve a market whose average ticket is four cents. Cards will very likely win the large, human-approved agentic purchase — a flight, a hotel, a restocking order. Machine-to-machine micropayments for API calls are a different market with different physics, and the honest position is that both will exist.

"Shouldn't I wait until the liability rules for agent purchases are settled?"

If your product is a high-ticket physical good sold to consumers through an agent, there is a real argument for watching that space — the liability question is genuinely unresolved and it isn't yours to solve. If you sell API calls, tools, data or compute, the wait buys you nothing, because the liability problem you'd be waiting on is a property of reversible instruments. And the compliance file you keep is unchanged either way: customer records, invoicing, sanctions duties and tax obligations do not move because the settlement instrument changed. What improves is the evidence — a timestamped, verifiable record of an exact amount arriving at an address you control, plus a full audit log.