x402 vs Mastercard AP4M: two bets on how agents pay

Two agentic-payment systems landed in front of Solana developers this spring, and they look superficially similar — both let an AI agent pay for something without a human clicking approve, both touch Solana, both talk about machine-to-machine commerce. But x402 and Mastercard's Agent Pay for Machines (AP4M) split the problem in opposite places. Understanding where each one draws its line is the fastest way to know which one you actually want.

The one-sentence version: x402 collapses authorization and settlement into a single on-chain act; AP4M pulls them apart — authorization onto public chains, settlement onto Mastercard's network. Everything else follows from that.

The core split

x402                              AP4M
────────────────────────          ────────────────────────
  agent's wallet = authority         on-chain credential = authority
        │                                  │  (Solana/Polygon/Base)
        ▼                                  ▼  "Verifiable Intent"
  pay 402 in USDC  ◀── same act      verify credential
        │             as settling           │
        ▼                                  ▼
  on-chain, done                     settle on Mastercard rails
                                     (fiat + stablecoins)

In x402, the agent's wallet is the authority and paying the 402 Payment Required challenge in USDC is the settlement — one signed Solana transaction does both jobs. In AP4M those are two layers: a public-chain credential says "this agent may spend," and a separate settlement over Mastercard's rails moves the money. Same goal, inverted architecture.

Dimension by dimension

Authorization

x402: implicit. Holding the keypair is the authorization — if you can sign the transfer, you can pay. There's no separate "is this agent allowed" check; spending limits live in whatever wallet or guard logic you wrap around the key.

AP4M: explicit and on-chain. Mastercard records a Verifiable Intent — spending caps and authorization rules — on a public chain (Solana, Polygon, or Base) so that any counterparty can verify the agent is acting within its mandate before settling. The authorization is a public, auditable fact rather than a property of key custody.

Settlement

x402: on-chain, in the response cycle. USDC moves on Solana (or another supported chain) as the second of two HTTP round-trips. The trust boundary is the chain — once the tx confirms, it's settled, full stop.

AP4M: on Mastercard's network, multi-rail across fiat (cards) and stablecoins, with guaranteed settlement. The public chain is not where value clears — it's only the credential ledger. The trust boundary is Mastercard.

Onboarding

x402: none. Any keypair with USDC can pay any x402 endpoint on the open internet — no signup, no account, no relationship. That permissionlessness is the entire point.

AP4M: you join. It's a permissioned network with 31 launch partners (acquirers, exchanges, infra); reaching it means an issuer or partner relationship, the way card acceptance always has.

Latency

x402: adds a Solana transaction to the call — roughly ~400ms minimum even with optimistic confirmation. Fine for occasional calls; for hot paths you batch (pay $1 upfront for 1,000 calls).

AP4M: sold on "machine speed" — the credential is read, not written, per transaction, and settlement rides existing high-throughput rails. The on-chain write happens when permissions are granted, not on every payment, which is how it aims to stay fast at high velocity.

Reach

x402: any endpoint that implements the spec. Today that's a growing but still crypto-native set of APIs and facilitators.

AP4M: Mastercard's acceptance footprint, eventually. That's the incumbent's structural advantage — if it ships, agents can in principle pay anywhere a card works, not just at x402-aware endpoints.

Maturity

x402: shipping. There's a public spec, reference SDKs, live facilitators, and you can build a seller today.

AP4M: announced June 10, 2026 — no public protocol spec, no API reference, no availability date. Mastercard's own chief product officer framed machine-to-machine as a five-year bet. It's a direction, not yet a dependency.

The summary table

                  x402                       AP4M (Mastercard)
────────────────  ─────────────────────────  ──────────────────────────
Authorization     implicit (key custody)      explicit on-chain credential
Where authz lives the wallet                   Solana / Polygon / Base
Settlement        on-chain USDC (Solana)       Mastercard rails (fiat+stable)
Trust boundary    the chain                    Mastercard's network
Onboarding        none — permissionless        join — partner/issuer
Latency           ~400ms (1 Solana tx/call)    "machine speed" (read-only)
Reach             x402-aware endpoints         Mastercard acceptance (goal)
Spec / SDK        public, shipping             not public yet
Best for          open agentic web, sub-cent   agent commerce at merchants

Where Solana sits in each

This is the part worth internalizing, because it's easy to conflate. In x402, Solana is the settlement layer — it's where the money actually moves, and sub-cent fees are what make $0.0001-per-call micropayments real rather than theoretical. In AP4M, Solana is a credentialing layer — one of three chains chosen to hold agent identity and spend rules, with the value clearing elsewhere. Same chain, two completely different jobs. That AP4M picked Solana for the identity role at all is a notable vote for where verifiable agent credentials are headed.

Which one do you reach for?

• Building an API or service an agent can pay per-call, today? x402. It exists, it's permissionless, and a single USDC transfer on Solana closes the loop. Start with the x402 seller guide.
• Want agents to transact with existing merchants over card rails, with guaranteed settlement? AP4M is the answer being built for that — but it's a watch-this-space, not a ship-this-week dependency. There's no SDK to integrate yet.
• Need agents to carry a verifiable, auditable identity with spending limits other parties can check? That's the genuinely new idea in AP4M, and it's conceptually an attestation — you can prototype the same shape on Solana now without waiting for Mastercard.

They're also not mutually exclusive. Nothing stops an agent from holding an on-chain credential and paying an x402 endpoint — the authorization model and the settlement rail are separable concerns, which is exactly the point AP4M's architecture is making. The broader agentic-payments field (x402, AP4M, Stripe/Tempo's Machine Payments Protocol, Google's AP2) is converging on one shared assumption: agents need a verifiable identity and a way to pay, and the identity is landing on public chains regardless of who clears the money. See the agentic-payments landscape for the wider map.

The honest read

Comparing a shipping open spec to a press release isn't entirely fair, and you should weight it accordingly: x402 is buildable now; AP4M is a stated intent with real partners behind it. If your decision is "what do I integrate this quarter," x402 is the only one of the two with a spec and SDKs. If your decision is "where is agent commerce going structurally," AP4M's decoupling of authorization from settlement — and its choice to put the authorization on public chains rather than a private table — is the more interesting signal, precisely because the incumbent didn't have to do it that way.

References

• x402: HTTP 402 reborn — internet-native payments on Solana
• Mastercard Agent Pay for Machines: card rails for agents, permissions on Solana
• Build an x402 seller on Solana
• The agentic-payments landscape, 2026
• x402.org — the open spec
• Mastercard — Agent Pay for Machines

Same question — how does an agent pay without a human — answered from opposite ends. x402 trusts the chain and asks for nothing else; AP4M trusts its own network and uses the chain only to vouch for who the agent is. For a Solana developer the useful realization is that Solana plays in both: as the rail that settles, and as the ledger that authorizes.