Agentic Payments

Intro

Visa, Mastercard, Shopify, OpenAI, Stripe, AWS, Cloudflare, Google, Base, Solana and Tempo. They operate on different layers and are giants in their own various industries. But they've all been moving toward the same thing over the past year at breakneck pace: agentic commerce.

Getting an AI agent to pay for something without human intervention is no longer a pipe dream. It's already here, and the alpha is out there. What this requires is re-imagining what payments mean across checkout, settlement, invoicing, billing, and every flow in between. Each of those layers has decades of assumptions baked in, and almost all of them assume a human is in the loop. Now that the human is being replaced with an agent, everyone is racing to stay relevant.

Even though we're still early in this space, the past year alone produced more agentic-payments protocols, specs, and announcements than the previous decade of internet payments combined. Let's try to make sense of the industry we're in.

Timeline

Context matters, so here's how the space has evolved over the past 12 months.

1. April 29, 2025 — Mastercard unveils Agent Pay with Agentic Tokens, partnering with IBM watsonx, Braintree, and Checkout.com. (mastercard.com)
2. April 30, 2025 — Visa launches Intelligent Commerce at its Global Product Drop, opening its network of 4.8B credentials and 150M merchants to AI agents (partners: OpenAI, Anthropic, Stripe, IBM). (usa.visa.com)
3. May 6, 2025 — Coinbase announces x402, an HTTP-native stablecoin payment protocol resurrecting the dormant HTTP 402 status code for agent and API micropayments. Launched in collaboration with AWS, Anthropic, Circle, and NEAR. (coinbase.com)
4. September 17, 2025 — Google announces Agent Payments Protocol (AP2) with 60+ partners (Mastercard, AmEx, PayPal, Coinbase, Adyen, etc.); also launches A2A x402 extension for crypto-native agent payments with Coinbase, Ethereum Foundation, and MetaMask. (Google Cloud Blog)
5. September 23, 2025 — Cloudflare announces x402 support in its Agents SDK + MCP servers, and co-launches the x402 Foundation with Coinbase. (blog.cloudflare.com/x402)
6. September 29, 2025 — Stripe + OpenAI release the Agentic Commerce Protocol (ACP) under Apache 2.0, alongside Shared Payment Tokens (SPTs) — a scoped, merchant-bound payment primitive that lets agents initiate payments without exposing buyer credentials. ChatGPT Instant Checkout goes live with Etsy and 1M+ Shopify merchants in pipeline. (stripe.com newsroom) (openai.com — Buy it in ChatGPT)
7. October 14, 2025 — Visa launches Trusted Agent Protocol (TAP) with Cloudflare, signing agent identity into HTTP request headers; partners include Adyen, Stripe, Shopify, Coinbase. (investor.visa.com)
8. October 28, 2025 — PayPal launches Agentic Commerce Services (Agent Ready + Store Sync) with Wix, BigCommerce, Cymbio, Shopware. (newsroom.paypal-corp.com)
9. January 2026 — Google + Shopify launch the Universal Commerce Protocol (UCP) at NRF 2026, endorsed by 20+ partners (Walmart, Target, Etsy, AmEx, Mastercard, Stripe, Visa, Best Buy). (Announced at NRF in mid-January; specific day not verified from a primary Google/Shopify source.) (shopify.com/news)
10. March 18, 2026 — Stripe + Tempo launch the Machine Payments Protocol (MPP) alongside the Tempo Mainnet (a Paradigm-built payments L1). MPP is an open, HTTP-402-based standard letting agents request, authorize, and settle payments programmatically across any service, API, MCP server, or HTTP endpoint. (stripe.com/blog/machine-payments-protocol) (mpp.dev)
11. April 29, 2026 — Stripe launches Link wallet for agents + Link CLI + Issuing for agents at Stripe Sessions 2026. The first consumer-facing wallet purpose-built for agentic commerce:
    • Roadmap: native support for agentic network tokens and stablecoins "soon". (stripe.com/blog/giving-agents-the-ability-to-pay) (github.com/stripe/link-cli) (link.com/agents)
12. May 7, 2026 — AWS launches Bedrock AgentCore Payments with Coinbase + Stripe, enabling autonomous Bedrock agents to make real-time online purchases. Built on Coinbase's x402 for stablecoin rails, with Stripe's Privy wallet as the payment connection. (coindesk.com)

