X Pay

The Payment Layer for the Autonomous Economy

Version 0.3 · October 2026.

Abstract#

Software increasingly acts on behalf of people and businesses. AI agents buy data, call models and allocate compute. Robots and connected devices add physical services to that exchange: completing deliveries, charging batteries and accessing infrastructure. Each needs a way to pay within an operator's authority and budget.

X-Pay brings payment operations and programmable payments into one platform. Its public API catalogue documents pay-per-request utility and AI endpoints using USDC on Base. The merchant application provides the operational workspace for integrations. x402 connects a resource request to machine-readable payment requirements and an authorized payment.

This paper describes the protocol, payment architecture, spending controls and the path from software agents to autonomous machines. Verification, settlement and operator authority are distinct responsibilities throughout the design.

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. Stablecoins and programmable payment authorizations make small machine payments practical in more settings. Whether an individual request is economical depends on the network, facilitator, asset and payment size.

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 connects this payment flow to the tools businesses need to integrate and operate it. Robotics is a near-term extension of the same infrastructure: a machine can pay for a digital resource before it can pay a physical charging station. The latter also requires the station operator to expose a compatible payment interface.

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

Each layer adds integration, maintenance and security work before a developer can operate a paid resource.

2.2 It excludes the fastest growing class of buyer#

Many conventional flows expect human interaction. An agent acts under an operator's authority, with credentials and purchase permissions that must be deliberately provisioned. Common approaches have tradeoffs:

• A human pre provisions an API key. This binds spend to a static secret with no per call ceiling. Without appropriate limits, a leaked or misused key can expose the account to uncontrolled spending.
• 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 uses delegated card access. This can work with appropriate controls, but a general-purpose credential must not imply unrestricted spending authority.

2.3 Small payments need a different cost structure#

Per-transaction processing costs can exceed the value of a small API call. Metered billing and prepaid balances address that problem by aggregating usage, but they usually require a relationship with each provider before an agent can make a purchase.

x402 offers another model: a service publishes payment requirements with the request, and a compatible client can pay under a preconfigured policy. The economics still depend on the payment rail and facilitator. Network fees, platform fees, settlement failures and refund handling belong in the integration's cost model.

3. Background: HTTP 402 and the x402 standard#

RFC 9110 reserves 402 Payment Required for future use. x402 defines payment requirements and payment payloads that can be carried over HTTP.

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 follows the selected scheme to verify, execute and settle, then returns the resource and payment result. The ordering depends on the supported payment flow.

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 can remove separate payment onboarding. A compatible endpoint can accept a payment without a provider subscription. Authentication, terms and other access controls remain a service-specific decision.

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.

4. Design principles#

Connect payment to the resource request. The client should discover and satisfy payment requirements through a machine-readable exchange, without an interactive checkout for each purchase.

Make settlement policy explicit. Response latency, finality and credit exposure are different concerns. A deployment must state when it releases a resource and how it handles pending or failed settlement.

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.

Use a predictable unit of account. Stablecoin-denominated requirements simplify budgeting, while still carrying issuer and market risk. A proposed ecosystem token must not be a prerequisite for an API payment.

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 Version 2 objects#

The official v2 specification defines three core objects. Use maintained libraries to encode and validate them; abbreviated addresses below explain their structure and are not executable integration values.

PaymentRequired. A resource server offers one or more acceptable payment methods. In HTTP transport, the JSON is base64-encoded in the PAYMENT-REQUIRED response header.

{
  "x402Version": 2,
  "resource": {
    "url": "https://api.example.com/resource",
    "mimeType": "application/json"
  },
  "accepts": [{
    "scheme": "exact",
    "network": "eip155:8453",
    "amount": "2000",
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "payTo": "0x...recipient",
    "maxTimeoutSeconds": 60,
    "extra": { "name": "USD Coin", "version": "2" }
  }]
}

amount is an integer string in the asset's smallest unit. 2000 units of a six-decimal token is 0.002 tokens. eip155:8453 identifies Base mainnet. The token contract and signing domain must match the actual network and asset; do not derive them from a display symbol alone.

PaymentPayload. The client returns the selected requirement in accepted, plus scheme-specific payment data. For an EIP-3009 authorization, the nested structure is:

{
  "x402Version": 2,
  "accepted": {
    "scheme": "exact",
    "network": "eip155:8453",
    "amount": "2000",
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "payTo": "0x...recipient",
    "maxTimeoutSeconds": 60,
    "extra": { "name": "USD Coin", "version": "2" }
  },
  "payload": {
    "signature": "0x...signature",
    "authorization": {
      "from": "0x...payer",
      "to": "0x...recipient",
      "value": "2000",
      "validAfter": "0",
      "validBefore": "...expiry timestamp",
      "nonce": "0x...32-byte random value"
    }
  }
}

