Check a payment before you take it, then put it on chain

Two POST calls with the same body: verify checks six things and submits nothing, settle broadcasts and cannot be undone — both free, both with the gas on us.

—

settles recorded OK

GET /api/stats

—

settles recorded failed

GET /api/stats

—

verifies recorded

GET /api/stats

—

networks with activity

GET /api/stats

Both counters, and what they are not. The failed count is published next to the successful one on purpose: a page that shows only successes is not reporting, it is advertising. Neither number is a ledger — the chain is. The record is written after settlement resolves, fire-and-forget, so a store that is unreachable loses rows and never blocks a payment.

And the endpoint's own two warnings, verbatim:

“—”

The two calls

POST /verify answers whether a signed authorization would settle — signature, nonce, amount, timestamps, token and network — and submits nothing. POST /settle broadcasts it. Verify is free to call, safe to repeat and answers in milliseconds; settle costs the facilitator gas and cannot be undone. The two take the same body.

curl -sS https://facilitator.ultravioletadao.xyz/verify \
  -H 'content-type: application/json' \
  -d '{"x402Version":1,
       "paymentPayload":{ ... the buyer signature ... },
       "paymentRequirements":{ ... the seller terms ... }}'

Full field-by-field shapes, the retryable and non-retryable failures, and the EIP-712 domain-name trap that catches most first integrations, are in /skill.md. The same two calls are MCP tools at /mcp, dispatched through these very handlers.

A settle that timed out is not a settle that failed. The transaction may already be on its way. Retry with the same Idempotency-Key header: the same key with the same payment returns the first result instead of settling twice, and the same key with a different payment is refused with 409. Generate a fresh unguessable value per payment — keys share one namespace across all callers, so a predictable one can be claimed by somebody else's settle first.

x402: The protocol. An HTTP endpoint answers 402 Payment Required with the terms it accepts; the caller signs one of them off-chain and retries with the signature in a header.
facilitator: The service that checks a signed payment and puts it on chain, paying the network fee. This one. It never holds your money and never holds your key.
verify: The free call. It answers whether an authorization would settle and submits nothing, so it is safe to repeat.
settle: The call that spends. It broadcasts the transfer and cannot be undone on any chain here.

Every route of the core

Method	Route	What it answers	Moves money
`GET`	`/verify`	Verification request schema	no
`POST`	`/verify`	Verify payment signature and requirements	no
`GET`	`/settle`	Settlement request schema	no
`POST`	`/settle`	Execute payment on-chain via EIP-3009	yes, irreversibly
`POST`	`/mcp`	MCP server (Streamable HTTP, stateless): the same four calls as tools	only through settle
`GET`	`/mcp`	The MCP guide for humans: transports, the four tools, and the traps	no
`POST`	`/accepts`	Negotiate and enrich payment requirements (Faremeter middleware)	no

Escrow — the x402r extension

Plain x402 is final on arrival: the buyer signs, the transfer lands, and there is no step in between where a refund could live. Escrow adds one. Funds are authorized into a contract and released, captured or refunded when a condition is met, so a payment can be undone by the terms both sides already agreed to rather than by trusting the seller afterwards.

It is the same POST /settle — there is no separate endpoint. The escrow path is taken when paymentPayload.extensions.refund is present; a plain settle never touches it. Where it can run is not a matter of configuration: the contracts have to be deployed on that chain, and /supported is what says where they are.

Where escrow is advertised right now, straight from /supported:

loading…

The escrow routes

Method	Route	What it answers	Moves money
`POST`	`/settle`	Settle to escrow proxy when "refund" extension is present	yes, irreversibly
`POST`	`/settle`	Settle via AuthCaptureEscrow when scheme="escrow"	yes, irreversibly

Add {"refund": {"window": 86400}} to extensions for trustless refund support via DepositRelay proxies.

Advanced escrow with authorize/charge/release/refund flows. Funds held in TokenStore until capture.

Upto — pay for what you used

A metered call cannot know its price before it runs. exact forces the seller to pick a number up front and be wrong in one direction or the other; upto lets the buyer authorize a ceiling and be charged what was actually consumed, in one signature, still gasless. It is built on Uniswap's Permit2, which is what makes a variable amount possible without a second round trip.

The scheme is advertised only where the Permit2 proxy is genuinely deployed. That list is not a config file somebody edits optimistically — it is checked against the chain with eth_getCode on two independent RPCs before an entry is added, because advertising a scheme that cannot settle is worse than not offering it.

Where upto is advertised right now, straight from /supported:

loading…

The upto routes

Method	Route	What it answers	Moves money
`POST`	`/verify`	Verify Permit2 authorization when scheme="upto"	no
`POST`	`/settle`	Settle for actual usage amount via x402UptoPermit2Proxy	yes, irreversibly

Client authorizes max amount via Permit2 signature. Server settles for actual usage (<= max). If usage is $0, no on-chain transaction is submitted.

Every scheme this facilitator settles

scheme	what it is	v1 names	CAIP-2 ids
loading…

Counted from /supported when this page loads, not typed. The two columns are not a formatting choice: a chain is published under two spellings and a scheme does not have to appear under both. Measured on 2026-09-02, escrow, commerce and upto are advertised under the CAIP-2 spelling only — zero v1 names between them — while exact appears under both. A client that discovers schemes by reading only the v1 entries will conclude this facilitator has no escrow.

What it costs

Nothing, to either side. This facilitator takes no fee, has no accounts and issues no API keys; its own routes never answer 402. It pays the gas for every settlement out of its own wallets, whose balances are on /networks — that is the real cost of running it, and it is visible rather than described.