Skip to main content
Faremeter’s plugin architecture allows community developers to create custom wallet adapters, payment schemes, and middleware integrations. Every layer of the stack is replaceable.

What can be extended

Building a custom wallet adapter

A wallet adapter is a factory function that returns an object capable of signing payment proofs. The exact shape depends on the chain, but the pattern is the same: accept credentials, return a signer.
The wallet is then passed to a payment handler. See Wallets & Signing for the full adapter pattern.

Building a custom payment handler

A payment handler bridges a wallet and a payment scheme. It receives payment requirements from a 402 response and returns PaymentExecer objects for any requirements it can fulfill.
Register the handler with the fetch wrapper:
See Payment Handlers for the full interface and composition model.

Building a custom facilitator handler

To support a new chain on the facilitator side, implement the FacilitatorHandler interface:
Wire it into a facilitator:
Handlers return null from handleSettle and handleVerify for schemes they don’t support, allowing multiple handlers to coexist. See Facilitator for the full setup.

Building a custom middleware adapter

If you use a framework other than Express or Hono, use handleMiddlewareRequest from @faremeter/middleware/common to wire up the payment flow manually. You provide functions to read headers, send responses, and handle the request body.
See Middleware Overview for the full API reference.

Publishing plugins

When publishing a faremeter plugin:
  1. Use the naming convention faremeter-* or @your-scope/faremeter-* for discoverability.
  2. Declare @faremeter/types as a peer dependency for type compatibility.
  3. Export your factory functions as the package’s public API.
  4. Include a README with a working example.

Plugin registry

Visit the faremeter plugin registry to browse community-contributed packages.

Further reading