The base64-encoded payload travels in PAYMENT-SIGNATURE. A nonce belongs to the authorization; the v2 payment requirements do not mandate a server-issued quote nonce. The client must match the method offered by the server, including relevant extensions.

SettlementResponse. The payment result is returned in PAYMENT-RESPONSE. A successful settlement response includes success, transaction and network; it may also include the payer and other scheme-specific details.

{
  "success": true,
  "transaction": "0x...transaction hash",
  "network": "eip155:8453",
  "payer": "0x...payer"
}

A verified authorization is not a successful settlement response. Keep the network, transaction identifier, request identifier and application outcome together for reconciliation.

5.2 The HTTP exchange#

GET /resource HTTP/1.1
Host: api.example.com

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: <base64 PaymentRequired JSON>

GET /resource HTTP/1.1
Host: api.example.com
PAYMENT-SIGNATURE: <base64 PaymentPayload JSON>

HTTP/1.1 200 OK
PAYMENT-RESPONSE: <base64 SettlementResponse JSON>
Content-Type: application/json

{"result": "..."}

The HTTP transport specification defines the wire contract. A client that already knows valid payment requirements may attach payment to its first request. An initial request followed by a paid retry is two requests, not one round trip.

5.3 EVM authorization#

EIP-3009 permits signed token transfer authorizations submitted by another party. For supported tokens, a facilitator can pay transaction gas while the payer authorizes the amount, recipient, validity window and nonce. Signing uses a network- and contract-specific domain.

EIP-3009 is one mechanism, not the definition of x402. Other networks and transfer methods have different payloads, verification rules and funding requirements. An EVM deployment must use the exact EVM scheme specification that matches its implementation.

5.4 Verification and replay control#

A resource server must compare the submitted payment against its own requirements, not trust a client-provided price. The following describes the design responsibilities, not a replacement for a scheme verifier:

1. Validate protocol version, schema, selected scheme, network and asset.
2. Match recipient and amount to the server's current requirements.
3. Validate the scheme's signature or payment proof, signing domain and validity period.
4. Apply replay and concurrent-request protection using the scheme's canonical payment identity.
5. Follow the required verification, resource execution and settlement ordering.
6. Persist the result so retries cannot purchase or deliver the same operation twice unintentionally.

For EIP-3009, replay tracking must scope an authorization to its network, token, payer and nonce. Atomic reservation is essential when multiple workers can accept the same payment. A local reservation does not lock funds onchain; settlement can still fail. Contract-wallet verification and chain state checks can require network calls, so there is no universal verification-latency guarantee.

5.5 Failure handling#

Exact status codes and error fields are part of the deployed endpoint's contract. Consult the endpoint documentation and protocol specification rather than assuming the proposed gateway exposes a particular error taxonomy.

6. Architecture#

6.1 Components#

The proposed architecture separates resource access, payment processing and merchant operations.

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 separates payment processing from resource logic. Response release must still follow the selected scheme and settlement policy.

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#

The diagram shows a proposed deferred-settlement variant. It carries credit exposure because value is delivered before settlement. It is not the default v2 HTTP success contract and must not emit a successful settlement receipt before payment succeeds. A standard deployment must implement the ordering required by its chosen scheme.

7. Verification and settlement#

7.1 Verification is not settlement#

Verification determines whether a payment authorization satisfies a scheme's requirements. Settlement moves value. Resource execution is a third operation, and its success must be reconciled with the payment outcome.

The selected payment flow determines the order of these operations. The default authorization flow verifies before execution and settles afterward; a final response must accurately report the settlement outcome. Processing time depends on the mechanism, facilitator and network.

7.2 Deferred settlement and exposure#

Releasing value before settlement completes creates credit exposure. It can be considered for a separately specified product, with explicit merchant terms and bounded limits, but must not be represented as settled payment.

Cryptographic authorizations do not use card-network chargebacks, but that does not eliminate refunds, fraud, legal disputes, issuer controls or chain risk. Allocation of settlement losses is agreed in the merchant integration terms.

8. Products#

8.1 Merchant application#

The merchant application is the entry point for payment operations and integration setup. Projects, API keys, webhooks, transaction history and wallet settings connect integration work to ongoing operations. The application's documentation specifies supported rails and integration requirements.

8.2 Published API catalogue#

The public X-Pay API catalogue and OpenAPI definition document pay-per-request APIs using USDC on Base. The published groups include:

Read the current schema for methods, required parameters and response formats. Payment requirements returned by the resource govern a particular request.

8.3 Integration libraries#

The merchant SDK is published as @xpay-llc/sdk. Consult its current package and merchant documentation for supported exports, authentication and version compatibility.

The separate x402 reference implementation maintains the protocol libraries. Protocol client/server packages and the X-Pay merchant SDK serve different integration needs; they should not be treated as interchangeable.

