An AI agent can search, compare information and call software tools. But when it reaches a paid resource, it often encounters a checkout designed for a person: create an account, choose a subscription and enter payment details.
x402 addresses that mismatch. It gives a server a way to tell software what a resource costs and how payment can be authorized within a normal web interaction. XPay is building around that idea, combining payment infrastructure with tools aimed at businesses and developers.
Related reporting: X Pay Reports 50,000 x402 Payments, Expands BNB Support
Understanding the relationship matters. x402 is the shared protocol; XPay is a project implementing services around it. Neither a successful payment nor a recognizable logo establishes that an AI agent can safely manage an unlimited budget.
Who invented x402?
Coinbase introduced x402 on May 6, 2025. Its launch announcement was authored by Erik Reppel, Nemil Dalal and Dan Kim. Cloudflare’s September 2025 foundation announcement identifies Reppel, then Coinbase Developer Platform’s head of engineering, as x402’s creator. XPay should therefore be described as an ecosystem implementer, not the inventor. Coinbase launch · Cloudflare announcement
The number comes from HTTP 402, the “Payment Required” status code. That code predates Coinbase’s project by decades. The HTTP standard still describes it as reserved for future use; x402 supplies a concrete protocol for communicating payment terms and responses rather than claiming to have invented the status code itself. HTTP semantics
Governance has also moved beyond the initial launch. In July 2026, the Linux Foundation announced the operational launch of the x402 Foundation and Coinbase’s completed contribution of the protocol. The aim is open, vendor-neutral development. Using x402 does not, by itself, establish a commercial partnership with any foundation member. Foundation announcement
How does an x402 payment work?
Consider an agent requesting one item of paid research. The normal sequence is straightforward:
- Request: The application asks the provider for the resource.
- Quote: The server responds with HTTP 402 and machine-readable terms, including the price, network, asset and recipient.
- Authorization: The client checks those terms against its permissions and creates the required payment payload.
- Retry: It submits the resource request again, this time carrying the payment authorization.
- Verification and settlement: The server, often using a facilitator, validates the payment and follows the selected scheme’s settlement process.
- Result: The client receives the resource and a payment outcome it can record.
In x402 V2, the relevant headers are PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE. These are not three different products: they carry the quote, client payload and settlement response. Exact-payment and batch-settlement schemes can have different settlement timing, so “every request instantly settles onchain” is not a universal rule. Protocol documentation
A facilitator is optional infrastructure that can handle verification and blockchain submission for the seller. It is not the resource itself. A payment authorization also must not be mistaken for a confirmed settlement. When a transaction is pending, reconciliation matters more than blindly creating a second payment. Facilitator documentation
For a beginner-friendly walkthrough, read The Token Press’s x402 payments explainer.
Where XPay fits
XPay describes its platform as a payment layer connecting businesses, APIs and AI agents. Its public website presents payment management, usage-based billing, developer projects, API keys and webhooks alongside x402 access. It also describes Stripe-powered card flows, with card clearing and subsequent onchain settlement treated as separate steps. These are the project’s published product descriptions, not evidence of independently audited merchant adoption. XPay platform
Its facilitator documentation is more specific. It describes USDC payments on Base using EIP-3009 authorizations and Binance-Peg USDC on BNB Smart Chain using Permit2. The assets differ in contracts, decimals and authorization mechanics; a shared USDC label does not make them interchangeable.
The documentation says public capability discovery is available without a key, while verification and settlement require a facilitator credential. BNB payers may need an initial token allowance transaction, which can require BNB for gas. It also warns that dashboard test mode does not turn its mainnet facilitator endpoints into testnets. XPay facilitator documentation
That distinction is central to evaluating XPay: the practical product is the integration and operating layer around payments, not ownership of x402 or an automatic right to claim every development in the wider protocol ecosystem.
Why this matters for AI agents and businesses
The useful change is purchase granularity. A business can price a particular API response rather than force every occasional customer into a monthly subscription. An agent can compare a quoted cost with the value of completing its assigned task before deciding to proceed.
Imagine, purely as an illustration, an agent allowed to spend $1 on a research job. At $0.002 per request, 100 paid requests would cost $0.20 before any additional charges. A clear budget could prevent a useful workflow from turning into an uncontrolled sequence of purchases. The example is arithmetic, not a claim about XPay’s current pricing or guaranteed operating costs.
Potential applications include paid datasets, individual model calls, specialized analysis and software tools sold by usage. Human-operated applications can use the same pattern; x402 is not restricted to autonomous agents. Its client/server model separates the buyer requesting a resource from the seller defining and enforcing its price. Client and server roles
What still needs to work reliably
Payment infrastructure cannot determine whether purchased information is accurate, whether a tool is useful or whether an agent should have bought it. Those remain application decisions.
Safe implementations need spending limits, approved destinations, protected signing credentials and a record connecting each payment with its request and outcome. Wallets authorize and receive payments, but possession of a wallet is not a substitute for a sensible purchasing policy. Wallet documentation
XPay’s whitepaper discusses replay protection, duplicate requests, insufficient funds and uncertain settlement. These are important operational questions: did the purchase execute, did the customer receive the result, and would retrying charge again? It also distinguishes its Base and BNB authorization paths rather than presenting one signing method as universal. XPay whitepaper
For readers assessing any provider, useful evidence would include repeat paying customers, successful settlement rates, transparent fees, documented failure handling and independently checkable production activity. A dashboard illustration or aggregate transaction count alone cannot answer those questions.
Is x402 the future of payments?
x402 offers a credible building block for a web where software buys services as well as retrieves information. An open standard can reduce the need for each service to invent a separate payment conversation. But a standard’s promise and a particular company’s commercial success are different propositions.
XPay also describes a robotics direction in which machines could earn from completed work and pay for compute, connectivity or charging. Its website presents that as a vision and expansion opportunity, not proof of a deployed autonomous-machine economy. XPay’s stated direction
The strongest case for XPay is therefore concrete: making supported payment flows easier to integrate and operate. The strongest case for x402 is broader: making prices and payment authorization understandable to software across services. If both deliver dependable, economical experiences, agent-driven commerce becomes more practical. Whether either achieves lasting adoption will be decided by real customers and reliable execution, not the label “the future.”
Explainer prepared with AI assistance and primary-source checks. Product descriptions are attributed to XPay; future use cases are possibilities, not guarantees.