Skip to main content
A payment scheme defines how a payment is made on a specific blockchain. Schemes handle the chain-specific details: constructing transactions, signing them, and producing the proof that gets sent in the X-PAYMENT header (v1) or PAYMENT-SIGNATURE header (v2).

​
Scheme identification

Every payment is identified by a tuple of three values:
FieldExampleDescription
scheme"exact"The payment method
network"solana-devnet"The blockchain network
asset"USDC"The token being used
When a server returns payment requirements, the client matches against this tuple to find a compatible payment handler.

​
Solana schemes

​
SPL Token payments

The primary Solana scheme uses SPL token transfers for payments. The client signs a transaction transferring tokens from their wallet to the merchant’s address. 
import { x402Exact } from "@faremeter/info/solana";

const requirements = x402Exact({
  network: "devnet",
  payTo: "7xKXwxRPMo2sUAT5...",
  asset: "USDC",
  amount: "10000",
});
Supported assets: USDC, PYUSD, USDT, USDG, USD1, USX, CASH, EURC, JupUSD, USDS, USDtb, USDu, USDGO, FDUSD. See Networks & Assets for per-network availability.

​
Native SOL

Faremeter also supports native SOL transfers for Solana payments.

​
Flex (prepaid escrow)

The @faremeter/flex scheme replaces per-request transactions with a prepaid escrow account and off-chain authorizations signed by a session key. The facilitator settles actual usage on-chain in batches after the work is done. This decouples service delivery from on-chain confirmation and is the right fit for variable-cost or high-frequency workloads (AI inference, streaming, metered APIs). 
import { createPaymentHandler } from "@faremeter/payment-solana/flex/client";
import { wrap } from "@faremeter/fetch";

const flexHandler = createPaymentHandler({
  network: "devnet",
  escrow: escrowAddress,
  mint: usdcMint,
  sessionKeyPair,
  sessionKeyAddress,
  rpc,
});

const flexFetch = wrap(fetch, { handlers: [flexHandler] });
See the Flex Overview and Quickstart for the full client and facilitator flow.

​
EVM schemes

​
EIP-3009 gasless transfers

The EVM scheme uses EIP-3009 transferWithAuthorization for gasless USDC payments. The client signs an EIP-712 typed message authorizing the transfer. The facilitator submits the transaction on-chain and pays the gas fees. 
import { x402Exact } from "@faremeter/info/evm";

const requirements = x402Exact({
  network: "base-sepolia",
  asset: "USDC",
  amount: "10000",
  payTo: "0x1234...",
});
Supported networks: Base, Base Sepolia, SKALE Europa Testnet, Polygon PoS, Polygon Amoy, Monad, Monad Testnet (7 networks). The gasless design means clients never need native tokens for gas. The facilitator covers transaction costs.

​
How schemes compose

Faremeter’s plugin architecture allows multiple schemes to coexist. A server can accept both Solana and EVM payments simultaneously: 
import { createMiddleware } from "@faremeter/middleware/express";
import { x402Exact as solanaX402Exact } from "@faremeter/info/solana";
import { x402Exact } from "@faremeter/info/evm";

const middleware = await createMiddleware({
  facilitatorURL: "https://facilitator.corbits.dev",
  accepts: [
    solanaX402Exact({
      network: "devnet",
      payTo: "7xKX...",
      asset: "USDC",
      amount: "10000",
    }),
    x402Exact({
      network: "base-sepolia",
      payTo: "0x1234...",
      asset: "USDC",
      amount: "10000",
    }),
  ],
});
The client selects the scheme it can fulfill based on its available wallets.

​
Capture timing: one-phase vs two-phase

Independent of which scheme is used, a payment can settle in one phase or two. The middleware body callback exposes two operations — authorize() (reserve funds) and capture() (settle them) — and a handler’s capturesAt value decides when capture runs. See the Middleware Overview for the body API.
capturesAtPhasesBody callback flow
"request"one-phasecalls capture() immediately
"response"two-phasecalls authorize() now, captures later
  • "request" — one-phase. The body calls capture() immediately, so the payment clears before the resource is produced. This is the simplest path, with no deferred settlement.
  • "response" — two-phase. The body calls authorize() now and defers capture to a later phase, once the final amount is known. The OpenAPI gateway, for example, captures at the /response step for usage-based pricing where the charge depends on a value in the response (such as usage.total_tokens).
The middleware resolves capturesAt per request from the matched handler’s authorize capability and the rule’s hasAuthorize flag, so the body callback does not have to inspect the context to choose a path. Two-phase capture requires a handler that can authorize (one that supports handleVerify); a scheme that cannot authorize is one-phase only.
Two-phase capture opens an authorize→capture window. For a non-escrow scheme like x402 exact, that window is rug-pullable — the payer can move funds before capture settles. Escrow-backed schemes like Flex are not exposed, because funds are pre-committed to escrow. Operators can pin the capture phase per route via x-faremeter-policy (see the Publisher page).

​
Adding new schemes

New payment schemes can be added through the payment handler interface. See Plugins for community-contributed schemes.

​
Further reading