Skip to main content
POST
/
v1
/
verify
Verify x402 payment (deprecated)
curl --request POST \
  --url https://api.mrdn.finance/v1/verify \
  --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>"
  }
}
'
{
  "isValid": true,
  "invalidReason": "<string>",
  "payer": "<string>",
  "authContext": {
    "organizationId": "<string>",
    "authMethod": "<string>",
    "timestamp": "<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.

POST /v1/verify is deprecated and retained for legacy integrations only.
Verify an x402 payment with organization-specific authentication. This legacy endpoint validates payment signatures and authorization data according to the x402 protocol specification.
When paymentRequirements.extra.name === "GatewayWalletBatched", verification is forwarded to Circle’s Gateway API. See Circle Gateway (Batched) for that flow and Payment Types for an overview.

​
Features

  • Organization-specific x402 authentication
  • Automatic fallback to default authentication
  • Authentication context in responses
  • Comprehensive error handling

​
Request Example

{
  "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. The USDm forwarder remains deprecated legacy compatibility only.
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.
NetworkFacilitator Contract
arc-testnet0x8e633dBf31adCc7D41BE3e95B7c8DD3526B5235A
base0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
bsc0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
base-sepolia0x8e633dBf31adCc7D41BE3e95B7c8DD3526B5235A
avalanche0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
optimism0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
optimism-sepolia0x8e633dBf31adCc7D41BE3e95B7c8DD3526B5235A
polygon0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
unichain0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
ink0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
worldchain0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
sei0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
hyperevm0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
megaeth0x8E7769D440b3460b92159Dd9C6D17302b036e2d6

​
Response Example

{
  "isValid": true,
  "payer": "0x742d35Cc6634C0532925a3b8D0c4E5e6C2aE7A3e",
  "authContext": {
    "organizationId": "org_123",
    "authMethod": "organization_specific",
    "timestamp": "2024-01-01T00:00:00.000Z"
  }
}

Authorizations

​
Authorization
string
header
required

Body

application/json
​
paymentPayload
object
required
​
paymentRequirements
object
required

Response

Legacy payment verification result

​
isValid
boolean

Whether payment is valid

​
invalidReason
string

Reason if payment is invalid

​
payer
string

Payment sender address

​
authContext
object