DEV Community: LemonCake

How I let AI agents pay for APIs per call (the HTTP 402 path)

LemonCake — Wed, 17 Jun 2026 19:19:09 +0000

If you've built an MCP server or any API that costs you money to run (an LLM call, a paid data source, compute), you've probably hit the same wall I did:

How do you get paid per call — when the caller is an AI agent, not a human with a credit card form?

A human can sign up, enter a card, get an API key. An autonomous agent can't fill out a Stripe checkout form mid-task. And you don't want to hand an agent a raw API key with no spending limit — one runaway loop and your bill explodes.

This post walks through the design I landed on. It's not the only way, but the pieces are reusable even if you build your own.

The core idea: HTTP 402

402 Payment Required has been a reserved HTTP status code since the beginning, basically unused. It turns out to be exactly the primitive we need.

The flow:

An agent calls your endpoint with no payment.
You respond 402 with a small JSON body describing how to pay (price, where to top up, what token format you accept).
The agent (or its owner) tops up once, getting a budget-capped token.
The agent retries with the token in the Authorization header. Now it works — and keeps working until the budget runs out, then it gets 402 again.

HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "accepts": [
    {
      "scheme": "lemoncake-pay-token",
      "price": "0.01",
      "currency": "USD",
      "mintUrl": "https://.../buy/<id>",
      "gatewayUrl": "https://.../g/<id>"
    }
  ]
}

This is the shape the x402 spec standardizes. You don't strictly need the spec to do it — but following it means agent frameworks that already understand 402 can pay you without custom glue.

The budget cap is the important part

The naive version — "give the agent an API key" — is dangerous because there's no ceiling. The whole point of an agent paying autonomously is that you stop watching it. So the token has to carry its own limits:

{
  "budget": 5.00,
  "spent": 0.06,
  "max_calls": 50,
  "calls_used": 6,
  "expires_at": "2026-07-01T00:00:00Z"
}

The gateway checks these on every call before forwarding upstream. Budget exhausted → 402. Rate limit hit → 429. Expired → 402. The agent can never spend more than the token allows, even if it goes haywire.

I encode the token as a signed JWT (HS256) so the gateway can verify it without a DB round-trip on the hot path, then check the live spend counter in Postgres. The JWT carries the token id, endpoint id, and owner id; the mutable budget lives in the DB.

The gateway pattern

The key architectural move: a proxy in front of the real endpoint. The agent never calls your upstream directly. It calls a gateway URL like /g/<endpoint-id>. The gateway:

Verifies the pay token.
Checks budget / rate limit / expiry.
Forwards the request to your real upstream (with your upstream auth attached server-side, so the agent never sees your real keys).
Records the call + cost in a ledger.
Returns the upstream response.

agent ──► /g/<id> (gateway)
            ├─ verify token
            ├─ check budget
            ├─ forward ──► your real API (with your secret key)
            ├─ record usage + cost
            └─ return response

