Skip to main content
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 or Circle Gateway settlement.

Supported types

Exact (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.

Circle Gateway (Batched)

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

Comparison

CapabilityExact (EIP-3009)Permit2 fallbackCircle Gateway Batched
TokensUSDCAny ERC-20USDC only
Minimum paymentToken-decimal granularityToken-decimal granularity$0.000001 USDC
Settlement targetX402ProxyFacilitatorx402ExactPermit2Proxy (via facilitator)Circle Gateway API
Buyer one-time setupNoneapprove(Permit2, ∞)Deposit USDC into Gateway Wallet
Per-payment signingEIP-3009 typed dataPermit2 witness typed dataEIP-712 typed data over Gateway Wallet domain
Gas paid by buyerNoneNoneNone
Cross-chainSame-chainSame-chainUnified balance across all funded chains
Buyer experience< 2s on-chain settlement< 2s on-chain settlementInstant signature verification; onchain settlement batched by Circle
Platform fee / cashbackSupportedSupportedNot applied (Meridian fee logic is skipped on the batched path)

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 “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.

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; the SDK middleware handles it.
  • 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. The BSC and MegaETH forwarders remain backward compatibility only. See Smart Contracts and Supported Networks.
  • High-frequency, sub-cent agent-to-agent payments where zero fees and unified balance matter more than per-tx settlement speedCircle Gateway Batched.

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.