x402 payments

x402 is an open standard that revives the dormant HTTP 402 Payment Required status code so a client can pay for a request inline, in stablecoins, with no account. It was open-sourced by Coinbase in 2025 and donated to the x402 Foundation (Linux Foundation) in April 2026. PDF As You Go uses it as the only payment and authentication mechanism — there is no API key.

Private preview

PDF As You Go is in private preview. Endpoints, retention windows, and supported networks may change. Access is granted on request — see Request preview access.

Why x402

A conventional API authenticates with a key and bills out of band. For an autonomous agent that means a human had to sign up and provision a credential first. x402 collapses authentication and payment into the request itself: the payment authorization is the auth. Nothing is issued, stored, or rotated.

The per-operation sequence

1. Request. The client calls a tool or hits an endpoint with its document and parameters.
2. 402 Payment Required. If unpaid, the server responds 402 with a payment-requirements body describing how to pay.
3. Sign. The client builds a signed payment payload — a gasless authorization — and retries the request with an X-PAYMENT header.
4. Verify & settle. A facilitator verifies the signature and settles the transfer onchain. The service holds no blockchain infrastructure of its own.
5. Deliver. On success the server runs the operation and returns the result plus an X-PAYMENT-RESPONSE header confirming settlement.

Settlement is typically sub-2-second, with onchain cost around $0.0001 — negligible against the $0.05 operation price.

The 402 payment-requirements body

When a request is unpaid, the server returns a JSON body with an accepts array. Each entry is one acceptable way to pay:

{
  "x402Version": 1,
  "error": "X-PAYMENT header is required",
  "accepts": [
    {
      "scheme": "exact",
      "network": "base",
      "maxAmountRequired": "50000",
      "resource": "https://api.pdfasyougo.com/v1/merge",
      "description": "Merge PDF documents",
      "mimeType": "application/json",
      "payTo": "0xA0b8…receiver",
      "maxTimeoutSeconds": 60,
      "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
      "extra": { "name": "USDC", "version": "2" }
    }
  ]
}

Field	Meaning
scheme	Payment scheme. PDF As You Go uses exact — a fixed price.
network	Settlement chain (CAIP-2 / x402 network id). base is the default.
asset	Token contract address. The example is USDC on Base.
payTo	The service’s receiving address.
maxAmountRequired	Price in the token’s base units. USDC has 6 decimals, so 50000 = $0.05.
resource	The URL being paid for.
description, mimeType	Human/machine context for the charge.
maxTimeoutSeconds	How long the quote is valid before you must re-request.
extra	Scheme-specific data — here, the USDC EIP-712 domain name/version.

Note

maxAmountRequired is always 50000 base units of USDC ($0.05) for every operation. The amount does not vary with file size or page count. See Wallets & networks for base-unit math on other tokens.

The payment headers

• X-PAYMENT (request) — a base64-encoded payment payload your client sends on the retry. For USDC it carries a gasless EIP-3009 transferWithAuthorization signature; other ERC-20s can use Permit2. The client signs locally — no gas, no prior onchain transaction.
• X-PAYMENT-RESPONSE (response) — a base64-encoded settlement receipt the server returns on success, including the onchain transaction reference.

The exact byte layout and a worked example are in The 402 flow.

The facilitator

A facilitator is the service that verifies a payment signature and settles it onchain. PDF As You Go delegates verify-and-settle to a facilitator, which is why it needs no chain infrastructure itself. From your side the facilitator is invisible — you sign, you send the header, and you get a settled receipt back.

Preview

The default network is Base with USDC during preview. Additional networks and tokens are feasible under the same schemes and are tracked on the Roadmap.

You almost never implement this yourself

In practice an x402-aware client does all of the above. For HTTP, libraries like x402-fetch wrap the loop; for MCP, an x402-capable client handles it inside the tool call. You provide a funded wallet; the library handles the 402, the signature, and the retry.

See also

• Wallets & networks — tokens, chains, and base units.
• The 402 flow — the full HTTP-level detail.
• Paying with x402 (MCP) — how clients settle a tool call.