Card networks (Visa, Mastercard, etc.) moved fast in announcing new initiatives and specs, and they were quickly followed by crypto networks and blockchains. That left a bunch of gaps across isolated layers of the stack such as identity, mandates, checkout, and discovery, which the second wave of protocols (TAP, AP2, ACP, UCP, covered in the next section) tried to fill.

Protocols

Let's look at the different protocols and which layer of the stack they operate in.

There is an ongoing power grab here. Different providers are establishing protocols for different layers in which AI agents will operate, each one trying to make sure their layer is the one that becomes the standard. A quick breakdown:

• x402 / MPP (the transport layer): These protocols operate on the HTTP layer. They define how a resource signals that a payment is needed before access is granted, how the agent submits a signed payment, and how the server verifies and settles it.
• Trusted Agent Protocol (TAP): Visa's attempt at establishing an identity layer for AI agents. The agent's identity is included as an HTTP request header for merchants to verify. This is critical for Visa's merchants, who already pay for fraud and dispute infra that assumes a cardholder is always a human.
• Agent Payments Protocol (AP2): Google's spec, which outlines user authorisation, authenticity and accountability when an agent is performing payments. This is enabled through a tamper-proof, cryptographically signed contract proving the user authorised a specific purchase. Deliberately kept payment-agnostic, and supports x402 to plug the on-chain rail in directly.
• Universal Commerce Protocol (UCP): Google + Shopify's protocol for how agents discover what's for sale across the entire commerce ecosystem, build an agent-shaped shopping session, and complete a purchase. More of a coordination layer than a wire protocol.

x402

x402 is very opinionated towards the blockchain stack and on-chain payment rails. When it was initially introduced, USDC was the only token used for settlement, and settlement happened on the Base L2 network.

But today, x402 is token and chain agnostic. Ethereum, Polygon, and even non-EVM chains like Solana now enable x402 payments (Solana now hosts the largest share of x402 traffic).

x402 re-purposed the HTTP 402 status code, which is used to indicate that the requested resource requires a payment. In a nutshell:

