# X Pay ## The Payment Layer for AI and APIs **Version 0.2, draft for review. August 2026.** --- ## Abstract The internet has a payment gap. HTTP has carried a status code reserved for payment since 1997, but no usable standard ever filled it, so the web grew a monetization stack built entirely around human buyers: accounts, cards, subscriptions and API keys. That stack fails at the exact moment software becomes the buyer. An autonomous agent cannot complete a signup form, accept terms of service or type a card number, and no card network will profitably clear a payment of two hundredths of a cent. X Pay is programmable payment infrastructure built on the x402 standard. It lets any HTTP endpoint quote a price, receive a cryptographically signed payment authorization, and serve its response inside a single round trip. Authorization happens offchain in milliseconds. Settlement happens onchain in stablecoins. The merchant never touches card rails, never carries chargeback risk and never builds a billing system. This paper describes the problem, the protocol in detail, the X Pay architecture, the verification algorithm, the security and threat model, the product surface, the token design, and the open problems that remain unsolved. :::info Reading this document Sections 1 to 4 are the case and the background. Section 5 is the protocol in detail and is the part an engineer should read first. Sections 10 and 16 are the parts an investor or a partner should read first, because they are where the unresolved risk lives. ::: --- ## 1. Introduction Two shifts are converging. The first is economic. Software is moving from things people operate to things people delegate to. An agent that plans a trip, reconciles a ledger or researches a market does not make one large purchase. It makes thousands of small ones: a geocoding lookup, a currency conversion, a document parse, a model call. Each is worth a fraction of a cent. Aggregated across a fleet of agents running continuously, they are worth a great deal. The second is technical. Stablecoin settlement on low fee networks has made a payment of $0.0002 economically real for the first time. The cost of moving value has fallen below the value being moved. What has been missing is the connective tissue: a way for a machine to discover a price, agree to it and pay it without a human in the loop, using infrastructure the machine already speaks. That infrastructure is HTTP. X Pay exists to make that round trip work in production. @diagram[handshake] --- ## 2. The problem ### 2.1 The monetization stack is built for humans To sell an API today, a developer assembles a stack that has almost nothing to do with the API itself: - user registration, email verification and account recovery - card processing, with its PCI scope, chargebacks and fraud review - subscription tiers that either under serve or over serve nearly every customer - API key issuance, rotation and revocation - usage metering, quota enforcement and invoice generation - dunning, refunds and reconciliation This is months of work that produces no product value. It is also a permanent tax: every one of those systems has to be maintained, secured and supported forever. ### 2.2 It excludes the fastest growing class of buyer Every element above assumes a human. An agent cannot register an account, cannot legally accept terms on its own behalf, and must not be handed a raw card credential. The workarounds in use today are all unsatisfying: - **A human pre provisions an API key.** This binds spend to a static secret with no per call ceiling. A leaked or misused key is an unbounded liability. - **A human prepays a balance.** This works, but only inside one vendor. It does not compose across the open web, and it cannot pay a service the agent discovers at runtime. - **The agent shares a card.** This is the outcome nobody wants, and it is what happens when no better primitive exists. ### 2.3 Small payments are structurally impossible on card rails A card transaction carries a fixed cost of roughly twenty to thirty cents plus a percentage. Selling a $0.002 API call over card rails loses money by two orders of magnitude. The only way to sell cheap things on expensive rails is to bundle them into a subscription, which is precisely the model that fails variable, bursty, machine driven demand. @diagram[cost] The result is a web where an enormous amount of value cannot be priced at all. --- ## 3. Background: HTTP 402 and the x402 standard RFC 7231 reserves status code **402 Payment Required** with the note that it is reserved for future use. It sat unused for a quarter of a century because there was no settlement layer fast or cheap enough to sit behind it. The x402 standard fills that gap. In outline: 1. A client requests a protected resource with no payment attached. 2. The server responds `402 Payment Required` together with a machine readable quote describing what payment would satisfy the request: scheme, amount, asset, network and recipient. 3. The client constructs a payment authorization, signs it, and retries the request with the authorization attached in a header. 4. The server verifies the authorization, serves the response, and settles the payment. The design has three properties that matter: - **It is in band.** No redirect, no hosted checkout page, no callback. The payment lives in the same request and response cycle as the resource. - **It is machine readable.** The quote is structured data, not a pricing page. Software can parse it, compare it against a budget and act. - **It is credential free.** A valid payment authorization is itself proof of entitlement. There is no separate API key to issue or revoke. x402 defines the handshake. It does not, on its own, give a merchant a gateway, a dashboard, a wallet with spending controls, payouts or a place to be discovered. That is the gap X Pay fills. :::warn The standard is young x402 is still moving. Field names, scheme identifiers and header encodings should be treated as subject to change, and any implementation should pin a protocol version. Section 16 covers what happens if the ecosystem fragments. ::: --- ## 4. Design principles **Payment is a property of the request, not a separate flow.** Anything that redirects, opens a window or requires a callback cannot be used by software. The handshake must complete inside one exchange. **Never hold a response behind a block.** Latency is the product. A design that inherits chain latency has already failed the workload it exists to serve. **Bound the blast radius before signing.** For an autonomous spender, controls that run after a signature exists are decoration. Every limit is enforced while refusal is still free. **Settle in something stable.** Nobody prices an API in a volatile asset. The token is for alignment, not for denomination. **Be honest about what is not built.** A payment system earns trust by being precise about its failure modes, not by omitting them. --- ## 5. The protocol ### 5.1 Objects Three objects carry the whole protocol. **Quote.** Issued with a 402. It describes what payment would satisfy the request. ```json { "x402Version": 1, "scheme": "exact", "network": "base", "asset": "USDC", "assetAddress": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "amount": "2000", "decimals": 6, "payTo": "0xA1c4...9F2b", "resource": "/v1/summarize", "nonce": "0x7f3a...c81d", "validBefore": 1786412400, "expiresIn": 120 } ``` `amount` is in atomic units, so `2000` at six decimals is $0.002. Amounts are never floats, and never travel as decimal strings, because a rounding disagreement between payer and payee is a dispute. **Authorization.** Produced by the payer, signed, and sent back in the `X-Payment` header. Under the `exact` scheme on EVM networks it is an EIP-3009 `transferWithAuthorization` payload signed as EIP-712 typed data: ```json { "x402Version": 1, "scheme": "exact", "network": "base", "payload": { "from": "0x9dE4...71aC", "to": "0xA1c4...9F2b", "value": "2000", "validAfter": "0", "validBefore": "1786412400", "nonce": "0x7f3a...c81d", "signature": "0x4c8b...1f00" } } ``` The header is the base64 encoding of that JSON, because header values must be ASCII safe. **Receipt.** Returned with the successful response in `X-Payment-Response`, and retained by both sides. ```json { "settled": true, "txHash": "0x7d1e...44b9", "network": "base", "amount": "2000", "asset": "USDC", "payer": "0x9dE4...71aC", "settledAt": "2026-08-03T14:21:07Z" } ``` Receipts are the basis of reconciliation, refunds and dispute handling. They are the only artefact that survives the request. ### 5.2 The wire exchange ```http GET /v1/summarize HTTP/1.1 Host: api.acme.dev HTTP/1.1 402 Payment Required X-Payment-Required: eyJ4NDAyVmVyc2lvbiI6MSwic2NoZW1lIjoiZXhhY3QiLCJu... Content-Type: application/json GET /v1/summarize HTTP/1.1 Host: api.acme.dev X-Payment: eyJ4NDAyVmVyc2lvbiI6MSwicGF5bG9hZCI6eyJmcm9tIjoiMHg5ZEU0... HTTP/1.1 200 OK X-Payment-Response: eyJzZXR0bGVkIjp0cnVlLCJ0eEhhc2giOiIweDdkMWUuLi4i... Content-Type: application/json {"summary": "..."} ``` ### 5.3 Why EIP-3009 `transferWithAuthorization` lets a holder sign a transfer that **someone else submits and pays gas for**. That single property is what makes x402 usable: - the payer needs no native gas token, only the stablecoin - the payer never sends a transaction, so there is no wallet popup and no pending state to poll - the signature is scoped to an exact amount, recipient, validity window and nonce - the facilitator, not the payer, absorbs gas and can batch A payer with $5 of USDC and zero ETH can transact. For an agent, which cannot be expected to manage a gas balance across chains, this is not a convenience. It is the difference between working and not working. ### 5.4 The verification algorithm Verification is the security boundary of the entire system. It runs on every paid request, and it must complete in single digit milliseconds. ``` verify(quote, authorization): 1. version and scheme must match the quote 2. payload.to == quote.payTo else REJECT wrong_recipient 3. payload.value == quote.amount else REJECT wrong_amount 4. payload.nonce == quote.nonce else REJECT nonce_mismatch 5. now < payload.validBefore else REJECT expired 6. now >= payload.validAfter else REJECT not_yet_valid 7. signer = recoverTypedDataAddress( domain: { name, version, chainId, verifyingContract: assetAddress }, types: TransferWithAuthorization, message: payload, signature: payload.signature ) signer == payload.from else REJECT bad_signature 8. atomically claim payload.nonce in the store already claimed else REJECT replay 9. balanceOf(payload.from) >= value else REJECT insufficient_funds (advisory, may be cached) ACCEPT ``` Steps 1 to 7 are pure computation and need no network. Step 8 is the only strongly consistent write on the hot path, which is why the nonce store is the component with the tightest latency and consistency budget in the system. :::danger Step 8 is the one that matters Every other check fails safe. If the nonce claim is not atomic, the same authorization can be spent twice concurrently, and the merchant serves two responses for one payment. A read then write is not sufficient. It must be a single atomic operation against a store with strong consistency. ::: ### 5.5 Error taxonomy A gateway returns `402` for anything the client can fix by paying correctly, and `4xx` or `5xx` for everything else. Machine readable codes matter more than messages, because the consumer is software. | Code | Status | Meaning | Client should | | --- | --- | --- | --- | | `payment_required` | 402 | No authorization attached | Sign the quote and retry | | `expired` | 402 | Quote or authorization past `validBefore` | Request a fresh quote | | `wrong_amount` | 402 | Value does not equal the quote | Re-sign against the quote | | `wrong_recipient` | 402 | `to` is not `payTo` | Re-sign against the quote | | `bad_signature` | 402 | Recovered signer is not `from` | Check signing domain and chain id | | `replay` | 409 | Nonce already claimed | Request a fresh quote | | `insufficient_funds` | 402 | Payer balance below value | Fund the wallet | | `unsupported_network` | 400 | Network not enabled for this route | Read `/v1/networks` | | `rate_limited` | 429 | Too many requests | Back off and retry | --- ## 6. Architecture ### 6.1 Components @diagram[architecture] **Gateway.** Middleware, plus a hosted edge service, that sits in front of a merchant endpoint. It resolves the price for the route, issues the 402 quote, verifies inbound authorizations, enforces replay protection and releases the response. **Facilitator.** The settlement service. It takes verified authorizations, submits them onchain, batches where batching is safe, tracks confirmation and produces receipts. Separating the facilitator from the gateway is what allows a response to be served before a block is confirmed. **Nonce and quote store.** The strongly consistent component. It holds unexpired quotes and claimed nonces, and it is the only thing in the path that cannot be eventually consistent. **Wallet.** The buyer side. It holds funds, evaluates quotes against policy, signs authorizations and records spend. The AI Wallet variant adds the constraints an autonomous spender needs. **Dashboard, Marketplace, SDK.** Merchant control plane, discovery surface, and the client and server libraries that mean neither side implements the handshake by hand. ### 6.2 Payment lifecycle @diagram[lifecycle] Everything from `quoted` to `served` is synchronous and inside the request. `settled` is not, and the merchant has already delivered value by the time it is reached. Section 7 explains why that is an acceptable trade and what bounds the exposure. --- ## 7. Verification and settlement ### 7.1 The latency argument @diagram[latency] If the gateway waited for onchain confirmation before responding, every API call would inherit the latency of the underlying chain. A one second block time turns a 40 millisecond API into a one second API. For the agent workloads x402 exists to serve, where a single task may make hundreds of sequential calls, that is the difference between a viable product and an unusable one. ### 7.2 What the split actually risks Serving before settling is a credit decision, and it should be described as one. | Risk | Why it exists | Mitigation | Residual | | --- | --- | --- | --- | | Balance moves between verify and settle | Authorization is not a lock on funds | Balance check at verify, short `validBefore`, prefunding on high value routes | Small, non zero | | Chain reorganization | Settlement can be undone | Confirmation depth policy per network before payout release | Bounded by depth choice | | Submission failure | RPC or gas market failure | Durable queue, retry with backoff, dead letter and alerting | Operational, not financial | | Payer griefing | Repeated deliberate failures | Reputation, rate limiting, forced prefunding after repeat failures | Bounded per payer | The merchant carries **no chargeback risk**, because a cryptographic authorization has no consumer initiated reversal path. This is a structural improvement over card rails, not merely a cost saving. The risk that remains is credit risk on a two hundredth of a cent, which is a different category of problem from fraud on a fifty dollar card payment. :::note Where the risk sits X Pay absorbs settlement risk on behalf of merchants rather than passing it through. That is a deliberate product decision and a real cost line, and it is why prefunding exists as an option for high value routes. ::: --- ## 8. Products ### 8.1 X Pay Gateway Pricing rules per route, including fixed price per call, price per unit of work, and dynamic pricing resolved by the merchant at request time. Handles verification, replay protection, idempotency, receipt generation and webhooks. ### 8.2 Merchant Dashboard Publish and price endpoints, watch revenue and call volume in real time, inspect individual payments, manage payouts, and see who the heaviest consumers are. The operational quality bar here is set by the best payment tooling in the industry, and matching it is a product requirement rather than a nice to have. ### 8.3 AI Wallet A wallet designed on the assumption that the spender is software and will occasionally behave in ways nobody predicted. Detailed in section 10. ### 8.4 SDK Server side: one middleware call wraps a route. Client side: a drop in replacement for `fetch` that catches a 402, evaluates it against policy, pays and retries transparently. ```js import { paywall } from "@xpay/sdk"; app.use("/v1/summarize", paywall({ price: "$0.002", network: "base", payTo: process.env.XPAY_PAY_TO, })); ``` ```js import { XPayWallet } from "@xpay/sdk"; const wallet = new XPayWallet({ sessionKey: process.env.XPAY_SESSION_KEY, limits: { perCall: "$0.05", daily: "$25" }, }); const res = await wallet.fetch("https://api.acme.dev/v1/summarize", { method: "POST", body: JSON.stringify({ text }), }); ``` ### 8.5 API Marketplace A catalogue where each listing carries structured pricing an agent can parse. Because payment requires no onboarding, discovery and first purchase collapse into a single step: an agent can find an endpoint and pay it in the same second. ### 8.6 Billing models Pay per use is the default, but the gateway supports per request, per second, per token, per unit of compute, prepaid credits, volume tiers and conventional monthly plans. These are configuration, not separate integrations, and can be mixed per route. --- ## 9. Security model **Replay protection.** Every authorization carries a nonce claimed atomically at verification time. See section 5.4, step 8. This is the single most important invariant in the system. **Quote expiry.** Quotes are short lived, which bounds the window in which a payer balance can change between quote and settlement. **Scope binding.** An authorization is bound to amount, asset, network, recipient and nonce. It cannot be replayed against a different route, a different merchant or a larger amount. **Domain separation.** EIP-712 typed data includes the chain id and the token contract address in the signing domain. A signature produced for one chain or one asset cannot be replayed on another. **Key handling.** Session keys are scoped and expiring by construction. They are the only credential an agent process should ever hold, and compromise is bounded by the limits attached to the key rather than by the balance of the underlying wallet. **Custody.** Merchant balances and payout paths are the highest value target in the system. The intended posture is that X Pay minimizes the period it holds merchant funds, and that the settlement path is independently reviewed before it carries meaningful volume. ### 9.1 Threat model | Threat | Vector | Control | | --- | --- | --- | | Double spend | Same authorization presented concurrently | Atomic nonce claim in a strongly consistent store | | Cross chain replay | Signature reused on another network | Chain id and token address in the EIP-712 domain | | Cross merchant replay | Signature reused against another payee | `to` bound in the signed payload and checked | | Amount tampering | Client re-signs for less | `value` compared against the quote before acceptance | | Quote forgery | Client invents a favourable quote | Quotes are server issued and stored, not trusted from the client | | Gateway compromise | Attacker fronts merchant traffic | Scoped payout addresses, payout allowlists, alerting on address change | | Facilitator key loss | Relayer key exposed | Relayer holds gas only, never merchant funds; authorizations are already scoped | | Agent runaway | Buggy or injected agent loops | Pre signature ceilings, session key expiry, revocation | :::danger Not yet reviewed No component described in this document has been through third party security review at the time of writing. No claim of audit, formal verification or production hardening is made anywhere in this paper. ::: --- ## 10. Agent safety An autonomous spender is a new category of risk. A bug, a prompt injection or an unbounded retry loop can turn a well behaved agent into one that drains a balance in seconds. The wallet is where this is contained. @diagram[limits] **Per call ceiling.** A hard maximum for any single payment. Quotes above it are refused without being signed. **Daily and rolling ceilings.** A budget across a time window, enforced locally before signing. **Session keys.** Scoped, expiring keys that an agent process holds instead of the wallet's main key. Revocation is immediate and does not require moving funds. **Destination policy.** An optional allowlist or denylist, so an agent can only pay endpoints its operator has sanctioned. **Auto pay thresholds.** Below a configured amount the wallet pays without asking. Above it, the payment requires explicit approval. This is the dial between autonomy and control. **Complete history.** Every quote seen, every authorization signed and every receipt received, queryable. An agent's spending must be auditable after the fact, not merely limited in advance. :::tip The ordering principle Limits are enforced **before a signature exists**. Once an authorization is signed and released it is a commitment that the payer cannot retract, so every control has to sit earlier in the pipeline. A wallet that checks its budget after signing has no budget. ::: --- ## 11. Token The network settles in stablecoins. The token does not sit between a buyer and a seller, and no user is required to hold it to transact. Its role is to align the parties who route, secure and grow the network. @diagram[fees] **Fee discounts.** Protocol fees settled in $XPAY are charged at a reduced rate, with the largest benefit accruing to the highest volume merchants. **Governance.** Fee parameters, supported networks, treasury allocation and protocol upgrades. **Staking.** Facilitator capacity is backed by stake. Stakers earn a share of the fees generated by the capacity they secure, and misbehaviour is penalised against that stake. **Ecosystem rewards.** Merchant incentives, integration grants and volume rebates, denominated in a way that pays for real usage rather than speculation. ### 11.1 Supply and distribution :::warn Deliberately unspecified Total supply, allocation across team, investors, treasury, ecosystem and community, vesting schedules and emission curve are all open decisions that require founder and legal sign off before publication. This section is left unspecified rather than filled with placeholder numbers that would be read as commitments. ::: What is decided is the shape: no allocation should unlock in a way that lets insiders exit ahead of the people building volume on the network, and emissions should be tied to measurable network usage. --- ## 12. Business model The core rate is a **1% fee on settled volume**. No monthly minimum, no setup fee, and nothing charged on calls that fail. Additional lines: - **Premium merchant plans.** Higher limits, priority settlement, advanced analytics and service levels. - **Marketplace commission.** A share of volume on endpoints discovered and sold through the catalogue. - **Enterprise integration.** Bespoke deployment, compliance support and dedicated infrastructure. - **White label gateway.** The full stack running under a partner brand. - **Cross chain routing.** A routing fee when a payment settles across networks or assets. The incentive alignment is deliberate: X Pay earns only when a merchant is paid. --- ## 13. Alternatives | Approach | Small payments | Machine buyer | No onboarding | Reversal risk | | --- | --- | --- | --- | --- | | Card subscription | No | No | No | Chargebacks | | Metered card billing | No | No | No | Chargebacks | | Prepaid vendor credits | Yes | Partly | No, per vendor | None | | Raw API keys | Yes | Yes | No | None, but unbounded spend | | Direct onchain transfer | Yes | Yes | Yes | None, but needs gas and confirmation wait | | **x402 with X Pay** | **Yes** | **Yes** | **Yes** | **None, credit risk only** | The closest alternative is a direct onchain transfer, and the differences are decisive: the payer needs no gas token, the response is not held for a confirmation, and the price is discoverable in band rather than agreed out of band. --- ## 14. Roadmap **Q3 2026.** Gateway in public beta. Node and Python SDKs. Merchant dashboard v1. Stablecoin settlement on a first EVM network. **Q4 2026.** AI Wallet with session keys and spending limits. Marketplace launch. Usage based and prepaid billing. Webhooks, receipts and exports. **Q1 2027.** Multichain settlement and routing. $XPAY utility and staking. Governance framework. Enterprise and white label tiers. **Q2 2027 and beyond.** Paywalls for sites, games and media. IoT, robotics and DePIN metering. Agent to agent settlement. Fiat on and off ramps. Dates are plans, not commitments. --- ## 15. Risks and open problems Stated plainly, because a whitepaper that lists only strengths is marketing. **Standard risk.** x402 is young. If the ecosystem converges on a different shape, or fragments across incompatible variants, integration cost rises for everyone. X Pay's answer is to implement the standard faithfully, pin a protocol version, and keep the gateway able to speak more than one dialect. **Regulatory risk.** Payment facilitation, custody of merchant funds and token distribution are all regulated activities, and the treatment varies by jurisdiction. This is a gating dependency on launch sequencing, not a detail to resolve later. **Settlement risk.** Verifying before settling is what makes the product fast, and it is also where the residual credit risk lives. Section 7.2 lists the mitigations. None of them reduce the risk to zero. **Security risk.** The gateway and the settlement path have not been independently reviewed. No production claims should be made until they have been. **Consistency risk.** The nonce store is a single strongly consistent dependency on the hot path. It is also the obvious scaling bottleneck and the obvious availability risk, and there is no version of this system that removes it. **Chain dependency.** Latency, cost and reliability are inherited from the settlement network. Multichain support is a mitigation and also an increase in surface area. **Adoption risk.** A marketplace is a two sided market. Merchants list where buyers are, and buyers arrive where listings are. The plausible wedge is agent frameworks, where the pain of the current model is sharpest. **Agent risk.** Spending controls reduce the blast radius of a misbehaving agent. They do not eliminate it, and the failure modes of autonomous spenders are not yet well understood by anyone. --- ## 16. Glossary **Atomic units.** An integer amount in the token's smallest denomination. `2000` at six decimals is $0.002. **Authorization.** A signed message committing a payer to a specific transfer. Not a transaction. **EIP-712.** The Ethereum standard for signing structured data, so a signature is human inspectable and domain separated. **EIP-3009.** The token standard that allows a signed transfer to be submitted and paid for by a third party. **Facilitator.** The service that submits verified authorizations onchain and reports settlement. **Nonce.** A single use value binding an authorization to one specific payment. **Quote.** The server issued description of what payment satisfies a request. **Receipt.** The record of settlement returned with a paid response. **Scheme.** The payment method identifier inside x402. `exact` means the payer authorizes precisely the quoted amount. **Session key.** A scoped, expiring key an agent uses instead of the wallet's main key. --- ## 17. Conclusion The web never got a native payment primitive, so it built a human shaped substitute and lived with the consequences: no small payments, no machine buyers, and a monetization stack every developer rebuilds. x402 supplies the missing handshake. X Pay supplies everything around it that turns a handshake into a business: the gateway that enforces it, the wallet that makes autonomous spending safe, the dashboard that makes revenue legible, and the marketplace that makes an endpoint discoverable. If software is going to buy things, it needs a way to pay for them. That is the whole thesis. --- ## Legal notice This document is a draft published for discussion. It is not an offer to sell, or a solicitation of an offer to buy, any token, security or financial instrument, and it is not investment, financial, legal or tax advice. Statements about future products, timelines, token mechanics and network behaviour are forward looking and subject to change without notice. Nothing here is a commitment to deliver any feature on any date. No representation is made that the systems described have been audited, formally verified or hardened for production use. Digital assets carry risk, including total loss of value. Contract addresses, amounts and identifiers shown in examples are illustrative and truncated. Do not copy them into production code. © 2026 X Pay. All rights reserved.