Skip to main content
This page covers concepts and end-to-end guides for @xentfi/x402-facilitator-sdk. For the client method/type reference, see x402 Reference in the Agent tab.

Overview

x402 is an open convention for monetizing HTTP resources using the (long-reserved, rarely-used) 402 Payment Required status code. A resource server responds 402 with a machine-readable list of accepted payment requirements; the client — often an AI agent — signs a payment authorization and retries the request with an X-PAYMENT header attached. It’s built for agent-to-agent and agent-to-API payments where there’s no human clicking “buy.” XentFi’s facilitator implements the eip3009 scheme: payments are EIP-3009 TransferWithAuthorization signatures — gasless, off-chain-signed authorizations that a relayer (your XentFi WAAS wallet) submits on-chain during settlement.

💰 Resource server

You’re getting paid. Use X402FacilitatorClient to verify() an incoming payment and settle() it on-chain — your WAAS wallet relays the transaction and receives the funds.

🤖 Payer

You’re paying. Use signEip3009Authorization() to build a real, offline EIP-712 signature from any viem LocalAccount, then attach it as the X-PAYMENT header.
The apiKey/orgId used here is your organization’s WAAS credential, not an agent API key — see Authentication. A pure payer needs no XentFi credential at all, only a viem-compatible signing account.

Getting paid (resource server)

Define what you accept

Use facilitator.getSupported() to find valid blockchainId/assetId values — it requires no authentication.

Challenge, verify, settle

1

No X-PAYMENT header

Respond 402 with { x402Version: 1, accepts: [requirement] } — the machine-readable challenge the payer’s agent parses.
2

X-PAYMENT header present

Base64-decode it into a PaymentPayload and call facilitator.verify(payload, requirement) — checks the EIP-712 signature, amount, recipient, and validity window. No funds move yet.
3

Verified — settle it

Call facilitator.settle(payload, requirement). Your WAAS wallet relays the TransferWithAuthorization on-chain and pays the gas; funds land at payTo.
4

Serve the content

Once settle() resolves, return the actual paid resource along with the txHash.
Both verify() and settle() throw on failure — catch the error and fold its message into your own 402 response’s error field, as shown above. See Error Handling for exact error classes and status mapping.

Paying as an agent

This is the “you’re making a payment” side — typically an agent that needs to pay for an API call and keep going without a human in the loop.
1

Probe the endpoint

A 402 response means payment is required; the body is an X402Challenge listing accepted PaymentRequirements.
2

Pick a requirement your agent can pay

Filter challenge.accepts for a scheme/network/assetId you support — currently eip3009.
3

Sign, don't call the facilitator directly

signEip3009Authorization() is pure local cryptography — it never touches the network. Your agent’s private key never leaves the client.
4

Attach and retry

Base64-encode the signed payload and send it as X-PAYMENT. The resource server calls verify()/settle() on your behalf — your agent doesn’t need a XentFi credential at all to pay.

EIP-3009 signing reference

Getting the token domain right

Eip3009TokenDomain must match the deployed contract exactly, or both the facilitator and the token contract will reject the signature: Pull these from the merchant’s PaymentRequirement/getSupported() response rather than hardcoding — different tokens on different chains use different version strings, and getting it wrong produces a signature the contract silently rejects.
A deterministic nonce (derived from your own request/order ID) lets you safely retry signing the same logical payment without risking a double-spend — the contract rejects a reused nonce for the same signer.

Security notes

  • validBefore is set from validitySeconds — keep this short. A long-lived signed authorization is a bearer instrument until it expires or is consumed.
  • validAfter is always 0 (immediately valid) in the current implementation.
  • The signature never leaves the caller’s process during signing — only the final Eip3009SchemePayload (which includes the signature, not the private key) is transmitted anywhere.
buildEip3009Domain(token: Eip3009TokenDomain) builds the matching EIP-712 domain object if you need to construct or verify a signature manually.

x402 Reference

X402FacilitatorClient methods and full type surface.

Error Handling

Error classes, retries, and HTTP status mapping.

Agent Tools guide

The other way an agent can transact — manage its own wallet.