1. The client tries to request the resource. The server responds with a 402 status code, indicating that a payment is required (the status code itself has been sitting in the HTTP spec since Tim Berners-Lee's earliest drafts in the early 90s, man really had the foresight). In the response payload, the following is also returned as a structured JSON:

   {
     "maxAmountRequired": "0.10",
     "assetType": "ERC20",
     "assetAddress": "0xA0b8...eB48",
     "paymentAddress": "0xRecipient...",
     "network": "base-mainnet",
     "expiresAt": "2026-05-24T12:05:00Z",
     "nonce": "x7Tg2pLqR9mKvNwY3hBcZa",
     "paymentId": "pay_abc123"
   }

2. Based on the payment details, the agent crafts a signed transaction using a private key. It then retries the original request with a custom X-PAYMENT header whose value is the base64-encoded signed payment payload (an EIP-712 typed-data signature for EVM chains).

3. A separate service called the facilitator handles on-chain verification and settlement, so the merchant doesn't have to run a node, hold a wallet, or know anything about gas. Coinbase operates the leading facilitator, and 20+ others have emerged in the ecosystem. After settlement, the merchant returns the resource plus an X-PAYMENT-RESPONSE receipt header.

Crypto rails are perfect for micropayments. Card networks have minimum viable transaction sizes (an agent paying $0.0001 per inference call simply cannot exist on Visa), and x402 fits in well here. x402 has gained some real traction too: per x402scan.com, the protocol has facilitated ~75M transactions and ~$24M cumulative volume in a recent 30-day window, with Solana hosting the largest share.

MPP

MPP takes x402's core ideas and extends them in several ways:

• Payment-rails agnostic. Payments can settle via fiat (Stripe) or on-chain (Tempo, Solana, Ethereum) under the same protocol.
• Properly specified error handling with defined error codes, retries, idempotency rules, and a clean concurrency model.
• First-class sessions. Persistent authenticated channel for streamed, pay-as-you-go workloads like LLM token billing, rather than just one-shot transactions.

Unlike x402, MPP doesn't invent any custom headers. It deliberately extends existing HTTP specs. The request-response flow looks like this:

1. The client requests a resource. The server responds with a 402 status code and a WWW-Authenticate header (this is the same header that 401 requests use to advertise the authentication scheme the client must use). MPP just registers Payment as a new scheme name (existing ones include Basic, Bearer, Digest):

   WWW-Authenticate: <SchemeName> <parameters>
   WWW-Authenticate: Payment id="abc", method="stripe", intent="charge", request="..."
   

   The required parameters are:

   • id — a unique handle for this challenge, cryptographically bound to all the other parameters, formed via id = HMAC-SHA256(server_secret, realm | method | xx..)
   • realm — the standard HTTP "protection space" (e.g. api.example.com).
   • method — the payment method (stripe, solana, tempo, lightning, invoice, etc). This is what makes MPP method-agnostic.
   • intent — the operation type (charge, authorize, session).
   • request — a base64url-encoded JSON blob containing method-specific data (amount, currency, recipient, etc.)

   This whole thing is referred to as the Payment Challenge.

2. The client then fulfils the challenge, i.e. actually makes the payment. If it's on-chain, the client signs a transaction with its private key and the signature goes into the payload. If it's off-chain via Stripe, the client creates a Stripe payment intent (using its API key against Stripe's machinery) and the intent ID goes into the payload.

3. The client re-submits the original request with an Authorization header set to Payment <base64url-credential>. The credential is a JSON object containing the original challenge (byte-for-byte identical), an optional source field (identifying the payer), and a payload field carrying the method-specific proof of payment. This is the Payment Credential.

There's a lot more nuance to this, especially around handling retries, expired challenges, sessions, and concurrency, but we won't go too deep into that. What's worth exploring is how MPP achieves payment-method agnosticism, and what security guarantees it offers.

How MPP stays payment-method agnostic

While x402 is locked into on-chain rails, MPP is framework- and payment-rails agnostic. This is enabled through the method parameter plus an IANA registry.

1. The method parameter is a required field inside the WWW-Authenticate: Payment challenge. Its value (stripe, solana, etc.) tells both the client and server which payment rail is being used, and it's also used when interpreting the request and payload JSON blobs.
2. The IANA registry is where those method names are formally listed. IANA (the Internet Assigned Numbers Authority) maintains the official registries for HTTP protocol identifiers (status codes, MIME types, auth schemes, etc.). Registering payment methods there makes the existing set extensible without re-versioning or modifying MPP itself. Anyone can write a small spec for a new method's request and payload, register the name, and existing clients keep working.

MPP defines the envelope (id, realm, method, intent, expires, request), and each registered method defines what goes inside the opaque request and payload blobs. A credential looks like this:

{
  "challenge": {
    "id": "x7Tg2pLqR9mKvNwY3hBcZa",
    "realm": "api.example.com",
    "method": "stripe",
    "intent": "charge",
    "request": "eyJhbW91bnQiOiIxMDAw...",
    "expires": "2025-01-15T12:05:00Z"
  },
  "source": "did:key:z6Mkh...",
  "payload": { "signature": "0x1b2c..." }
}

For an EVM payment, payload carries an EIP-712 signature. For Bitcoin Lightning, it carries a preimage (the secret whose hash matches the invoice's payment hash). This is essentially a plug-and-play model, where different rails and networks can easily be included in MPP.

Security guarantees

MPP's security guarantees are worth walking through. Here are the most common attacks and how the protocol defends against them.

• Replay attacks: Every challenge has a unique id, generated server-side as HMAC-SHA256(server_secret, all_challenge_params). When a client submits a credential, it echoes the id back. The server then

  • recomputes the HMAC to confirm the id is genuine
  • records the id as consumed.

  If the client re-submits the same credential against the same resource or any other, the server sees that id has already been used and rejects the request.

• Wrong resource / wrong amount: Two mechanisms are involved here

  1. request field in the HMAC. When the server responds with 402, the WWW-Authenticate: Payment header carries a request parameter, which is a base64url-encoded JSON blob with the method-specific data:

     {
       "amount": "0.10",
       "currency": "USDC",
       "recipient": "0xabc...",
       "network": "base-mainnet"
     }

     This whole blob is part of the HMAC input that produces id. If anyone (server, network, or agent) changes any of those values, the recomputed HMAC won't match and the request will be rejected.

  2. Body digest binding: For state-mutating HTTP actions (POST, PUT, PATCH), the payment challenge includes digest="sha-256=:<base64-hash-of-body>:". On retry, the server hashes the body the client actually sent and compares it to the digest in the echoed challenge. If there is a mismatch detected, the request is rejected. This is what stops the "pay for request body A, submit request body B" attack.

     Why only state-mutating methods? GET, HEAD, and OPTIONS are "safe" by HTTP semantics: they don't change server state, and the resource is fully identified by the URL (which is already implicit in the exchange). There's no separate body whose contents drive the operation, so there's nothing extra to bind. POST/PUT/PATCH carry bodies that determine what happens, so the body has to be tied to the payment.

• Unauthorised payment (A pays for B): This is relatively straightforward. The payment credential's payload carries a signature against the payer's wallet private key (EIP-712 on EVM chains, Ed25519 on Solana). Anyone can verify the signature against the payer's public key to verify who is making the payment.

• MITM (man-in-the-middle). Both protocols assume TLS underneath, so the underlying channel is already encrypted and tamper-proof. The base64url on the request field is just an encoding, not encryption, but that's fine. Even if a challenge or credential were intercepted, the attacker has neither the server's HMAC secret (so they can't forge or modify challenges) nor the client's private key (so they can't sign new payments).

x402 vs MPP at a glance

pay.sh

x402 and MPP are protocol-level specs that cover what happens on the wire (status codes, headers, challenge formats, etc.), but there isn't much tooling that implements any of it for you. Every team that wants to integrate agentic payments ends up writing the same client-side boilerplate: parse the 402 challenge, figure out which protocol it is, construct the transaction, sign the payload with the right key, etc. That's exactly the friction pay.sh removes.

pay.sh is the Solana Foundation's open-source client implementation of these protocols, launched alongside a hosted Google Cloud gateway. It ships as a Rust binary that supports both MPP and x402, and settles in any stablecoin deployed to the network. It handles the parsing, the signing, the proof-encoding, and the retries. Teams integrate it by building from the crate (cargo install) and running pay setup once. From then on, a developer or an agent can transact on any 402-gated endpoint without writing a line of boilerplate code.

How it works. pay.sh exposes itself in two ways:

1. As a HTTP-client wrapper (pay curl ..., pay wget ...).

   The normal HTTP command is invoked, just prefixed with pay. If the response comes back as a regular 200 response, nothing happens. If it comes back as a 402, pay.sh handles the payment: it detects whether the challenge is MPP or x402, builds the Solana transaction locally, asks the wallet backend to sign it, and re-submits the original request with the payment proof in the right header. Either way, the final response lands on stdout, so the developer or agent keeps using the tools they already know.

2. As an agent launcher (pay claude, pay codex).

   These spin up Claude Code or Codex with pay.sh's MCP server already wired into the session, so the agent can pay through MCP tool calls instead of re-invoking pay curl each time.

The MCP server is also bundled into the same binary and can be added to agentic coding tools like Claude Code and Codex. It exposes payment as a first-class tool the agent calls directly, while signing still happens out-of-process in the wallet backend.

Security & signing. pay.sh delegates signing to an OS-native secure backend:

• macOS: Touch ID via Keychain (Secure Enclave-backed on Apple silicon)
• Linux: GNOME Keyring, brokered through polkit (a one-time policy install grants pay.sh the right to prompt)
• 1Password vault integration, cross-platform
• a file-based fallback for CI and scripting, where biometrics aren't available

When a 402 response arrives, pay.sh builds the transaction and hands it to the backend to sign. The user gets a biometric prompt, and rejecting it blocks the payment. The agent never sees any secrets and can't sign anything the user didn't approve. On top of that, session budgets cap how much a session can spend and when it expires, so an agent can't drain the wallet even inside an approved session.

Solana has been at or near the top of x402 activity by transaction count, running as high as ~88% in early February 2026 before Polygon and Base competition pulled it back toward ~50%, with Base still ahead on cumulative value. That's exactly why supply-side tooling matters. The protocols define the wire format; pay.sh removes the integration tax and makes Solana the easiest rail to actually transact on from any CLI or agent.

Stripe Link CLI

The Link CLI is the consumer-facing plug that enables Stripe to support agentic payments at scale.

Stripe started out as a developer-first API for payments and has since grown into a giant in finance, sitting between millions of merchants and the underlying card, bank, and crypto rails. The Link CLI is how Stripe plugs that whole base into agentic commerce.

For consumers, any Link wallet holder can authorise agents to spend on their behalf. The flexibility on offer is well thought through. Users can:

• pay using fiat, crypto, or stablecoins under the same wallet
• set per-agent budgets and transaction limits
• set explicit user approval scoped to what the agent is actually doing

Stripe's demo shows Claude Code buying coffee, which is cool, but Claude Code is a tool for developers. The real problem is how everyday consumers can tap into this flow. If we look at the underlying mechanics:

1. The agent first inspects the merchant site to decide what credential to request.
   • If it's a normal website with a checkout form, a virtual card will be requested.
   • If a 402 response with method="stripe" in the WWW-Authenticate header is received (MPP), a Shared Payment Token (SPT) will be requested.
     • A Shared Payment Token (SPT) is Stripe's scoped, merchant-bound payment token that allows agents to initiate a purchase on the customer's behalf.
2. The agent then executes link-cli spend-request create, which is a CLI command that asks the Link wallet to provision a credential, passing the merchant, amount, line items, and a ≥100-character context string explaining what's being bought and why.
   • The Link wallet then fires a push notification to the user's phone via the Link app, where they read that context string and either approve or deny the request.
3. Once approved, the agent fetches the credential and uses it in one of two ways:
   • Virtual card → fill the merchant's checkout form with the issued number, CVV, expiry, and billing address — all valid until a timestamp baked into the credential.
   • SPT → call link-cli mpp pay, which runs the full MPP payment flow automatically: parses the WWW-Authenticate header, builds the Authorization: Payment credential with the SPT inside it, and re-submits the original request.

Both the virtual card and the SPT are single-use and time-bound; if a payment fails, the agent has to go back to step 2 and request a new one. The user's real payment method — the card or bank account saved in Link — never leaves the wallet.

Real-world examples are starting to land. @pejmanjohn buying coffee beans through OpenClaw being one.

The powerful part of this is that, for merchants, there is zero work required to support agentic payments. Stripe is essentially using its existing distribution (which is massive) to make itself the broadest agentic-payments network in existence. Those two credential types map to two distribution stories:

• Virtual card is the bridge. The credential the agent submits looks like a real one-time card, so any merchant already accepting Stripe-processed cards instantly accepts agentic purchases too. No new integration, no SDK, no extra checkout surface. This is what makes the "zero merchant changes" claim true, and it covers the long tail of merchants that haven't adopted MPP, which is essentially all of them today.
• SPT is the upgrade. If the merchant has adopted MPP, the SPT slots in as the method="stripe" payload inside MPP's method-agnostic envelope: no form-filling, just a clean HTTP request. Faster, lower-friction, and where the protocol is headed.

That's the play. MPP gives Stripe the protocol on the merchant side; the Link CLI gives them the wallet on the consumer side. Virtual cards light up the existing merchant base overnight; SPTs are the on-ramp for merchants that move to MPP. Same bet from both directions: be the surface that lets any agent transact across any rail.

Forward-looking thoughts

• Method-agnostic wins long-term, opinionated wins short-term. x402 keeps growing because it ships and works today. MPP catches up because it's where the standardisation gravity is. The likely steady state is MPP-the-framework, with x402-style USDC-on-Base as one of the most popular registered methods underneath it.
• Sessions become the unit of agentic payment. One-shot 402 payments are great for "fetch this row of data". But agents do streamed, multi-turn work. The protocol that handles a 30-minute LLM session with token-level billing, without a 402 round-trip per token, is the one that wins the real agent traffic.
• The wallet layer is the unsolved one. Both protocols assume the agent already has a wallet. None of them say where it lives, how keys are stored, or how an agent discovers a wallet created by a different framework. Stripe Link wraps it in a consumer wallet. MoonPay's CLI is trying to standardise the onboarding layer, which has traditionally been one of the toughest blockers in this space. Whoever owns this layer for the agent economy is structurally in the position Stripe was in for cards in 2011.
• Anthropic has been quiet. You can bet they're cooking something. They've been a partner on Visa Intelligent Commerce and the x402 launch, but haven't shipped their own payment surface yet.