Agent payments

prxy.monster exposes a dedicated Machine Payments Protocol surface for agents that can respond to HTTP 402 Payment Required challenges.

Agent payments are in private preview. The gateway can publish merchant discovery and issue payment challenges. Full payment-token redemption is disabled until the charging path is enabled. API-key access through POST /v1/messages remains the production path today.

Discovery

Wallet-aware agents discover paid routes by reading:


GET https://api.prxy.monster/.well-known/mpp

The endpoint returns 404 unless MPP is explicitly enabled for the deployment. When enabled, it advertises the dedicated agent route:


{
  "spec_version": "0.1",
  "realm": "api.prxy.monster",
  "routes": [
    {
      "path": "/v1/agent/messages",
      "method": "POST",
      "price_usd_per_call": 0.05,
      "category": "llm-generation"
    }
  ]
}

Regular API-key endpoints such as /v1/messages and /v1/chat/completions are intentionally not advertised as MPP routes. They require Authorization: Bearer <prxy_key>.

Agent Route


POST https://api.prxy.monster/v1/agent/messages

The request body uses the same Anthropic-compatible Messages shape as POST /v1/messages. The authentication flow is different:

Request	Response
No `Authorization: Payment ...` header	`402 Payment Required` with `WWW-Authenticate: Payment ...`
`Authorization: Payment ...` header present	Private-preview response until payment-token redemption is enabled

Example Challenge

request


curl -i https://api.prxy.monster/v1/agent/messages \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-6",
    "max_tokens": 256,
    "messages": [{ "role": "user", "content": "Say hi" }]
  }'

Why a Separate Route?

MPP wallets and API-key clients have different auth shapes. Keeping /v1/agent/messages separate from /v1/messages prevents a wallet retry from colliding with bearer-token auth, and it lets production API-key traffic stay boring.

Production Checklist

Before this becomes a general-availability payment path, the deployment needs:

Payment-token verification.
Idempotent charge creation.
Receipts tied to the provider call result.
Refund handling when the provider call fails after payment.
Per-agent and per-wallet spend controls.
Public docs that say “agents can pay” only after the above is live.