Payment Types

The Meridian facilitator accepts several payment payload types through POST /v1/settle. The facilitator inspects each settle request and routes it to the correct settlement path automatically; clients do not call a separate endpoint for Permit2, Circle Gateway, or Solana settlement.

Supported types

x402 (EIP-3009)

Default scheme. Buyer signs an EIP-3009 transferWithAuthorization for USDC and Meridian settles through X402ProxyFacilitator on the destination chain. Use this path when the payment token natively exposes EIP-3009.

Permit2 (non-EIP-3009)

Current path on MegaETH, BSC, and BOT chain when the token does not expose EIP-3009. Buyer approves Permit2 once, then signs a witness authorization that Meridian settles through x402ExactPermit2Proxy.

Upto (Permit2)

Usage-based pricing on any supported network. Buyer signs a Permit2 witness authorization for a maximum amount; Meridian settles the actual usage amount (≤ the signed max) through x402UptoPermit2Proxy.

Circle Gateway (Batched)

Gas-free, batched USDC nanopayments backed by Circle’s Gateway Wallet. Detected via paymentRequirements.extra.name === "GatewayWalletBatched".

Solana (SVM)

USDC payments on Solana settled through the meridian_x402 program. The buyer signs the settlement transaction and the facilitator co-signs as fee payer. Detected via network === "solana" / "solana-devnet".

Comparison

Capability	x402 (EIP-3009)	Permit2 fallback	Circle Gateway Batched
Tokens	USDC	Any ERC-20	USDC only
Minimum payment	Token-decimal granularity	Token-decimal granularity	$0.000001 USDC
Settlement target	`X402ProxyFacilitator`	`x402ExactPermit2Proxy` (via facilitator)	Circle Gateway API
Buyer one-time setup	None	`approve(Permit2, ∞)`	Deposit USDC into Gateway Wallet
Per-payment signing	EIP-3009 typed data	Permit2 witness typed data	EIP-712 typed data over Gateway Wallet domain
Gas paid by buyer	None	None	None
Cross-chain	Same-chain or Across via `destinationChainId`	Same-chain	Unified balance across all funded chains
Buyer experience	< 2s same-chain; Across fill for cross-chain	< 2s on-chain settlement	Instant signature verification; onchain settlement batched by Circle
Platform fee / cashback	Supported	Supported	Not applied (Meridian fee logic is skipped on the batched path)

Upto scheme (usage-based pricing)

The upto scheme decouples the signed authorization from the settled amount: the buyer signs a Permit2 witness authorization for a maximum amount before consuming the resource, and the seller settles the actual usage amount afterwards. It is available on every supported network, since it always settles through Permit2 (x402UptoPermit2Proxy at 0x402015c795ecb48A360bDC6e35a2EaEb313a0002, the same address on every chain). Differences from the exact Permit2 flow:

paymentRequirements.scheme is "upto" and maxAmountRequired is the cap the buyer signs, not the final price.
The buyer signs with x402UptoPermit2Proxy as the Permit2 spender, and the witness carries an extra facilitator field bound to the Meridian facilitator contract: { to, facilitator, validAfter }.
At settle time the seller passes the final amount as paymentRequirements.extra.settleAmount (base units, must be 0 < settleAmount ≤ maxAmountRequired). If omitted, the full signed maximum is settled. Platform fees, treasury fees, and cashback all apply to the settled amount only.

Accepting payments from multiple chains

An x402 challenge can expose multiple payment routes in accepts. Each route is a full paymentRequirements object for the source chain the buyer will pay from. The buyer or SDK selects the requirement that matches the connected wallet chain, then signs against that source chain’s token contract. For example, a seller that wants to receive settlement on Base while allowing buyers to pay from Base, Ink, or Optimism would return one requirement per source chain:

{
  "x402Version": 1,
  "accepts": [
    {
      "scheme": "exact",
      "network": "base",
      "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
      "payTo": "0x8E7769D440b3460b92159Dd9C6D17302b036e2d6",
      "maxAmountRequired": "1000000",
      "resource": "https://seller.example/api/tool",
      "description": "Paid access",
      "mimeType": "application/json",
      "maxTimeoutSeconds": 300,
      "extra": {
        "name": "USD Coin",
        "version": "2",
        "creditedRecipient": "0x1111111111111111111111111111111111111111",
        "destinationChainId": 8453
      }
    },
    {
      "scheme": "exact",
      "network": "ink",
      "asset": "0x2D270e6886d130D724215A266106e6832161EAEd",
      "payTo": "0x8E7769D440b3460b92159Dd9C6D17302b036e2d6",
      "maxAmountRequired": "1000000",
      "resource": "https://seller.example/api/tool",
      "description": "Paid access",
      "mimeType": "application/json",
      "maxTimeoutSeconds": 300,
      "extra": {
        "name": "USD Coin",
        "version": "2",
        "creditedRecipient": "0x1111111111111111111111111111111111111111",
        "destinationChainId": 8453
      }
    },
    {
      "scheme": "exact",
      "network": "optimism",
      "asset": "0x0b2C639c533813f4Aa9D7837CAf62653d097Ff85",
      "payTo": "0x8E7769D440b3460b92159Dd9C6D17302b036e2d6",
      "maxAmountRequired": "1000000",
      "resource": "https://seller.example/api/tool",
      "description": "Paid access",
      "mimeType": "application/json",
      "maxTimeoutSeconds": 300,
      "extra": {
        "name": "USD Coin",
        "version": "2",
        "creditedRecipient": "0x1111111111111111111111111111111111111111",
        "destinationChainId": 8453
      }
    }
  ]
}

