The Four Agentic Payment Rails: x402, MPP, ACP, and AP2

A practitioner’s guide to the protocol stack that lets AI agents discover, authorize, and pay for services autonomously — with concrete implementation details from building all four into clawql-payments.

This pairs with clawql-inference payment rails in the LiteLLM comparison and the cost stack’s entitlement layer in twelve layers of LLM cost. Product reference: docs.clawql.com/payments/clawql-payments.

---

The Problem With Agent Payments

Human payment flows are built around the checkout page. A human reads a price, decides it’s acceptable, fills in card details, clicks a button. The entire infrastructure of web payments — Stripe’s checkout SDK, PayPal’s redirect flow, Apple Pay’s biometric auth — assumes that human is present and participating.

AI agents don’t have checkout pages. An agent discovering a paid API endpoint needs to evaluate the price against its budget, pay, and proceed — programmatically, without a human in the loop, potentially thousands of times per hour across many different services. The agent might be running on a schedule with no human supervising individual actions, or it might be delegated by a human who authorized a spending budget upfront and stepped away.

Between September 2025 and March 2026, four protocols shipped to address this. They are widely misunderstood as competitors. They stack — each solving a different layer of the same problem.

A full agentic purchase involving a human user, a merchant with a cart, and an API that charges per-request might use all four: AP2 to prove the human authorized the purchase, ACP to navigate the merchant’s checkout, and x402 or MPP to pay for the underlying compute. More commonly, you use one or two depending on what your agent is actually doing.

---

x402: HTTP-Native Per-Request Stablecoin Settlement

Announced: May 2025 (Coinbase). V2: December 2025. x402 Foundation (Linux Foundation): April 2026. Production traction: 100M+ transactions in first six months. Stripe integrated x402 on Base in February 2026. AWS Bedrock AgentCore adopted x402 in May 2026. Cloudflare supports x402 natively. Settlement: USDC on Base L2 (primary), multi-chain in V2.

What It Does

x402 revives the HTTP 402 status code — reserved but unused since HTTP/1.1 was defined in 1996 — to make payment a native part of HTTP.

The flow:

1. Agent requests a paid resource
2. Server returns HTTP 402 with machine-readable payment instructions: price, currency, destination wallet, supported chains
3. Agent signs a USDC payment (EIP-712 TransferWithAuthorization)
4. Agent retries the request with the payment signature in a header
5. Server verifies settlement, returns the resource

No accounts. No API keys. No sessions. No signup. The payment receipt is the credential. An agent discovering a new x402-protected endpoint for the first time can pay for it immediately without any prior relationship with the operator.

The Economics

At $0.001 per on-chain transaction on Base L2, x402 works for service calls priced at $0.01 and above. For sub-cent micropayments, per-request on-chain settlement adds overhead that exceeds the service cost. The fix is deposit-based metering: agents deposit USDC upfront, the service meters usage off-chain, and settles periodically. This is the pattern AWS Bedrock uses for high-frequency agent tool calls.

When to Use x402

x402 suits services charging per API call, per document processed, or per inference request. It works well for gating MCP tools behind payment requirements and for operators who want zero-friction agent onboarding without accounts or API keys. Settlement in stablecoins needs to be acceptable to your buyers — x402 is stablecoin-only, so fiat-only buyers need a different rail.

In clawql-payments

# Enable x402 gating on the inference endpoint
export CLAWQL_X402_ENFORCE=1

# Gate a specific MCP tool
clawql payments x402 gate \
  --tool knowledge_search \
  --price 0.001 \
  --asset USDC

# Set up receiving wallet
clawql payments x402 wallet setup --address 0x...

The X402GateService, X402RuntimeService, and X402FacilitatorService in the Effect McpProxyPipeline handle gate registration, runtime enforcement, and verification against the x402.org/CDP facilitator. Every payment verification writes a WORM event (X402_PAYMENT_RECEIVED or X402_PAYMENT_FAILED) with the correlation_id linking to the specific tool call that triggered it.

---

MPP: Session-Based Streaming Machine Payments

Announced: March 18, 2026 (Stripe + Tempo mainnet launch). Design partners: Anthropic, OpenAI, Shopify, Mastercard, Visa, Lightspark. Production integrations: Browserbase, DoorDash, Ramp, Revolut, 100+ at launch. Settlement: Stablecoins via Tempo chain, fiat cards via Stripe SPT and Visa/Mastercard, Bitcoin Lightning via Lightspark.

