x402 Protocol

​

Why x402

​

The standard x402 flow

1. Request — the client requests a paid resource normally.
2. 402 challenge — the server responds 402 Payment Required with the accepted payment requirements (scheme, network, asset, amount, payee) in the response body and headers.
3. Signed retry — the client constructs a payment payload for one of the offered requirements, signs it (an EIP-712 typed-data signature over an ERC-3009 transfer authorization for USDC), and retries the same request with the payload base64-encoded in an X-PAYMENT header.
4. 200 + settlement — the server (or a facilitator acting for it) verifies the signature, settles the transfer on-chain, and returns the resource with an X-PAYMENT-RESPONSE header containing the settlement result.

​

SohoPay’s implementation

• MPC co-signing. The agent’s signature alone can’t move funds. Every settlement requires a second signature from the Policy Service under SohoPay’s 2-of-3 MPC scheme. A stolen agent key cannot pay anyone on its own.
• Allowlist enforcement. The Policy Service refuses to co-sign payments to merchants outside the agent’s on-chain allowlist, plus off-chain credit, rate-limit, and AML checks.

​

Example HTTP exchange

GET /api/reports/q3 HTTP/1.1
Host: merchant.example.com
Accept: application/json

HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "x402Version": 1,
  "accepts": [
    {
      "scheme": "exact",
      "network": "base",
      "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
      "maxAmountRequired": "1000000",
      "payTo": "0x3f2a90b41c8d4e5f6a7b8c9d0e1f2a3b4c5d6e7f",
      "resource": "https://merchant.example.com/api/reports/q3",
      "description": "Q3 market report",
      "maxTimeoutSeconds": 600,
      "extra": { "provider": "sohopay", "order_id": "ord_9f8e7d6c" }
    }
  ]
}

GET /api/reports/q3 HTTP/1.1
Host: merchant.example.com
Accept: application/json
X-PAYMENT: eyJ4NDAyVmVyc2lvbiI6MSwic2NoZW1lIjoiZXhhY3QiLCJuZXR3b3JrIjoi...

HTTP/1.1 200 OK
Content-Type: application/json
X-PAYMENT-RESPONSE: eyJzdWNjZXNzIjp0cnVlLCJ0eEhhc2giOiIweDRkNWUuLi45YTBiIiwibmV0d29yayI6ImJhc2UifQ==

{ "report": "..." }

​

Use cases

• Agent-to-merchant purchases — an agent buys a dataset, report, or physical-goods order from a merchant API in one request cycle.
• Agent-to-service metering — pay-per-call APIs (inference, search, scraping) charge per request without API-key billing plumbing.
• Machine-to-machine commerce — services that are themselves agents can charge each other with no human in the loop.

​

Next steps