@rail402.dev/facilitator as a library.
Why self-facilitate
Pointing at a hosted facilitator adds a network hop and a dependency on a service you do not run. Self-facilitation removes both: your server holds the sponsoring signer, submits the settlement itself, and serves the resource, all in one process. The non-custodial invariant is unchanged, because the only fund movement is submitting the buyer-signed authorization exactly as authorized. You still get automatic, settlement-gated cataloging, because the Bazaar runs in the same process as the facilitator.1. Install
2. Build the facilitator in-process
loadConfig reads configuration from the environment, and buildFacilitator returns a facilitator exposing verify, settle, and getSupported.
npx @rail402.dev/cli fund; to fund an address you already have, friendbot tops it up with XLM.
MAX_TRANSACTION_FEE_STROOPS defaults to 100000. A smart-account buyer cross-calls a verifier and a policy, which costs several times more, so raise the ceiling toward 500000 if you serve contract accounts. See Errors for the refusal a too-low ceiling produces.3. Wire it into your resource server
Pass the in-processfacilitator where you would otherwise pass a HTTPFacilitatorClient. It exposes the same verify, settle, and getSupported methods, so x402ResourceServer uses it directly and no HTTP hop happens.
server.js
/quote now returns a priced 402, and your own process verifies and settles the payment.
Next steps
Run the facilitator
Run verify and settle as a standalone service, with a durable catalog and metrics.
Charge for an endpoint
The full seller quickstart, from paywall to first settled payment.
Payment loop
What verify and settle actually do, and where fee sponsorship fits.
Packages
Every published package and what it is for.
When it fails
A misconfigured signer, an unfunded facilitator account, or a settlement fee aboveMAX_TRANSACTION_FEE_STROOPS each surface a machine-readable code and a non-null reason. See Errors.