Agentic Payments (x402)

The most interesting payments customer of 2026 is an AI agent. Furlpay speaks x402 — the HTTP 402 "Payment Required" protocol — so any agent or client can pay per request in USDC with no account, no API key, and no card on file.

The flow

1. Request the resource

An unpaid request returns 402 with a machine-readable payment quote:

curl -i "https://furlpay.com/api/x402/fx?from=USD&to=EUR&amount=100"

HTTP/1.1 402 Payment Required
{
  "x402Version": 1,
  "accepts": [{
    "scheme": "exact",
    "network": "base",
    "maxAmountRequired": "10000",        // 0.01 USDC (6 decimals)
    "asset": "0x833589fCD6…2913",        // USDC on Base
    "payTo": "0x2096…287C",
    "resource": "https://furlpay.com/api/x402/fx",
    "extra": { "quoteId": "…", "expiresAt": 1782943200, "binding": "…" }
  }]
}

2. Pay and retry

The client signs an EIP-3009 transferWithAuthorization for the quoted amount and retries with the base64 payload in the X-PAYMENT header. On success the resource is returned with an X-PAYMENT-RESPONSE settlement receipt.

curl "https://furlpay.com/api/x402/fx?from=USD&to=EUR&amount=100" \
  -H "X-PAYMENT: $(base64_signed_payload)"

HTTP/1.1 200 OK
X-PAYMENT-RESPONSE: eyJzdWNjZXNzIjp0cnVl…
{ "paid": true, "payer": "0x1111…", "quote": { "rate": 0.917, "amountTo": 91.7 } }

Hardened verification

With agents, the payment is the authentication — so payment verification is the entire security boundary. Furlpay defends the four attack classes from 2026 x402 research (arXiv 2605.11781 / 2605.30998):

• Authorization — amount, recipient, and network are re-checked server-side; the client's echoed requirements are never trusted.
• Binding — each quote carries an HMAC over (resource, method, amount, expiry); a payment for one endpoint fails closed on every other.
• Replay — quote IDs and nonces are single-use with a 300-second expiry.
• Web-layer — the header is size-capped and strictly parsed; malformed input returns 400, never a free resource.