What It Does

MPP addresses the failure mode of per-request settlement: if your agent queries a data feed thousands of times per hour, signing and broadcasting a blockchain transaction for each call wastes both time and fees. MPP introduces sessions.

The flow:

1. Agent opens an MPP session, pre-authorizing a spending limit
2. Agent makes requests against the session, metered by the service
3. Service records usage off-chain against the session
4. Session batch-settles on Tempo chain at configured intervals

One authorization, many requests, periodic settlement. The session credentials are scoped: the agent can spend up to the authorized limit against the specific service the session was opened with.

x402 vs MPP in Practice

x402 settles USDC on-chain per request. MPP settles via Tempo or fiat card via Stripe SPT in bulk after metered usage accumulates. x402 is fully permissionless — any wallet, no setup. MPP requires a Stripe account for fiat settlement. x402 works well for individual API calls; MPP works better for inference sessions, compute time, or data subscriptions priced by ongoing usage. MPP is also the only rail here that natively supports fiat cards alongside stablecoins in the same session via Stripe SPT.

The mppx Adapter

For MCP contexts, the mppx optional adapter in clawql-payments handles MCP JSON-RPC payment error codes (-32042 for payment required, -32043 for payment failed) — the machine-readable signal that an MCP tool call was blocked due to payment requirements.

In clawql-payments

export CLAWQL_MPP_ENABLED=1
export CLAWQL_MPP_MCP_JSONRPC=1
export CLAWQL_MPPX_ENABLED=1   # MCP JSON-RPC error codes

The MppOpenApiService and MppVerificationService handle credential verification and challenge registry. The offers[] array in the payment response includes PayPal, Adyen, and Square alongside the primary rail.

---

ACP: Agentic Commerce Protocol for Merchant Checkout

Announced: September 29, 2025 (OpenAI + Stripe, same day as ChatGPT Instant Checkout). Status: Instant Checkout shut down March 2026 after conversion rate shortfalls. ACP protocol continues as open standard. Shopify, Salesforce, PayPal still building on it. Settlement: Fiat only, via Stripe Shared Payment Token (SPT).

What It Does

ACP answers a different question than x402 or MPP. Those handle machine-to-machine payments for APIs and compute. ACP handles agents completing purchases from merchants — navigating a cart, selecting variants, handling shipping, checking out on a user’s behalf.

Four RESTful endpoints define the full lifecycle:

POST /checkout               → Create: agent sends SKU, merchant creates cart
PUT  /checkout/{id}          → Update: modify quantities, shipping, customer details
POST /checkout/{id}/complete → Complete: execute payment via SharedPaymentToken
POST /checkout/{id}/cancel   → Cancel: abort the checkout

The Shared Payment Token (SPT) is the core mechanism. A user pre-authorizes a Stripe SPT scoped to specific constraints — maximum amount, expiry time, allowed merchant categories. The agent presents this token at checkout. The merchant charges against it. The agent never sees raw card credentials. If the agent is compromised, the stolen token is time-bound, amount-limited, and merchant-scoped.

The Instant Checkout Postmortem

ACP’s flagship deployment shut down six months after launch. Users preferred completing purchases on merchant sites where they had saved accounts, saved addresses, and loyalty programs. The agent-mediated checkout added friction rather than removing it for most retail purchases.

This doesn’t invalidate ACP. It invalidates one specific use case — replacing the consumer checkout page for retail impulse purchases. ACP remains useful for B2B procurement where an agent executes on a pre-approved purchase order, subscription and digital goods where there’s no delivery address or variant selection, and enterprise workflows where a human has already pre-authorized a category of purchases.

Shopify made UCP self-serve in Spring ‘26 Edition. From June 17, 2026, any developer can register an agent profile in Shopify’s Developer Dashboard. ACP is included in that surface.

In clawql-payments

The AcpCheckoutService implements the gateway-auth and agentic-checkout slices of the full protocol — create/get/complete checkout sessions with Stripe SPT completion and a dry-run path for testing:

export CLAWQL_ACP_ENABLED=1
export CLAWQL_ACP_DRY_RUN=1    # test without live payments

ClawQL’s ACP implementation is a soft subset of the full spec. ACP complete currently supports Stripe SPT — other provider types in the spec’s type union don’t have live complete paths yet. The docs-site UCP /.well-known stubs that power scanner discovery are separate from the ACP implementation in clawql-payments.

