Mastercard Agent Pay for Machines: card rails for agents, permissions on Solana
Mastercard's AP4M (June 2026) lets AI agents transact at machine speed down to fractions of a cent. The design choice that matters: it stores agent permissions on public chains — Solana, Polygon, Base — while settling on Mastercard's own rails across fiat and stablecoins. What that split means next to the open x402 stack.
On June 10, 2026, Mastercard announced Agent Pay for Machines (AP4M) — a protocol for letting AI agents and machines transact with each other at "machine speed": high-frequency, low-latency payments down to fractions of a cent, executed in chains without a human approving each step. It extends the Agent Pay program Mastercard introduced in 2025 with four pieces it names as credentialing, permission controls, automated transacting, and multi-rail settlement.
For a Solana developer the headline isn't that Mastercard wants in on agentic payments — everyone does. It's where the authorization lives. AP4M writes the permissions a human grants an agent onto public blockchains — Solana, Polygon, and Base are the first three — while keeping settlement on Mastercard's own network. That split is the whole design, and it's worth understanding because it's a different bet than the one x402 makes.
The architecture: authorization on-chain, settlement off it
Most coverage led with "Mastercard does crypto." That misreads it. Mastercard is not asking banks to settle on a blockchain. It's using public chains as an authorization and credentialing ledger, and leaving the money movement on the rails it already runs. Two different layers, deliberately decoupled:
HUMAN ──grants──▶ AGENT
│
"Verifiable Intent": spending limits + auth rules
│
▼
┌──────────────────────────────────────────┐
│ AUTHORIZATION LAYER (public chains) │
│ Solana · Polygon · Base │
│ • agent credentials │
│ • permissions / spend caps │
│ • publicly auditable by any party │
└──────────────────────────────────────────┘
│ verified against ▲
▼
┌──────────────────────────────────────────┐
│ SETTLEMENT LAYER (Mastercard network) │
│ multi-rail: fiat (cards) + stablecoins │
│ • guaranteed settlement │
└──────────────────────────────────────────┘Mastercard calls the on-chain object Verifiable Intent: a programmable set of spending limits and authorization rules attached to an agent, recorded on a public chain so that multiple parties — the merchant, a facilitator, an auditor — can independently check whether an agent is acting within its mandate before money moves. The credential isn't in a private Mastercard database you have to trust and query; it's on Solana (or Polygon, or Base) where anyone in the transaction can read it.
Why a public chain for permissions
The instinct on a card network would be to keep the permission table internal. Putting it on-chain buys three things that matter for machine-to-machine commerce:
- Multi-party verifiability. When agent A pays agent B, B's side (and B's payment provider) can confirm A is authorized without calling back to Mastercard. The credential is a public fact, not a permission you have to ask the issuer about.
- Programmable, auditable limits. Spending caps and rules are enforced against an on-chain record, so "this agent may spend up to $50 on hosting this month" is something a third party can audit after the fact, not just trust.
- Interoperability. A credentialing ledger that isn't owned by one settlement network is, in principle, readable by others. That's the open-protocol pitch — whether it holds depends on the spec, which isn't public yet (more below).
This is recognizably the same idea as an attestation: a signed, verifiable claim about an actor that other actors can check. AP4M just scopes the claim to "what this agent is allowed to spend" and spreads it across three chains.
The canonical example
Mastercard's own framing: an entrepreneur opening a flower shop tells an agent to "build and launch the store's web presence within a budget." That one human request fans out into a chain of agent-executed purchases — buy a domain, buy hosting, buy stock images, stand up checkout — each a separate transaction across separate providers, all bounded by the one budget the human set. The on-chain permission is what each provider checks; Mastercard's rails are what each provider gets paid over.
How it sits next to x402
If you've read the x402 and x402 + MCP pieces, the contrast is the useful part. The two protocols decompose the problem differently:
x402 (Coinbase / open) AP4M (Mastercard)
───────────────────── ─────────────────────
Authorization : the wallet Authorization : on-chain credential
holds funds (Solana/Polygon/Base)
Settlement : on-chain Settlement : Mastercard rails
USDC, in the (fiat + stablecoins)
402 response
Trust boundary : the chain Trust boundary : Mastercard's network
Onboarding : none — any Onboarding : issuer / partner
keypair pays relationship
Spec : public Spec : not yet publicx402 collapses authorization and settlement into one on-chain act: the agent's wallet is the authority, and paying the 402 Payment Required challenge in USDC is the settlement. AP4M splits them: the on-chain credential authorizes, but the value still settles over Mastercard. The result is that AP4M can quote a card, reach existing merchants, and offer guaranteed settlement — at the cost of being a permissioned network you join, where x402 is an open endpoint any keypair can transact with.
These aren't mutually exclusive. AP4M is one of several agentic-commerce efforts now in the open — alongside x402, Stripe and Tempo's Machine Payments Protocol, and Google's AP2 — and an agent could plausibly hold an on-chain credential and still pay an x402 endpoint. The shared direction is the same one showing up everywhere: agents need a verifiable identity and a way to pay, and the verifiable identity is landing on public chains regardless of who moves the money.
The partners
Mastercard launched with 31 partners — a deliberately mixed roster of TradFi acquirers, fintechs, exchanges, and infra:
Acquiring / fintech : Stripe · Adyen · Checkout.com · BVNK
Exchanges / custody : Coinbase · OKX · Anchorage Digital
Chains / DeFi : Solana · Polygon · Base · Ripple · Aave Labs
Infra : Cloudflare · Ant International
(…over 30 named in total)Cloudflare is the tell for the developer use case Mastercard keeps citing: an agent paying a website "piecemeal" for data access — i.e. the same per-request, pay-as-you-go pattern x402 targets, which Cloudflare has also been building toward at the edge.
The honest read
This is an announcement, not an SDK. As of launch there's no public protocol spec, no API reference, and no availability timeline — Mastercard's own chief product officer framed machine-to-machine as a five-year bet, not a shipping product. So treat the "open protocol" language as intent: the interesting claim (a chain-agnostic credential others can read) is exactly the part you can't yet verify against a spec.
The trust boundaries are also worth naming. Settlement is Mastercard's network, so the guarantees, fees, and reach are theirs — the public chain is the authorization ledger, not where your money lives or clears. And "permissions on Solana" is real but narrow: it's credentialing and spend rules on-chain, not on-chain settlement. If you're building on Solana today and want an agent to pay autonomously now, x402 with a USDC wallet is the thing that exists and works (build an x402 seller); AP4M is the incumbent's answer to watch, and Solana being one of its three launch chains for agent identity is a meaningful vote for where verifiable agent credentials are going to live.
References
- Mastercard — Agent Pay for Machines launch (press release)
- Fortune — Mastercard launches a protocol to let AI agents pay each other
- Crypto Briefing — AP4M with Aave, Coinbase, OKX, Polygon, Ripple, Solana
- x402: internet-native payments on Solana
- The agentic-payments landscape, 2026
- x402 + MCP: how agents pay for tools
Strip away the card-network branding and AP4M is a clean architectural claim: put the agent's permission on a public chain where anyone can verify it, and keep the settlement wherever it already works. Mastercard picked Solana as one of the three places that permission lives — which makes the chain a credentialing layer for agents as much as a settlement one.
Keep reading
Both x402 and Mastercard's AP4M answer the same question — how does an agent pay without a human in the loop — and they answer it differently. One is an open HTTP status code settled in USDC on Solana; the other is a permissioned network that uses public chains only as a credential ledger. Here's the head-to-head, dimension by dimension, and a decision guide.
An agent that can call any paid API on the open internet sounds great until you ask: whose money, and what stops it from draining the wallet? This is the practical wiring — x402 inside the MCP tool loop, the @x402/svm client, and the Solana agent wallets (Coinbase, Crossmint, Privy, SendAI) that enforce spend caps and allowlists.
Everyone's racing to be the payment layer for AI agents, and the names blur together: x402, AP2, MPP, L402. They're not all competitors — some are settlement rails, one is an authorization layer, one is for humans at a checkout. Here's the map, what each is actually for, and why Solana ends up at the center of the settlement story.