Facilitator

The facilitator is the /settle server: it takes a payment authorization the gateway has already verified and submits the on-chain transfer, holding the gas key that the gateway itself never has. It’s a separate deployable from the gateway on purpose — see Architecture for why, and Gate vs settle for how it fits into the invocation lifecycle.

• Self-hosting a facilitator is OSS — run your own, with your own signer (currently a local key; AWS KMS is a designed but not-yet-wired backend).
• The managed facilitator — Commercial — is Zerker-operated settlement (settle.zerker.dev) so you don’t have to run gas-key infrastructure yourself.

Either way, it’s the same binary and the same wire contract (x402types.SettleRequest/SettleResponse) — pointing your gateway at a facilitator is one config value (facilitator_url on PATCH /v1/settlement/config), whether that URL is yours or Zerker’s.

What it does

POST /settle doesn’t trust that the gateway already verified the payment — it independently re-verifies the signature, amount, recipient, validity window, and network/asset policy before spending a wei of gas, then submits transferWithAuthorization on the caller’s behalf and waits for first-block inclusion before returning a transaction hash. See Endpoints for the full request/response shape and failure taxonomy.

In this section

• Custody posture — exactly what the facilitator holds (a gas key) and what it never touches (anyone’s funds), and why that’s true for both the self-hosted and managed deployments.
• Self-hosting vs managed — running your own facilitator (OSS) versus pointing at Zerker’s (Commercial): what each requires and what each buys you.
• Endpoints — /settle, /supported, and /healthz, with request/response examples and the failure taxonomy.
• Signer backends — the local-keystore signer versus AWS KMS, and why signing sits behind an interface either way.