For a cross-chain EIP-3009 payment, network, asset, and payTo describe the source chain. extra.destinationChainId describes the destination chain where Meridian settles after Across fills the bridge. A Base-only requirement cannot be paid from Ink; the seller must expose an Ink-source requirement for an Ink-funded buyer. Across uses exact-input routing in the current flow. If the seller must receive an exact destination-chain amount, quote the route and set the source-chain maxAmountRequired high enough to cover Across fees.

How routing works

POST /v1/settle follows this decision tree. It distinguishes between EIP-3009 and Permit2 by trying the standard payment payload first and falling back to the Permit2 payload: The Solana branch is checked first, keyed off paymentPayload.network; a solana / solana-devnet payment is routed to the meridian_x402 program settlement path (the payload carries a base64 transaction instead of an EIP-3009 or Permit2 authorization). See Solana Program. The “is this a batched payment?” check is implemented via isBatchPayment from @circle-fin/x402-batching/server. It looks at paymentRequirements.extra only; the rest of the request body keeps the same x402 v1 shape for EIP-3009 and Circle Gateway paths. Inside the default EIP-3009 path, Meridian compares the source chain from paymentPayload.network with paymentRequirements.extra.destinationChainId. If they differ, the facilitator pulls source-chain USDC and routes the destination-chain settlement through Across. If they match or destinationChainId is omitted, settlement stays on the source chain.

Choosing a payment type

Building a typical x402 paywall on Base, Optimism, Arbitrum, Polygon, etc. → Exact (EIP-3009). Nothing extra to set up for native EIP-3009 tokens; follow the Quickstart.
Accepting USDC from several source chains while settling to one destination chain → Exact (EIP-3009) with one accepts entry per source chain and extra.destinationChainId set on routes that should settle elsewhere via Across.
Integrating Avalanche, Sei, or Arc Testnet on the Instant demo → Exact (EIP-3009), same-chain only. Use matching source and destination network ids; Across cross-chain is not used on these chains. See Supported Networks.
Integrating MegaETH, BSC, or BOT chain testnet/mainnet when no EIP-3009 token is present → Permit2 via x402ExactPermit2Proxy 0x402085c248EeA27D92E8b30b2C58ed07f9E20001. Buyers approve Permit2 0x000000000022D473030F116dDEE9F6B43aC78BA3, sign with the proxy as spender, and keep facilitator fields bound to Meridian. See Smart Contracts and Supported Networks.
Usage-based pricing (metered APIs, per-token inference, pay-per-result) where the final price is only known after serving the request → Upto via x402UptoPermit2Proxy 0x402015c795ecb48A360bDC6e35a2EaEb313a0002, on any supported network. Buyer signs the maximum; seller settles the metered amount via extra.settleAmount.
High-frequency, sub-cent agent-to-agent payments where zero fees and unified balance matter more than per-tx settlement speed → Circle Gateway Batched.
Accepting USDC on Solana → Solana (SVM) via the meridian_x402 program, same-chain only. The buyer signs the settlement transaction and the facilitator co-signs as fee payer. See Solana Program and the Solana payments guide.

Do not mix the signing flows. EIP-3009 routes use a TransferWithAuthorization authorization under paymentPayload.payload. Permit2 routes use owner, permit, and witness fields instead. Solana routes carry a base64-encoded, payer-signed transaction under paymentPayload.payload. All are submitted to POST /v1/settle, but the signing code and payload shape are different.

Reference

POST /v1/verify: deprecated verification entrypoint for EIP-3009 and Circle Gateway payloads.
POST /v1/settle: settlement entrypoint for EIP-3009, Permit2, and Circle Gateway payloads.
GET /v1/supported: list of { x402Version, scheme, network } triples the facilitator accepts.

Overview

x402 Payments

x402 Inference

Merchant Top-ups

Nanopayments Gateway

Supported types

x402 (EIP-3009)

Permit2 (non-EIP-3009)

Upto (Permit2)

Circle Gateway (Batched)

Solana (SVM)

Comparison

Upto scheme (usage-based pricing)

Accepting payments from multiple chains

How routing works

Choosing a payment type

Reference

​Supported types

x402 (EIP-3009)

Permit2 (non-EIP-3009)

Upto (Permit2)

Circle Gateway (Batched)

Solana (SVM)

​Comparison

​Upto scheme (usage-based pricing)

​Accepting payments from multiple chains

​How routing works

​Choosing a payment type

​Reference

Supported types

Comparison

Upto scheme (usage-based pricing)

Accepting payments from multiple chains

How routing works

Choosing a payment type

Reference