Updated · by true402
In an x402 payment the buyer signs and the seller serves. Somebody still has to check the signature and put the transfer on-chain. That is the facilitator's job. We built our own, so this guide covers what it does and what it leaves to you.
GET /supported → { "kinds": [ { "x402Version": 2, "scheme": "exact", "network": "eip155:8453" } ], "extensions": [] }
POST /verify { paymentPayload, paymentRequirements }
→ { "isValid": true, "payer": "0x…" }
→ { "isValid": false, "invalidReason": "insufficient_funds", "payer": "0x…" }
POST /settle { paymentPayload, paymentRequirements }
→ { "success": true, "transaction": "0x<tx hash>", "network": "eip155:8453", "payer": "0x…" }
→ { "success": false, "errorReason": "…", "transaction": "", "network": "…" }transferWithAuthorization on-chain and returns the transaction hash once it is mined.The wire format is part of the spec in x402-foundation/x402. Coinbase's reference client (HTTPFacilitatorClient in @x402/core) speaks it, so any facilitator that follows it can be swapped for another by changing a URL.
An EIP-3009 authorization is only a signature until somebody submits it. Submitting needs an RPC connection, a wallet holding gas, nonce and fee handling, and receipt polling. Most API sellers don't want any of that. The facilitator takes it on: it pays the gas from its own wallet and the USDC moves straight from buyer to seller. It never holds the funds, because the recipient is fixed inside the buyer's signature.
The buyer never needs ETH either. That is why x402 on Base works with a wallet holding USDC only.
pay.openfacilitator.io that need no account or key. You trust a third party you have no contract with, which makes your own checks (§05) more important.For a live list of the facilitators in use, with the chains they serve and their recent settlement volume, see x402-list's facilitator list. Fees change and differ by provider, so check each one's own pricing page rather than a comparison that may be out of date.
true402 built its own facilitator, because operating with no account anywhere is a hard rule for this project. The rest of this page is what that taught us.
A facilitator holds a wallet that pays gas for strangers' transfers. Anything it settles without good reason is gas burned or a service handed out for free.
"0" and an authorization worth 0 from an empty wallet passes every "is it enough" test. We refuse any amount that is not positive./settle runs the full verification again, including an on-chain read of the payer's balance and whether the nonce is already used.// What a resource server should check itself, before it trusts any facilitator's "isValid":
payload.network === quote.network // the CAIP-2 id WE quoted, e.g. eip155:8453
quote.asset === canonical USDC // pinned server-side, never taken from the request
authorization.to === our payTo
authorization.value === quote.amount // EXACT. Not >=. There is no refund path.
recoverTypedData(sig) === authorization.from // EIP-712 over the genuine USDC domain
usdc.balanceOf(from) >= authorization.value
usdc.authorizationState(from, nonce) === false // nonce not already used on-chain
seen(network:from:nonce) === false // accept each authorization onceExact versus at-least. Our facilitator's verify checks that the payment is at least the requirement. That is correct for a facilitator: it answers for resources it never priced. The resource server knows its own price, so it checks for exactly that amount. Settlement moves the signed value and there is no refund path, so an overpayment would just be kept. Equality also ties the signature to the one resource it was quoted for.
Don't serve on the facilitator's word alone. We have seen a facilitator return isValid: true for a payment with a corrupted signature, and for a correctly signed payment from a wallet holding no USDC. A server that serves on that answer and settles afterwards gives its product away. true402 now recovers the signature and reads balance and nonce itself before it serves, and holds back the answer when a settlement is refused.
Settlement preemption. This is one of the attacks described in the research paper "Five Attacks on x402". EIP-3009 lets anyone submit a signed authorization. If someone lands it before the facilitator, the seller is still paid, but the facilitator reports a failure. The tempting fix, "the nonce shows as used, so we were paid", is wrong: the nonce is the payer's choice, so a payer can sign a second authorization with the same nonce to themselves and land that one first. The safe check is the AuthorizationUsed(payer, nonce) event plus, in the same transaction, a USDC Transfer of exactly the quoted amount to your own address. A mined revert is a refusal, not an "uncertain".
Every gate response should also carry Cache-Control: no-store, private, so a cache in between never keeps a paid answer or a payment header.
Every true402 endpoint applies the server-side checks above. Request one unpaid with curl -i -X POST https://true402.dev/api/v1/web-extract to see the 402, then pay it with any v2 client from the buy guide. Field-level detail is in the API reference. For how buyers find paid endpoints, read the x402 Bazaar guide; for the protocol from the start, what is x402.
A service that checks and settles x402 payments for a resource server. The server sends it the buyer's signed payment and its own payment requirements. /verify says whether the payment is valid. /settle submits it on-chain and returns the transaction hash. /supported lists the schemes and networks it handles. The server never has to run a node or hold gas.
No. The spec lets a resource server verify and settle by itself. A facilitator is a convenience: someone has to submit the signed authorization on-chain and pay the gas, and a facilitator does that for you.
Three kinds exist. Coinbase's CDP facilitator needs a CDP API key, has a monthly free allowance of on-chain transactions and charges per transaction above it, and its settlements are what get endpoints indexed in the Coinbase Bazaar. Open facilitators such as pay.openfacilitator.io need no account. Or you can self-host one with the reference SDKs. Pick by what you can accept: an account, a third party, or running a gas wallet yourself.
Not on that alone. A facilitator answers for a payment it did not quote, so it can only check that the payment covers the requirement it was given. The resource server should still check its own quote: exact amount, recipient, asset, network, a valid signature, enough balance and an unused nonce. We have seen a facilitator report a corrupted signature and an empty wallet as valid.
Whoever submits the EIP-3009 authorization on-chain. With a facilitator, that is the facilitator's own wallet. The buyer only signs, and the seller only receives, so neither needs ETH.
EIP-3009 lets anyone submit a signed authorization, not only the facilitator. Someone who sees the payment header in transit can land it first. The money still reaches the seller, because recipient and amount are in the signature, but the facilitator's own settlement then fails. A server can recover by finding the AuthorizationUsed event for that payer and nonce and checking that the same transaction moved exactly the quoted USDC to its own address.
It depends on which one. Coinbase's CDP facilitator documents a monthly free allowance of transactions and a per-transaction fee above it, with verification free. Open facilitators set their own terms. A self-hosted facilitator has no fee, but you pay the gas for every settlement from your own wallet. In every case the buyer pays no gas: the facilitator submits the transfer.
Yes. The protocol only defines the /verify, /settle and /supported endpoints, so any service that implements them works, and a resource server switches facilitator by changing a URL. You then hold a hot wallet that pays gas, so it needs the refusals in §04: pin the asset, refuse zero amounts, restrict recipients, lock per authorization, and cap the gas price.
The paid answer should not be released. A server that serves first and settles afterwards gives the answer away whenever settlement fails. The safe order is verify, do the work, settle, and only then return the result with the PAYMENT-RESPONSE header. A failed settlement is answered with a 402 and the buyer is not charged.