---

AP2: Cryptographic Authorization for Agent-Initiated Payments

Announced: September 16, 2025 (Google, 60+ launch partners). Donated to: FIDO Alliance, April 28, 2026 (v0.2 release). Partners: Mastercard, PayPal, American Express, Adyen, Coinbase, Salesforce, ServiceNow, Worldpay, UnionPay, JCB, Etsy. Settlement: Payment-method agnostic — cards, stablecoins, bank transfers, crypto.

What It Does

AP2 operates at a different layer than the other three. It gives an AI agent a verifiable, cryptographically signed permission slip from a human before it can spend money on that human’s behalf.

The protocol doesn’t move money. It proves authorization. Three signed mandates, each a W3C Verifiable Credential:

Intent Mandate — signed by the user, captures scope and constraints: “buy white running shoes, size 10, under $150, deliver to my saved address.” The agent cannot exceed this scope without re-prompting. This is what makes autonomous “Human Not Present” purchases auditable.

Cart Mandate — produced by the merchant, signed by the user when present: the exact items, price, tax, shipping, and total. The user’s signature is cryptographic proof of “I saw this exact cart and approved it.” The agent presents this to the payment processor.

Payment Mandate — authorizes the final charge against a specific funding source. Binds the payment to the Intent and Cart, creating a complete chain of proof from user intent to merchant charge.

The v0.2 “Human Not Present” flow is the operationally important one: a user pre-signs an Intent Mandate with budget limits and authorized categories. The agent executes purchases within those limits without needing the user to sign each Cart Mandate. Verifiable Intent (co-developed with Mastercard) logs all agent actions against the Intent Mandate as a tamper-proof audit trail.

Why AP2 Matters for Enterprise

The problem AP2 solves is one that enterprise and regulated-industry buyers care about deeply: when an AI agent makes a purchase, who is legally liable? Was the purchase authorized? Can you prove it?

Traditional payment systems answer this with signatures, PINs, and biometrics at the point of sale. AP2 answers it cryptographically without requiring the human to be present at each transaction. The mandate chain is W3C Verifiable Credentials with asymmetric cryptography. It is structurally impossible for an agent to alter a price or item payload after the human has signed off on the intent.

The dispute resolution path becomes clear: if a merchant disputes whether a charge was authorized, the Verifiable Intent log shows every action the agent took under the pre-authorized mandate. If a chargeback is filed, the mandate chain provides cryptographic evidence of the user’s authorization scope. This is the compliance story that enterprise procurement, financial services, and regulated industries need before allowing agents to spend autonomously.

The AP2 + x402 Bridge

AP2’s A2A x402 extension lets an AP2 Payment Mandate authorize an x402 stablecoin settlement. The mandate provides the authorization proof; x402 provides the settlement rail. Enterprise agents using USDC micropayments get the full audit trail — user authorization, cart contents, payment execution — without losing the permissionless economics of stablecoin settlement.

In clawql-payments

export CLAWQL_AP2_ENABLED=1
export CLAWQL_AP2_REQUIRE=1    # strict mode: block calls without valid mandate

The Ap2MandateService handles parse/verify of Payment Mandates (with optional HS256 HMAC verification), writes WORM events on every mandate verification, and bridges into x402 gates — an AP2 mandate can authorize an x402 payment without the agent needing separate x402 credentials.

The current implementation is a soft subset of the full spec: the gateway-auth slice covering mandate parsing, verification, and WORM logging. Full card-network settlement paths via Mastercard, Visa, and American Express are still maturing in the broader ecosystem.

---

A Complete Example: All Four Rails

An enterprise agent tasked with “monitor cloud spend and automatically purchase additional compute capacity when usage exceeds 80% for 15 minutes” uses all four:

AP2 — the administrator pre-signs an Intent Mandate: “purchase compute resources from approved vendors, up to $500/month, auto-execute without confirmation for purchases under $50.” This travels with every subsequent transaction as proof of authorization.

ACP — when provisioning from a cloud vendor with structured merchant checkout (select instance type, region, billing period), the agent uses the ACP checkout flow to navigate cart creation and complete via Stripe SPT.

x402 — for per-request API calls to monitoring tools, data feeds, or model inference endpoints priced by the call, the agent pays directly via x402 USDC without opening a merchant checkout.

MPP — for the compute capacity itself, if the provider uses session-based billing (metered by minute, by token, or by resource-hour), the agent opens an MPP session with a spending limit and streams payments against it.