8.4 Gateway and usage billing#

A payment gateway connects route pricing, authorization handling, usage records and reconciliation. Metered billing can price a request, model usage or a unit of compute. Supported meters, billing schedules and rail combinations belong in the merchant integration contract rather than being assumed from the x402 protocol.

8.5 Autonomous wallets#

The proposed wallet design combines spending limits, destination policy and auditable payment history. Section 10 defines the control requirements for implementation.

8.6 Robotics and machine payments#

Robots, drones, autonomous vehicles and connected devices can participate in the same payment flow. An operator can assign a machine a wallet or delegated spending authority, with policies that define what it may purchase and how much it may spend.

A delivery robot could receive payment for a task, pay for an AI navigation API, purchase charging and continue to the next job. API purchases can use existing digital interfaces; charging and machine-to-machine services require compatible infrastructure and a reliable way to establish that the physical service was delivered.

The near-term path is integration with individual operators and service providers. It does not require every machine to become autonomous at once. On-chain transactions can record settlement, while device identity, task completion and sensitive operational data need their own verification and privacy design.

9. Security model#

The architecture requires the following controls, validated against the selected implementation.

Replay protection. Track scheme-specific payment identities and prevent concurrent reuse. For EIP-3009 this includes the authorization nonce. See section 5.4.

Quote expiry. Quotes are short lived, which bounds the window in which a payer balance can change between quote and settlement.

Scope binding. An EIP-3009 authorization binds amount, asset, network, recipient and nonce. It does not itself sign a URL or request body. The application must separately bind entitlement and idempotency to the intended operation.

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#

Independent security review should cover the deployed gateway, wallet controls and settlement path. Review scope and findings belong in the deployment's security documentation.

10. Agent safety#

Delegated spending requires controls enforced by the wallet, signer and network implementation.

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.

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. The revocation mechanism and propagation time must be documented; already released authorizations may remain usable.

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.

11. Token#

The proposed token model connects network participation to utility, staking and governance. Implementation depends on product, security and legal review.

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.

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#

Supply, allocation, vesting schedules and emissions require product and legal approval. The design should align distribution with long-term network participation.

Allocation and emissions should support measurable network usage and sustained participation.

12. Business model#

The proposed transaction model uses a 1% fee on settled volume, with no monthly minimum or setup fee. Commercial terms are agreed per integration, including rail-specific and third-party costs.

Potential additional revenue 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 intended model aligns platform revenue with merchant activity; the final fee schedule must define exceptions and third-party costs explicitly.

13. Alternatives#

These approaches can coexist. The relevant choice depends on buyer behavior, transaction size, supported rails and the operator's risk policy.

14. Roadmap#

Development priorities follow integration needs, security requirements and demand from operators.

Integration and operations. Maintain the published API catalogue, merchant integration documentation, payment records and reconciliation paths. Validate supported client, server and facilitator versions together.

Delegated spending. Extend policy-based wallet access, limits, authorization lifecycle management and operational monitoring. Test recovery and revocation as carefully as successful payments.

Machine services. Work toward integrations where robots and connected devices purchase APIs, compute, charging or other infrastructure and receive payments for completed tasks. Physical service verification and operator responsibility are prerequisites.

Network expansion. Evaluate additional settlement networks, partner facilitators, enterprise deployments and discovery mechanisms against actual demand and security requirements.

Token and governance research. Any token issuance, staking or governance design remains subject to product, legal and security review.

15. Risks and open problems#

The proposed architecture has unresolved technical, operational and commercial dependencies.

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 and token distribution may trigger different legal obligations depending on the activity and jurisdiction. This is a gating dependency on launch sequencing, not a detail to resolve later.

Settlement risk. An authorization can fail to settle. Deferred delivery policies can create merchant credit exposure; Section 7.2 describes the tradeoffs. Controls reduce exposure without eliminating it.

Security risk. Independent review of a specific gateway and settlement deployment must be established separately.

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, within this proposed architecture.

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 autonomous economy needs payment infrastructure that software can use under clear authority. x402 provides a common language for resource payments. X-Pay connects that direction to merchant operations, API integrations and stablecoin settlement.

The next step extends beyond software agents. Robots and connected devices can use the same payment principles, with additional requirements for identity, physical service verification and operational control. AI is the brain. Robotics is the body. X-Pay is the payment layer.

References#

• X-Pay API catalogue and OpenAPI definition.
• X-Pay merchant application and merchant SDK package.
• x402 v2 core specification, HTTP transport and EVM exact scheme.
• EIP-3009 transfer authorization.
• RFC 9110: HTTP 402.

Sources reviewed for this revision on 4 October 2026. Protocol and service documentation can change; pin implementation versions and use current endpoint requirements.

Legal notice#

This document describes X-Pay's technology and product direction. 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.