Payments

SummaryCopy Anchor Link

An agent that buys things needs explicit, verifiable, revocable spending authority, and the merchant on the other side needs to know the agent is authorized to spend on a specific user's behalf. Ad-hoc "card on file with the agent vendor" breaks both halves: the user cannot see or cap what the agent may spend, and the merchant cannot tell an authorized agent from a scripted bot replaying stored credentials. Every serious payment protocol in this space converges on the same fix: a signed, scoped, revocable authorization - a mandate - as a first-class object instead of an implicit trust relationship.

• A mandate is not a payment: it authorizes one, and is a different fact from a completed payment or a delivered order
• AP2 - the general mandate primitive, Google-originated, v0.2.0, no published deployment figures
• x402 and MPP - HTTP-native machine-to-machine payment for a single resource, not a cart
• Card networks (Visa, Mastercard) are shipping their own agent-payment schemes; Stripe is shipping agent-specific payment primitives on top of card and stablecoin rails
• Distinguish human-present (the user is watching and approves in the moment) from human-not-present (delegated, unattended) - protocols increasingly support both, but they need different controls

Mandates: the common primitiveCopy Anchor Link

A mandate is a signed payment authorization that binds an agent, a user, an amount cap, and a scope into a single verifiable credential a merchant or payment network can check. Distinguish that authorization from a payment challenge, settlement proof, or receipt - they answer different questions, and validating one does not validate the others.

Agentic commerce is an agent-authorization problem as much as a payments problem. A mandate is a specialization of the general pattern in Agent Identity: scoped, delegated, auditable authority that a downstream service can verify without trusting the caller's self-description. Design your spending authority as verifiable signed intent, and the specific protocol becomes a serialization detail.

AP2 - Agent Payments ProtocolCopy Anchor Link

Status: open spec, no published deployment figures. AP2 is Google-originated with 60+ collaborators. The spec is at v0.2.0 (2026-04-28) and includes "Human Not Present" flows for delegated purchases the user is not actively watching. The repository ships samples and demos; no source publishes how many merchants run it in production, so ask your payment partner what it supports.

AP2's core object is the mandate described above: Intent, Cart, and Payment mandates, each Open or Closed, proving a human authorized a purchase. UCP is designed to be AP2-compatible, which is why AP2 matters even where it is not yet directly deployed as a standalone integration. Adopt the mandate concept now; pin a hard dependency on AP2 endpoints only once your payment partner ships concrete support.

x402 - HTTP 402 paymentsCopy Anchor Link

Status: open spec with provider integrations. x402 revives the long-dormant HTTP 402 Payment Required status code as an actual payment-negotiation mechanism. It originated at Coinbase and moved under the Linux Foundation as the x402 Foundation in April 2026, with members including AWS, Cloudflare, Anthropic, and Circle. The canonical repository is now github.com/x402-foundation/x402; Coinbase's copy is a development fork.