The AP2 mandate travels with every transaction as proof of authorization. The settlement rail — x402, MPP, or ACP — depends on what the vendor supports.

---

The WORM Audit Trail Across All Four Rails

Every payment event across all four rails writes to the same WORM audit trail with the same correlation_id structure:

'X402_PAYMENT_RECEIVED'; // x402 settlement success
'X402_PAYMENT_FAILED'; // x402 verification failure
'MPP_SESSION_OPENED'; // MPP session initialized
'MPP_PAYMENT_STREAMED'; // MPP session payment recorded
'MPP_SESSION_SETTLED'; // MPP batch settlement
'ACP_CHECKOUT_CREATED'; // ACP checkout session started
'ACP_CHECKOUT_COMPLETED'; // ACP purchase executed
'AP2_MANDATE_VERIFIED'; // AP2 mandate accepted
'AP2_MANDATE_REJECTED'; // AP2 mandate rejected
'STRIPE_INVOICE_PAID'; // Stripe subscription/invoice
'STRIPE_PAYMENT_FAILED'; // Stripe payment failure
'ENTITLEMENT_LIMIT_REACHED'; // Plan cap hit

Every event carries correlation_id linking it to the specific tool call, inference request, or document processing job that triggered the payment. A compliance query — “show me every payment made by agent session abc-123 last Tuesday, linked to the specific tool calls that caused them” — is a single WORM index lookup.

clawql payments spend report --group-by provider
clawql payments spend report --group-by rail
clawql payments spend report --group-by team
clawql payments audit --correlation-id abc-123
clawql payments audit verify

---

Choosing the Right Rail

Services charging per API call or per unit of compute: start with x402. If you need sessions or fiat cards, add MPP.

Building a merchant checkout for physical or digital goods: use ACP if you want ChatGPT/agent compatibility with Stripe SPT.

Enterprise buyers who need cryptographic proof of authorization: add AP2 as the authorization layer on top of whatever settlement rail you’re using.

Fiat cards (Visa/Mastercard) in addition to stablecoins: MPP via Stripe SPT or AP2 via card-network mandate, depending on whether you need settlement or authorization.

Human-initiated fiat billing — subscriptions, invoices: Stripe directly, via clawql payments stripe. This is separate from all four agentic rails.

---

Honest Gaps

x402: Stablecoin-only today. Per-request on-chain settlement has fee overhead that breaks the economics for sub-cent calls. Deposit-based metering fixes this but adds implementation complexity.

MPP: Requires Stripe integration for fiat settlement, so less permissionless than x402 for operators who want zero-friction setup. Production track record is months old, not years.

ACP: Instant Checkout shut down six months after launch. The consumer checkout use case failed to find traction. The protocol continues for B2B and enterprise use cases. Fiat-only, so stablecoin buyers need x402 or MPP separately.

AP2: The authorization framework is well-specified and FIDO-governed. Full card-network mandate flows via Mastercard, Visa, and Amex are still maturing. The “Human Not Present” flow via the x402 bridge is production-ready for autonomous agent use cases.

All four: The ecosystem is six to twelve months old. APIs will change, implementations will mature, some protocols may consolidate. Building on clawql-payments’ multi-rail architecture rather than hard-coding any single protocol is the practical hedge against protocol evolution.

---

Quick Reference

# x402: gate an MCP tool behind USDC micropayment
clawql payments x402 gate --tool knowledge_search --price 0.001 --asset USDC
export CLAWQL_X402_ENFORCE=1

# MPP: enable session-based streaming payments
export CLAWQL_MPP_ENABLED=1
export CLAWQL_MPPX_ENABLED=1

# ACP: merchant checkout with Stripe SPT
export CLAWQL_ACP_ENABLED=1
export CLAWQL_ACP_DRY_RUN=1

# AP2: require mandate verification on tool calls
export CLAWQL_AP2_ENABLED=1
export CLAWQL_AP2_REQUIRE=1

# Stripe: human-facing subscriptions and invoices
clawql payments stripe setup
clawql payments plan show

# Unified audit
clawql payments audit --correlation-id <id>
clawql payments spend report --group-by rail

Full documentation: docs.clawql.com/payments/clawql-payments

---

All four payment rails — x402, MPP, ACP, and AP2 — are implemented in clawql-payments, available as part of the ClawQL platform. Docs: docs.clawql.com.