You wrote an MCP server, agents call it, and every call costs you money. The obvious next step is to charge for it, and that is where most people discover the protocol offers no help at all.

Here is the short version, by situation.

• Remote HTTP server, autonomous agent callers, dollar pricing. Use x402. Cloudflare, Coinbase and the x402 Foundation's own @x402/mcp package all ship a working wrapper.
• Human at the keyboard in Claude or ChatGPT. Use OAuth plus your own subscription, with checkout on your own site.
• You already run on Stripe and agents buy one-off items. Stripe's MCP guide now charges agents through MPP.
• Hundreds of small calls in one session. Look at MPP, or sell credits with Nevermined.
• You want distribution more than control. Publish on a marketplace that bills for you, such as Apify.
• You cannot get a merchant account, or you are an agent with no company behind you. Bitcoin routes are the ones that work: L402, MPP's Lightning method or Hypawave. x402 has specified Lightning too, but no SDK implements it yet.
• Your tool call is expensive and one-shot (an inference job, a scrape, a report). Gate the handler on settlement rather than metering usage.

Everything below is sourced to official documentation, and it is a companion to our wider survey of payment platforms for autonomous agents. See methodology and sources for how each claim was checked.

MCP has no payment layer, and that is the whole problem

The 2026-07-28 specification is the largest revision since launch, and it is still the current version. It made the protocol core stateless, dropped the initialize handshake, added multi round-trip requests, cacheable list results, header-based routing, a formal extensions framework, and hardened authorization with RFC 9207 issuer validation and Client ID Metadata Documents. It contains nothing about money.

That is not an oversight anyone is ignoring. Payment support has been proposed three times. On 23 December 2025 a contributor filed SEP-2007, a Standards Track proposal to let servers charge for tool invocations, with a protocol-agnostic framework and x402 v2 as the first supported method. Its design was sensible: servers declare payment capability, clients see prices in tools/list, a paid tool returns error code -32402, the client retries with a signed payment authorization. Two companion issues were filed the same day. All three are closed, and the pull request was closed unmerged on 24 June 2026.

The pressure has not gone away, but neither has the resistance. On 11 August 2026 someone opened RFC #3229, asking for native token metering, session budgets and payment tracking, and framing it as a safety problem rather than a commerce one. It opened with agents running up "massive, unexpected API bills" because nothing in the protocol imposes a spending guardrail. A maintainer closed it on 23 August with a one-line comment: "AI-generated with no disclosure." A September proposal for a standard x402 client flow, #3393, was closed within two days and redirected to the working groups, and since 28 September a spec proposal needs a working-group or interest-group discussion before it can be submitted. The project's August roadmap names five priorities, and payments is not one of them.

So the practical position in October 2026 is simple. Every paid MCP server in production is running a layer that the protocol does not define, and nobody has to be interoperable with anybody.

Your transport decides half of your options

The spec defines exactly two standard transports: stdio, meaning newline-delimited JSON-RPC over the standard streams of a client-launched subprocess, and Streamable HTTP, where each message is an HTTP POST to a single endpoint.

This matters more than it sounds. Every popular payment scheme for MCP is built on the HTTP 402 status code. x402, MPP and L402 all work by answering an unpaid request with 402 plus machine-readable payment requirements, then honoring a retry that carries proof. A stdio server has no HTTP layer and therefore no status codes, so none of those schemes apply to it.

If your server runs locally, payment has to happen inside the tool call. The tool returns an invoice or a payment challenge in its result, the agent pays out of band, and a later call presents proof. That is more work than importing a wrapper, but it has one advantage worth noting: it survives any transport, including stdio, custom sockets and whatever the extensions framework produces next.

Four problems, not one

"Charging for tool calls" bundles four separate jobs, and most tooling only solves some of them.

1. Identify the caller. MCP's authorization spec covers this well with OAuth 2.1, and the July revision tightened it further. This is the one piece the protocol genuinely gives you.
2. Price a unit. A call is rarely the unit anyone values. Tokens consumed, rows returned, a job completed, a seat per month: pick the one your buyer would recognise on an invoice.
3. Collect the money. Rails, custody, refunds, chargebacks, and whether the payer is a person with a card or a process with a wallet.
4. Gate the handler. Verify the payment applies to this call, exactly once, and refuse to run otherwise.

Note that 4 is where correctness bugs live. Retries, at-least-once webhooks and agents that call the same tool twice in a loop will all bill someone twice unless you enforce idempotency yourself.

The options

Your own auth plus your own billing

The conservative choice. Put OAuth in front of your remote server, look up the customer's plan on each call, meter usage, and bill on Stripe like any SaaS product.

