Settle x402 payment
x402 Payments
Settle x402 Payment
Settle an x402 payment with organization-specific authentication. This endpoint supports standard exact EIP-3009 EVM payloads, Circle Gateway batched payloads, and the Permit2 payload used on non-EIP-3009 EVM networks.
POST
Settle x402 payment
Settle an x402 payment on-chain after verification. This endpoint executes the actual blockchain transaction to transfer funds according to the x402 payment authorization.
For EIP-3009 payloads, both
The settlement response transaction hash is the source-chain transaction that
started the Across bridge. The seller receives the destination-chain output
after Across fill and Meridian destination-side settlement.
Permit2 settlement is used for
When
paymentRequirements.extra.name === "GatewayWalletBatched", this
endpoint forwards the request to Circle’s Gateway API instead of settling
on-chain. See Circle Gateway
(Batched) for the batched
payment type and Payment Types for an
overview of all routing paths.Authentication
Requires API key authentication with organization context.Recipient
For standard merchant integrations, the wallet that receives settled funds is configured in your organization settings and tied to your API key. KeeppaymentRequirements.payTo set to the Meridian facilitator contract for the
network; do not use payTo for your merchant wallet.
Platform and marketplace integrations can route the end payout with
paymentRequirements.extra.creditedRecipient. See Marketplace
Fees for that flow.
Standard Request Body
authorization.to and payTo must be set to the
facilitator contract address for the network. For Permit2 payloads, keep
payTo and witness.to bound to the facilitator.
Cross-Chain EIP-3009 Request Body
Cross-chain USDC settlement uses the samePOST /v1/settle endpoint and the
same EIP-3009 payload shape. The payment payload is signed on the source chain
where the buyer has USDC. Set paymentRequirements.network, asset, and
payTo for that source chain, then set paymentRequirements.extra.destinationChainId
to the destination chain where Meridian should settle after Across fills the
bridge.
For example, a buyer paying from Ink USDC to a seller receiving on Base uses
network: "ink" and destinationChainId: 8453:
A seller that accepts payments from multiple source chains should expose one
paymentRequirements object per route in the x402 accepts array. A
Base-source requirement cannot be paid by a buyer who only has USDC on Ink.
Return an Ink-source requirement with extra.destinationChainId: 8453 for
that route.Permit2 Request Body
There is no separatePOST /v1/permit2 endpoint. Permit2 payments are settled
through POST /v1/settle with the Permit2 payload shape below.
megaeth, bsc, bot-chain,
bot-chain-testnet, and tempo. If the buyer has not already approved Permit2 for the
token, include the optional paymentPayload.payload.permit2612 object for
tokens that support ERC-2612:
On chains where the payment token does not expose EIP-3009, use Permit2
through
x402ExactPermit2Proxy 0x402085c248EeA27D92E8b30b2C58ed07f9E20001.
This is the canonical exact Permit2 proxy from the official x402
repository, deployed at
the same address on supported EVM chains. This includes MegaETH, BSC, and BOT
chain testnet and mainnet. New integrations should keep payTo pointed at the
facilitator, set paymentRequirements.asset to the ERC-20 token address,
approve Permit2 0x000000000022D473030F116dDEE9F6B43aC78BA3, and sign the
Permit2 witness with the proxy as spender. Your backend should still call
Meridian POST /v1/settle.| Network | Facilitator Contract |
|---|---|
arc-testnet | 0x8e633dBf31adCc7D41BE3e95B7c8DD3526B5235A |
bot-chain-testnet | 0x8e633dBf31adCc7D41BE3e95B7c8DD3526B5235A |
bot-chain | 0x8E7769D440b3460b92159Dd9C6D17302b036e2d6 |
base | 0x8E7769D440b3460b92159Dd9C6D17302b036e2d6 |
bsc | 0x8E7769D440b3460b92159Dd9C6D17302b036e2d6 |
base-sepolia | 0x8e633dBf31adCc7D41BE3e95B7c8DD3526B5235A |
avalanche | 0x8E7769D440b3460b92159Dd9C6D17302b036e2d6 |
optimism | 0x8E7769D440b3460b92159Dd9C6D17302b036e2d6 |
arbitrum | 0x8E7769D440b3460b92159Dd9C6D17302b036e2d6 |
optimism-sepolia | 0x8e633dBf31adCc7D41BE3e95B7c8DD3526B5235A |
polygon | 0x8E7769D440b3460b92159Dd9C6D17302b036e2d6 |
unichain | 0x8E7769D440b3460b92159Dd9C6D17302b036e2d6 |
ink | 0x8E7769D440b3460b92159Dd9C6D17302b036e2d6 |
worldchain | 0x8E7769D440b3460b92159Dd9C6D17302b036e2d6 |
sei | 0x8E7769D440b3460b92159Dd9C6D17302b036e2d6 |
hyperevm | 0x8E7769D440b3460b92159Dd9C6D17302b036e2d6 |
megaeth | 0x8E7769D440b3460b92159Dd9C6D17302b036e2d6 |
tempo | 0x8E7769D440b3460b92159Dd9C6D17302b036e2d6 |
monad | 0x8E7769D440b3460b92159Dd9C6D17302b036e2d6 |
robinhood | 0x8E7769D440b3460b92159Dd9C6D17302b036e2d6 |
Response
Success Response
Error Response
Error Codes
invalid_payload- Payment payload format is invalidinvalid_payment_requirements- Payment requirements format is invalidinsufficient_funds- Insufficient balance for settlementunexpected_settle_error- Unhandled exception during settlementinvalid_transaction_state- On-chain transaction failed
Authorizations
Body
application/json