The Four Agentic Payment Rails: x402, MPP, ACP, and AP2 — What Each Actually Does and When You Need More Than One

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.

Why Agent Payments Are Different From Human Payments

Human payment flows are designed around a checkout page. There’s a human who can read a price, decide whether it’s acceptable, fill in their card details, and click a button. The entire infrastructure of web payments — Stripe’s checkout SDK, PayPal’s redirect flow, Apple Pay’s biometric auth — assumes this human is present and participating.

AI agents don’t have checkout pages. An agent discovering a paid API endpoint, evaluating whether the price is within its budget, paying, and proceeding to use the service needs to do all of that programmatically, without a human in the loop, potentially thousands of times per hour across many different services. The agent might be autonomous — 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.

None of the existing payment infrastructure was designed for this. Credit card APIs require accounts with stored payment methods, session management, and redirect flows. Subscriptions require manual signup. Invoice billing requires a human to approve each bill.

Between September 2025 and March 2026, four protocols shipped to address this. They are almost universally misunderstood as competitors. They are not. They stack — each solving a different layer of the same problem. Understanding what layer each one operates on is the prerequisite for understanding when you need more than one.

Lesson: treat these as layers of one stack, not a bake-off. Picking “the winner” is how you build a service that can’t authorize, can’t check out, or can’t settle.

The Protocol Stack at a Glance

The clearest mental model: four questions that an agentic transaction needs to answer, four protocols that each answer one of them.

A full agentic purchase that involves 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 that the agent uses to do the shopping.

More commonly, you use one or two depending on what your agent is doing. An agent that only calls paid APIs needs x402 or MPP. An agent that only shops for users needs ACP. The authorization layer from AP2 matters when compliance, auditability, or dispute resolution require proof of human consent.

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 Actually Does

x402 revives the HTTP 402 status code — which has been 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 makes sense 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 rather than per-request. This is the pattern AWS Bedrock uses for high-frequency agent tool calls.

When to Use x402

x402 is the right choice when:

• Your service charges per API call, per document processed, or per inference request
• You want zero-friction onboarding for agent clients (no account, no API key, no signup)
• You’re gating MCP tools behind payment requirements
• Settlement in stablecoins is acceptable

x402 is not the right choice when:

• Your buyers need to pay in fiat (cards, bank transfer) — x402 is stablecoin-only
• You’re doing structured merchant checkout with cart management, variants, shipping, and returns
• You need enterprise compliance features like dispute resolution and chargeback handling

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...

# Verify payment proof on incoming requests
# Handled automatically by X402EnforcementService in the McpProxyPipeline

The X402GateService, X402RuntimeService, and X402FacilitatorService in the Effect McpProxyPipeline handle gate registration, runtime enforcement, and verification against the x402.org/CDP facilitator respectively. 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 + Visa/Mastercard, Bitcoin Lightning via Lightspark.

What It Actually 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 is wasteful. 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, not a cent more, against the specific service the session was opened with.

MPP vs x402: The Practical Difference

x402 is best understood as the simple paywall/payment trigger, while MPP is a more comprehensive protocol layer for how services and agents coordinate payment behavior over time.

Concretely:

• 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 is best for individual API calls. MPP is best for inference sessions, compute time, data subscriptions, or any resource priced by ongoing usage.
• MPP uniquely supports fiat cards alongside stablecoins in the same session via Stripe SPT. x402 is stablecoin-only.

The mppx Adapter

For MCP contexts specifically, 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

# Enable MPP session payments
export CLAWQL_MPP_ENABLED=1

# Enable MCP JSON-RPC payment error codes
export CLAWQL_MPP_MCP_JSONRPC=1

# Enable the mppx adapter for MCP tool payment coordination
export CLAWQL_MPPX_ENABLED=1

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, giving the agent client the full set of settlement options.

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 Actually 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, and 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. The honest reason: 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 compelling for:

• B2B procurement where an agent is executing on a pre-approved purchase order
• Subscription and digital goods where there’s no delivery address or variant selection
• Enterprise workflows where the human has already pre-authorized a category of purchases and just wants the agent to execute

The protocol itself is open and continues to be developed. 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:

# Enable ACP checkout
export CLAWQL_ACP_ENABLED=1

# Test without live payments
export CLAWQL_ACP_DRY_RUN=1

Important caveat: 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. This is intentional Tier 1 scope — the gateway-auth and agentic-checkout slices cover the core use case. Also note: the docs-site UCP /.well-known stubs that power scanner discovery are separate from the ACP implementation in clawql-payments — they serve different purposes.

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 Actually Does