This is what the chat clients steer you toward for human buyers. OpenAI's guidance recommends sending users to your own checkout (more on that below). Stripe's own MCP page used to document this path as well, but it now covers charging agents directly through MPP, described in the MPP section.

One point of confusion worth clearing up, because it wastes a lot of people's time: Stripe's MCP server at mcp.stripe.com is a server that lets your agent call the Stripe API. It is not a way to charge for your own MCP server. Those are different products and the docs link across to each other.

Where it falls short. It requires a legal entity, a bank account and KYC, so an autonomous agent cannot use it and neither can a developer in a country Stripe does not serve. It also assumes a human at checkout, which is the wrong assumption for a server whose callers are other machines.

x402, per call

The default for remote servers with agent callers, and the best supported option by a distance.

Cloudflare's Agents SDK documents charging for MCP tools with a paidTool drop-in replacement for tool, so free and paid tools live in the same server. You wrap the server with withX402 and configure a network (base or base-sepolia), a recipient wallet address, and a facilitator such as https://x402.org/facilitator:

const X402_CONFIG: X402Config = {
	network: "base",
	recipient: "0xYourWalletAddress",
	facilitator: { url: "https://x402.org/facilitator" },
};

Prices are given in USD, so 0.01 is one cent. When a client calls a paid tool without payment, the server returns 402 with payment requirements, the client pays and retries with proof, and the result comes back. Cloudflare notes that servers can offload verification and settlement to a facilitator, so your worker never needs blockchain connectivity.

Vercel published x402-mcp in September 2025 covering the same ground for the AI SDK, but that package has not been updated since. The maintained route is now the x402 Foundation's own @x402/mcp, built on x402's MCP transport spec. Coinbase documents the buyer side with a CDP-managed wallet, so no private keys are handled manually. Cloudflare has also announced a Monetization Gateway covering "web pages, datasets, APIs, or MCP tools," though for now it is a waitlist for Cloudflare customers.

Where it falls short. Most implementations settle in USDC on Base, so both sides need an EVM wallet and the buyer needs funds on the right chain before the first call. Onboarding friction on the agent side is the recurring complaint in the ecosystem, including from server operators who otherwise like the protocol. And it prices per call, which is the wrong shape for chatty tools. x402 has also specified a Lightning scheme, but none of these wrappers supports it yet.

MPP, per session

Cloudflare's agentic payments overview also supports the Machine Payments Protocol, which adds WWW-Authenticate: Payment and Authorization: Payment headers to 402 responses and covers one-time, usage-based and recurring payments across cards via Stripe and stablecoins. It is "backwards-compatible with x402: MPP clients can consume existing x402 services without modification."

Stripe now makes it its main answer for MCP builders. Its Monetize your MCP server guide, which it labels experimental, has your tool return a payment link. The link answers agents with HTTP 402, and the agent pays with a Shared Payment Token from Stripe's Link agent wallet, by card or stablecoin, while browsers are sent to your own checkout. It covers one-time purchases such as bookings or digital goods.

MPP also has a Lightning method that works with "any Lightning node or wallet that can create BOLT11 invoices and verify preimages," and where "anyone can participate without accounts, approvals, or special routing."

Use it when an agent makes many calls in one working session and you would rather settle once at the end than mint a payment per call, or when you already run on Stripe and want agents to pay you directly.

Where it falls short. It is young. MPP shipped in March 2026, and Stripe still calls its MCP flow experimental. Its card path inherits Stripe's entity requirements, and Shared Payment Tokens are available in the US, Canada and select European countries.

Nevermined, credits and plans

Nevermined takes a different angle: instead of a payment per call, it puts a paywall in front of your MCP handlers that "acts as a gatekeeper, intercepting every incoming request to a tool, resource, or prompt." You wrap handlers with withPaywall, or call payments.mcp.start() with a planId, and after a successful execution the paywall deducts credits. Credits can be fixed per call, or dynamic based on the arguments or the size of the response. Settlement runs through ERC-4337 account abstraction for crypto plans, or cards through Stripe and Braintree for fiat plans. It now implements x402's MCP transport and lists MPP as rolling out.

Use it when the unit you want to sell is a plan or a balance rather than a transaction, and you want the metering handled for you.

Where it falls short. You add a vendor to the authorization path of every single tool call, and you need a Nevermined account, API key and registered plan before anything works.

A marketplace that bills for you

