checkout402_
Reference

MCP tools#

JSON-RPC 2.0 over streamable HTTP at https://api.checkout402.com/mcp.

Authorization: Bearer c402_live_...

tools/list needs no auth — a host can see what's on offer before anyone connects. Everything that touches your account does.

Setup for Claude specifically: Connect Claude.

Seller tools#

create_checkout#

The one that matters. Same object as POST /v1/checkouts.

Argument
title required
price_usd required, decimal string
pay_to required, your payout wallet
description
fulfillment inline | relay | webhook
payload / origin_url the goods, or your endpoint
reusable, test_mode, expires_in_minutes
input_schema, output_schema offer card
example_input, example_output offer card
freshness, coverage, source, constraints offer card

Returns the checkout including its url — the thing to share.

Offer-card fields are commercial claims

An agent should propose freshness, coverage and source for the seller to approve, never infer and publish them. A buyer relies on them.

list_checkouts · get_checkout#

Yours, and one in detail. get_checkout takes checkout_id.

list_receipts · get_receipt#

Payments received. A receipt carries the payer, the split, tx_hash and the delivery outcome.

create_webhook#

{url} → registration plus the signing secret, shown once.

Buyer tools#

quote_checkout#

Read any checkout's price and offer card without paying. Takes a checkout URL or id; returns the total, the fee, and what you'd be buying.

Use it before deciding. It spends nothing.

pay_test_checkout#

Pay a test_mode checkout end to end. Exists so an agent can prove the whole loop — challenge, sign, settle, receipt — before real money is involved.

There is no pay_live_checkout tool

Deliberate. Live spending happens through a client the buyer controls — pay402, with its required max_usd ceiling — not through a tool an agent can call in a loop.

Calling it directly#

curl -X POST https://api.checkout402.com/mcp \
  -H "content-type: application/json" \
  -H "Authorization: Bearer $C402_KEY" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
       "params":{"name":"create_checkout","arguments":{
         "title":"Financials","price_usd":"0.10","pay_to":"0x..."}}}'

The transport is a plain JSON-RPC POST: one request object in, one JSON object back. There is no SSE stream, no GET /mcp and no session header, so the accept header changes nothing and a bare curl is a complete client.

Notifications are the exception — notifications/* messages carry no id and get an empty 202 rather than a result.

OAuth#

For hosts that connect on a user's behalf:

Endpoint
/.well-known/oauth-protected-resource Which server guards /mcp
/.well-known/oauth-authorization-server Registration, authorize, token
POST /oauth/register Dynamic client registration — nothing to pre-arrange
GET /oauth/authorize Consent screen
POST /oauth/token Code → token, PKCE required

Every tool here is a thin wrapper over the REST API in the API reference. Nothing is reachable through MCP that isn't reachable with curl.