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

# Payment Types

> Payment schemes and settlement paths supported by the Meridian facilitator

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

<CardGroup cols={2}>
  <Card title="x402 (EIP-3009)" icon="signature">
    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.
  </Card>

  <Card title="Permit2 (non-EIP-3009)" icon="shield">
    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`.
  </Card>

  <Card title="Upto (Permit2)" icon="gauge">
    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`.
  </Card>

  <Card title="Circle Gateway (Batched)" icon="layer-group">
    Gas-free, batched USDC nanopayments backed by Circle's Gateway Wallet.
    Detected via `paymentRequirements.extra.name === "GatewayWalletBatched"`.
  </Card>

  <Card title="Solana (SVM)" icon="coins">
    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"`.
  </Card>
</CardGroup>

## 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:

```json theme={"system"}
{
  "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:

```mermaid theme={"system"}
flowchart TD
    A[Incoming payment] --> S{isSupportedSolanaNetwork&#40;network&#41;?<br/>network == "solana" or "solana-devnet"}
    S -- Yes --> SV[Solana path<br/>meridian_x402 program settlement]
    S -- No --> B{isBatchPayment&#40;paymentRequirements&#41;<br/>extra.name == "GatewayWalletBatched"<br/>and extra.version == "1"?}
    B -- Yes --> F{isGatewayEnabledForNetwork&#40;network&#41;?}
    F -- Yes --> H[Forward to Circle Gateway API<br/>via BatchFacilitatorClient]
    F -- No --> G[HTTP 403<br/>errorReason: gateway_not_enabled]
    B -- No --> C{Payload parses as<br/>Permit2 payload?}
    C -- No --> D[Default x402 path<br/>X402ProxyFacilitator on-chain]
    C -- Yes --> E[Permit2 path<br/>x402ExactPermit2Proxy]
```

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](/payments/solana-program).

The "is this a batched payment?" check is implemented via [`isBatchPayment`](https://www.npmjs.com/package/@circle-fin/x402-batching) 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](/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](https://instant.mrdn.finance)** → 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](/api-reference/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](/payments/smart-contracts) and [Supported Networks](/api-reference/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](/api-reference/payment-types/circle-gateway).
* **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](/payments/solana-program) and the [Solana payments](/ai-skills/solana) 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`](/api-reference/endpoint/verify-payment): deprecated verification entrypoint for EIP-3009 and Circle Gateway payloads.
* [`POST /v1/settle`](/api-reference/endpoint/settle-payment): settlement entrypoint for EIP-3009, Permit2, and Circle Gateway payloads.
* [`GET /v1/supported`](/api-reference/endpoint/supported-payments): list of `{ x402Version, scheme, network }` triples the facilitator accepts.