AP2 operates at a different layer than the other three. AP2 is an open protocol that 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 — the user signed the intent before stepping away.

Cart Mandate — produced by the merchant, signed by the user when present: the exact items, price, tax, shipping, and total. The user’s signature here 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. The Intent Mandate is the pre-authorization. Verifiable Intent (co-developed with Mastercard) logs all agent actions against it 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. Those mechanisms require human presence. 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 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 they’ll allow agents to spend autonomously.

Lesson: settlement without authorization proof is a receipt. Authorization without settlement is a permission slip. Enterprise buyers need both chained — and dispute-ready.

The AP2 + x402 Bridge

The most important integration for ClawQL’s architecture: 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 giving up the permissionless economics of stablecoin settlement.

In clawql-payments

# Enable AP2 mandate verification
export CLAWQL_AP2_ENABLED=1

# Require AP2 mandate on all tool calls (strict mode)
export CLAWQL_AP2_REQUIRE=1

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.

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

How They Stack: A Complete Example

An enterprise agent tasked with “monitor our cloud spend and automatically purchase additional compute capacity when usage exceeds 80% for 15 minutes” might use 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 is stored and presented with every subsequent transaction as proof of authorization.

ACP — when provisioning from a cloud vendor with a structured merchant checkout (select instance type, region, billing period), the agent uses the ACP checkout flow to navigate cart creation, option selection, and completion 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. This is why all four are complementary, not competing: they answer different questions at different points in the same workflow.

The WORM Audit Trail Across All Four Rails

This is what makes clawql-payments different from implementing each protocol independently. Every payment event across all four rails writes to the same WORM audit trail with the same correlation_id structure:

// WORM events across all four rails
'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 (scope, expiry, or sig failure)
'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, not a join across four separate payment system logs.

# Unified spend report across all rails
clawql payments spend report --group-by provider
clawql payments spend report --group-by rail
clawql payments spend report --group-by team

# Audit a specific transaction chain
clawql payments audit --correlation-id abc-123

# Verify WORM chain integrity
clawql payments audit verify

Choosing the Right Rail

The decision tree for a new service:

Are you charging per API call or per unit of compute? → Start with x402. If you need sessions or fiat cards → add MPP.

Are you building a merchant checkout for physical or digital goods? → Use ACP if you want ChatGPT/agent compatibility with Stripe SPT.

Do your enterprise buyers need cryptographic proof of authorization? → Add AP2 as the authorization layer on top of whatever settlement rail you’re using.

Do you need fiat cards (Visa/Mastercard) in addition to stablecoins? → MPP (Stripe SPT + Tempo) or AP2 (card-network mandate) depending on whether you need settlement or authorization.

Do you need human-initiated fiat billing (subscriptions, invoices)? → Stripe directly, via clawql payments stripe. This is separate from all four agentic rails.

What’s Missing From Every Protocol (Honest Assessment)

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, which means a Stripe account for merchants. 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 — users preferred familiar merchant sites. 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 now FIDO-governed. The card-network settlement paths via Mastercard, Visa, and Amex are still maturing. The “Human Not Present” flow is what most autonomous agent use cases need and it’s production-ready via the x402 bridge. Full card-network mandate flows are coming.

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   # MCP JSON-RPC error codes

# ACP: merchant checkout with Stripe SPT
export CLAWQL_ACP_ENABLED=1
export CLAWQL_ACP_DRY_RUN=1    # test without live payments

# AP2: require mandate verification on tool calls
export CLAWQL_AP2_ENABLED=1
export CLAWQL_AP2_REQUIRE=1    # strict mode: block calls without valid mandate

# 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

Conclusion

The agentic payment stack isn’t four competing protocols. It’s four layers of the same problem: authorization (AP2), commerce checkout (ACP), per-request settlement (x402), and session settlement (MPP). Each layer answers a question the others don’t. The full stack, when you need it, composes naturally — AP2 proves authorization, ACP navigates merchant checkout, x402 or MPP moves money, and the WORM trail records everything with enough correlation_id linking to reconstruct any transaction from intent to settlement.

Most services need one or two of these. Autonomous agents operating across regulated industries at enterprise scale need all four.

The agentic economy is being wired, protocol by protocol, in real time. Whether you’re building a service to be consumed by agents or building agents that consume services, understanding what layer each protocol operates on is the prerequisite for building the right thing.

---

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.