How to Add Payments to Your MCP Server (2026 Update)

· Circuit & Chisel · 11 min read

How to Add Payments to Your MCP Server (2026 Update)

If you want to charge AI agents to call tools on your MCP server, you now have three production-ready options: x402, Stripe MPP, and ATXP. This guide covers how to add payments to your MCP server with working code for each approach, an honest comparison of their tradeoffs, and a decision framework for picking the right one.

The original post on how to monetize your MCP server was written when x402 was the only protocol-native option. Since then, Stripe launched MPP (Machine Payments Protocol) in March 2026, Marqeta launched a dedicated MCP payment server for enterprise card issuance, and Cloudflare added edge-native x402 support via Workers. The options multiplied. The tradeoffs changed. This is the updated guide.

Why Standard API Monetization Doesn’t Work for MCP

Over 10,000 community-built MCP servers are listed in the open registry as of March 2026 (ModelContextProtocol.io, March 2026). Most are free. A growing number charge for tool access — but not with API keys and billing dashboards.

The reason: your users are agents, not humans. They won’t fill out a payment form, manage a subscription, or respond to a payment failure email. The payment has to happen inline, machine-to-machine, without human intervention.

That means you need three things traditional payment infrastructure doesn’t provide:

  1. Per-call billing — each tool invocation has a cost, not a monthly subscription fee
  2. Pre-execution authorization — you need to verify payment before running an expensive operation, not after
  3. No human in the loop — the agent must be able to pay autonomously, within its assigned budget

Three distinct approaches now solve this at the protocol layer.

The Three Options in 2026

x402Stripe MPPATXP
Payment railCrypto (USDC, ETH)Fiat + stablecoin hybridMulti-rail (fiat, crypto, IOU tokens)
Sub-cent micropaymentsYes — native$0.05 practical floorYes
Fiat supportNoYesYes
Agent identityNoNoYes
Per-task budget enforcementNoBuild it yourselfNative
Audit trail per callNoStripe dashboardATXP receipts
Infrastructure reqCloudflare Worker or self-hostedStripe accountATXP account
Best forCrypto-native, sub-cent volumesStripe-first teamsMulti-protocol, identity-sensitive, audit-required

For a broader view of how these protocols compare outside the MCP context, see Every Agent Payment Protocol Compared (2026).

Option 1: How Do You Add x402 to an MCP Server?

x402 is conceptually the simplest. When an agent calls a tool, your server returns an HTTP 402 Payment Required response with a payment address and amount. The agent pays on a crypto rail (typically USDC on Base), includes proof in the retry request, and the server executes.

Coinbase’s x402 Foundation standardized the protocol. Cloudflare added edge-native support in February 2026, which means you can implement x402 as a Cloudflare Worker without running any server infrastructure (Cloudflare Blog, Feb 2026).

// Cloudflare Worker implementation
import { verifyX402Payment } from '@x402/cloudflare'

export default {
  async fetch(request: Request): Promise<Response> {
    const tool = request.headers.get('X-MCP-Tool')

    if (tool === 'deep-search') {
      const payment = await verifyX402Payment(request, {
        amount: '0.001',   // $0.001 USDC
        currency: 'USDC',
        network: 'base'
      })

      if (!payment.valid) {
        return new Response(JSON.stringify({
          error: 'Payment required',
          payment_details: payment.required
        }), {
          status: 402,
          headers: { 'Content-Type': 'application/json' }
        })
      }
    }

    return executeTool(request)
  }
}

What x402 gets you: Sub-cent micropayments with near-zero gas fees on Base L2, no Stripe account, edge-deployable with Cloudflare Workers.

What it doesn’t get you: Fiat support — your agents need crypto wallets. There’s no spending limit primitive at the protocol layer. The server verifies payment occurred but has no visibility into whether the agent’s total task budget is exhausted. For a full breakdown of the protocol mechanics, see Coinbase X402 Explained.

Choose x402 if: your agent infrastructure is already crypto-native and you’re optimizing for sub-cent transaction costs.

Option 2: How Do You Add Stripe MPP to an MCP Server?

