Skip to main content
A facilitator is a service that sits between the resource server and the blockchain. It verifies payment proofs and settles transactions on-chain so that merchants never need to manage blockchain infrastructure directly.

​
Why facilitators exist

Without a facilitator, every merchant would need to:
  • Run blockchain nodes or connect to RPCs
  • Verify cryptographic signatures for each payment scheme
  • Submit transactions and monitor confirmations
  • Handle gas fees and failed transactions
Facilitators abstract all of this. The merchant sends the payment proof to the facilitator, and the facilitator handles verification and settlement.

​
How they work

Client                    Server                  Facilitator        Blockchain
  |                         |                         |                  |
  |--- request + payment -->|                         |                  |
  |                         |--- verify + settle ---->|                  |
  |                         |                         |--- submit tx --->|
  |                         |                         |<-- confirmation -|
  |                         |<-- settlement result ---|                  |
  |<-- 200 + resource ------|                         |                  |

​
Facilitator API

Facilitators expose four endpoints:
EndpointMethodPurpose
/acceptsPOSTReturns enriched payment requirements (adds facilitator-specific fields)
/verifyPOSTVerifies a payment proof without settling
/settlePOSTVerifies and settles a payment on-chain
/supportedGETLists supported schemes, networks, and assets

​
/accepts

The middleware calls /accepts with partial payment requirements (scheme, network, asset, amount, recipient, resource URL). The facilitator enriches them with blockchain-specific details needed for the client to construct a valid payment: Solana enrichment:
  • Fee payer address (the facilitator co-signs and pays transaction fees)
  • Token decimals
  • Recent blockhash
EVM enrichment:
  • EIP-712 domain parameters: name, version, chainId, verifyingContract
The enriched requirements are cached by the middleware and returned to clients in 402 responses.

​
/settle

When a client sends a valid payment header (X-PAYMENT or PAYMENT-SIGNATURE), the middleware forwards it to /settle along with the original payment requirements. The facilitator:
  1. Validates the payment payload structure
  2. Verifies cryptographic signatures
  3. Checks amounts, addresses, and nonces
  4. Submits the transaction on-chain:
    • Solana: Co-signs the partially-signed transaction as fee payer and submits to Solana RPC
    • EVM: Calls transferWithAuthorization on the token contract and pays gas
  5. Returns { success: true, transaction, network }
Legacy v1 implementations may return these fields as txHash and networkId. Spec-compliant v1 and v2 both use transaction and network. See Protocol Versions for the full mapping.

​
/verify

Verifies a payment proof without settling it on-chain. Useful for pre-validation before committing to settlement: 
curl -X POST https://facilitator.corbits.dev/verify \
  -H "Content-Type: application/json" \
  -d '{"paymentRequirements": {...}, "paymentPayload": {...}}'
Returns { isValid: true, payer: "..." } on success.

​
/supported

Returns the list of schemes, networks, and assets the facilitator supports. Use this to confirm compatibility: 
curl https://facilitator.corbits.dev/supported

​
Default facilitator

Corbits provides a free production-ready facilitator: 
https://facilitator.corbits.dev
This is the default used in faremeter’s middleware and examples. It supports:
ChainNetworks
Solanadevnet, mainnet-beta
EVMBase, Base Sepolia, SKALE Europa Testnet, Polygon PoS, Polygon Amoy, Monad, Monad Testnet
Query the /supported endpoint for the canonical list of supported schemes, networks, and assets: 
GET https://facilitator.corbits.dev/supported

​
Running your own

You can run a facilitator using @faremeter/facilitator. See the Facilitator guide for setup instructions.

​
In-process handlers

Facilitator handlers can also run in-process, embedded directly in the middleware. Instead of configuring a facilitatorURL, you pass FacilitatorHandler instances to the middleware via x402Handlers. The middleware calls them locally to resolve requirements, verify, and settle payments. Both modes use the same FacilitatorHandler interface, so handlers written for one mode work in the other. See the Middleware Overview for configuration details.

​
Further reading

  • Payment Schemes — What happens inside the facilitator for each chain.
  • Middleware — How to configure the middleware to talk to a facilitator.