Confidential by defaultEstablished 201072 Jurisdictions

What x402 Sellers, Buyers, and Production Systems Need

What You Need to Become an x402 Seller

Suppose you want to charge for an API.

You need:

19.1 Something worth buying

Example:

GET /api/company-risk?domain=example.com

Output:

{
  "risk": "low",
  "jurisdiction": "US",
  "signals": 14
}

19.2 A price

Example:

US$0.10 per query

19.3 A receiving address/account

The seller needs a valid destination compatible with the chosen settlement method.

19.4 A network

For example:

Base Sepolia — test
Base Mainnet — production candidate

19.5 An asset

For example:

USDC

19.6 An x402 middleware/server library

The application needs logic that:

if no valid payment:
    return payment requirements
else:
    deliver resource

19.7 Verification and settlement

Either:

  • use a facilitator; or

  • perform the supported verification/settlement operations yourself.

19.8 Internal accounting

Record:

request ID
customer/payer if known
payment identifier
quoted price
actual charge
network
asset
transaction identifier
facilitator
resource delivered
timestamp
settlement status

19.9 Operational rules

Define:

  • timeout;

  • retries;

  • duplicate handling;

  • settlement pending behavior;

  • refunds;

  • unsupported networks;

  • failed payment behavior.

19.10 Compliance policy

Determine what the business model requires.


What You Need to Become an x402 Buyer

A buyer needs:

20.1 A wallet/signer

The software needs a cryptographic signing capability.

For production, do not casually store raw private keys inside application code.

Use:

  • a secure secret store;

  • managed wallet infrastructure;

  • KMS/HSM-backed signing where appropriate;

  • restricted hot-wallet balances.

20.2 Funds

The wallet must have an acceptable asset.

20.3 Payment-capable client

The client needs to recognize a payment-required response, inspect it, and construct the appropriate payment payload.

20.4 Spending policy

This is mandatory for serious agent use.

An agent should not simply follow this logic:

If price exists:
    pay it.

It should behave more like:

Is seller allowed?
Is endpoint expected?
Is asset allowed?
Is network allowed?
Is amount <= per-call limit?
Is daily spend <= budget?
Is scheme allowed?
Does requested resource match what the agent intended to buy?
Has this exact request already been paid?
Is human approval required at this amount?

A strong policy model might be:

<= $0.05             auto-pay
$0.05–$1.00          auto-pay only for approved vendors
$1.00–$25.00         require business-rule approval
> $25.00              require human approval

The thresholds are illustrative.

The principle is not.


What You Need for Production

A laboratory demo and a production financial system are different things.

Production requires at least:

Payment

  • production facilitator or controlled settlement infrastructure;

  • supported mainnet;

  • supported asset;

  • treasury policy;

  • reconciliation.

Security

  • hardened key storage;

  • network allowlists;

  • asset allowlists;

  • spend limits;

  • rate limits;

  • replay prevention;

  • duplicate-settlement protection;

  • route protection tests;

  • audit logs.

Reliability

  • facilitator SLA;

  • fallback policy;

  • RPC resilience if self-hosting;

  • timeout handling;

  • settlement_pending reconciliation;

  • idempotent resource execution where feasible.

Commercial

  • pricing;

  • refunds;

  • credits;

  • support;

  • service-level promise;

  • buyer documentation.

Finance

  • revenue recognition;

  • stablecoin accounting;

  • wallet reconciliation;

  • asset conversion policy;

  • treasury limits;

  • fee attribution.

Compliance

  • sanctions approach;

  • jurisdiction restrictions;

  • buyer/seller controls where required;

  • transaction-monitoring policy where applicable;

  • regulatory-perimeter analysis.

Engineering

  • pinned SDK version;

  • automated tests;

  • monitoring;

  • logs;

  • incident response;

  • version-upgrade process.


If You Are Building This Commercially

A production x402 business may still need named accounts or multi-currency accounts for operating treasury. If it administers customer money rather than merely receiving payment for its own service, an FBO account may also become relevant.

Key Takeaway

The protocol is only one layer. Production readiness means payment, keys, reconciliation, treasury, monitoring, customer operations, and compliance are all designed together.

This page is part of x402 Protocol Explained, the full guide to how machine-to-machine payments work.

Sources and Further Reading

Share
Page Last Updated: 21/Sep/2026 (3232554)