This decouples two things that are usually tangled: who can call (the agent's pay token) and how you authenticate upstream (your secret, never exposed). It also means you can put a per-endpoint price on any existing API without touching its code.

Settling the money

Minting a budget-capped token means someone paid up front. I use Stripe Checkout as a Direct Charge on the provider's connected account (Stripe Connect), so the money lands in the provider's balance and the platform takes a small application fee — once, at payment time, not per call. The per-call cost is just a ledger figure that draws down the prepaid budget.

This matters because charging a fee on every tiny call would get eaten by Stripe's per-transaction minimums. Prepaid bundle + ledger drawdown sidesteps that entirely.

What I'd tell you before you build your own

A few things that bit me:

Don't put the fee on each call. Stripe's minimum charge makes sub-cent per-call billing impossible. Prepay a budget, draw it down in your own ledger.
The token must be re-displayable. Agents lose context. The buyer needs a way to recover the same token (I key the success page off the Stripe session id, which is single-use and unguessable).
Scope the token to one endpoint. A token minted for endpoint A should be rejected at endpoint B. Otherwise a leaked token is a blank check.
Forward upstream auth server-side only. The agent should never be able to read your real upstream key. The gateway attaches it after auth.

The result

I packaged this up as a project called LemonCake — you wrap any API/MCP endpoint, set a price per call, and get a gateway URL an agent can pay through autonomously. There's a live demo (no signup) if you want to see the 402 → top-up → call loop run end to end: https://www.lemoncake.xyz/demo

If you'd rather not leave your terminal, you can watch a budget-capped token get minted and spent in about ten seconds:

# 1) mint a sandbox pay token ($0.20 cap, 20 calls, no signup)
RESP=$(curl -s -X POST https://www.lemoncake.xyz/api/lc/demo/token)
TOKEN=$(echo "$RESP" | jq -r .jwt)
GATEWAY="https://www.lemoncake.xyz$(echo "$RESP" | jq -r .gatewayPath)"

# 2) call the metered gateway with it — note the x-lemoncake-charge header
curl -s -D - -o /dev/null -X POST "$GATEWAY" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d '{"ping":1}' \
  | grep -i x-lemoncake-charge
# -> x-lemoncake-charge: 0.01

Keep calling and the budget drains; when it hits zero the gateway answers 402 again and the agent simply stops.

But honestly, even if you never touch it, the pattern stands on its own:

402 to advertise the price → budget-capped token → gateway that verifies, forwards, and meters.

I'm still genuinely unsure whether autonomous per-call payment is something agent builders need today or whether I'm a year or two early. If you've hit the "how do I charge an agent" problem from the other side, I'd love to hear how you solved it.

How I let AI agents pay for APIs per call (the HTTP 402 path)

LemonCake — Wed, 17 Jun 2026 18:07:56 +0000

If you've built an MCP server or any API that costs you money to run (an LLM call, a paid data source, compute), you've probably hit the same wall I did:

How do you get paid per call — when the caller is an AI agent, not a human with a credit card form?

This post walks through the design I landed on. It's not the only way, but the pieces are reusable even if you build your own.

The core idea: HTTP 402
402 Payment Required has been a reserved HTTP status code since the beginning, basically unused. It turns out to be exactly the primitive we need.

The flow:

An agent calls your endpoint with no payment.
You respond 402 with a small JSON body describing how to pay (price, where to top up, what token format you accept).
The agent (or its owner) tops up once, getting a budget-capped token.
The agent retries with the token in the Authorization header. Now it works — and keeps working until the budget runs out, then it gets 402 again.
HTTP/1.1 402 Payment Required
Content-Type: application/json

{
"accepts": [
{
"scheme": "lemoncake-pay-token",
"price": "0.01",
"currency": "USD",
"mintUrl": "https://.../buy/",
"gatewayUrl": "https://.../g/"
}
]
}
This is the shape the x402 spec standardizes. You don't strictly need the spec to do it — but following it means agent frameworks that already understand 402 can pay you without custom glue.

The budget cap is the important part
The naive version — "give the agent an API key" — is dangerous because there's no ceiling. The whole point of an agent paying autonomously is that you stop watching it. So the token has to carry its own limits:

{
"budget": 5.00,
"spent": 0.06,
"max_calls": 50,
"calls_used": 6,
"expires_at": "2026-07-01T00:00:00Z"
}
The gateway checks these on every call before forwarding upstream. Budget exhausted → 402. Rate limit hit → 429. Expired → 402. The agent can never spend more than the token allows, even if it goes haywire.

The gateway pattern
The key architectural move: a proxy in front of the real endpoint. The agent never calls your upstream directly. It calls a gateway URL like /g/. The gateway:

Verifies the pay token.
Checks budget / rate limit / expiry.
Forwards the request to your real upstream (with your upstream auth attached server-side, so the agent never sees your real keys).
Records the call + cost in a ledger.
Returns the upstream response.
agent ──► /g/ (gateway)
├─ verify token
├─ check budget
├─ forward ──► your real API (with your secret key)
├─ record usage + cost
└─ return response
This decouples two things that are usually tangled: who can call (the agent's pay token) and how you authenticate upstream (your secret, never exposed). It also means you can put a per-endpoint price on any existing API without touching its code.

Settling the money
Minting a budget-capped token means someone paid up front. I use Stripe Checkout as a Direct Charge on the provider's connected account (Stripe Connect), so the money lands in the provider's balance and the platform takes a small application fee — once, at payment time, not per call. The per-call cost is just a ledger figure that draws down the prepaid budget.

This matters because charging a fee on every tiny call would get eaten by Stripe's per-transaction minimums. Prepaid bundle + ledger drawdown sidesteps that entirely.

What I'd tell you before you build your own
A few things that bit me:

Don't put the fee on each call. Stripe's minimum charge makes sub-cent per-call billing impossible. Prepay a budget, draw it down in your own ledger.
The token must be re-displayable. Agents lose context. The buyer needs a way to recover the same token (I key the success page off the Stripe session id, which is single-use and unguessable).
Scope the token to one endpoint. A token minted for endpoint A should be rejected at endpoint B. Otherwise a leaked token is a blank check.
Forward upstream auth server-side only. The agent should never be able to read your real upstream key. The gateway attaches it after auth.
The result
I packaged this up as a project called LemonCake — you wrap any API/MCP endpoint, set a price per call, and get a gateway URL an agent can pay through autonomously. There's a live demo (no signup) if you want to see the 402 → top-up → call loop run end to end: https://www.lemoncake.xyz/demo

But honestly, even if you never touch it, the pattern stands on its own:

402 to advertise the price → budget-capped token → gateway that verifies, forwards, and meters.

I'm still genuinely unsure whether autonomous per-call payment is something agent builders need today or whether I'm a year or two early. If you've hit the "how do I charge an agent" problem from the other side, I'd love to hear how you solved it.

How to Monetize Your MCP Server with Pay-Per-Call USDC Payments

LemonCake — Sun, 17 May 2026 13:58:52 +0000

How to Monetize Your MCP Server with Pay-Per-Call USDC Payments

If you've built an MCP server, you've probably wondered: how do I actually charge for this?

The Monetization Gap in the MCP Ecosystem

The MCP ecosystem is exploding. Thousands of servers listed on registries, npm, Glama, Smithery. But look closely at the pricing model for almost all of them:

Free.

Not "freemium." Just free. With a GitHub Sponsors link buried at the bottom that nobody clicks.

This makes sense for early adoption — you want distribution. But it's not a business. And the obvious alternatives don't fit agentic workflows:

Model	Problem
Monthly subscription	AI agents don't have credit cards. Who signs up?
API key + quota	Rate limits = agent blocking at 3am. Friction.
Per-seat SaaS	Makes sense for humans, not for 100 parallel agents

There's a mismatch. MCP tools are called programmatically, at scale, in automated pipelines. The payment model should match.

That's the gap I wanted to fill.

The Pay Token Pattern

Here's the insight: treat every tool call like an API call with a receipt.

An agent that can call search_markets() or place_order() should be able to pay for those calls — automatically, with no human approval per call, within pre-set limits.

The pattern looks like this:

User (human)                    MCP Client            MCP Server (your tool)
     │                               │                        │
     ├─ Top up $20 USDC once ───────>│                        │
     ├─ Set daily cap $5 ───────────>│                        │
     │                               │                        │
     │ (agent runs autonomously)     │                        │
     │                               ├─ call_tool(args) ─────>│
     │                               │   + LEMONCAKE_PAY_TOKEN │
     │                               │                        ├─ charge $0.01
     │                               │<─ result + receipt ────┤
     │                               │                        │

The key element is the Pay Token — a short-lived, scoped JWT that:

Carries a spend limit the agent cannot exceed
Can be revoked instantly (kill switch)
Doesn't expose your wallet or API key to the MCP server
Produces a machine-readable receipt on every successful charge

The Safety Mechanic: Spend Caps the Agent Can't Override

This is what took the most thought to get right.

The obvious approach is trusting the agent to "spend responsibly." This doesn't work. An injected prompt, a hallucinated loop, or a misconfigured instruction can rack up charges before you notice.

The safer design: the cap is enforced server-side, outside the agent's call graph.

// alpaca-guard-mcp: preflight before every order
async function guarded_place_order(args: PlaceOrderArgs) {
  // 1. Resolve notional cost
  const notional = args.qty * (args.limitPrice ?? await get_latest_quote(args.symbol));

  // 2. Preflight against cap.json — BEFORE any Alpaca call
  const cap = await readCap(); // { dailyLimitUsd: 50, todayUsedUsd: 12.50 }
  const remaining = cap.dailyLimitUsd - cap.todayUsedUsd;

  if (notional > remaining) {
    return {
      allowed: false,
      status: "BUDGET_EXCEEDED",
      hint: `This order would cost ~$${notional} but only $${remaining} remains under today's $${cap.dailyLimitUsd} cap.`
    };
  }

  // 3. Only then: call Alpaca
  const order = await alpaca.placeOrder(args);

  // 4. Record the charge
  await recordCharge(notional);
  return order;
}

The agent sees the BUDGET_EXCEEDED structured response and can explain it to the user. It cannot retry past the cap. There's no agent-side override.

Adding Billing to Your Own MCP Server

If you've built an MCP server and want to add pay-per-call billing, it's three lines:

npm install @lemon-cake/mcp-sdk

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { createLemonCakeSDK } from "@lemon-cake/mcp-sdk";

const server = new McpServer({ name: "my-server", version: "1.0.0" });
const lc = createLemonCakeSDK({ sellerKey: process.env.LEMONCAKE_SELLER_KEY });

server.tool(
  "my_paid_tool",
  { query: z.string() },
  // Wrap your handler with lc.charge()
  lc.charge({ price: 0.05 })(async ({ query }) => {
    const result = await doExpensiveOperation(query);
    return { content: [{ type: "text", text: result }] };
  })
);

Demo Mode: if LEMONCAKE_SELLER_KEY is absent, lc.charge() is a no-op. Your tool runs, charges are logged to stderr, no real billing. Safe for local dev.

Live Mode: set LEMONCAKE_SELLER_KEY in your server env. Every successful tool call deducts from the caller's Pay Token balance and returns a receipt.

The Full Flow for a Paid Tool Call

What actually happens when an agent calls a billed tool:

Agent calls tool → MCP client injects LEMONCAKE_PAY_TOKEN from its env
SDK validates token → checks signature, expiry, remaining balance
Handler executes → your actual logic runs
SDK charges token → atomic debit from Pay Token balance
Receipt returned → x402Receipt appended to tool result
Agent gets result + receipt → can log, display, or ignore

If the token is expired, exhausted, or revoked at step 2, the tool returns a structured error — the agent never calls your downstream API.

Real MCPs Using This Pattern

I've shipped several MCP servers using this model:

agent-payment-mcp — pays for calls to 10+ APIs (Serper, Hunter, Jina, Firecrawl, Slack). Free demo mode, no signup.

alpaca-guard-mcp — wraps Alpaca trading API with a hard daily USD cap. Paper trading default.

polymarket-guard-mcp — Polymarket prediction markets with USDC billing. Read-only free.

xstocks-mcp — tokenized US stocks on Solana via Jupiter DEX. $0.10/trade.

All use the same pattern: free read tools, charged write tools, spend caps enforced before any destructive operation.

The x402 Connection

If you've been following the x402 protocol — HTTP-native machine payments — this is the same idea applied to MCP.

agent-payment-mcp speaks x402: every successful charge returns an x402Receipt, and upstream 402 challenges from APIs are parsed and handled automatically. Agent code written for on-chain x402 works unmodified.

The eventual goal is for the cap ledger to live on a server-side API rather than a local file — same daily cap mechanic, but shared across MCP clients and auditable. That's the Phase B roadmap item.

Getting Started

As a user (call billed tools):

Sign up at lemoncake.xyz
Top up $5+ USDC
Copy your Buyer JWT
Add LEMON_CAKE_BUYER_JWT to any of the MCPs above

As a developer (add billing to your MCP server):

npm install @lemon-cake/mcp-sdk
Wrap handlers with lc.charge({ price: 0.01 })(handler)
Apply to lemoncake.xyz to list in the marketplace

Demo mode works immediately with no signup. You can ship a billed tool today and test the full flow before going live.

Questions? Drop them below or find me at @evidai. The spec for the Pay Token format and x402 compatibility is in the agent-payment-mcp README.

Tags: mcp, ai, agents, payments, usdc, claude, typescript