A useful API may only be needed once. A research agent might need a single company lookup or one fresh price response, while a developer may want to try a service before committing to a subscription. Base x402 payments give sellers a way to attach a price to that individual HTTP request.
The interesting part is not simply moving a token. It is connecting the buyer’s payment to the exact result they asked for, with enough evidence to recover when something goes wrong.
What are Base x402 payments?
x402 is an open payment protocol built around HTTP 402 Payment Required. Base is one blockchain on which a compatible implementation can settle a payment. The protocol, the network and the facilitator are separate parts of the system.
Base Mainnet uses chain ID 8453 and ETH for network fees. A service accepting a stablecoin must specify the exact token contract, amount and recipient. A familiar token name on its own is not enough to identify what a buyer is being asked to authorize.
How a paid API request works
The buyer first requests a protected resource. The server responds with payment requirements, and a compatible client decides whether those terms are acceptable. It then supplies the required payment payload so the server can verify and settle the payment through its configured route.
The seller must also deliver the promised result. A successful transaction does not, by itself, show that an API returned useful data. Payment handling and delivery should be recorded together, using a request reference that support can trace later.
Implementations differ by protocol version and payment scheme. Use matching client and server libraries rather than copying headers from an unrelated example.
Choose the facilitator before launching
A facilitator can handle payment verification and settlement for a seller. For a production Base service, check the provider’s current supported networks, tokens and schemes, along with its fees and availability requirements. The public x402.org facilitator is intended for development and testnet use rather than being a universal production mainnet option.
A small pilot should test more than a successful purchase. Try an expired authorization, an insufficient balance and a lost HTTP response. Write down what the buyer should do in each case before the endpoint is opened to customers.
Who pays gas on Base?
The network fee is paid in ETH, but the person paying that fee depends on the integration. A facilitator may sponsor or submit settlement transactions. That does not make operating the service cost-free: provider charges, infrastructure and failed attempts still need a budget.
Avoid promising a fixed cost per request without measuring the actual settlement path. A stablecoin price and an onchain gas fee are different costs and should be presented separately.
Give AI agents a sensible spending policy
An agent buying a research result should have a maximum price per call, an overall budget and an allowlist of services. For example, a 0.01 USDC lookup can be useful, but repeated calls to an unavailable endpoint should not consume an unlimited balance. This price is an example, not a standard x402 tariff.
If a request times out, check its existing payment state before authorizing another purchase. Where the provider supports payment identifiers or recovery endpoints, use them to connect retries to the original request.
What should a Base payment dashboard show?
Keep quoted requests, settled transactions and delivered results separate. Show the reporting period, last successful index check and the scope of each metric. A transfer to a shared recipient wallet may belong to several products; it should not automatically be attributed to one API.
Explore payment-enabled projects in our directory: Explore AI agents and apps
For the other network guide, read: BNB Chain x402 Payments: API Payments, Fees and Receipts
Base USDC configuration: a concrete example
Base Mainnet is eip155:8453. Native USDC uses contract 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 and six decimals. A 0.01 USDC quote therefore means 10000 atomic units; a 0.03 USDC quote means 30000. These values should be converted with integer-safe decimal handling, not floating-point rounding.
For XPay's documented Base route, the API base is facilitator-xpay.llc. Its capability response identifies x402 v2 exact payments using USDC transferWithAuthorization. Its integration guide describes EIP-3009 typed authorization with the USD Coin domain, version 2. Keep the facilitator API key on the merchant server, and construct the price, token and receiving address from trusted server configuration.
What we verified in a real Base receipt
During our public registry review on 26 October 2026, we queried Base transaction 0x72d2dfe803256939db9ad2d5b89ced1a1afb79c527b4b02fb01b7fe3f304927d. The receipt reported successful execution and a native-USDC Transfer of 0.03 to the receiving wallet declared by AISkills402.
Receipt reference: basescan.org/tx/0x72d2dfe803256939db9ad2d5b89ced1a1afb79c527b4b02fb01b7fe3f304927d
That independently establishes the transfer, token, recipient and amount. It does not independently prove that a skill file was delivered, that the payer was an unrelated customer, or that every transfer to the wallet belongs to this product. AISkills402 shares this recipient with three other submitted services; attributing the full wallet total to each one would duplicate activity. The application remains subject to its separate delivery-evidence review.
This is why a payment explorer should connect a chain receipt to a specific paid request instead of treating any incoming token transfer as a confirmed sale.
Integration reference: facilitator-xpay.llc/docs
Frequently asked questions
Does every Base API support x402? No. The seller must implement a compatible payment flow and publish its terms.
Does a receipt prove delivery? It can help establish payment, but the application should also retain its delivery result.
Can an agent pay without a subscription? A seller can offer payment per request, while still setting its own access and usage policies.
Sources:
Base network documentation
x402 client and server documentation
x402 production facilitator directory
A production handoff checklist for Base
Record the chain identifier, exact token contract and integer amount used by your integration in one configuration record. Keep the provider’s current accepted scheme and authorization requirements alongside them. Validate that the seller receiving the payment is the seller selected by your application, rather than trusting a symbol or logo in an untrusted response.
After a controlled purchase, retain the operation identifier, settlement receipt and delivered output. Compare your application’s status with the receipt on Base. If they disagree, pause retries and investigate the original operation instead of issuing another authorization.
Monitor the right failure signals
Separate quote failures, authorization rejection, submission errors and delayed settlement in your monitoring. An API returning HTTP 200 for its homepage does not prove a paid route can settle. Use a bounded integration check and alert on sustained failures without presenting check traffic as independent customer adoption.