Cloudflare and AWS have announced x402 integrations at the edge, letting a server answer a request with 402 plus payment terms and accept stablecoin settlement. Treat these as announced integrations or previews (Cloudflare's gateway below is a waitlist) and check each provider's current availability before depending on one.

x402 fits a different shape than the cart-and-checkout protocols: it is for machine-to-machine payment for a resource (paying for an API call, a piece of content, a compute unit) rather than consumer retail checkout. The v2 specification is transport-independent and defines exact, upto, and batch-settlement schemes, so a request does not necessarily settle individually on-chain. If your surface is a metered API or agent-callable resource, x402 is the relevant protocol, not UCP or ACP.

The clearest productization so far is Cloudflare's Monetization Gateway (waitlist opened 2026-07-01): usage-based pricing for any protected resource - pages, datasets, API routes, MCP tools - settled over x402. The flow is the raw protocol: the server answers a gated request with 402 Payment Required carrying price, accepted asset, and payment destination; the client pays and retries with proof; a facilitator verifies; the resource is returned. Settlement is peer-to-peer to the seller's wallet in stablecoins (USDC, Open USD, redeemable for fiat), with sub-second settlement as the design target. Two details matter for agent-surface design: pricing rules can be conditional (per-request, compute-scaled up to a cap, or charged only to unauthenticated callers), and the gateway can require Web Bot Auth before pricing rules apply - identity verification and payment negotiation composing into one edge flow. This generalizes the earlier Pay Per Crawl experiment from "charge crawlers for content" to "charge any caller for any resource," making a priced agent surface a configuration decision rather than a billing-infrastructure project.

MPP - Machine Payments ProtocolCopy Anchor Link

MPP supports the same shape of problem as x402 through a vendor-neutral spec: HTTP payment-gated resources. It is relevant when a client needs to pay for an API request, content, or tool call - not for a free documentation service, and not for retail checkout, which needs product, cart, shipping, and order semantics beyond paying for one HTTP resource. MPP overview.

The server returns an HTTP 402 payment challenge; the client evaluates the terms and, within its spending authority, obtains and returns a payment credential; the server verifies payment before releasing the resource and supplies receipt information. Use the maintained implementation for challenge construction, credential validation, and receipts rather than assembling a plausible-looking header by hand. Server integration.

Set resource, merchant, currency, amount, and aggregate spending limits before allowing an agent to pay, and require user approval for commitments outside that authority. Keep server secrets out of client bundles and logs. Separate payment authorization from access to private data - paying for a resource does not grant another person's permissions. Managing agent spend. Document expired challenges, unsupported payment methods, insufficient funds, duplicate credentials, interrupted delivery, refund policy, and whether retrying a request can charge again; distinguish transport retries from a new purchase.

Choosing between MPP and x402 comes down to the payment methods, clients, and provider integrations you actually need to support - both solve the same HTTP-402 shape with different settlement rails.

Card-network agent schemesCopy Anchor Link

The card networks are publishing their own agent-payment frameworks, layered on top of card rails rather than replacing them.

Visa - Visa Intelligent Commerce is Visa's strategic portfolio for agent-driven transactions, covering agents, issuers, merchants, and developers. Within it, the Trusted Agent Protocol, developed with Cloudflare, lets a merchant distinguish a legitimate commerce agent from a scraper or fraud bot: the agent signs its requests with a merchant- and purpose-specific, time-bound signature, and the merchant verifies it against a published key. Replay and relay protection holds only when the verifier checks the signature, its freshness, and the intended recipient. See Trust and Risk for the verification mechanics, which are the same shape as Web Bot Auth.

Mastercard - Agent Pay is Mastercard's agent-payment framework, including an "Agent Pay for Machines" track for machine-to-machine payments announced June 2026. Its trust layer is Verifiable Intent (Draft v0.1, 2026), an open specification co-developed with Google that creates a tamper-evident delegation chain binding an agent's actions to a human-approved scope: layered SD-JWT credentials bind issuer, user, and agent; eight constraint types express amount bounds, merchant allowlists, budget caps, and recurrence terms; and the mapping is explicitly protocol-agnostic, with bindings to AP2, ACP, and UCP rather than a Mastercard-only format.

Treat both as watchlist-adjacent rather than production-default: real backing (Visa + Cloudflare; Mastercard + Google, with Adyen, Checkout.com, Fiserv, Worldpay, IBM, and Basis Theory expressing support for Verifiable Intent), but single-network origin. Evaluate them when your payment processor or acquirer actually supports them, not ahead of that. Support does exist in places: Stripe documents provisioning Mastercard Agent Pay and Visa Intelligent Commerce network tokens through Shared Payment Tokens (below).

Stripe's agent payment primitivesCopy Anchor Link

Stripe's agentic commerce surface splits by role. For sellers, Stripe supports selling through agents (share your catalog, accept agent-initiated checkout via UCP or ACP) and accepting machine payments (MPP or x402) for API calls and services. For agent builders, Stripe provides Shared Payment Tokens (SPTs), now in Public preview - a scoped grant to use a customer's payment method, with its own usage and expiry limits (amount, currency, expiry), issued from the Onelink Agent Wallet (formerly Link Agent Wallet; the CLI package is still @stripe/link-cli). An SPT is functionally a mandate: the buyer grants it within those limits, the agent presents it to complete a purchase, and it cannot be used outside its scope. Tokens can be one-time or recurring (a recurring token sets usage_limits.recurring_interval, and off-session permission is checked separately), and an SPT can be resolved once to network credentials for a third-party processor. Stripe may also provision Mastercard Agent Pay and Visa Intelligent Commerce network tokens through SPTs. The Delegated Payment Spec, part of ACP (OpenAI's key concepts), is the mechanism OpenAI uses to share payment credentials with merchants in Agentic Checkout flows - Stripe's Shared Payment Token is the first implementation of it.

Human-present vs human-not-presentCopy Anchor Link

Distinguish two authorization shapes before choosing a control:

• Human-present - the user is in the loop at the moment of purchase: reviewing a cart, approving a total, confirming a payment prompt. This is the default shape for ACP checkout sessions and most retail UCP flows today.
• Human-not-present - the user has delegated authority ahead of time (a budget, a recurring purchase, an agent monitoring price and buying when a condition is met) and is not watching the specific transaction. AP2's "Human Not Present" flows and Mastercard's "Agent Pay for Machines" both target this case explicitly.

Human-not-present needs tighter mandate scoping (amount cap, merchant allowlist, expiry, revocation path) precisely because there is no in-the-moment review to catch a mistake. Match your approval thresholds and mandate constraints to which shape a given flow actually is - see Trust and Risk for setting those thresholds.

Related PagesCopy Anchor Link

• Agentic Commerce - the five-layer overview
• Checkout Protocols - UCP and ACP, which these payment mechanisms settle
• Trust and Risk - verifying the agent presenting a mandate is who it claims to be
• Agent Identity - the general scoped-delegation pattern a mandate specializes
• Emerging Standards - protocols still too early-stage for this page