Stripe launched MPP (Machine Payments Protocol) on March 18, 2026 — a protocol designed specifically for machine-to-machine payments (Stripe Blog, March 18, 2026). Unlike x402, MPP runs on fiat rails and integrates with Stripe’s existing compliance and reconciliation infrastructure.

MPP uses a pre-authorization model: the server creates a payment intent before tool execution and settles after, which avoids charging for failed or partial operations.

import Stripe from 'stripe'
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!)

async function handleToolCall(req: MCPRequest) {
  const { tool, agentPaymentMethod, taskId, agentId } = req

  // Pre-authorize before execution
  const intent = await stripe.paymentIntents.create({
    amount: toolPricing[tool].cents,  // e.g. 5 = $0.05
    currency: 'usd',
    payment_method: agentPaymentMethod,
    metadata: { mcp_tool: tool, task_id: taskId, agent_id: agentId },
    capture_method: 'manual',  // authorize now, capture after
    confirm: true,
    off_session: true
  })

  if (intent.status !== 'requires_capture') {
    return { error: 'Authorization failed', code: 402 }
  }

  const result = await executeTool(tool, req.params)

  // Capture actual cost after execution
  await stripe.paymentIntents.capture(intent.id, {
    amount_to_capture: result.actualCost ?? toolPricing[tool].cents
  })

  return result
}

What MPP gets you: Fiat payments, Stripe’s compliance and fraud infrastructure, per-call receipts in the Stripe dashboard, and a pre-auth/capture split that lets you charge for actual usage rather than estimated cost.

What it doesn’t get you: MPP doesn’t have a per-task budget primitive. You can check a budget in your own logic before calling Stripe, but the protocol itself doesn’t propagate task-level constraints. Agent identity is tied to a Stripe payment method, not a named agent ID with its own spending history.

Choose MPP if: you’re already running on Stripe infrastructure and need fiat-denominated tool call payments without building a separate payment layer.

For a deeper comparison of MPP’s positioning relative to Stripe’s earlier ACP work, see Stripe MPP Explained: The Fifth Agent Payment Protocol.

Option 3: How Do You Add ATXP to an MCP Server?

ATXP sits above the protocol layer. Instead of wiring your server directly to x402 or MPP, you wire it to ATXP — which handles routing, agent identity, per-task budget enforcement, and receipts across whichever rails your agents use.

The integration uses an authorize-then-settle pattern. Agents pre-load ATXP credits tied to a specific agent ID. Your server authorizes each tool call against that agent’s budget before running anything.

import { ATXPClient } from '@atxp/sdk'

const atxp = new ATXPClient({ apiKey: process.env.ATXP_API_KEY! })

export async function handleMCPToolCall(req: MCPRequest) {
  const { tool, agentId, taskId, taskBudget } = req

  // Check authorization before any execution
  const auth = await atxp.authorize({
    agentId,
    taskId,
    tool,
    amount: toolPricing[tool],       // { value: 0.005, currency: 'USD' }
    remainingBudget: taskBudget      // per-task cap from orchestrator
  })

  if (!auth.approved) {
    return {
      error: auth.reason,
      // 'BUDGET_EXCEEDED' | 'AGENT_NOT_AUTHORIZED' | 'INSUFFICIENT_CREDITS'
      code: 402
    }
  }

  const result = await executeTool(tool, req.params)

  // Settle actual cost after execution
  await atxp.settle({
    authorizationId: auth.id,
    actualCost: result.actualCost ?? toolPricing[tool]
  })

  return result
}

What ATXP gets you: Agent identity (your server knows which agent called your tool, not just that payment cleared), per-task budget enforcement propagated from the orchestrator, multi-rail settlement (agents can pay via fiat, x402, or ATXP credits — same server code regardless), and a receipt for every tool call linked to the agent ID.

What it’s not: ATXP is a layer above x402 and MPP, not a replacement for them. If you want pure protocol-native simplicity with zero external dependencies, ATXP isn’t that.

Choose ATXP if: you need agent identity, spending limit enforcement, or multi-rail support — or if you don’t want to commit to a single protocol rail and have that decision be impossible to reverse later.

Ready to Wire Up Your MCP Server?