If distribution matters more than control, let someone else own the payment relationship. Apify hosts MCP servers, publishes them across its ecosystem and partner platforms, and bills on a pay-per-event model where you add Actor.charge('eventName', count=N) to your code and define event prices in the console. Its monetization docs state the developer receives 80% of the revenue charged, with platform usage costs then deducted from that share, plus monthly payouts and no cost to publish or host.

Where it falls short. You take the platform's rate, their payout schedule and their audience, and your server is only paid inside their ecosystem.

L402, Lightning-native

The Lightning HTTP 402 scheme from Lightning Labs, which now has a dedicated home at l402.tech. A server answers with 402 plus a macaroon and a Lightning invoice, the agent pays in sats and retries with the preimage as proof, and the macaroon is reusable afterwards, so an agent pays once per endpoint and caches the credential. The site describes it as "optimized for machine-to-machine interaction. No accounts. No intermediaries."

Where it falls short. The seller needs a Lightning node, the ecosystem is a fraction of x402's, and the credential proves payment rather than delivery. Nothing in L402 binds the payment to what the server actually returns.

Hypawave, settlement-gated execution

Ours, so treat the rest of this section with the appropriate suspicion, and read the limitations at the end.

Hypawave sells actions rather than access. You create an offer with an execution_webhook, the buyer pays your Lightning address directly, and on settlement Hypawave POSTs you {payment_intent_id, offer_id, payment_hash, preimage, locked_amount_sats, payer_pubkey, settled_at}. The preimage is the useful part: the buyer's wallet revealed it to them when the payment settled, and the webhook delivered the same value to you, which makes it a shared secret established by the payment itself. Your tool call then verifies SHA-256(preimage) == payment_hash and runs the job on your own infrastructure.

The seller side needs no account, no API key and no KYC. A seller is a secp256k1 keypair, the identity is created on the first authenticated request, and principal never touches Hypawave. Our own MCP server exposes this as four tool calls, and it runs over stdio, which is the point made earlier about local servers: because payment lives inside the tool call rather than in an HTTP status code, the transport does not constrain it.

Where it falls short, honestly:

• Sats, not dollars. Price a call at 300 sats and its dollar value moves with Bitcoin.
• The buyer needs a preimage-returning wallet. Wallet of Satoshi and Phoenix mobile will pay an invoice and never expose the preimage, so they cannot unlock anything.
• The fee is charged upfront, as unit_price × max_payments × fee% with a minimum fee, when the offer activates, because a platform outside the payment path has no moment at which to deduct a cut. Better than a percentage if you sell steadily, worse if you are testing.
• One implementation, not a standard. x402 sits under the Linux Foundation with independent implementations. We are a single protocol operator.
• A small ecosystem. Far more agents speak x402 than speak this.

Side by side

Approach	Unit billed	Seller needs	Works on stdio	Legal entity or KYC
OAuth plus Stripe	Subscription or metered	Stripe account, entity	Yes	Yes
x402	Per call	EVM wallet address	No	No
MPP	Session, one-time or recurring	Wallet, Lightning node, or Stripe for cards	No	Cards only
Nevermined	Credits against a plan	Account, API key, plan	Yes	Fiat plans only
Apify	Per event	Apify account	Hosted only	Payout details
L402	Per endpoint, cached	Lightning node	No	No
Hypawave	Per settled action	A keypair and a Lightning address	Yes	No

The distribution catch nobody mentions

Where your paid server can live is a separate question from how it collects, and the answer is narrower than most people assume.

Claude's connectors directory listed over 950 MCP servers in July, and the Claude Marketplace, launched in September 2026, lets enterprise customers buy listed products with part of their Anthropic commitment, which is a paid channel for products rather than per-call billing. Charging for a listed connector is fine, and commercial connectors are already there. What is not fine is a connector that moves money for the user. Anthropic's Software Directory Policy, dated 15 April 2026, lists Unsupported Use Cases under the line "Unless otherwise expressly permitted by us in writing, we do not allow Software with certain capabilities into our Directories," and one of those capabilities is "Software that transfers money, cryptocurrency, or other financial assets, or executes financial transactions on behalf of users."

Read that carefully, because the distinction is the one that matters for this article. A server that sells its own output and takes payment for it is a merchant. A server that spends the user's balance on their behalf, which is what a payment-capable MCP server is, falls in the excluded category. That includes ours. A local stdio install via npx is the route for anything in that class, and it is the route we use.

ChatGPT is more permissive but less finished. OpenAI's plugin monetization guidance says "the recommended and generally available approach is to use external checkout," meaning you send the user to your own domain. Checkout with the ChatGPT payment sheet is a private beta "limited to select marketplaces today," approvals are currently limited to physical goods, and a newer option lets users pay with payment methods already saved with the merchant.

