What can I sell?#

Anything you can hand over when someone pays for it.

Your existing subscriptions, API keys and enterprise contracts stay exactly as they are. This adds a new purchasing surface for ad-hoc agent demand — buyers who will never sign up, but will pay $0.10 right now.

Start here: three questions#

Every checkout is the same three answers. Nothing else is required.

The first answer picks your checkout type. The other two are settings on it.

Pick your type#

Sell an API — relay#

You have an endpoint. We put a paywall in front of it, call it after payment, and hand back what it returned. Your URL and your upstream key never reach the buyer. The most common type, and it can be sold in bulk.

Sell MCP tools — mcp#

You run an MCP server. Price one named tool, or the whole server. We speak the protocol properly, so a tool that fails inside an HTTP 200 is not billed as a success. Two genuinely different products; can be sold in bulk.

Sell stored data — inline#

A key, a licence, a fixed answer. You give us the bytes and we hand them over when someone pays. Nothing to host, nothing to keep running, and the schema buyers inspect is derived from your payload automatically.

Sell anything else — webhook#

Physical goods, human work, your own flow. We take the payment and tell you; you deliver and close it out. The escape hatch, and the most flexible.

Sell a file — also a face#

A PDF, a dataset, a clip. relay pointed at the file, plus a content declaration that says it is one — so it gets a pay page, a download disposition and a working Range, and the bytes stay on your server. Under 5 MB; above that, relay to your own signing endpoint instead.

Sell an article — a face, not a fifth mode#

An essay, a report, a page. The opening stays on your site; the rest is served from checkout402 only to someone who paid. Readers pay in the page they are reading and crawlers get a 402 with a price on it instead of your text.

Not a fifth mode: it is inline or relay plus a content declaration, answering at /x/{id} instead of /c/{id}. If your CMS is WordPress there is a plugin and you never touch any of this.

The four modes, side by side#

Every checkout ends in one of four fulfilment modes. The mode is the only thing that differs between selling an API call, stored data and a physical object — price, payout, receipts and the 402 are identical in all four.

Pick by where the thing lives:

You rarely name a mode. It is inferred from what you send:

fulfillment is still accepted and still wins if you send it. But it is an implementation word, and you should not have to learn one to sell something.

Two shapes cannot be inferred, and both must say fulfillment out loud: webhook, because there is nothing else to go on, and a whole MCP server — an origin_url with no tool name is indistinguishable from a relay.

One of each:

c402 checkouts create --title "…" --price 0.10 --payload '{"key":"…"}'
c402 checkouts create --title "…" --price 0.10 --origin-url https://api.yourco.com/v1/x
c402 checkouts create --title "…" --price 0.10 --origin-url https://mcp.yourco.com/mcp \
  --mcp-tool search_companies
c402 checkouts create --title "…" --price 25.00 --fulfillment webhook

{"title": "…", "price_usd": "0.10", "payload": {"key": "…"}}
{"title": "…", "price_usd": "0.10", "origin_url": "https://api.yourco.com/v1/x"}
{"title": "…", "price_usd": "0.10", "origin_url": "https://mcp.yourco.com/mcp",
 "mcp_tool": "search_companies"}
{"title": "…", "price_usd": "25.00", "fulfillment": "webhook"}

How they actually differ#

inline stores your bytes and hands them back. Nothing is called, so nothing can fail after settlement and the delivery is always delivered. Buyers get unlimited re-fetches of the same payload, which is retry safety, not generosity — replaying costs nobody anything. That is also why it cannot be a package.

relay calls your endpoint after the money settles and forwards what it says, so the response can be different every time. The buyer's parameters are forwarded as your query string — mcp does the same, as tool arguments, and the other three ignore them. One payment buys 3 deliveries by default — not 1, because a buyer whose connection drops after paying must be able to re-fetch, and not unlimited, because each delivery spends your upstream quota. If your origin times out, is unreachable, returns a non-2xx, or exceeds the body cap, the buyer gets 502 with their receipt id and the delivery is recorded failed. They never see your host or your error text.

mcp connects to your MCP server as a client and calls one tool. Two products live here: omit mcp_tool and one price buys any tool, with the buyer naming it at call time; set it and the checkout buys that tool, enforced on every call. origin_method is forced to POST.

webhook returns the buyer nothing at payment time and is the only mode where the sale stays open after the money moves. It sits at pending until you close it with c402 fulfilled. Use it for anything you cannot return over HTTP in the moment; do not use it as "how I get notified", because every paid checkout fires checkout.paid to your registered endpoints regardless of mode.

Describe it well enough to sell#

A bare title and price will get you some sales. An offer card gets you more, because an agent can tell whether your data fits its task before spending.

c402 checkouts create \
  --title "Swiss company financials" --price 0.10 --pay-to 0x... \
  --fulfillment relay --origin-url https://api.yourco.com/v1/financials \
  --input-schema  '{"company_uid": "string"}' \
  --output-schema '{"company_name": "string", "revenue": "number", "employees": "number"}' \
  --example-input '{"company_uid": "CHE-123.456.789"}' \
  --freshness "updated daily" \
  --coverage "all 26 cantons" \
  --source "Zefix commercial register"

Schemas and examples accept @file.json — real ones outgrow a shell argument:

c402 checkouts create --output-schema @schema.json --example-output @sample.json ...

Pricing#

Set the price you want. The fee is added on top and shown separately, so the buyer sees both numbers and you receive exactly what you asked for.

The fee is 0.5% of the price plus a fixed $0.01. The fixed part is what one on-chain settlement costs to land, and it costs the same whether the sale is $0.01 or $1,000.

Sub-cent prices work — there is no minimum on a single call. But the fixed part is charged per payment, so selling calls for less than a cent each means selling a package, where one settlement covers many calls.

Offering buyer protection#

Selling something expensive, transferable, or trust-heavy (a repo, a domain, a physical thing)? Offer escrow: add "escrow_offer": "optional" to your create and the checkout advertises a protected twin the buyer can choose at pay time — or create with POST /v1/escrow-checkouts to make protection the only face. You get paid when the escrow releases (automatically after the settle window unless the buyer disputes); the fee is 1% instead of 0.5% and the buyer pays it. How escrow works.

Getting paid#

Money lands in pay_to on-chain, in the same transaction that takes the fee. There's no balance, no payout schedule, and no withdrawal request, because checkout402 never holds it.

Build unarmed, then go live#

c402 keys create --name dev --mode test     # test keys can't move real money
c402 checkouts create --test ...            # unarmed: settles with a synthetic receipt

When it works end to end, arm it in place — same id, same URL:

c402 checkouts go-live chk_abc123

Nothing else changes, and rehearsal doesn't stop: every checkout keeps a test face at /c/{id}/test that settles with no money, forever, and can never be armed. Scripts point there; buyers get the bare URL.

Selling many endpoints#

Don't create sixty checkouts by hand. Point Claude at your API and let it read your routes and docs — see Connect Claude.

Or loop the CLI, since every command speaks JSON:

jq -c '.[]' products.json | while read -r p; do
  c402 checkouts create --json \
    --title    "$(jq -r .title <<<"$p")" \
    --price    "$(jq -r .price <<<"$p")" \
    --origin-url "$(jq -r .url <<<"$p")" \
    --fulfillment relay --pay-to "$PAYOUT"
done

Knowing when you've been paid#

Poll GET /v1/checkouts, or register a webhook and be told — see Webhooks.