If you want spending limits, agent identity, and per-call receipts without building those primitives yourself, atxp.ai is the starting point. SDK integration takes about 15 minutes — the authorize and settle calls above are the full pattern.

Which Option Should You Actually Build On?

Decision tree:

  1. Do your agents use crypto wallets natively?

    • Yes → x402. Sub-cent fees, minimal infrastructure.
    • No → continue.

  2. Are you already on Stripe for other payment infrastructure?

    • Yes → MPP integrates with your existing setup, receipts in the Stripe dashboard.
    • No → continue.

  3. Do you need any of the following?

    • Agent identity (know which agent, not just that payment cleared)
    • Per-task budget enforcement (block when the task budget is exhausted, not just the per-call amount)
    • Multi-rail support (some agents pay in fiat, some in crypto)
    • Audit trail per tool call linked to an agent ID

    If any of these apply → ATXP.

For developers without strong prior infrastructure constraints, ATXP’s multi-rail design means you don’t have to make a protocol bet today. Your server handles payment the same way regardless of whether agents settle via MPP, x402, or ATXP credits. The how-to for wiring up the orchestrator side — including how per-task budgets get assigned before the agent reaches your server — is covered in How to Give an AI Agent a Budget.

Fees and Transaction Economics

Transaction sizex402 (Base L2)Stripe MPPATXP credits
$0.001 micropayment~$0.00005 gasNot cost-effectiveFlat % — viable
$0.05 tool call~$0.0005 gas~$0.002 + 0.05%Flat %
$1.00 tool call~$0.001 gas~$0.03 + 2.9%Flat %
$10.00 tool call~$0.001 gas~$0.29 + 2.9%Flat %
Settlement timeSeconds (Base)Instant (Stripe)Instant

At sub-cent volumes, x402 on Base wins on transaction costs. At dollar-range prices per tool call, the fee gap narrows and the feature set — identity, budget enforcement, audit trail — becomes the deciding factor. Per-task budget enforcement has a real economic value: a runaway agent that can’t exceed its task cap is cheaper than one that can. The spending limit primitives covered in How ATXP’s IOU Model Caps Agent Spending apply directly to MCP server integrations.

A Note on the Marqeta MCP Server

Marqeta launched a dedicated MCP payment server in March 2026. It’s designed for a different use case — issuing virtual cards to agents via tool call, with full BIN support and card network integration. Useful if your agents need a physical-world payment credential that works at any merchant accepting Visa or Mastercard. Not the right tool for per-call micropayments on an MCP tool server.

If your MCP server charges agents for tool execution — search, data enrichment, inference, storage, API access — the three options above are what you want.

FAQ

Can I add payments to an existing MCP server without rewriting it?

Yes. x402 and ATXP both work as interceptors — you add a payment check before your existing tool handler, not instead of it. The tool execution code doesn’t change. Stripe MPP requires slightly more integration since you manage payment intents directly, but it wraps cleanly around existing logic.

What happens if an agent’s payment fails mid-task?

x402 returns a 402 before execution, so there’s no partial state. Stripe MPP and ATXP both support pre-authorization before execution and settlement after — you can check budget before running an expensive operation without blocking on speculative cost. ATXP’s authorize/settle pattern makes this split explicit.

Do MCP servers need to handle refunds for failed tool calls?

For sub-cent micropayments, typically no. For larger tool calls, you’ll want a settlement pattern that only charges for actual usage. ATXP’s authorize-then-settle model handles this natively — you authorize the maximum and settle the actual. With x402, you’d build partial-settlement logic yourself.

How does my MCP server connect to the agent’s overall task budget?

Your server verifies that each tool call is paid, but doesn’t inherently know the agent’s task-level budget. ATXP bridges this: when an orchestrator assigns a $5 task budget, that budget propagates to every tool call the agent makes, including calls to your server. The server sees remainingBudget on each authorization request and can decline if the task is running over.

The original MCP monetization guide covers the business model side — how to price per tool call, usage-based vs. prepaid credit models, and developer onboarding. This guide covers the payment infrastructure layer. Both halves matter: the pricing model is the strategy; the payment integration is how it actually runs.