> ## Documentation Index
> Fetch the complete documentation index at: https://docs.faremeter.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Payment Schemes

> How payment schemes work in faremeter and what chains are supported.

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:

| Field     | Example           | Description            |
| --------- | ----------------- | ---------------------- |
| `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.

```typescript theme={null}
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](/concepts/networks-and-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).

```typescript theme={null}
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](/flex/overview) and [Quickstart](/flex/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.

```typescript theme={null}
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:

```typescript theme={null}
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](/server/middleware-overview) for the body API.

| `capturesAt` | Phases    | Body callback flow                      |
| ------------ | --------- | --------------------------------------- |
| `"request"`  | one-phase | calls `capture()` immediately           |
| `"response"` | two-phase | calls `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.

<Warning>
  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](#flex-prepaid-escrow) 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](/marketplace/publisher)).
</Warning>

## Adding new schemes

New payment schemes can be added through the [payment handler interface](/concepts/payment-handlers). See [Plugins](/plugins) for community-contributed schemes.

## Further reading

* [Wallets & Signing](/concepts/wallets-and-signing) -- How wallets interact with payment schemes.
* [Networks & Assets](/concepts/networks-and-assets) -- Supported networks and tokens.