`POST /settle`

Signs, submits, and confirms the payment transaction on-chain. This is the production endpoint — call it when the payment is ready to execute.

curl -X POST https://x402.dexter.cash/settle \
  -H "Content-Type: application/json" \
  -d '{
    "paymentPayload": { ... },
    "paymentRequirements": { ... }
  }'

Request

Same shape as POST /verify:

{
  "paymentPayload": {
    "x402Version": 2,
    "resource": {
      "url": "https://api.example.com/paid-route",
      "description": "Premium resource",
      "mimeType": "application/json"
    },
    "accepted": {
      "scheme": "exact",
      "network": "eip155:8453",
      "asset": "USDC_ADDRESS",
      "amount": "10000",
      "payTo": "SELLER_WALLET",
      "maxTimeoutSeconds": 60
    },
    "payload": {
      "transaction": "SIGNED_OR_PREPARED_PAYMENT_PAYLOAD"
    }
  },
  "paymentRequirements": {
    "scheme": "exact",
    "network": "eip155:8453",
    "asset": "USDC_ADDRESS",
    "amount": "10000",
    "payTo": "SELLER_WALLET",
    "maxTimeoutSeconds": 60
  }
}

Success Response

{
  "success": true,
  "network": "eip155:8453",
  "transaction": "0xabc123...",
  "payer": "BUYER_WALLET_ADDRESS"
}

The transaction field is the on-chain transaction hash — use it as the settlement proof.

Failure Response

{
  "success": false,
  "network": "eip155:8453",
  "transaction": "",
  "errorReason": "Asset not allowed",
  "errorCode": "policy:asset_not_allowed",
  "payer": "BUYER_WALLET_ADDRESS"
}

See Facilitator Error Codes for all possible errorCode values.

Integration Pattern

Build payment requirements server-side
Client constructs and signs the payment
Use POST /verify during development to debug
Call POST /settle in production for real execution

POST /settle

Request

Success Response

Failure Response

Integration Pattern

On this page

`POST /settle`