The upshot: if your buyers are humans in a chat client, plan on sending them to your own checkout. If your buyers are agents, the client directories are not your distribution channel anyway, and a registry listing or a public offer directory is.

Charging for one tool call, end to end

Concretely, the shape we recommend for an expensive one-shot tool, using our own rails. This is Recipe 6 in the operating manual, and it is the same pattern behind our live compute demo.

Once, at setup. Create an offer with execution_webhook pointed at your HTTPS endpoint. No files needed if you are selling an action. Through the MCP server that is a single call:

create_offer {
  amount: 300, pricing_type: "sats",
  description: "One enrichment job, up to 1000 rows",
  payment_destination: "you@getalby.com",
  max_payments: 100,
  execution_webhook: "https://your-api.example.com/hypawave",
  is_public: true, title: "Company enrichment",
  category: "compute", output_type: "json",
  pay_activation_fee: true
}

Per sale. The buyer pays your Lightning address directly and confirms with the preimage. Hypawave POSTs your webhook. Then:

1. Verify the delivery cryptographically. SHA-256(hex-decoded preimage) == payment_hash, and the payload references an offer you own. Webhook POSTs carry no HMAC and no shared secret, so this check is the authentication, not a formality.
2. Store payment_intent_id → preimage with a unique constraint on payment_intent_id. That constraint is how you enforce one payment, one job.
3. Your paid MCP tool takes {payment_intent_id, preimage} as arguments, does a constant-time compare against the stored value, runs the job, and returns the result.
4. Reconcile missed deliveries. Webhook delivery is fire and forget with a 5-second timeout and no retry, so poll GET /api/offers/list-payments for your settled intents rather than assuming the POST arrived.

Two failure modes to design for. Deliveries can be missed, which is why step 4 exists. And an agent in a retry loop will call your tool repeatedly with the same credential, which is fine and correct here: the preimage buys one job, and every call after the first should return the stored result rather than running again.

How to choose

Work down the list and stop at the first line that matches.

1. Your callers are humans in a chat client. OAuth plus your own subscription, with external checkout.
2. You cannot get a merchant account, either because you are an agent or because card processors do not serve you. L402, MPP's Lightning method, or Hypawave.
3. One tool call does expensive work and delivery is the risk. Gate the handler on settlement, which is the pattern above.
4. Many small calls inside one session. MPP, or Nevermined credits.
5. You already run on Stripe and agents buy one-off items. Stripe's MPP flow.
6. You want distribution and will trade margin for it. Apify or a comparable marketplace.
7. Anything else, meaning a remote server with agent callers and dollar pricing. x402.

If none of them fits cleanly, default to x402 and revisit when the protocol picks a standard. Given that every payment proposal so far has been closed, and new ones must now start in a working group, do not build a roadmap around that happening soon.

Methodology and sources

Research date. Every claim here was verified against primary sources on 13 August 2026 and rechecked on 1 October 2026. The recheck found the metering RFC closed, Stripe's MCP guidance rewritten around MPP, OpenAI's checkout options renamed, MCPay's hosted service gone, and Vercel's package superseded by @x402/mcp, and it added MPP's Lightning method as a route for sellers without a merchant account. Treat anything in this article older than a quarter as needing a recheck.

What counts as a source. Official documentation, specifications, first-party announcements and the MCP repository's own issues and pull requests, linked inline at the point of use. We read the GitHub API directly for the status of every proposal cited rather than trusting summaries of it, which is how we caught that SEP-2007 is closed rather than pending, a detail several secondary write-ups get wrong. Competitor marketing pages and news aggregators were excluded when making factual claims about competitors.

Known uncertainties. We could not verify from official documentation whether the major MCP registries other than Apify offer billing to server authors, so we make no claim either way about them. Stripe labels its MPP flow for MCP experimental, so expect it to change. Cloudflare documents both x402 and a Stripe-based path for paid tools; we describe the x402 one because that is what its current documentation specifies, and we make no claim about the exact API of the Stripe integration. Revenue-share figures are quoted from the platform's own docs and platforms change them.

Disclosure. We build Hypawave and we ship an MCP server, so we are a competitor to several products described above. We have tried to be harder on ourselves than on anyone else, which is why our own directory exclusion is spelled out rather than left implied. If you find an error, tell us and we will correct it and note the change.

Further reading

• Best payment platforms for autonomous AI agents, the wider comparison this post sits inside
• How Hypawave works, settlement-triggered execution in detail
• Documentation, the accountless seller flow end to end
• Live offers, things agents are buying right now