u/TooDu0

Every "AI Agent payment rails" startup I see is just wrapping Stripe checkout in a WebView. It’s brain-dead. An autonomous agent is not going to open Chromium, fill a billing address, and solve a Cloudflare turnstile.

If we want real machine-to-machine economy, agents must transact programmatically, in-band, without humans in the loop.

We built MCPay to fix this. It leverages a strict HTTP 402 Challenge-Response flow:

1. The Block: Agent tries to write/call an API. Gateway returns HTTP 402 Payment Required + a signed challenge containing a spend cap, nonce, and payload hash.

2. The Signature: Agent signs the challenge using its scoped sub-key (Ed25519 capability chain).

3. The Execution: Agent retries the request with the cryptographic proof in the headers. Gateway verifies it in <2ms and releases the call.

If the agent mutates a single byte of the payload to bypass limits, the signature breaks and execution drops before any state changes.

No browser hops. No post-factum logging. Pure cryptographic pre-execution policy gating.

It's open-source. What did we miss?

I built MCPay to explore a question around MCP tools:
How should an MCP server authorize paid tool calls when an agent is acting autonomously?Most payment flows are designed for humans: open a checkout page, confirm payment, then continue. That model doesn't map well to MCP tools where agents call resources programmatically.

MCPay experiments with using HTTP 402 as a payment challenge layer between agents and MCP servers.

The flow:

1. Agent calls an MCP tool that requires payment.
2. Server returns HTTP 402 with a signed challenge containing limits, nonce, and request hash.
3. Agent signs the challenge using a scoped Ed25519 capability key.
4. Agent retries the tool call with the cryptographic proof.
5. Server verifies the proof before executing the action.

The authorization is bound to the exact payload, so changing the tool arguments invalidates the signature before execution.
This is still an early prototype, and I'm looking for feedback from people building MCP servers and agent infrastructure.

I'm especially interested in:
\- whether this fits naturally into MCP workflows
\- delegation and authorization patterns
\- security issues I might be missing
\- existing approaches I should study

I'll share the repo and demo in the comments.

I built MCPay to explore a question around MCP tools:
How should an MCP server authorize paid tool calls when an agent is acting autonomously?Most payment flows are designed for humans: open a checkout page, confirm payment, then continue. That model doesn't map well to MCP tools where agents call resources programmatically.

MCPay experiments with using HTTP 402 as a payment challenge layer between agents and MCP servers.

The flow:

1. Agent calls an MCP tool that requires payment.
2. Server returns HTTP 402 with a signed challenge containing limits, nonce, and request hash.
3. Agent signs the challenge using a scoped Ed25519 capability key.
4. Agent retries the tool call with the cryptographic proof.
5. Server verifies the proof before executing the action.

The authorization is bound to the exact payload, so changing the tool arguments invalidates the signature before execution.
This is still an early prototype, and I'm looking for feedback from people building MCP servers and agent infrastructure.

I'm especially interested in:
- whether this fits naturally into MCP workflows
- delegation and authorization patterns
- security issues I might be missing
- existing approaches I should study

I'll share the repo and demo in the comments.

I built MCPay as an experiment around one question:

How should AI agents pay for APIs when there is no human in the loop?

Most payment flows today are designed around humans: open a checkout page, fill information, confirm payment, and continue. That model doesn't translate well to autonomous agents making API calls.

MCPay explores a different approach using HTTP 402 with a challenge-response flow:

1. Agent requests a protected API resource.

2. Gateway responds with HTTP 402 and a signed challenge containing payment limits, nonce, and payload hash.

3. Agent signs the challenge using a scoped Ed25519 capability key.

4. Agent retries the request with the cryptographic proof.

5. Gateway verifies the proof before executing the request.

The authorization is bound to the exact payload, meaning any modification to the request invalidates the signature before execution.

This is still an early prototype, and I'm looking for feedback from people working on MCP servers, agents, and infrastructure.

Some things I'm especially interested in:

- security assumptions I might be missing

- replay protection and delegation boundaries

- existing protocols or prior work I should study

- whether this model makes sense for agent-to-agent payments

I'll put the GitHub repo and demo in the comments

Monetizing MCP tools is a mess right now. Traditional SaaS subscriptions and checkout forms break the moment the user isn't a human, but an autonomous AI agent running inside Cursor, Claude Desktop, or a background workflow. An agent obviously can't stop, open a browser, and type in credit card details just to trigger a tool.

We built MCPay to fix this. It acts as a proxy layer that handles pay-per-call micropayments directly between agents and MCP servers on the fly, without manual forms or subscriptions.

We just launched the beta and are looking for feedback from anyone building custom MCP servers or agent workflows.

Link is in the comments if you want to check out the setup

Monetizing MCP servers is currently broken. Standard subscription models and credit card forms don't work when the user is an AI agent running inside Cursor, Claude, or a custom workflow. Agents can't go through a checkout page just to run a single tool call.

We built MCPay to act as a payment layer for MCP. It handles pay-per-call micropayments directly between agents and tools without manual forms or subscriptions.

You can try it out directly on the site. Dropped the link in the comments.

Testing autonomous agents that call external APIs like Stripe, GitHub, or Twilio is a pain. Running continuous loops against real test environments burns through API limits, creates garbage state data, and makes it hard to simulate 500 errors or rate limiting on demand.

>

Hey,

Every time I test tool-calling agents locally, I always worry about them getting stuck in a retry loop overnight and burning through API credits or hitting live third-party endpoints (Stripe, GitHub, OpenAI, Twilio).

I wanted a way to run agent iterations 100% offline without leaking keys, triggering real webhooks, or wasting money.

So I built GhostAPI — an open-source local API sandbox and MCP control plane. It emulates common APIs right on your machine so your agents can run tools, fail, and retry safely without touching production services or costing a single cent.

Dropping the GitHub link in the comments below.

How are you guys currently isolating your local agent testing, or are there specific endpoints you usually wish were mocked?