CreateOS MPP (Machine Payments): An HTTP 402 payment gateway for AI agents

We built a payment gateway that lets AI agents pay for cloud deployment using stablecoins (USDC/USDT), with no account registration, no API key, and no human in the loop at the point of transaction. The on-chain payment is the access control.

The gateway is built on MPP (Machine Payment Protocol) and uses HTTP 402, the "Payment Required" status code that has been in the HTTP spec since 1997 but almost never implemented in practice.

Full documentation: https://nodeops.network/createos/docs/MPP

The problem

When an AI agent needs to use a paid service, the payment step almost always requires a human. Someone has to create an account, agree to terms, enter a credit card or set up billing, and hand the agent an API key. The agent can call the service autonomously, but the commercial relationship is still bootstrapped by a person.

This works, but it means every new service an agent wants to use requires a human to set up billing first. As agents start composing multiple services together, that becomes a bottleneck.

How it works

The gateway implements a payment negotiation pattern using HTTP status codes. Here is the full sequence:

Step by step:

1. The agent sends a deploy request to POST /agent/deploy

2. If the agent has credits, the deployment proceeds normally (200)

3. If not, the server returns HTTP 402 with a JSON body containing: the price, the token address (USDC or USDT), the recipient wallet, and the chain

4. The agent sends the ERC20 transfer on-chain to the specified address

5. The agent retries the original request, adding the transaction hash as a header (X-Payment-Tx)

6. The gateway verifies the payment on-chain and proceeds with deployment

The wallet address is the only identity. No registration, no email, no OAuth flow. The agent authenticates by signing a message with its private key. The payment itself is the authorization.

Credit system

Agents do not need to make an on-chain transaction for every deployment. Payments are converted to CreateOS credits at a rate of $1 = 100 credits. Credits are consumed hourly by active projects based on resource usage.

If an agent already has credits from a previous payment, the gateway skips the 402 step entirely and deploys immediately. Credits are pooled across all active projects for a wallet, so a single payment can fund multiple deployments.

There is one edge case worth mentioning: if an agent deploys a new project while other projects are already running on the same wallet, the new deployment draws from the same credit pool. The gateway warns about this and requires an explicit opt-in header (X-Use-Existing-Credits: true) to prevent agents from accidentally reducing the runway of their other projects.

Supported chains and tokens

Both are Ethereum L2s where transaction fees are typically under $0.01, making micropayments for individual deployments practical.

What this is (and what it is not)

• This is a permissionless payment layer. Any agent with a funded wallet can show up and use the service without anyone approving them first. There is no vendor relationship to establish.

• This is not the first way an agent can pay for things. An agent with a Stripe API key can already make programmatic payments. Cloud providers like AWS and Vercel already have deploy APIs with billing attached. We are not claiming agents could not pay for deployment before this.

• The actual difference is in the access model. Stripe requires KYC, account approval, and a billing relationship with each vendor. Traditional cloud APIs require registration and API key provisioning. MPP requires none of that. The tradeoff is that you need a crypto wallet funded with stablecoins, which is its own setup step, just a different one.

• This is an open protocol, not a proprietary API. HTTP 402 + a standardised payment negotiation schema means any service provider could implement the same pattern. We would like this to become infrastructure that other services adopt, not a single integration.

Architecture decisions

We chose stablecoins (USDC/USDT) over ETH or other volatile tokens because agents should not need to reason about price fluctuations when deciding whether a deployment is worth the cost. A deployment that costs $0.50 today should cost $0.50 tomorrow.

We chose Arbitrum and Base because L2 transaction fees are low enough that the payment overhead for a single deployment is negligible. On mainnet Ethereum, gas fees alone could exceed the cost of the deployment itself.

The only dependency for the client side is viem for wallet signatures and ERC20 transfers. No SDK, no special libraries.

Try it

The gateway is live at: https://mpp-createos.nodeops.network

If you are using an AI coding tool (Claude Code, Copilot, Gemini CLI, etc.), you can install the skill directly:

npx skills add NodeOps-app/skills --skill createos-deploy

This gives your agent the full deploy flow out of the box: wallet auth, payment negotiation, and deployment, handled automatically.

If you want to integrate manually:

• Discovery endpoint: GET /openapi.json

• Health check: GET /health

• Full working example (TypeScript, ~100 lines): https://nodeops.network/createos/docs/MPP/Example

• Full docs: https://nodeops.network/createos/docs/MPP/Overview

Testnet support (Arbitrum Sepolia) is available for trying it without real funds.

What we are looking for

Feedback on the protocol design. We think HTTP 402 is underused and that a standardised machine payment negotiation pattern could be useful beyond our specific use case. If you are building agent tooling or infrastructure that charges for usage, we would be interested in whether this pattern makes sense for your service.

The interesting question for us is whether the 402-based negotiation pattern generalises. Any API that charges per-request could return a 402 with a payment quote instead of requiring pre-provisioned API keys. We built this for deployment, but the same flow could work for compute, storage, inference, or any metered service.