Skip to main content
POST
/
v1
/
settle
Settle x402 payment
curl --request POST \
  --url https://api.mrdn.finance/v1/settle \
  --header 'Authorization: <api-key>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "paymentPayload": {
    "x402Version": 1,
    "scheme": "exact",
    "network": "base-sepolia",
    "payload": {
      "signature": "<string>",
      "authorization": {
        "from": "<string>",
        "to": "<string>",
        "value": "<string>",
        "validAfter": "<string>",
        "validBefore": "<string>",
        "nonce": "<string>"
      }
    }
  },
  "paymentRequirements": {
    "amount": "<string>",
    "recipient": "<string>",
    "network": "<string>",
    "asset": "<string>",
    "resource": "<string>",
    "description": "<string>",
    "mimeType": "<string>"
  }
}
'

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.

Settle an x402 payment on-chain after verification. This endpoint executes the actual blockchain transaction to transfer funds according to the x402 payment authorization.
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

The recipient wallet that receives settled funds is configured in your organization settings and tied to your API key. You do not need to specify the recipient in the request body.

​
Request Body

{
  "paymentPayload": {
    "x402Version": 1,
    "scheme": "exact",
    "network": "base-sepolia",
    "payload": {
      "signature": "0x...",
      "authorization": {
        "from": "0x742d35Cc6634C0532925a3b8D0c4E5e6C2aE7A3e",
        "to": "0x8e633dBf31adCc7D41BE3e95B7c8DD3526B5235A",
        "value": "1000000",
        "validAfter": "1234567890",
        "validBefore": "1234567899",
        "nonce": "0x..."
      }
    }
  },
  "paymentRequirements": {
    "scheme": "exact",
    "network": "base-sepolia",
    "maxAmountRequired": "1000000",
    "resource": "https://example.com/resource",
    "description": "Payment for resource access",
    "mimeType": "application/json",
    "payTo": "0x8e633dBf31adCc7D41BE3e95B7c8DD3526B5235A",
    "maxTimeoutSeconds": 3600,
    "asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e"
  }
}
Both authorization.to and payTo must be set to the facilitator contract address for the network.
For MegaETH, the recommended flow is now Permit2, not the forwarder. New integrations should keep payTo pointed at the facilitator, set paymentRequirements.asset to the ERC-20 token address, approve Permit2 0x000000000022D473030F116dDEE9F6B43aC78BA3, and sign with x402ExactPermit2Proxy 0x402085c248EeA27D92E8b30b2C58ed07f9E20001. Your backend should still call Meridian POST /v1/settle. The USDm forwarder is deprecated and should be kept only for legacy EIP-3009 clients.
On BSC, Meridian supports USDC through the same EIP3009Forwarder adapter pattern used by the legacy MegaETH USDm path. Buyers approve the BSC forwarder 0x2c2d8EF0664432BA243deF0b8f60aF7aB43a60B4 once, sign against the forwarder domain, and keep authorization.to and payTo pointed at the facilitator. Your backend still calls Meridian POST /v1/settle.
NetworkFacilitator Contract
arc-testnet0x8e633dBf31adCc7D41BE3e95B7c8DD3526B5235A
base0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
bsc0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
base-sepolia0x8e633dBf31adCc7D41BE3e95B7c8DD3526B5235A
avalanche0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
optimism0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
optimism-sepolia0x8e633dBf31adCc7D41BE3e95B7c8DD3526B5235A
polygon0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
unichain0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
ink0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
worldchain0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
sei0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
hyperevm0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
megaeth0x8E7769D440b3460b92159Dd9C6D17302b036e2d6

​
Response

​
Success Response

{
  "success": true,
  "transaction": "0x1234567890abcdef...",
  "network": "base-sepolia"
}

​
Error Response

{
  "success": false,
  "errorReason": "insufficient_funds",
  "transaction": "",
  "network": "base-sepolia"
}

​
Error Codes

  • invalid_payload - Payment payload format is invalid
  • invalid_payment_requirements - Payment requirements format is invalid
  • insufficient_funds - Insufficient balance for settlement
  • unexpected_settle_error - Unhandled exception during settlement
  • invalid_transaction_state - On-chain transaction failed

Authorizations

​
Authorization
string
header
required

Body

application/json
​
paymentPayload
object
required
​
paymentRequirements
object
required

Response

Payment settlement result